[25266] in North American Network Operators' Group
Re: "firewalls" at high speed -- resending
daemon@ATHENA.MIT.EDU (Hank Nussbacher)
Sun Oct 3 02:39:18 1999
Message-Id: <3.0.5.32.19991003083445.00801cb0@max.ibm.net.il>
Date: Sun, 03 Oct 1999 08:34:45 +0200
To: nanog@merit.edu
From: Hank Nussbacher <hank@ibm.net.il>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Errors-To: owner-nanog-outgoing@merit.edu
Hopefully this gets thru this time since the last time I sent it (Sept 30)
I received:
<nanog@merit.edu>: Command died with status 2: "/private/majordomo/wrapper
resend -l nanog -h merit.edu -s nanog-outgoing". Command output: Can't
locate getopts.pl in @INC (@INC contains:
/usr/local/perl-5.004_04/lib/sun4-solaris/5.00404
/usr/local/perl-5.004_04/lib
/usr/local/perl-5.004_04/lib/site_perl/sun4-solaris
/usr/local/perl-5.004_04/lib/site_perl .) at
/private/majordomo-1.94.4/resend line 74.
and no one from Merit has responded yet to my email.
>Alex Rudnev observed,
>
>>Folks, why all you are saying about the Gigabit traffic for the firewall?
>>
>>Usially, firewall stand between intranet and internet, and it should
>>proceed your upstream traffic, not more... And than, it's important to
>>measure the throughput in packets/per_second, not in the gigabits...
>>
>>Everything other is true - I suggess no one good firewall can proceed
>>gigabit traffic at all, and only a few specially designed boxes can
>>proceed 100Mbit traffic. But just again - it's a rare case when you does
>>have 100Mbit upstream link.
Super Firewalls!=20
http://www.data.com/issue/990521/firewalls.html
Almost all hit 72Mb/sec or more whether NAT was disabled or enabled.
To quote from the article:
Once again we started with a baseline test.
With no
firewall on the test bed, we achieved TCP
forwarding rates of 15.6 Mbyte/s over each
four-minute run of the test scripts; this works
out to
nearly 125 Mbit/s. So why didn=92t we get the
200-Mbit/s theoretical maximum of a switched,
full-duplex test bed? First and foremost, our
measurements are taken at the application
layer. It=92s
likely that packet headers and the continuous
opening and closing of SMTP connections took a
bite out of the effective data rate. Second,
clients
offered lots of traffic that the rule sets
expressly
denied=97so at least some of the time the wire=
was
occupied carrying traffic that wouldn=92t be
forwarded.
Third, there may have been a firepower
limitation in
the amount of traffic our clients and servers
could
offer. We can=92t say for certain how much the
degradation is due to application overhead, and
how
much to test platform limitations.=20
I would think that 200Mb/sec is achievable with not much effort and perhaps
the next testing round will prove it.=20
-Hank
