Hi,
Sorry, I hadn't noticed that I had removed that part of information by
mistake when I split the debug information in a different file. I had
been told about that setting and had seen the thread, which stated
around 256MB per gigabit interface. I had tested from 1000 up to 2500,
and although it did reduce the congestion a lot, I was still seeing over
1 per second, which I can't consider that safe for production. I haven't
tested higher than 2500 though.
Thanks,
Steve
Thomas Althoff wrote:
What about net.inet.ip.ifq.maxlen ?
Try net.inet.ip.ifq.maxlen=2500 at least.
I don't recall Henning's rule, search the archive something like X times
your number of nics.
-Thomas
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Steve Johnson
Sent: den 8 maj 2008 23:18
To: misc@openbsd.org
Subject: PF Congestion and state table question
Hi,
After successfully putting into testing the new firewall setup with some
of our services, we are seeing some low congestion issues It's not
major, but since I'm only throwing it half our expected traffic for the
time being, I would have liked it to be at 0.
Our setup is a 4.3 i386 (Xeon 3GHz) box with 6 Intel gigabit interfaces
(em), all of them having at least one carp interface, and 2 of them
having trunked VLANs. NAT is only applied to outgoing traffic, which is
very minimal. Just about all of the traffic that I'm sending to it right
now consists of very small XML requests over HTTP, so low throughput but
very high session count. All the interfaces have the speed and duplex
hardcoded at the switch and system level.
Here's a link that includes some possible debugging information from
pfctl -si, some sysctl parameters, top load and dmesg:
http://www.sjohnson.info/other/diaginfo.txt
And here's the set of PF rules that are active:
http://www.sjohnson.info/other/pf.conf
Just about all the traffic that is coming in at the moment is hitting
that first "pass in quick" rule.
Is the congestion issue that I'm getting considered "normal" under that
type of traffic and with the present hardware? Are there any other
settings that I should look into tweaking?
Also, is it expected that a total of 135K sessions in our link load
balancers give us around 550K sessions with PF? I now know it's supposed
to be at least double because of the directional state entry, but I just
find the number alerting, especially since it was close to a 1:1 when we
compared them to our netfilter states (agreeing that state processing is
completely different between the two). This is with aggressive setting,
as I was getting passed 750K sessions with conservative setting.
Thanks again for help,
Steve Johnson
