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.