Embed Size (px)
Citation preview
Slovenská technická univerzita Fakulta informatiky a informačných technológií
Ilkovičova 3, 842 16 Bratislava 4
Simulátor komunikácie v
počítačovej sieti
Projektová dokumentácia
Tím 8.
Predmet: Tímový projekt I. Vedúci projektu: Ing. Igor Grellneth, PhD. Členovia tímu: Bc. Roman Broniš Bc. Andrej Kozemčák
Bc. Pavel Cséfalvay Bc. Peter Morvay Bc. Lukáš Káčer Bc. Adam Sloboda
Akademický rok: 2010/2011
ii
Obsah
0 Úvod ................................................................................................................................................. v
0.1 Účel a rozsah dokumentu ........................................................................................................ vi
0.2 Zadanie projektu ..................................................................................................................... vi
0.3 Slovník pojmov ........................................................................................................................ vi
0.4 Použité skratky ....................................................................................................................... vii
1 Špecifikácia ...................................................................................................................................... 1
1.1 Dokumentačná časť projektu .................................................................................................. 1
1.1.1 Inštalačná príručka .......................................................................................................... 1
1.1.2 Používateľská príručka ..................................................................................................... 1
1.2 Implementačná časť ................................................................................................................ 1
1.2.1 Sfunkčnenie systemu ....................................................................................................... 2
1.2.2 Zjednodušenie inštalácie ................................................................................................. 2
1.3 Rozšírenia ................................................................................................................................ 2
1.3.1 Podpora IPv6 pre PC stanice a laboratórne úlohy ........................................................... 2
1.3.2 Zobrazovanie aktuálneho vyťaženia CPU a RAM ............................................................. 3
1.4 Vyhodnocovanie a testovanie labov ....................................................................................... 3
2 Analýza ............................................................................................................................................ 4
2.1 Analýza aktuálneho stavu projektu VLAB ................................................................................ 4
2.2 Zjednodušenie inštalácie ......................................................................................................... 4
2.3 Rozšírenia ................................................................................................................................ 5
2.3.1 Analýza možností zobrazovania využitia systémových prostriedkov .............................. 5
2.3.2 Podpora IPv6 pre PC stanice a laboratórne úlohy ........................................................... 5
iii
2.3.3 Vyhodnocovanie a testovanie LABov .............................................................................. 6
2.4 Sfunkčnenie nového VLABu ..................................................................................................... 7
2.4.1 Starý server VLAB ............................................................................................................ 7
2.4.2 Inštalácia nového serveru ................................................................................................ 7
2.5 Dynamips IdlePC hodnoty ....................................................................................................... 9
2.6 Využitie RAM IOSmi ............................................................................................................... 12
2.6.1 Spúšťacie skripty ............................................................................................................ 12
3 Návrh ............................................................................................................................................. 17
3.1 Podpora IPv6 ......................................................................................................................... 18
3.2 Zobrazenie a vyťaženie CPU a RAM ....................................................................................... 18
3.3 Zjednodušenie inštalácie ....................................................................................................... 19
3.4 Sfunkčnenie starého VLABu .................................................................................................. 20
3.5 Vyhodnocovanie labov .......................................................................................................... 21
4 Návrh systému ............................................................................................................................... 22
5 Implementácia ............................................................................................................................... 28
5.1 Výber implementačného jazyka a prostredia ........................................................................ 28
5.2 Opis realizácie ........................................................................................................................ 29
5.2.1 Webové rozhranie ......................................................................................................... 29
5.2.2 Funkčné vyhodnocovanie .............................................................................................. 30
5.2.3 Konfigurácia VLAB ......................................................................................................... 32
5.2.4 Základná konfigurácia .................................................................................................... 32
5.2.5 Testovanie ..................................................................................................................... 36
5.3 Tvorba testovania .................................................................................................................. 43
iv
5.3.1 Spôsob navrhovania testovania .................................................................................... 49
6 Overenie výsledku ......................................................................................................................... 58
7 Záver .............................................................................................................................................. 59
8 Zdroje............................................................................................................................................. 60
9 Príloha A ........................................................................................................................................ 61
9.1 Vytvorenie testovania pre Basic Router Configuration ......................................................... 61
9.1.1 Zadanie úlohy Basic Router Configuration .................................................................... 61
9.1.2 Vzorová konfigurácia ..................................................................................................... 63
9.1.3 Navrhnuté testovanie .................................................................................................... 64
9.1.4 Výpis pri dosiahnutí plného počtu bodov...................................................................... 64
9.2 Vytvorenie testovania pre Basic BGP configuration .............................................................. 65
9.2.1 Zadanie úlohy Basic BGP configuration ......................................................................... 65
v
0 Úvod
Informatika je veda, ktorá je síce pomerne mladá, ale v súčastnosti je jedna z najrýchlejšie sa
vyvíjajúcich. K jej najväčším úspechom v súčastnoti patrí hlavne Internet, ktorý je zdrojom
obrovského množstva informácií. Aktuálna vízia udáva, že do roku 2025 bude mať prístup k internetu
približne 5 miliard ľudí. *1]
Internet je postavený na jednej z prvých počítačových komunikačných sietí - ARPANET. Táto
malá vojenská sieť, ktorá prepájala najprv desiatku osobných počítačov, neskôr univerzity, dnes spája
celý svet. To, čo vzniklo ako jednoduché prepojenie počítačov medzi sebou, sa postupne začalo
rozširovať o ďalšie zariadenia, ktoré dokázali rozšíriť dostupnosť pripojenia k sieti ďalej a k viacerím
používateľom. K tomuto účelu sa do siete začali pridávať postupne bridge, huby, switche a routre…
Účelom týchto zariadení nebolo len poskytnúť pripojenie pre viac vzdialených zariadení, ale vytvoriť
systém. Tak vznikla adresácia, siete a podsiete. Internet je svojim spôsobom len jedna veľká sieť
skladajúca sa z obrovského množstva menších sietí. Tieto malé siete majú svoje účely. Niektoré patria
do sféry domácich sietí, firemných sietí, univerzitných sietí, a pod. Na to, aby sme vedeli ako fungujú
takéto siete a vedeli ich spravovať slúžia aj rozličné predmety na našej škole, ktoré sa tématikou
počítačových sietí zaoberajú. *2]
Pri štúdiu sa musí študent oboznámiť s rozličnými protokolmi v počítačových sieťach, typmi
prepojení zariadení, ako funguje v sieťach adresácia a mnoho iného. Konkrétne v predmet Počítačové
siete II. sa študenti oboznamujú so switchmi a routermi, ich funkciou a učia sa ako tieto zariadenia
správne používať. Pre skúšanie konfigurácie týchto zariadení im slúžia prevažne cvičenia, kde majú
študenti k týmto zariadeniam fyzický prístup. Študent má teda len obmedzený čas, ktorý môže využiť
na oboznamovanie sa so zariadeniami. Čo v prípade, ak by študent potreboval viac času na získanie
všetkých potrebných znalostí a zručností?
Je pravda, že študent si môže pre dodatočné štúdium vybaviť prístup do školských laboratórií,
no toto riešenie je zložité, pretože by študent potreboval v laboratóriu kvalifikovaný dozor. Druhou
možnosťou je, že si študent zabezpečí zariadenia vlastné. Toto riešenie je pre študentov finančne
náročné, keďže takéto zariadenia cenovo sú drahé a študent potrebuje minimálne štyri (dva routre a
dva switche) aby si mohol vyskúšať všetky potrebné nastavenia. Tretia možnosť je využiť softvérový
simulátor sieťovej komunikácie. Medzi takéto patrí napríklad Cisco Packet Tracer.[3+ Vďaka tomuto
programu si môže študent vyskúšať rozličné nastavenia zariadení v rozličných sieťových topológiách.
Takéto riešenie by mohlo byť ideálne, no tento produkt je platený. Preto študenti častokrát siahajú
po nelegálnych verziách Packet Tracera. Naskytuje sa riešenie nájsť k programu Packet Tracer zdarma
vi
dostupný ekvivalent. Takéto riešenie existuje a skladá sa z programov dynamips a dynagen. Tieto
programy sú voľne dostupné, no pre prácu s nimi je potrebné vlastniť IOSy zariadení, ktoré chceme
simulovať. Pre študenta je to ďalšia slepá ulička, keďže IOS si treba zakúpiť a inštalácia samotného
systému je pomerne komplikovaná.
Ako riešenie prišla idea navrhnúť vlastný sieťový simulátor, ktorého používanie by bolo voľne
dostupné študentom. Pod vedením Ing. Grellnetha PhD. tak vznikol projekt VLAB - Virtuálny sieťový
simulátor. [4]
0.1 Účel a rozsah dokumentu
Tento dokument vznikol ako projektová dokumentácia k predmetu Tímový projekt na Fakulte
Informatiky a Informačných technológií, STU Bratislava. Vypracoval ho tím PSS číslo 8 z roku 2010/11.
Je určený najmä pre účely hodnotenia a neskôr ako dokumentácia pre nadviazanie na projekt.
Dokument má zatiaľ rozsah odpovedajúci odovzdávanému projektu počas zimného semestra.
Obsahuje časti špecifikácia požiadaviek, analýza a návrh riešenia pre softvérovú simuláciu sieťovýh
prostriedkov.
0.2 Zadanie projektu
Názov: Simulátor komunikácie v počítačovej sieti
Znenie: Navrhnite a zrealizujte programový systém pre simuláciu sieťovej komunikácie na druhej a
tretej vrstve sieťovej architektúry RM OSI.
Systém má umožňovať:
definovanie topológie simulovanej siete
simuláciu rôznych prepájacích zariadení (napr. prepínač, smerovač, firewall … )
simuláciu komunikácie medzi prepájacími zariadeniami. Funkčnosť navrhnutého systému overte v sieti so simulovanými zariadeniami pomocou komunikácie
medzi koncovými zariadeniami.
0.3 Slovník pojmov
Nasleduje zoznam pojmov, ktoré v slovenskom jazyku neamjú vhodný preklad a tak sme sa
ich v dokumenterozhodli písať v pôvodnom tvare. Tieto výrazy sú v texte uvedené kurzívou.
Pôvodné výrazy sme neskloňovali uvádzame ich v tvare bez pomlčky, použili sme základ slova
vii
a k nemu sme pridali príponu podľa slovenskej gramatiky. Väčšina týchto skratiek pochádza ešte
z predchádzajucich tímových projektov[7].
Bash je unixový príkazový shell interpreter naprogramovaný v rámci projektu GNU. Názov je
akronym k názvu Bourne again shell - je založený na Bourne Shellu (bsh), čo bol
najpoužívanejší unixový shell
Demo je predvádzací program.
Enterprise v preklade podnik, podniková.
Ethernet je technológia počítačových sietí.
Firewall je sieťové zariadenie a/alebo softvér, ktorého úlohou je oddeliť siete s rôznymi
prístupovými právami a kontrolovať tok dát medzi týmito sieťami.
Flash pamäť celým menom Flash-EEPROM, je zrýchlená elektricky preprogramovateľná
pamäť ROM (Read-Only Memory).
Frame Relay jeho podstata spočíva v zriadení prístupových okruhov a v zriadení virtuálnych
okruhov.
Hypervisor je konzola programu Dynamips.
Proxy je špeciálny typ servera - prostredníka v komunikácii, ktorý sa umiestňuje medzi klienta a
servery, s ktorými komunikuje. Proxy server sa tvári voči klientovi ako server a voči serveru ako
klient.
Root alebo inak administrátor má schopnosť pristupovať ku všetkým súborom v systéme.
Telnet je sieťový komunikačný protokol, ktorý umožňuje pripojenie k inému zariadeniu na sieti.
Wrapper je mechanizmus, ktorý umožňuje riadiť prístup k službám vášho servera na základe
adresy, z ktorej prichádza požiadavka klienta.
0.4 Použité skratky
Kvôli prehľadnosti a účelnosti dokumentu sme sa rozhodli používať všeobecne známe
skratky, Rovnako väčšina z nich pochádza z predchádzajúcich tímových projektov.
ACL Access Control List
ASA Adaptive Security Appliance
CCNA Cisco Certified Network Associate
CCNP Cisco Certified Network Professional
IANA Internet Assigned Numbers Authority
ID Identification Database
IM Instant Messaging
viii
IOS Internetwork Operating System
IP Internet Protocol
IPv6 Internet Protocol verzia 6
IPS Intrusion Prevention Sensor
IPv6 Internet Protocol version 6
ISDN Integrated Services Digital Network
LAB Laboratórna úloha v prostredí VLABu
LAN Local Area Network
NAT Network Address Translation
OS Operating System
OSPF Open Shortest Path First
PAT Port Address Translation
PNG Portable Network Graphics
RFC Request for Comments
RIP Routing Information Protocol
RM OSI Reference Model Open System Interconnected
RSH - Remote Shell, Vzdialená konzola. Táto skratka označuje nástroj a protokol, pomocou ktorého sa
vykonácajú príkazy na vzdialenom zariadení v sieti pod špecifikovaným používateľom.
SPI Stateful Packet Inspection
SSH Secure Shell
SSL Secure Sockets Layer
TCP Transmission Control Protocol
UDP User Datagram Protocol
UML Unified Modeling Language
VDE Virtual Distributed Ethernet
VLAB Virtual Lab
VLAN Virtual LAN
VPN Virtual Private Network
WAN Wide Area Network
1
1 Špecifikácia
V časti špecifikácia si povieme aké úlohy sme v rámci projektu odhalili.
1.1 Dokumentačná časť projektu
Projekt VLAB vznikal ako projekt viacerých tímov v predmete Tímový projekt a taktiež boli
určité jeho časti aj náplňou diplómových prác. Tento projekt je veľmi komplexný a rozsiahli, čo má za
následok určitú neprehladnosť pri jeho inštalácii, správe a používaní. Preto sme sa rozhodli
sprehľadniť momentálny stav vytvorením používateľskej dokumentácie a inštalačnej príručky.
1.1.1 Inštalačná príručka Inštalačná príručka má za cieľ oboznámiť správcu s inštaláciou pri nasadzovaní VLABu na nový
stroj, čím mu má zjednodušiť a tak aj zrýchliť celý proces inštalácie. Pôvodná dokumentácia nebola na
dostatočnej úrovni, veľa častí nie je zdokumentovaných, alebo chýba. Pri našej novej inštalácií sa
vyskytol návrh inštaláciu sprehľadniť a zjednodušiť. Zavedením odlišného postupu inštalácie je preto
nutné vytvoriť novú inštalačnú príručku.
1.1.2 Používateľská príručka Používateľská príručka by mala zabezpečiť sprehľadnenie systému ako používateľom z radu
študentov a učiteľov tak aj správcom systému. Preto by sa mala skladať z troch častí navrhnutých pre
daný typ používateľa podľa ich predpokladaných vedomostí a možností práce so systémom.
Používateľská príručka pre študentov musí byť ľahko čitateľná a zrozumiteľná aj pre používateľov,
ktorý majú len základné vedomosti s používaním počítaču. Príručka má obsahovať najmenej
rezervácie, vytváranie a používanie LABov. Časť určená pre učiteľov má obsahovať okrem časti pre
študenta aj rozšírenie v podobe popisu registrácie tried a používateľov. Posledná časť určená pre
správcov systému musí obsahovať ako časti pre študentov a učiteľov, tak aj rozšírenie o rozšírené
možnosti správy rezervácií, používateľov a LABov, tak i výpisy štatistických informácií a logov.
1.2 Implementačná časť
V rámci implementačnej časti si povieme, čo je nutné v rámci projektu naimplementovať.
2
1.2.1 Sfunkčnenie systemu Systém je hlavne určený pre študentov študujúcich predmety ps2 a WAN technológie.
Samozrejme ho môžu používať aj študenti študujúci program CISCO. Pretože daný systém bol už
dlhšiu dobu nefunkčný budeme ho musieť znovu sfunkčniť aby ho študenti mohli používať.
Sfunkčnenie systému bude veľmi dôležité aj pre nás aby sme systém mohli znovu vyvíjať vylepšovať a
testovať. Zároveň, keď bude systém funkčný budú ho môcť používať aj študenti a budú nám môcť
hlásiť veci, ktoré v systéme nefungujú a mi sa na ne budeme môcť zamerať, zistiť prečo nefungujú a
následne ich opraviť.
1.2.2 Zjednodušenie inštalácie Systém sme prebrali v nefunkčnom stave a preto sme ho museli rozbehať odznova. Pri
rozbiehaní sme zistili, že neexistuje žiaden inštalačný skript a preto budeme musieť všetky súbory na
nový systém nahadzovať ručne. V dokumentácií sa nám podarilo nájsť návod ako program na nový
systém nainštalovať, ale tento návod bol dosť zložitý a miestami bol už zastaraný. Preto súčasný stav
ohľadom inštalácie pokladáme za nevyhovujúci a v budúcnosti ho plánujeme podstatne zjednodušiť.
Chceli by sme vytvoriť jednoduchý skript, ktorý by program nainštaloval za nás a my by sme nemuseli
postupne ručne kopírovať všetky zdrojové kódy na ich miesto a nastavovať oprávnenia pre jednotlivé
súbory.
1.3 Rozšírenia
Našou úlohou je posunuť projekt ďalej. V rámci toho sme by sme chceli implemtovať
nasledujúce rozšírenia.
1.3.1 Podpora IPv6 pre PC stanice a laboratórne úlohy Pre Internet začínajú byť problémom obmedzenia IP protokolu verzie 4 (IPv4). Odhaduje sa,
že v roku 2011 už nebudú ďalšie voľné IP adresy, IANA pridelí posledné bloky piatim regionálnym RIR
(Regional Internet Registry). Každý región, v Európe je to Réseaux IP Européens Network
Coordination Centre (RIPE NCC), dostane po jednom bloku. V ázijsko-pacifickom regióne sa jeden
blok vyčerpá za približne jeden a pol mesiaca.
Úplné vyčerpanie je teda nevyhnutné a rýchlo sa blíži. V poslednej dekáde sa softvér a
operačné systémy prispôsobovali aby boli na IP verzie 6 (IPv6) pripravení. Pre študentov je
3
nevyhnutné aby sa oboznámili s protokolom, ktorý sa v ďalších rokoch stane dominantným, a mohli si
vyskúšať ako sa s ním pracuje a aké zmeny prináša.
Naším cieľom je rozšíriť VLAB o podporu simulácie IPv6 siete.
1.3.2 Zobrazovanie aktuálneho vyťaženia CPU a RAM VLAB je nástroj na simuláciu sieťovej komunikácie. Táto simulácia je so zvyšujúcim sa počtom
simulovaných zariadení viac náročnejšia na systémové prostriedky - konkrétne procesor a hlavnú
pamäť. Pre správ VLABu je preto častokrát nutné pre správcu pri riešení problémov pripájať sa ku
konzole stroja, na ktorom VLAB beží a príkazmi je schopný si zobraziť aktuálny stav využitia
prostriedkov.
Takéto riešenie má viac nedostatkov. Správca by mal mať znalosti, ako si príkazmi zistiť stav
systému, ale je to zdĺhavá činnosť. Pre zjednodušenie môže použiť aplikáciu ako napríklad top (resp.
htop), ktorá mu zobrazí aktuálny stav využitia prostriedkov. Nevýhodou takéhoto riešenia je, že
zobrazuje iba aktuálny stav a pre správcu je potrebné častokrát si vedieť zobraziť aj staršie údaje, aby
získal predstavu, ako boli systémové prostriedky vyťažené.
Pre riešenie tohoto problému sme sa rozhodli zanalyzovať možnosti merania prostriedkov,
navrhnúť ich používateľsky jednoduchú prezentáciu, ktorú následne implementujeme do VLABu.
1.4 Vyhodnocovanie a testovanie labov
Pre študenta je síce nápomocné, že si môže pomocou VLABu vyskúšať konfigurovanie
sieťových zariadení pre jednotlivé predpripripravené zapojenia podľa rôznych úloh, no určite ho aj
zaujíma, či danú úlohu zvládol. Preto sme sa rozhodli rozšíriť VLAB aj o možnosť automatickej
kontroly študentovej konfigurácie. Pre túto kontrolu je možné zvoliť viacero prístupov, z ktorých
každý ma svoje pre a proti.
4
2 Analýza
V časti analýza sa bližšie pozrieme na oblasti definované v špecifikácií a samotný VLAB.
Ukážeme si, čo sme už pre rozbehnutie VLABu spravili.
2.1 Analýza aktuálneho stavu projektu VLAB
Projekt VLAB má viacročnú historiu. Ide o projekt, na ktorom už pracovali dva rôzne tímy na
predmete Tímovy projekt. Taktiež na tomto projekte pracoval aj ing. Peter Péti vo svojej diplomovej
práci. Výstupom týchto snažení sú okrem iného 3 dokumenty, v ktorých sú podrobné analýzy
jednotlivých častí VLABu.
V diplomovej práci ing. Pétiho ako aj v dokumentácií tímu č. 9 zo školského roku 2008/2009
sú aj inštalačné príručky VLABu. Aj keď sú tieto dva dokumenty najnovšie, po krátkej analýze sme
však zistili, že niesú najaktuálnejšie nakoľko boli na tomto projekte robené úpravy aj po odovzdaní
týchto dokumentov. Podľa informácií vedúce projektu ing. Grellnetha, PhD. išlo hlavne o opravy
chýb, ktoré boli odhalené pri používaní projektu študentami. Išlo o nezdokumentované úpravy a
existovali iba na nasadenom VLABe na školskom serveri, no počas analýzi nám bolo povedané, že
tento server je už nejakú dobu zrušený, a nebolo jasné či existuje nejaká záloha. Na základe toho sme
sa rozhodli, že rozchodíme VLAB podla inštalačnej príručky z diplomovej práce, nakoľko bola podľa
nás najkvalitnejšia. Táto inštalačná príručka bola pre linuxovú distribúciu Gentoo no my sme sa
rozhodli, že budeme VLAB vyvíjať na linuxovej distribúcií Debian. Po nainštalovaní balíčkov
potrebných pre funkčnosť VLABu sme narazili na niekoľko problémových skutčností. Približne v tom
istom čase sme sa ale dostali k zálohe zo starého servera na ktorm VLAB fungoval čo nám pomohlo
ujasniť si tieto problémy a sfunkčniť VLAB aj s nezdokumentovanými opravami a vylepšeniami.
Nakoľko sme si ako jeden z cieľov dali zjednodušenie celého inštalačného procesu,
nebudeme v tejto analýze (bližšie) rozoberať kroky v ktorých sa popisovaná inštalácia líši od nami
vykonanej inštalácie, keďže predpokladáme, že sa tento postup bude v priebehu nasledujúcich
mesiacov meniť. Uvádzame preto len priebežnú zjednodušenú verziu v časti Sfunkčnenie nového
VLABu.
2.2 Zjednodušenie inštalácie
Projekt VLAB je rozsiahly či už do počtu častí, ktoré sám obsahuje, ale aj do počtu externých
častí od ktorých je závislý. Preto je pochopiteľné, že sú potrebné značné vedomosti a schopnosti na
5
jeho inštaláciu, resp. zduplikovanie a oddelenie vývojovej a produkčnej inštancie. O tomto fakte sme
sa na začiatku našej práce aj sami presvedčili, a preto by sme tento proces chceli čo možno najviac
zjednodušiť.
2.3 Rozšírenia
V tejto časti si ozrejmíme aké rozšírenia bude nutné spraviť.
2.3.1 Analýza možností zobrazovania využitia systémových prostriedkov Pre správcu VLABu je častokrát potrebné poznať nielen aktuálne využitie systémových
prostriedkov, ale aj aké bolo ich vyťaženie v minulosti.
Obľúbený spôsob zobrazovania aktuálneho vyťaženia prostriedkov je pomocou
aplikácie ps pod OS Linux / UNIX. Pomocou tejto aplikácie je vhodnou modifikáciou prepínačov
a úpravou výstupom možné dostať aktuálne vyťaženie CPU a RAM ako pre procesy konkrétneho
používateľa, tak i pre všetky procesy v systéme.
Samotné aktuálne informácie o stave systému sú síce dôležité, ale z pohľadu správcu by bolo
dobré poznať predošlé vyťaženie systémových prostriedkov. Výstup programu ps je preto potrebné
ukladať s časovým údajom, kedy boli hodnoty získané. Pravideľný zber údajov zabezpečíme napríklad
pravideľným spúšťaním príkazov pomocou programu cron.
Súbor obsahujúci vyťaženie CPU a RAM v konkrétnom čase je možné pomocou programov
vytvárajúcich premeniť do jednoduchej podoby obrázku grafu závislosti vyťaženia CPU a RAM v čase.
Za programy, ktoré dokážu vytvárať grafy na základe údajov spomeniem napríklad RRDTool
a GNUPlot. Výstupy týchto programov sú v podobe obrázkov typu PNG, ktoré je možné ľahko
zobrazovať v používateľskom rozhraní VLABu.
Takýmto spôsobom správca ľahko získa prehľad o stave systému.
2.3.2 Podpora IPv6 pre PC stanice a laboratórne úlohy Systémy Cisco IOS majú zabudovanú podporu IPv6 už niekoľko rokov, čo bolo overené
testovaním aj na verziách IOS použitých vo VLAB.
User-Mode Linux (UML) jadro použité v pôvodnej verzii VLAB bohužiaľ túto podporu nemá.
Jadro je verzie 2.6.23, ktoré má možnosť podpory IPv6, preto bude nutné vytvoriť nové jadro, ktoré
bude mať túto podporu.
6
Systém, ktorý UML jadro používa, obsahuje iba program ifconfig, ktorý je nedostatočný pre
konfiguráciu IPv6 a často aj IPv4, preto bude nutné tiež pridať nový balíček nástrojov ip.
Pretože sa jedná iba o zmenu verzie IP protokolu, čo sa nedotkne vyšších ani nižších vrstiev,
mali by byť pôvodné laby použiteľné s oboma verziami IP protokolu.
2.3.3 Vyhodnocovanie a testovanie LABov Analýzov sme zistili tieto tri možnosti vyhodnodcovania LABov.
Vyhodnocovanie konfiguračných súborov
Tento prístup navrhuje ako možné rozšírenie aj ing. Péti vo svojej diplomovej práci [8].
Kontrola by spočívala v porovnávaní častí vypracovanej konfigurácie k vzorovému riešeniu. Ide v
princípe o jednoduchý prístup, no pri zložitejších úlohách treba myslieť na to, že správna konfigurácia
nie je iba jedna.
Testovanie pomocou diagnostických sieťových nástrojov
Pri tomto spôsobe testovania sa nekontrolujú samotné konfigurácie zariadení, ale dostupnosť
jednotlivých sieťových prepojení a služieb. Na základe výstupov jednotlivých diacnostických nástrojov
(ako napr. ping alebo netcat) vieme s určitosťou povedať, či je výsledný efekt konfigurácie taký ako sa
v zadaní úlohy očakáva, no už nevieme vyhodnotiť, či sa tento efekt dosiahol spôsobom predpísaným
v zadaní. Napríklad vyhodnotíme, že ǚsetky smerovače smerujú správne, no nevieme či na to
používajú správny protokol. Tento spôsob má však relatývne veľký problém už so samotným
pripojením sa na smerovače a UML, keďže tieto sa môžu nachádzať v rôznych stavoch. Taktiež treba
počítať s tým, že formát výstupu jednotlivých nástrojov nie je všetkých zariadeniach rovnaký.
Analýza na zaklade vypisov zariadeni (show)
Na kontrolu zadani sa daju použiť príkazy (typu show) ktoré IOS obsahuje a primárne slúžia pre
administrátora, aby si vedel po sebe skontrolovať, či systém funguje tak, ako by si predstavoval. IOS
umožňuje pridať do konfigurácie aj takzvané TCL skripty, ktoré sa dajú vhodne využiť na
skombinovanie týchto diagnostických nástrojov. Tieto skripty potom vedia slúžiť či už ako súčasť
automatického vyhodnocovania, alebo ako poloautomatické vyhodnotenie, ktoré si študent bude
môcť spustiť sám na zariadení.
7
2.4 Sfunkčnenie nového VLABu
2.4.1 Starý server VLAB Pôvodný projekt VLAB bežal pod správou Petra Pétiho. Jednalo sa o virtuálny server
poskytnutý fakultou, ktorý mal nainštalovaný operačný systém Gentoo 2007, ktorý už nie je
podporovaný a bolo by veľmi náročné aktualizovať celý systém. Po zvážení všetkých nevýhod sme sa
rozhodli nainštalovať celý projekt VLAB nanovo s cieľom, aby v budúcnosti nebolo nutné kvôli
aktualizácii znovu podnikať takéto závažné a časovo náročné zmeny.
2.4.2 Inštalácia nového serveru Projekt dostal pridelený nový virtuálny server, ktorý je prístupný na pôvodnej
adrese vlab.fiit.stuba.sk. Na tento server sme nainštalovali operačný systém Debian GNU/Linux.
Vytvorili sme zálohu poslednej verzie softvéru na starom serveri a postupne sme obnovili
webovú aplikáciu, databázu aj samotnú emuláciu. Niektoré časti dostupnej dokumentácie
nezodpovedali súčasnému stavu a preto bolo nutné zistiť pokusmi ako softvér pracuje, ktoré
programy a skripty sú ešte aktuálne a využívané a ktoré je možné bezpečne odstrániť.
Základné závislosti projektu
Projekt závisí na niekoľkých serveroch, ktoré umožňujú spustenie webového rozhrania a
databázy. V zátvorke sú uvedené názvy balíčkov v systéme Debian:
- Apache 2 – webový server (apache2),
- PHP 5 (libapache2-mod-php5),
- MySQL – databázový server (mysql-server).
Závislosti skriptov
V zátvorke sú uvedené názvy balíčkov v systéme Debian:
- Dynamips – emulátor Cisco hardvéru (dynamips),
- Dynagen – nástroj na ovládanie Dynamips (dynagen), - PEMU – emulátor pre Cisco PIX (nemá balíček),
- User-Mode Linux pre emuláciu počítačov v topológiách (uml-utilities a špeciálne skompilovaný),
- Telnet – pre pripojenie konzoly UML (telnetd)
- Virtual Distributed Ethernet – virtuálny prepínač (vde2),
- cpulimit – obmedzenie vyťaženia PEMU (cpulimit),
- sudo – nástroj pre spúšťanie programov a skriptov pod iným užívateľom (sudo).
Závislosti webovej aplikácie
8
V zátvorke sú uvedené názvy balíčkov v systéme Debian:
- Smarty – šablónovací engine pre jazyk PHP (smarty),
- Smarty compiler.defun-plugin plugin (http://lammfellpuschen.de/compiler.defun/)
- PEAR (PHP Extension and Application Repository) pre
balíčky HTML_QuickForm2 a Image_GraphViz(php-pear).
Reorganizácia projektu
Súbory projektu boli pôvodne rozmiestnené na viacerých miestach. Pre zvýšenie prehľadnosti
sa všetky súvisiace súbory presunuli do podadresárov v adresári /srv. Z webovej aplikácie boli
oddelené adresáre pre dočasné dáta.
/srv/cisco obrazy Cisco softvéru
/srv/uml User-Mode Linux systém
/srv/vlab/web webová aplikácia
/srv/vlab/scripts skripty
/srv/vlab/tmp miesto pre ukladanie dočasných a pracovných súborov pre webovú aplikáciu,
skripty a emulátory
Kvôli zmenám umiestnenia bolo nutné upraviť veľké množstvo zdrojových súborov, ktoré
používali pevné cesty k súborom. Toto prispelo ku konfigurovateľnosti a využijeme to pri inštalácii
oddelenej vývojovej verzie.
Počas reorganizácie boli nájdené súbory, ktoré projekt už nepoužíva, a boli pre zvýšenie
prehľadnosti odstránené.
Vytvorenie nového User-Mode Linux jadra (UML)
Správne vytvorenie User-Mode Linux jadra sa ukázalo ako problematické – jadro zo starého
projektu je nekompatibilné s novým serverom. Podarilo sa nám vytvoriť funkčnú konfiguráciu pre
jadro verzie 2.6.23, akékoľvek novšie jadro (2.6.24, 2.6.32, 2.6.36) nepracovalo správne. Taktiež sa
nám nepodarilo použiť 64-bitové jadro.
S použitím našej konfigurácie je možné bez ďalších úprav skompilovať jadro 2.6.23.17
nasledujúcimi príkazmi (32-bitové i386 jadro je možné skompilovať na amd64 systéme):
make oldconfig ARCH=um SUBARCH=i386
9
make ARCH=um SUBARCH=i386
Výsledné je veľmi veľké kvôli symbolom, tie je možné odstrániť príkazom:
strip linux
2.5 Dynamips IdlePC hodnoty
Kvôli zmene serveru sa museli odskúšať všetky použité obrazy IOS a zistiť novú hodnotu
IdlePC. Tieto nové sme aktualizovali v konfiguráciách topológií, čo výrazne znížilo zaťaženie
serveru.
IdlePC hodnota – Pri emulovaní sieťových zariadení je nutné, aby sme zefektívnili
vykonávanie jednotlivých inštrukcií procesora. Keďže procesory v zariadeniach sú architektúry MIPS,
ich inštrukcie nie sú kompatibilné s inštrukciami v x86 procesoroch. Aby sme odľahčili x86 procesoru,
musíme ho naučiť, ktoré inštrukcie v procesore zariadenia zodpovedajú takzvaným waiting loop
inštrukciám. Toto sa robí pomocou nastavenie idlePC hodnoty.
Po spustení nového operačného systému zariadenia, emulovací systém nevie rozpoznať
waiting loop a tak jedno zariadenia využíva jedno jadro procesora na 100 %. Po správnom nastavení
idlePC hodnoty vieme dosiahnuť využívanie len niekoľkých percent CPU.
Následne si ukážeme, ako sme hľadali správnu idlePC hodnotu. Pre jednoduchosť sme
overovali naše hypotézy na programe GNS3, ktorý využíva dynamips, dynagen na operačnom
systéme Windows. Keďže správna idlePC hodnota je špecifická pre každú kombináciu OS zariadenia
a hardware emulovacieho systému, toto meranie sme brali len orientačne a najmä z dôvodu overenia
hypotéz. Zvolili sme si 3 rôzne platformy konkrétne Cisco routre 2961, 3640 a 7200.
Na testovanie sme využili notebook Lenovo T60 v konfigurácii 1951WMB s procesorom Intel
T2400 dualcore s 1,83 GHz a 2,5GB RAM.
Použili sme tieto verzie IOSov:
- c7200-jk8s-mz.122-15.T17.bin - c3640-ik9o3s-mz.124-25b.bin - c2691-adventerprisek9-mz.124-25c.bin
Ako prvé sme sa pokúsili nájsť idlePC hodnotu, ktorá pri použití jedného routra využívala
procesor na čo najmenej percent. Podarilo sa nám pri všetkých troch platformách nájsť idlePC
hodnotu, pri ktorej sa využitie procesora s jedným zariadením pohybovala na úrovni 0 - 5 percent.
Aby sme našli ideálnu hodnotu, museli sme zvoliť väčšiu topológiu. Zvolili sme si topológiu
10
pozostávajúcu z 8 routrov, a na každom routri sme ako simuláciu sieťových protokolov použili
kombináciu 3 routovacích protokolov, konkrétne: RIPv2, EIGRP a OSPFv2.
Obrázok 1.: Jednoduchá topológia
Topológia testovacej siete
Prvá platforma po skonvergovaní využila približne 30 % CPU. Následne sme skúsili použiť
platformu, ktorá je vlajkovou loďou spoločnosti Cisco a to 7200. Samotný dynamips je optimalizovaný
na beh tejto platformy a tak sme očakávali lepšie výsledky. Pri topológii s 8 routrami spotrebovávala
emulácia približne 25 percent CPU. Následne sme skúsili nájsť hranicu, koľko routrov sa dá na našom
hardware emulovať pri neprejavovaní výraznejších latencií. Dostali sme sa na hranicu 16 routrov
s využitím CPU na 80 – 90 %. Pri pridaní ďalšieho routra sme už dosiahli vyťaženie na 100 %. Pre
ilustráciu sme priložili aj obrázok s topológiou, na ktorej sme testovali hraničné možnosti.
11
Obrázok 2.: Zložitá topológia
Topológia na testovanie hraničných možností
Keďže latencie pingov sú v dynamipse značne väčšie ako pri reálnych zariadeniach rozhodli
sme sa použiť pre meranie odozvy fyzickú prácu so zariadeniami, konkrétne vypisovanie routovacích
tabuliek na zariadenich. Pri topológii so 16 routrami sa aj pri zmene v topológii a teda prepočítavaní
na každom routri dalo s routrami svižne pracovať a neregistrovali sme žiadne výrazné latencie.
Platforma 7200 nepodporuje switchové karty, preto sme otestovali aj tretiu platformu a to
3640. Pri tejto platforme sme dosiahli mierne lepšie výsledky ako pri platforme 2961. Preto sme sa
v ďalšej implementácii rozhodli používať platformy 7200 na emuláciu routrov a 3640 pri emuláciu
switchov.
Najviac sa nám osvedčili tieto idlePC hodnoty:
- c7200-jk8s-mz.122-15.T17.bin - 0x60709500 - c3640-ik9o3s-mz.124-25b.bin - 0x605f1120 - c2691-adventerprisek9-mz.124-25c.bin - 0x60a48d14
12
2.6 Využitie RAM IOSmi
Pri emulovaní sieťových zariadení je značne limitujúcim faktorom aj veľkosť RAM na PC. Tu je
možné nastavovať rôzne hodnoty pre konkrétnu platformu. Žiaľ množstvo pridelenej RAM sa nedá
znižovať do nekonečna. Ak zmenšíme veľkosť RAM príliš, zariadenie pri bootovaní vypíše chybu,
alebo sa jednoducho zasekne a nenabootuje. Pri všetkých vyššie zmienených IOSoch sme overili plnú
funkčnosť pri veľkosti RAM 128 MB. O samotné spravovanie RAM sa stará proces dynamips-wxp. Na
efektívnejšie využitie viacjadrových systémov sa naraz spustí viacero procesov dynamips-wxp. Pri
spustení 17 IOSov sme mali spustených 7 procesov, ktoré spolu využívali 1111MB RAM. Jeden proces
mal prednastavené používanie maximálne 512 MB RAM. Keďže používame menej, ako 8 jadrové
systémy, skúsili sme nastavit ako limit jedného procesu 768 MB RAM. V takomto prípade sme
používali rovnako 7 procesov a dokonca až 1177 MB RAM. Tu sme overili, že na nastavení limitnej
hodnoty nad 512 MB RAM pre jeden dynamips proces sa jeho správanie nemení. Pri pokusoch sme
zaznamenali využitie jedným procesom najviac 330 MB RAM.
V projekte sme využili znalosti z tejto analýzy a k vybraným IOSom sme už len dopočítali
špecifické idlePC hodnoty.
V ďalšej časti si povieme, aké skripty sú vo VLABe využité.
2.6.1 Spúšťacie skripty Skripty majú za úlohu vytvoriť potrebné podmienky na spustenie programu dynamips a
fungujú nasledujúcim spôsobom.
Cez webové rozhranie spustíme simuláciu. Ako vstupné údaje programu pre pošle tieto
údaje: id simulácie, dĺžku simulácie, login užívateľa a jeho prihlasovacie heslo. Po obdržaní vstupných
údajov sa spustí skript startup.sh, ktorý nájde volný port a vytvorí nového užívateľa a vytvorí preňho
dočasné adresáre, do ktorých bude ukladať svoje súbory.
Po vytvorení nového užívateľského účtu sa spustí skript startup_user.sh, ktorý načíta z
databázy informácie o spustenej simulácií a z nich vytvorí konfiguračný súbor pre program dynamips
a zároveň vytvorí xml súbor, ktorý sa nám zobrazí na webovej stránke. V tomto xml súbore budú
uložené informácie o danej simulácií. Potom skript pustí program dynamips a program pemu.
Nakoniec skript skontroluje, či bol program dynamips spustený a do databázy uloží, že práve
prebieha daná simulácia.
Potom sa spustí skript create_users.sh, ktorý pre každé nami emulované zariadenie vytvorí
užívateľský účet a domovský adresár. Zároveň pre každého užívateľa nastaví cpu limit.
13
Na záver sa spúšťa skript shutdown.sh. Skript má za úlohy zabiť všetky programy, ktoré sme
spustili počas danej simulácie. Zároveň vymaže všetkých užívateľov, ktorých sme vytvorili pre potrebu
danej simulácie a vymaže ich adresáre. Nakoniec ešte raz skontroluje či zabil všetky programy a ak
nie tak ich zabije ešte raz.
Skript test.sh je špeciálny skript určený na testovanie. Robí to isté čo skript startup.sh, len s
tým rozdielom, že ho spúšťame z konzoly.
Podrobnejší opis skriptov, ako fungujú je opísaný nižšie.
startup.c
Program sa spúšťa cez webovú rozhrania stlačením tlačítka start lab. Úlohou programu je len
spracovať vstupné dáta, ktoré sme mu poslali a spustiť skript startup.sh a predať mu tieto vstupné
dáta. Program dostáva tieto vstupné údaje: id_simulacie, dlzka_simulacie, login, heslo (hash)
env.sh
Sem boli presunuté definície premenných prostredia pre skripty.
header.sh
V skripte header.sh sú inicializované premenné a dve funkcie find_free_port() a
find_start_port(). Úlohou týchto dvoch funkcií je nájsť volný port a obidve fungujú na rovnakom
princípe. Spustia program netstat a skontrolujú, či je nami definovaný port (7500) voľný. Ak nie
pripočítajú k nemu jednotku a znova skontrolujú, či ja daný port volný. Takto funkcie pokračujú kým
nenájdu voľný port.
startup.sh
Skript zavolá funkciu find_start_port() a skontroluje, či mu boli poslané všetky vstupné
parametre. Ak áno vytvorí nového užívateľa pre túto simuláciu a zároveň mu vytvorí aj dočasné
adresáre a nastaví im potrebné oprávnenia.
Potom skontroluje, či mu bol poslaný piaty nepovinný parameter TEST. Ak áno spustí príkaz
/usr/bin/sudo -H -u “$RUN_USER” $STARTUP $START_PORT $CONF_ID FORE
a otestuje návratovú hodnotu. Pričom: $RUN_USER - užívateľ $STARTUP - startup_user.sh
$START_PORT - číslo portu $CONF_ID - id simulácie Ak nebol zadaný piaty nepovinný parameter
spustí iba príkaz:
/usr/bin/sudo -H -u "$RUN_USER" $STARTUP $START_PORT $CONF_ID
Na záver skript startup.sh spúšťa na pozadí ešte tieto skripty create_user.sh a shutdown.sh
startup_user.sh
Skript na začiatku vytvorím dočasné súbory a pripojí sa do databázy, kde hľadá id práve
spustenej simulácie. Potom postupne prechádza výstup, ktorý sme získali z databázy a vytvára z neho
14
xml súbor, ktorý sa nám zobrazí na stránke. Zároveň vytiahne z databázy aj konfiguračné súbory pre
dynamips, ktorý následne spustí na pozadí. Ak bolo nastavené, aby sa spustil program pemu, tak ho
spustí. Potom pomocou programu netstat skontroluje či program beží na pridelenom porte, ak zistí
že nič na danom porte nebeží, tak počká 20s a ak stále na kontrolovanom porte nič nebeží uvolní
zdroje a ukončí program s chybou. Ak mu bol pridelený port pokračuje ďalej v programe. Pred
koncom skript ešte skontroluje, či bol spustený v testovacom móde a ak áno spustí program
dynagen_wrapper. Na záver skript aktualizuje databázu.
V databáze aktualizuje práve bežiacu simuláciu. Nastaví že je momentálne aktívna, meno
užívateľa a zariadenie, ktoré momentálne simuluje.
create_users.sh
Skript vytvorí pre každé simulované zariadenie jedného užívateľa a zároveň pre každého
užívateľa nastaví maximálny cpu_limit.
shutdown.sh
Skript najprv skontroluje svoje vstupy a potom spustí skript config.sh. Potom sa uspí na čas,
ktorý bol nastavený v premennej dĺžka simulácie. Po prebudení hľadá programy spustené pod daným
užívateľom a vypína ich. Potom zmaže dočasné súbory daného užívateľa a nakoniec vymaže aj
daného užívateľa. Na záver sa na chvíľu uspí a potom sa pokúša ukončiť súbory, ktoré zostali visieť.
config.sh
Skript skontroluje svoje vstupy, či mu boli zadané správne premenné, ak nie tak skonči. Skript
potom prehľadáva dočasný priečinok, kde hľadá informácie o routroch, ktoré potom uloží do
databázy.
pemulimit.sh
Skript nastaví cpu limit pre pemu.
test.sh
Je to pomocný skript, robí to isté, čo skript startup.sh len sa spúšťa z konzoly.
firewall.py
aby script firewall.py fungoval je potrebne aby pred jeho spustením
mal adresár web/ práva na zápis pre vlastníka (alebo aspoň existoval aj keď prázdny súbor
web/.htaccess s takýmito právami) a aby bol script firewall.py spúšťaný s právami tohto používateľa.
Takisto treba zabezpečiť aby tento istý používateľ mohol zapisovať do súboru /etc/ssh/sshd_config a
aby mohol spustiť /etc/init.d/sshd reload. V našom prípade išlo o používateľa www-data.
Script firewall.py sa súšťa vždy buť s parametrom 'on' alebo 'off', inak sa nič nevykoná.
Parameter 'on'
-select
-vygenerovanie .htaccess (akého)
15
-vytvorenie sshd_config z sshd_config.template
-reload sshd
Parameter 'off'
-vygenerovanie .htaccess (akého)
-vytvorenie sshd_config z sshd_config.template
-reload sshd
16
Obrázok 3.: Súvislosti spúšťacích skriptov
17
3 Návrh
Našou základnou ulohou bolo pripraviť VLAB, aby ho mohli používať študenti FIIT. Prvotnou
ideou bolo, že základ VLABu je funkčný, a mi sa hneď zameriame na nami navrhnuté rozšírenia. Hneď
na úvod sme zistili, že samotný VLAB nefunguje a nedá sa do neho korektne prihlásiť, následne sme
zistili, že pôvodný projekt bežiaci na stroji Xena, už nie je aktívny. Z toho dôvodu sme ho museli
vybudovať odznova. Na to sme samozrejme použili dokumentáciu a pôvodné skripty zo starších
tímových projektov a diplomových prác.
Na úvod sme si prácu rozdelili do týchto piatich krokov:
- Získanie nového virtuálneho stroja - Analýza predchádzajúcich verzí VLABu - Analýza možnosti systému Dynamips - Nainštalovanie operačného systému a potrebných aplikácií - Nahratie a nastavenie potrebných skriptov a frontend aplikácií
Jednotlivé body sme si rozdelili podľa skúseností a schopností členov tímu. Toto malo najmä
za účel plne využiť potenciál členov tímu a hlavne rozdeliť prácu, aby sa jednotlý členovia neblokovali.
Samotné zriadenie virtuálneho stroja prbiehalo takmer bezproblémovo, za čo vďačíme
pánovi Steinmüllerovi. Snažili sme sa získať stroj s čo možno najväčším množstvom RAM. Aktuálna
dohoda je taká, že nám dal toľko RAM, koľko mal starý stroj - 2GB, a keď budeme potrebovať viac
pamäte, skúsime sa dohodnúť. Týmto sme splnili bod jeden a mohli sme pokračovať na nadvezujúce
body 4 a 5.
Po získaní vlastného virtuálneho stroja sme mohli začať budovať nový VLAB. Keďže chceme
starý VLAB vylepšiť, našou jedinou šancou, aby sme nemuseli budovať všetko nanovo a teda sa pri
obrovskej snahe dostať sotva na úroveň zo zimy 2009, bolo získať čo možno najviac materiálov
zo starších projektov a zlúčiť ich s našim projektom. Kvôli bezpečnostným politikám na FIIT sme
museli oficiálnou cestou požiadať o prístup na stroj, kde bežal frontend starého VLABu. Tu sme sa
narazili na veľký sklz, keďže bývali administrátor je v zahraničí.
Aby sme splnili pôvodný plán mať funkčný prototyp na konci siedmeho týždňa semestra,
museli sme paralelne spustiť snahu o vlastný VLAB, bez prístupu k pôvodnému. Paralelne sme
nainštalovali operačný systém na virtuálny stroj a na pracovné stanice členov tímu. Tak sme si
rozdelili prácu a na hlavný server sa aplikovali len overené a potrebné zmeny, respektíve aplikácie.
V bode 2 sme sa sústredili na predchádzajúce verzie VLABu. Pri tomto sme využili staršie
dokumentácie a ako je už spomenuté, chceli sme využiť aj pred časom fungujúcu implementáciu.
Keďže vybavenie prístupu do stroja s frontendom VLABu trvalo o veľa dlhšie, ako sme pôvodne
zamýšlali, sprvu sme sa sústredili na sfunkčnenie backendu. Samotné kroky sú popísané v časti
analýza Sfunkčnenie nového VLABu.
18
V bode 3 sme analyzovali, ako možno zefektívniť chod emulovaných zariadení. Pod tým si
môžme predstaviť minimalizáciu používaných systémových prostriedkov: RAM a CPU. O tomto bližšie
hovorila časť Dynamips idlePC hodnota v analýze.
V ďalších častiach práce sa budeme venovať aplikácií navrhnutých zmien a rozšírení. Ako
priority sme si určili nasledujúce:
3.1 Podpora IPv6
Analýza ukázala, že systémy Cisco IOS majú zabudovanú podporu IPv6 už niekoľko rokov, čo
bolo overené testovaním aj na verziách IOS použitých vo VLAB.
User-Mode Linux (UML) jadro použité v pôvodnej verzii VLAB bohužiaľ túto podporu nemá.
Jadro je verzie 2.6.23, ktoré má možnosť podpory IPv6, preto bude nutné vytvoriť nové jadro, ktoré
bude mať túto podporu.
Systém, ktorý UML jadro používa, obsahuje iba program ifconfig, ktorý je nedostatočný pre
konfiguráciu IPv6 a často aj IPv4, preto bude nutné tiež pridať nový balíček nástrojov ip.
Pretože sa jedná iba o zmenu verzie IP protokolu, čo sa nedotkne vyšších ani nižších vrstiev,
mali by byť pôvodné laby použiteľné s oboma verziami IP protokolu.
3.2 Zobrazenie a vyťaženie CPU a RAM
Ako bolo písané v analýze, na získanie údajov o vyťažení CPU a RAM použijeme program ps.
Vhodnými prepínačmi si upravíme výstup programu, aby zobrazoval údaje o všetkých procesoch
v systéme.
vlab:~$ ps aux USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.0 0.0 8352 696 ? Ss Nov01 0:05 init [2] root 2 0.0 0.0 0 0 ? S Nov01 0:00 [kthreadd] root 3 0.0 0.0 0 0 ? S Nov01 0:00 [migration/0] root 4 0.0 0.0 0 0 ? S Nov01 0:00 [ksoftirqd/0] root 5 0.0 0.0 0 0 ? S Nov01 0:00 [watchdog/0] ... postfix 9436 0.0 0.1 39224 2292 ? S 10:12 0:00 pickup -l -t fifo -u -c www-data 14068 0.0 0.3 185072 6788 ? S 06:25 0:00 /usr/sbin/apache2 -k start ...
19
Z výpisu možno vyčítať, koľko percent prostriedkov (stĺpce %CPU a %MEM) proces (stĺpec
COMMAND) používateľa (stĺpec USER) využíval.
Zo získaných údajov si vieme spočítať celkové vyťaženie procesora a pamäte (v percentách)
jednoduchým súčtom ich využitia jednotlivými procesmi:
vlab:~$ ps aux | awk '{SUMC += $3; SUMM += $4} END {print "CPU:"SUMC"% MEM:"SUMM"%"}' CPU:0% MEM:4.1%
Takto získané údaje možno ukladať do súboru pre neskoršie spracovanie. Týmto spôsobom sa
vytvorí aj databáza predošlých meraní. Samotná postupnosť hodnôt nám však nič nepovie o čase v
ktorom boli namerané. Preto je potrebné okrem údajov o vyťažení prostriedkov uchovávať aj čas
merania. Ten získame pomocou príkazu date. Jeho výstup zmeníme do tvaru Unixového času (počet
sekúnd od 1.1.1970) Výsledný príkaz a výstup bude vyzerať nasledovne:
ps aux | awk '{SUMC += $3; SUMM += $4} END {print systdate +'%s'")" "SUMC" "SUMM}' | tr "\n" " "
| awk '{print $1" "$3" "$4}'
1289416474 32.2 10.7
Po presmerovaní výstupu do súboru (>> cpuram.dat) získame obraz o vyťažení prostriedkov v
čase. Pravidelné spúšťanie zabezpečíme programom cron. Pomocou programu GNUPlot údaje zo
súboru vieme pretransformovať na graf vo formáte PNG. Graf vygenerujeme príkazom:
gnuplot meraci_skript.gs
Formát súboru skriptu meraci_skript.gs bude mať potom obsah:
# # generovany grafu # set terminal png size 1200,250 set output "cpuram.png" set xlabel "Cas" set ylabel "Teplota [C]" set xdata time set timefmt "%s" set format x "%d.%m.%Y\n%H:%M:%S" plot "cpuram.dat" using 1:2 title "CPU" with lines, "cpuram.dat" using 1:3 title "RAM" with lines
3.3 Zjednodušenie inštalácie
Na základe analýzy súčasného stavu sme sa rozhodli toto zjednodušenie realizovať upravením
vnútornej štruktúry VLABu a prerobením samotného postupu inštalácie.
Upravenie vnútornej štruktúry VLABu
20
Tu by sme chceli oddeliť dáta od zdrojových súborov VLABu, ale aj nahradiť všetky absolútne
cesty s relatívnymi alebo konfigurovateľnými, v závislosti od častí projektu, ktorých sa to týka. Okrem
iného to bude mať za dôsledok, sprehľadnenie systému, ako aj možnosť mať zduplikovaný systém
umiestnený v inej adresárovej štruktúre. Taktiež nám tento bod umožní, že aj keď nebudeme
distribuovať Cisco IOS spolu s VLABom (čo je proti licencií), bude na prvý pohľad jasné kam ho treba
nakopírovať.
Upravenie postupu inštalácie
V súčasnosti síce existuje niekoľko Inštalačných príručiek, no ani jedna nie je aktuálna. Preto by
sme chceli spísať aktuálne závislosti projektu na balíčky linuxovej distribúcie Debian, ako aj na
knižnice ktoré nie sú dostupné ako balíčky. Taktiež je potrebné spísať, ako ktorú čas» nainštalovať,
prípadne čo je potrebné na jej kompiláciu. V neposlednom rade by sme chceli čo do možno najväčšej
miery tento proces zautomatizovať pomocou inštalačného skriptu.
3.4 Sfunkčnenie starého VLABu
Projekt VLAB má už viacročnú históriu. Ide o projekt, na ktorom už pracovali dva rôzne tými na
predmete Tímový projekt. Taktiež na tomto projekte pracoval aj ing. Peter Péti vo svojej diplomovej
práci. Výstupom týchto snažení sú okrem iného 3 dokumenty, v ktorých sú podrobné analýzy
jednotlivých častí VLABu.
V diplomovej práci ing. Pétiho ako aj v dokumentácií tímu č. 9 zo školského roku 2008/2009 sú
aj inštalačné príručky VLABu. Aj keď sú tieto dva dokumenty najnovšie, po krátkej analýze sme však
zistili, že nie sú najaktuálnejšie nakoľko boli na tomto projekte robené úpravy aj po odovzdaní týchto
dokumentov. Podľa informácií vedúce projektu ing. Grellnetha, PhD. išlo hlavne o opravy chýb, ktoré
boli odhalené pri používaní projektu študentami. Išlo o nezdokumentované úpravy a existovali iba na
nasadenom VLABe na školskom serveri, no počas analýzy nám bolo povedané, že tento server je už
nejakú dobu zrušený, a nebolo jasné či existuje nejaká záloha. Na základe toho sme sa rozhodli, že
rozchodíme VLAB podľa inštalačnej príručky z diplomovej práce, nakoľko bola podľa nás
najkvalitnejšia. Táto inštalačná príručka bola pre linuxovú distribúciu Gentoo no my sme sa rozhodli,
že my budeme VLAB vyvíja na linuxovej distribúcií Debian. Preto sme nemohli použiť postup na
nainštalovanie balíčkov, ktoré projekt VLAB používa, opísaný v Inštalačnej príručke a táto príručka
nám v tejto časti slúžila iba na sprehľadnenie závislostí VLABu. Po nainštalovaní týchto balíčkov sme
však narazili na niekoľko problémov o ktorých sa žiadna z Inhalačných príručiek nezmieňovala. Na
vyriešenie týchto problémov nám nepomohlo ani podrobnejšie preštudovanie všetkých dokumentov,
ktoré naši predchodcovia napísali. Približne v tom istom čase sme sa ale dostali k zálohe zo servera na
21
ktorom VLAB fungoval v podstatne novšej verzií. Následne sme sa rozhodli, že sa nebudeme snažiť o
sfunkčnenie starej verzie VLABu, ale budeme pracovať iba s verziou ktorá bola na zálohe zo servera.
3.5 Vyhodnocovanie labov
Na základe analýzy sme sa zhodli, že jeden spôsob kontroly a vyhodnocovania nie je
postačujúci, a preto bude vhodné, ak použieme ich kombináciu. Pri všetkých spomínaných spôsoboch
okrem priameho vyhodnocovania konfiguračných súborov je protrebné nejakým spôsobom
komunikovať s emulovanými zariadeniami. Pre toto sa nám ako najvhodnejšie riešenie javí použitie
takzvaných chat skriptov. [5] Tieto nám umožnia riadiť komunikáciu so zariadením, a to tak, že si
vytvoríme stavový automat, v ktorom sa budeme na základe rôznych odpovedí zo strany zariadenia
rozhodovať, aký príkaz mu dáme, respektíve nedáme vykonať. Tento spôsob síce nie je
najjednoduchší, no vieme sa pomocou neho vysporiadať s rôznymi stavmi, v ktorých sa môže
zariadenie nachádzať pred samotným testovaním, alebo v ktorých sa môže ocitnúť počas testovania.
Chat skripty sú implementovnané vo viacerých programovacích a skriptovacích jazykoch a Cisco ich
uvádza ako jednu z možností pre konfiguráciu modemov. [6]
22
4 Návrh systému
Architektúra systému sa skladá z troch častí, z frontendu, backendu a databázy. Frontend
predstavuje webové rozhranie z ktorého sa ovláda celý VLAB. Webové rozhranie sa skladá zo štyroch
modulov: rezervácia, simulácia, zápočtovkový modul a firewall. Rezervačný modul a simulačný
modul už existovali v starom systéme. Do nového systému sme do implementovali zápočtovkový
modul a firewall modul. Backend tvoria pythonové skripty určené na spúšťanie simulácií a testovania
zápočtoviek. Backend aj fronted sa pripájajú k databáze a ukladajú do nej svoje údaje. Externý klient
sa potom pripojuje k frontendu.
Obrázok 4 Architektúra systému
Na nasledujúcom obrázku je zobrazený model vykonania zápočtovky.
23
Obrázok 5 Vykonanie zápočtovky
Študent
Pre používateľov z rady študentov sme doplnili alebo upravili nasledujúcu funkcionalitu:
24
Obrázok 6: Use case - študent
Resetnutie hesla – má formu známu z komerčných služieb. Po zabudnutí hesla si používateľ vyžiada
nové, ktoré mu je zaslané na email. S novým heslom sa môže ihneď prihlásiť.
Začiatok testu – študent sa pred zápočtovkou prihlasuje pomocou dočasného hesla. Pre začatie
z testu je nutné spustiť test, po čom sa začne odpočítavať čas priradený na zápočtovku.
Vyhodnotenie konfigurácie – študent si môže po, alebo počas konfigurovania klasickej simulácie, nie
testu, vyhodnotiť svoju konfiguráciu. Toto sa robí pomocou tlačidla Test lab. Študent dostane
informáciu o priebežných bodoch a výpis s testovanými príkazmi.
Písanie testu – študent má možnosť pomocou VLABu písať test. Test môže byť buď zápočtovkový,
skúškový prípadne aj v rámci rôznych súťaží.
Ukončenie testu – po skončení testu študent test ukončiť. To sa deje buď po stlačení tlačidla na to
určeného alebo po vypršaní časového intervalu priradeného na test. Študentovi sa po refreshi
stránky zobrazí výsledok so získanými bodmi a percentami.
Učiteľ
Pre používateľov z rady učiteľov sme doplnili alebo upravili nasledujúcu funkcionalitu:
25
Obrázok 7:Use case - učiteľ
Import študentov – učiť zo zoznamu študentov vo formáte .csv importuje študentov, týmto
študentom sa priradí jedinečný login, vytvorí im heslá a priradí ich do tried. Existujúcich študentov iba
zaradí do aktuálnej triedy.
Export študentov – Učiteľ pre účely testu exportuje zoznam používateľov s ich dočasnými heslami vo
formáte .pdf – tieto sú určené na vytlačenie a rozdanie pre študentov na začiatku písania testu.
Zobrazenie prihlasovacích údajov – pred testom je možné zobraziť zoznam študentov vo frontende.
Vytvorenie triedy – pre formát importu sme upravili možnosť vytvorenia triedy.
26
Zaradenie študenta do triedy – pre potrebu importu používateľov sme doplnili možnosť ich
hromadne zaradiť do zvolenej triedy.
Znovunačítanie konfigurácie z testovania – v prípade nespokojnosti študenta s hodnotením z testu, je
možné znovu načítať jeho konfiguráciu a tým sa uistiť o správnosti vyhodnotenia.
Vytvorenie úrovni študentov – počas importu sa pre triedy zvoli okrem zoznamu študentov aj ich
úroveň. Podľa úrovne je umožnený prístup k labov pre jednotlivé úrovne.
Vytvorenie labu – učiteľ môže vytvoriť lab. Toto je možné spraviť priamo z frontendu. Na tieto účely
učiteľ zadá konfiguríciu topológie, znenie zadania a príkazy testovania.
Vytvorenie testovania – Pre účel rýchleho overenia konfigurácie učiteľ vytvorí testovanie. Toto je
použité počas simulácie ako aj pri písaní testu. Práve toto testovanie sa zadáva pri písaní labu.
Nastavenie firewallu – pre zvýšenie bezpečnosti a zabezpečenie prístupu k písaniu testu len na určitú
miestnosť sa pred testom vytvorí pravidlo pre prístup k labu. Toto slúži na zabránenie prípadným
pokusom o písanie zápočtovky z iných ako vyhradených priestorov.
Vytvorenie testu – učiteľ musí po vytvorení testovania vytvoriť test, v ktorom špecifikuje jeho
parametre ako názov testu, dátum konania testu, maximálne získateľné body a zoznam študentov,
ktorý môžu písať test.
Spustenie testu – pre zablokovanie zdrojov na účely testovania je nutné spustiť test.
Ukončenie testu – po skončení testu môže učiteľ pred vypršaním časového limitu ukončiť test. Tento
je v prípade vypršania časového limitu ukončený automaticky. Po skončení testu sa uvolnia
rezervované prostriedky.
Administrátor
Administrátor má oproti učiteľovi len práva vytvoriť užívateľa s administrátorskými právami. Pre
používateľov z rady administrátorov sme doplnili alebo upravili rovnakú funkcionalitu ako pre
užiteľov:
27
Obrázok 8: Use case - administrátor
28
5 Implementácia
5.1 Výber implementačného jazyka a prostredia
Projekt pozostáva z dvoch častí z frontendu a backendu. Pôvodná časť frontendu bola
implementovaná v php. Pretože frontend predstavuje webové rozhranie rozhodli sme sa ďalej
používať php ako implementačný jazyk pre frontend.
Backend bol pôvodne implementovaný v bash skriptoch. Tieto skripty sa nám zdali
nevyhovujúce a neprehladné, preto sme sa rozhodli celý backend prepísať do jazyka Python. Týmto
sme podľa nás zvýšili prehľadnosť riešenia. Pre Python sme sa rozhodli hlavne pre jeho výhody pri
práci s textom. Túto jeho vlastnosť sme využili hlavne pri vyhodnocovaní textových reťazcov z
konfigurácie smerovačov.
29
5.2 Opis realizácie
V nasledujúcich častiach si popíšeme, čo všetko sme spravili počas implementácie.
5.2.1 Webové rozhranie
Vylepšili sme systém rezervácií vlabu. Pôvodný systém, bol navrhnutý tak, že užívateľ si
mohol rezervovať vlab vždy len hodinu dopredu. Ak si užívateľ chcel rezervovať aktuálnu hodinu
mohol využiť už existujúcu funkciu v systéme, pomocou ktorej si mohol rezervovať aktuálne bežiacu
hodinu. Nevýhodou tohto riešenia bolo to, že mal na prácu k dispozícií len aktuálnu hodinu. Toto
riešenie bolo dosť obmedzujúce, lebo ak sa užívateľ napr. prihlásil do systému o pol druhej a zistil, že
na daný deň si nikto nič nerezervoval tak mal na výber dve možnosti: buď počkať pol hodinu do celej
hodiny, alebo si rezervovať aktuálnu hodinu pričom po polhodine by sa mu simulácia automaticky
zrušila. Toto obmedzenie sme odstránili a upravili tak, že teraz si užívateľ môže normálnym
spôsobom rezervovať napr. dve hodiny pričom začiatok rezervácie si bude môcť nastaviť od aktuálne
bežiacej hodiny do jej 50 minúty. Od 51 minúty už nebude mať možnosť si rezervovať aktuálnu
hodiny a bude si môcť za rezervovať až ďalšiu hodinu.
Systém rezervácií sme ešte rozšírili aj o možnosť rezervovať si hodiny na prelome dňa. V pôvodnom
systéme sme si nemohli rezervovať 23 hodinu, čo môže byť pre niektorých študentov dosť
obmedzujúce. Preto sme rezervačný systém vylepšený tak, že ak má napr. užívateľ možnosť
rezervovať si 6 hodín a dal si začiatok rezervácie na 22:00 tak sa mu automaticky sprístupní možnosť
dať si koniec rezervácie na 4:00. Ak ma k dispozícií len 3 hodiny tak sa mu zobrazí nastaviť si koniec
rezervácie len 1:00. Doteraz študent tu možnosť nemal a mohol si rezervovať systém len do polnoci a
kvôli tomu sa mu po polnoci simulácia automaticky vypla.
Kvôli testovania študentov sme potrebovali možnosť naimportovať študentov z externého súboru.
Pôvodný systém už obsahoval možnosť importovania užívateľov s externého súboru, len tento
systém pracoval s iným formátom externého súboru a mi potrebujeme pracovať s formátom, ktorý
nám vrátil systém ais. V aise vyberieme nasledujúci typ zobrazenia: FIIT – Zostava pre učiteľov –
ID,ročník , ktorý ma nasledujúci formát:
;Celé meno s titulmi;ID;Identifikácia štúdia;Roč.
1.;Jožko Mrkvička;595;FIIT B-PKSS den *sem 4, roč 3+;3
Kvôli tomu sme museli implementovať vlastnú verziu importu, ktorá bude vedieť pracovať s
nasledujúcim formátom. Pri importovaní musíme ešte dodatočne nastaviť 4 parametre a to typ
30
kódovania, oddeľovací znak, level študenta a kurz študenta. Základné nastavené parametre sú
nasledujúce: typ kódovania – „WINDOWS – 1250“, oddeľovací znak - „;“ , level študenta - „PS2“ a
kurz študenta - „-“. Prvé dve hodnoty sú v systéme napevno nastavené. Ďalšie hodnoty môže užívateľ
v systéme podla potreby meniť. Najdôležitejšia hodnota je kurz študenta lebo podľa tejto hodnoty sa
filtrujú študenti na zápočtovku. Systém automaticky pri importe vygeneruje prihlasovacie meno,
heslo a email daného študenta. Vygenerované údaje majú nasledujúci tvar:
Meno heslo email
595_mrkvicka mj595 [email protected]
Heslo sa generuje nasledujúcim spôsobom. Prvé písmeno z priezviska, mena a ID číslo študenta.
Heslo ma naschvál taký ľahký tvar aby sa študent vedel bez problémov pri prvom prihlásení prihlásiť a
mohol si ho podla vlastného uváženia bez problémov zmeniť. Hesla sa potom pre každú zápočtovú
písomku generujú osobitne, podrobnejšie je to vysvetlené v inej časti dokumentu. Ak užívateľ
zabudne svoje heslo má možnosť automatický si ho pre poslať na mail. Pretože heslá sú v databáze
šifrované tak nepoznáme pôvodné heslá. Preto keď užívateľ zabudne svoje heslo a rozhodne poslať si
nové na mail tak sa mu automaticky vygeneruje nové heslo, ktoré sa automaticky pošle užívateľovi a
uloží sa do databázy. Možnosť poslať si nové heslo sa užívateľovi zobrazí až po prvom neúspešnom
prihlásení.
Do vlabu sme implementovali ešte jednouché fórum, ktoré môžu využívať učitelia na posielanie
dôležitých správ, alebo tipov pre študentov a študenti ho môžu využiť v prípadoch keď sa budú chcieť
s niekym poradiť.
Frontend pre modul firewall slúži na nastavovanie rozsahu ip adries, ktoré budú blokované. V tomto
module môžeme pridávať rozsahy ip adries ktoré budú blokované pričom pri pridávaný nových ip
adries sa automaticky skontroluje či vložená ip adresa je platná. Ak vkladaná ip adresa nebude platná
tak užívateľ bude na to upozornený a daný rozsah ip adries sa neuloží do databázy. Užívateľ má
možnosť si už uložené rozsahy ip adries pozrieť s editovať ich, alebo vymazať z databázy.
5.2.2 Funkčné vyhodnocovanie
Pre kontrolu správneho nakonfigurovania siete ako celku, sú veľmi užitočné diagnostické nástroje ako
napríklad ping pre kontrolovanie stavu liniek alebo stavu samotných sieťových zariadení. Zazívame
toto testovanie “funkčné vyhodnocovanie.” Pre spúšťanie jednotlivých diagnostických nástrojov je
potrebné mať prístup k spusteným nakonfigurovaným zariadeniam. Pre tento účel sme si vybrali
31
protokol RSH. Spôsob pripájania k týmto zariadeniam cez protokol RSH je popísaný v kapitole
“Pripojenie k IOS pre testovanie zadaní”.
Vstup
Vstupom pre funkčné vyhodnocovanie je ten istý vstupný súbor ako pri vyhodnocovaní skriptom a
číslo portu na ktorom je testované zariadenie dostupne a z ktorého sa dá vypočítať jeho IP adresa na
ktorej má nakonfigurovaný vzdialený prístup. Riadky ktoré predpisujú funkčné vyhodnocovanie sa
skladajú so šiestich zložiek, čo je rovnaký počet ako pri riadkoch určených pre vyhodnocovanie
skriptom, význam niektorých zložiek je iný:
Č;F;názov;príkaz;popis_výstupu;váha
* Č - číslo riadku/podúlohy - potrebné pre vyhodnotenie komplexnejších úloh
* F - hodnota F určujúca či že sa jedná o funkčné vyhodnocovanie
* názov - názov podúlohy, ktorý sa zobrazí študentovi pri vyhodnotení
* príkaz - píkaz ktorý sa má vykonať, ako napríklad "ping <ip>" alebo "show ip route"
* popis_výstupu - popisu správneho výstup z príkazu. V pripade ak sa popis zkladá z viacerých častí sú
tieto oddelené znakom "," (čiarka)
* váha – ohodnotenie
Najväčšia zmena je v piatej zložke, ktorá popisuje správny výstup z príkazu. Výstup jedného
kontrolného príkazu sa môže skladať z viacerých hodnôt, ktoré chcem skontrolovať. Rozhodli sme sa
túto zložku rozdeliť na viacero častí, ktoré sú navzájom oddelené znakom ”,” (čiarka).
Príklady:
Riadok vstupného súboru predpisujúceho príkaz “ping”:
12;F;ping z R1 na R2;ping 192.168.1.4;1;2
kde sú zaujímavé hlavne posledné tri zložky. Zložka “ping 192.168.1.4” je príkaz ktorý sa má vykonať.
Ďalšia zložka (číslo 1) je popis výstupu, čo pri príkaze ping znamená, že ak sa má vyhodnotiť ako
úspešný, musí byť jeho úspešnosť vyššia ako číslo v tejto zložke. Poslednou zložkou je číslo určujúce
ohodnotenie.
Riadok vstupného súboru predpisujúceho príkaz “show ip route”:
13;F;kontrola EIGRP routovania;show ip route;D,192.168.1.0/24,10.10.10.2;1
32
sa od predchádzajúceho príkladu líši hlavne v piatej zložke, ktorá popisuje výstup z príkazu. Môžeme
vidieť že sa skladá z troch častí, ktoré ako sme uviedli vyššie, sú oddelené čiarkou a na ich poradí
záleží. Tento popis hovorí, že na výstupe má byť záznam o ceste do sieti “192.168.1.0/24” naučenej
cez EIGRP (“D”) a pakety do tejto siete sa smerujú cez uzol “10.10.10.2”.
5.2.3 Konfigurácia VLAB
Konfigurácia skriptov VLABu je uložená vo formáte INI v týchto súboroch:
env.ini – obsahuje informácie o SQL databáze a prevážne cesty k dôležitým adresárom a programom,
cisco.ini – obsahuje nastavenia použité v nastaveniach topológie.
Webovú časť VLABu je možné konfigurovať pomocou súborov v adresári web/etc.
Syntax používaná v INI súboroch
Na riadku je možné definovať hodnoty vo formáte názov=hodnota. Takto definovanú konštantu je
možné použiť v iných definíciách pomocou zápisu %(názov)s, ktorý bude nahradený aktuálnou
hodnotou.
Riadky začínajúce mriežkou # sú komentáre a sú ignorované.
5.2.4 Základná konfigurácia
Väčšina nastavení v súbore env.ini nie je potrebné meniť, najdôležitejšie je nastavenie
databázy a niektorých ciest k dôležitým adresárom.
Tieto nastavenia umožňujú spustiť viacero nezávislých inštancií VLAB na jednom serveri, čo
bolo overené aj počas vývoja, keď bola nezávisle prevádzkovaná stabilná a vývojová verzia. Súbor
env.ini by mal začína deklaráciou sekcie *DEFAULT+, pretože hodnoty z nej môžu byť potom použité v
inom INI súbore.
Dôležité nastavenia:
MYSQL_USER – prihlasovacie meno do databázy
MYSQL_PASS – heslo do databázy
MYSQL_DB – meno databázy
PREFIX – cesta k inštalácii VLAB
CISCO – cesta k Cisco softvéru
33
TMP_DIR – cesta k adresáru, kde sa budú ukladať dočasné súbory simulácií
Ďalej je možné upraviť niektoré ďalšie cesty k adresárom, programom či výstupným súborom. Tieto
hodnoty neodporúčame meniť bez podrobnejšieho oboznámenie sa s infraštruktúrou systému VLAB.
Všetky možné nastavenia sú obsiahnuté vo vzorovom súbore env.ini.dist, ktorý má byť použitý pri
novej inštalácii VLAB a upravený.
Konfigurácia Cisco zariadení v topológiách
Tieto nastavenia sú načítané zo súboru cisco.ini. V tomto súbore je možné používať nastavenia zo
sekcie default súboru env.ini, takže je možné pohodlne meniť umiestnenie a topológie v databáze sa
tak stali nezávislé od adresárovej štruktúry projektu. Okrem cesty k image súboru je možné definovať
aj iné nastavenia topológie, týkajúce sa každého zariadenia používajúce konkrétny image:
[image 3640]
image = %(cisco)s/c3640.bin
ram = 128
rom = 4
nvram = 128
idlepc = 0x60564960
Takýmto spôsobom je možné jednoducho hromadne meniť viaceré nastavenia, obzvlášť užitočné je
nastavenie IdlePC, ktoré je závislé od konkrétneho stroja, na ktorom sa simulácie spúšťajú.
Okrem samotných nastavení image je možné definovať rôzne variácie nastavení pre rôzne zariadenia
s použitím toho istého image. Taktiež je tým zjednodušené testovanie týchto nastavení.
Nastavenie IdlePC sa dá jednoducho vyčítať pomocou telnetu na serveri pomocou dynagen konzoly,
ktorú špeciálne upravený dynagen spúšťa na porte pred prvým zariadením, ak je voľný. Ak tento port
nie je voľný, pokúša sa ho spustiť na portoch za posledným zariadením.
Konfigurácia webového rozhrania
V adresári web/etc/ sú viaceré súbory s nastaveniami.
Dôležitý je súbor db.etc.php, ktorý obsahuje nastavenie databázy:
<?
$etc['db']['server'] = 'localhost';
$etc['db']['user'] = 'vlab';
$etc['db']['password'] = '';
$etc['db']['dbname'] = 'vlab';
34
?>
Ďalej je nutné upraviť system.etc.php, ktorý obsahuje dôležitú cestu k skriptom:
$etc['scripts'] = '/srv/vlab/scripts';
Pre odhaľovanie chýb pri vývoji je možné tiež nastaviť logovanie (system.etc.php):
$etc['system']['debug_output']['exec'] = '/tmp/debug_exec';
$etc['system']['debug_output']['start'] = '/tmp/debug_start';
$etc['system']['debug_output']['kill'] = '/tmp/debug_kill';
Pripojenie k IOS pre testovanie zadaní
Cisco systémy IOS umožňujú povoliť prístup a vykonávať príkazy prostredníctvom RSH. Pre testovanie
správnosti zadania je nutné, okrem statickej kontroly uloženého konfiguračného súboru startup-
config, vykonať aj kontrolu stavu smerovača alebo test spojení príkazom ping.
Všetky topológie je nutné upraviť a pridať ďalší slot/port, cez ktorý sa budú dať posielať príkazy.
Každý smerovač pred spustením simulácie dostane vygenerovaný konfiguračný súbor, ktorý povolí
RSH a nakonfiguruje port.
Konfiguračný súbor pre smerovač bude približne takýto:
interface e2/0
description NECHYTAJ
ip address 10.29.79.1 255.255.255.0
duplex auto
speed auto
!
ip rcmd rsh-enable
username test privilege 15 nopassword
ip rcmd remote-host test 10.29.79.2 root enable
no ip rcmd domain-lookup
End
Tieto príkazy nakonfigurujú IP adresu podľa portu terminálu a povolia privilegované príkazy
používateľovi root z IP adresy 10.29.79.2. Menia sa len príslušné hodnoty IP adries a taktiež port/slot,
ktorý je použitý na testovanie. Tento port je nutné uviesť v konfigurácii topológie spolu s pridaným
slotom:
slot2 = NM-1E
35
# e2/0 = test_R1
Spúšťacie skripty sa postarajú o vygenerovanie príslušnej konfigurácie portu e2/0 a vytvorenie a
napojenie virtuálnej sieťovej karty. Druhý riadok je zakomentovaný, pretože to nie je valídne
nastavenie pre emulátor mipsim. Spúšťací skript ho nahradí informáciami o virtuálnej sieťovej karte,
ktorú vytvorí keď získa všetky potrebné informácie pre jej vytvorenie a nastavenie. Toto prepojenie je
docielené podobným spôsobom ako prepojenie emulovaných Cisco zariadení a User-Mode Linux
jadier použitím Virtual Distributed Ethernet. Rozdiel je, že miesto prepojenia navzájom sa jeden
koniec pripojí ako virtuálne sieťové zariadenie tap, ktoré je možné konfigurovať a používať rovnako
ako ozajstnú sieťovú kartu.
Pripojenie k UML Linux pre testovanie zadaní
User-Mode Linux v topológiách je upravený aby pri štarte vytvoril a nakonfiguroval ďalšiu sieťovú
kartu a umožnil pripojenie cez SSH. Toto sa deje automaticky a nie je nutné v topológiách nič meniť,
ako je to v prípade smerovačov.
Tento systém poskytuje namiesto RSH pripojenie cez SSH (program dropbear) a obsahuje kľúč,
pomocou ktorého sa testovací skript môže autentifikovať. SSH použitie hesla zo skriptu neumožňuje.
Prostredníctvom SSH je možne spúšťať akékoľvek potrebné príkazy pre kontrolu zadania, rovnako
ako v prípade IOS systémov.
Schéma IP adries pre testovanie
Všetky zariadenia sú prístupné cez telnet terminál, ktorý je na unikátnom porte, teda tento port
jednoznačne identifikuje spustené zariadenie. Porty môžu byť maximálne z rozsahu 16 bitov, ale pre
pre prehľadnosť sme zvolili schému vytvárania IP adries 10.a.b.1/24 pre zariadenie a 10.a.b.2/24 zo
strany servera. Čísla a a b sú 8-bitové, takže spolu môžu obsiahnuť maximálny možný počet zariadení.
Tieto čísla sa dajú jednoducho získať z čísla portu bitovým posunom (a) alebo aplikovaním masky či
operáciou modulo (b).
Táto schéma nám umožňuje mať v každom momente prístup na všetky zariadenia a ich siete nie sú v
žiadnom konflikte na strane servera.
Testovací LAB
36
Pre implementáciu akéhokoľvek vyhodnocovania sme si najprv navrhli nový LAB, v ktorom je
úlohou nakonfigurovať zariadenia podľa zadania. Tento LAB sme si vzorovo vyriešili a zanalyzovali
sme možnosti vyhodnocovania konfigurácií routerov. Nami navrhnuté zadanie:
Nakonfigurujte sieť, aby bol možný ping z PC0 na PC1. Na prislúchajúcich interfaceoch
pridajte popisy a IP adresy podľa obrázka a vhodne zvoleného subnetovania. Na rozsubnetovanie
použite nasledujúce údaje: Máte pridelený subnet 192.168.0.0/16, prideľujte najmenšie možné
subnety. Prvú možnú sieť prideľte na segment siete s PC0. Na tejto sieti je nutné mať priestor pre 254
počítačov aj s interfejsom na routri. Druhú voľnú sieť rovnako s 254 počítačmi (aj s interfejsom na
routri) pridelte na časť siete s PC1. Na interfesy routrov prideľte prvú voľnú adresu a na počítače
druhú voľnú IP adresu.
Medzi routrami nastavte sieť 10.10.10.0/30 RT1 s IP .1, RT2 s IP .2 Na linkách k počítačom
nemajú byť posielané update-y z IGP. Ako IGP použite EIGRP s číslom AS 5.
Routre nazvite podľa obrázka. V routovacej tabuľke musí byť cesta do cudzej siete naučená z
EIGRP.
5.2.5 Testovanie
Vyhodnocovanie labov sa vykonáva podľa definovaného súboru príkazov. Každý príkaz musí byť
na samostatnom riadku a výsledok vyhodnotenia je súčet bodov. Vyhodnotenie môže obsahovať aj
operátory (bloky), ktoré určujú spôsob počítania bodov v príkazoch. Operátory je možné do seba
vnárať a tým docieliť rôzne spôsoby vyhodnotenia a pokrytie rôznych situácií ako je napr. znížený
počet bodov za neúplné riešenia.
Body môžu mať aj desatinnú bodku, čo umožňuje vytvoriť testovanie s ľubovoľnou
granularitou bodovania. Súbor testovacích príkazov môže obsahovať prázdne riadky a komentáre
začínajúce mriežkou (”#”) a končiace koncom riadka.
37
Pre testovanie je nutné aby zariadenia, ktoré chceme testovať, mali v topológii definovaný testovacie
rozhranie.
5.2.5.1 Operátory
Operátory predstavujú bloky, ktoré sa vyhodnocujú v nadradenom operátore/bloku ako jeden príkaz
určitým spôsobom. Ich základná syntax je nasledovná:
operátor ! points=X
# príkazy alebo vnorené operátory (bloky)
end
Výkričníkom sa začína časť, ktorá obsahuje pomenované (keyword) argumenty a je nepovinná.
Operátor ''SUM''
Operátor SUM sčítava body podradených príkazov alebo operátorov a neprijíma teda žiadne
pomenované argumenty, preto je možné ju vynechať. Tento operátor sa implicitne aplikuje na
najvyššej úrovni súboru testovacích príkazov:
sum
# súbor testovacích príkazov, explicitný operátor SUM je nadbytočný
end
Príklad:
sum
conf Router1 hostname Router1 ! points=0.5
conf Router2 hostname Router2 ! points=0.5
end
Operátor ''AND''
Operátor AND aplikuje na príkazy operáciu logického súčinu. Tento operátor pridelí zadaný počet
bodov ak sa všetky príkazy vyhodnotia kladne. Počet bodov je nutné zadať pomenovaným
argumentom points, napríklad:
and ! points=5
38
# príkazy
end
Príklad:
# pridelí body iba ak oba hostname sú správne
and ! points=2
conf Router1 hostname Router1
conf Router2 hostname Router2
end
Operátor ''OR''
Operátor OR aplikuje na príkazy operáciu logického súčtu. Tento operátor pridelí zadaný počet bodov
ak sa aspoň jeden príkaz vyhodnotí kladne. Počet bodov je nutné zadať pomenovaným argumentom
points, napríklad:
or ! points=5
# príkazy
end
Vyhodnocovanie príkazov zámerne nie je skrátené (short-circuit) a vyhodnotia sa všetky
príkazy aj keď už niektorý bol vyhodnotený kladne.
Príklad:
# pridelí body ak jeden hostname je správne (študent preukázal znalosť nastavením jedného
hostname)
or ! points=2
conf Router1 hostname Router1
conf Router2 hostname Router2
end
Operátor ''MAX''
Operátor MAX vráti najvyšší dosiahnutý počet bodov. V tomto operátore je nutné definovať príkazom
bodové ohodnotenia. Kombináciou s ďalšími vnorenými operátormi je možné napríklad prideliť
znížené ohodnotenie za čiastočné riešenie.
max
39
# príkazy
end
Tento operátor neprijíma počet bodov pomocou pomenovaného argumentu, pretože sa vyhodnocuje
podľa bodových výsledkov podradených príkazov.
Príklad:
# pridelí maximálny počet bodov z príkazov (0, 1 alebo 2)
max
# ping susedného Router2 je za 1 bod
exec Router1 ping 172.16.0.2 ! points=1
# ping do siete za Router2 je za 2 body - predchádzajúci príkaz bude pravdepodobne splnený
tiež
exec Router1 ping 192.168.2.2 ! points=2
end
5.2.5.2 Príkazy
Každý príkaz musí byť na jednom samostatnom riadku a má nasledujúcu základnú syntax: <druh
testovania> <meno cieľového zariadenia> <príkaz a jeho argumenty> [! Pomenované argumenty]
Samotné príkazy sa často skladajú z viacerých častí, preto ak nejaký argument príkazu sa skladá z
viacerých slov oddelených bielymi znakmi (medzera, tabulátor), je nutné takýto argumentu uzavrieť
do úvodzoviek (”, '), prípadne escapovať znakom \ rovnako ako je to bežné v shelloch. Týmto sa dá
medzera alebo aj úvodzovky zahrnúť do jedného argumentu a nebudú rozdelené.
Argumenty v hranatých zátvorkách sú nepovinné, argumenty v lomených zátvorkách sú povinné. Tri
bodky značia, že argumentov môže nasledovať viac. Tak ako pri operátoroch platí, že výkričníkom sa
začína časť, ktorá obsahuje pomenované (keyword) argumenty a väčšina príkazov nepoužíva povinné
pomenované argumenty.
Všetkým príkazom je možné zadať pomenovaný argument points pre určenie počtu bodov pri
kladnom vyhodnotení. Implicitná hodnota je 0 bodov a vyhodnocuje sa iba úspešnosť príkazu.
5.2.5.2.1 Kontrola konfigurácie
Tieto príkazy začínajú kľúčovým slovom conf a kontrolujú iba obsah konfigurácie.
Všeobecná syntax riadku conf príkazu je:
40
conf <zariadenie> <príkaz> [! pomenované argumenty]
Príkaz ''HOSTNAME''
hostname [meno]
Príkaz hostname skontroluje či je nakonfigurované meno zariadenia. Pokiaľ je argument meno
vynechaný, podmienku spľňa akékoľvek nastavenie hostname. Argument je použitý ako regulárny
výraz.
Príklad:
conf Router1 hostname Router1
Príkaz ''SECTION''
section <sekcia> <nastavenie>
Oba argumenty tohto príkazu je nutné zvyčajne uzavrieť do úvodzoviek, pretože sa skladajú z
viacerých slov. sekcia označuje blok konfiguračného súboru, v ktorom sa má nastavenie vyskytovať.
Argumenty sekcia a nastavenie sa použijú ako regulárne výrazy.
Príklad:
# 1 bod za nastavený description
conf Router1 section "interface FastEthernet1/0" "description" ! points=1
Príkaz ''REGEXP''
regexp [výraz]
Hľadá či konfigurácia obsahuje riadok zodpovedajúci regulárnemu výrazu výraz.
Príklad:
# 1 bod za EIGRP s AS 5, vypíše správu "msg"
conf Router1 regexp router eigrp 5 ! points=1 msg="EIGRP correct AS n 5, Router1"
5.2.5.2.2 Kontrola stavu
41
Tieto príkazy začínajú kľúčovým slovom exec, čiže ide o príkazy vykonávané v spustenej simulácii a
závislé od aktuálneho stavu zariadení v simulovanej topológii.
Všeobecná syntax riadku exec príkazu je:
exec <zariadenie> <príkaz> [! pomenované argumenty]
Príkaz ''PING''
ping [argumenty programu] ...
Príkaz ping akceptuje voliteľný pomenovaný argument min, ktorý udáva minimálny percentuálnu
hodnotu, od ktorej sa príkaz považuje za úspešný. Implicitne je to 1, čiže každá nenulová hodnota je
vyhodnotená kladne. V prípade hostov je nutné zadať argument -c nasledovaný počtom odoslaných
ICMP Echo
Request správ, inak sa nikdy neukončí.
Príklad:
exec Router1 ping 192.168.1.2 ! points=0.5
exec Host1 ping -c5 192.168.1.1 ! points=0.5
Príkaz ''STATUS''
status <tabuľka> <argument> ...
Príkaz status kontroluje aktuálny stav zariadenia (a siete).
Tabuľka ''ip route''
status "ip route" <adresa> ! type=<typ>
Kontrola tabuľky ip route prijíma argument adresa, ktorý sa použije ako regulárny výraz. Pomenovaný
argument type udáva typ cesty, ktorý hľadáme, a je teda povinný. V prípade potreby je možné zadať
regulárny výraz, ktorý pokryje všetky typy, ktoré. Definované sú nasledujúce typy:
connected
static
rip
mobile
42
bgp
eigrp
ospf
candidate
Pokiaľ nemá žiadaný typ definíciu, je možné zadať priamo označenie, ktoré sa v tabuľke ip route
používa pre daný typ cesty. Rovnako je možné zadať typ aj pre definované typy, ale použitie vyššie
uvedených definícií uľahčuje čítanie testovacieho príkazu.
Príklad:
exec Router1 status "ip route" 192.168.1.0/24 ! type=EIGRP points=1
Tabuľka ''ip bgp neighbors''
status "ip bgp neighbors" ! ip=<adresa> as=<autonómny systém> type=<typ>
Vo výpise show ip bgp neighbors hľadá záznam pre zadanú IP adresu, autonómny systém a typ.
Vyhodnotenie je úspešné iba ak tento záznam obsahuje stav spojenia Established.
Typ môže byť napríklad external alebo internal.
Všetky argumenty sa používajú ako regulárny výraz.
Príklad:
exec Router1 status "ip bgp neighbors" ! ip=172.16.32.1 as=64512 type=internal points=3
msg="BGP internal neighbor 172.16.32.1 AS 64512"
Príkaz ''SHOW''
Pre tabuľky, ktoré nie sú implementované v príkaze STATUS je možné použiť príkaz SHOW, pre ktorý
platí nasledujúca všeobecná syntax:
show <tabuľka> <regulárny výraz> ...
Regulárny výraz by mal byť uzavretý v úvodzovkách, ak nie je, v prípade viacerých slov sa spojí
pomocou medzier. Body pridelí v prípade, ak niektorý riadok zodpovedá regulárnemu výrazu. Týmto
spôsobom je možné implementovať všetky jednoduché kontroly riadkov vo výstupoch IOS príkazu
show. V prípade, že nejaká kontrola sa opakuje a obsahuje zložitejší regulárny výraz s viacerými
argumentami, je vhodné ju implementovať ako rozšírenie príkazu STATUS. Tento príkaz je tiež
43
užitočný pri vývoji na testovanie regulárnych výrazov pri implementácií nových rozšírení príkazu
STATUS.
Príklad:
exec Router1 show "ip ospf neighbor" Serial1/0 ! points=1 msg="ospf neighbor RT2,
Router1"
5.3 Tvorba testovania
Tvorba testovania priamo vychádza z požiadaviek profesora. Rovnako ako pri písomkách na
papier alebo iných opravovaných písomkách profesor určí mieru voľnosti. V našom prípade miera
voľnosti určuje, či kontrolujeme podrobný postup a príkazy podľa vzorového riešenia alebo
kontrolujeme len výsledok, fungujúci ping, cesta v smerovacej tabuľke, prípadne vhodnú kombináciu
oboch. V našom vypracovaní ponúkame profesorovi plnú voľnosť a ten si môže určiť čo a ako
skontroluje. Jednoduchý príklad je dať plný počet bodov, napríklad 10, za funkčný obojsmerný ping.
Ak ping prejde a profesorovi to stačí, nie je nutné ďalej kontrolovať konfiguráciu a stav siete.
V prípade, ak ping neprejde, alebo prechádza len každý x-tý, profesor sa môže rozhodnúť priradiť
aspoň časť bodov. Tu prichádza na radu jasnosť a presnosť zadania. Najjednoduchšie v prípade
prideľovania čiastkových bodov je skontrolovať jednotlivé príkazy, ak súhlasia s hodnotenou
konfiguráciou, body sa pridelia, ak nesúhlasia, body sa nepridelia. V tomto prípade sa však neberie do
úvahy študentova kreativita a všadeprítomná možnosť vyriešiť zadanie rôznymi spôsobmi. Keďže
možnosti vypracovávania zadaní a prípadné požiadavky profesorov sú veľmi rozsiahle, tvorba testov
nikdy nebude úplne triviálna záležitosť. V tejto časti sa však pokúsime spomenúť dostatočné
množstvo príkladov a postupov, aby vytvoriť testovanie mohol aj človek s minimálnymi skúsenosťami
s VLABom. V príkladoch budeme používať syntax spomenutú v časti funkčné vyhodnocovanie.
Zariadenie bude mať označenie Router1, v prípade použitia viacerých zariadení sa bude zvyšovať
index e.g. Router2.
Pri vôli ponechať kreativitu študentom môžeme kontrolovať len čiastočné príkazy. Napríklad
nasledujúce OSPF príkazy sú významom veľmi podobné a všetky zaradia interfejs a IP adresou
10.10.10.1 maska /24 do OSPF procesu:
network 10.10.10.1 0.0.0.255 area 0
network 10.10.10.1 0.0.0.0 area 0
network 10.10.10.1 255.255.255.255 area 0
44
V takomto prípade je vhodné nájsť buď vhodný príkaz network alebo skontrolovať, či je daný interfejs
priradený do OSPF procesu pomocou show príkazu. Keďže sa dá daná úloha vyriešiť pomocou
nepreberného množstva network, prípadne iných príkazov, je vhodné zvoliť postup so show
príkazom. Najprv nájdeme vhodný príkaz v tomto prípade je to príkaz
Router#show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
10.29.81.1 0 FULL/ - 00:00:35 10.10.10.2 Serial1/0
Ako je v ukážke vidno, posledný atribút, ktorý sa nám o susedovi vypíše je interfejs, cez ktorý je
vytvorené susedstvo. Ak vieme, že sieť, ktorú sme chceli pridať do OSPF procesu je 10.10.10.0/24 a tá
sa nachádza na interfejsy Serial1/0 stačí vo výpise hľadať správny interfejs v tomto prípade:
exec Router1 section show “ip ospf neighbor" "Serial1/0" ! points=2
ako už bolo vysvetlené v sekcii funkčné vyhodnocovanie, vezme sa časť v úvodzovkách po show ako
argument show príkazu a vo výpise sa hľadá časť v druhých úvodzovkách.
V prípade kontrolovania len časti príkazu môžeme skontrolovať prvú časť príkazu network:
conf Router1 section "router ospf" "network 10.*area 0" ! points=1 msg="network 10 area 0,
Router1"
Pri OSPF nám susedstvo ešte stále nemusí stačiť. Preto sa dá nájsť ešte ďalší show príkaz, ktorý overí
iné nastavenia. Kompletný výpis príkazu show ip ospf interface serial 1/0 môže vyzerať nasledovne:
Router#sh ip ospf interface serial 1/0
Serial1/0 is up, line protocol is up
Internet Address 10.0.0.1/24, Area 0
Process ID 1, Router ID 10.29.79.1, Network Type POINT_TO_POINT, Cost: 64
Transmit Delay is 1 sec, State POINT_TO_POINT,
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
oob-resync timeout 40
Hello due in 00:00:02
Supports Link-local Signaling (LLS)
45
Index 1/1, flood queue length 0
Next 0x0(0)/0x0(0)
Last flood scan length is 1, maximum is 1
Last flood scan time is 0 msec, maximum is 0 msec
Neighbor Count is 1, Adjacent neighbor count is 1
Adjacent with neighbor 10.29.81.1
Suppress hello for 0 neighbor(s)
Router#
Pre overenie nastavenia defaultných časovačov na interfejsy Serial1/0 použijeme nasledovný príkaz:
exec Router1 section show “ip ospf interface serial 1/0" "Timer intervals configured, Hello 10, Dead
40, Wait 40" ! points=2
V tomto prípade sme použili príkaz! ” exec section show”, ktorý v show príkaze napísaného v prvých
úvodzovkách, hľadá výraz v druhých úvodzovkách. V ďalších častiach si ukážeme, aký je tento príkaz
všeobecný a pomocou zreťazovania vieme skontrolovať aj viac riadkov v jednom výpise.
Nasledovným spôsobom je možné skontrolovať, či je interfejs zaradený do správnej area:
exec Router1 section show “ip ospf interface serial 1/0" " , Area 0”! points=2
Ako vyplýva z uvedených príkladov, môžeme v show príkazoch hľadať ľubovoľné sekvencie písmen.
Je len na náročnosti zadania a kreativite skúšajúceho, akým spôsobom a pomocou akých príkazov
overí správnosť vypracovania.
Pri kontrolovaní BGP konfigurácie sme narazili na problém, kde sme museli overiť viacero riadkov
nasledujúcich po sebe. Konkrétne sme chceli overiť stav susedstva s želaným susedom. To sa dá
dvoma spôsobmi, buď z často používaného príkazu
Router1#show ip bgp summary
BGP router identifier 172.16.64.1, local AS number 64512
BGP table version is 5, main routing table version 5
3 network entries using 351 bytes of memory
3 path entries using 156 bytes of memory
5/3 BGP path/bestpath attribute entries using 620 bytes of memory
46
1 BGP AS-PATH entries using 24 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 1151 total bytes of memory
BGP activity 3/0 prefixes, 4/1 paths, scan interval 60 secs
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
1.1.1.1 4 54512 0 0 0 0 0 never Idle
172.16.32.1 4 64512 16 20 0 0 0 00:01:24 Active
192.168.1.5 4 200 7 6 5 0 0 00:01:36 1
V tomto prípade vieme overiť nadviazanie susedstva pomocou riadkov na konci výpisu. V stĺpci
State/PfxRcd vidíme aktuálny stav susedstva. Stavov v BGP je rovnako ako v iných smerovacích
protokolov viacero, preto by sme museli hľadať na konci riadku číslo. Toto sa dá, no rozhodli sme sa
pre elegantnejší spôsob a to pomocou iného výpisu, konkrétne:
Router1#sh ip bgp neighbors 172.16.32.1
BGP neighbor is 172.16.32.1, remote AS 64512, internal link
BGP version 4, remote router ID 172.16.32.1
BGP state = Established, up for 00:00:37
Last read 00:00:06, last write 00:00:06, hold time is 180, keepalive interval is 60 seconds
Neighbor capabilities:
Route refresh: advertised and received(old & new)
Address family IPv4 Unicast: advertised and received
Message statistics:
InQ depth is 0
OutQ depth is 0
Sent Rcvd
Opens: 2 2
Notifications: 1 0
Updates: 5 6
Keepalives: 18 15
Route Refresh: 0 0
47
Total: 26 23
Default minimum time between advertisement runs is 0 seconds
...
V tomto prípade ide o veľmi detailný výpis o konkrétnom susedovi. Pre nás najdôležitejšie časti sa
nachádzajú v prvých troch riadkoch. Potrebujeme skontrolovať, že ide o internal link a BGP state je
established. Hľadané výpisy majú pevný odstup jedného riadku. Pre tento účel sme vytvorili
samostatný príkaz, ktorý má hľadané premenné ako argumenty, konkrétne IP adresu suseda, typ, či
ide o internal alebo external suseda a AS v ktorom sa má sused nachádzať, automaticky sa hľadá stav
susedstva established:
exec Router1 status "ip bgp neighbors" ! ip=172.16.32.1 as=64512 type=internal points=4 msg="BGP
internal neighbor 172.16.32.1 AS 64512"
Ako sme už spomenuli, podobný efekt sa dá dosiahnuť zreťazením viacerých kontrol.
S výhodou tu využijeme príkazy popísané v časti funkčné vyhodnocovanie a to konkrétne AND
a SHOW. Vďaka tomuto overíme výskyt viacerých výrazov v jednom show výpise. Ekvivalentný príkaz
k už uvedenému môže mať napríklad nasledujúcu podobu, všimnime si, že sme použili konkrétnejší
show príkaz doplnený o IP adresu suseda:
and ! points=4
exec Router1 section show “ip bgp neighbors 172.16.32.1" " remote AS 64512, internal link”!
points=2
exec Router1 section show “ip bgp neighbors 172.16.32.1" " BGP state = Established”! points=2
end
AND príkazu sme dali váhu 4 bodov, čo je súčet jednotlivých príkazov. V prípade splnenia všetkých
podmienok budú pridelené plné body, v prípade nesplnenia aspoň jednej z podmienok nebude
pridelený bod ani jeden. V tomto prípade môžeme kontrolovať aj iné ako established stavy.
Uvedeným spôsobom si môžeme poradiť v veľkým množstvom kontrolovaných výrazov. Zvolíme si
správny show príkaz a zreťazujeme podľa potreby. Myslíme si, že sa v budúcnosti objavý špecifický
príkaz, pre ktorý bude nutné vytvoriť samostatný príkaz. To môže byť napríklad, ak hľadáme riadky
48
v konkrétnom poradí. Najmä z toho dôvodu sme vytvorili samostatný príkaz status "ip bgp
neighbors". Tento príkaz môže byť v budúcnosti po menšej modifikácii použitý na tvorbu podobných
zreťazených výpisov so stabilnými odstupmi aj v iných príkazoch.
Druhý možný prístup ku kontrole je kontrolovať priamo konfiguráciu zariadenia. Aby sme zachovali
konzistenciu medzi hodnotenou konfiguráciou a výpismi z funkcionálneho testovania, zvolili sme
kontrolovanie running configu v momente ukončenia testu, čí už z vôle študenta, alebo vypršania
časového limitu. Samozrejme si študent môže uložiť konfiguráciu vždy, keď spraví pokrok
v konfigurácii. Následne pre návrat k staršej konfigurácii treba zadať nasledujúci príkaz[1]:
configure replace nvram:startup-config force
Keď chceme skontrolovať príkazy v running configu, použijeme testovací príkaz regexp. Napríklad pri
kontrolovaní použitia správne nakonfigurovanej EIGRP AS v tomto prípade 64512 použijeme príkaz[2,
3]:
conf Router1 regexp router eigrp 64512 ! points=1 msg="EIGRP AS 64512, Router1"
Príkaz hľadá v running configu zhodu s výrazom nasledujúcim po regexp teraz “router eigrp 64512”.
Niekedy nestačí nájsť len jeden riadok, niekedy potrebujeme nájsť viacero príkazov. Vtedy zreťazíme
regexp príkazy podobne ako v prípade exec výrazov pomocou konštrukcie AND. Naopak, ak hľadáme
nadväznosť napríklad IP adresu na interfejsy, alebo network príkaz v konkrétnom routovacom
protokole, použijeme príkaz section. Príkladom je:
conf Router1 section "interface FastEthernet1/0" "ip address 172.16.2.2 255.255.255." ! points=1
msg="IP address on , Router1"
Uvedený príkaz hľadá v sekcii z prvých úvodzoviek výraz z druhých úvodzoviek. V tomto pípade
kontroluje či je na interfejsy fastethernet 1/0 nakonfigurovaná IP adresa 172.16.2.2 255.255.255.x.
Schválne je vynechaný posledný oktet, aby sme ukázali možnosť pri nešpecifickom zadaní
skontrolovať správnosť minimálnej možnej funkčnej možnosti.
Keď sme si predstavili možnosti testovania, je nutné povedať, že každý príkaz môže byť
vyhodnocovaný pozitívnym očakávaním a to napríklad že sa v routovacej tabuľke cesta nachádza
49
prípade, že ping prejde alebo s očakávaním negatívnym – cesta sa v tabuľke nenachádza, ping
neprejde atď. Príkazy sa negujú pomocou pridania znaku “~” na začiatok príkazu. Negovanie
predchádzajúceho príkazu vyzerá následovne:
~conf Router1 section "interface FastEthernet1/0" "ip address 172.16.2.2 255.255.255." ! points=1
msg="IP address on fa0/1, Router1"
Ako sme si už z príkladov mohli všimnúť, v testovacích príkazoch sa nachádza argument msg. Ten je
nutné uviesť vždy, podľa neho sa zobrazuje výsledný výpis. Nemá síce vplyv na hodnotenie, no
sprehľadňuje a stransparentňuje proces hodnotenia. Tu si treba zvoliť, čo uviesť do vypisovanej
správy. V našom testovaní sme sa snažili uviesť čo najpresnejší popis, aby sme si mohli čo možno
najjednoduchšie opraviť chybu vo vypracovaní. Na písomke to tak byť nemusí a je možné, že profesor
bude chcieť podať len čiastkový výpis študentovi, aby nemohol ďalej šíriť správne výsledky aj bez
vlastnej vedomosti. V tomto prípade necháme na profesora, akú mieru informatívnosti zvolí. Najviac
sa nám osvedčil formát, kedy sa na konci správy nachádza zariadenie, na ktorom sa testovalo:
msg="IP address on fa0/1, Router1". V aktuálnej verzii testovacieho modulu sa študentovi počas
testu zobrazí výsledok vo forme získaných bodov a percent.
5.3.1 Spôsob navrhovania testovania
Pri navrhovaní, akým spôsobom je najlepšie automaticky testovať konfigurácie sme došli na spôsob
“Splň povinnú jazdu, over funkčnosť, ak všetko funguje prideľ plný počet bodov, ak nie hľadaj čo je
správne nakonfigurované.” Ako je z dlhého názvu jasné, najprv sa skontrolujú príkazy, ktoré musia
byť zadané presne podľa zadania, napríklad hostname alebo ”no ip domain-lookup”. Tieto sa
jednoducho skontrolujú pomocou testovacích príkazov regexp alebo section. V tomto prípade nemá
cenu skúšať príkaz zaobaľovať, prípadne ich skracovať, buď sa v konfigurácii nachádzajú a študent
získa body alebo sa tam nenachádzajú a študent ich nezíska.
Následne sa skontrolujú príkazy ako ping či už s očakávaným kladným alebo záporným výsledkom.
Tieto reprezentujú overenie cieľa celého zadania, napríklad ping z jednej strany na druhú, alebo
správne cesty v smerovacej tabuľke. Tieto sú zreťazené pomocou bloku AND a teda musia byť
splnené všetky úlohy zadania. Ak sa tieto nevyhodnotia kladne, kontroluje sa alternatívna možnosť.
50
Táto reprezentuje jednotlivé kroky, ktoré vedú k správnemu vyriešeniu úlohy. Mnohé úlohy sa dajú
splniť viacerými spôsobmi. Ideálnym príkladom je nastavenie smerovacieho protokolu. Interfejs sa dá
do smerovacie procesu pridať buď cez príkaz network v konfigurácii smerovacieho protokolu alebo sa
dá pridať priamo na interfejs. V tomto prípade môžeme pomocou bloku OR v testovaní pokryť všetky
nami odhalené cesty k správnemu vyriešeniu úlohy. V prípade viacerých možností na vypracovanie, je
samozrejme jednoduchšie skontrolovať už želaný výsledok a preto sme dali na prvé miesto
funkcionálne testovanie. Body sa za blok MAX priradia podradenému bloku s najvyšším blokovým
ziskom. Ak získame za AND 0 bodov, za druhé konfiguračné testovanie 2 body a za tretie 9 bodov, vo
výsledku sa vypíše a započíta len tretie testovanie.
Nami navrhovanému spôsobu testovania zodpovedá nasledujúca kostra testovania:
#povinné príkazy
#conf SanJose2 section "interface Serial0/0" "ip address 172.16.1.2 255.255.255.0" ! points=1
msg="IP address on Serial0/0, SanJose2"
max ! msg="variable testing"
and ! points=10 msg="functional testing"
#prvý blok testovania, funkcionálne pomocou AND
#exec SanJose2 show "ip bgp nei" 'BGP neighbor is 172.16.64.1, remote AS 64512, internal link' !
points=1 msg="BGP neighbor SJ1 172.16.64.4 AS 64512 external, SanJose2"
end
sum ! msg="configuration testing, via router ospf"
#druhý blok testovania, parsovacie pomocou SUM
#conf SanJose2 section "router ospf" "network 172.16." ! points=1 msg="OSPF network 172.16.0.0,
SanJose2"
end
sum ! msg="configuration testing via interfaces"
#tretí blok testovanie, parsovacie pomocou SUM
#conf SanJose2 section "interface Serial0/0" "ip ospf . area 0" ! points=1 msg=" OSPF on Serial0/0,
SanJose2"
end
end
51
print Max points: 15
print Earned points:
Tvorbu testovania si finálne ukážeme na úlohe, ktorú sme medzi laby pridali ako pilotnú, pre účely
testovania.
5.3.1.1 Úloha má nasledujúce zadanie:
Nakonfigurujte sieť, aby bol možný ping z PC0 na PC1.
Na prislúchajúce interfacey pridajte zmysluplne popisy.
Použite rozsahy sietí s najmenším možným počtom použiteľných IP adries, rozsahy zvoľte podľa
nasledujúcich údajov:
Máte pridelený subnet 172.16.0.0/16 Prvú možnú sieť prideľte na segment siete s PC0. Na tejto sieti
je nutné mať priestor pre 253 počítačov. Druhú voľnú sieť rovnako s 253 počítačmi prideľte na časť
siete s PC1. Na interfecey routrov prideľte prvú voľnú adresu z prislúchajúceho rozsahu, na počítače
druhú voľnú IP adresu.
medzi routrami nastavte sieť 10.10.10.0/30 RT1 s IP .1, RT2 s IP .2
na linkách k počítačom nemajú byť posielané updatey z IGP
ako IGP použite EIGRP s číslom AS 5
routre nazvite presne podľa obrázka Router1 - Router1, Router2 - Router2. V routovacej tabuľke musí
byť cesta do cudzej siete naučená z EIGRP
52
5.3.1.2 Naša vzorová konfigurácia vyzerá následovne:
Router1:
hostname Router1
!
interface FastEthernet0/0
description kPC1
ip address 172.16.0.1 255.255.255.0
no shutdown
!
interface Serial1/0
description kRT2
ip address 10.10.10.1 255.255.255.252
no shutdown
!
router eigrp 5
passive-interface FastEthernet0/0
network 10.10.10.0 0.0.0.3
network 172.16.0.0 0.0.0.255
no auto-summary
53
!
Router2:
hostname Router2
!
interface FastEthernet0/0
description kPC1
ip address 172.16.1.1 255.255.255.0
no shutdown
!
interface Serial1/0
description kRT1
ip address 10.10.10.2 255.255.255.252
no shutdown
!
router eigrp 5
passive-interface FastEthernet0/0
network 10.10.10.0 0.0.0.3
network 172.16.1.0 0.0.0.255
no auto-summary
Host PC0 a PC1 majú IP adresy predkonfigurované.
54
5.3.1.3 Nami navrhnuté testovanie:
conf Router1 hostname Router1 ! points=1 msg="hostname, Router1"
conf Router2 hostname Router2 ! points=1 msg="hostname, Router2"
#kontrola hostname na router1 a Router 2
conf Router1 section "interface Serial1/0" "description" ! points=1 msg="description s1/0, Router1"
conf Router1 section "interface FastEthernet0/0" "description" ! points=1 msg="description fa0/0,
Router1"
conf Router2 section "interface Serial1/0" "description" ! points=1 msg="description s1/0, Router2"
conf Router2 section "interface FastEthernet0/0" "description" ! points=1 msg="description s1/0,
Router2"
#kontrola description na router1 a Router 2
conf Router1 section "router eigrp 5" "passive-interface FastEthernet0/0" ! points=1 msg="EIGRP
passive interface fa0/0, Router1"
conf Router2 section "router eigrp 5" "passive-interface FastEthernet0/0" ! points=1 msg="EIGRP
passive interface fa0/0, Router2"
#kontrola passive-interface v eigrp AS 5 na interfejsoch k počítačom na Router1 a Router2
max ! msg="variable testing"
and ! points=11 msg="functional testing"
exec PC0 ping -c5 172.16.1.2 ! msg="succesfull ping PC0 PC1, PC0"
exec PC1 ping -c5 172.16.0.2 ! msg="succesfull ping PC1 PC0, PC1"
exec Router1 status "ip route" 172.16.1.0 ! type=EIGRP msg="EIGRP route from other PC segment
172.16.1.0/24, Router1"
exec Router2 status "ip route" 172.16.0.0 ! type=EIGRP msg="EIGRP route from other PC segment
172.16.0.0/24, Router2"
end
#funkcionálna kontrola pozostávajúca z kontroly hlavných bodov zadania end-to-end ping a
prešírenie cesty pomocou smerovacieho protokolu EIGRP.
sum ! msg="configuration testing"
conf Router1 section "interface Serial1/0" "ip address 10.10.10.1 255.255.255.252" ! points=1
msg="IP address s1/0, Router1"
55
conf Router1 section "interface FastEthernet0/0" "ip address 172.16.0.1 255.255.255.0" ! points=1
msg="IP address fa0/0, Router1"
conf Router2 section "interface Serial1/0" "ip address 10.10.10.2 255.255.255.252" ! points=1
msg="IP address s1/0, Router2"
conf Router2 section "interface FastEthernet0/0" "ip address 172.16.1.1 255.255.255.0" ! points=1
msg="IP address fa0/0, Router2"
conf Router1 regexp router eigrp 5 ! points=1 msg="EIGRP correct AS number 5, Router1"
conf Router2 regexp router eigrp 5 ! points=1 msg="EIGRP correct AS number 5, Router2"
conf Router1 section "router eigrp 5" "no auto-summary" ! points=1 msg="EIGRP no auto-summary,
Router1"
conf Router2 section "router eigrp 5" "no auto-summary" ! points=1 msg="EIGRP no auto-summary,
Router2"
exec Router1 status "ip route" 172.16.1.0 ! type=EIGRP points=1 msg="EIGRP route from other PC
segment 172.16.1.0/24, Router1"
exec Router2 status "ip route" 172.16.0.0 ! type=EIGRP points=1 msg="EIGRP route from other PC
segment 172.16.0.0/24, Router2"
end
end
#konfiguračná kontrola pozostávajúca z krokov potrebných na nakonfigurovanie daného zadania.
Postupne sme skontrolovali všetky potrebné príkazy z našej vzorovej konfigurácie a pridaného
skontrolovania naučenia cesty zo smerovacieho protokolu definovaného v zadaní. Príkazy sú v bloku
SUM, ktorý sčítava hodnotu jednotlivých správne vyhodnotených príkazov. Ak by sa v testovaní
nachádzal aj ďalší SUM blok, vyberie sa blok s maximálnym získaným počtom bodov.
print Max points: 19
print Earned points:
#vypísanie maximálneho počtu bodov získateľného v zadaní a textu, za ktorým nasleduje získaný
počet bodov.
56
5.3.1.4 Nasleduje výpis z uvedeného testovania pri nami navrhnutej
konfigurácii:
hostname, Router1: 1/1
hostname, Router2: 1/1
description s1/0, Router1: 1/1
description fa0/0, Router1: 1/1
description s1/0, Router2: 1/1
description s1/0, Router2: 1/1
EIGRP passive interface fa0/0, Router1: 1/1
EIGRP passive interface fa0/0, Router2: 1/1
MAX variable testing = 11.0 pts: functional testing: 11.0/11.0
succesfull ping PC0 PC1, PC0: 0/0
succesfull ping PC1 PC0, PC1: 0/0
EIGRP route from other PC segment 172.16.1.0/24, Router1: 0/0
EIGRP route from other PC segment 172.16.0.0/24, Router2: 0/0
variable testing: 11.0/11.0
Max points: 19
Earned points:
19
Ak sa z nejakého dôvodu nevykoná funkcionálne testovanie, vypíše sa nasledujúce hodnotenie
reprezentujúce povinnú časť a konfiguračné testovanie
hostname, Router1: 1/1
hostname, Router2: 1/1
description s1/0, Router1: 1/1
description fa0/0, Router1: 1/1
description s1/0, Router2: 1/1
description s1/0, Router2: 1/1
EIGRP passive interface fa0/0, Router1: 1/1
EIGRP passive interface fa0/0, Router2: 1/1
MAX variable testing = 10.0 pts: configuration testing: 10.0/10.0
57
IP address s1/0, Router1: 1/1
IP address fa0/0, Router1: 1/1
IP address s1/0, Router2: 1/1
IP address fa0/0, Router2: 1/1
EIGRP correct AS number 5, Router1: 1/1
EIGRP correct AS number 5, Router2: 1/1
EIGRP no auto-summary, Router1: 1/1
EIGRP no auto-summary, Router2: 1/1
EIGRP route from other PC segment 172.16.1.0/24, Router1: 1/1
EIGRP route from other PC segment 172.16.0.0/24, Router2: 1/1
variable testing: 10.0/10.0
Max points: 19
Earned points:
18
Častou chybou pri tvorení testovania a overovaní jeho správnosti je kopírovanie celého startup-
configu, pričom sa neskopíruje stav liniek a teda tie, ktoré boli pôvodne v stave up teraz iba nemaju
v konfigurácii príkaz shutdown, preto treba buď ručne upnúť potrebné interfejsy, do uloženého
startup-configu pripísať no shutdown. Alebo ak máme v zariadení nahraný súbor s konfiguráciu už
spomínaný príkaz:
configure replace nvram:startup-config force
Druhou častou chybou je, skopírovanie aj IP adresy testovacieho interfejsu, ktorý v tomto prípade už
nemusí mať pôvodnú IP adresu. To má za následok nemožnosť prihlásenia na zariadenie testovacím
skriptom. Testovacie interfejsy majú rezervovaný rozsah a to sieť 10.29.0.0 / 16. Tieto IP adresy
nesmú byť v zadaní použité, sú totiž počas ukončovania testu z konfigurácie zmazané. Ďalšie príklady
testovania sa nachádzajú v prílohe.
58
6 Overenie výsledku
Prácu v rámci tímového projektu sme verifikovali priebežne. Počas vývoja systému sme
postupovali iteračne a po každej fáze sme overili funkčnosť novej, rovnako ako aj už
implementovanej funkcionality. Počas vývoja sme overovali nie len správnosť skriptov no aj vplyv na
celkový výkon systému. Viackrát sme museli upravovať postupy práve kvôli negatívnemu vplyvu na
výkon.
Na verifikáciu funkčnosti sme používali logovacích výpisy frontendu a aktuálne bežiacich procesov.
Tieto výpisy sme v úvodných fázach upravili do prehľadnej podoby. Pri potrebe overiť funkčnosť,
respektíve pri hľadaní chýb sme často používali debug výpisy pomocou aplikačného serveru Apache
priamo do frontendu.
Funkčnosť a prehľadnosť systému sme overovali spolu so študentmi bakalárskeho stupňa, najviac by
sme sa chceli poďakovať za pomoc študentovi Petrovi Bôžikovi, ktorý nám pomáhal počas vývoja
najvýraznejšie.
Nezaznamenali sme výraznejšie problémy. Dvakrát sa nám stalo, že sme si prepísali už spravenú
a overenú funkcionalitu. Našťastie sme si pre takéto účely robili pravidelné zálohy. Vďaka tomu sme
sa vedeli rýchlo vrátiť k predošlej verzii a opätovne doplnili zmazanú funkcionalitu.
Aby sme neovplyvnili funkčnosť VLABu prístupného pre študentov, rozdelili sme vývoj na dve vetvy.
V rámci jednej sme udržiavali ostrú verziu prístupnú 24 hodín denne, 7 dní v týždni a druhú,
development verziu, na ktorú sme aplikovali zmeny. Na ostrej verzii sme iba odstraňovali vážne chyby
a dopĺňali overenú kľúčovú funkcionalitu. Development verzia bola určená len pre naše účely a na
testovanie pre vybraných študentov. Funkcionalita sa do ostrej verzie dostala až po dôkladnom
overení. Na záver projektu sme development verziu upravili na ostrú verziu a vďaka tomu poskytli
vyladený a doplnený VLAB študentom aj profesorom. Finálne testovanie prebiehalo v skupine
a overili sme plnú funkčnosť. Systém zvládol záťaž nad úrovňou možností jedného laboratória,
konkrétne 8 študentov na jednu zápočtovku.
59
7 Záver
VLAB je momentálne v plne funkčnom stave. Je umiestnený na novom virtuálnom stroji a je
prístupný študentom. Prístup do labu bol prezentovaný na predmete PS2. Je možná registrácia
nových používateľov pomocou administrátorského účtu. Všetky LABy fungujúce v predchádzajúcich
verziách VLABu fungujú aj v aktuálnej verzii. Momentálne pracujeme na možnosti paralelnom
rezervovaní simulácií. Zároveň hľadáme chyby v implementácii, ktoré následne odrstraňujeme.
Doposial sme našli len nevýrazné chyby ako chýbajúca kontrola formátu emailovej adresy študenta.
V najbližšej dobe začneme pracovať na navrhnutých rozšíreniach, ktoré plne implementujeme počas
budúceho semestra.
60
8 Zdroje
[1] http://www.zive.sk/do-roku-2025-bude-na-internete-mozno-az-5-a-pol-miliardy-ludi/sc-4-a-
290432/default.aspx
[2] Kleinrock, L.: History if the Internet and its flexible future, IEEE Wireless Communications,
February 2008
[3] http://www.cisco.com/web/learning/netacad/course_catalog/PacketTracer.html
[4] https://vlab.fiit.stuba.sk/
[5] http://tldp.org/HOWTO/PPP-HOWTO/x1219.html
[6] http://www.cisco.com/en/US/docs/ios/12_1/termserv/configuration/guide/dcdmodem.html
[7] Projektová dokumentácia VLAN PSS tým 8, 2009
http://labss2.fiit.stuba.sk/TeamProject/2008/team09pss/documents-zs/projekt_final_ZS.pdf
[8] Péti, P.: Podpora pre simulátor/emulátor počítačovej siete, Diplomový projekt II, ÚPSS
FIIT STU, Bratislava 2009.
[9] http://www.cisco.com/en/US/docs/ios/12_3t/12_3t7/feature/guide/gtrollbk.html (Internet
čerpané 7.4)
[10] http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080093f07.shtml
(Internet čerpané 7.4)
[11] http://www.cisco.com/en/US/docs/ios/12_0/np1/configuration/guide/1ceigrp.html (Internet
čerpané 7.4)
61
9 Príloha A
V tejto prílohe si ukážeme, ako sme vytvorili testovanie pre vzorové simulácie.
9.1 Vytvorenie testovania pre Basic Router Configuration
V tejto časti si popíšeme priebeh tvorby testovania pre úlohu Basic Router Configuration.
9.1.1 Zadanie úlohy Basic Router Configuration
Cvičenie 3: Prvotná konfigurácia použitím základných príkazov
Krok 1
Presuňte sa do globálneho konfiguračného módu. Nasledujúcim príkazom nastavíte meno
smerovača:
Router(config)# hostname meno
- parametrom je textový reťazec
Nakonfigurujte meno smerovača na Smerovac. Prompt sa zmení na:
Smerovac(config)#
Ja však budem aj naďalej písať Router namiesto Smerovac.
Krok 2
Ďalším dôležitým krokom je nastaviť heslá pre prístup na smerovač. Nastavujú sa hlavne tieto:
Heslo pre privilegovaný režim:
Router(config)# enable secret password
Heslo pre konzolový port:
62
Router(config)# line con 0
Router(config-line)# login
Router(config-line)# password password
Heslo pre prístup cez telnet:
Router(config)# line vty 0 4
Router(config-line)# login
Router(config-line)# password password
VTY = VirtualTeletYpe, normálne Cisco smerovače umožňujú až päť virtuálnych spojení (cez
telnet alebo SSH), ktoré sú číslované od 0 do 4. Na každé spojenie sa dá použiť samostatné
heslo. Po nakonfigurovaní sa dá na smerovač pripojiť vzdialene cez telnet.
Nastavte všetky heslá na cisco a potom použite nasledujúce príkazy:
Router(config)# line con 0
Router(config-line)# logging synchronous
- týmto príkazom si zabezpečíte neporušenie výstupu na obrazovku v prípade vypisovania
rôznych hlášok operačného systému
Krok 3
Rozhrania na smerovači sfunkčníme nasledujúcimi príkazmi. Pre smerovače s fixnou
konfiguráciou rozhraní sa používa:
Router(config)# interface type port
V našom prípade interface fa0/0
Pre modulárne stavané smerovače, ktoré umožňujú zmenu rozhraní prídavnými kartami (WIC
– Wan Interface Card, Network modules) sa používa:
Router(config)# interface type slot/port
Po prechode na želané rozhranie mu treba priradiť IP addresu príkazom:
Router(config-if)# ip address <address> <mask>
V našom prípade ip address 192.168.0.1 255.255.255.0
A následne rozhranie zapnúť:
Router(config-if)# no shutdown
Router(config-if)# description popis
Pripojte vašu stanicu kríženým káblom priamo na Ethernet port na smerovači. Nakonfigurujte
Ethernetové rozhranie tak, aby malo IP adresu default gateway, ktorú zistíte z konfigurácie
63
vašej pracovnej stanice. Takisto označte, kam vedie toto spojenie, napr.:
Router(config-if)# description Pripojenie k stanici
Krok 4
Veľmi dôležitá vec je nakonfigurovanie oznamu, ktorý sa zobrazí používateľovi po
prihlásení na smerovač, či už cez konzolu, modem alebo virtuálne spojenie. Takáto výstraha
sa konfiguruje:
Router(config)# banner motd # message #
- správa, ktorú chcete aby bola zobrazovaná sa umiestni medzi znaky #
Nakonfigurujte takýto oznam:
Entering restricted area. Unauthorized persons should logout immediately!
9.1.2 Vzorová konfigurácia
Router1
hostname Router1
enable secret password
interface FastEthernet0/0
description kPC
ip address 192.168.0.1 255.255.255.0
no shutdown
banner motd @Entering restricted area. Unauthorized persons should logout immediately!@
!
line con 0
password password
logging synchronous
line aux 0
line vty 0 4
password password
login
!
64
9.1.3 Navrhnuté testovanie
conf R1 hostname Router1 ! points=1 msg="hostname, Router1"
conf R1 section "line con 0" "password password" ! points=1 msg="password on console, Router1"
conf R1 section "line con 0" "logging synchronous" ! points=1 msg="logging synchronous on console,
Router1"
conf R1 section "line vty 0 4" "password password" ! points=1 msg="password on vty, Router1"
conf R1 regexp "enable secret 5" ! points=1 msg="enable secret, Router1"
conf R1 section "interface FastEthernet0/0" "description" ! points=1 msg="dexcription on fa0/0,
Router1"
conf R1 section "interface FastEthernet0/0" "ip address 192.168.0.1 255.255.255.0" ! points=1
msg="IP address on fa0/0, Router1"
conf R1 regexp "banner motd" ! points=1 msg="banner motd, Router1"
max ! msg="variable testing"
and ! points=5 msg="functional testing"
exec host1 ping -c5 192.168.0.1 ! points=3 msg="succesful ping PC0 -> Router1, PC0"
end
sum ! msg="configuration testing"
~conf R1 section "interface FastEthernet0/0" "shutdown" ! points=1 msg="no shutdown on fa0/0,
Router1"
end
end
print Max points: 13
print Earned points:
9.1.4 Výpis pri dosiahnutí plného počtu bodov
hostname, Router1: 1/1
65
password on console, Router1: 1/1
logging synchronous on console, Router1: 1/1
password on vty, Router1: 1/1
enable secret, Router1: 1/1
dexcription on fa0/0, Router1: 1/1
IP address on fa0/0, Router1: 1/1
banner motd, Router1: 1/1
MAX variable testing = 5.0 pts: functional testing: 5.0/5.0
succesful ping PC0 -> Router1, PC0: 3/3
variable testing: 5.0/5.0
Max points: 13
Earned points:
13
9.2 Vytvorenie testovania pre Basic BGP configuration
9.2.1 Zadanie úlohy Basic BGP configuration
[4]:
Configuring basic BGP
66
Objective
In this lab, the student will configure BGP to exchange routing information with two Internet Service Providers (ISPs). The use of no synchronization and neighbor next-hop-
self commands will be observed.
Scenario
The International Travel Agency relies extensively on the Internet for sales. The company has
contracted with two ISPs for Internet connectivity with fault tolerance. The BGP that runs
between the SanJose1 and 2 boundary routers and the two ISP routers needs to be configured.
Step 1
Build and configure the network according to the diagram, but do not configure a routing
protocol. Do not configure IBGP and OSPF routing until step 5.
Configure a loopback interfaces with an IP address for each ISP router, as shown in the
Figure. These loopbacks simulate real networks that can be reached through the ISP.
Configure loopback interfaces with the IP addresses for the routers located inside the OSPF
area 0 network. These loopbacks simulate the connections to internal LANs.
Use ping to test connectivity between the directly connected routers.
Step 2
Configure the ISP routers. In this lab, configure the providers’ equipment as well as the International Travel Agency’s boundary routers, SanJose1 and SanJose2. On the ISP1 router, enter the following commands to establish EBGP session with SanJose1 router:
ISP1(config)# router bgp 200
ISP1(config-router)# neighbor 10.0.0.2 remote-as 100
ISP1(config-router)# network 12.0.1.0 mask 255.255.255.0
On the ISP2 router, configure BGP as shown in the following:
ISP2(config)# router bgp 300
ISP2(config-router)# neighbor 172.16.0.2 remote-as 100
ISP2(config-router)# network 172.16.1.0 mask 255.255.255.0
Step 3
Configure the SanJose1 and SanJose2 router to run EBGP with both providers. Use the following configuration to establish EBGP sessions with the two providers:
SanJose1(config)# router bgp 100
SanJose1(config-router)# neighbor 10.0.0.1 remote-as 200
SanJose1(config-router)# network 192.168.1.0
SanJose2(config)# router bgp 100
SanJose2(config-router)# neighbor 172.16.0.1 remote-as 300
SanJose2(config-router)# network 192.168.2.0
67
This completes the EBGP configuration. Check the routing table for these EBGP peers with the show ip route. SanJose1 and 2 have routes to the loopback networks at each ISP
router. Verify that SanJose routers have connectivity to these networks by pinging each
loopback address from its console. These pings should be successful.
Step 4
Use show commands to verify the operation of BGP on our EBGP peers. First, verify the
neighbor establishment using the show ip bgp neighbors command.
1. Based on the output of this command, what is the BGP state between this router and its peers?
2. How long has this connection been up?
Optionally, the command show ip bgp summary will give you a brief overview about BGP
peering establishment. Now, use the show ip bgp command to view the routes learned via BGP.
3. What do the asterisks (*) next to each route indicate? 4. What do the “>” symbols next to each route indicate? 5. What is the local router ID? 6. Which table version is displayed?
7. On the ISP1 router, issue the shutdown command on Loopback0. Return to SanJose1
and issue the show ip bgp command again. Which table version is displayed?
The version number will vary, but the shutdown command should have caused a routing
table update, so the version should be one higher than the last.
Bring the ISP1 router Loopback0 back up by issuing the no shutdown command.
Step 5
Routing with external peers is configured. Now we will configure internal routers. First
configure OSPF routing inside International Travel Agency. However, because later we will
configure IBGP inside ITA’s AS 100 to carry all routing information about internal LANs,
configure OSPF so that it will run on only directly connected serial and Ethernet links which
are inside AS 100. After you are done, verify the routing tables and OSPF neighbors among
internal ITA routers.
68
Step 6
Now we will move into IBGP configuration. First configure IBGP peering session just between SanJose1 and SanJose2: SanJose1(config)# router bgp 100
SanJose1(config-router)# neighbor 10.10.10.2 remote-as 100
SanJose2(config)# router bgp 100
SanJose2(config-router)# neighbor 192.168.64.1 remote-as 100
After a while look into BGP tables using show ip bgp of SanJose1 and SanJose2 routers.
They each will have two routes in the table. However, if you look into routing table of SanJose routers you will see BGP routes missing.
8. Which routes are missing on SanJose1 router? Which routes are missing in SanJose2 router?
Step 7
In order for BGP to insert the routes into the routing table, the NEXT-HOP of the route must be known. In other words, the route to the NEXT-HOP address must be in routing table.
9. Check the BGP tables on SanJose routers using show ip bgp command. Which NEXT-
HOP address is BGP using for each route? However, if you look into routing tables, the NEXT-HOP address for routes learned from ISP1 are not in routing table of SanJose2 and vice versa. We have two solutions here:
Using IGP, advertise networks on which our EBGP sessions are formed.
Use next-hop-self command.
Because second solution is preferred, configure BGP on SanJose routers, so that it will modify the NEXT-HOP attribute: SanJose1(config)# router bgp 100
SanJose1(config-router)# neighbor 10.10.10.2 next-hop-self
SanJose2(config)# router bgp 100
SanJose2(config-router)# neighbor 192.168.64.1 next-hop-self
69
Again use the command show ip bgp and check the NEXT-HOP attribute of each route.
Step 8
10. Check the routing tables again using show ip route command. Are BGP routes still
missing from the table? Check the BGP tables of ISP routers using show ip bgp command. You may notice the
routes from other ISP are missing. This happens if you are running IOS software version earlier than 12.2(8). In these versions of IOS the command synchronization is configured
on each BGP router by default. This is to prevent the black-holing of traffic problem, because the BGP and IP routing tables are considered not synchronized. The rule of synchronization states that in order for BGP to insert routes learned via IBGP into the routing table and advertise them to EBGP neighbors, the routes need to be known via IGP. To demonstrate the problem synchronization is trying to prevent, use extended ping with source address of loopback0 from ISP2 to ISP1 network. 11. What happened to the ping? If you try a traceroute, you will notice packets will be dropped by Westasman router.
Step 9
Finish the IBGP configuration. Create full-mesh IBGP, so that synchronization will not be an issue:
Westasman(config)# router bgp 100
Westasman(config-router)# no synchronization !not needed in IOS v12.2(8)
up Westasman(config-router)# neighbor 10.10.10.2 remote-as 100
Westasman(config-router)# neighbor 192.168.64.1 remote-as 100 Westasman(config-router)# network 192.168.3.0
SanJose1(config)# router bgp 100
SanJose1(config-router)# no synchronization !not needed in IOS v12.2(8)
up SanJose1(config-router)# neighbor 192.168.64.2 remote-as 100
SanJose1(config-router)# neighbor 192.168.64.2 next-hop-self
SanJose2(config)# router bgp 100
SanJose2(config-router)# no synchronization !not needed in IOS v12.2(8)
up
SanJose2(config-router)# neighbor 10.10.10.1 remote-as 100
SanJose2(config-router)# neighbor 10.10.10.1 next-hop-self
Now you should be able to ping networks of other ISP. Verify your BGP and IP routing tables on SanJose and Westasman routers and use extended ping again to verify the full connectivity from ISP1 to ISP2.
Step 10
SanJose routers are now configured so that they advertise routes belonging to ISP1. ISP2
then installs these routes in its table and might then attempt to route transit traffic through the
ITA network. Configure the SanJose routers so that they advertise only ITA networks
192.168.0.0, 192.168.1.0, 192.168.2.0 and 192.168.3.0 to both providers. On the SanJose1
router, configure the following access list:
70
SanJose1(config)# access-list 1 permit 192.168.0.0 0.0.3.255
Then apply this access list as a route filter, using the distribute-list keyword with the
BGP neighbor statement:
SanJose1(config)# router bgp 100
SanJose1(config-router)# neighbor 10.0.0.1 distribute-list 1 out
Do the similar for SanJose2 router. After the route filter has been configured, check the
routing tables on ISP routers again. Routes to 12.0.1.0, ISP1, and 172.16.1.0/24, ISP2,
should still be in the table.
Return to SanJose routers and issue the clear ip bgp * command. Wait until the routers
reach the Established state, which might take up to 60 seconds.
After the routers reach the Established state, recheck the ISP routing tables. The route to ISP1 should no longer be in the routing table of ISP2 and vice versa. Now you should not be able to ping networks from ISP of other ISP. Use extended ping again to verify the full connectivity from ISP1 to ISP2. To test final state of lab use extended ping from ISP1 to SanJoses2’s Lo0 and from ISP2 to SanJoses1’s Lo0.
9.2.2 Vzorová konfigurácia
ISP1
en
conf t
hostname ISP1
int s0/0
ip add 10.0.0.1 255.255.255.252
no shut
int lo0
ip add 12.0.1.1 255.255.255.0
no shut
router bgp 200
neighbor 10.0.0.2 remote-as 100
netw 12.0.1.0 mask 255.255.255.0
SanJose1
en
conf t
hostname SanJose1
71
int s0/0
ip add 10.0.0.2 255.255.255.252
desc toISP1
no shut
int lo 0
ip add 192.168.1.1 255.255.255.0
int s0/1
ip add 192.168.64.1 255.255.255.0
desc toWESTaman
no shut
access-list 1 permit 192.168.0.0 0.0.3.255
router bgp 100
neigh 10.0.0.1 remote-as 200
netw 192.168.1.0 mask 255.255.255.0
neigh 192.168.64.2 remote-as 100
neigh 10.0.0.1 distrib 1 out
neighbor 10.10.10.2 remote-as 100
neighbor 192.168.64.2 next-hop-self
neighbor 10.10.10.2 next-hop-self
router ospf 1
netw 10.0.0.2 0.0.0.0 area 0
netw 192.168.64.1 0.0.0.0 area 0
WESTASMAN
en
conf t
hostname WESTASMAN
int s0/0
ip add 192.168.64.2 255.255.255.252
no shut
72
int lo 0
ip add 192.168.0.1 255.255.255.0
no shut
int fa1/0
ip add 10.10.10.1 255.255.255.0
no shut
router bgp 100
neigh 192.168.64.1 remote-as 100
neigh 10.10.10.2 remote-as 100
netw 192.168.0.0 mask 255.255.255.0
router ospf 1
netw 0.0.0.0 0.0.0.0 area 0
SanJose2
en
conf t
hostname SanJose2
int fa1/0
ip add 10.10.10.2 255.255.255.0
no shut
int lo 0
ip add 192.168.2.1 255.255.255.0
int s0/0
ip add 172.16.0.2 255.255.255.252
no shut
access-list 1 permit 192.168.0.0 0.0.3.255
router bgp 100
neigh 172.16.0.1 remote-as 300
neighbor 172.16.0.1 distribute-list 1 out
netw 192.168.2.0 mask 255.255.255.0
neigh 10.10.10.1 remote-as 100
73
neighbor 10.10.10.1 next-hop-self
neigh 192.168.64.1 remote-as 100
neighbor 192.168.64.1 next-hop-self
router ospf 1
netw 10.10.10.2 0.0.0.0 area 0
do clear ip bgp * soft out
ISP2
en
conf t
hostname ISP2
int s0/0
ip add 172.16.0.1 255.255.255.252
no shut
int lo0
ip add 172.16.1.1 255.255.255.0
router bgp 300
neigh 172.16.0.2 remote-as 100
netw 172.16.1.0 mask 255.255.255.0
9.2.3 Navrhnuté testovanie
conf ISP1 hostname ISP1 ! points=1 msg="hostname, ISP1"
conf ISP1 section "interface Serial0/0" "ip address 10.0.0.1 255.255.255.252" ! points=1 msg="IP na
serial0/0, ISP1"
conf ISP1 section "interface Loopback0" "ip address 12.0.1.1 255.255.255.0" ! points=1 msg="IP na
loopback0, ISP1"
conf SanJose1 hostname SanJose1 ! points=1 msg="hostname , SJ1"
conf SanJose1 section "interface Serial0/0" "ip address 10.0.0.2 255.255.255.252" ! points=1 msg="IP
na serial0/0, SJ1"
74
conf SanJose1 section "interface Loopback0" "ip address 192.168.1.1 255.255.255.0" ! points=1
msg="IP na loopback0, SJ1"
conf SanJose1 section "interface Serial0/1" "ip address 192.168.64.1 255.255.255.0" ! points=1
msg="serial0/1, SJ1"
conf WESTASMAN hostname WESTASMAN ! points=1 msg="hostname, WESTAMAN"
conf WESTASMAN section "interface FastEthernet1/0" "ip address 10.10.10.1 255.255.255.0" !
points=1 msg="IP na fastethernet1/0, WESTAMAN"
conf WESTASMAN section "interface Loopback0" "ip address 192.168.0.1 255.255.255.0" ! points=1
msg="IP na Loopback0, WESTAMAN"
conf WESTASMAN section "interface Serial0/0" "192.168.64.2 255.255.255.252" ! points=1 msg="IP
na Serial0/0, WESTAMAN"
conf SanJose2 hostname SanJose2 ! points=1 msg="hostname, SJ2"
conf SanJose2 section "interface FastEthernet1/0" "ip address 10.10.10.2 255.255.255.0" ! points=1
msg="IP na fastethernet1/0, SJ2"
conf SanJose2 section "interface Loopback0" "ip address 192.168.2.1 255.255.255.0" ! points=1
msg="IP na loopback0, SJ2"
conf SanJose2 section "interface Serial0/0" "172.16.0.2 255.255.255.252" ! points=1 msg="IP na
serial0/0, SJ2"
conf ISP2 hostname ISP2 ! points=1 msg="hostname, ISP2"
conf ISP2 section "interface Serial0/0" "ip address 172.16.0.1 255.255.255.252" ! points=1 msg="IP
na serial0/0, ISP2"
conf ISP2 section "interface Loopback0" "ip address 172.16.1.1 255.255.255.0" ! points=1 msg="IP
na loopback0, ISP2"
max ! msg="variable testing"
and ! points=30 msg="functional testing"
exec ISP1 status "ip route" 192.168.0.0 ! type=bgp msg="route 192.168.0.0 from customer at ISP1,
ISP1"
exec ISP1 status "ip route" 192.168.1.0 ! type=bgp msg="route 192.168.1.0 from customer at ISP1,
ISP1"
exec ISP1 status "ip route" 192.168.2.0 ! type=bgp msg="route 192.168.2.0 from customer at ISP1,
ISP1"
75
exec ISP2 status "ip route" 192.168.0.0 ! type=bgp msg="route 192.168.0.0 from customer at ISP2,
ISP2"
exec ISP2 status "ip route" 192.168.1.0 ! type=bgp msg="route 192.168.1.0 from customer at ISP2,
ISP2"
exec ISP2 status "ip route" 192.168.2.0 ! type=bgp msg="route 192.168.2.0 from customer at ISP2,
ISP2"
and ! points=10 msg="zablokovanie routy 12.0.1.0, ISP2"
~exec ISP2 status "ip route" 12.0.1.0 ! type=bgp
exec SanJose2 status "ip route" 12.0.1.0 ! type=bgp
end
and ! points=10 msg="zablokovanie routy 172.16.10.0, ISP1"
~exec ISP1 status "ip route" 172.16.1.0 ! type=bgp
exec SanJose1 status "ip route" 172.16.1.0 ! type=bgp
end
end
sum ! msg="configuration testing"
conf ISP1 section "router bgp 200" "neighbor 10.0.0.2 remote-as 100" ! points=1 msg="neighbor SJ1
statement, ISP1"
conf ISP1 section "router bgp 200" "network 12.0.1.0 mask 255.255.255.0" ! points=1 msg="bgp
network 12.0.1.0, ISP1"
conf SanJose1 section "router bgp 100" "neighbor 10.0.0.1 remote-as 200" ! points=1 msg="neighbor
ISP1 statement, SJ1"
conf SanJose1 section "router bgp 100" "network 192.168.1.0" ! points=1 msg="network 192.168.1.0,
SJ1"
conf SanJose1 section "router bgp 100" "neighbor 10.10.10.2 remote-as 100" ! points=1
msg="neighbor SJ2, SJ1"
76
conf SanJose1 section "router bgp 100" "neighbor 192.168.64.2 remote-as 100" ! points=1
msg="neighbor Westasman, SJ1"
conf SanJose1 section "router bgp 100" "neighbor 10.10.10.2 next-hop-self" ! points=1 msg="next-
hop-self SJ2, SJ1"
conf SanJose1 section "router bgp 100" "neighbor 10.0.0.1 distribute-list 1 out" ! points=1
msg="neighbor ISP1, SJ1"
conf SanJose1 section "router bgp 100" "neighbor 192.168.64.2 next-hop-self" ! points=1
msg="next-hop-self WestasMan, SJ1"
conf SanJose1 section "router ospf" "network 192.168.64." ! points=1 msg="network 192.168.64.0 ,
SJ1"
conf SanJose1 regexp access-list 1 permit 192.168.0.0 0.0 ! points=1 msg="access-list 192.168.0.0
siete zakaznika , SJ1"
conf WESTASMAN section "router bgp 100" "neighbor 192.168.64.1 remote-as 100" ! points=1
msg="neighbor SJ1, WESTASMAN"
conf WESTASMAN section "router bgp 100" "network 192.168.0.0" ! points=1 msg="network
192.168.0.0, WESTAMAN"
conf WESTASMAN section "router bgp 100" "neighbor 10.10.10.2 remote-as 100" ! points=1
msg="neighbor SJ2, WESTASMAN"
exec WESTASMAN show "ip ospf neighbor" FastEthernet1/0 ! points=1 msg="ospf neighbor SJ2,
WESTAMAN"
exec WESTASMAN show "ip ospf neighbor" Serial0/0 ! points=1 msg="ospf neighbor SJ1,
WESTASMAN"
conf SanJose2 section "router bgp 100" "172.16.0.1 remote-as 300" ! points=1 msg="neighbor ISP2,
SJ2"
conf SanJose2 section "router bgp 100" "network 192.168.2.0" ! points=1 msg="network
192.168.2.0, SJ2"
conf SanJose2 section "router bgp 100" "neighbor 10.10.10.1 remote-as 100" ! points=1
msg="neighbor WestasMan, SJ2"
conf SanJose2 section "router bgp 100" "neighbor 192.168.64.1 remote-as 100" ! points=1
msg="neighbor SJ1, SJ2"
77
conf SanJose2 section "router bgp 100" "neighbor 10.10.10.1 next-hop-self" ! points=1 msg="next-
hop-self WestasMan, SJ2"
conf SanJose2 section "router bgp 100" "neighbor 192.168.64.1 next-hop-self" ! points=1
msg="next-hop-self SJ1, SJ2"
conf SanJose2 section "router ospf" "network 10.10.10." ! points=1 msg="network 10.10.10.0, SJ2"
conf ISP2 section "router bgp 300" "neighbor 172.16.0.2 remote-as 100" ! points=1 msg="neighbor
SJ2, ISP2"
conf ISP2 section "router bgp 300" "172.16.1.0 mask 255.255.255.0" ! points=1 msg="network
172.16.1.0, ISP2"
end
print Max points: 48
print Earned points:
9.2.4 Výpis pri dosiahnutí plného počtu bodov
hostname, ISP1: 1/1
IP na serial0/0, ISP1: 1/1
IP na loopback0, ISP1: 1/1
hostname , SJ1: 1/1
IP na serial0/0, SJ1: 1/1
IP na loopback0, SJ1: 1/1
serial0/1, SJ1: 1/1
hostname, WESTAMAN: 1/1
IP na fastethernet1/0, WESTAMAN: 1/1
IP na Loopback0, WESTAMAN: 1/1
IP na Serial0/0, WESTAMAN: 1/1
hostname, SJ2: 1/1
IP na fastethernet1/0, SJ2: 1/1
IP na loopback0, SJ2: 1/1
IP na serial0/0, SJ2: 1/1
hostname, ISP2: 1/1
78
IP na serial0/0, ISP2: 1/1
IP na loopback0, ISP2: 1/1
MAX variable testing = 30.0 pts: functional testing: 30.0/30.0
route 192.168.0.0 from customer at ISP1, ISP1: 0/0
route 192.168.1.0 from customer at ISP1, ISP1: 0/0
route 192.168.2.0 from customer at ISP1, ISP1: 0/0
route 192.168.0.0 from customer at ISP2, ISP2: 0/0
route 192.168.1.0 from customer at ISP2, ISP2: 0/0
route 192.168.2.0 from customer at ISP2, ISP2: 0/0
zablokovanie routy 12.0.1.0, ISP2: 10.0/10.0
zablokovanie routy 172.16.10.0, ISP1: 10.0/10.0
variable testing: 30.0/30.0
Max points: 48
Earned points:
48
9.3 Vytvorenie testovania pre IBGP and EBGP
9.3.1 Zadanie úlohy IBGP and EBGP
79
Objective
In this lab, the student will configure both IBGP and EBGP. In order for IBGP peers to correctly exchange routing information, the next-hop-self command must be used. Use of
LOCAL-PREFERENCE and MED attributes must also be used. This is to insure that the flat
rate unlimited use T1 link is used for sending and receiving data to and from the AS 200 on ISP. The metered T1 should only be used in the event that the primary T1 link has failed. Traffic sent across the metered T1 link offers the same bandwidth of the primary link but at a huge expense. Insure that this link is not used unnecessarily.
Note: Lo0 interface on SanJose routers is designed to be used as router ID and for BGP peering Lo1 interfaces are designed to represent two internal LANs in ITA network.
Scenario
The International Travel Agency runs BGP on its SanJose1 and SanJose2 routers externally with ISP1, AS 200. IBGP is run internally between SanJose1 and SanJose2. The job is to configure both EBGP and IBGP for this internetwork to allow for redundancy.
Step 1
Build and configure the network according to the diagram, but do not configure a routing protocol. Configure a loopback1 interface on the SanJose1 and SanJose2 routers as shown. These loopbacks will be used with BGP neighbor statements for increased stability.
80
Use ping to test connectivity between the directly connected routers.
Step 2
Configure EIGRP between the SanJose1 and SanJose2 routers with the same commands as follows:
SanJose(config)#router eigrp 64512
SanJose(config-router)#network 172.16.0.0
Because loopback interface also belong 172.16.0.0 network, but do not need EIGRP to be run on them, add passive-interface commands to prevent EIGRP from consuming
additional resources on router.
Step 3
Configure IBGP between the SanJose1 and SanJose2 routers. On the SanJose1 router,
enter the following configuration:
SanJose1(config)# router bgp 64512
SanJose1(config-router)# no auto-summary
SanJose1(config-router)# neighbor 172.16.32.1 remote-as 64512
SanJose1(config-router)# neighbor 172.16.32.1 update-source lo0
This topology uses VLSM. Therefore, automatic summarization along classful boundaries, should be disabled with the no auto-summary command.
If multiple pathways to the neighbor exist, then the router can use any IP interface to communicate by way of BGP. The update-source lo0 command instructs the router to
use interface loopback 0 for TCP connections. This command will offer greater fault tolerance in the event that one of the potentially numerous links within the corporate EIGRP WAN cloud fails.
Verify that SanJose1 and SanJose2 become BGP neighbors by issuing the show ip bgp
summary command. If the BGP state is not established, troubleshoot the connection.
Because IBGP will eventually advertise networks that might not be a part of the EIGRP
172.16.0.0 network, the following command should be entered on SanJose1 and SanJose2:
SanJose1(config)# router bgp 64512
SanJose1(config-router)#no synchronization
SanJose2(config)# router bgp 64512
SanJose2(config-router)#no synchronization
The no synchronization command permits BGP to advertise networks regardless of
whether EIGRP knows of the network. Usually, a BGP speaker does not advertise a route to
an external neighbor unless that route is local or exists in the IGP.
Step 4
Configure ISP1 to run EBGP with SanJose1 and SanJose2. Enter the following commands on ISP1 as shown in the following:
81
ISP1(config)# router bgp 200
ISP1(config-router)# no auto-summary
ISP1(config-router)# neighbor 192.168.1.6 remote-as 64512
ISP1(config-router)# neighbor 192.168.1.2 remote-as 64512
ISP1(config-router)# network 192.168.100.0
Because EBGP sessions are almost always established over point-to-point links, there is no reason to use the update-source keyword in this configuration. Only one path exists
between the peers. If this path goes down, alternative paths are not available.
Step 5
Configure EBGP between the SanJose1, SanJose2 and ISP1 routers. On the SanJose1
router, enter the following configuration:
SanJose1(config)# router bgp 64512
SanJose1(config-router)# neighbor 192.168.1.5 remote-as 200
SanJose1(config-router)# network 172.16.0.0
Use the show ip bgp summary command to verify that EBGP sessions have reached the
Established state. Troubleshoot, if necessary.
Step 6
Test whether ISP1 can ping the Loopback 0 address of 172.16.64.1 from SanJose1, as well as the serial link between SanJose1 and SanJose2, 172.16.1.1.
Now ping from ISP1 to the Loopback 0 address of 172.16.32.1 from SanJose2, as well as the
serial link between SanJose1 and SanJose2. This time try 172.16.1.2.
Successful pings should be seen to each IP address on SanJose2 router. Ping attempts to
the 172.16.64.1 and 172.16.1.1 should fail. If the ping to these two addresses works, use clear ip bgp * on ISP1 router.
1. Why is this the case?
Now try extended ping with source IP address of 192.18.100.1. Does it work? Why or why not?
Notice that ISP1 has two valid routes to the 172.16.0.0 network, indicated by the *. However,
the link to SanJose2, the metered T1, has been selected as the best path. While that may be better for the ISP, a premium will be paid for each megabyte transferred across this link.
2. Was this a malicious attempt by the ISP to get more money? Why did the ISP prefer the link to SanJose2 over SanJose1? 3. Would changing the bandwidth metric on each link help to correct this issue?
82
BGP operates differently than all other protocols. Unlike other routing protocols which may use complex algorithms involving factors such as bandwidth, delay, reliability, and load to formulate a metric, BGP is policy-based. BGP will determine the best path based upon variables such as, AS_Path, Weight, Local Preference, MED, and so on. All things being
equal, as in this case, BGP will prefer the route leading to the BGP speaker with the lowest IP address. This was not a malicious attempt by the ISP to get additional funds. In fact, this ISP1 router was configured from the beginning. The SanJose2 router with address 192.168.1.2 was preferred to the higher IP address of the SanJose1 router, 192.168.1.6.
At this point, the ISP1 router should be able to get to each network connected to SanJose1 and SanJose2 from the FastEthernet address 192.168.100.1. Verify the complete reachability using extended ping.
ISP1# ping 172.16.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.1.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
ISP1# ping 172.16.64.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.64.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
Step 7
Before the ISP can successfully ping the internal serial interfaces of AS 64512, two issues need to be resolved. First, SanJose1 does not know about the link between the ISP and SanJose2. Second, SanJose2 is unaware of the link between the ISP and SanJose1. This can be resolved by an advertisement of these serial links by way of BGP on the ISP router. This can also be resolved by way of EIGRP on each of the SanJose routers. The preferred method
is for the ISP to advertise these links. If they are advertised and then, at a future date, a BGP link is activated to another ISP in addition to ISP1 at AS 200, then there is a risk of becoming a Transit AS.
The next issue to consider is BGP policy routing between AS systems. BGP routers do not
increment the next hop address to their IBGP peers. The SanJose2 router is passing a policy
to SanJose1 and vice versa. The policy for routing from AS 64512 to AS 200 is to forward
packets to the 192.168.1.1 interface. SanJose1 has a similar yet opposite policy, forwarding
requests to the 192.168.1.5 interface. In the event that either WAN link fails, it is critical that the opposite router become a valid gateway. This is only achieved if the next-hop-self
command is configured on SanJose1 and SanJose2.
Before the next-hop-self command was issued:
SanJose2# show ip bgp
BGP table version is 3, local router ID is 172.16.32.1
Status codes: s suppressed, d damped, h history, * valid, > best, i – internal
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 172.16.0.0 0.0.0.0 0 32768 i
* i 172.16.64.1 0 100 0 i
*> 192.168.100.0 192.168.1.1 0 0 200 i
* i 192.168.1.5 0 100 0 200 i
83
SanJose1(config)# router bgp 64512
SanJose1(config-router)# neighbor 172.16.32.1 next-hop-self
SanJose2(config)# router bgp 64512
SanJose2(config-router)# neighbor 172.16.64.1 next-hop-self
After issuing these commands, reset BGP operation on either router by entering the command clear ip bgp *.
After the routers have returned to established BGP speakers, issue the show ip bgp
command to validate that the next hop has also been corrected.
SanJose2# show ip bgp
BGP table version is 3, local router ID is 172.16.32.1
Status codes: s suppressed, d damped, h history, * valid, > best, i – internal
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
* i172.16.0.0 172.16.64.1 0 100 0 i
*> 0.0.0.0 0 32768 i
* i192.168.100.0 172.16.64.1 0 100 0 200 i
*> 192.168.1.1 0 100 0 200 i
Step 8
At this point, everything looks good with the exception of default routes, the outbound flow of data, and inbound packet flow.
Since the local preference value is shared between IBGP neighbors, configure a simple route-map that references local preference value on SanJose1 and SanJose2. This policy will adjust outbound traffic to prefer the link off the SanJose1 router instead of the metered T1 off SanJose2.
Issue the following commands on SanJose1 and SanJose2 respectively:
SanJose1(config)# route-map PRIMARY_T1_IN permit 10
SanJose1(config-route-map)# set local-preference 150
SanJose1(config-route-map)# exit
SanJose1(config)# router bgp 64512
SanJose1(config-router)# neighbor 192.168.1.5 route-map PRIMARY_T1_IN
in
SanJose2(config)# route-map SECONDARY_T1_IN permit 10
SanJose2(config-route-map)# set local-preference 125
SanJose2(config-route-map)# router bgp 64512
SanJose2(config-router)# neighbor 192.168.1.1 route-map SECONDARY_T1_IN
in
Do not forget to use the command clear ip bgp * after configuring this new policy. Once
the conversations have been re-established, issue the show ip bgp command on
SanJose1 and SanJose2. Verify that routing to the FastEthernet segment for ISP1, 192.168.100.0 /24, will be reached only through the link common to SanJose1 and ISP1.
Step 9
5. How will traffic return from network 192.168.100.0 /24? Will it be routed through SanJose1 or SanJose2?
84
The simplest solution would be to issue show ip bgp on ISP1 router. What if access was
not given to the ISP router? Would there be a simple way to verify before receiving the monthly bill? Traffic returning from the Internet should not be passed across the metered T1. How can it be checked instantly? Use an extended ping in this situation. Issue the following
command and compare the output to that provided in the following: SanJose2# ping
Protocol [ip]:
Target IP address: 192.168.100.1
Repeat count [5]: 2
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: 172.16.32.1
Type of service [0]:
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]: r
Number of hops [ 9 ]:
Loose, Strict, Record, Timestamp, Verbose[RV]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.100.1, timeout is 2 seconds:
Packet has IP options: Total option bytes= 39, padded length=40
Record route: <*>
(0.0.0.0)
(0.0.0.0)
(0.0.0.0)
(0.0.0.0)
(0.0.0.0)
(0.0.0.0)
(0.0.0.0)
(0.0.0.0)
(0.0.0.0)
Reply to request 0 (12 ms). Received packet has options
Total option bytes= 40, padded length=40
Record route:
(172.16.2.2)
(192.168.1.6)
(192.168.100.1)
(192.168.1.5)
(172.16.2.1)
(172.16.32.1) <*>
(0.0.0.0)
(0.0.0.0)
(0.0.0.0)
End of list
Reply to request 1 (8 ms). Received packet has options
Total option bytes= 40, padded length=40
Record route:
(172.16.2.2)
(192.168.1.6)
(192.168.100.1)
(192.168.1.5)
(172.16.2.1)
(172.16.32.1) <*>
(0.0.0.0)
(0.0.0.0)
(0.0.0.0)
End of list
85
If the record option has not been used prior to this, the important thing to note is that each of the IP addresses in brackets is an outgoing interface. The output can be interpreted as follows:
1. A ping that is sourced from 172.16.32.1 will exit SanJose2 through s0/0, 172.16.1.2. It will then arrive at the S0/1 interface for SanJose1. 2. SanJose1 S0/0, 192.168.1.6, routes the packet out to arrive at the S0/0 interface of ISP1. 3. The target of 192.168.100.1 is reached, 192.168.100.1. 4. The packet is next forwarded out the S0/1, 192.168.1.1, interface for ISP1 and arrives at the S0/1 interface for SanJose2. 5. SanJose2 then forwards the packet out the last interface, Loopback 0, 172.16.32.1.
Although the unlimited use of the T1 from SanJose1 is preferred here, the ISP prefers the link
from SanJose2 for all return traffic.
The next step is to create a new policy to force the ISP to return all traffic via SanJose1. Create a second route-map utilizing the MED (metric) which is shared between EBGP neighbors.
SanJose1(config)# route-map PRIMARY_T1_MED_OUT permit 10
SanJose1(config-route-map)# set Metric 50
SanJose1(config-route-map)# exit
SanJose1(config)# router bgp 64512
SanJose1(config-router)# neighbor 192.168.1.5 route-map
PRIMARY_T1_MED_OUT out
SanJose2(config)# route-map SECONDARY_T1_MED_OUT permit 10
SanJose2(config-route-map)# set Metric 75
SanJose2(config-route-map)# exit
SanJose2(config)# router bgp 64512
SanJose2(config-router)# neighbor 192.168.1.1 route-map
SECONDARY_T1_MED_OUT out
As before, do not forget to clear ip bgp * after issuing this new policy. Issuing the show
ip bgp command as follows on SanJose1 or SanJose2 will not indicate anything about this
newly defined policy Now reissue an extended ping with a record command as follows:
SanJose2# ping
Protocol [ip]:
Target IP address: 192.168.100.1
Repeat count [5]: 2
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: 172.16.32.1
Type of service [0]:
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]: record
86
Number of hops [ 9 ]:
Loose, Strict, Record, Timestamp, Verbose[RV]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.100.1, timeout is 2 seconds:
Packet has IP options: Total option bytes= 39, padded length=40
Record route: <*>
(0.0.0.0)
(0.0.0.0)
(0.0.0.0)
(0.0.0.0)
(0.0.0.0)
(0.0.0.0)
(0.0.0.0)
(0.0.0.0)
(0.0.0.0)
Reply to request 0 (8 ms). Received packet has options
Total option bytes= 40, padded length=40
Record route:
(172.16.2.2)
(192.168.1.6)
(192.168.100.1)
(192.168.1.5)
(172.16.2.1)
(172.16.32.1) <*>
(0.0.0.0)
(0.0.0.0)
(0.0.0.0)
End of list
Reply to request 1 (8 ms). Received packet has optionsTotal option bytes= 40, padded
length=40
Record route:
(172.16.1.2)
(192.168.1.6)
(192.168.100.1)
(192.168.1.5)
(172.16.2.1)
(172.16.32.1) <*>
(0.0.0.0)
(0.0.0.0)
(0.0.0.0)
End of list
6. Does the output look correct? Does the 192.168.1.5 above mean that the ISP1 will now prefer SanJose1 for return traffic?
There will not be a chance to telnet to the ISP router and to issue the show ip bgp
command. However, the command on the opposite side of the newly configured policy MED is clear, showing that the lower value is considered best. The ISP now prefers the route with
the lower MED value to AS 64512. This is just opposite from the local-preference knob configured earlier.
Step 10
The final step is to establish a default route that uses a policy statement that will adjust to
changes in the network. Configure both SanJose1 and SanJose2 to use the 192.168.100.0 /24 network as the default network. The output that follows includes the routing table before the command was issued, the actual command syntax, and then the routing table after the command was issued. Complete the same task on the SanJose2 router.
87
SanJose1# show ip route ****Note: Prior to Default-Network Statement****
Gateway of last resort is not set
172.16.0.0/16 is variably subnetted, 4 subnets, 2 masks
D 172.16.32.0/24 [90/20640000] via 172.16.1.2, 02:43:46, Serial0/1
B 172.16.0.0/16 [200/0] via 172.16.32.1, 00:12:32
C 172.16.1.0/24 is directly connected, Serial0/1
C 172.16.64.0/24 is directly connected, Loopback0
192.168.1.0/30 is subnetted, 2 subnets
B 192.168.1.0 [20/0] via 192.168.1.5, 00:14:05
C 192.168.1.4 is directly connected, Serial0/0
B 192.168.100.0/24 [20/0] via 192.168.1.5, 00:14:05
SanJose1(config)# ip default-network 192.168.100.0
SanJose1# show ip route
Gateway of last resort is 192.168.1.5 to network 192.168.100.0
172.16.0.0/16 is variably subnetted, 4 subnets, 2 masks
D 172.16.32.0/24 [90/20640000] via 172.16.1.2, 02:44:09, Serial0/1
B 172.16.0.0/16 [200/0] via 172.16.32.1, 00:12:55
C 172.16.1.0/24 is directly connected, Serial0/1
C 172.16.64.0/24 is directly connected, Loopback0
192.168.1.0/30 is subnetted, 2 subnets
B 192.168.1.0 [20/0] via 192.168.1.5, 00:14:28
C 192.168.1.4 is directly connected, Serial0/0
B* 192.168.100.0/24 [20/0] via 192.168.1.5, 00:14:29
What would be required to add a future T3 link on SanJose2 and for this future link to have preference for incoming and outgoing traffic? A newly added route would be as easy as adding another route-map for local-preference with a value of 175 and a route-map referencing a MED (metric) value of 35. You would then issue the clear ip bgp * command and this lab is then completed.
9.3.2 Vzorová konfigurácia
SanJose1
hostname SanJose1
interface Loopback0
ip address 172.16.64.1 255.255.255.255
!
interface Loopback1
ip address 172.16.3.1 255.255.255.0
!
interface Serial0/0
88
description ISP1
ip address 192.168.1.6 255.255.255.252
no shutdown
interface Serial0/1
description SJ2
ip address 172.16.1.1 255.255.255.0
no shut
interface FastEthernet1/0
description SJ2-2
ip address 172.16.2.1 255.255.255.0
no shutdown
router eigrp 64512
passive-interface Loopback0
passive-interface Loopback1
network 172.16.0.0
no auto-summary
!
router bgp 64512
no synchronization
bgp log-neighbor-changes
network 172.16.0.0
network 172.16.64.1 mask 255.255.255.255
neighbor 172.16.32.1 remote-as 64512
neighbor 172.16.32.1 update-source Loopback0
neighbor 172.16.32.1 next-hop-self
neighbor 192.168.1.5 remote-as 200
neighbor 192.168.1.5 route-map PRIMARY_T1_IN in
neighbor 192.168.1.5 route-map PRIMARY_T1_MED_OUT out
no auto-summary
!
route-map PRIMARY_T1_IN permit 10
set local-preference 150
!
89
route-map PRIMARY_T1_MED_OUT permit 10
set metric 50
!
SanJose2
hostname SanJose2
interface Loopback0
ip address 172.16.32.1 255.255.255.255
!
interface Loopback1
ip address 172.16.4.1 255.255.255.0
!
interface Serial0/0
description SJ1
ip address 172.16.1.2 255.255.255.0
no shut
!
interface Serial0/1
description ISP1
ip address 192.168.1.2 255.255.255.252
no shut
!
interface FastEthernet1/0
description SJ1-2
ip address 172.16.2.2 255.255.255.0
no shutdown
router eigrp 64512
passive-interface Loopback0
passive-interface Loopback1
network 172.16.0.0
no auto-summary
!
90
router bgp 64512
no synchronization
bgp log-neighbor-changes
network 172.16.32.1 mask 255.255.255.255
neighbor 172.16.64.1 remote-as 64512
neighbor 172.16.64.1 update-source Loopback0
neighbor 172.16.64.1 next-hop-self
neighbor 192.168.1.1 remote-as 200
neighbor 192.168.1.1 route-map SECONDARY_T1_IN in
neighbor 192.168.1.1 route-map SECONDARY_T1_MED_OUT out
no auto-summary
!
route-map SECONDARY_T1_IN permit 10
set local-preference 125
!
route-map SECONDARY_T1_MED_OUT permit 10
set metric 75
ISP1
hostname ISP1
interface Serial0/0
ip address 192.168.1.5 255.255.255.252
no shut
!
interface Serial0/1
ip address 192.168.1.1 255.255.255.252
no shut
!
interface FastEthernet1/0
ip address 192.168.100.1 255.255.255.0
no shut
!
91
router bgp 200
no synchronization
bgp log-neighbor-changes
network 192.168.100.0
neighbor 192.168.1.2 remote-as 64512
neighbor 192.168.1.6 remote-as 64512
no auto-summary
!
9.3.3 Navrhnuté testovanie
conf SanJose1 section "interface Loopback0" "ip address 172.16.64.1 255.255.255.255" ! points=1
msg="IP address on Loopback0, SanJose1"
conf SanJose1 section "interface Loopback1" "ip address 172.16.3.1 255.255.255.0" ! points=1
msg="IP address on Loopback1, SanJose1"
conf SanJose1 section "interface Serial0/0" "ip address 192.168.1.6 255.255.255.252" ! points=1
msg="IP address on Serial0/0, SanJose1"
conf SanJose1 section "interface Serial0/1" "ip address 172.16.1.1 255.255.255.0" ! points=1 msg="IP
address on Serial0/1, SanJose1"
conf SanJose1 section "interface FastEthernet1/0" "ip address 172.16.2.1 255.255.255.0" ! points=1
msg="IP address on FastEthernet1/0, SanJose1"
conf SanJose2 section "interface Loopback0" "ip address 172.16.32.1 255.255.255.255" ! points=1
msg="IP address on Loopback0, SanJose2"
conf SanJose2 section "interface Loopback1" "ip address 172.16.4.1 255.255.255.0" ! points=1
msg="IP address on Loopback1, SanJose2"
conf SanJose2 section "interface Serial0/0" "ip address 172.16.1.2 255.255.255.0" ! points=1 msg="IP
address on Serial0/0, SanJose2"
conf SanJose2 section "interface Serial0/1" "ip address 192.168.1.2 255.255.255.252" ! points=1
msg="IP address on Serial0/1, SanJose2"
conf SanJose2 section "interface FastEthernet1/0" "ip address 172.16.2.2 255.255.255." ! points=1
msg="IP address on , SanJose2"
92
conf ISP1 section "interface Serial0/0" "ip address 192.168.1.5 255.255.255.252" ! points=1 msg="IP
address on Serial0/0, ISP1"
conf ISP1 section "interface Serial0/1" "ip address 192.168.1.1 255.255.255.252" ! points=1 msg="IP
address on Serial0/1, ISP1"
conf ISP1 section "interface FastEthernet1/0" "ip address 192.168.100.1 255.255.255.0" ! points=1
msg="IP address on FastEthernet1/0, ISP1"
max ! msg="variable testing"
and ! points=50 msg="functional testing"
exec SanJose1 section show ip bgp 192.168.100.0 "from 192.168.1.5" " localpref 150," ! msg="local
pref of 150 on route 192.168.100.0 from 192.168.1.5, SanJose1"
exec SanJose2 section show ip bgp 192.168.100.0 "from 172.16.64.1" " localpref 150," ! msg="local
pref of 150 on route 192.168.100.0 from 172.16.64.1, SanJose2"
exec SanJose2 section show ip bgp 192.168.100.0 "from 192.168.1.1" " localpref 125," ! msg="local
pref of 125 on route 192.168.100.0 from 192.168.1.1, SanJose2"
exec ISP1 section show ip bgp 172.16.32.1 "from 192.168.1.6" " metric 50," ! msg="metric of 50 on
route 172.16.32.1 from 192.168.1.6, ISP1"
exec ISP1 section show ip bgp 172.16.32.1 "from 192.168.1.2" " metric 75," ! msg="metric of 75 on
route 172.16.32.1 from 192.168.1.2, ISP1"
exec ISP1 section show ip bgp 172.16.64.1 "from 192.168.1.2" " metric 75," !msg="metric of 75 on
route 172.16.64.1 from 192.168.1.2, ISP1"
exec ISP1 section show ip bgp 172.16.64.1 "from 192.168.1.6" " metric 50," ! msg="metric of 50 on
route 172.16.64.1 from 192.168.1.6, ISP1"
exec ISP1 show "ip bgp nei" 'BGP neighbor is 192.168.1.6, remote AS 64512, external link' !
msg="BGP neighbor SJ1 192.168.1.6 AS 64512 external, ISP1"
exec ISP1 show "ip bgp summ" 192.168.1.6 ! points=1 msg="BGP route 192.168.1.6 as neighbor,
ISP1"
93
exec ISP1 show "ip bgp nei" 'BGP neighbor is 192.168.1.2, remote AS 64512, external link' !
msg="BGP neighbor SJ2 192.168.1.2 AS 64512 external, ISP1"
exec SanJose1 show "ip bgp nei" 'BGP neighbor is 192.168.1.5, remote AS 200, external link' !
msg="BGP neighbor ISP1 192.168.1.5 AS 200 external, SanJose1"
exec SanJose1 show "ip bgp nei" 'BGP neighbor is 172.16.32.1, remote AS 64512, internal link' !
msg="BGP neighbor SJ2 172.16.32.1 AS 64512 internal, SanJose1"
exec SanJose2 show "ip bgp nei" 'BGP neighbor is 172.16.64.1, remote AS 64512, internal link' !
msg="BGP neighbor SJ1 172.16.64.4 AS 64512 external, SanJose2"
exec SanJose2 show "ip bgp nei" 'BGP neighbor is 192.168.1.1, remote AS 200, external link' !
msg="BGP neighbor ISP1 192.168.1.1 AS 200 external, SanJose2"
end
sum ! msg="configuration testing"
#SanJose1
conf SanJose1 regexp router eigrp 64512 ! points=1 msg="EIGRP AS 64512, SanJose1"
conf SanJose1 section "router eigrp" "passive-interface Loopback0" ! points=1 msg="EIGRP passive-
interface Loopback0, SanJose1"
conf SanJose1 section "router eigrp" "passive-interface Loopback1" ! points=1 msg="passive-
interface Loopback1, SanJose1"
conf SanJose1 section "router eigrp" "network 172.16." ! points=1 msg="EIGRP network 172.16.0.0,
SanJose1"
conf SanJose1 section "router eigrp" "no auto-summary" ! points=1 msg="EIGRP no auto-summary,
SanJose1"
conf SanJose1 section "router bgp" "network 172.16.64.1 mask 255.255.255.255" ! points=1
msg="BGP network 172.16.64.1 mask 255.255.255.255, SanJose1"
conf SanJose1 section "router bgp" "neighbor 172.16.32.1 remote-as 64512" ! points=1
msg="neighbor 172.16.32.1 remote-as 64512 , SanJose1"
conf SanJose1 section "router bgp" "neighbor 172.16.32.1 update-source Loopback0" ! points=1
msg="neighbor 172.16.32.1 update-source Loopback0, SanJose1"
94
conf SanJose1 section "router bgp" "neighbor 172.16.32.1 next-hop-self" ! points=1 msg="neighbor
172.16.32.1 next-hop-self , SanJose1"
conf SanJose1 section "router bgp" "neighbor 192.168.1.5 remote-as 200" ! points=1
msg="192.168.1.5 remote-as 200, SanJose1"
conf SanJose1 section "router bgp" "neighbor 192.168.1.5 route-map PRIMARY_T1_IN in" ! points=1
msg="route-map PRIMARY_T1_IN in from neighbor 192.168.1.5, SanJose1"
conf SanJose1 section "router bgp" "neighbor 192.168.1.5 route-map PRIMARY_T1_MED_OUT out" !
points=1 msg="route-map PRIMARY_T1_MED_OUT out to 192.168.1.5, SanJose1"
conf SanJose1 regexp route-map PRIMARY_T1_IN permit ! points=1 msg="defined route-map
PRIMARY_T1_IN, SanJose1"
conf SanJose1 section "route-map PRIMARY_T1_IN permit" "set local-preference 150" ! points=1
msg="defined local pref in route-map PRIMARY_T1_IN, SanJose1"
conf SanJose1 regexp route-map PRIMARY_T1_MED_OUT ! points=1 msg="defined route-map
PRIMARY_T1_MED_OUT, SanJose1"
conf SanJose1 section "route-map PRIMARY_T1_MED_OUT permit 10" "set metric 50" ! points=1
msg="defined metric in route-map PRIMARY_T1_MED_OUT, SanJose1"
#SanJose2
conf SanJose2 regexp router eigrp 64512 ! points=1 msg="EIGRP AS 64512, SanJose2"
conf SanJose2 section "router eigrp" "passive-interface Loopback0" ! points=1 msg="EIGRP passive-
interface Loopback0, SanJose2"
conf SanJose2 section "router eigrp" "passive-interface Loopback1" ! points=1 msg="EIGRP passive-
interface Loopback1, SanJose2"
conf SanJose2 section "router eigrp" "network 172.16." ! points=1 msg="EIGRP network 172.16.0.0,
SanJose2"
conf SanJose2 section "router eigrp" "no auto-summary" ! points=1 msg="EIGRP no auto-summary,
SanJose2"
conf SanJose2 section "router bgp" "network 172.16.32.1 mask 255.255.255.255" ! points=1
msg="BGP network 172.16.32.1 mask 255.255.255.255, SanJose2"
conf SanJose2 section "router bgp" "neighbor 172.16.64.1 remote-as 64512" ! points=1 msg="BGP
neighbor 172.16.64.1 remote-as 64512, SanJose2"
95
conf SanJose2 section "router bgp" "neighbor 172.16.64.1 update-source Loopback0" ! points=1
msg="BGP neighbor 172.16.64.1 update-source Loopback0, SanJose2"
conf SanJose2 section "router bgp" "neighbor 172.16.64.1 next-hop-self" ! points=1 msg="BGP
neighbor 172.16.64.1 next-hop-self, SanJose2"
conf SanJose2 section "router bgp" "neighbor 192.168.1.1 remote-as 200" ! points=1 msg="BGP
neighbor 192.168.1.1 remote-as 200, SanJose2"
conf SanJose2 section "router bgp" "neighbor 192.168.1.1 route-map SECONDARY_T1_IN in" !
points=1 msg="BGP route-map SECONDARY_T1_IN in from neighbor 192.168.1.1, SanJose2"
conf SanJose2 section "router bgp" "neighbor 192.168.1.1 route-map SECONDARY_T1_MED_OUT
out" ! points=1 msg="BGP route-map SECONDARY_T1_MED_OUT out from neighbor 192.168.1.1,
SanJose2"
conf SanJose2 regexp route-map SECONDARY_T1_IN permit ! points=1 msg="defined route-map
SECONDARY_T1_IN, SanJose2"
conf SanJose2 section "route-map SECONDARY_T1_IN permit" "set local-preference 125" ! points=1
msg="defined local pref in route-map SECONDARY_T1_IN, SanJose2"
conf SanJose2 regexp route-map SECONDARY_T1_MED_OUT permit ! points=1 msg="defined route-
map SECONDARY_T1_MED_OUT, SanJose2"
conf SanJose2 section "route-map SECONDARY_T1_MED_OUT permit 10" "set metric 75" ! points=1
msg="defined metric in route-map SECONDARY_T1_MED_OUT, SanJose2"
#ISP1
conf ISP1 section "router bgp 200" "network 192.168.100.0" ! points=1 msg="BGP network
192.168.100.0, ISP1"
conf ISP1 section "router bgp 200" "neighbor 192.168.1.2 remote-as 64512" ! points=1 msg="BGP
neighbor 192.168.1.2 remote-as 64512, ISP1"
conf ISP1 section "router bgp 200" "neighbor 192.168.1.6 remote-as 64512" ! points=1 msg="BGP
neighbor 192.168.1.6 remote-as 64512, ISP1"
end
end
96
print Max points: 63
print Earned points:
9.3.4 Výpis pri dosiahnutí plného počtu bodov
IP address on Loopback0, SanJose1: 1/1
IP address on Loopback1, SanJose1: 1/1
IP address on Serial0/0, SanJose1: 1/1
IP address on Serial0/1, SanJose1: 1/1
IP address on FastEthernet1/0, SanJose1: 1/1
IP address on Loopback0, SanJose2: 1/1
IP address on Loopback1, SanJose2: 1/1
IP address on Serial0/0, SanJose2: 1/1
IP address on Serial0/1, SanJose2: 1/1
IP address on , SanJose2: 1/1
IP address on Serial0/0, ISP1: 1/1
IP address on Serial0/1, ISP1: 1/1
IP address on FastEthernet1/0, ISP1: 1/1
MAX variable testing = 50.0 pts: functional testing: 50.0/50.0
local pref of 150 on route 192.168.100.0 from 192.168.1.5, SanJose1: 0/0
local pref of 150 on route 192.168.100.0 from 172.16.64.1, SanJose2: 0/0
local pref of 125 on route 192.168.100.0 from 192.168.1.1, SanJose2: 0/0
metric of 50 on route 172.16.32.1 from 192.168.1.6, ISP1: 0/0
metric of 75 on route 172.16.32.1 from 192.168.1.2, ISP1: 0/0
metric of 75 on route 172.16.64.1 from 192.168.1.2, ISP1: 0/0
metric of 50 on route 172.16.64.1 from 192.168.1.6, ISP1: 0/0
BGP neighbor SJ1 192.168.1.6 AS 64512 external, ISP1: 0/0
BGP route 192.168.1.6 as neighbor, ISP1: 1/1
BGP neighbor SJ2 192.168.1.2 AS 64512 external, ISP1: 0/0
BGP neighbor ISP1 192.168.1.5 AS 200 external, SanJose1: 0/0
BGP neighbor SJ2 172.16.32.1 AS 64512 internal, SanJose1: 0/0
BGP neighbor SJ1 172.16.64.4 AS 64512 external, SanJose2: 0/0
97
BGP neighbor ISP1 192.168.1.1 AS 200 external, SanJose2: 0/0
variable testing: 50.0/50.0
Max points: 63
Earned points:
63
