Témakörök

MikroTik CCR2004-1G-12S+2XS - Teszt

0 0
2020.08.25. 09:46

Múlt heti videónkban megismerkedhettetek a MikroTik CCR2004-1G-12S+2XS-el és bemutattuk nektek, hogy milyen újításokkal vértezte fel a MikroTik mérnöki csapata ezt az eszközt. A mai epizódban már a teljesítményé lesz a főszerep. Megtudhatjátok, hogy a CCR2004-es miként vette az akadályokat és milyen eredményeket produkált tesztjeinken.

A korábbi gyakorlattól némileg eltérve itt egyetlen egy routert használtunk a teszteléshez. Ez a router nem volt más, mint a CCR széria legerősebb tagja a CCR1072-es. A CCR1072-es modellben megtalálható traffic generator funkció volt segítségünkre a mérések során. Ennek a tool-nak a közreműködésével képesek voltunk nagy pontossággal és jó paraméterezhetőséggel sok-sok csomagot generáljon majd ellenőrizze azt, hogy ezek a keretek milyen hatékonysággal érkeztek meg. Topológia szempontjából több okból is akadályokba ütköztünk. Elsőként a portok számával hisz míg a CCR2004-ben 10db SFP+ és 2db SFP28 (amely szintén használható SFP+-ként is) addig a CCR1072-es „csupán” 8db SPF+ foglalattal rendelkezik. A 25 Gigás SFP28-as interfészeket pedig annál az egyszerű oknál fogva nem tudtuk lemérni, hogy jelenleg a MikroTik kínálatában kizárólag a CCR2004-es rendelkezik e portokkal. Ezektől eltekintve elárulhatjuk, hogy így is képesek voltunk megizzasztani a CCR2004-est.

Ahogy azt már korábbi teszteink során megszokhattátok most is mérésre került Bridge, valamint Route-olt forgalom átviteli sebesség. Természetesen nem csak a maximálisan átvihető sávszélességre hanem a csomagszámokra is kiterjed a mérés.

Megállapítottuk, hogy a kapott eredmények nagyrészt a gyári adatlapon feltüntetett értékeket hozták.

Bridge és Route környezetben 40Gbit/s-os értékeket kaptunk. IPv6 esetén ez a teljesítmény szignifikánsan lecsökkent megközelítőleg a felére 19Gbit/s-ra úgy, hogy a 1072-es összes portján folyamatosan küldtük az IPv6 forgalmat a CCR2004-es irányába.

Ennek a teljesítménycsökkenésnek az egyik oka, hogy a router jóval több erőforrást használ fel az IPv6-os csomagok feldolgozására. Ha belegondolunk ez egyáltalán nem váratlan eredmény hisz az IPv6-os protokoll esetén az IP header mérete duplája (40 bájt) az IPv4 (20 bájtos) méretéhez képest. A másik ok az lehet, hogy míg az IPv4-eseténben a router operációs rendszerében már számos optimalizálás került elvégzésre (Fast Path, FastTrack) addig ezek még IPv6 esetében nem elérhetőek.

A PPS méréseket is végeztünk. Itt két módszerrel gyűjtöttük be az adatokat. Először az általunk tesztelt portoknak az összes átvihető csomagszámát 1 sec alatt, illetve ugyanezt csak kizárólag egy portra korlátozva.

Ahogy azt az eredményekből láthatjátok tunneleket is mértünk a tesztek alatt. A tunnel építés topológiája némileg eltért a fent bemutatott metódustól. A CCR1072-es és a CCR2004 közé beékeltünk egy CCR1036-ost is, amelynek feladata az volt, hogy a tunneleket elindítsa a végződtető CCR2004-es irányába. Meg kell jegyeztünk, hogy a CCR1036-os esetében is hardveres korlátokba ütköztünk hiszen itt csupán két SFP+ porton keresztül tudtuk átküldeni a forgalmat.

1, illetve 2 session-el is mértünk feltételezve azt, hogy 1 session esetén a processzor nem fogja több magra szétosztani a teljesítményt így megláthatjuk azt, hogy ténylegesen milyen korlátokkal számolhatunk számítási kapacitás terén.

Ezt a számok igazolták is mivel egyik esetben 7 Gbit/s-os értéket míg a másik esetben 10 Gbit/s-os értéket kaptunk L2TP-n, amely a mérési módszer maximuma volt

Fontos megjegyeztünk, hogy az L2TP mérés esetén minden optimalizálva volt a maximális eredmény elérésének érdekében. Gondolunk itt arra, hogy az MTU értékeket mindenhol megemeltük, ahol szükséges, hogy fragmentálásra semmiképp ne kerüljön sor, valamint IPsec-et se használtunk, noha a CCR2004-es is rendelkezik hardveres IPsec gyorsítással.

Abban biztosak lehettek, hogy amint megjelennek a MikroTik termékkínálatában a további 25 Gbps-os SFP28-as interfésszel felvértezett routerek akkor újra előkerül a CCR2004-es és megnézzük, hogy akkor milyen eredményeket fog produkálni immár hardveres korlátok nélkül.

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.