On Wed, 17 Oct 2012, Mark McCullough wrote:
On 2012 Oct 17, at 21:10 , [email protected] wrote:
On Wed, 17 Oct 2012, Andrew Hume wrote:
screwed by linux again. sigh.
so apparently i am overloading my pathetic linux system with too much tcp/ip
traffic.
is there any way to detect this while (or before or after) it is happening?
of course no error messages are emitted.
but might there be some other thing buried away somewhere, like /proc?
It depends on what caused the problem.
I would guess that the cause of the problem is probably due to overloading the
conntrack capabilities of your system (needed for stateful firewalling, a
bottleneck otherwise)
there are lots of stats available in:
/proc/sys/net/ipv4/netfilter
If this is the case, you may have some entries in your logs and dmesg that look
like:
nf_conntrack: table full, dropping packet.
adding something like:
net.ipv4.netfilter.ip_conntrack_max = 256000
will probably bump up the limit (at the cost of eating more memory)
If you have a system that is not needing the stateful firewalling, compiling a
kernel without conntrack will save you some memory and a potentially
significant amount of CPU
Normally I would only expect problems on either a very low-end box (a home wifi
router for example) or a box that is under a huge load of short-lived
connections.
Connection tracking only turns on when iptables is going to do certain
types of things like port forwarding/NAT. Otherwise, it isn't even
loaded into the kernel. We had to adjust one of our internal documents
on port forwarding because of that problem. As you mention, it tends to
be noisy in logs, per the old discussion, no log messages.
That is not my experience. If connection tracking is enabled in the
kernel, it is invoked for all packets, no matter what iptables rules you
have in place.
It may be that in some configurations the kernel module doesn't get loaded
in some cases, but you would really want to check that.
David Lang
_______________________________________________
Tech mailing list
[email protected]
https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech
This list provided by the League of Professional System Administrators
http://lopsa.org/
