Az 1U magasságú CCR1009-es redundáns tápmegoldásának köszönhetően már nagyobb biztonságban érezhetjük magunkat 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. Maga az eszköz 8 db Gbit-es ETH csatlakozással rendelkezik, amelyhez további 1 db 10Gbps-os SFP+ foglalat társul. Fontos tudni, hogy a 8. ETH kombó portként üzemel így lehetőségünk van választani rezes RJ-45-ös LAN és egy SFP használata közül. Kiegészítő információként megemlítendő, hogy ez a modell alkalmas egyedül 100BASE-T SFP interfészek fogadására. A CCR1009-7G-1C-1S+ aktív hűtésű, két ventilátor gondoskodik arról, hogy rackszekrénybe szerelve is optimális hűtéshez jusson.
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.
Következzen az CCR1009-es blokkdiagramja.
(képre kattintva teljes méretben megjelenik)
Ahogy a képen is látható a CCR1009-es esetében minden egyes interfész közvetlen BUSZ kapcsolattal rendelkezik a CPU felé. Egyedül kivételt képez ez alól a korábban már említett kombó port hisz ennél mindig az aktuálisan kiválasztott típus kerül engedélyezésre automatikusan.
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 CCR1009-es 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 15,8 Gbps, illetve 9,1 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 4%-os CPU load valamint 804 KPPS értékekkel kísérve.
- NAT accept szabálynál aggregált 7,7 Gbps-t, 69%-os CPU terhelést, illetve 752 KPPS-es csomagterhelést kaptunk.
- NAT accept FT szabálynál: aggregált 8,5 Gbps-t, 24%-os CPU load-ot mértünk 799 KPPS mellett.
- NAT Masquerade szabálynál aggregált 8 Gbps, 77%-os CPU terhelés mutatkozott 824 KPPS-el.
- NAT Masquerade FT szabálynál aggregált 8,7 Gbps, 26% CPU használat és 816 KPPS-t kaptunk eredményül.
Tűzfalnál 10-25-50-75-100-150 szabályt felvéve hajtottuk meg az CCR1009-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 Gbps- os adatátvitelre volt képes a CCR1009 (CPU 15%, 590 KPPS) viszont abban a pillanatban, hogy már IPSec titkosítást használunk a mért érték visszazuhant 640 Mbps-re (CPU 11%, 77 KPPS).
A tapasztalt sebességcsökkenés egy kis kutatásra sarkalt minket é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 75 (CPU 12%, 10 KPPS) és 90 Mbps-ot (CPU 10%, 11 KPPS) tudtunk elérni. Egy normál IPSec tunnel esetén ez az eredmény 600 Mpbs (CPU 20%, 75 KPPS) növekedett amennyiben kihasználtuk a hardveres gyorsítást. Ennek bekapcsolása nélkül az eredmény a harmadára 195 Mbps-re csökkent (CPU 11%, 26 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.
További kiegészítés, hogy többmagos processzorok esetén a CPU terhelés számértéke félrevezető lehet mivel ez az összes mag értékéből vett átlagot adja vissza eredményül. Egy példán levezetve jól látható, hogy amikor a szoftveresen átvihető maximális IPSec forgalmat mértük 11%-ot kaptunk vissza. Azonban ez azt jelenti, hogy a jelen esetben a CPU-ban lévő 9 mag közül 1-et használtunk teljes terheltségen míg a többi „üresjáraton” ketyegett. Ezért fontos, hogy minden esetben megnézzük minden egyes CPU mag terhelését külön-külön, hogy ezzel elkerüljük a potenciális bottleneck szituációkat.
Köszönjük, hogy velünk tartottatok. Jövő héten újabb résztvevővel folytatjuk tesztünket.