Témakörök









































Router teszt 2020 - MikroTik CCR1072-1G-8S+

0 0
2020.04.09. 10:30

2020-as router tesztsorozatunk aktuális epizódjában bemutatjuk nektek a CCR széria jelenlegi legerősebb modelljét, ami nem más, mint a 8db SFP+ interfésszel és 72 CPU maggal felszerelt CCR1072-1G-8S+. A 1072-es routert elsősorban nagyvállalati környezetbe, valamint szolgáltatói hálózatokba azon belül is kimagaslóan nagy terhelésű csomópontokba ajánljuk. Lássuk, hogy a CCR1072-es milyen eredményeket produkált korábbi ismertető videónkban bemutatott tesztjeinken.

 

Az 1U magasságú CCR1072-es hasonlóan kisebb testvéreihez redundáns tápmegoldással érkezik hozzánk azonban itt már a felhasználók nagy örömére a Hot swap-os megoldás is rendelkezésünkre áll. A számítási munkák mihamarabbi elvégzéséről egy 72 magos Tilera CPU gondoskodik. Interfészek tekintetében 8 db 10 Gbps-os SFP+ foglalattal és 1 db 1 Gbps-os rezes ETH porttal számolhatunk. Ezen felül találunk egy RJ-45-ös konzolportot, valamint egy SD kártya foglalatot, USB aljzatot és egy Smart Card slot-ot. Az alaplapi nyákon továbbá helyet kapott 2db M.2-es PCIe foglalat melyre akár SSD-t is csatlakoztathatunk. Az elődeivel ellentétben itt a gyári ventilátorok már rendelkeznek teljesítmény szabályzási funkcióval így mindig a processzor által megkívánt fordulatszámon üzemelnek.

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.

A blokkdiagrammról néhány szóban annyit érdemes elmondani, hogy a korábbi CCR routerekhez hasonlóan itt is minden port közvetlenül csatlakozik a CPU-hoz.

Mivel a 1072-es már 8 db 10 Gbps-os SFP+ foglalattal rendelkezik így a bridge méréseket is könnyedén elvégezhettük. Csupán annyit kellett tennünk, hogy a szerverekből érkező kábelvégződéseket csatlakoztattuk 1-1 SFP+ foglalatba.

100 Gbps-os forgalmat a mostani tesztkörnyezetben sajnos nem sikerült reprodukálni a szerverek teljesítménykorlátai miatt így nem tudtuk teljes mértékben leterhelni a 1072-es routert. Az eredmények ezáltal nagyban megegyeznek a 1036-os által mért eredményekkel. A leginkább szembetűnő különbség a CPU terhelés jelentős csökkenése volt.

 

 (képre kattintva teljes méretben megjelenik)

Fontos információ, hogy a CCR1072-es esetében minden porton beérkező hálózati forgalom külön-külön CPU maghoz van társítva így elosztva a beérkező terhelést.

 

Bridge módban aggregált 8 Gbps-os eredményt kaptunk 0,5%-os CPU load valamint 750 KPPS értékekkel kísérve.

Route szabályt felvéve aggregált 13 Gbps-os eredményt kaptunk 0%-os CPU load valamint 1140 KPPS értékekkel kísérve.

NAT accept szabálynál aggregált 10,5 Gbps-t, 9%-os CPU terhelést, illetve 940 KPPS-es csomagterhelést kaptunk.

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

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

NAT Masquerade FT szabálynál aggregált 12,5 Gbps, 3% CPU használat és 1140 KPPS-t kaptunk eredményül.

 

Ahogy arról korábban is beszámoltunk a bridge valamint route mérések közti szembetűnő eltérésnél utánajártunk annak, hogy mi lehet az oka ennek a nagy mértékű teljesítményváltozásnak. Az IP címeket kiosztottuk a routerből a szervereknek majd elindítottuk a méréseket. Ezek után a két szerververt közvetlenül összekötöttük egymással és rájöttünk arra, hogy így is megegyező eredményeket kapunk. Levonva a következtetéseket arra jutottunk, hogy nagy valószínűséggel a szerverek bizonyos limitációjából adódik az, hogy ha azonos subnetből származik mindkét oldal akkor a mért adat 8 Gbps körül alakul míg, ha külön subnetből valamilyen route vagy tűzfal megoldás van a kettő között akkor 13 Gbps-os érték között mozognak a maximumok.

Tűzfalnál 10-25-50-75-100-150 szabályt felvéve hajtottuk meg az CCR1072-őt 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ó.

Következnek a VPN mérések.

 


(képre kattintva teljes méretben megjelenik)

 

L2TP VPN esetén 6 Gbps- os adatátvitelre volt képes a CCR1072 (CPU 1%, 680 KPPS) viszont abban a pillanatban, hogy már IPSec titkosítást használunk a mért érték visszazuhant 660 Mbps-re (CPU 4%, 100 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 a mért értékek rögtön jobb eredményeket mutatnak. 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 92 (CPU 1%, 12 KPPS) valamint 90 (CPU 1%, 11 KPPS) Mbps-ot tudtunk elérni. Egy normál IPSec tunnel esetén ez az eredmény 550 Mpbs (CPU 5%, 65 KPPS) növekedett amennyiben kihasználtuk a hardveres gyorsítást. Ennek bekapcsolása nélkül az eredmény kb felére 240 Mbps-re csökkent (CPU 1%, 34 KKPS).

A fenti eredmények után szerettük volna jobban megpörgetni a routert ezért egy multipontos VPN környezetet szimuláltunk. A központi szerepet a CCR1072-es töltötte be míg a VPN csatornákat 6-6 db hEX S valamint 4011 látta el.

 


(képre kattintva teljes méretben megjelenik)

 

Ezáltal az alábbi eredmények születtek a multipontos VPN mérésekkor:

 

4011-esek esetén:

 

IPSec HW: 2,6 Gbps (CPU 23%, 301 KKPS)

L2TP/IPSec: 2,2 Gbps (CPU 28%, 258 KKPS)

SSTP: 85 Mbps (CPU 2%, 11 KKPS)

 

hEX S esetén:

 

IPSec HW: 1,6 Gbps (CPU 6%, 198 KKPS)

L2TP/IPSec: 1,7 Gbps (CPU 15%, 215 KKPS)

SSTP: 107 Mbps (CPU 2%, 14 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 jelentkezünk Router tesztünk összefoglaló videójával.

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.