Added section: How much overhead does IPFW incur?

svn path=/head/; revision=2257

FAQ/network.sgml

@@ -1,4 +1,4 @@
-<!-- $Id: network.sgml,v 1.2 1997-11-14 20:22:31 brian Exp $ -->
+<!-- $Id: network.sgml,v 1.3 1997-12-14 22:20:38 alex Exp $ -->
 <!-- The FreeBSD Documentation Project -->
 
   <sect>
@@ -730,5 +730,75 @@ vat_nv_record	Recording tools for vat ftp.sics.se:archive/vat_nv_record.tar.Z
       <p>For further information on configuring a FreeBSD firewall,
       see the <url url="../handbook/firewalls.html" name="Handbook section">.
 
+    <sect1>
+      <heading>How much overhead does IPFW incur?</heading>
+
+      <p>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.
+
+      <p>The following measurements were made using 2.2.5-STABLE on
+      a 486-66.  IPFW was modified to measure the time spent within
+      the <tt/ip_fw_chk/ routine, displaying the results to the console
+      every 1000 packets.
+
+      <p>Two rule sets, each with 1000 rules were tested.  The first set
+      was designed to demonstrate a worst case scenario by repeating the
+      rule:
+
+      <verb>
+        ipfw add deny tcp from any to any 55555
+      </verb>
+
+      <p>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 <tt>allow ip
+      from any to any</tt>.
+
+      <p>The second set of rules were designed to abort the rule
+      check quickly:
+
+      <verb>
+        ipfw add deny ip from 1.2.3.4 to 1.2.3.4
+      </verb>
+
+      <p>The nonmatching source IP address for the above rule causes
+      these rules to be skipped very quickly.  As before, the 1000th
+      rule was an <tt>allow ip from any to any</tt>.
+
+      <p>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.
+
+      <p>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.
+
+      <p>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:
+
+      <itemize>
+
+        <item>Place an `established' rule early on to handle the
+        majority of TCP traffic.  Don't put any <tt>allow tcp</tt>
+        statements before this rule.
+
+        <item>Place heavily triggered rules earlier in the rule
+        set than those rarely used (<bf>without changing the
+        permissiveness of the firewall</bf>, of course).  You can see
+        which rules are used most often by examining the packet counting
+        statistics with <tt>ipfw -a l</tt>.
+
+      </itemize>
+
   </sect>