By Marek Ploštica
Vrnetlab je open-source emulátor sieťových smerovačov, ktorý môže bežať len za účasti Linuxového jadra. Prvotne bol vytvorený pre použitie v spoločnosti Deutsche Telekom. Pre správnu prevádzku virtuálnych smerovačov používa KVM a Docker. Docker je nástroj určený pre jednoduchšie vytváranie, nasadenie a beh aplikácií, používaním takzvaných kontajnerov v prostredí OS Linux a Windows. Softvéroví vývojári a sieťoví inžinieri používajú Vrnetlab predovšetkým na testovanie zmien vo virtuálnom prostredí a v prípade správnosti tieto zmeny aplikujú do reálneho prostredia.
Vrnetlab vytvára tzv. Docker image pre každý typ smerovača, ktorý sa bude používať. Tento image súbor je spojenie originálneho image súboru spolu s KVM softvérom, pythonovými skriptami a ostatnými zdrojmi požadovanými konkrétnym smerovačom. Z týchto image súborov sa dajú vytvoriť a následne spustiť kontajnery, chápané ako samotné inštancie smerovačov.
Vytvorenie spojenia medzi týmito inštanciami sa realizuje prostredníctvom vr-xcon skriptu. Môže existovať jeden skript pre všetky spojenia v rámci topológie, alebo na druhú stranu, môžu byť vytvorené nezávislé inštancie vr-xcon pre každý spoj. Pri vytváraní spojenia definujeme rozhrania na konkrétnej inštancii smerovača.
Keďže sa nám nepodarilo zohnať jediný podporovaný prepínač (Juniper vQFX) pre tento nástroj, tak sme sa zaobišli bez otestovania protokolov ako napríklad STP.
Jednoduchosť inštalácie
Korektný rozbeh tohto nástroja spočíva v stiahnutí a inštalácii virtualizačného riešenia KVM a jeho balíčkov spolu s Docker enginom. Po úspešnom dokončení týchto úkonov, stačí už len naklonovať Vrnetlab repozitár do nami zvoleného adresára. Priebeh inštalácie bol bezchybný a časovo nenáročný. Kompletná inštalácia všetkých potrebných súčastí zabrala približne 5 minút vrátane sťahovania neodmysliteľných súborov.
Časovo náročnejšia je tu úloha konverzie originálneho image súboru do Docker image súboru. Do vopred definovaného adresára pre konkrétnu platformu treba skopírovať originálny image súbor. V tomto adresári je nutné spustiť príkaz #make, ktorý následne vyvolá samotnú konverziu. V prípade Cisco Cloud smerovača (CSR1000v) táto operácia trvala približne 5 minút, čo je dĺžka času podobná so samotnou inštaláciou celého nástroja. Na druhú stranu konverzia RouterOS trvala niečo málo pod minútu.
Po úspešnej konverzii sa všetky novovytvorené Docker image súbory dajú zobraziť pomocou príkazu #docker image ls. Vo výpise sa nachádzajú dôležité informácie o jednotlivých image súboroch ako napríklad názov, TAG, Image ID a veľkosť.
Z týchto image súborov sa následne vytvárajú a spúšťajú nami definované kontajnery chápané ako inštancie príkazom #docker run -d –name „názov inštancie“ –privileged „názov Docker image“.
Hardvérové požiadavky emulátora na systém
Výrobca stanovuje systémové požiadavky priamo v jeho sekcii na githube, kde sa nachádza aj samotný emulátor. Dôraz sa kladie na nevyhnutnosť potreby Linux jadra s podporou KVM a správne nakonfigurovaného Docker enginu. Docker je síce dostupný aj pre operačný systém OS X s VMM (Virtual Machine Monitor) xhyve typu 2, ale samotný hypervízor neponúka vnútornú virtualizáciu a z toho dôvodu nie je možné spustiť KVM vo VM (Virtual Machine) v xhyve.
Samotné hardvérové požiadavky závisia od emulácie miereného smerovača. Každý podporovaný smerovač má vlastný priečinok, v rámci adresára vrnetlab, kde sa okrem iného nachádzajú aj pythonové skripty pre tvorbu Docker image a README textový súbor. Práve v tomto súbore sa nachádzajú informácie o minimálnych hardvérových požiadavkách daného smerovača, ba dokonca aj jeho testované verzie.
Bezchybná inštalácia všetkých potrebných súčastí emulátora a samotné zavedenie emulátora z gitu do systému, nám zobralo z HDD 697 MB. Ku tejto hodnote treba pripočítať veľkosti jednotlivých image súborov smerovačov a taktiež Docker image súborov, ktoré sa vytvoria spustením príkazu #make v adresári smerovača. Z obrazu RouterOS, ktorého veľkosť je 34MB, sa spraví Docker image o veľkosti 328MB. V prípade cloud smerovača spoločnosti Cisco, ktorého obraz má 1.47GB, sa spraví Docker image s veľkosťou 3.2GB. Testovaný bol aj obraz Cisco IOS XRv9k s veľkosťou 1.96GB a po dokončení procesu konverzie zobral Docker image z disku 2.37GB.
Keďže hardvérové požiadavky závisia od reálnych požiadaviek konkrétnych smerovačov, vo všetkých prípadoch je množstvo spustených inštancií závisle od veľkosti operačnej pamäte. Naša hardvérová konfigurácia umožnila spustenie maximálne 32 inštancií typu RouterOS. Inštancia typu CSR1000v má veľké nároky na hardvér (4 GB RAM) a podarilo sa spustiť iba 1 inštanciu.
Po spustení a načítaní kompletnej testovacej topológie, zloženej z hore uvedených zariadení, nám zostalo z operačnej pamäte k dispozícii približne 1 GB z celkových 8 GB. Procesor pri inicializácii danej topológie ukazoval vyťaženie všetkých (8) jadier na 100%, no v kľudnom stave boli jednotlivé jadra vyťažené maximálne od 10 do 20%.
Podpora platforiem
Vrnetlab podľa autora podporuje mnoho komerčných smerovačov vrátane Cisco CSR1000V, Cisco Nexus NX-OS, Cisco XRv, Cisco XRv9000, Juniper vMX a RouterOS od spoločnosti Mikrotik. V súčasnosti podporuje len jeden open-source smerovač OpenWRT. Umožňuje virtualizovať aj prepínače, no bohužiaľ jediný podporovaný prepínač je Juniper vQFX.
Z nami testovaných platforiem (CSR1000v, RouterOS, Juniper vMX 17.3R Olive, Juniper vMX 15.1F Olive, XRv9000, XRv9000 demo, C7200, C2691) sa nám podarilo úspešne spustiť len RouterOS a CSR1000v. V prípade Cisco XRv9000 sa podarilo len vytvoriť Docker image. Pri pokuse tvorby a spustenia kontajnera tohto image súboru vznikol problém, ktorý sa nepodarilo vyriešiť žiadnym spôsobom. Kontajner sa síce vytvoril, no pri pozeraní jeho stavu príkazom #docker container ls prešiel cca po jednej minúte zo stavu starting do stavu exited. Rovnaké správanie nastalo aj pri Cisco XRv9000 demo. Znovu spustenie už vytvoreného kontajnera nepomohlo. Inicializácia a konečné spustenie RouterOS trvalo približne jednu minútu. Horšie to bolo s CSR1000v, kde kontajner prechádzal stavmi starting, unhealthy, healthy dohromody 5 minút. Čo sa týka C7200 a C2691, tak nebolo možné vytvoriť ani len Docker image.
Po vypnutí a následnom zapnutí kontajnerov vznikla chyba v prípade RouterOS, kde sa už znova nezapol a dostal sa do stavu unhealthy.
Pri testovaní spustenia operačných systémov od spoločnosti Juniper( vMX 17.3R Olive, vMX 15.1F Olive) vznikali chyby už pri tvorbe Docker image, pričom sa nám nepodarilo spraviť konverziu ani jedného nami testovaného image súboru.
Vrnetlab nepodporuje nastavovanie hardvérových prostriedkov pre jednotlivé kontajnery. Inštancia si zoberie toľko prostriedkov, koľko reálne využije a tieto prostriedky sú popísané v súbore README v adresári konkrétneho smerovača.
Potreba získať OS virtuálneho zariadenia
Nástroj síce dokáže emulovať smerovače a prepínač, ale samotné image súbory podporovaných platforiem neobsahuje. Priečinky jednotlivých smerovačov obsahujú len skripty pre tvorbu Docker image a README súbor. Samotné operačné systémy je nutné si teda zaobstarať vlastnými metódami.
Podpora režimu klient/server
Vrnetlab je možné spustiť na ľubovoľnej distribúcii Linux s podporou KVM. To znamená, že sa dá spustiť aj na serveri a prístup ku virtuálnym smerovačom sa dá realizovať prostredníctvom vzdialeného prístupu použitím protokolov telnet alebo SSH
Prehľadnosť prostredia simulátora a jednoduchosť jeho inštalácie
Emulátor nezahŕňa v sebe grafické prostredie. Celý Vrnetlab funguje len na emulovaní smerovačov a prepojení medzi nimi. Smerovače možno v rámci emulátora spúšťať, vypínať a reštartovať. Rovnaké operácie sa dajú vykonávať aj s kontajnerom starajúcim sa o samotné prepojenie. Samotná konfigurácia a nastavovanie je teda obmedzené na použití konkrétneho smerovača a jeho podporovaných funkcii.
Na vytvorenie spojenia medzi virtuálnymi smerovačmi sa používa špeciálny Docker image nazývaný vr-xcon. Tento image taktiež treba vytvoriť použitím príkazu #make v adresári vr-xcon. Pri použití príkazu #docker run -d –name „názov prepoja“ –link „názov smerovača 1“ –link „názov smerovača 2“ „názov image súboru vr-xcon“ –p2p smerovač1/číslo rozhrania–smerovač2/číslo rozhrania sa vytvorí prepojenie medzi virtuálnymi smerovačmi na definovaných rozhraniach.
Vrnetlab prichádza s pár užitočnými funkciami, ktoré sú definované v súbore vrnetlab.sh. Ak ich chceme používať musíme v adresári /vrnetlab napísať príkaz source vrnetlab.sh. Jednou z užitočných funkcií je zjednodušené spájanie smerovačov. Použitím príkazu #vrbridge „smerovač1“ číslo rozhrania „smerovač2“ číslo rozhrania sa vykoná to isté ako v prípade hore popísaného príkazu. Takýmto spôsobom môžeme spájať ľubovoľné inštancie virtuálnych smerovačov a vytvárať tak topológiu. Tvorba spojení medzi smerovačmi takýmto spôsobom pri väčších topológiách zaberie priveľa času.
Väčšie topológie sa dajú realizovať použitím Docker Compose, čo je v podstate nástroj umožňujúci jedným príkazom spustiť topológiu definovanú v súbore docker-compose.yml. Príkaz #docker-compose up -d musí byť potvrdený v adresári kde sa tento súbor nachádza.
Pre prístup ku CLI daných smerovačov sa dá okrem telnetu a SSH použiť príkaz #vrcons „názov kontajnera“.
Podpora zo strany vývojárov a komunity
Dokumentácia obsahuje pomerne stručné informácie o tomto emulátore ako napríklad podporované platformy, použitie a minimálne požiadavky. Ohľadom samotnej inštalácie a použitia sa nenachádza žiaden záznam. Na druhú stranu sa tu nachádzajú odkazy na stránky, kde už samotná inštalácia a nevyhnutná konfigurácia popísaná je. Autor sa o Vrnetlab zmieňuje aj v rámci video prednášky o TeraStream, kde popisuje základné vlastnosti tohto emulátora.
Starostlivosť o tento emulátor je ukážkový. Podľa posledných zmien na githube, ktoré odkazujú na február tohto roku sa dá predpokladať, že vývojári neustále pracujú na vylepšení a optimalizácii tohto nástroja.
Inak to nie je ani v prípade komunity. V sekcii vyhradenej pre otázky a odpovede sa riešia problémy rôzneho typu.
Možnosť prepojenia simulátora s reálnou sieťou
Po dlhom skúmaní a testovaní sa nám nepodarilo žiadnym spôsobom pripojiť emulátor k reálnej sieti. Špeciálny Docker image vr-xcon, slúžiaci na vytvorenie spojení medzi jednotlivými smerovačmi, nedovoľuje pripojenie inštancie do reálnej siete.
O danom probléme sme písali na github tohto nástroja v sekcii Issues, žiaľ bez odpovede.
Schopnosti emulátora ako vzdelávacieho nástroja
Emulátor sa na základe autorom popísaných podporovaných platforiem môže zdať na prvý pohľad ako nástroj vhodný na použitie v priestoroch KIS. No opak je však pravdou. Zo všetkých podporovaných platforiem spoločnosti Cisco sa nám podarilo rozbehnúť iba cloud smerovač, ktorý je veľmi náročný na operačnú pamäť. Čo sa týka Juniper zariadení, tak ani jeden náš image súbor sa nepodarilo ani len prekonvertovať na Docker image. RouterOS od spoločnosti Mikrotik si na druhú stranu nevyžaduje enormné množstvo operačnej pamäte a ani spustenie či správny chod smerovačov nerobili problémy.
Dynamické smerovacie protokoly ako RIP či OSPF fungovali tak ako majú a to aj v prípade rozdielnych platforiem (prepojenie RouterOS s CSR1000v). Rovnako správne funguje aj statické smerovanie a nechýba tu tiež podpora IPv6. Etherchannel taktiež pracoval tak ako mal v prípade spojenia medzi danými Mikrotik-mi.
Emulátor síce obsahuje podporu pre jediný prepínač (Juniper vQFX), avšak získanie tohto operačného systému je dosť obťažné. Nám sa ho nepodarilo zohnať a tak testovanie prebiehalo bez jeho účasti, čo znemožnilo otestovať správnu funkčnosť protokolov ako napríklad STP.
Záverečné hodnotenie
Slabou stránkou tohto nástroja pre vzdelávanie v oblasti sieťových technológií je absencia grafického prostredia. Študenti nemajú možnosť sledovať dátovú prevádzku a nemajú ani predstavu ako daná topológia vyzerá. Výhodou je ale beh emulátora na serveri, čo umožňuje vzdialený prístup ku jednotlivým inštanciám, napríklad pomocou komunikačného protokolu telnet. Emulátor sa tak dá jednoducho použiť v prípade dištančnej formy vzdelávania, pričom študenti pracujú s originálnym operačným systémom zariadenia.