Router teszt 2020 - MikroTik CCR1016-12S-1S+

1 0
2020.03.26. 10:10

Egy hét elteltével ismételten jelentkezünk 2020-as router tesztsorozatunk legfrissebb epizódjával. A széria legújabb részében bemutatjuk nektek a CCR1016-12S-1S+-t amelyet elsősorban nagyvállalati környezetbe, valamint szolgáltatói hálózatokba azon belül is közepes terhelésű csomópontokba ajánlunk. Lássuk, hogy a CCR1016-os milyen eredményeket produkált korábbi ismertető videónkban bemutatott tesztjeinken.

Az 1U magasságú CCR1016-os is redundáns tápmegoldással érkezik így ennek hála már nagyobb biztonságban tudhatjuk eszközünket tudva azt, hogy ha esetlegesen az elsődleges betáppal történik valami akkor a másik azonnal képes annak átvételére. A számítási feladatok gyors elvégzéséről egy 16 magos Tilera CPU gondoskodik. Interfészek tekintetében 1 db 10Gbps-os SFP+ foglalattal, valamint 12db 1 Gbps-os SFP csatlakozási lehetőséggel bír. Ezen felül találunk egy RJ-45-ös konzolportot valamint egy SD kártya foglalatot és egy USB aljzatot. A gyári csomagolásban az eszközön felül találunk a rackbe való rögzítéshez szükséges füleket és egy RJ-45-ös 1000Base-T-s SFP copper modult. A tápegységekre visszakanyarodva fontos megemlíteni, hogy könnyedén átalakítható és integrálható DC -48V-os DC -s telko környezetbe.

A router rendelkezik egy érintőképernyős LCD panellal is, amelyen keresztül bizonyos szintig konfigurálható, illetve különböző statisztikák megjelenítésére alkalmas. Fontos megemlíteni, hogy érdemes mindig jelszóval védeni az LCD felhasználói felületét mivel így elkerülhetjük azt, hogy illetéktelenek esetleg bármilyen módosítást végezhessenek eszközünkön.

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 CCR1016-os 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 19 Gbps, illetve 9 Gbps-os eredmény érhető el függően a csomagmérettől.


(képre kattintva teljes méretben megjelenik)

- Route szabályt felvéve aggregált 8,5Gbps-os eredményt kaptunk 1%-os CPU load valamint 785 KPPS értékekkel kísérve.

- NAT accept szabálynál aggregált 7,7 Gbps-t, 40%-os CPU terhelést, illetve 750 KPPS-es csomagterhelést kaptunk.

- NAT accept FT szabálynál: aggregált 8,5 Gbps-t, 15%-os CPU load-ot mértünk 798 KPPS mellett.

- NAT Masquerade szabálynál aggregált 8 Gbps, 50%-os CPU terhelés mutatkozott 803 KPPS-el.

- NAT Masquerade FT szabálynál aggregált 8 Gbps, 15% CPU használat és 792 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 5,2 Gbps- os adatátvitelre volt képes a CCR1016 (CPU 7%, 607 KPPS) viszont abban a pillanatban, hogy már IPSec titkosítást használunk a mért érték visszazuhant 580 Mbps-re (CPU 26%, 72 KPPS).

A tapasztalt sebességcsökkenés egy kis kutatásra sarkalt minket melyet az alábbi videóban visszanézhettek é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.

Az SSTP és az OpenVPN esetén 85 (CPU 7%, 10 KPPS) és 78 Mbps-ot (CPU 6%, 163 KPPS) tudtunk elérni. Egy normál IPSec tunnel esetén ez az eredmény 490 Mpbs (CPU 30%, 58 KPPS) növekedett amennyiben kihasználtuk a hardveres gyorsítást. Ennek bekapcsolása nélkül az eredmény a harmadára 178 Mbps-re csökkent (CPU 7%, 25 KKPS)

Hasznos információ: Amennyiben IPSec-et konfiguráltok mindig látogassatok el a MikroTik oldalára és nézzétek meg az IPSec és a router kompatibilitási mátrixát a hardveres gyorsításhoz.

Köszönjük, hogy velünk tartottatok. Jövő héten újabb résztvevővel a CCR1036-os routerrel 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.