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
105
Embed
počítačovej sietilabss2.fiit.stuba.sk/TeamProject/2010/team08pss/_media/dokument.pdf · Frame Relay jeho podstata spočíva v zriadeí prístupových okruhov a v zriadení virtuálnych
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
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
3 Návrh ............................................................................................................................................. 17
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.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ý),
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:
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:
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:
Configure the SanJose1 and SanJose2 router to run EBGP with both providers. Use the following configuration to establish EBGP sessions with the two providers:
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
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
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
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
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.
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,
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:
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
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
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:
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.
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