Re: lug-bg: ip_conntrack dropping packet

[George Danchev <danchev@xxxxxxxxx>]

On Saturday 11 June 2005 17:24, Nikola Antonov wrote:
> Здравейте,
>
> Предполагам почти всеки от вас се е сблъсквал с съобщението в системните
> логове, което е и заглавие на темата, особено когато става дума за
> по-натоварени рутери. Известно е, че този проблем се решава с увеличаване
> на стойността в /proc/sys/net/ipv4/ip_conntrack_max, която по пдразбиране
> наистина е доста ниска за машини, през които минава повечко трафик (над 100
> мегабита)
>
> Въпросът ми е по-скоро до каква степен е разумно тази стойност да се
> увеличава и изобщо по какъв начин се определя тя от ядрото. Разгледах и
> сорса на самия модул, но тъй като не съм програмист, предпочитам да науча
> мнението на тези, които имат по-задълбочени познания.

	Според мен на dedicated firewall/nat-only machines ти можеш да увеличаваш 
това ограничение до безкрай, и неща ще се случат 2 неща:
* ако има памет ще алокира контрак в талицата, това е ясно, но ако някой те 
abuse-ва ( p2p приятелите и други подобни с амнайсе TCP сесии от client ip 
address / block и нямаш connlimit за тях) то ще стигнеш до:  
* да не може да алокира поради липса на свободна памет. ще дропне пакети със 
съответното съобщение в лога (и от кода printk-ва нещо си и return-ва ENOMEM 
(out of memory) или ENOSPC (no space left on device, иде реч за мрежовия 
дивайс)). Т.е. 'до края и душата в рая', ограничен си от хардуера.

	Когато има и други работи на тази машина, може да изцензурираш малко 
abuse-ването на паметта ;-) Смисъла на ограничението за conntrack_max и 
hashsize е: да можеш да кажеш 'не повече от mem - X' памет ще се алокира от 
нетфилтър контракинг [1] /при извръщения, се дропват пакети/, а X памет 
остава за други най-различни неща (като например squid който хапва по еди 
колко си К (4 на х86) на отворен сокет, а работа му е да отваря такива и да 
пълни паметта ;-).

[1] http://www.wallfire.org/misc/netfilter_conntrack_perf.txt
/ ако искаш да налагаш ограничения /

-- 
pub 4096R/0E4BD0AB 2003-03-18 <danchev.fccf.net/key pgp.mit.edu>
fingerprint    1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB