On Mon, Jan 17, 2005 at 10:22:33AM +0100, marc gmx wrote: > This is a part of /var/log/messages > > /root # more /var/log/messages > Jan 14 09:26:53 dmzserv3 /bsd: pf: started > Jan 14 09:26:53 dmzserv3 /bsd: altq: started > Jan 14 09:31:08 dmzserv3 /bsd: d address 192.168.13.3 > Jan 14 09:31:08 dmzserv3 /bsd: pf_map_addr: selected address 192.168.13.3
These are only printed if you have debug logging enabled (pfctl -x m). I don't know how expensive the logging is in your case (given several thousand messages per second), but try reducing the log level to 'urgent' with pfctl -x u and repeat. One theory is that the IP input queue is overflowing. It can hold 300 packets by default. When the CPU is not fast enough to handle packets, the queue will fill up and pf will drop any packet when the queue is full. The reasoning is that pf's processing of a packet is making the condition worse, as state lookups, ruleset evaluation, and in your case, NAT address selection, are causing CPU load. Hence, we drop packets without wasting more CPU and hope the condition gets better. This strategy makes sense, assuming it's pf contributing significantly to the delay in packet processing. Unfortunately, the fullness of the IP input queue cannot be queried from userland (or I don't know how), netstat -Id prints the individual interfaces' send queues, not the (global, across all interfaces) input queue. You don't have a huge ruleset, the only peculiar thing about your setup is that you create a new NAT state for each of those packets. So, it's possible that NAT address/port selection is so expensive that your CPU can't execute it at the rate you're sending packets. Or it might be that the logging mentioned above is the expensive thing. I've run similar tests on weak boxes, like nmap -sT -t insane creating of NAT states within seconds, and never seen this happen. I wonder if it's related to the round-robin address selection. If you can, try running the test with NATing to a single fixed address (-> 192.168.13.3, instead of -> (if) round-robin), or even with no NAT rule at all. Daniel
