/proc/net/ip_conntrack trange behavior

Krzysztof Oledzki ole at ans.pl
Fri Aug 31 17:09:45 CEST 2007



On Fri, 31 Aug 2007, Dong_Wei wrote:

> Hi Patrick
>
>> On Thu, 30 Aug 2007, Dong_Wei wrote:
>> 
>>>>> And we can't avoid this issue on 2.4, because no code deal with the 
>>>>> special case.
>>>> 
>>>> 
>>>> Thats correct. Is there a problem with this behaviour?
>>> 
>>> As we know, ip_conntrack has a hash_size to control the ip_conntrack 
>>> record size. and if tcp in ESTABLISH, and ip_conntrack will keep it for 5 
>>> DAYs.
>>> 
>>> For exsample, a NAT server can handle 8000 connections, and if sometime, 
>>> NAT server need reboot(6000 conntrack in ESTBLISHED state now). Also we 
>>> set ip_conntrack allowing pickup ESTABLISHED tcp connection, when NAT 
>>> server available again, ip_conntrack will take 6000 conntracks for the 
>>> original connections. but actully these connections are INVALID for the 
>>> web server, because the source ip is the private IPs,such as 192.168.0.1. 
>>> and web server will not answer the client's request. But still the NAT 
>>> server will keep the 6000 conntrack for 5 DAYs. And just 2000 conntracks 
>>> can be used for the clients. If more than 2000 client want connect to some 
>>> websites, some ip_conntrack will be droped.
>> 
>> 
>> You can drop ACK packets in state NEW to avoid connection pickup.
> That's a good idea, I will make a patch for my own 2.4 Linux NAT server, 
> thanks a lot :-)

No need to, as all you should do is a proper iptables rule.

Best regards,

 				Krzysztof Olędzki


More information about the netfilter-devel mailing list