Re[2]: Interesting problems

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Tuesday, August 5, 2003, 12:38:13 PM, Chris Wilson wrote:

CW> Hi Peteris,

>>   - there is a computer PII 266, now with 192mb ram, it's running
[...]
>>     `wc -l /proc/net/ip_conntrack' shows around 20000 entries.
>>     A reboot helps.

CW> This does not surprise me at all. You have a very old computer handling an 
CW> enormous amount of traffic and you complain that it's slow? =)

266 isnt that slow, that's only connection tracking, is it (too slow)?

CW> For reference, we have a 350MHz Cyrix machine handling iptables with
CW> stateful inspection for a medium-loaded 2Mb line with maybe 50 users/boxes
CW> behind it, and it has about 3000 connections right now and a load of 0.04.  
CW> 50% of CPU time is used by the System, indicating netfilter.  Perhaps your
CW> users are very busy?

Simple internet users, some are lazy and just downloading stuff from
different edonkies and emules. Some just use net for google.

Most of the entries taking up conntrack table are:
tcp 6 419547 ESTABLISHED src=X dst=Y sport=A dport=B [UNREPLIED] src=Y
dst=X sport=B dport=A use=1 mark=0

They would expire only after 419547 secs that is 4 days, but during those 4
days the table grows 5 times that much entries..

Is there some trick to kill UNREPLIED tcp conntrack entires if there
is no reply after NN seconds.
Also could it be done in software w/o much trouble? Monitoring
conntrack table and removing dead entries like these.
If it's not much trouble i can instruct our programmers instantly to
work on such tool.

CW> When `wc -l /proc/net/ip_conntrack' shows around 20000 entries, and you 
CW> have set the max to 20000, then no more connections can be added and the 
CW> kernel prints the warning you saw.

Yes, i know.

>>     The question is what could i do to avoid the growthy of connection
>>     tracking entries? I guess the entries taking up space are already
>>     established tcp connections which were not properly terminated, so
>>     they are there to timeout.

CW> Terminate some of your users, or tell them not to use the Internet so 
CW> much!

:)

CW> But a better solution would be to get a real powerful box or not use
CW> stateful inspection (or maybe run nf-hipac or BSD's ipf instead of 
CW> iptables, as apparently both are faster).

Stateful inspection is needed to allow only outbound connections. and
inbound only ESTABLISHED,RELATED.

Unfortunately the software using iptables and Linux is being programmed
for half a year. 3 months left to finish the product. Can't change the
platform.

I can instruct our programmers (I am the team leader) to do some work
on iptables connection tracking code and after improvments i could
send it as a patch for current iptables. So connection tracking would
be as efficient as possible. I just need someone to tell me exactly
what is inefficient in conntrack code.


P.Krumins



[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux