HELP: Conntrack table filling up !!!
Hi everybody,
I have this problem with connexion tracking table filling to the max
and then it remains in a state "near the edge" that will allow only a small number of new conexions and will cause a large packet loss, even "sendto: operation not permited" sometimes when I ping the neighboor routers and so on.
Everything got cleared up if I delete the ip tables rules that deal
with contrack and remove and reinsert ip_conntrack module.
Now if there is some method of avoiding this ( I only see a discution
from 2001 that was not conclusive) or if there is is an method to time-out faster those conexions in conntrack table or even a method of globaly quick-flush that table ( could be a even an experimental patch, I'm willing to try it and report) I'd very muck like to hear about it.
Anyhow, thank you for your good work and have a happy new year.
Regards,
Mircea Ciocan
P.S. kernel is 2.4.18 and machine have enough ram ( 512 MB) and processing power ( P-III 800MHZ), traffic is something like 50 Mb/s top ans 25-30 medium.
There are ways in which pings (ICMP packets) can fill up conntrack tables quickly. Are you running into problems with ICMP traffic only or with any traffic ? e.g. look at /proc/net/ip_conntrack . Is it filled up with ICMP traffic connections only ? If so, you might want to protect your linux box from malformed ICMP packets, by DROPping all such packets in the "filter" table.
Ranjeet Shetye
Senior Software Engineer
Zultys Technologies
771 Vaqueros Avenue
Sunnyvale CA 94085
USA
[email protected]
http://www.zultys.com/
Quoted 42 lines
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Mircea Ciocan
Sent: Monday, December 23, 2002 11:00 AM
To: [email protected]
Cc: [email protected]
Subject: HELP: Conntrack table filling up !!!Hi everybody,
I have this problem with connexion tracking table
filling to the max
and then it remains in a state "near the edge" that will allow only a small number of new conexions and will cause a large packet loss, even
"sendto: operation not permited" sometimes when I ping the neighboor routers and so on.
Everything got cleared up if I delete the ip tables
rules that deal
with contrack and remove and reinsertip_conntrackmodule.
Now if there is some method of avoiding this ( I only
see a discution
from 2001 that was not conclusive) or if there is is an method to time-out faster those conexions in conntrack table or even a method of
globaly quick-flush that table ( could be a even an experimental patch,
I'm willing to try it and report) I'd very muck like to hear about it.
Anyhow, thank you for your good work and have a happy new year.Regards,
Mircea Ciocan
P.S. kernel is 2.4.18 and machine have enough ram ( 512 MB) and processing power ( P-III 800MHZ), traffic is something like 50 Mb/s top
ans 25-30 medium.
Quoted 7 lines · Ranjeet Shetye
There are ways in which pings (ICMP packets) can fill up conntrack tables quickly. Are you running into problems with ICMP traffic only or with any traffic ? e.g. look at
/proc/net/ip_conntrack. Is it filled up with ICMP traffic connections only ? If so, you might want to protect your linux box from malformed ICMP packets, by DROPping all such packets in the "filter" table.
Don't arbitrarily drop all ICMP, bad idea, breaks a few things.
Couldn't the 'full ip conntrack table' problem be solved by echo'ing a
bigger number into /proc/sys/net/ipv4/ip_conntrack_max ?
root@jimblewix:/proc/sys/net/ipv4; 23:48:19 0$ echo 32768 > ip_conntrack_max
certainly changes it here.
-Ath
Signature · 4 lines
- Athanasius = Athanasius(at)miggy.org / http://www.miggy.org/
Finger athan(at)fysh.org for PGP key
"And it's me who is my enemy. Me who beats me up.
Me who makes the monsters. Me who strips my confidence." Paula Cole - MEOh no, definitely, I was only talking of dropping the malformed packets. Unfortunately, how do you identify/match malformed ICMP packets in iptables ?? Don't know that one.
Actually, the ICMP problem that I have seen does not go away with a larger ip_conntrack_max. The extra table space just gets filled up. Agreed, that the ICMP packets I used to flood the iptables conntrack mechanism did not strictly comply with ICMP RFC standards, but then which cracker cares about standards ? :( That's why I asked, are you seeing malformed ICMP packets ?
Ranjeet Shetye
Senior Software Engineer
Zultys Technologies
771 Vaqueros Avenue
Sunnyvale CA 94085
USA
[email protected]
http://www.zultys.com/
Quoted 38 lines
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Athan
Sent: Tuesday, December 31, 2002 3:50 PM
To: [email protected]
Subject: Re: HELP: Conntrack table filling up !!!Quoted 3 lines · Ranjeet Shetye
There are ways in which pings (ICMP packets) can fill up conntrack tables quickly. Are you running into problems with ICMP
traffic only
Quoted 2 lines
or with any traffic ? e.g. look at
/proc/net/ip_conntrack. Is it filled up with ICMP traffic connections only ? If so, youmight want
Quoted 1 line
to protect your linux box from malformed ICMP packets, by
DROPping all
Quoted 1 line
such packets in the "filter" table.
Don't arbitrarily drop all ICMP, bad idea, breaks a few things.
Couldn't the 'full ip conntrack table' problem be solved by
echo'ing a bigger number into/proc/sys/net/ipv4/ip_conntrack_max?root@jimblewix:/proc/sys/net/ipv4; 23:48:19 0$ echo 32768 > ip_conntrack_maxcertainly changes it here.
-Ath
Signature · 5 lines
- Athanasius = Athanasius(at)miggy.org / http://www.miggy.org/ Finger athan(at)fysh.org for PGP key "And it's me who is my enemy. Me who beats me up. Me who makes the monsters. Me who strips my confidence." Paula Cole - ME
Quoted 6 lines · Ranjeet Shetye
Actually, the ICMP problem that I have seen does not go away with a larger
ip_conntrack_max. The extra table space just gets filled up. Agreed, that the ICMP packets I used to flood the iptables conntrack mechanism did not strictly comply with ICMP RFC standards, but then which cracker cares about standards ? :( That's why I asked, are you seeing malformed ICMP packets ?
Fair enough. Check out if the unclean match module catches these bad
ICMP packets then:
iptables -A INPUT -i ${PUBINT} --match unclean -j LOG --log-level info --log-prefix "fwr-unclean "-Ath
Signature · 4 lines
- Athanasius = Athanasius(at)miggy.org / http://www.miggy.org/
Finger athan(at)fysh.org for PGP key
"And it's me who is my enemy. Me who beats me up.
Me who makes the monsters. Me who strips my confidence." Paula Cole - ME