Firewall Wizards mailing list archives
Re: High Speed Firewalls
From: Crispin Cowan <crispin () wirex com>
Date: Tue, 07 Mar 2000 20:55:01 +0000
David Newman wrote:
We may be talking at cross-purposes here. I agree fully with what you say here, but I was making a different point. My contention is that it is not possible to ftp a 12.5-Mbyte (100-Mbit) file through a firewall with 100Base-T interfaces in 1 second, even though the interfaces are theoretically capable of moving traffic at that rate.
Ok. My contention is precisely that it IS possible to FTP a 100 Mbit file through a firewall with 100Base-T interfaces in one second, plus the epsilon time of network latency for the last packet to get through. If the application experiences lower throughput than that, then it may be the fault of the end-host systems, and not the firewall.
Even a perfect firewall will still have to deal with packet headers, TCP connection setup and tear down, and its own inspection engine -- and all that pushes us over our 1-second budget. Ergo, there's no such thing as "line-rate" throughput from an application perspective. Any claim that a firewall does so (and I've heard several such claims) is a lie.
This is the part that does not follow. All of those issues relate to packet latency, not throughput. If the firewall is a makes no attempt at parallel operation, and therefore processes each packet sequentially, then your claim is true. But those assumptions are not necessarily true. A firewall could have a CPU that is a great deal faster than line speed, and therefore have ample time to inspect one packet while another packet is being transferred from the network interface to the machine's memory.
This is a different issue than measuring bits on the wire, as we do when we benchmark switch or router performance. Of course there are firewalls that can saturate a 100Base-T link, full duplex; I've tested several of these. But they don't, and can't, push application data or even TCP at "line rate."
The only fundamental reason that applications cannot see "line rate" performance at the application layer is the bandwidth overhead imposed by packet headers. All that stuff about inspection is irrelevant to the question of theoretical upper bounds to firewall bandwidth. Certainly the stuff about inspection is relevant to *practical* discussions of firewall bandwidth. The more inspection you try to do at "line speed", the more computes you're going to need in the firewall. But if you throw enough CPU hardware at the problem, you certainly can get the firewall to process packets at line speed bandwidth, as evidenced by your evaluations that saturate 100Base-T links. Crispin ----- Crispin Cowan, CTO, WireX Communications, Inc. http://wirex.com Free Hardened Linux Distribution: http://immunix.org JOBS! http://immunix.org/jobs.html
Current thread:
- Re: personal firewalls, (continued)
- Re: personal firewalls elad (Mar 21)
- Re: High Speed Firewalls Mike Barkett (Mar 07)
- Re: High Speed Firewalls Bennett Todd (Mar 07)
- Active FTP behind a router doing NAT Arnaud Chiaberge (Mar 12)
- Re: Active FTP behind a router doing NAT Ryan Russell (Mar 17)
- Re: High Speed Firewalls Eric Hall (Mar 13)
- Re: High Speed Firewalls Crispin Cowan (Mar 12)
- RE: High Speed Firewalls David Newman (Mar 12)
- Re: High Speed Firewalls Crispin Cowan (Mar 12)
- RE: High Speed Firewalls David Newman (Mar 12)
- Re: RE: High Speed Firewalls Crispin Cowan (Mar 17)
- RE: RE: High Speed Firewalls David Newman (Mar 17)
- Re: RE: High Speed Firewalls Crispin Cowan (Mar 21)
- RE: RE: High Speed Firewalls David Newman (Mar 21)
- Re: RE: High Speed Firewalls Crispin Cowan (Mar 21)
- RE: RE: High Speed Firewalls David Newman (Mar 21)
- Re: RE: High Speed Firewalls Crispin Cowan (Mar 21)
- RE: RE: High Speed Firewalls David Newman (Mar 21)
- Re: RE: High Speed Firewalls Saravana Ram (Mar 23)