Any one who can tell me the performance of ipfw in real life?

C

cyberman

I'm think to port ipfw to a multi-core platform with two 10GbE interface. Before that it's better to know the performance others already know, like the network bandwidth already tested and how many rules used so I can make some estimation.

Like most other rule-based firewall, ipfw scan rules linearly, thus its performance will drop with rule number increased. I'll be appreciated if some one tell me usually how many rules will be used in real-life firewall.


And another question, is there any other way to design a firewall other than that? I thought maybe we can expand all the rules to generate address pairs and only associate the lowest rule number which use that address pair and use hash to organize and search. Maybe it will speed-up match will a lot of rules used, but for some address like Class-A network, it will generate too many address pairs and make it unusable.
 
Why ipfw? At least pf has the quick keyword available, so you can skip the rest of the ruleset once a 'quick match' occurs.
 
Okay, I do not have much experience with ipfw. However, duchD is right about quick keyword. It is available under pf too.

For all our branch offices we have pf installed on either FreeBSD or OpenBSD. We have 10 or 100Mbps metro Ethernet Internet connection. AMD 170 + 4GB ram and 250 GB hard disk x 2 boxes works in failover mode using pf CARP failover. Never had problem and we block over 30000+ bad IPs and subnets. PF is ultra fast. PF is perfect alternative to overpriced cisco gear for nat and DMZ usage. I'm sharing additional info coz I'm fan of PF and it may help you too :D
 
And if you need a number from me: PF on a bridge, with two Gig-E fiber NICs doing at least 80-125 Mbit/sec, handling 55,000+ state entries (and growing), and a system load of < 0.1.
 
DutchDaemon said:
Why ipfw? At least pf has the quick keyword available, so you can skip the rest of the ruleset once a 'quick match' occurs.
Click to expand...

IPFW is a first-match-wins packet filter, which means as soon as a packet matches a rule, it stops processing the packet. Think of it as "quick" always being on.

PF/IPF are last-match-wins packet filters, where every single rule in the ruleset is checked for every single packet, unless one uses the "quick" keyword.
 
cyberman said:
I'm think to port ipfw to a multi-core platform with two 10GbE interface. Before that it's better to know the performance others already know, like the network bandwidth already tested and how many rules used so I can make some estimation.

Like most other rule-based firewall, ipfw scan rules linearly, thus its performance will drop with rule number increased. I'll be appreciated if some one tell me usually how many rules will be used in real-life firewall.
Click to expand...

You can use "skipto" to break the ruleset into chunks. Thus dropping the number of rules that any individual packet has to be checked against.

And another question, is there any other way to design a firewall other than that? I thought maybe we can expand all the rules to generate address pairs and only associate the lowest rule number which use that address pair and use hash to organize and search. Maybe it will speed-up match will a lot of rules used, but for some address like Class-A network, it will generate too many address pairs and make it unusable.
Click to expand...

IPFW and PF do a whole lot of optimisation behind the scenes. The rule that you see on the screen is nothing like the rule that is actually used during the search and packet processing. :)

Our "biggest" firewall for traffic is:
  • ASUS motherboard
  • dual-core Opteron 1200-series CPU @ 2.6 GHz
  • 2 GB DDR2 SDRAM
  • 80 GB SATA harddrive
  • quad-port Intel Pro/1000MT PCIe NIC
This is connected via gigabit fibre to all our in-town secondary schools. It does vlan tagging for all of them, routing between them, some 1-1 NAT for public servers, with 836 ipfw rules, using 10 tables and several sets of IPs in the rules. Manages to push just under 100 Mbps from the fibre sites to the Internet throughout the day without ever using more than 10-15% CPU. Most of that is from using natd instead of the nat keyword (so it's userland NAT instead of in-kernel). And it pushes just under 250 Mbps across the fibre link between sites during backups.

Our "biggest" firewall for number of rules uses the same hardware as above with just under 1800 individual rules, horribly, horribly unoptimised (no tables, spaghetti-use of skipto rules, less than half use the interface name, etc).

Our school firewalls are only P2 333 MHz systems with 256-512 MB RAM using 100 Mbps NICs. They can saturate the 10 Mbps Internet connections without ever using more than 50% CPU. These all have just under 700 very specific rules (protocol, source/dest IPs and ports, NIC names, tables, etc) without using any skipto rules. Packets that will be denied can be tested against every rule in the list.

So there's lots of scalability in IPFW, at least on single-CPU systems. It really matters more about the NIC performance.
 
phoenix said:
IPFW is a first-match-wins packet filter, which means as soon as a packet matches a rule, it stops processing the packet. Think of it as "quick" always being on.
Click to expand...

Either this is at odds with ipfw(8), or these paragraphs are open to more than one interpretation:

The packet passed to the firewall is compared against each of the rules in the firewall ruleset. When a match is found, the action corresponding to the matching rule is performed.
Click to expand...
Also note that each packet is always checked against the complete ruleset, irrespective of the place where the check occurs, or the source of the packet.
Click to expand...

This looks like 'read every rule for every packet, then pick the best match'. I miss keywords like 'starting from the top, until a match occurs' ;)
 
Hrm, well, I guess someone needs go through the source and figure this one out.

This is the first I've seen it put into writing like that. All the how-tos and docs and whatnot that I've read over the years have split ipfw from (i)pf based on first-match/last-match rules processing.

All the e-mails I've received from freebsd-ipfw@ also talk about the first-match-wins/stop-processing feature of ipfw. Especially when divert and tee rules are involved.

I think I'll send an e-mail to ipfw@ and see if anyone who's been playing in the ipfw code lately can give a definitive answer.
 
First to explain why I'm thinking to use ipfw. I browsed the source code of netfilter, ipfw and pf. It seems netfilter is bind too tightly to Linux protocol stack, and pf has too little comments in source code so it's very hard for me to understand it in a short time.

Besides the above, ipfw can used directly on Ethernet frames, and that's where I want to put it, the new platform will get L2 packet directly from high-speed interfaces without TCP/IP protocol stack. I've seen somebody else already porting ipfw into Windows.

The network bandwidth I'll face to is from 4GbE to 10GbE.
 
Sorry I posted it before finished and can't find out a way to edit it. Doesn't this forum support editing?

If pf is really fast than ipfw, I'll think about it.
 
phoenix said:
You can use "skipto" to break the ruleset into chunks. Thus dropping the number of rules that any individual packet has to be checked against.
.........
Click to expand...

Thanks for patient reply. I'm not very familiar with ipfw, I only used it on our web site server with about 20 rules. I'll learning how to use "skipto".

Do you have any idea what the traffic is if you stop firewall on your "biggest" firewall?
My application is easy than yours since I cant just support static rules, but the traffic is from 4GbE to 10GbE. Like maybe only use two 10GbE fibre to act like a transparent firewall.
 
phoenix said:
Hrm, well, I guess someone needs go through the source and figure this one out.
Click to expand...

I've read some part of the source code. ipfw organize rules into a list sorted with rule number, and for static rules just do a first-match searching. For a specific rule it just break it into instructions and actions, when using that rule it will go through instructions to see if the corresponding parts of the packet match what instruction specified, and is any part can't match it will stop and goto the next rule.

I've thought to use some algorithm like LPM to speed-up matching, but the problem is LPM only need destination IP and mask, but firewall need to check a lot of things than that. I've also thought about expanding all the address and associating only the action of the lowest-numbered rule which match that address pairs, but it will consume so much memory if Class-A network used.
 
cyberman said:
Sorry I posted it before finished and can't find out a way to edit it. Doesn't this forum support editing?
Click to expand...

After 10 posts && 10 days of membership. You should now be able to edit.
 
According to Julian Elischer and Ian Smith, the man page and I are both correct. :)

IPFW will stop testing rules as soon as a terminal rule matches (allow, deny, divert, a couple others). IPFW will continue testing rules for non-terminal matches (count/log, tee, a couple others). And IPFW will continue checking rules starting at the last match for certain rules (divert, tee, a couple others).

IOW, you can think of IPFW as a first-match-wins rules processing system, with the caveat that some rule types don't stop the rules processing.
 
You must log in or register to reply here.
Back
Top