This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.
Date: Wed, 27 Dec 2000 23:16:45 -0800 To: svlug@svlug.org Subject: Re: [svlug] firewall speed From: Rick Moen <rick@linuxmafia.com> begin Ray Olszewski quotation: > In practice, 10 Mbps isa NICs seem to be able to handle only about 5 > Mbps (there was some discussion of this limit on Don Becker's old > CEDIS site, the one that's gone). This is inherent in the design of the ethernet protocol. Above about 30% of the theoretical bandwidth, retransmits from collision packets from collision events become so frequent that you effectively can't go much faster. > When I've done some relatively careful tests, I've found that putting > a Linux-based firewall/router between two machines (though one with a > much smaller ruleset, maybe 20-25 rules in the input chain and only a > couple on output and forward) reduces throughput by about 10%. I'm still impressed that an x86/Linux filtering router with ~100 filter rules doesn't bog down unconditionally. That aside, the rule of thumb for filtering routers is that simpler rulesets reduce the possibility of errors with (in some cases) catastrophic effects on security. This is one of the areas where application-level proxy gateways have an advantage over filtering routers: It's more difficult to make catastrophic setup errors. If I tempted to run a filtering router with anything like 100 rules, I'd definitely spend some time probing it with one or more of Nessus, nmap, and Firewalk. > Since you mention seeing this problem in connection with ftp traffic, > my thought would be that ip_masq_ftp.o introduces some delays in the > time it spends matching up the data and control channels. It could be something as simple as reverse DNS lookups on client hosts opening ftp connections. He should check his tcp wrappers hostaccess files. -- Cheers, "Besides, Debian runs Web sites, Red Hat runs Rick Moen Quake, and Windows runs Half-Life." rick@linuxmafia.com -- Bryce Kerley (on Slashdot) ===