On 10/10/14 23:34, Stuart Henderson wrote:
oops, missed your sysctl -a output (I wasn't expecting to see it,
well done ;-)
net.inet.ip.ifq.drops=140720
You would probably benefit from increasing net.inet.ip.ifq.maxlen,
maybe double it once or twice and see if net.inet.ip.ifq.drops stops
On Fri, 10 Oct 2014 21:28:25 + (UTC)
Stuart Henderson s...@spacehopper.org wrote:
Hi Stuart
Many thanks for the input, i do have access to the servers too.
I was going to suggest that you might have asymmetric routing causing
split states i.e. one firewall seeing inbound packets, one
Hi
First, thank you Paul and Andy for your input! I'm very thankful for
your effort!
On Thu, 2014-10-09 at 16:08 +0100, Andy wrote:
I have seen this when the allowed number or states is too low and PF
clears the idle states too early..
See http://www.openbsd.org/faq/pf/options.html;
set
On 2014-10-09, Nicolas Christener li...@0x17.ch wrote:
Besides those steps we also disabled one of the boxes by stopping ospf
and removing the carp interfaces - however, the disconnects didn't go
away.
I was going to suggest that you might have asymmetric routing causing
split states i.e. one
oops, missed your sysctl -a output (I wasn't expecting to see it,
well done ;-)
net.inet.ip.ifq.drops=140720
You would probably benefit from increasing net.inet.ip.ifq.maxlen,
maybe double it once or twice and see if net.inet.ip.ifq.drops stops
increasing.
Hello
We have a somewhat curious issue and run out of ideas ;)
We do not have a trigger to reproduce the issue, but we for example see
some IRC disconnects from users behind our firewall.
What we have:
- two HP Proliant DL360 G5 with Broadcom BCM5708 NICs, 2GB RAM,
Intel Xeon E5335@2.0GHz
-
I can confirm that we've seen this with any long running TCP connections
in environments where pf was literally only sampling packets for pflow
(not even actually firewalling.)
Removing pf from the equation fixed the problem right up.
5.5 current was what I was running at the time.
On
I have seen this when the allowed number or states is too low and PF
clears the idle states too early..
See http://www.openbsd.org/faq/pf/options.html;
set optimization/option/
Good luck, Andy.
On 09/10/14 14:58, Paul S. wrote:
I can confirm that we've seen this with any long running TCP
8 matches
Mail list logo
