Re: iptable rules and performance
On Sat, 22 Dec 2001, Jor-el wrote:
> On Sat, 22 Dec 2001, Daniel Pittman wrote:
>> On Fri, 21 Dec 2001, Jor-el wrote:
>>
>> ...and you can't collapse the set of addresses into a series of
>> network ranges or relax the rules a fraction more by allowing all the
>> hosts to get to all the ports?
>
> I looked at the range of ip-addresses and there may be a few cases
> where the machines were clustered together in a contiguous ip range,
> and so I could use a single rule to cluster together maybe 16 machines
> or so. But thats only about 4 bits that dont need to be matched, so
> I'm not sure how much the gain would be.
*nod* Your biggest gain is probably going to be eliminating the fairly
slow set of tests against the host/port matches for all other traffic.
However, I am sure you already know to make sure that you do less
matches per packet by sorting the rules. :)
[...]
>> That comes out as around 5.75 packets per second. I can't imagine
>> that you would find this over-taxing for any system. :)
>
> You're right - I should have done this trivial calculation before
> emailing my question. Actually, I would say that about .48 million
> packets arrive within 8 hours. Thats .48 million inwards and .48
> million outwards . The packet rate then comes out to about 33 packets
> / sec .
So, for my router that would be ... around 7,060,606 machine cycles per
second on my fairly archaic Pentium 233. Even accounting for memory
reload costs &c., I can't see that being over-taxing.
I would spend more time servicing interrupts on the less-than-optimal
(ahem) NE2K-PCI card I use. ;)
> Still not worrisome I think. However, I have noticed that I have a few
> dropped packets a week, and this seems to indicate that perhaps the
> burst rates are high enough that the NIC cant keep up with the traffic
> even without any firewalling...
What sort of card is it? Er, and what sort of rate can you see from the
connection?
>> It's worth noting that using iptables tends to mean that you take the
>> slow path with your packets as well as the cost of the firewalling
>> but, even so, it's not the global packet rate you need to worry
>> about.
>
> I dont follow. What is the slow path and what is the fast path?
The Linux TCP stack has a "fast" path -- it's the common case where you
don't have firewalling or whatever involved.
Packets that can follow the fast path have to be pretty simple and they
get routed, processed, etc, *really* fast.
Anything that doesn't, because of firewall tables, odd or non-standard
TCP options, weird misaligned data due to odd packing, &c., takes the
"slow" path.
This path can take a lot more cycles to process a packet through because
it's not really the common way that things work.
For example, fragment reassembly and a copy of the SKB (packet headers
and data) are taken in the "slow" path for iptables.
When you see the advertising that says Linux can move X packets per
second on Y hardware, that almost certainly means "X fast-path packets,"
not "X slow-path packets." :)
>> At least, not unless you plan on using a 486 or something to run the
>> system or your firewall is loaded heavily...
>
> Well, its a dual Pentium II 300 (not sure about the exact speed, and
> its too much trouble to log on right now and find out for sure) with
> 256 MB RAM. So you are right, it is probably a non-issue.
Unless you have a pipe *much* bigger that 1.5mbit either way, I wouldn't
worry. That's going to be ample (read, wasted ;) for most uses.
>> Do a bench test over your 100 mbit network. :)
>
> Good idea anyway. How does one do such things?
Well, the two things you probably care about are the UDP traffic and the
rest of the traffic.
So, to test the rest of the traffic, grab two other machines and set
them up as such:
+--------+ +----------+ +------+
| source |-----| firewall |-----| sink |
+--------+ +----------+ +------+
Have the source and sink machines connected to the firewall via 100mbit
network cable -- use a pair of hubs, switches or crossover cables
depending on what you have on hand.
Make sure your rules are running on the firewall machine, then use
something that generates TCP packets (that is, packets that *don't*
match your UDP rule chain at all).
This should send data as fast as it can to the sink machine. Then, sit
on the firewall and make sure that it doesn't drop packets and that the
CPU time spent isn't unreasonable.
To test the UDP stuff is a little harder, but not much. Grab your
favorite scripting or programming language; Perl, Python, Ruby and C all
work, and most others probably do as well.
Then use the raw network packet generator interface to send a lot of UDP
packets from the source to the sink, some of which do and some which
don't match your rules...
There are, IIRC, a number of packages in the Debian archive which allow
you to trivially generate IP packets to specification. These are
probably the easiest way to do this.
Daniel
--
CAUTION: This product exerts a force on every other object in the
Universe, proportional to the product of their masses divided by the
square of the distance between them, center to center.
Reply to: