A burkolat alatt 10 db Gbit-es LAN portot valamint egy 10 Gbps SFP+ foglalatot találunk. A rendszergazdák nagy örömére itt már 1 db RJ-45-ös serial port is rendelkezésre áll. Fontos kiegészítés az SFP+ foglalathoz, hogy nem csak 10 Gbps-os modult tudunk belehelyezni, hanem 1Gbps-t is viszont DAC kábel alkalmazásakor ügyelnünk kell arra, hogy csak aktív kábelekkel képes együttműködni az RB4011.
Megtáplálását tekintve választhatunk a klasszikus DC tápmegoldás, valamint passzív PoE közül. A 10-es ETH-en keresztül pedig PoE out funkcióra is képes az RB4011 57V-ig. Processzora megegyezik az RB 1100-es ben is dobogó 1.4 GHz-es 4 magos 32 bites ARM chipsettel. A nyákon látszik egy miniPCI foglalat jövendőbeli helye is, amely foglalat akár egy v2-es verzióba már beépítésre kerülhet. A kompakt termékmegjelenés és a passzív hűtés miatt az eszköz hajlamos a melegedésre (tesztek során 38-41 C fokos hőmérsékletet mutatott) ezért amennyiben rackszekrénybe helyezzük feltétlen gondoskodjunk a hűtéséről.
Mivel az eszköz 1 db 10Gbps-os interfésszel rendelkezik ezért kénytelenek voltunk egy switchet is közbeiktatni. A konfiguráció így az alábbiak szerint állt össze: A két szerver felől érkező adat bement a switch két portjába ahol természetesen két különböző VLAN taggel lettek ellátva. Ezután egy trönkportnak konfigurált foglalatot a switchből átkötöttük a 4011-es 10Gbps-os portjába ahol szintén beállítottuk a két VLAN-t és így szimuláltuk azt mintha két fizikai interfészen érkezne be az adat.
(képre kattintva teljes méretben megjelenik)
Ennek okán a Bridge mérésekre vonatkozó tesztjeinket nem tudtuk elvégezni mivel, ha a routerben a két VLAN-t összebridgelésre került volna akkor közbeiktatott switch ennek értelmezésére nem lett volna képes ezért a gyártói oldalon feltüntetett mérésekre voltunk kénytelenek hagyatkozni.
A MikroTik tesztjein UDP méréseket végeznek meghatározott csomagméretekkel, amelyek alapján 9,7 Gbps, illetve 2,8 Gbps-os eredmény érhető el függően a csomagmérettől.
Következzen az RB4011-es blokkdiagramja.
(képre kattintva teljes méretben megjelenik)
Ahogy a képen is látható 2 switch chip található a nyákon, amelyre egyenként 5-5db Gbit-es ETH port csatlakozik. Switch chipenként 2,5 Gbps-os BUSZ sebesség biztosított a CPU felé. Az SFP+ portnál semmilyen limitációval nem kell számolni a CPU irányába egy 10Gbps-os BUSZ továbbítja az adatot.
Folytassuk a mérési eredményekkel:
(képre kattintva teljes méretben megjelenik)
Route szabályt felvéve aggregált 8,5Gbps-os eredményt kaptunk 45%-os CPU load valamint 794 KPPS értékekkel kísérve.
NAT accept szabálynál aggregált 5,4 Gbps-t, 89%-os CPU terhelést, illetve 536 KPPS-es csomagterhelést kaptunk.
NAT accept FT szabálynál: aggregált 8 Gbps-t, 68%-os CPU load-ot mértünk 753 KPPS mellett.
NAT Masquerade szabálynál aggregált 4,6 Gbps, 84%-os CPU terhelés mutatkozott 462 KPPS-el.
NAT Masquerade FT szabálynál aggregált 8,4 Gbps, 69% CPU használat és 790 KPPS-t kaptunk eredményül.
Tűzfalnál 10-25-50-75-100-150 szabályt felvéve hajtottuk meg az RB4011-et FastTrack használatával, valamint anélkül:
(képre kattintva teljes méretben megjelenik)
A FastTrack működési elve az, hogy a router nem vizsgál meg minden egyes rajta átmenő csomagot, hanem egy adott flow-ba tartozó csomagoknál „megtanulja”, hogy az előzőekkel milyen műveletet végzett. Ezt pedig később alkalmazza a további csomagokra. Ennek köszönhetően nem használ CPU forrást a csomag továbbítására, illetve vizsgálatára helyette teljes egészében a hardverre hagyatkozik.
Fontos infó a FastTrackkel kapcsolatban, hogy RouterOS-en belül egyelőre csak IPV4-re működik TCP valamin UDP protokollok esetén. Ennek eredményeként egyelőre IPV6 esetén ez a funkció nem használható.
Zárszóként pedig következnek a VPN mérések.
(képre kattintva teljes méretben megjelenik)
L2TP VPN esetén 1915 Mbps- os adatátvitelre volt képes a 4011 (CPU 20%, 210 KPPS) viszont abban a pillanatban, hogy már IPSec titkosítást használunk a mért érték visszazuhant 600 Mbps-re (CPU 39%, 78 KPPS).
A tapasztalt nagy mértékű sebességcsökkenés egy kis kutatásra sarkalt minket és kiderítettük, hogy ha a gyárilag beállított 1450-es MTU értéket 1420-ra csökkentjük vissza akkor megnő ez a sebesség 1 Gbps-ra. Ennek az elméleti magyarázata az, hogy az IPSec titkosítás egy extra adathalmazt helyez el az adott csomag elé, amelytől ennek mérete megnő viszont a router interfész maximális csomagáteresztő mérete nem nő meg. Emiatt a router arra kényszerül, hogy ezeket a „túlméretes” csomagokat feldarabolja és több darabba küldje el. Ebből következik, hogy a küldendő csomagok száma ahogy nálunk is történt megduplázódik és így ez extra terhet ró az eszközre, amelynek eredménye a sebességcsökkenés. Ezt elkerülendő érdemes a csomagméretet úgy módosítani, hogy az összes overhead-el együtt egy csomagba beférjen.
(képre kattintva teljes méretben megjelenik)
Az SSTP és az OpenVPN esetén 90 (CPU 28%, 12 KPPS) és 114 Mbps-ot (CPU 22%, 15 KPPS) tudtunk elérni. Egy normál IPSec tunnel esetén ez az eredmény 810 Mpbs (CPU 65%, 124 KPPS) növekedett.
Köszönjük, hogy velünk tartottatok. Jövő héten újabb résztvevővel folytatjuk tesztünket.