/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