(sorry, in Czech only)
Overit v zakladnich rysech silu soekrisu v sitove narocnych operacich. Jde o to vedet, kolik preroutuje kdyz je firewall permit any, kdyz traffic povoluje cca 10. pravidlem a kdyz cca 100. pravidlem. Overit jak se na snizeni pruchodnosti podili NAT. Overit totez pro polling(4).
Nebudu pocitat hodnoty typu overhead na jedno pravidlo pro paket velikosti 1000 bajtu, nebylo by to zas tak jednoduche aby to bylo rigorozni (bylo by nutne uvazovat ACKy, window size atd.). Predpokladam, ze konecne vysledky ve formet XX Mbit/s budou dostatecne.
Odkazuju na sekci zaver pro rychle vystupni informace o testu.
Je nutne si uvedomit, ze vysledne hodnoty uvadeji jednosmerny
traffic generovany programem ttcp. Pokud je ocekavan obousmerny
traffic zhruba ve stejnych hodnotach RX/TX, je nutne cisla delit dvemi !!!
sender/receiver overhead muzeme zanedbat, jsou to mnohonasobne silnejsi
stroje nez soekris. Mezi nimi uz neni zadny dalsi aktivni prvek.
Soekris 4521 (133MHz/64M RAM) zvladne uroutovat traffic na hranici 25
Mbit/s pri maximalni velikosti paketu a v klasickem interuptovem modu. V te
chvili jiz system zacina byt ze 100% vytizen zpracovanim preruseni a
prestava pracovat na urovni userlandu.
Pri zapnutem polling(4) se propustnost zvysi na 30 Mbit/s a hlavne
drasticky snizi zatizeni procesoru, takze s boxem je mozne bez problemu
pracovat.
V pripade pouziti NATu je maximalni propoustnost cca 7.5 Mbit/s, ale
realna propustnost je za predpokladu nasazeni firewallu pro 32 klientu a
realneho rozlozeni trafficu uz jen cca 3 Mbit/s (v sitich neblokujich
peer-to-peer site je pak nutne pocitat pouze s 1.5Mbit/s IN a 1.5Mbit/s OUT,
jelikoz tyto hodnoty se scitaji, viz poznamka v uvodu tohoto dokumentu). Pro
vice klientu je snizeni propustnosti zanedbatelne (hlavni overhead je NAT a
uvazujeme stromovou strukturu firewallu, kde zdvojnasobeni poctu klientu
zvysi pocet zpracovanych pravidel pouze o jedno).
Prestoze se muze zdat malo, je myslim NAT s 3 Mbit/s v prostredi
koncovych uzivalu (64-256Kbit/s linky) dostatecne reseni. Rozumna agregace
1:4 dava 48 klientu s 256Kb/s lajnami na jeden soekris router. Pri NAT
reseni samozrejme polling(4) nema zadny vyznam.
Pri predpokladu napr. 5.8-ove technologie poskytujici 0.5 Mbit/s a vyse
se da na druhou stranu predpokladat, ze pouziti NATu bude zakazniky
odmitnuto, takze je mozne pocitat s propustnosti cca 30 Mbit/s i kdyz
uvazujeme firewall pro cca 30 zakazniku. 30 Mbit/s s agregaci 1:4, dava to
pouze ctvrtinu z mozneho sitoveho zatizeni, takze ani zde nevidim zadny
problem.
Je mozne pouzivat obe reseni najednou (NAT i verejne adresy) s tim, ze
traffic na verejnych adresach pres NAT proces neprochazi a k nezadoucimu
zpomaleni tedy nedochazi. Bylo by nutne jen udelat pro konkretni situace
testy pro vyladeni pollingu.
Pokud by presto byl potreba stroj se silnejsim procesorem nez 4501
(stejny jako 4521, ale nema PCMCIA sloty) za 150 dolaru, neni problem pouzit
napriklad soekris 4801 s procesorem GEODE 266MHz v cene cca 240 dolaru.
Pokud je stroj pouzivan jako VPN server, je situace jiz vyrazne horsi.
Traffic routovany pres jediny vytvoreny PPTP tunel ukonceny na soekrisu
dosahl pouze 2.9 Mbit/s, resp. 1.7 Mbit/s s NATem.
Hardware and Software
root@s1.osad.prg:~# uname -a
FreeBSD s1.osad.prg.mynet.cz 4.10-RELEASE-p2 FreeBSD 4.10-RELEASE-p2 #0: Tue Jul 13 11:05:02 CEST 2004
root@axxem.hide.idc.cz:/share/wibsd/generic_ap_4_10.mynet/share/wibsd/generic_ap_4_10.mynet/RELENG_4_10/src/sys/generic_ap_4_10.mynet i386
FreeBSD 4.10-RELEASE-p2 #0: Tue Jul 13 11:05:02 CEST 2004
root@axxem.hide.idc.cz:/share/wibsd/generic_ap_4_10.mynet/share/wibsd/generic_ap_4_10.mynet/RELENG_4_10/src/sys/generic_ap_4_10.mynet
Timecounter "i8254" frequency 1189159 Hz
CPU: AMD Am5x86 Write-Back (486-class CPU)
Origin = "AuthenticAMD" Id = 0x4f4 Stepping = 4
Features=0x1
Scenario
sender <---> soekris <---> receiver
Tests
TEST(1): ttcp, rule 1 akceptuje
-------------------------------
Problemy: soekris byl celou dobu nepristupny, pouze routoval,
odpovidal, ale napr. ssh session byla zamrzla -> vice viz TEST(9)
&& polling(4)
ttcp-t: 134217728 bytes in 42.88 real seconds = 3056.63 KB/sec +++
ttcp-t: 134217728 bytes in 43.59 real seconds = 3006.89 KB/sec +++
ttcp-t: 134217728 bytes in 42.75 real seconds = 3066.12 KB/sec +++
Vysledek: cca 24.5 Mbit/s
TEST(2): ttcp, akceptuje rule 16
--------------------------------
Problemy: jako TEST(1)
ttcp-t: 131072000 bytes in 46.61 real seconds = 2746.11 KB/sec +++
ttcp-t: 131072000 bytes in 46.93 real seconds = 2727.21 KB/sec +++
ttcp-t: 131072000 bytes in 46.34 real seconds = 2762.06 KB/sec +++
Vysledek: cca 21.8 Mbit/s
TEST(3): ttcp, akceptuje rule 100
---------------------------------
Poznamka: prvnich 99 ruli je typu deny from 3.3.3.3 to 4.4.4.4
Problemy: jako TEST(1)
ttcp-t: 134217728 bytes in 77.25 real seconds = 1696.77 KB/sec +++
ttcp-t: 134217728 bytes in 77.24 real seconds = 1696.84 KB/sec +++
ttcp-t: 134217728 bytes in 77.36 real seconds = 1694.37 KB/sec +++
Vysledek: cca 13.5 Mbit/s
TEST(4): ttcp, akceptuje 2. pravidlo, 1. pravidlo je NAT
--------------------------------------------------------
ttcp-t: 81920000 bytes in 83.40 real seconds = 959.18 KB/sec +++
ttcp-t: 81920000 bytes in 83.61 real seconds = 956.79 KB/sec +++
ttcp-t: 81920000 bytes in 83.95 real seconds = 952.98 KB/sec +++
Vysledek: cca 7.6 Mbit/s
TEST(5): jako TEST(4) s tim rozdilem, ze ta pravidla jsou 15. a 16.
-------------------------------------------------------------------
Poznamka 1: obdobna jako u TEST(3)
Poznamka 2: 16. pravidlo by melo byt maximalni cislo pro novy fw,
ktery ma 9-10 ruli a pak sekci pajp. 32 lajn postavenych do stromu
vysky 5 tak dava jako horni odhad poctu zpracovanych pravidel na
paket cislo 15.
ttcp-t: 81920000 bytes in 85.81 real seconds = 932.27 KB/sec +++
ttcp-t: 81920000 bytes in 86.00 real seconds = 930.21 KB/sec +++
ttcp-t: 81920000 bytes in 87.28 real seconds = 916.58 KB/sec +++
Vysledek: cca 7.5 Mbit/s
TEST(6): jako TEST(5), jen ma 99 ,,hluchy'' pravidel na zacatku
---------------------------------------------------------------
Poznamka: tento test slouzi jako ukazka, ze v pripade pouziti NATu
uz neni pocet pravidel pred divertem pro celkovou propustnost jiz
tak dulezity
ttcp-t: 81920000 bytes in 106.57 real seconds = 750.71 KB/sec +++
ttcp-t: 81920000 bytes in 106.51 real seconds = 751.09 KB/sec +++
ttcp-t: 81920000 bytes in 106.47 real seconds = 751.42 KB/sec +++
Vysledek: cca 6 Mbit/s
TEST(X): ttcp, akceptuje 16. pravidlo, coz (viz dale) by mel byt
nejhorsi pripad pro novy firewall a 32 zakaznickych pajp
TEST(7): jako TEST(6), ale pakety maji max. 500 bajtu
------------------------------------------------------
Poznamka: velikosti paketu bylo dosazeno snizenim MTU na 500 na
strane sendera
ttcp-t: 33554432 bytes in 98.90 real seconds = 331.33 KB/sec +++
ttcp-t: 33554432 bytes in 98.36 real seconds = 333.14 KB/sec +++
ttcp-t: 33554432 bytes in 99.10 real seconds = 330.66 KB/sec +++
Vysledek: cca 2.7 Mbit/s
TEST(8): jako TEST(7), ale bez NATu
-----------------------------------
Poznamka: opet je videt, ze NAT je zakladni vec, ktera ovlivnuje
propustnost
ttcp-t: 33554432 bytes in 32.83 real seconds = 998.05 KB/sec +++
ttcp-t: 33554432 bytes in 32.85 real seconds = 997.42 KB/sec +++
Vysledek: cca 8 Mbit/s
TEST(9): zapnuty polling(4)
---------------------------
Poznamka 1: ostatni nastaveni pollingu byly na defaultnich hodnotach
(max_burst etc.)
Poznamka 2: pri zapnutem pollingu se drasticky snizuje zatizeni
procesoru a na systemu je normalne mozne pracovat (co je hlavni
duvod, proc byl polling implementovan)
Poznamka 3: HZ byl nastaven na 500, prestoze doporucovana hodnota
je 1000-2000. Toto nastaveni ale neni vhodne pro slabe stroje.
ttcp-t: 131072000 bytes in 35.43 real seconds = 3612.78 KB/sec +++
ttcp-t: 131072000 bytes in 36.20 real seconds = 3535.75 KB/sec +++
ttcp-t: 131072000 bytes in 35.51 real seconds = 3604.73 KB/sec +++
Vysledek: cca 29 Mbit/s
TEST(10): traffic jde pres vpn via PPTP, akceptuje 1. pravidlo,
zadny NAT
----------------------------------------------------------------
Poznamka: od sebe (sender) jsem propojen na soekris, nastaveny
routy tak, abych na receivera sel pres VPN na soekris a dale uz
normalne na receivera pres lokalni fastethernet segment.
ttcp-t: 16777216 bytes in 45.45 real seconds = 360.50 KB/sec +++
ttcp-t: 16777216 bytes in 45.32 real seconds = 361.49 KB/sec +++
ttcp-t: 16777216 bytes in 45.46 real seconds = 360.40 KB/sec +++
Vysledek: cca 2.9Mbit
TEST(11): jako TEST(10), ale se zapnutym NATem (1. rule)
--------------------------------------------------------
ttcp-t: 16777216 bytes in 75.21 real seconds = 217.84 KB/sec +++
ttcp-t: 16777216 bytes in 76.04 real seconds = 215.47 KB/sec +++
ttcp-t: 16777216 bytes in 75.74 real seconds = 216.31 KB/sec +++
Vysledek: cca 1.7 Mbit/s
TEST(12): pptp tunel je mezi soekrisem and receiverem
--------------------------------------------------------
Poznamka: ze sendera posilam data na receivera
ttcp-t: 16777216 bytes in 60.09 real seconds = 272.67 KB/sec +++
ttcp-t: 16777216 bytes in 59.86 real seconds = 273.71 KB/sec +++
ttcp-t: 16777216 bytes in 59.91 real seconds = 273.46 KB/sec +++
Vysledek: cca 2.2 Mbit/s
Conclusion
home | contact | legal | ©
2003-2005 The WiBSD Project. All rights reserved.