Témakörök









































Router teszt 2020 - MikroTik RB4011iGS+RM

1 0
2020.03.13. 09:27

Folytatódik 2020-as router teszt sorozatunk. A mai epizódban a komolyabb otthoni feladatokra, valamint közepes kliensszámú irodai környezetbe pozícionált nagy népszerűségnek örvendő RB4011iGS+RM-et mutatjuk be nektek részletesen majd ezután alávetjük az ismertető videóban taglalt tesztjeinknek.

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.

Hozzászólás írása

Hozzászólások

Ez a blogbejegyzés csak belépve kommentelhető!

Még nincs egy hozzászólás sem.