10.19. How much overhead does IPFW incur?

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:

        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:

        ipfw add deny ip from 1.2.3.4 to 1.2.3.4
      

The nonmatching 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. Don't 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.