Az 1U magasságú CCR1036-os hasonlóan kisebb testvéreihez redundáns tápmegoldással érkezik hozzánk. A számítási munkák mihamarabbi elvégzéséről egy 36 magos Tilera CPU gondoskodik. Interfészek tekintetében 2 db 10Gbps-os SFP+ foglalattal, valamint 8 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 és egy USB aljzatot. Az alaplapi nyákon továbbá helyet kapott egy M.2-es PCIe foglalat melyre akár egy SSD-t is csatlakoztathatunk. Megemlítendő, hogy a hűtésnél a gyári ventillátorok nem rendelkeznek teljesítmény szabályozási funkcióval így minden esetben azonos fordulatszámon működnek. Azonban jó hír, hogy ezeket bármikor kicserélhetjük. A tápegységekre visszakanyarodva fontos megemlíteni, hogy könnyedén átalakítható és integrálható -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.
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 1036-os már 2 db 10Gbps-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.
Fontos információ, hogy a CCR1036-os 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.
(képre kattintva teljes méretben megjelenik)
- Bridge módban aggregált 8 Gbps-os eredményt kaptunk 1%-os CPU load valamint 750 KPPS értékekkel kísérve.
- Route szabályt felvéve aggregált 13 Gbps-os eredményt kaptunk 1%-os CPU load valamint 1140 KPPS értékekkel kísérve.
- NAT accept szabálynál aggregált 10,5 Gbps-t, 19%-os CPU terhelést, illetve 900 KPPS-es csomagterhelést kaptunk.
- NAT accept FT szabálynál: aggregált 12,5 Gbps-t, 6,5%-os CPU load-ot mértünk 1140 KPPS mellett.
- NAT Masquerade szabálynál aggregált 10,5 Gbps, 21,5%-os CPU terhelés mutatkozott 940 KPPS-el.
- NAT Masquerade FT szabálynál aggregált 12,5 Gbps, 7% CPU használat és 1160 KPPS-t kaptunk eredményül.
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 CCR1036-ot 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 7 Gbps- os adatátvitelre volt képes a CCR1036 (CPU 1%, 750 KPPS) viszont abban a pillanatban, hogy már IPSec titkosítást használunk a mért érték visszazuhant 850 Mbps-re (CPU 8%, 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 mindkét esetben 90 Mbps-ot tudtunk elérni. A terhelések az alábbiak szerint alakultak SSTP esetén: (CPU 3%, 11 KPPS) illetve OpenVPN esetén: (CPU 2,5%, 12 KPPS). Egy normál IPSec tunnel esetén ez az eredmény 700 Mpbs (CPU 6%, 77 KPPS) növekedett amennyiben kihasználtuk a hardveres gyorsítást. Ennek bekapcsolása nélkül az eredmény a harmadára 300 Mbps-re csökkent (CPU 4%, 38 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 CCR1036-os 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ésekor:
(képre kattintva teljes méretben megjelenik)
4011-esek esetén:
- IPSec HW: 3,2 Gbps (CPU 36%, 365 KKPS)
- L2TP/IPSec: 2,6 Gbps (CPU 44%, 303 KKPS)
- SSTP: 124 Mbps (CPU 3%, 16 KKPS)
hEX S esetén:
- IPSec HW: 1,6 Gbps (CPU 10%, 198 KKPS)
- L2TP/IPSec: 1,7 Gbps (CPU 18%, 217 KKPS)
- SSTP: 144 Mbps (CPU 3%, 19 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 a CCR kategória koronázatlan királyával a CCR1072-es routerrel folytatjuk tesztünket.