netfilter buglog - Aug 2004 - [Bug 40] system hangs, Availability problems, maybe conntrack bug, possible reason here.

https://bugzilla.netfilter.org/cgi-bin/bugzilla/show_bug.cgi?id=40





------- Additional Comments From pmccurdy@net-itech.com  2004-08-04 06:06
-------
We have managed to replicate this bug in-house.  It seems to happen to us when
we have a machine acting as a NAT router that we saturate with outgoing UDP
packets;  we use hping2 to generate them from a workstation connected via 100
Mbit ethernet.  While this is happening, if a PPTP connection comes into that
server, there is a very good chance the machine will hang.  



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

https://bugzilla.netfilter.org/cgi-bin/bugzilla/show_bug.cgi?id=40





------- Additional Comments From luismi@b2bi.es  2004-08-04 10:08 -------
Hi Peter,

As I understand you aren't using vlans at all in that linux box, right?
I can't reproduce the problem here since we change the network topology to
avoid
this problem, anyway, maybe you can obtain some useful information with programs
like netstat-nat (http://tweegy.demon.nl/projects/netstat-nat/index.html) or
netstat-viewer (http://cv.intellos.net/), I am not sure.

If the problem is at the conntrack table (is it a table, isn´t it?) maybe you
can do some tunning modifying the timeouts:
>From http://kalamazoolinux.org/presentations/20010417/conntrack.html (<-
maybe
it is obsolete, not sure, there is also a module at pom that offers the option
to change the timeouts via sysctl)

Timeouts
--------
Something to note is that timeouts are reset to the maximum each time a
connection sees traffic. Timeouts are set in
/usr/src/linux/net/ipv4/netfilter/ip_conntrack_proto_tcp.c at compile time. Here
is the relevant section of code:


static unsigned long tcp_timeouts[]
= { 30 MINS,    /*      TCP_CONNTRACK_NONE,     */
    5 DAYS,     /*      TCP_CONNTRACK_ESTABLISHED,      */
    2 MINS,     /*      TCP_CONNTRACK_SYN_SENT, */
    60 SECS,    /*      TCP_CONNTRACK_SYN_RECV, */
    2 MINS,     /*      TCP_CONNTRACK_FIN_WAIT, */
    2 MINS,     /*      TCP_CONNTRACK_TIME_WAIT,        */
    10 SECS,    /*      TCP_CONNTRACK_CLOSE,    */
    60 SECS,    /*      TCP_CONNTRACK_CLOSE_WAIT,       */
    30 SECS,    /*      TCP_CONNTRACK_LAST_ACK, */
    2 MINS,     /*      TCP_CONNTRACK_LISTEN,   */
};

There is no absolute timeout for a connection. 


Hope this helps.
LuisMi



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

https://bugzilla.netfilter.org/cgi-bin/bugzilla/show_bug.cgi?id=40





------- Additional Comments From pmccurdy@net-itech.com  2004-08-05 01:45
-------
Interesting about the vlans, we originally noticed the problem without using
vlans, but the reproduction steps I mentioned were tested in a setup involving a
vlan.



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.