perfSONAR User Q&A and Other Discussion

[Mark Feit <>]

Antoine Delvaux writes:


>I think another quick way to optimise the iptables rules, and still use 
>connection tracking, is to move the ESTABLISHED state tracking as the very 
>first single rule of the set and disregard port number in this rule.
>...
>That way, most packets will go through the very first rule and only the new 
>connections will need to go through additional checks.

That would help.  Ed’s suggestion would cut some time out of it, but there 
are still a lot of checks being made and not in the most optimal order.

My seat-of-the-pants guess is that putting a single check for the 
time-sensitive port numbers first in the chain would probably be faster than 
checking for an established connection.  The best way to find out for sure is 
doing some empirical study of the various tests’ impact on throughput and 
making use of the faster ones.  A slow system will magnify the deficiencies, 
making it a good testing tool.

>BTW, if anybody has more understanding of what is happening in the linux 
>kernel with the iptables rules and the limited throughput on low end 
>devices, it might be a good topic to submit to this BoF session at netdev 
>1.1: 
>http://www.netdevconf.org/1.1/bof-network-performance-bof-jesper-dangaard-brouer.html

Everything going on here is iptables 101.  Each decision being made about a 
packet takes time and additional time taken to make each decision (i.e., slow 
machine) limits throughput.  Ipchains (the predecessor to iptables, before 
Linux 2.4) was an improvement over userland proxy-type firewalls like FWTK in 
the 1990s.  It didn’t take long for people to realize that putting it in the 
kernel didn’t give them carte blanche to stuff in as many rules as they could.

Routers have the same problem when you apply ACLs and take the processing out 
of the ASICs/FPGAs that route quickly and shunt them into software.  Back 
before layer 2 got meshy and intra-AS traffic had more layer 3 hops, ISPs 
avoided using ACLs on core routers because throughput was king.  Filtering at 
the edges distributes the work more evenly, lets you throw more horsepower at 
higher-traffic demarcs and keeps unwanted traffic out of the core.  (Sorry, 
that was a bit of a digression…)

—Mark