From ebd510c00faa0a8b09a4671524c7736f17a5e7ef Mon Sep 17 00:00:00 2001 From: Michael Lucas Date: Mon, 28 Jan 2002 10:32:01 +0000 Subject: [PATCH] Now that the Handbook knows how much overhead IPFW incurs, and how to optimize IPFW throughput, replace detailed answer with pointer to detailed answer. --- en_US.ISO8859-1/books/faq/book.sgml | 73 ++--------------------------- 1 file changed, 5 insertions(+), 68 deletions(-) diff --git a/en_US.ISO8859-1/books/faq/book.sgml b/en_US.ISO8859-1/books/faq/book.sgml index 839e03b77a..feb72998e7 100644 --- a/en_US.ISO8859-1/books/faq/book.sgml +++ b/en_US.ISO8859-1/books/faq/book.sgml @@ -9020,74 +9020,11 @@ round-trip min/avg/max/stddev = 2.530/2.643/2.774/0.103 ms - The answer to this depends mostly on your rule set and - processor speed. For most applications dealing with Ethernet - and small rule sets, the answer is, negligible. For those of - you that need actual measurements to satisfy your curiosity, - read on. - - The following measurements were made using 2.2.5-STABLE - on a 486-66. IPFW was modified to measure the time spent - within the ip_fw_chk routine, displaying - the results to the console every 1000 packets. - - Two rule sets, each with 1000 rules were tested. The - first set was designed to demonstrate a worst case scenario - by repeating the rule: - - &prompt.root; ipfw add deny tcp from any to any 55555 - - This demonstrates worst case by causing most of IPFW's - packet check routine to be executed before finally deciding - that the packet does not match the rule (by virtue of the port - number). Following the 999th iteration of this rule was an - allow ip from any to any. - - The second set of rules were designed to abort the rule - check quickly: - - &prompt.root; ipfw add deny ip from 1.2.3.4 to 1.2.3.4 - - The non-matching source IP address for the above rule causes - these rules to be skipped very quickly. As before, the 1000th - rule was an allow ip from any to any. - - The per-packet processing overhead in the former case was - approximately 2.703ms/packet, or roughly 2.7 microseconds per - rule. Thus the theoretical packet processing limit with these - rules is around 370 packets per second. Assuming 10Mbps - Ethernet and a ~1500 byte packet size, we would only be able to - achieve a 55.5% bandwidth utilization. - - For the latter case each packet was processed in - approximately 1.172ms, or roughly 1.2 microseconds per rule. - The theoretical packet processing limit here would be about - 853 packets per second, which could consume 10Mbps Ethernet - bandwidth. - - The excessive number of rules tested and the nature of - those rules do not provide a real-world scenario -- they were - used only to generate the timing information presented here. - Here are a few things to keep in mind when building an - efficient rule set: - - - - Place an established rule early - on to handle the majority of TCP traffic. Do not put any - allow tcp statements before this - rule. - - - - Place heavily triggered rules earlier in the rule - set than those rarely used (without - changing the permissiveness of the firewall, - of course). You can see which rules are used most often - by examining the packet counting statistics with - ipfw -a l. - - + Please see the Handbook's Firewalls + section, specifically the section on IPFW + Overhead & Optimization.