FreeBSD router - propustnost

Tomas Podermanski tpoder at cis.vutbr.cz
Sun Oct 12 15:25:47 CEST 2003


Peter Sedivy - PeSe wrote:

>On Wed, 8 Oct 2003, Ivo Hazmuk wrote:
>
>  
>
>>Dobry den,
>>
>>Co prinaselo necekane problemy nebyla fw pravidla (IPFW), ale SNORT. Ten
>>je schopen s ruznou uspesnosti sledovat provoz do 100Mb/s.
>>
>>Cemu by mel clovek venovat pozornost je kernel. IPSec ci IPF vyrazne
>>snizili propustnost systemem o desitky procent.
>>
>>    
>>
>chcete povedat, ze je tak zasadny rozdiel medzi IPF a IPFW?
>Ak ano, su na to argumenty, resp. dokumentacia?
>
>		PeSe
>
>
>  
>
K tomu zaveru jsme dosli praktickym testovanim. Zkouseli jsme vliv 
ruznych parametru na prospustnost routeru/bridge ve FreeBSD. Abychom se 
bavili o konkretnich cislech, tak v pripade pouhe pritomnosti kodu ipf 
(tedy bez jakychkoliv pravidel ve firewallu) byla propustnost routeru s 
procesorem PIII snizena z 301Mbps na 213Mbps, coz je nejakych 30%. 
Dalsich cca 35% bylo zpusobeno zarazenim kodu IPSEC do kernelu (tedy z 
301Mbps na 194Mbps).

Ostatni volby kernelu nemely na vykonnost  routeru prilis  vyrazny vliv 
(jen namatkou  kod IPFW  -7%, MULTICAST ROUTING +1,5%, POOLING +1,5%, 
BRIDGE +1,5%).

Je ovsem treba brat v potaz, ze se jednalo o testy v laboratornim 
prostredi s malou smerovaci tabulkou, bez firewallu, generovanou 
velikosti paketu 1400B atd. Je nutno ovsem opozornit, ze vykon 
smerovace/bridge znacne zavisi rovnez na poctu pravidel firewallu a 
velikosti paketu. Zejmena u velikosti paketu jsou posuny vykonu 
markantni  (1400B -> 301Mbps, 650B -> 300Mbps, 300B -> 293Mbps, 150B -> 
190Mbps, 50B -> 80BMbps, 25B -> 42Mbps). Velikost paketu muze byt 
dokonce pro router osudna, protoze v takovem pripade dojde vlivem 
obsluhy velkeho poctu preruseni k 100% zatizeni CPU a v pripade, ze na 
routeru bezi smerovaci demon dojde k absolutni katastrofe.

Dale jsme zkouseli moznosti PCI-X a vliv poctu procesoru na vykon 
smerovace.  V pripade pouziti PCI-X nebyl problem dosahnout propustnosti 
radove 1Gbps. Zde opet nastava problem zatizeni CPU u kratkych paketu. 
Ovsem diky kvalitnejsim procesorum (v nasem pripade Xeon 2,4GHz) je 
problematicka hranice posunuta mnohem vys. Pouziti vice procesoru na 
roueru nema vyrazny vyznam, protoze kod kernelu je obsluhovan stejne 
jednim CPU. U FreeBSD 5.1 doslo dokonce po zarazeni kodu SMP ke znacne 
degradaci celkoveho vykonu.  FreeBSD 5.2 by na tom snad mohlo byt lip.

Co se tyce platforem tak se nekonaly vyrazne rozdily. Zkouseli jsme 
FreeBSD, Linux, OpenBSD, NetBSD a vykonnost jednotlivych platforem byla 
v teto uloze vice mene stejna.


T. Podermanski



>  
>
>>	Ivosh Hazmuk
>>
>>--
>>FreeBSD mailing list (users-l at freebsd.cz)
>>http://www.freebsd.cz/listserv/listinfo/users-l
>>
>>    
>>
>
>==============================
>    Omnia mea mecum porto
>==============================
>     Peter Sedivy - PeSe
>            ***
>   UNIX/BSD/Linux, Networks
>            ***
>        pese at pese.sk
>==============================
>
>
>  
>





More information about the Users-l mailing list