os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Now that the Handbook knows how much overhead IPFW incurs, and how to

Browse source 
optimize IPFW throughput, replace detailed answer with pointer to
detailed answer.
This commit is contained in:
Michael Lucas 2002-01-28 10:32:01 +00:00
parent 222defdacd
commit ebd510c00f
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=11925
1 changed files with 5 additions and 68 deletions
Download patch file Download diff file Expand all files Collapse all files

73
en_US.ISO8859-1/books/faq/book.sgml
View file

@ -9020,74 +9020,11 @@ round-trip min/avg/max/stddev = 2.530/2.643/2.774/0.103 ms</screen>
</question>
<answer>
<para>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.</para>
<para>The following measurements were made using 2.2.5-STABLE
on a 486-66. IPFW was modified to measure the time spent
within the <literal>ip_fw_chk</literal> routine, displaying
the results to the console every 1000 packets.</para>
<para>Two rule sets, each with 1000 rules were tested. The
first set was designed to demonstrate a worst case scenario
by repeating the rule:</para>
<screen>&prompt.root; <userinput>ipfw add deny tcp from any to any 55555</userinput></screen>
<para>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
<literal>allow ip from any to any</literal>.</para>
<para>The second set of rules were designed to abort the rule
check quickly:</para>
<screen>&prompt.root; <userinput>ipfw add deny ip from 1.2.3.4 to 1.2.3.4</userinput></screen>
<para>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 <literal>allow ip from any to any</literal>.</para>
<para>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.</para>
<para>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.</para>
<para>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:</para>
<itemizedlist>
<listitem>
<para>Place an <literal>established</literal> rule early
on to handle the majority of TCP traffic. Do not put any
<literal>allow tcp</literal> statements before this
rule.</para>
</listitem>
<listitem>
<para>Place heavily triggered rules earlier in the rule
set than those rarely used (<emphasis>without
changing the permissiveness of the firewall</emphasis>,
of course). You can see which rules are used most often
by examining the packet counting statistics with
<command>ipfw -a l</command>.</para>
</listitem>
</itemizedlist>
<para>Please see the Handbook's <ulink
url="../handbook/firewalls.html">Firewalls</ulink>
section, specifically the section on <ulink
url="../handbook/firewalls.html#IPFW-OVERHEAD">IPFW
Overhead & Optimization</ulink>.</para>
</answer>
</qandaentry>