FAKULTA INFORMAČNÍCH TECHNOLOGIÍ

ˇ ´ UCEN Í TECHNICKE ´ V BRNE ˇ VYSOKE BRNO UNIVERSITY OF TECHNOLOGY

ˇ ÍCH TECHNOLOGIÍ FAKULTA INFORMACN ˇ ÍCH SYSTEM ´ ´ U ˚ USTAV INFORMACN FACULTY OF INFORMATION TECHNOLOGY DEPARTMENT OF INFORMATION SYSTEMS

´ Í A SIMULACE NAVRHOV ´ ´ ˚ MODELOVAN YCH VZORU ˇ ÍTACOV ˇ ˇ ´ Í V POC ´ SMEROV AN YCH SÍTÍCH

ˇ ´ PRACE ´ BAKALA´ RSK A BACHELOR’S THESIS

´ AUTOR PRACE AUTHOR

BRNO 2009

´ VERONIKA RYBOVA

ˇ Í TECHNICKE ´ V BRNE ˇ VYSOKE´ UCEN BRNO UNIVERSITY OF TECHNOLOGY

ˇ ÍCH TECHNOLOGIÍ FAKULTA INFORMACN ˇ ÍCH SYSTEM ´ ´ U ˚ USTAV INFORMACN FACULTY OF INFORMATION TECHNOLOGY DEPARTMENT OF INFORMATION SYSTEMS

´ Í A SIMULACE NAVRHOV ´ ´ ˚ MODELOVAN YCH VZORU ˇ ÍTACOV ˇ ˇ ´ Í V POC ´ SMEROV AN YCH SÍTÍCH MODELLING AND SIMULATION OF NETWORK DESIGN GUIDES FOR IP ROUTING

ˇ ´ PRACE ´ BAKALA´ RSK A BACHELOR’S THESIS

´ AUTOR PRACE

´ VERONIKA RYBOVA

AUTHOR

´ VEDOUCÍ PRACE SUPERVISOR

BRNO 2009

ˇ Ing. PETR MATOUSEK, Ph.D.

Abstrakt Tato bakal´ aˇrsk´ a pr´ ace se zab´ yv´ a modelován´ım a simulac´ı s´ıt´ı v nástroj´ıch Packet Tracer a OMNeT++. Modely s´ıt´ı jsou vytvoˇreny podle návrhov´ ych vzor˚ u firmy Cisco a zamˇeˇruj´ı se na smˇerovac´ı protokoly RIP, OSPF a redistribuci. Aby byly modely plnˇe funkˇcn´ı, je pro OMNeT++ implementov´ an protokol RIP a redistribuce z protokolu OSPF do protokolu RIP. Praktické vyuˇzit´ı n´ astroj˚ u je ukázáno na simulaci dostupnosti a stability s´ıtˇe. Pr´ ace zkoum´ a v´ ysledky simulac´ı a vyuˇzit´ı obou nástroj˚ u pro simulaci s´ıt´ı. Vyuˇz´ıváme návrhové vzory urˇcené pro n´ avrh smˇerov´ an´ı v reáln´ ych s´ıt´ı a implementujeme protokol podle standardu RFC. Proto pˇredpokl´ ad´ ame praktické vyuˇzit´ı pˇri anal´ yze a simulac´ı firemn´ıch a akademick´ ych poˇc´ıtaˇcov´ ych s´ıt´ı.

Abstract This bachelor’s thesis describes simulation of network using tools Packet Tracer and OMNeT++. Models of network are created according to design guides by Cisco company, which use routing protocols RIP, OSPF and redistribution. In order to provide full functionality of models in OMNeT++ it is necessary to implement protocol RIP and redistribution from protocol OSPF to protocol RIP. Practical usage of tools is demonstrated by simulations of accessibility and stability of network. Thesis investigates results of simulations and usage of both tools for simulation of networks. We use design guides, which are destined to design of real networks, and implement protocol according to standard RFC, therefore we suppose that this thesis will have practical usage for analysis and simulation of company’s and academical networks.

Kl´ıˇ cov´ a slova Simulace s´ıt´ı, modelov´ an´ı s´ıt´ı, anal´ yza s´ıt´ı, RIP, OSPF, OMNeT++, Packet Tracer, Cisco

Keywords Simulation of networks, modelling of networks, analysis of networks, RIP, OSPF, OMNeT++, Packet Tracer, Cisco

Citace Veronika Rybov´ a: Modelov´ an´ı a simulace návrhov´ ych vzor˚ u smˇerován´ı v poˇc´ıtaˇcov´ ych s´ıt´ıch, bakal´ aˇrsk´ a pr´ ace, Brno, FIT VUT v Brnˇe, 2009

Modelov´ an´ı a simulace n´ avrhov´ ych vzor˚ u smˇ erov´ an´ı v poˇ c´ıtaˇ cov´ ych s´ıt´ıch Prohl´ aˇ sen´ı Prohlaˇsuji, ˇze jsem tuto bakal´ aˇrskou práci vypracovala samostatnˇe pod veden´ım pana Ing. Matouˇska, Ph.D. ....................... Veronika Rybov´ a 15. kvˇetna 2009

Podˇ ekov´ an´ı Dˇekuji zejména svému vedouc´ımu Ing. Petru Matouˇskovi, PhD. za odbornou pomoc a stálou ˇcasovou dostupnost. Podˇekov´ an´ı si zaslouˇz´ı i dalˇs´ı kolegové z ANSA t´ ymu, kteˇr´ı mi taktéˇz pˇrispˇeli odborn´ ymi radami. Nakonec bych ráda podˇekovala své rodinˇe a pˇr´ıteli za psychickou podporu pˇri zpracov´ av´ an´ı bakal´ aˇrské práce.

c Veronika Rybov´

a, 2009. Tato pr´ ace vznikla jako ˇskoln´ı d´ılo na Vysokém uˇcen´ı technickém v Brnˇe, Fakultˇe informaˇcn´ıch technologi´ı. Pr´ ace je chr´ anˇena autorským z´ akonem a jej´ı uˇzit´ı bez udˇelen´ı opr´ avnˇen´ı autorem je nez´ akonné, s výjimkou z´ akonem definovaných pˇr´ıpad˚ u.

Obsah ´ Uvod C´ıl pr´ ace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Struktura pr´ ace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Simulaˇ cn´ı n´ astroje 1.1 Modelov´ an´ı a simulace 1.2 N´ astroj Packet Tracer 1.3 N´ astroj OMNeT++ . 1.4 Shrnut´ı kapitoly . . . .

4 4 4

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

6 6 8 12 16

OSPF . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

18 18 19 22 27 29

3 Simulaˇ cn´ı modely 3.1 Simulaˇcn´ı modely v PT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Simulaˇcn´ı modely v OMNeT++ . . . . . . . . . . . . . . . . . . . . . . . . 3.3 Shrnut´ı kapitoly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

31 31 33 35

4 Implementace 4.1 Implementace protokolu RIP . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Implementace redistribuce . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3 Shrnut´ı kapitoly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

36 36 39 39

5 Simulace v prostˇ red´ı Packet Tracer 5.1 Dostupnost . . . . . . . . . . . . . 5.2 Stabilita . . . . . . . . . . . . . . . 5.3 Shrnut´ı kapitoly . . . . . . . . . . .

40 40 45 47

s´ıt´ı . . . . . . . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

2 N´ avrhov´ e vzory se zamˇ eˇ ren´ım na protokoly RIP a 2.1 Smˇerov´ an´ı . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Protokol RIP . . . . . . . . . . . . . . . . . . . . . . 2.3 Protokol OSPF . . . . . . . . . . . . . . . . . . . . . 2.4 N´ avrhové vzory Cisco . . . . . . . . . . . . . . . . . 2.5 Shrnut´ı kapitoly . . . . . . . . . . . . . . . . . . . . .

a . . .

. . . .

. . . .

. . . .

. . . .

OMNeT++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6 V´ ysledky simulac´ı v n´ astroj´ıch OMNeT++ a Packet Tracer 6.1 V´ ysledky simulac´ı . . . . . . . . . . . . . . . . . . . . . . . . . 6.2 Porovn´ an´ı n´ astroj˚ u OMNeT++ a Packet Tracer . . . . . . . . 6.3 Pˇr´ınos simulace pro praktickou anal´ yzu poˇc´ıtaˇcov´ ych s´ıt´ı . . . . 6.4 Shrnut´ı kapitoly . . . . . . . . . . . . . . . . . . . . . . . . . . .

1

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

48 48 50 52 52

Z´ avˇ er Vlastn´ı pˇr´ınos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Dalˇs´ı v´ yvoj . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

53 53 54

A Obsah DVD

57

B Instalaˇ cn´ı pˇ r´ıruˇ cka B.1 Instalace programu PacketTracer 5.0 . . . . . . . . . . . . . . . . . . . . . . B.2 Instalace n´ astroje OMNeT++ . . . . . . . . . . . . . . . . . . . . . . . . . . B.3 Instalace framework INET . . . . . . . . . . . . . . . . . . . . . . . . . . . .

58 58 59 59

C Implementace RIPRouting

60

D Konfiguraˇ cn´ı soubory D.1 Konfiguraˇcn´ı soubor pro OSPF model . . . . . . . . . . . . . . . . . . . . . D.2 Konfiguraˇcn´ı soubor pro RIP model . . . . . . . . . . . . . . . . . . . . . . D.3 Konfiguraˇcn´ı soubor pro redistribuˇcn´ı model . . . . . . . . . . . . . . . . . .

62 62 63 64

2

Seznam obr´ azk˚ u 1.1

Proces modelov´ an´ı a simulace (Z = znalosti; AM = abstraktn´ı model; SM = simulaˇcn´ı model). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Prostˇred´ı programu PT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 Konfiguraˇcn´ı rozhran´ı pˇrep´ınaˇce v PT. . . . . . . . . . . . . . . . . . . . . . 1.4 Rozhran´ı s operaˇcn´ım systémem IOS v PT. . . . . . . . . . . . . . . . . . . 1.5 Z´ akladn´ı informace o zaˇr´ızen´ı v PT. . . . . . . . . . . . . . . . . . . . . . . 1.6 Simulaˇcn´ı m´ od. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7 OSI model PDU v PT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.8 Struktura PDU v PT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.9 Hierarchick´ a struktura modul˚ u. . . . . . . . . . . . . . . . . . . . . . . . . . 1.10 Spojen´ı submodul˚ u mezi sebou a propojen´ı rodiˇcovského modulu se submoduly. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.11 Diagram popisuj´ıc´ı vytvoˇren´ı spustitelného souboru v OMNeT++. . . . . . 1.12 Simulaˇcn´ı prostˇred´ı v OMNeT++. . . . . . . . . . . . . . . . . . . . . . . . Struktura zpr´ avy protokolu RIP. . . . . . . OSPF s´ıt’ bez Designated Router. . . . . . . Struktura OSPF Hello paketu. . . . . . . . S´ıt’ se smˇerovac´ım protokolem RIP. . . . . . RIP s´ıt’ se smˇerovac´ım protokolem OSPF ve S´ıt’ rozdˇelen´ a na OSPF oblasti. . . . . . . .

. . . . . .

22 25 26 28 28 29

3.1 3.2

Topologie s´ıtˇe v PT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Topologie s´ıtˇe v OMNeT++. . . . . . . . . . . . . . . . . . . . . . . . . . .

32 35

4.1 4.2

Modul ANSARouter obsahuj´ıc´ı modul RIP. . . . . . . . . . . . . . . . . . . Diagram aktivit zobrazuj´ıc´ı vztahy mezi metodami ve tˇr´ıdˇe RIPRouting. . .

37 38

5.1 5.2

Topologie simulovan´ı s´ıtˇe. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 V´ ypis pr˚ uchodu ICMP paketu s´ıt’ov´ ymi zaˇr´ızen´ımi. a) Linky jsou v poˇrádku. b) Pˇri cestˇe paketu zpˇet doˇslo k pádu linky. c) Linka mezi R1 a R2 je nefunkˇcn´ı. 41 V´ ypis pr˚ uchodu ICMP paketu s´ıt’ov´ ymi zaˇr´ızen´ımi. ACL na smˇerovaˇci R2 paket zahodil. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

6.1 6.2 6.3

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

14 16 17

2.1 2.2 2.3 2.4 2.5 2.6

5.3

. . . . . . . . . . . . . . . . . . . . stˇredu. . . . . . .

7 9 10 10 11 12 13 13 14

Graf z´ avislosti poˇctu pˇrijat´ ych paket˚ u na ∆t dle tabulky 5.1. . . . . . . . . Graf z´ avislosti pr˚ umˇerného poˇctu pˇrijat´ ych paket˚ u na ∆t dle tabulky 5.2. . Model s´ıtˇe, kterou vyuˇz´ıváme v simulac´ıch. . . . . . . . . . . . . . . . . . .

3

49 50 51

´ Uvod Tato pr´ ace popisuje moˇznosti simulace s´ıt´ı a to zejména za u ´ˇcelem zjiˇstˇen´ı chován´ı s´ıtˇe za r˚ uzn´ ych okolnost´ı. Zamˇeˇruje se pˇredevˇs´ım na simulaci smˇerovac´ıch protokol˚ u a to konkrétnˇe RIP a OSPF, které se v dneˇsn´ı dobˇe ve firmách nejˇcastˇeji vyuˇz´ıvaj´ı. Pro tyto u ´ˇcely vyuˇzijeme simulaˇcn´ı n´ astroje Packet Tracer a OMNeT++ a na vybran´ ych vhodn´ ych topologi´ıch pˇredvedeme simulaci stav˚ u, ke kter´ ym v rámci smˇerován´ı v s´ıt´ıch bˇeˇznˇe docház´ı. Rozhodneme-li se vytvoˇrit zcela novou s´ıt’, napˇr. pro vznikaj´ıc´ı firmu ˇci jej´ı poboˇcku, m˚ uˇze b´ yt n´ aroˇcné zjiˇst’ovat, jaké s´ıt’ové prvky, jaké jejich nastaven´ı a jaká topologie jsou pro ni nejvhodnˇejˇs´ı. Zakoupen´ı r˚ uzn´ ych druh˚ u s´ıt’ov´ ych prvk˚ u a následné experimentov´ an´ı s c´ılem dos´ ahnout, co nejv´ yhodnˇejˇs´ı topologie a konfigurace, je finanˇcnˇe i ˇcasovˇe nároˇcné. Podobnˇe zjiˇst’ov´ an´ı parametr˚ u u jiˇz existuj´ıc´ı s´ıtˇe nen´ı lehk´ y u ´kol. Testovat takovou s´ıt’ za chodu m˚ uˇze zp˚ usobovat problémy, obzvláˇstˇe pokud se rozhodneme zjiˇst’ovat, jak bude reagovat s´ıt’ pˇri p´ adu nˇekolika smˇerovaˇc˚ u pˇri maximáln´ım zat´ıˇzen´ı s´ıtˇe. To sebou nese problémy nejen s uˇzivateli této s´ıtˇe, ale firmˇe m˚ uˇze také pˇrinést nechtˇené finanˇcn´ı ztráty. Jako nejlevnˇejˇs´ım a nejefektivnˇejˇs´ım ˇreˇsen´ı se jev´ı vyuˇzit´ı simulace s´ıtˇe. V simulaˇcn´ım nástroji m˚ uˇzeme modelovat aktuáln´ı nebo zam´ yˇslenou topologii s´ıtˇe a podrobit ji sérii nejr˚ uznˇejˇs´ıch test˚ u. Dneˇsn´ı simulaˇcn´ı nástroje vˇetˇsinou podporuj´ı i grafické uˇzivatelské rozhran´ı, d´ıky kterému je moˇzné vizuálnˇe sledovat chován´ı s´ıtˇe.

C´ıl pr´ ace Tato pr´ ace by mˇela b´ yt ucelen´ ym návodem, jak provádˇet simulován´ı s´ıt´ı. Zamˇeˇr´ı se na smˇerovac´ı protokoly RIP a OSPF, které se vyuˇz´ıvaj´ı v s´ıt´ıch nejˇcastˇeji. Povede ˇcten´ aˇre od základn´ıch informac´ı nutn´ ych k pochopen´ı simulac´ı s´ıtˇe aˇz k proveden´ı vlastn´ıch simulac´ıch. Nahlédne pod pokliˇcku simulaˇcn´ıch nástroj˚ u Packet Tracer a OMNeT++, na kter´ ych pˇredvede, jaké rysy jsou pro simulaci podstatné. Pop´ıˇse modelován´ı nˇekolika vybran´ ych topologi´ı, navrhne, které aspekty je podstatné simulovat, a simulaci provede.

Struktura pr´ ace Prvn´ı kapitola se zab´ yv´ a t´ım, co je simulace s´ıt´ı a jaké prostˇredky je moˇzné vyuˇz´ıt. V druhé kapitole se zab´ yv´ ame smˇerován´ım a konkrétn´ımi smˇerovac´ımi protokoly RIP a OSPF. Zm´ın´ıme se zde také o návrhov´ ych vzorech, které pouˇzijeme pro simulaci. V tˇret´ı kapitole je pops´ ana tvorba simulaˇcn´ıch model˚ u na základˇe vybran´ ych návrhov´ ych vzor˚ u v n´ astroj´ıch Packet Tracer a OMNeT++. ˇ Ctvrt´ a kapitola se zab´ yv´ a implementac´ı chybˇej´ıc´ıch modul˚ u do nástroje OMNeT++. V p´ até kapitole si pˇredvedeme simulaci vybran´ ych vlastnost´ı s´ıt´ı v nástroj´ıch Packet Tracer a OMNeT++ s vyuˇzit´ım vytvoˇren´ ych simulaˇcn´ıch model˚ u.

4

ˇ a kapitola se zamˇeˇr´ı na zhodnocen´ı v´ Sest´ ysledk˚ u simulac´ı z pˇredchoz´ı kapitoly a zhodnocen´ı obou simulaˇcn´ıch n´ astroj˚ u. Nakonec shrneme moˇznosti praktického vyuˇzit´ı tˇechto simulac´ı a simulaˇcn´ıch n´ astroj˚ u.

5

Kapitola 1

Simulaˇ cn´ı n´ astroje Smyslem této pr´ ace je popsat simulace s´ıt´ı, proto je podstatné si na zaˇcátku vysvˇetlit, co to vlastnˇe simulace s´ıt´ı je a co vˇsechno zahrnuje. Následnˇe pop´ıˇseme, jak se pracuje pˇri simulace s´ıt´ı v simulaˇcn´ıch n´ astroj´ıch Packet Tracer a OMNeT++. Na závˇer oba tyto nástroje srovn´ am a zhodnot´ım jejich simulaˇcn´ı moˇznosti.

1.1

Modelov´ an´ı a simulace s´ıt´ı

V této sekci se kromˇe simulace jako takové zamˇeˇr´ıme na popis diskrétn´ı simulace, kter´ a se pˇri simulac´ıch s´ıt´ı nejˇcastˇeji pouˇz´ıvá. Velká ˇcást této sekce se bude zab´ yvat simulac´ı zamˇeˇrenou jiˇz konkrétnˇe na s´ıtˇe.

1.1.1

Modelov´ an´ı a simulace obecnˇ e

Modelov´ an´ı je proces vytv´ aˇren´ı modelu systému. Pˇredpokládejme, ˇze systém je soubor element´ arn´ıch ˇc´ ast´ı, které mezi sebou maj´ı urˇcité vazby. Model je urˇcitou abstrakc´ı systému. Modelov´ an´ı je z´ asadn´ı a podstatn´ y krok, od kterého se vyv´ıj´ı v´ ysledky simulace. Kvalita modelu je z´ avisl´ a na naˇs´ıch znalostech o systému. Simulace je experimentován´ı s modelem systému za u ´ˇcelem z´ısk´ av´ an´ı nov´ ych poznatk˚ u o modelovaném systému. Tvorba modelu a jeho vhodn´ y popis, stejnˇe jako jeho správnost, jsou pro simulaci kl´ıˇcové. Nejdˇr´ıve je tˇreba systém dobˇre prozkoumat a ujasnit si, které jeho aspekty chceme modelovat. Po té vytvoˇr´ıme abstraktn´ı model, kter´ y neobsahuje vˇsechny podrobnosti re´ alného systému, ale jen ty, o kter´ ych jsme rozhodli, ˇze jsou pro simulován´ı podstatné. T´ım dojde ˇcasto k v´ yraznému zjednoduˇsen´ı a model je pak snadnˇejˇs´ı implementovat. Na z´ akladˇe abstraktn´ıho modelu vytvoˇr´ıme model simulaˇcn´ı. Mezi obˇema modely je homomorfn´ı vztah, takˇze uˇz nedocház´ı k ˇzádnému zjednoduˇsen´ı. Simulaˇcn´ı model má ale ˇ za u ´kol, narozd´ıl od abstraktn´ıho, slouˇzit k simulac´ım a experimentován´ım. Casto je proto simulaˇcn´ı model vlastnˇe programem, kter´ y postihuje abstraktn´ı model v celém rozsahu. Následuj´ı jiˇz samotné simulaˇcn´ı experimenty. V pr˚ ubˇehu simulace sb´ıráme data. Jejich anal´ yzou z´ısk´ av´ ame nové poznatky o systému a t´ım se cel´ y simulaˇcn´ı kruh uzav´ırá. V analyzaˇcn´ı f´ azi se také zab´ yv´ ame vhodnou prezentac´ı v´ ysledk˚ u v podobˇe graf˚ u, histogram˚ u apod. pro jejich lepˇs´ı zn´ azornˇen´ı. Cel´ y proces je znázornˇen na obrázku 1.1. Podrobnˇejˇs´ı informace se m˚ uˇzete dozvˇedˇet v [11]. Simulace mohou b´ yt spojité, diskrétn´ı nebo kombinované (obsahuje diskrétn´ı i spojité ˇcásti). Kaˇzd´ a z nich se hod´ı na nˇeco jiného. Pˇri simulaci s´ıt´ı se ale nejˇcastˇeji pouˇz´ıv´ a

6

Obrázek 1.1: Proces modelov´ an´ı a simulace (Z = znalosti; AM = abstraktn´ı model; SM = simulaˇcn´ı model).

diskrétn´ı simulace, nebot’ jde o zas´ılán´ı zpráv mezi s´ıt’ov´ ymi prvky. Proto se v následuj´ıc´ı ˇcásti budeme zab´ yvat jen t´ımto typem.

1.1.2

Diskr´ etn´ı simulace

Diskrétn´ı simulace jsou zaloˇzeny na zmˇenˇe stavu systému v urˇcitém, pˇredem naplánovaném ˇcase. Stavy jsou mˇenˇeny tzv. ud´ alostmi. Pˇredpokládá se, ˇze událost se vykoná v nulovém ˇcasu, a mezi jednotliv´ ymi ud´ alostmi se nic nedˇeje a systém se nijak nemˇen´ı. Podstatn´ ym pojmem pro kaˇzdou simulaci je simulaˇcn´ı ˇcas. Ten se podstatnˇe liˇs´ı od ˇcasu reálného nebo procesorového (jak dlouho trvá vykonán´ı programu). Oproti ˇcasu reálnému ho m˚ uˇzeme dle potˇreby zrychlit nebo zpomalit. V diskrétn´ıch simulac´ıch je se simulaˇcn´ım ˇcase spojen kalend´ aˇr ud´ alost´ı, kter´ y ˇr´ıd´ı pr˚ ubˇeh simulace. Kalend´ aˇr ud´ alost´ı je uspoˇr´ adaná datová struktura, která uchovává záznamy o naplánovan´ ych ud´ alostech a to tak, ˇze jsou v kalendáˇri seˇrazeny dle ˇcasu události od událost´ı s nejbliˇzˇs´ım ˇcasem vykon´ an´ı. Simulátor pracuje ve smyˇcce. Pokud kalendáˇr nen´ı prázdn´ y, vybere prvn´ı ud´ alost, nastav´ı simulaˇcn´ı ˇcas na dobu, kdy se má událost vykonat, a událost provede. Pokud jsou nˇejaké dvˇe události naplánované na stejn´ y ˇcas, rozhoduje o postupu zpracov´ an´ı jejich priorita. Pokud i ta je shodná, rozhodne náhodnˇe simulátor.

1.1.3

Simulace s´ıt´ı

Jak jiˇz bylo zm´ınˇeno v kapitole , pokud navrhujeme novou s´ıt’ nebo rozˇsiˇrujeme s´ıt’ stávaj´ıc´ı, m˚ uˇze n´ am simulace velmi pomoci. Je vhodné navrhnout nˇekolik topologi´ı, ty simulovat, experimentovat s r˚ uzn´ ymi problémy a pokusit se o nejlepˇs´ı návrh. Zaj´ımavou moˇznost´ı je vyuˇzit´ı emulace. Jde o propojen´ı simulace s reáln´ ym provozem. Simulace s´ıt´ı se nejˇcastˇeji provádˇej´ı z d˚ uvod˚ u abychom zjistili: • Jak´ y dopad bude m´ıt na s´ıt’ vˇetˇs´ı vyt´ıˇzenost urˇcit´ ych linek ˇci zaˇr´ızen´ı oproti ostatn´ım. • Jak´ y dopad na v´ ykon bude m´ıt zmˇena topologie, rozˇs´ıˇren´ı s´ıtˇe nebo v´ ymˇena nˇekter´ ych s´ıt’ov´ ych zaˇr´ızen´ı za novˇejˇs´ı. • Jak se s´ıt’ bude chovat, pokud dojde k chybˇe linky nebo nˇekterého s´ıt’ového zaˇr´ızen´ı. • Kter´ a zaˇr´ızen´ı nebo aplikace zp˚ usobuj´ı nejvˇetˇs´ı zpomalen´ı s´ıtˇe. • Kolik uˇzivatel˚ u zvl´ adne s´ıt’ obslouˇzit bez vˇetˇs´ıch zpoˇzdˇen´ı.

7

• Jak dlouho trv´ a s´ıt’ov´ ym aplikac´ım, neˇz odpov´ı na poˇzadavky uˇzivatel˚ u. Existuj´ı také problémy, které jsou pomoc´ı simulac´ı témˇeˇr neˇreˇsitelné, jako je napˇr. zjiˇstˇen´ı, zda jsou zaˇr´ızen´ı propojena korektnˇe, optimalizace návrhu a v´ ykonu s´ıtˇe, simulov´ an´ı rozsáhl´ ych s´ıt´ıch a v neposledn´ı ˇradˇe simulace bezdrátov´ ych s´ıt´ı, kdy je vliv okoln´ıho prostˇred´ı na tolik v´ yznamn´ y, ˇze ho nen´ı moˇzné zanedbat. Typick´ ymi ud´ alostmi pˇri diskrétn´ıch simulac´ıch s´ıt´ı je vyslán´ı paketu, pˇrijet´ı paketu a vyprˇsen´ı ˇcasovaˇce (Timeout). Do kalendáˇre událost´ı jsou události vkládány podle ˇcasu, kdy maj´ı dorazit do svého c´ıle. V´ıce o simulaci s´ıt´ı se lze doˇc´ıst v [12]. Existuje velké mnoˇzstv´ı simulaˇcn´ıch nástroj˚ u, které maj´ı r˚ uzné zamˇeˇren´ı. Nˇekteré z nich vnikly pro v´ yukové u ´ˇcely, napˇr. Packet Tracer [24], CNET [19] nebo NetSim [28]. PARSEC [29], GloMoSim [18] nebo QualNet Developer [27] podporuj´ı paraleln´ı simulaci. Pokud bychom r´ adi vyhodnotili v´ ykon naˇs´ı s´ıtˇe, pak jsou vhodné nástroje Performance PROPHET [25] nebo QualNet Developer [27]. Na simulován´ı bezdrátov´ ych s´ıt´ı se zamˇeˇrili produkty GloMoSim a SWANS [22] postaven´ y na JiST. Nástroj Traffic [20] se zab´ yvá zpoˇzdˇen´ım v s´ıti. Existuje ale i ˇrada obecnˇe zamˇeˇren´ ych nástroj˚ u jako je OMNeT++ [23], CNET, GTNetS [21] a dalˇs´ı.

1.2

N´ astroj Packet Tracer

V této ˇc´ asti se budeme zab´ yvat simulaˇcn´ım nástrojem od firmy Cisco – Packet Tracer (d´ ale jen PT). Pro popis jsme zvolili nejnovˇejˇs´ı verzi PT 5.0 [24]. Zjiˇst’ovali jsme, jaké schopnosti má tento program v oblasti modelován´ı a simulaci s´ıt´ı. Návod na instalaci programu je v pˇr´ıloze B. Dalˇs´ı informace m˚ uˇzete nastudovat v struˇcném návodu [3].

1.2.1

Popis prostˇ red´ı a moˇ znost´ı programu Packet Tracer

PT nab´ız´ı vizualizaˇcn´ı a simulaˇcn´ı nástroje, nástroje pro sestaven´ı topologie z model˚ u reáln´ ych s´ıt’ov´ ych prvk˚ u od firmy Cisco ˇci nástroje pro vytváˇren´ı nejr˚ uznˇejˇs´ıch aktivit a test˚ u pro studenty. D˚ uraz se klade na mnoˇzstv´ı s´ıt’ov´ ych prvk˚ u této firmy, které si m˚ uˇze uˇzivatel sestavit, propojit a nastavit dle vlastn´ıho uváˇzen´ı. Vizualizace a animace jsou vhodné pˇri simulaci reálného provozu s´ıtˇe, d´ıky nimˇz m´ a 1 uˇzivatel moˇznost sledovat, v jakém ˇcase, odkud kam putuj´ı jednotlivé PDU (Protocol Data Unit), vˇcetnˇe toho jaké informace nesou. Packet Tracer podporuje protokoly HTTP, Telnet, SSH, TFTP, DHCP, TCP, UDP, IPv4, IPv6, ICMPv4, ICMPv6, RIP, EIGRP, OSPF, statické smˇerov´ an´ı, distribuce cest, Ethernet/802.3, 802.11, HDLC, Frame Relay, PPP, ARP, CDP, STP, RSTP, 801.1q, VTP, DTP a PAgP. Prostˇred´ı programu po je zobrazeno na obrázku 1.2.

1.2.2

Modelov´ an´ı s´ıt´ı

Pro modelov´ an´ı s´ıt´ı obsahuje PT mnoho moˇznost´ı a vcelku vˇernˇe napodobuje skuteˇcné vytváˇren´ı s´ıt´ı (kabel´ aˇz, konfigurace). Nab´ız´ı nepˇreberné mnoˇzstv´ı model˚ u s´ıt’ov´ ych prvk˚ u a kabel˚ u k jejich propojen´ı. M˚ uˇzeme vyb´ırat z nˇekolika druh˚ u smˇerovaˇc˚ u, pˇrep´ınaˇc˚ u, rozboˇcovaˇc˚ u a bezdr´ atov´ ych zaˇr´ızen´ı od firmy Cisco. Podobnˇe u kabel˚ u si je moˇzné vybrat, zda pouˇzijeme kˇr´ıˇzen´ y, pˇr´ım´ y, sériov´ y, koaxiáln´ı ˇci optick´ y kabel. 1

Obecn´ y n´ azev pro datovou jednotku zas´ılanou po s´ıti.

8

Obr´ azek 1.2: Prostˇred´ı programu PT.

Vˇetˇsina z nab´ızen´ ych zaˇr´ızen´ı je modulárn´ıch a tak i v PT je moˇzné pˇridávat do zaˇr´ızen´ı vybrané moduly. Napˇr´ıklad z´ akladn´ı smˇerovaˇc Cisco 1841 umoˇzn ˇuje pˇridán´ı s´ıt’ov´ ych karet s ethernetov´ ymi porty (RJ-45), telefonn´ımi porty (RJ-11) nebo sériov´ ymi porty. Vˇsechna zaˇr´ızen´ı je moˇzné konfigurovat tak, jako by se jednalo o zaˇr´ızen´ı reálná. Smˇerovaˇce a pˇrep´ınaˇce lze nastavovat pomoc´ı pˇr´ıkaz˚ u operaˇcn´ıho systému IOS. Zde vˇsak mus´ıme podotknout, ˇze PT neumoˇzn ˇuje pouˇz´ıvat pˇr´ıkazy IOS v plné ˇs´ıˇri, ale bˇeˇznˇe uˇz´ıvané pˇr´ıkazy zvládne. Modelov´ an´ı s´ıt´ı se prov´ ad´ı v logickém pracovn´ım prostotu. Do nˇej vkládáme s´ıt’ové prvky z nab´ıdky vlevo dole. Pro propojen´ı zaˇr´ızen´ı nejprve vybereme potˇrebn´ y druh kabel˚ u z nab´ıdky. Kliknut´ım na zaˇr´ızen´ı a v´ ybˇerem rozhran´ı, do kterého kabel zapoj´ıme, vybereme prvn´ı zaˇr´ızen´ı. Podobnˇe to provedeme s druh´ ym zaˇr´ızen´ım, které chceme k prvn´ımu kabelem pˇripojit. M˚ uˇzeme pokraˇcovat nastaven´ım jednotliv´ ych zaˇr´ızen´ı. Klepnut´ım na zaˇr´ızen´ı se dostaneme do jeho nastaven´ı. Je moˇzné pracovat pˇres uˇzivatelské rozhran´ı v záloˇzce Config (obrázek 1.3), které je vhodné pˇredevˇs´ım pro zaˇcáteˇcn´ıky nebo bˇeˇzné uˇzivatele. U pˇrep´ınaˇce a smˇerovaˇce m˚ uˇzeme vyuˇz´ıt moˇznosti profesionáln´ıho nastaven´ı zaˇr´ızen´ı v záloˇzce CLI (obrázek 1.4), kde se simuluje pˇripojen´ı k zaˇr´ızen´ı pˇres konzolové rozhran´ı a umoˇzn ˇuje vyuˇz´ıt operaˇcn´ı systému IOS. Zjiˇstˇen´ı nˇekter´ ych z´ akladn´ıch nastaven´ı zaˇr´ızen´ı lze provést pouh´ ym um´ıstˇen´ım kurzoru na dané zaˇr´ızen´ı. Na obr´ azku 1.5 m˚ uˇzeme vidˇet, ˇze se objev´ı nápovˇeda obsahuj´ıc´ı nastaven´ı jednotliv´ ych rozhran´ı zaˇr´ızen´ı (Up/Down, VLAN, MAC a IP adresa). V Realtime módu lze vˇsechna zaˇr´ızen´ı restartovat pouˇzit´ım tlaˇc´ıtka Power Cycle Devices vyznaˇceného v obrázku 1.5 ˇcerven´ ym ov´ alem. To je praktické chceme-li sledovat chován´ı protokolu od momentu jeho spuˇstˇen´ı na zaˇr´ızen´ı.

9

Obr´ azek 1.3: Konfiguraˇcn´ı rozhran´ı pˇrep´ınaˇce v PT.

Obr´ azek 1.4: Rozhran´ı s operaˇcn´ım systémem IOS v PT.

10

Obr´ azek 1.5: Základn´ı informace o zaˇr´ızen´ı v PT.

1.2.3

Simulace s´ıt´ı

Simulaˇcn´ı m´ od umoˇzn ˇuje upravit ˇcasovou osu, sledovat zprávy, které si v s´ıti zaˇr´ızen´ı zas´ılaj´ı, sledovat jejich trasy, zkoumat podrobnˇe jejich obsah a vys´ılat vlastn´ı zprávy. Simulace v PT je diskrétn´ı, tedy dalˇs´ı akce v ˇcase se provádˇej´ı skokovˇe. Popis simulaˇ cn´ıho m´ odu V simulaˇcn´ım m´ odu je pro simulaci pˇripraven simulaˇcn´ı panel. Na obrázku 1.6 vid´ıme, ˇze se sklád´ a ze tˇr´ı ˇc´ ast´ı. V prvn´ı ˇc´ asti s názvem Event List se pˇri simulaci bude zobrazovat záznam o pos´ılan´ ych paketech. Ke kaˇzdému PDU se zde zaznamenává ˇcas, ve kter´ y byl zaslán, z jakého zaˇr´ızen´ı byl zasl´ an, na kterém zaˇr´ızen´ı se právˇe nacház´ı a protokol, kter´ y vyuˇz´ıv´ a. Pro lepˇs´ı orientaci jeˇstˇe obsahuje dodatkové informace o tom, jestli je PDU pr´ avˇe viditelné a jakou barvu m´ a. PDU jsou totiˇz v topologii zobrazovány jako obálky r˚ uzn´ ych barev (obr´ azek 1.6). Dalˇs´ı ˇc´ ast s n´ azvem Play Controls umoˇzn ˇuje simulaci ovládat. Pomoc´ı tlaˇc´ıtka Auto Capture/Play m˚ uˇzeme nechat simulaci plynule bˇeˇzet. Pro konkrétn´ı ˇreˇsen´ı nˇejakého problému jsou pak vhodnˇejˇs´ı tlaˇc´ıtka Capture/Forward a Back, které provád´ı v simulaci jeden krok dopˇredu nebo vzad. Na posuvn´ıku m˚ uˇzeme urˇcovat jak rychle se bude simulace provádˇet. V posledn´ı ˇc´ asti Event List Filters m˚ uˇzeme filtrovat provoz, kter´ y je v simulaci zobrazován. Implicitnˇe jsou povoleny vˇsechny protokoly, které PT um´ı. Pomoc´ı tlaˇc´ıtka Edit Filters lze urˇcit, které protokoly budeme sledovat, a nastavit ACL filtr. Resetov´ an´ım simulace se simulaˇcn´ı ˇcas nastav´ı na 0,000 sekund a vymaˇze se EventList. Resetov´ an´ı simulace provedeme tlaˇc´ıtkem Reset Simulation, restartován´ım zaˇr´ızen´ı (tlaˇc´ıtkem Power Cycle Devices) ˇci modifikován´ım topologie s´ıtˇe.

11

Obrázek 1.6: Simulaˇcn´ı mód.

Studium PDU Kaˇzdou jednotku PDU, kter´ a se zobraz´ı v Event Listu, m˚ uˇzeme d˚ ukladnˇe prozkoumat. PT má struktury PDU velmi dobˇre graficky zpracované a tak se v nich lehce vyzná i zaˇcáteˇcn´ık. Po informativn´ı str´ ance jsou plnohodnotné, takˇze i odborn´ık v nich najde vˇse potˇrebné. PDU informace z´ısk´ ame kliknut´ım na obálku v topologii nebo na záznam v Event Listu. V z´ aloˇzce OSI Model (obr´ azek 1.7) je názornˇe zobrazeno, jak je zpráva zpracovávána jednotliv´ ymi vrstvami OSI modelu. Pod obrázkem znázorˇ nuj´ıc´ım OSI model je postup detailnˇe pops´ an. Záloˇzka PDU Details (obr´ azek 1.8) zobrazuje obsah PDU. Ten je graficky organizov´ an do tabulek zn´ azorˇ nuj´ıc´ıch r˚ uzné typy hlaviˇcek, které PDU obsahuje. Ty jsou dále ˇclenˇeny na pole obsahuj´ıc´ı informace.

1.3

N´ astroj OMNeT++

Vzhledem k tomu, ˇze se v této pr´ aci máme zab´ yvat moˇznostmi simulaˇcn´ıho nástroje OMNeT++, bude tato sekce vˇenov´ ana pr´ avˇe jemu. OMNeT++ je pro tuto práci vhodn´ y, protoˇze je volnˇe dostupn´ y a m´ a otevˇren´ y zdrojov´ y kód. Jeho dalˇs´ı v´ yhody budou uvedeny dále. Pro popis jsme zvolili posledn´ı verzi 4.0. Vˇsechny informace byly ˇcerpány z velmi dobˇre zpracovaného manuálu [17]. Stejnˇe jako u PT jsme zjiˇst’ovali, jaké schopnosti má tento program v oblasti modelov´ an´ı a simulaci s´ıt´ı.

1.3.1

Moˇ znosti programu OMNeT++

OMNeT++ je objektovˇe orientovan´ y modulárn´ı diskrétn´ı s´ıt’ov´ y simulátor. Je zaloˇzen´ y na objektovém jazyku C++ a vlastn´ım jazyku NED. Existuj´ı verze pro Unix i Windows a obˇe verze jsou pro ˇskoln´ı u ´ˇcely zdarma. Kromˇe simulaˇcn´ıho jádra obsahuje GUI a IDE. Obsahuje knihovny pro pr´ aci s TCP/IP, Ethernet, FDDI, Token Ring, 802.11 a Peer-to-peer.

12

Obr´ azek 1.7: OSI model PDU v PT.

Obr´ azek 1.8: Struktura PDU v PT.

13

1.3.2

Modelov´ an´ı

Pˇri modelov´ an´ı v OMNeT++ se do sebe vnoˇruj´ı jednotlivé moduly hierarchicky. Nejv´ yˇse postaven´ y modul se oznaˇcuje jako modul systémov´ y, ten se skládá ze submodul˚ u (obrázek 1.9). M˚ uˇze se jednat o modely sloˇzené, které se skládaj´ı z dalˇs´ıch sloˇzen´ ych modul˚ u nebo z modul˚ u jednoduch´ ych. Ty jsou dále nedˇelitelné.

Obr´ azek 1.9: Hierarchická struktura modul˚ u. Topologie s´ıtˇe – propojen´ı jednotliv´ ych modul˚ u – se v OMNeT++ popisuje speciáln´ım jazykem NED. Jednoduché moduly obsahuj´ı algoritmus, kter´ y se zapisuje v jazyce C++. Moduly nen´ı tˇreba ps´ at od zaˇc´ atku. OMNeT++ obsahuje nˇekolik pˇreddefinovan´ ych tˇr´ıd objekt˚ u, u kter´ ych je tˇreba jen redefinovat chován´ı. Moduly mezi sebou komunikuj´ı pomoci zas´ılán´ı zpráv. Ty budeme vˇetˇsinou povaˇzovat za model PDU. Zpr´ avy mohou pˇrij´ıt od jiného modulu nebo ze stejného (vyuˇz´ıvaj´ı se jako ˇcasovaˇce). Kaˇzd´ y modul obsahuje brány, které jsou vstupn´ı (In) pro pˇr´ıjem zpráv a v´ ystupn´ı (Out) pro odes´ıl´ an´ı zpr´ av. Mezi bránami modul˚ u se vytváˇr´ı spojen´ı. Spojen´ı m˚ uˇze existovat mezi moduly na stejné u ´rovni hierarchie nebo mezi modulem a jeho sloˇzen´ ym rodiˇcovsk´ ym modulem (obr´ azek 1.10). Pro moˇznost modelován´ı pˇrenosu paket˚ u po lince, má spojen´ı tˇri volitelné parametry – pˇrenosové zpoˇzdˇen´ı, bitová chybovost a rychlost pˇrenosu dat.

Obrázek 1.10: Spojen´ı submodul˚ u mezi sebou a propojen´ı rodiˇcovského modulu se submoduly.

1.3.3

Jazyk NED

Jazyk NED slouˇz´ı pro popis topologii s´ıtˇe. Soubory obsahuj´ıc´ı popis jazykem NED mus´ı m´ıt pˇr´ıponu .ned. Zp˚ usob, kter´ ym se popisuj´ı moduly, je rozd´ıln´ y pro moduly sloˇzené a jednoduché. Popis jednoduchého modelu obsahuje kromˇe povinného názvu volitelnˇe parametry a br´ any. Br´ any m˚ uˇzeme zadat pomoc´ı vektoru. simple SimpleModuleName { parametres:

; n´ azev jednoduch´ eho modulu ; deklarace parametr˚ u 14

const example1; string example2; gates: input fromPort, input[]; output toPort, output[];

; deklarace bran ; vstupn´ ı br´ any (pomoc´ ı skal´ aru i vektoru) ; v´ ystupn´ ı br´ any

}

Popis sloˇzeného modulu m˚ uˇze volitelnˇe obsahovat parametry, brány, submoduly a popis spojen´ı. Povinn´ y je jen n´ azev. Parametry a brány maj´ı stejn´ y v´ yznam jako u jednoduch´ ych modul˚ u. Submoduly jsou moduly, ze kter´ ych se sloˇzen´ y modul skládá. Spojen´ı jsou kl´ıˇcov´ a pro vytvoˇren´ı topologie a ud´ avaj´ı, která vstupn´ı brána se propoj´ı s kterou v´ ystupn´ı bránou. module CompoundModuleName { parametres: const example1; string example2; gates: input fromPort; output toPort; submodules: node1: Node {}; node2: Node {}; connections: node1.output --> node2.input; node1.input <-- node2.output; }

; n´ azev sloˇ zen´ eho modulu ; deklarace parametr˚ u

; deklarace bran

; deklarace modulu (typ a n´ azev)

; definice propojen´ ı bran

Soubory .ned lze zapisovat textovˇe nebo pomoc´ı jednoduchého uˇzivatelsky pˇr´ıvˇetivého nástroje GNED, kter´ y OMNeT++ nab´ız´ı.

1.3.4

Simulace

Poté, co m´ ame napsané vˇsechny topologické popisy v souborech s pˇr´ıponou .ned, popisy zpráv v souborech s pˇr´ıponou .msg a popisy chován´ı jednoduch´ ych modul˚ u v jazyk˚ u C++ v souborech s pˇr´ıponou .cc, m˚ uˇzeme cel´ y simulaˇcn´ı program sestavit. V´ ysledkem je spustiteln´ y soubor .exe (pod Windows), kter´ y jiˇz nepotˇrebuje knihovnu OMNeT++ a je spustiteln´ y na libovolném PC (obrázek 1.11). Pro nastaven´ı parametr˚ u simulace jeˇstˇe budeme potˇrebovat soubor omnetpp.ini, jinak bychom museli toto nastaven´ı dˇelat pˇri kaˇzdém spuˇstˇen´ı simulace ruˇcnˇe. Tento soubor m´ a vlastn´ı specifickou syntax, kter´ a je dopodrobna popsána v [23]. K dispozici jsou dva druhy uˇzivatelsk´ ych rozhran´ı – pˇr´ıkazová ˇrádka (Cmdenv) a grafické (Tkenv zaloˇzen na Tcl/Tk). Pro vˇetˇs´ı názornost simulace je vhodn´ y grafick´ y reˇzim, pokud n´ as ale zaj´ımaj´ı pouze v´ ysledky simulace, postaˇc´ı nám pˇr´ıkazová ˇrádka. V grafickém reˇzimu m˚ uˇzeme sledovat, jak zpr´ avy putuj´ı mezi zaˇr´ızen´ımi, zrychlovat/zpomalovat simulaci, sledovat grafické v´ ystupy statistik (histogramy atd.), restartovat animaci a dalˇs´ı. Bohuˇzel simulaci nejde vracet v ˇcase. 15

Obr´ azek 1.11: Diagram popisuj´ıc´ı vytvoˇren´ı spustitelného souboru v OMNeT++.

Simulaˇcn´ı prostˇred´ı m˚ uˇzeme vidˇet na obrázku 1.12. Pod panelem nástroj˚ u se nach´ az´ı ˇcasová osa, na které jsou vyznaˇcena události uloˇzené v kalendáˇri. Vpravo na obrázku m˚ uˇzeme vidˇet modul pˇredstavuj´ıc´ı topologii s´ıtˇe a vlevo modul pˇredstavuj´ıc´ı smˇerovaˇc. Zprávy jsou symbolizov´ any ˇcervenou teˇckou s názvem zprávy, které se pohybuj´ı topologi´ı. Vpravo dole je okno s bliˇzˇs´ımi informacemi o zprávˇe. V pˇr´ıpadˇe paketu se zde m˚ uˇzeme doˇc´ıst vˇsechny podstatné informace - MAC adresy, IP adresy, porty, obsah zprávy apod. OMNeT++ je pro simulaci vybaven rozsáhlou simulaˇcn´ı knihovnou, kter´ y sk´ ytá mnoho moˇznost´ı. Existuje zde tˇr´ıda pˇredstavuj´ıc´ı zas´ılané zprávy (cMessage), tˇr´ıda pro pˇr´ıstup k bran´ am a parametr˚ um zadan´ ym v .ned souboru(cModule), funkce pro zas´ılán´ı, pˇrij´ım´ an´ı zpráv a pl´ anov´ an´ı ud´ alost´ı (send(), schedulaAt(), endSimulation()), funkce pro pˇr´ıstup k ostatn´ım modul˚ um (parentModulu(), ownerModule(), toGate()). Statistick´ a knihovna umoˇzn ˇuje zpracovávat v´ ysledky a vypisovat poˇcet vzork˚ u, pr˚ umˇerné hodnoty, odchylky, minima, maxima. Má také nˇekolik moˇznost´ı implementace histogram˚ u. Souˇcást´ı OMNeT++ jsou n´ astroje Plove a Scalars, které mohou b´ yt pouˇzity pro zpracov´ an´ı a anal´ yzu v´ ysledk˚ u ve formˇe graf˚ u. Plove pracuje s hodnotami v ˇcase a Scalars s hodnotami skalárn´ımi.

1.4

Shrnut´ı kapitoly

Tato kapitola popsala, co to je simulace. Bl´ıˇze popsala simulaci diskrétn´ı a nakonec se zamˇeˇrila na simulov´ an´ı s´ıt´ı. Byly zde také zm´ınˇeny simulaˇcn´ı nástroje, které m˚ uˇzeme k simulaci pouˇz´ıt. Dva z nich – Packet Tracer a OMNeT++ – byly následnˇe bl´ıˇze popsány. Oba nástroje jsou vhodné pro simulaci s´ıt´ı, ale kaˇzd´ y má své v´ yhody i nev´ yhody. OMNeT++ je univerz´ aln´ı simulaˇcn´ı nástroj s velk´ ymi moˇznostmi. Pro nekomerˇcn´ı vyuˇzit´ı je zcela zdarma a je moˇzné jej dále rozˇsiˇrovat o knihovny, které potˇrebujeme ke své práci. M´ a propracovan´ y jazyk pro popis topologie s´ıt´ı a pˇredpˇripravené tˇr´ıdy pro popis nejjednoduˇsˇs´ıch stavebn´ıch prvk˚ u topologie. Oproti tomu PT mohou vyuˇz´ıvat pouze studenti a uˇcitelé Cisco akademie a jeho k´ od nen´ı volnˇe dostupn´ y. Také vˇsechna zaˇr´ızen´ı, ze kter´ ych je moˇzné vytváˇret s´ıtˇe, jsou pouze znaˇcky Cisco, ani ty zde vˇsak nejsou zastoupeny vˇsechny. Program PT nen´ı moˇzné prakticky nijak rozˇs´ıˇrit. Nen´ı moˇzné doplˇ novat dalˇs´ı zaˇr´ızen´ı a kabely, upravovat jejich vlastnosti, ani

16

Obr´ azek 1.12: Simulaˇcn´ı prostˇred´ı v OMNeT++.

si doprogramovat chybˇej´ıc´ı protokoly nebo jejich novˇejˇs´ı verze. K modelov´ an´ı se v PT nab´ız´ı ˇsiroká paleta s´ıt’ov´ ych komponent. Jejich propojován´ı je jednoduché a intuitivn´ı. Taktéˇz nastavován´ı jednotliv´ ych s´ıt’ov´ ych prvk˚ u je jednoduché jak pro zaˇc´ ateˇcn´ıka, tak pro profesion´ ala, kter´ y m˚ uˇze vyuˇz´ıt operaˇcn´ı systém IOS. V OMNeT++ je tˇreba mnoho komponent dopsat, proto je v oblasti modelován´ı s´ıt´ı PT jednoduˇsˇs´ı a po mnoha str´ ank´ ach lepˇs´ı (re´ alné s´ıt’ové prvky, IOS). Simulace s´ıt´ı je v PT velmi názorná a snadná. Zkoumán´ı obsah˚ u PDU je jednoduché, srozumitelné a pˇrehledné. Simulace je ale ponˇekud primitivn´ı a pro naˇse potˇreby nejsou zcela dostaˇcuj´ıc´ı. Neumoˇzn ˇuje simulovat nˇekteré základn´ı akce jako je pád linky ˇci porucha zaˇr´ızen´ı. V´ ysledky simulace nen´ı moˇzné nijak vyexportovat. Je tedy vhodnˇejˇs´ı pro ˇskoln´ı v´ yuku neˇz pro simulaci vˇetˇs´ı s´ıtˇe. Simulace v OMNeT++ mohou b´ yt v grafickém reˇzimu také velmi n´ azorné. OMNeT++ je ale naproti PT ryz´ı simulaˇcn´ı nástroj a tak nab´ız´ı velké mnoˇzstv´ı tˇr´ıd vhodn´ ych pro simulaci. OMNeT++ je tedy po simulaˇcn´ı stránce jednoznaˇcnˇe lépe vybaven. D´ıky tomu, ˇze se jedn´ a o univerzáln´ı nástroj, neobsahuje samotn´ y OMNeT++ mnoho knihoven, které by byly vhodné pro simulaci s´ıtˇe, pˇrednˇe zde chyb´ı knihovny pro smˇerovan´ı (RIP i OSPF), které budeme d´ ale potˇrebovat. Tento problém se ale dá ˇreˇsit pouˇzit´ım framework INET, kter´ y pracuje nad OMNeT++ a nab´ız´ı knihovny pro simulace s´ıt´ı. Ale ani v tomto pˇr´ıpadˇe nejsou knihovny dostaˇcuj´ıc´ı a bude tˇreba si nˇekteré dopsat. Tento problém nemus´ıme u PT v˚ ubec ˇreˇsit, podporuje totiˇz vˇsechny bˇeˇzné smˇerovac´ı protokoly. Program PT byl urˇcen ke studiu s´ıt´ı. Jeho ovládán´ı je jednoduché a intuitivn´ı i pro laika. Pokud chce uˇzivatel pracovat s OMNeT++, mus´ı umˇet alespoˇ n základy C++ a pˇredpoklád´ a se, ˇze se nauˇc´ı i nov´ y jazyk NED. Nástroj je pro zaˇcáteˇcn´ıka pomˇernˇe sloˇzit´ y a zabere dost ˇcasu, neˇz se v nˇem zorientuje. Naˇstˇest´ı manuál [23] je velmi dobˇre zpracován. 17

Kapitola 2

N´ avrhov´ e vzory se zamˇ eˇ ren´ım na protokoly RIP a OSPF Tato kapitola se zab´ yv´ a pˇredmˇetem simulován´ı. Budeme simulovat smˇerovac´ı protokoly RIP a OSPF. Proto se kr´ atce zm´ın´ım o tom, co to vlastnˇe smˇerovan´ı je a pop´ıˇsu zm´ınˇené smˇerovac´ı protokoly. Prozkoum´ am návrhové vzory od firmy Cisco a vyberu nˇekolik z nich, které budou pro simulaci vhodné.

2.1

Smˇ erov´ an´ı

Tato kapitola je u ´vodem do smˇerován´ı. Uvád´ıme zde základn´ı informace o smˇerov´ an´ı a smˇerovac´ı tabulce. Lehce se zm´ın´ıme o statickém smˇerován´ı, dynamickém smˇerován´ı a reˇ distribuci. Cerpali jsme z [2] a [7].

2.1.1

Smˇ erov´ an´ı a smˇ erovac´ı tabulka

Smˇerov´ an´ı je proces, pˇri kterém smˇerovaˇc zjiˇst’uje cestu do c´ılové s´ıtˇe. Tento proces prob´ıh´ a na tˇret´ı vrstvˇe modelu ISO/OSI. K smˇerován´ı potˇrebuje smˇerovaˇc m´ıt smˇerovac´ı tabulku. V té se nach´ az´ı vˇsechny s´ıtˇe, které zná a rozhran´ı, na které má poslat paket, pokud smˇeruje nˇekteré z tˇechto s´ıt´ı. Kam smˇeˇruje, zjist´ı smˇerovaˇc z IP hlaviˇcky paketu, pˇresnˇe z c´ılové IP adresy. Informace o s´ıt´ıch se do tabulky mohou dostat r˚ uzn´ ym zp˚ usobem. Záleˇz´ı na tom, zda smˇerovaˇc vyuˇz´ıv´ a statického, dynamického smˇerován´ı ˇci obou zp˚ usob˚ u.

2.1.2

Statick´ e smˇ erov´ an´ı

Statické smˇerov´ an´ı funguje na z´ akladˇe statick´ ych záznam˚ u v smˇerovac´ı tabulce. Tyto záznamy se musej´ı do tabulky zad´ avat ruˇcnˇe a zvláˇst’ pro kaˇzdou s´ıt’, coˇz m˚ uˇze b´ yt nároˇcné pro velké mnoˇzstv´ı okoln´ıch s´ıt´ıch, a tak se ˇcasto v takovémto pˇr´ıpadˇe nahrazuje smˇerován´ım dynamick´ ym. Tyto z´ aznamy se také mohou stát ˇcasem neaktuáln´ı a vyˇzaduj´ı znovu zásah administr´ atora. Nejˇcastˇeji se proto pouˇz´ıvaj´ı pro zápis, tzv. Default Gateway. Jde o záznam v tabulce, kter´ y je vybr´ an vˇzdy, pokud se jin´ y záznam v tabulce neshoduje s c´ılovou adresou s´ıtˇe paketu. V´ yhodou staticky zadan´ ych záznam˚ u je to, ˇze maj´ı nejniˇzˇs´ı administrativn´ı vzdálenost ze vˇsech moˇzn´ ych zp˚ usob˚ u smˇerován´ı. Administrativn´ı vzdálenost (Administrative Distance) ud´ av´ a d˚ uvˇeryhodnost zdroje cesty v tabulce. Záznamy zadané staticky ji

18

maj´ı implicitnˇe nastavenou na jedna. To znamená, ˇze tyto záznamy jsou povaˇzovány za nejd˚ uvˇeryhodnˇejˇs´ı a maj´ı prioritu nad ostatn´ımi záznamy.

2.1.3

Dynamick´ e smˇ erov´ an´ı

Dynamické smˇerov´ an´ı, narozd´ıl od statického, um´ı reagovat na zmˇeny v topologii s´ıtˇe. Pro vytváˇren´ı z´ aznam˚ u v tabulce vyuˇz´ıvá algoritmy, které dokáˇzou z informac´ı, které pˇricházej´ı od sousedn´ıch smˇerovaˇc˚ u, vypoˇc´ıtat tu nejlepˇs´ı cestu k c´ıli. Existuj´ı r˚ uzné zp˚ usoby dynamického smˇerován´ı, jejichˇz chován´ı, funkˇcnost a v´ ymˇena informac´ı mezi smˇerovaˇci je podloˇzena r˚ uzn´ ymi druhy smˇerovac´ıch protokol˚ u. Podstatné ale je, ˇze vybran´ y protokol se nastav´ı na smˇerovaˇci a dále jiˇz vˇse funguje bez zásahu administrátora. To znamen´ a, ˇze smˇerovaˇce si sami zjist´ı okoln´ı s´ıtˇe a dokáˇzou reagovat na zmˇeny topologie. S´ıtˇe b´ yvaj´ı rozdˇeleny pro u ´ˇcely dynamického smˇerován´ı do autonomn´ıch oblast´ı. D˚ uvodem je, aby se informace o smˇerovac´ıch tabulkách neˇs´ıˇrily cel´ ym internetem a správa s´ıt´ı byla snazˇs´ı. Podle druhu algoritm˚ u, které smˇerovac´ı protokoly pouˇz´ıvaj´ı, je dˇel´ıme na protokoly vektorovˇe orientované (Distance Vector Routing Protocol) a protokoly stavu linky (Linkstate). Vektorovˇe orientované optimalizuj´ı cestu pouze podle vzdálenosti od zdroje k c´ıli. Smˇerovaˇc si uchov´ av´ a informaci o smˇeru cesty jako vektor smˇeru (Next hop) a vzdálenosti (Metric). Mezi takovéto protokoly patˇr´ı RIP [5] a IGRP [6]. Link-state protokoly jsou typické t´ım, ˇze si udrˇzuj´ı kompletn´ı mapu topologie s´ıtˇe v tzv. topologické databázi (Link State Database). Takov´ ymi protokoly jsou OSPF [9] a IS-IS [10].

2.1.4

Redistribuce

V momentˇe, kdy r˚ uzné ˇc´ asti s´ıtˇe vyuˇz´ıvaj´ı r˚ uzné smˇerovac´ı protokoly (v naˇsem pˇr´ıpadˇe RIP a OSPF), je tˇreba vyuˇz´ıt redistribuci. Redistribuce je proces v rámci jednoho smˇerovaˇce, kter´ y umoˇzn ˇuje pˇrekl´ adat smˇerovac´ı informace z jednoho smˇerovac´ıho protokolu na druh´ y. Moˇzná v´ as napadne, proˇc pouˇz´ıvat rozd´ılné smˇerovac´ı protokoly. Protokol RIP je nejstarˇs´ım dnes uˇz´ıvan´ ym protokolem, proto ho podporuj´ı snad vˇsechny s´ıt’ové prvky umoˇzn ˇuj´ıc´ı prov´ adˇet dynamické smˇerován´ı. Jak se dozv´ıme v následuj´ıc´ı kapitole, nemus´ı RIP vyhovovat poˇzadavk˚ um administrátor˚ u a ti pak mohou sáhnout po nˇekterém z novˇejˇs´ıch protokol˚ u jako je napˇr. OSPF. Proto mohou v ménˇe kritick´ ych ˇcástech s´ıtˇe ponechat star´ a nebo ménˇe dokonalá zaˇr´ızen´ı, která budou vyuˇz´ıvat protokol RIP a napˇr´ıklad p´ ateˇrn´ı ˇc´ ast s´ıtˇe vybavit prvky, které podporuj´ı OSPF protokol. Hlavn´ım problémem pˇri smˇerovan´ı jsou r˚ uzné metriky, které smˇerovac´ı protokoly vyuˇz´ıvaj´ı. Hraniˇcn´ı smˇerovaˇce (smˇerovaˇce, které pracuj´ı s dvˇema ˇci v´ıce druhy smˇerovac´ıch protokol˚ u) se pak mus´ı nastavit tak, aby dokázaly cesty propagovat s vhodnou metrikou.

2.2

Protokol RIP

Prvn´ım protokolem, kter´ ym se budeme zab´ yvat je Routing Information Protocol (dále jen RIP). Je jedn´ım ze smˇerovac´ıch protokol˚ u, jejichˇz chován´ı máme simulovat. Bude uvedeno, jak RIP funguje, jakou metriku vyuˇz´ıvá a jak vypadaj´ı zprávy, které si smˇerovaˇce mezi sebou zas´ılaj´ı. Taktéˇz se zm´ın´ıme jeho klady a zápory, které na závˇer zhodnot´ıme.

19

2.2.1

Struˇ cn´ y popis

RIP je nejstarˇs´ım a nejpouˇz´ıvanˇejˇs´ım smˇerovac´ım protokolem. Vznikl koncem 70. let a v roce 1988 se doˇckal standardizace v podobˇe RFC 1058 [5]. Protokol RIP vdˇeˇc´ı za svou obl´ıbenost pˇredevˇs´ım jednoduchosti, která pˇredˇc´ı i jeho nˇekteré nedostatky. Vˇetˇsina z nich pak byla odstranˇena v druhé verzi tohoto protokolu. My se zamˇeˇr´ım pˇredevˇs´ım na popis protokol RIP verze 1 (RIPv1), protoˇze pˇredevˇs´ım ten budeme pouˇz´ıvat pˇri této práci. Jak uˇz bylo uvedeno v´ yˇse, RIP patˇr´ı mezi vektorovˇe orientované protokoly.

2.2.2

Funkce protokolu RIP

RIP pouˇz´ıv´ a dva druhy zpr´ av – ˇzádost (Request) a odpovˇed’ (Response) – a vˇzdy zas´ıl´ a vˇsechny zpr´ avy pomoc´ı broadcastu. Po restartu smˇerovaˇce rozeˇsle smˇerovaˇc na vˇsechna sv´ a rozhran´ı ˇz´ adost (Request). Jeho sousedé mu odpov´ı pomoc´ı zprávy (Response) obsahuj´ıc´ı jejich smˇerovac´ı tabulky. N´ aslednˇe, pokud nedojde ke zmˇenˇe topologie, uˇz smˇerovaˇc pos´ıl´ a jen aktualizaˇcn´ı zpr´ avy (Update Message). Kdyˇz smˇerovaˇc pˇrijme zpr´ avu obsahuj´ıc´ı smˇerovac´ı tabulku od souseda, která obsahuje zmˇeny, provede aktualizaci své tabulky. Metrika pro cestu se zv´ yˇs´ı o jedna a zap´ıˇse do tabulky. Podobnˇe pokud pˇrijde informace o cestˇe, kterou uˇz smˇerovaˇc v tabulce má, ale s lepˇs´ı metriku, aktu´ aln´ı z´ aznam pˇrep´ıˇse t´ımto nov´ ym. Smˇerovaˇc udrˇzuje vˇzdy jen informaci o té nejlepˇs´ı cestˇe, tedy cestu s nejniˇzˇs´ı metrikou. Soused, od kterého zprávu dostal, je oznaˇcen jako smˇer cesty (Next Hop). Po aktualizaci vlastn´ı tabulky, zaˇcne smˇerovaˇc vys´ılat vlastn´ı aktualizaˇcn´ı zpr´ avy, aby informoval o zmˇenách sousedn´ı smˇerovaˇce.

2.2.3

Metrika a administrativn´ı vzd´ alenost

Protokol RIP pouˇz´ıv´ a jako metriku pro mˇeˇren´ı vzdálenosti mezi smˇerovaˇcem a c´ılovou s´ıt´ı poˇcet skok˚ u k c´ıly (Hop Count). Cesta mezi dvˇema soused´ıc´ımi smˇerovaˇci je vˇetˇsinou ohodnocena jedniˇckou. Pokud tedy smˇerovaˇc zas´ılá dvou smˇerovac´ı tabulku svému sousedovi, pˇred odesl´ an´ım zpr´ avy nav´ yˇs´ı vˇsem cestám Hop Count o jedna. Jak jiˇz bylo zm´ınˇeno v´ yˇse, IP adresa souseda je pak pouˇzita jako c´ıl pro nejbliˇzˇs´ı dalˇs´ı skok (Next Hop). RIP m´ a implicitn´ı administrativn´ı vzdálenost 120, coˇz znamená, ˇze je jeden z nejménˇe d˚ uvˇeryhodn´ ych smˇerovac´ıch protokol˚ u. Napˇr´ıklad statická cesta má administrativn´ı vzd´ alenost jedna, protokol EIGRP 90 nebo OSPF 110. V praxi to znamená, ˇze pokud smˇerovac´ı tabulka obsahuje stejné cesty z r˚ uzn´ ych zdroj˚ u, pak je pro smˇerován´ı vybrána cesta s nejniˇzˇs´ı administrativn´ı vzd´ alenosti.

2.2.4

Tˇ r´ıdn´ı protokol

Smˇerovaˇce pouˇz´ıvaj´ıc´ı protokol RIP zas´ılaj´ı pouze IP adresy c´ıle, ne masku. RIP je totiˇz tˇr´ıdn´ı (Classful) protokol. Smˇerovaˇc pak pouˇzije masku nakonfigurovanou na lokáln´ım rozhran´ı nebo implicitn´ı masku na základˇe tˇr´ıdy IP adresy. Toto m˚ uˇze b´ yt, spolu s automatickou sumarizac´ı, z´ avaˇzn´ y problém. Uved’me si pˇr´ıklad. Budeme-li uvaˇzovat tˇri budovy firmy, kaˇzdá bude m´ıt vlastn´ı IP adresu s´ıtˇe, ˇreknˇeme 10.10.0.0/16, 10.11.0.0/16 a 10.12.0.0/16. Smˇerovaˇce v jednotliv´ ych budovách budou propojeny s´ıt´ı s IP adresou 192.168.1.0/24. V tomto pˇr´ıpadˇe nelze pouˇz´ıt protokol RIP, nebot’ smˇerovaˇce si budou pos´ılat informace pouze o s´ıt´ıch s IP adresou 10.0.0.0/8 (dojde k sumarizaci podle typu tˇr´ıdy) a tedy nebude moˇzné rozeznat jednotlivé firemn´ı pods´ıtˇe.

20

Ze stejného d˚ uvodu nen´ı moˇzné RIP pouˇz´ıt v prostˇred´ı, kde se pracuje s maskami promˇenné délky (VLSM) nebo se smˇerován´ım na bázi adresov´ ych prefix˚ u (CIDR).

2.2.5

ˇ Casovaˇ ce

ˇ Pro lepˇs´ı ˇr´ızen´ı v´ ykonnosti protokolu, pouˇz´ıvá RIP tˇri ˇcasovaˇce. Casovaˇ c Routing-update urˇcuje ˇcasov´ y interval mezi zas´ıl´ an´ım periodick´ ych aktualizaˇcn´ıch zpráv. Implicitnˇe je nastaven na 30 sekund. Po restartu se k nim pˇriˇc´ıtá jeˇstˇe malá prodleva, aby nedoˇslo k ucp´ an´ı linky. ˇ Casovaˇ c Route-timeout ud´ av´ a ˇcas, do jehoˇz uplynut´ı mus´ı smˇerovaˇc zaslat aktualizaˇcn´ı zprávu, jinak bude cesta k nˇemu povaˇzována za neplatnou. Tento ˇcasovaˇc je implicitnˇe nastaven na 180 sekund. Následnˇe odpoˇc´ıt´ av´ a ˇcasovaˇc Route-flush, po jehoˇz uplynut´ı je neplatná cesta z smˇerovac´ı ˇ tabulky vymaz´ ana. Casovaˇ c je implicitnˇe nastaven na 240 sekund.

2.2.6

Stabilita protokolu

I kdyˇz Bellman-Ford˚ uv algoritmus nedokáˇze pˇredej´ıt vznik˚ um smyˇcek, RIP má opatˇren´ı k tomu, aby se to nest´ avalo. V protokolu je zaneseno, ˇze maximáln´ı poˇcet skok˚ u (Next Hop) je 15. Pokud m´ a nˇejak´ a cesta metriku 16, coˇz je u RIP povaˇzováno za nekoneˇcno, smˇerovaˇc pˇredpokl´ ad´ a, ˇze c´ıl je nedostupn´ y. Na druhou stranu je z tohoto postupu jasnˇe viditeln´ a nev´ yhoda. RIP m´ a omezen´ı na 15 skok˚ u a tud´ıˇz nem˚ uˇze b´ yt pouˇzit v rozsáhl´ ych s´ıt´ıch. Krom tohoto opatˇren´ı m´ a RIP i dalˇs´ı vlastnosti, které jsou navrˇzené pro zajiˇstˇen´ı stability pˇri rychl´ ych zmˇen´ ach topologie, napˇr. Split Horizon. Ten zabraˇ nuje tomu, aby smˇerovaˇc zas´ılal cestu na rozhran´ı, skrz které se tuto informaci dozvˇedˇel. Je tedy jednou z metod, která zabraˇ nuje smˇerovac´ım smyˇckám.

2.2.7

Form´ at zpr´ avy

Protokol RIP pracuje na aplikaˇcn´ı vrstvˇe. Na obrázku 2.1 je znázornˇena struktura zprávy vˇcetnˇe jej´ı souvislost s niˇzˇs´ımi vrstvami. RIP vyuˇz´ıvá jako transportn´ı vrstvu UDP a m´ a rezervovan´ y UDP port 520. Jak uˇz bylo ˇreˇceno dˇr´ıve, RIP vyuˇz´ıvá pro zas´ılán´ı zpráv broadcast. Z toho vypl´ yv´ a, ˇze v IP hlaviˇcce je zadaná c´ılová IP adresa 255.255.255.255 a v hlaviˇcce s´ıt’ového rozhran´ı je c´ılov´ a MAC adresa FF- FF- FF- FF- FF- FF. RIP zpr´ ava (2.1) se skl´ ad´ a z tˇechto pol´ıˇcek: • Command – obsahuje 1 nebo 2 podle toho, zda se jedná o ˇzádost (Request) nebo odpovˇed’ (Response). • Version – obsahuje informaci o verzi, v tomto pˇr´ıpadˇe jde o RIPv1. • Address Family Identifier – specifikuje pouˇzitou adresn´ı rodinu. IP má identifikátor 2. • IP Address – obsahuje IP adresu c´ıle cesty. • Metric – ud´ av´ a poˇcet skok˚ u do c´ıle a nab´ yvá hodnot 1 aˇz 16. Jedna zpr´ ava m˚ uˇze nést aˇz 25 záznam˚ u, tedy 25 opakuj´ıc´ıch se pol´ıˇcek Address Family Identifier, IP Adress a Metric. 21

Obr´ azek 2.1: Struktura zprávy protokolu RIP.

2.2.8

N´ astupce RIPv2

V roce 1994 byla vyvinuta novˇejˇs´ı verze protokolu RIP, RIP verze 2 (RIPv2). RIPv2 je specifikov´ ana v RFC 2453 [8], resp. STD 56. Splˇ nuje základn´ı charakteristiky RIPv1, ale ˇreˇs´ı nˇekteré jeho nedostatky. Spolu s c´ılovou adresou a metrikou se ve zprávách také zas´ılá maska, t´ım pádem RIPv2 podporuje VLSM i CIDR. Na rozes´ılán´ı zpráv uˇz nepouˇz´ıvá broadcast, ale multicast s IP adresou 224.0.0.9. D´ıky tomuto vylepˇsen´ı jsou zprávy zas´ılány jen smˇerovaˇc˚ um, které také vyuˇz´ıvaj´ı smˇerovac´ı protokol RIPv2. Dále umoˇzn ˇuje autentizaci smˇerovac´ıch informac´ı. RIPv2 také dok´ aˇze spolupracovat s jin´ ymi smˇerovac´ımi protokoly, at’ uˇz vnitˇrn´ımi (pomoc´ı odkazu na n´ asleduj´ıc´ı skok) nebo vnˇejˇs´ımi (prostˇrednictv´ım oznaˇcen´ı cest mimo autonomn´ı systém).

2.3

Protokol OSPF

Dalˇs´ım protokolem, kter´ y m´ ame za u ´kol simulovat, je Open Shortest Path First (dále jen ’ OSPF). Budeme o nˇej zjiˇst ovat podobné informace jako o protokolu RIP. Tato kapitola bude m´ıt proto podobnou strukturu jako ta pˇredeˇslá s v´ yjimkou nˇekter´ ych rys˚ u specifick´ ych pro tento protokol.e

2.3.1

Struˇ cn´ y popis

OSPF je pravdˇepodobnˇe nejpouˇz´ıvanˇejˇs´ım protokolem IGP1 (Interior Gateway Protocol) ve velk´ ych podnikov´ ych s´ıt´ıch. OSPF byl vyv´ıjen organizac´ı IETF od 80. let minulého stolet´ı. V roce 1991 se doˇckal prvn´ı standardizace, dnes se OSPF bˇeˇznˇe pouˇz´ıvá v jeho verzi 2 specifikovanou v RFC 2338 [9] z roku 1998. Jedná se o protokol typu Link-state.

2.3.2

Typy OSPF zpr´ av

Dˇr´ıve, neˇz se pod´ıv´ ame na to, jak OSPF protokol funguje, je dobré udˇelat si poˇrádek ve zprávách (resp. paketech), které OSPF pouˇz´ıvá. Je jich nˇekolik druh˚ u – Hello, Database 1

Smˇerovac´ı protokol pouˇz´ıvan´ y uvnitˇr autonomn´ıho systému (RIP, OSPF, EIGRP atd.).

22

Description (DBD), Link-State Request (LSR), Link-State Update (LSU) a Link-State Acknowledgement (LSAck). Hello pakety se pouˇz´ıvaj´ı k nalezen´ı soused˚ u, ustaven´ı a udrˇzován´ı spojen´ı mezi nimi. DBD slouˇz´ı k synchronizaci databáze mezi smˇerovaˇci. LSR zpráva je ˇzádost o urˇcit´ y záznam Link-state. LSU je pak odpovˇed’ na LSR a obsahuje ˇzádan´ y záznam. LSAck se pouˇz´ıv´ a k potvrzen´ı ostatn´ıch paket˚ u.

2.3.3

Router ID

Pˇri procesu v´ ymˇeny informac´ı mezi smˇerovaˇci v OSPF oblasti je nutné jednoznaˇcnˇe identifikovat jednotlivé smˇerovaˇce. K tomu slouˇz´ı tzv. Router ID. Hodnota Router ID je automaticky nastavena na nejniˇzˇs´ı IP adresu rozhran´ı Loopback2 . Pokud smˇerovaˇc ˇzádné rozhran´ı Loopback nem´ a, je pouˇzita nejniˇzˇs´ı IP adresa ze vˇsech rozhran´ı. Router ID jde samozˇrejmˇe i nastavit ruˇcnˇe v IOS smˇerovaˇce. Volba Router ID se provede na poˇcátku a uˇz se pozdˇeji nemˇen´ı.

2.3.4

Funkce protokolu OSPF

Po restartu mus´ı smˇerovaˇc ze vˇseho nejdˇr´ıve objevit své sousedn´ı smˇerovaˇce (Neighbor) a ustanovit s nimi spojen´ı. Rozeˇsle tedy multicastovˇe na vˇsechna svá rozhran´ı Hello paket. Pˇr´ıjem Hello paketu na nˇekterém rozhran´ı smˇerovaˇce znamená, ˇze je smˇerovaˇc pˇripojen k jinému OSPF smˇerovaˇci na této lince. Pˇredt´ım, neˇz m˚ uˇze doj´ıt k spojen´ı, se mus´ı smˇerovaˇce shodnout v tˇrech z´ akladn´ıch bodech – Hello Interval, Dead Interval a Network Types. Pokud sousedn´ı smˇerovaˇc souhlas´ı s tˇemito parametry komunikace, zaˇsle p˚ uvodn´ımu smˇerovaˇci odpovˇed’ obsahuj´ıc´ı jeho Router ID. P˚ uvodn´ı smˇerovaˇc dostane tuto zprávu a dojde k ustaven´ı spojen´ı. Pˇrestoˇze na zaˇcátku se Hello pakety pos´ılaj´ı pomoc´ı multicastu, po ustaven´ı spojen´ı spolu smˇerovaˇce komunikuji pomoc´ı unicastu. Toto ustaven´ı mus´ı probˇehnout v obou smˇerech. Po ustaven´ı spojen´ı je tˇreba naplnit topologickou databázi informacemi o topologii s´ıtˇe. Ve v´ ysledku obsahuj´ı datab´ aze vˇsech smˇerovaˇc˚ u v OSPF s´ıti identické u ´daje. Rozd´ıly vznikaj´ı aˇz pˇri vytv´ aˇren´ı smˇerovac´ıch tabulek. Smˇerovaˇce si zaˇslou DBD paket, kter´ y obsahuje n´ ahodnˇe vybrané sekvenˇcn´ı ˇc´ıslo, které budou pouˇz´ıvat k dalˇs´ı komunikaci pˇri v´ ymˇenˇe topologick´ ych informac´ı. Pouˇz´ıvá se sekvenˇcn´ı ˇc´ıslo, které navrhne smˇerovaˇc s vyˇsˇs´ım Router ID. Následnˇe si pos´ılaj´ı dalˇs´ı pakety DBR s informacemi ze sv´ ych topologick´ ych databáz´ıch. Smˇerovaˇc pak porovn´ av´ a tyto informace ze sousedn´ıho smˇerovaˇce s informacemi, které m´ a ve své vlastn´ı datab´ azi. Pokud zjist´ı, ˇze mu nˇekterá informace v databázi chyb´ı nebo je zastaralá, vyˇz´ ad´ a si od svého souseda tyto informace pomoc´ı paketu LSR. Sousedn´ı smˇerovaˇc poˇsle tyto informace v paketu LSU. Smˇerovaˇc následnˇe pˇr´ıjem tohoto paketu potvrd´ı pomoc´ı LSAck. Kdyby k tomuto potvrzen´ı nedoˇslo, poslal by soused LSU po nˇejakém ˇcasu znovu. Uveden´ y postup z´ısk´ av´ an´ı topologick´ ych informac´ı se opakuje i v pˇr´ıpadˇe, ˇze smˇerovaˇc zjist´ı, ˇze nˇekter´ y z jeho sousedu jiˇz nen´ı aktivn´ı. Vyˇsle vˇsem sv´ ym soused˚ um LSU paket s informac´ı o zmˇenˇe topologie. Sousedi pak pos´ılaj´ı tento LSU dále po s´ıti aˇz se dostane ke vˇsem smˇerovaˇc˚ um v topologii. 2

Logick´ a smyˇcka, umoˇzn ˇuj´ıc´ı zas´ılat pakety s´ am sobˇe.

23

2.3.5

ˇ Casovaˇ ce

Protokol OSPF pouˇz´ıv´ a nˇekolik ˇcasovaˇc˚ u, které udrˇzuj´ı stav topologické databáze a t´ım pádem i smˇerovac´ı tabulky vˇsech smˇerovaˇc˚ u v konzistentn´ım stavu. Základn´ımi kameny jsou ˇcasovaˇce Hello Interval a Dead Interval, na kter´ ych se smˇerovaˇce mus´ı shodnout pˇred zah´ ajen´ım v´ ymˇeny informac´ı. Hello interval udává, jak ˇcasto si smˇerovaˇce zas´ılaj´ı Hello pakety. Implicitnˇe je to 10 sekund v s´ıt´ıch LAN3 (Local Area Network) a 30 sekund v s´ıt´ıch NBMA4 (Nonbroadcast Multiple Access Network). Pokud Hello paket nepˇriˇsel do uplynut´ı Dead Interval, je soused povaˇzován za nefunkˇcn´ıho a je tˇreba o tom informovat zb´ yvaj´ıc´ı sousedy. Dead Interval je implicitnˇe ˇctyˇrnásobek Hello Intervalu, tedy 40 sekund pro LAN s´ıtˇe a 120 sekund pro NBMA s´ıtˇe. Dalˇs´ım ˇcasovaˇcem je MaxAge. Tento ˇcasovaˇc je propojen s pol´ıˇckem Age, kter´ y je u kaˇzdého z´ aznamu v topologické databázi. Ten se periodicky inkrementuje a pokud dosáhne hodnoty MaxAge, je informace v topologické databázi jiˇz povaˇzována za zastaralou a je odstranˇena z datab´ aze. Implicitnˇe je MaxAge nastaven na 1 hodinu. Aby nedoch´ azelo k odstranˇen´ı poloˇzek z databáze, tak se s periodou ˇcasovaˇce LSRefreshTime zas´ılaj´ı soused˚ um LSA pakety, které vynuluj´ı pol´ıˇcko Age u záznamu. Implicitn´ı hodnota tohoto ˇcasovaˇce je 30 minut.

2.3.6

Metrika a administrativn´ı vzd´ alenost

Metrika, kter´ a se pouˇz´ıv´ a u protokolu OSPF se naz´ yvá Cost nebo-li cena. RFC ale nespecifikuje, co by mˇelo b´ yt pouˇzito pro urˇcován´ı této ceny. Z RFC 2328 [5]: A cost is associated with the output side of each router interface. This ” cost is configurable by the system administrator. The lower the cost, the more likely the interface is to be used to forward data traffic. “ Vzhledem k tomu, ˇze tato pr´ ace se zab´ yvá Cisco technologiemi, je tˇreba vz´ıt v u ´vahu cenu, tak jak ji definuje firma Cisco. Ta pouˇz´ıvá jako cenu souˇcet ˇs´ıˇrek pásma v´ ystupn´ıch rozhran´ı po cestˇe od smˇerovaˇce do c´ılové s´ıtˇe. Cena rozhran´ı se vypoˇc´ıtá jako 108 /bw, kde bw je ˇs´ıˇrka p´ asma v jednotce bps. D´ıky tomuto vzorci dosáhneme toho, ˇze rozhran´ı s vˇetˇs´ı ˇs´ıˇrkou p´ asma budou m´ıt niˇzˇs´ı cenu. Jak bylo uvedeno v citaci v´ yˇse, ˇc´ım niˇzˇs´ı cena, t´ım je cesta preferovanˇejˇs´ı. Z daného vzorce ale vypl´ yv´ a, ˇze rozhran´ı FastEthernet (100 Mbps) a rychlejˇs´ı budou m´ıt stejnou cenu, tj. jedna. Nˇekteré implementace proto umoˇzn ˇuj´ı konstantu 108 zv´ yˇsit nebo zadat cenu rozhran´ı ruˇcnˇe, ˇc´ımˇz je moˇzné i priorizovat nˇekteré námi vybrané cesty. Administrativn´ı vzd´ alenost protokolu OSPF je 110. T´ım pádem jsou cesty zjiˇstˇené protokolem OSPF povaˇzov´ any za d˚ uvˇeryhodnˇejˇs´ı a t´ım pádem i preferovanˇejˇs´ı neˇz cesty zjiˇstˇené protokolem RIP nebo tˇreba IS-IS.

2.3.7

Vytv´ aˇ ren´ı smˇ erovac´ı tabulky

Po naplnˇen´ı topologické datab´ aze informacemi o topologii s´ıtˇe je tˇreba tyto informace transformovat na smˇerovac´ı tabulku. Tuto transformaci provád´ı algoritmus Dijkstra’s shortest path first (SPF). Tento algoritmus nejprve vytvoˇr´ı z databáze graf, pˇresnˇeji strom SPF. Vˇsechny hrany tohoto stromu ohodnot´ı cenami (metrikou). Vrcholem stromu je vˇzdy dan´ y smˇerovaˇc, kter´ y 3

Poˇc´ıtaˇcov´ a s´ıt’, kter´ a pokr´ yv´ a malé geografické u ´zem´ı, napˇr. dom´ acnost. S´ıt’ propojuj´ıc´ı nˇekolik smˇerovaˇc˚ u, nen´ı vˇsak schopna pos´ılat broadcast, napˇr. s´ıtˇe Frame Relay, ATM nebo X.25. 4

24

si tvoˇr´ı smˇerovac´ı tabulku. SPF pak vytváˇr´ı strom takov´ ym zp˚ usobem, ˇze se snaˇz´ı odstranit vˇsechny potenci´ aln´ı smyˇcky a naj´ıt nejlepˇs´ı moˇznou cestu do c´ılové s´ıtˇe. Kdyˇz uˇz je v´ ysledn´ y strom hotov´ y, do smˇerovac´ı tabulky se vˇzdy uloˇz´ı IP adresa c´ıle, dalˇs´ı skok (Next Hop) a celkov´ a cena cesty. Pokud SPF algoritmus objev´ı dvˇe cesty do c´ıle, které maj´ı stejnou cenu, vloˇz´ı do smˇerovac´ı tabulky obˇe. Následnˇe záleˇz´ı na nastaven´ı smˇerovaˇce, zda si vybere jednu z tˇechto cest nebo bude vyuˇz´ıvat obˇe a ˇcást paket˚ u zprávy poˇsle jednou cestou a druhou ˇca´st druhou cestou. Druh´ y uveden´ y zp˚ usob je praktiˇctˇejˇs´ı vzhledem k rovnomˇernému zat´ıˇzen´ı obou linek. Z tohoto popisu m˚ uˇze b´ yt jasné, ˇze algoritmus SPF je pro smˇerovaˇc pomˇernˇe nároˇcn´ y a nen´ı ˇz´ adouc´ı, aby se v´ ypoˇcet opakoval pˇr´ıliˇs ˇcasto. To m˚ uˇze b´ yt problém, pokud se v s´ıti objev´ı nˇejak´ a nestabiln´ı linka, která ˇcasto padá. Z tohoto d˚ uvodu byl stanoven minimáln´ı ˇcas mezi v´ ypoˇcty algoritmu SPF.

2.3.8

Designated Router

Z uvedeného popisu funkce OSPF protokolu vypl´ yvá, ˇze pokud mezi smˇerovaˇci nebudou spoje Point-to-point, ale s´ıt’ s v´ıcenásobn´ ym pˇr´ıstupem (Multiaccess), m˚ uˇze b´ yt komunikace mezi smˇerovaˇci n´ aroˇcn´ a a v nejhorˇs´ım pˇr´ıpadˇe m˚ uˇze zahltit linku. Vezmˇeme si jako pˇr´ıklad topologii z obrázku 2.2. Zde je propojeno pˇet smˇerovaˇc˚ u. Kaˇzd´ y smˇerovaˇc mus´ı s kaˇzd´ ym dalˇs´ım smˇerovaˇcem s´ıtˇe ustavit spojen´ı a konfrontovat své záznamy z datab´ aze. Pokud se stane jeden soused nefunkˇcn´ım, vˇsechny smˇerovaˇce si navzájem zaˇcnou pos´ılat informaci o zmˇenˇe topologie.

Obr´ azek 2.2: OSPF s´ıt’ bez Designated Router. Z obr´ azku 2.2 je zˇrejmé, ˇze pro pˇet smˇerovaˇc˚ u mus´ı doj´ıt k vytvoˇren´ı deseti spojen´ım. Z toho vypl´ yv´ a jednoduch´ y vztah pro v´ ypoˇcet potˇrebn´ ych spojen´ı, pokud máme v s´ıti s v´ıcen´ asobn´ ym pˇr´ıstupem n smˇerovaˇc˚ u: n(n − 1) (2.1) 2 Budeme-li m´ıt v této s´ıti napˇr´ıklad 100 smˇerovaˇc˚ u, vyˇsplhá se celkov´ y poˇcet spojen´ı na 4950! To linku hodnˇe zatˇeˇzuje a proto zde existuje ˇreˇsen´ı v podobˇe volby Designated Routeru a Backup Designated Routeru. 25

Smˇerovaˇce si na poˇc´ atku zvol´ı Designated Router (DR), coˇz je smˇerovaˇc s nejvyˇsˇs´ı prioritou (Router Priority). Backup Designated Router (BDR), nebo-li záloˇzn´ı DR, je smˇerovaˇc s druhou nejvyˇsˇs´ı prioritou. Informace o prioritˇe se zas´ılá na poˇcátku v Hello paketu. Smˇerovaˇc poté navazuje sousedské vztahy pouze s DR. Následnˇe veˇskerá komunikace mezi smˇerovaˇci prob´ıh´ a tak, ˇze smˇerovaˇc zaˇsle informaci DR a ten ji rozeˇsle vˇsem ostatn´ım smˇerovaˇc˚ um v s´ıti. V s´ıt´ıch Point-to-point se pro komunikaci mezi smˇerovaˇci pouˇz´ıvá unicast. Zde ale smˇerovaˇc pos´ıl´ a informace, jak DR, tak i BDR, proto se pouˇz´ıvá multicastov´ a komunikace.

2.3.9

Form´ at zpr´ avy

OSPF, narozd´ıl od protokolu RIP, nepouˇz´ıvá transportn´ı vrstvu, ale pracuje pˇr´ımo s protokolem IP. OSPF jej´ı funkce nepotˇrebuje, protoˇze si sám zajiˇst’uje detekci chyb a opravu. Kaˇzd´ a OSPF zpr´ ava je zabalena do IP paketu, jehoˇz hlaviˇcka obsahuje c´ılovou multicastovou adresu 224.0.0.5 nebo 224.0.0.6. V pˇr´ıpadˇe, ˇze v s´ıti pouˇz´ıváme DR a BDR, tak komunikace s nimi prob´ıh´ a na IP adrese 224.0.0.6 a komunikace se vˇsemi OSPF smˇerovaˇci pomoc´ı IP adresy 224.0.0.5. Hlaviˇcka Ethernetového rámce pak nese informaci o c´ılové multicastové MAC adrese 01-00-5E-00-00-05 nebo 01-00-5E-00-00-06. Z obr´ azku 2.3 je zˇrejmé, ˇze OSPF zpráva se skládá z hlaviˇcky a tˇela nesouc´ıho data. Zde pop´ıˇsi jen jednu z pˇeti nejˇcastˇeji pouˇz´ıvan´ ych zpráv – Hello paket. Hlaviˇcka je vˇsak u vˇsech zpráv stejn´ a a skl´ ad´ a se z tˇechto ˇcást´ı:

Obr´ azek 2.3: Struktura OSPF Hello paketu.

• Version – identifikuje verzi OSPF, která je pouˇzita. Nejˇcastˇeji se jedná o verzi 2. • Type – ud´ av´ a typ OSPF paketu (Hello, DBD, LSR, LSU nebo LSAck). • Packet length – ud´ av´ a délku paketu vˇcetnˇe hlaviˇcky v bytech. 26

• Router ID – identifikuje zdroj paketu, jedná se o jednoznaˇcn´ y identifikátor smˇerovaˇce. • Area ID – identifikuje oblast (Area), ke které paket patˇr´ı. • Checksum – kontroln´ı souˇcet zajiˇst’uje paket proti chybovosti nebo poniˇcen´ı pˇri pˇresunu. • AutType – obsahuje typ autentizace. Vˇsechny OSPF v´ ymˇeny zpráv jsou autentizov´ any. • Authentication – nese autentifikaˇcn´ı informaci. Datov´ a ˇc´ ast Hello paketu se skládá z tˇechto ˇcást´ı: • Network Mask – s´ıt’ovou masku souvisej´ıc´ı s rozhran´ım, skrz které je zpráva zas´ılána. • Hello Interval – ud´ av´ a interval mezi zas´ılán´ım Hello paket˚ u v sekundách. • Router Dead Interval – ud´ avá ˇcas v sekundách, po jejichˇz uplynut´ı, pokud nepˇrijde Hello paket, je soused odstranˇen z topologické databáze. • Router Priority – pouˇz´ıv´ a se pˇri volbˇe DR a BDR. • Designated Router (DR) – obsahuje identifikaci (Router ID) DR smˇerovaˇce. • Backup Designated Router (BDR) – obsahuje identifikaci (Router ID) BDR smˇerovaˇce. • List of Neighbor(s) – nese seznam identifikac´ı (Router ID) sousedn´ıch smˇerovaˇc˚ u.

2.4

N´ avrhov´ e vzory Cisco

Aby s´ıt’, kterou budeme vzorovˇe simulovat, byla co nejvˇernˇejˇs´ı a odpov´ıdala vyuˇzit´ı v praxi, pouˇzijeme pro vytvoˇren´ı topologi´ı návrhové vzory spoleˇcnosti Cisco. V této ˇcásti se proto budeme zab´ yvat hled´ an´ım a v´ ybˇerem vhodn´ ych návrhov´ ych vzor˚ u pro simulaci. Návrhov´ y vzor je vzorov´ a topologie, kterou Cisco doporuˇcuje vyuˇz´ıt pˇri návrhu s´ıt´ı. Na konci se krátce zm´ın´ıme o principu a smyslu redistribuce.

2.4.1

V´ ybˇ er vhodn´ ych n´ avrhov´ ych vzor˚ u

C´ılem této pr´ ace je prostudovat návrhové vzory od firmy Cisco se zamˇeˇren´ım na RIP a OSPF. Pro ide´ aln´ı propojen´ı tˇechto dvou protokol˚ u jsem se pˇri hledán´ı zamˇeˇrila na návrhové vzory zab´ yvaj´ıc´ı se redistribuc´ı mezi tˇemito protokoly. Na webov´ ych stránk´ ach firmy Cisco lze nalézt mnoho n´ avrhov´ ych vzor˚ u. M´ ym poˇzadavk˚ um vyhovoval [1]. V tomto dokumentu jsou tˇri návrhové vzory, které budu modelovat a simulovat. Vˇsechny topologie se skládaj´ı z páteˇre a okol´ı. Páteˇr se sklád´ a ze tˇr´ı smˇerovaˇc˚ u propojen´ ych mezi sebou. S´ıtˇe LAN, ve kter´ ych se pˇredpokládaj´ı uˇzivatelé a jiná koncov´ a zaˇr´ızen´ı, se napojuj´ı na tyto páteˇrn´ı smˇerovaˇce. V prvn´ım n´ avrhovém vzoru (obrázek 2.4) je v s´ıti pouˇzit pouze smˇerovac´ı protokol RIP. RIP je tˇr´ıdn´ı protokol, proto jsou zde pouˇzity IP adresy tˇr´ıdy B. Druh´ y n´ avrhov´ y vzor (obr´ azek 2.5) je dalˇs´ım krokem v pˇrechod z RIP protokolu na OSPF protokol. P´ ateˇr bude provozována na protokolu OSPF a LAN s´ıtˇe na protokolu RIP. Tedy tˇri p´ ateˇrn´ı smˇerovaˇce mus´ı b´ yt hraniˇcn´ımi smˇerovaˇci a je poˇzadováno, aby umˇely pracovat s obˇema smˇerovac´ımi protokoly a tak mohly mezi nimi provádˇet redistribuci. 27

Obr´ azek 2.4: S´ıt’ se smˇerovac´ım protokolem RIP.

Obr´ azek 2.5: RIP s´ıt’ se smˇerovac´ım protokolem OSPF ve stˇredu.

Tˇret´ı n´ avrhov´ y vzor (obr´ azek 2.6) pˇredstavuje s´ıt’ pouˇz´ıvaj´ıc´ı jiˇz jen smˇerovac´ı protokol OSPF. N´ avrh ale vyuˇz´ıv´ a nˇekolik autonomn´ıch oblast´ı. Autonomn´ı oblast páteˇrn´ı ˇcásti je area0 a kaˇzd´ a ze s´ıt´ı pˇripojen´ ych k páteˇrn´ım smˇerovaˇc˚ um tvoˇr´ı dalˇs´ı autonomn´ı oblast´ı area1 – area3. P´ ateˇrn´ı smˇerovaˇce jsou oblastn´ımi hraniˇcn´ımi smˇerovaˇci, které kontroluj´ı v´ ymˇenu smˇerovac´ıch informac´ı mezi oblastmi.

28

Obr´ azek 2.6: S´ıt’ rozdˇelená na OSPF oblasti.

2.5

Shrnut´ı kapitoly

Tato kapitola shrnula z´ akladn´ı poznatky o smˇerován´ı, smˇerovac´ıch protokolech a redistribuci. D´ ale jsme si popsali smˇerovac´ı protokoly RIP i OSPF, které jsou velmi populárn´ı a ˇcasto uˇz´ıvané, avˇsak kaˇzd´ y z nich je vhodn´ y pro jiné u ´ˇcely. Protokol RIP je nejstarˇs´ım a nejobl´ıbenˇejˇs´ım smˇerovac´ım protokolem. Hlavn´ı jeho v´ yhodou je jednoduchost a velmi snadná implementace, které ˇcasto vyváˇz´ı jeho nedostatky. Hlavn´ı nedostatek je absence masek, d´ıky které RIPv1 nepodporuje VLSM a CIDR. Tyto nev´ yhody jsou zcela odstranˇeny v novˇejˇs´ı verzi RIPv2. Avˇsak zásadn´ı nev´ yhodou st´ ale z˚ ustáv´ a metrika, kter´ a nab´ yv´ a 1 aˇz 15 skok˚ u a tedy nen´ı moˇzné nasadit protokol RIP v rozsáhl´ ych s´ıt´ıch. Obl´ıbenost protokolu je zˇrejmá, nebot’ se stále vyv´ıj´ı a jiˇz existuje i verze pro IPv6 (RIPng). OSPF je nejpouˇz´ıvanˇejˇs´ım protokol typu Link-state. Oproti protokolu RIP se m˚ uˇze pochlubit rychlejˇs´ı konvergenc´ı, moˇznost´ı zas´ılat masky s´ıtˇe (t´ım pádem i podpora CIDR a VLSM) a obecnˇe moˇznost´ı pouˇzit´ı ve vˇetˇs´ıch s´ıt´ıch. Po ustaven´ı spojen´ı komunikuj´ı smˇerovaˇce pomoc´ı unicastu (Point-to-point s´ıtˇe) nebo multicastu (Multiaccess s´ıtˇe), coˇz je v´ yhodné pro malé zat´ıˇzen´ı linky. OSPF také podporuje autentizaci s ˇsifrován´ım hesla MD5, která zajiˇst’uje ovˇeˇrov´ an´ı pravosti pˇredávan´ ych informac´ı. Nem˚ uˇze tedy doj´ıt k podvrˇzen´ı informace a n´ aslednému pˇresmˇerován´ı provozu. Hlavn´ı nev´ yhodou je nároˇcnost algoritmu SPF a t´ım p´ adem neschopnost reagovat na pˇr´ıliˇs ˇcasté zmˇeny a také vysoká nároˇcnost kladen´ a na smˇerovaˇc pˇri v´ ypoˇctu. Proto jsou zaˇr´ızen´ı podporuj´ıc´ı OSPF draˇzˇs´ı. Vˇetˇs´ı firmy a instituce si ale jistˇe r´ adi pˇriplat´ı a z´ıskaj´ı tak v´ yhody tohoto protokolu. Perspektiva pro’ tokolu je zˇrejm´ a, nebot se st´ ale vyv´ıj´ı a jiˇz existuje i verze pro IPv6 (OSPFv3). K dokreslen´ı pˇriklád´ am srovn´ avac´ı tabulku 2.1. Na str´ ank´ ach firmy Cisco jsem vybrala návrhové vzory t´ ykaj´ıc´ıch se uˇzit´ı protokol˚ u RIP

29

a OSPF ve vˇetˇs´ıch (firemn´ıch, ˇskoln´ıch) s´ıt´ıch. Pouˇzit´ı obou protokol˚ u v jedné s´ıti je pro jejich simulaci ide´ aln´ı a proto jsem se zamˇeˇrila i na jejich vzájemnou redistribuci. Popsané topologie jsou vhodné pro simulaci. Vlastnosti

RIPv1

RIPv2

OSPF

Distance Vector

Distance Vector

Link-state

pomalá

pomalá

rychlá

Metrika

poˇcet skok˚ u

poˇcet skok˚ u

cena cesty

VLSM

ne

ano

ano

CIDR

ne

ano

ano

Zat´ıˇzen´ı smˇerovaˇce

malé

malé

velké

Zat´ıˇzen´ı s´ıtˇe

velké

velké

malé

Typ protokolu Konvergence

Tabulka 2.1: Srovnán´ı smˇerovac´ıch protokol˚ u RIP a OSPF

30

Kapitola 3

Simulaˇ cn´ı modely Co je to modelov´ an´ı a simulaˇcn´ı model jsme si jiˇz vysvˇetlili v sekci 1.1. Nyn´ı m˚ uˇzeme pˇrevést teorii do praxe a za pouˇzit´ı nástroj˚ u PT (sekce 1.2) a OMNeT++ (sekce 1.3) vytvoˇrit simulaˇcn´ı modely topologi´ı s´ıt´ı z vybran´ ych návrhov´ ych vzor˚ u (sekce 2.4).

3.1

Simulaˇ cn´ı modely v PT

V této sekci si vysvˇetl´ım, jak jsme vytváˇreli dle návrh˚ u simulaˇcn´ı modely v programu PT.

3.1.1

Tvorba model˚ u

Pro vytvoˇren´ı modelu jsem pouˇzila Cisco smˇerovaˇce 1841 s modulem WIC-2T a pˇrep´ınaˇce 2960. Smˇerovaˇce jsem mezi sebou propojila sériov´ ym kabelem a k smˇerovaˇc˚ um jsem pˇripojila kˇr´ıˇzen´ ym kabelem dalˇs´ı smˇerovaˇce pˇredstavuj´ıc´ı pods´ıtˇe a k nim pˇr´ım´ ym kabelem po jednom pˇrep´ınaˇci. Modelovˇe jsem ke kaˇzdému pˇrep´ınaˇci pˇripojila pˇr´ım´ ym kabelem po dvou poˇc´ıtaˇc´ıch. Na obr´ azku 3.1 je vidˇet v´ ysledná topologie. Následovalo nakonfigurov´ an´ı s´ıtˇe. Ke konfiguraci smˇerovaˇc˚ u jsme pouˇzili IOS. V´ ypis konfiguraˇcn´ıho registru pro prvn´ı model (pouze RIP) na smˇerovaˇci R1 je následuj´ıc´ı: interface FastEthernet0/0 ip address 130.10.8.1 255.255.255.0 duplex auto speed auto ! interface Serial0/1/0 ip address 130.10.62.1 255.255.255.0 clock rate 56000 ! interface Serial0/1/1 ip address 130.10.63.2 255.255.255.0 clock rate 56000 ! router rip network 130.10.0.0

;konfigurace ethernetov´ eho portu ; nastaven´ ı IP adresy a masky

; konfigurace s´ eriov´ eho portu ; nastaven´ ı IP adresy a masky ; kmitoˇ cet (u DCE)

; konfigurace protokolu RIP ; distribuovan´ a s´ ıt’

Nastaven´ı na smˇerovaˇci R1 pro druh´ y model (RIP + OSPF) je: 31

Obr´ azek 3.1: Topologie s´ıtˇe v PT.

interface FastEthernet0/0 ip address 130.10.8.1 255.255.255.0 duplex auto speed auto ! interface Serial0/1/0 ip address 130.10.62.1 255.255.255.0 clock rate 56000 ! interface Serial0/1/1 ip address 130.10.63.2 255.255.255.0 clock rate 56000 ! router ospf 100 log-adjacency-changes redistribute rip subnets network 130.10.62.0 0.0.0.255 area 0 network 130.10.63.0 0.0.0.255 area 0 ! router rip ; redistribute ospf 100 metric 4 ; passive-interface Serial0/1/0 ; passive-interface Serial0/1/1 ; network 130.10.0.0 ;

; konfigurace protokolu OSPF ; redistribuce do RIP ; distribuovan´ e s´ ıtˇ e

konfigurace protokolu RIP redistribuce do OSPF s metrikou 4 rozhran´ ı, na kter´ e se nebudou ... ... zasilat RIP zpr´ avy ’ distribuovan´ a s´ ıt

Nastaven´ı na smˇerovaˇci R1 v tˇret´ım modelu (OSPF oblasti) je:

32

interface FastEthernet0/0 ip address 130.10.8.1 255.255.255.0 duplex auto speed auto ! interface Serial0/1/0 ip address 130.10.62.1 255.255.255.248 clock rate 56000 ! interface Serial0/1/1 ip address 130.10.63.1 255.255.255.248 clock rate 56000 ! router ospf 100 log-adjacency-changes redistribute rip subnets network 130.10.62.0 0.0.0.255 area 0 network 130.10.63.0 0.0.0.255 area 0 network 130.10.8.0 0.0.0.255 area 1

3.2

Simulaˇ cn´ı modely v OMNeT++

V této sekci vysvˇetl´ıme tvorbu simulaˇcn´ıch model˚ u v nástroji OMNeT++. OMNeT++ jako takov´ y nem´ a témˇeˇr ˇz´ adné moˇznosti pro smˇerován´ı a nepodporuje protokoly RIP a OSPF. Proto pouˇzijeme framework INET, kter´ y má podporu OSPF a obsahuje dalˇs´ı d˚ uleˇzité im’ plementace pro s´ıt ov´ y provoz. Protokol RIP zcela chyb´ı a bude ho tˇreba doimplementovat.

3.2.1

Modelov´ an´ı n´ avrhov´ ych vzor˚ u

Nejprve si vytvoˇr´ıme sloˇzky pro budouc´ı simulaˇcn´ı modely. Pro kaˇzd´ y návrhov´ y vzor vytvoˇr´ıme model s´ıtˇe v jazyce NED. Jedn´ a se o sloˇzen´ y modul. Popis vˇsech tˇr´ı model˚ u je podobn´ y. Pouˇzijeme sloˇzen´ y modul smˇerovaˇce ANSARouter, kter´ y vznikl v rámci bakaláˇrské pr´ ace V. Siváka [14]. Kromˇe tohoto modulu vyuˇzijeme jednoduché moduly s´ıt’ov´ ych prvk˚ u z knihovny INET a to koncové zaˇr´ızen´ı typu StandardHost a pˇrep´ınaˇce typu EtherSwitch. ˇ ast RIP.ned souboru Nakonec provedeme propojen´ı jejich bran, resp. s´ıt’ov´ ych rozhran´ı. C´ popisuj´ıc´ı topologii prvn´ıho modelu (viz. obr. 2.4) je: import import import import import import

inet.nodes.ethernet.EtherSwitch; inet.ansa.ANSARouter; inet.nodes.inet.StandardHost; inet.world.ChannelInstaller; inet.world.ScenarioManager; ned.DatarateChannel;

network RIP { <ˇ c´ ast k´ odu vypuˇ stˇ ena>

; vloˇ zen´ e knihovny

; n´ azev modelovan´ e s´ ıtˇ e

33

submodules: ; moduly, ze kter´ ych se skl´ ad´ a <ˇ c´ ast k´ odu vypuˇ stˇ ena> H11: StandardHost { ; PC parameters: ; obr´ azek a jeho um´ ıstˇ en´ ı @display("p=40,52;i=device/pc2"); gates: ethg[1]; ; jedno ethernetov´ e rozhran´ ı } S1: EtherSwitch { ; pˇ rep´ ınaˇ c parameters: @display("p=168,92;i=device/switch"); gates: ethg[3]; ; m´ a tˇ ri ethernetov´ e rozhran´ ı } R1: ANSARouter { ; smˇ erovaˇ c parameters: @display("p=357,93;i=srouter"); gates: ethg[3]; ; m´ a tˇ ri ethernetov´ e rozhran´ ı } <ˇ c´ ast k´ odu vypuˇ stˇ ena> connections: ; propojen´ ı modul˚ u skrz br´ any H11.ethg[0] <--> C <--> S1.ethg[1]; H21.ethg[0] <--> C <--> S2.ethg[1]; S1.ethg[0] <--> C <--> R1A.ethg[0]; S2.ethg[0] <--> C <--> R2B.ethg[0]; R1.ethg[0] <--> C <--> R1A.ethg[1]; R2.ethg[0] <--> C <--> R2B.ethg[1]; <ˇ c´ ast k´ odu vypuˇ stˇ ena> }

Pro kaˇzd´ y model je d´ ale nutné vytvoˇrit soubor omnetpp.ini, kter´ y obsahuje parametry pro spuˇstˇen´ı simulace. Nakonec pro modely vytvoˇr´ıme spustiteln´ y soubor run. Do tohoto souboru staˇc´ı napsat: #!/bin/sh ../../../../src/run_inet $* Soubor se odkazuje na pˇreloˇzenou knihovnu INET. Spuˇstˇen´ı souboru zajist´ı naˇcten´ı nastaven´ı ze souboru omnetpp.ini a spuˇstˇen´ı simulaˇcn´ıho prostˇred´ı.

3.2.2

Pˇ r´ıprava model˚ u pro simulaci

Plnˇe funkˇcn´ı vytvoˇr´ıme zat´ım pouze tˇret´ı model (viz. obr. 2.6), kter´ y vyuˇz´ıvá smˇerovac´ı protokol OSPF a smˇerov´ an´ı mezi ˇctyˇrmi oblastmi (Area 0 - 3). Pˇrestoˇze INET obsahuje implementaci protokolu OSPF, pouˇzijeme upravenou verzi OSPF, která vznikla v rámci bakaláˇrské pr´ ace [4]. 34

V pˇredchoz´ı sekci jsme si vytvoˇrili soubor popisuj´ıc´ı topologii s´ıtˇe ospfAreas.ned. V´ yslednou topologii je moˇzné vidˇet na obrázku 3.2.

Obr´ azek 3.2: Topologie s´ıtˇe v OMNeT++.

Pro konfiguraci s´ıtˇe vyuˇz´ıv´ ame XML soubor RoutersConfig, jehoˇz struktura byla navrˇzena v rámci bakal´ aˇrské pr´ ace P. Scherfela [13]. V nˇem pˇriˇrad´ıme jednotliv´ ym rozhran´ım smˇerovaˇc˚ u IP adresy a masky a provedeme jejich rozdˇelené do oblast´ı OSPF. Dále vytvoˇr´ıme pro zaˇr´ızen´ı pracuj´ıc´ı se smˇerovac´ı tabulkou (PC, smˇerovaˇc) soubory obsahuj´ıc´ı konfiguraci s´ıt’ov´ ych rozhran´ı a statické cesty. Tyto informace se nacházej´ı v souborech .irt. N´ azev souboru je pro kaˇzdé zaˇr´ızen´ı uloˇzeno v inicializaˇcn´ım souboru omnetpp.ini v parametru routingFileName. U kaˇzdém s´ıt’ového rozhran´ı nap´ıˇseme jméno rozhran´ı, IP adresu, masku, multicastové skupiny, MTU a metriku. Poté, co naimplementujeme protokol RIP a redistribuci, dopln´ıme zb´ yvaj´ıc´ı dva modely pro OMNeT++ podobn´ ym zp˚ usobem, jak´ y byl v této sekci uveden. Konfiguraˇcn´ı soubory k jednotliv´ ym model˚ um jsou uvedeny v pˇr´ıloze D.

3.3

Shrnut´ı kapitoly

V této kapitole jsme vytvoˇrili modely v programu PT. Vyváˇrené modely jsme nakonfigurovali v IOS stejnˇe jako v na reálném zaˇr´ızen´ı, coˇz je velká v´ yhoda programu PT. Vytváˇren´ı model˚ u bylo velmi lehké a rychlé. Vznikli nám tak tˇri soubory .pkt, které jsou pˇripraveny pro simulaci. V OMNeT++ se simulaˇcn´ı modely vytváˇrely h˚ uˇr a to pˇredevˇs´ım kv˚ uli nutnosti popsat modely v m´ alo zn´ amém jazyku NED. Plnˇe funkˇcn´ı je pouze model vyuˇz´ıvaj´ıc´ı protokol OSPF. Pro ostatn´ı n´ avrhové vzory bude tˇreba doimplementovat ˇcásti umoˇzn ˇuj´ıc´ı smˇerovan´ı pomoc´ı protokolu RIP a umoˇzn ˇuj´ıc´ı redistribuci mezi RIP a OSPF.

35

Kapitola 4

Implementace Tato kapitola se zab´ yv´ a implementac´ı jednoduch´ ych modul˚ u do framework INET pro smˇerovac´ı protokol RIP a pro redistribuci smˇerovac´ıch informac´ı mezi protokoly RIP a OSPF.

4.1

Implementace protokolu RIP

V této sekci bude pops´ ana postupná implementace smˇerovac´ıho protokolu RIP v jeho prvn´ı verzi. Bude se zab´ yvat popisem jednotliv´ ych tˇr´ıd, ze kter´ ych se jeho implementace sklád´ a. Pˇri implementaci jsme vych´ azeli z RFC 1058 [5].

4.1.1

RIPPacket

Pro spr´ avnou funkˇcnost smˇerovac´ıho protokolu si nejprve vytvoˇr´ıme zprávu, která ponese vˇsechny informace, které nese i reálná zpráva RIP. Zpráva RIPPacket.msg plnˇe koresponduje se standardem (obr´ azek 2.1). Po pˇrekladu se automaticky vygeneruje pˇr´ısluˇsn´ y zdrojov´ y (.cc) a hlaviˇckov´ y soubor. RIPPacket.msg vypadá následovnˇe: struct RouteEntry { short addressID; short mustBeZero2 = 0; IPAddress ipAdress; long mustBeZero3 = 0; long mustBeZero4 = 0; long metric; }

; z´ aznamy o cest´ ach ; typ adresy (2 pro IP) ; adresa

; metrika

message RIPPacket { char command enum(RIPCommand); char version = 1; short mustBeZero1 = 0; RouteEntry routeEntry[]; }

36

; typ zpr´ avy (Req/Resp) ; verze protokolu RIP ; z´ aznamy o cest´ ach

4.1.2

RIPTimer

Jak jsme si uvedli v podsekci 4.1.2, protokol RIP vyuˇz´ıvá tˇri ˇcasovaˇce. V diskrétn´ı simulaci se ˇcasovaˇce modeluj´ı jako zpr´ avy, které objekt zas´ılá sám sobˇe se zpoˇzdˇen´ım. Proto jsme pro nˇe vytvoˇrili zpr´ avu RIPTimer.msg. Struktura zprávy je: enum RIPTimerType { hello = 1; timeout = 2; garbage = 3; trigger = 4; };

; typ ˇ casovaˇ ce ; ; ; ;

ˇasovaˇ c c casovaˇ ˇ c casovaˇ ˇ c odpoˇ cet

Update Timeout Garbage pˇ red rozesl´ an´ ım zmˇ en

message RIPTimer extends cMessage { char timerKind enum(RIPTimerType) = hello; };

; typ ˇ casovaˇ ce

ˇ V´ yznam ˇcasovaˇc˚ u Update, Timeout a Garbage byl popsán v podsekci . Casovaˇ c Trigger se vyuˇz´ıv´ a pro rozes´ıl´ an´ı aktualizac´ı pˇri v´ yznamné zmˇenˇe (pád/obnoven´ı linky, zmˇena cesty).

4.1.3

RIPRouting

Pro jednoduch´ y modul RIPRouting jsme vytvoˇrili popis v souboru RIPRouting.ned a provedli jeho implementaci v jazyce C++. Jedná se o tˇr´ıdu, která je odvozena od tˇr´ıdy UDPAppBase. Ta n´ am poskytuje prostˇredky transportn´ıho protokolu UDP, kter´ y RIP vyuˇz´ıv´ a. Jak m˚ uˇzeme vidˇet na obr´ azku 4.1, RIP modul je pˇripojen na UDP modul. Hlaviˇckov´ y soubor tˇr´ıdy je uveden v pˇr´ıloze C.

Obr´ azek 4.1: Modul ANSARouter obsahuj´ıc´ı modul RIP.

37

Metoda handleMessage() pˇr´ıjme zprávu a rozpozná, zda jde o zprávu odeslanou z tohoto (nˇekter´ y z ˇcasovaˇc˚ u RIP) nebo jiného procesu. V pˇr´ıpadˇe, ˇze se jedná o ˇcasovaˇc, provede poˇzadované akce (odesl´ an´ı zprávy, smazán´ı cesty ze smˇerovac´ı tabulky, restartov´ an´ı ˇcasovaˇce). V pˇr´ıpadˇe, ˇze se jedn´ a o ciz´ı zprávu, pˇrepoˇsle ji metodˇe processPacket(). Ta zkontroluje IP adresu, verzi protokolu, strukturu zprávy a zjist´ı, zda se jedná o ˇzádost (Request) nebo odpovˇed’ (Response). Podle toho zprávu dále zpracovává metoda processRequest() nebo processResponse().

Obrázek 4.2: Diagram aktivit zobrazuj´ıc´ı vztahy mezi metodami ve tˇr´ıdˇe RIPRouting.

Metoda processRequest() zkontroluje poˇcet záznamu v ˇzádosti. Pokud je jen jedna, ˇzádá odes´ılatel o vˇsechny z´ aznamy z smˇerovac´ı tabulky. Zavolá metodu sendPacket(), kter´ a se postar´ a o sestavn´ı a zasl´ an´ı v´ ysledné zprávy sousedovi. Tato metoda vyuˇz´ıvá metodu createPacket() pro vytvoˇren´ı zprávy a naplnˇen´ı zprávy smˇerovac´ımi informacemi. Metoda processResponse zpracovává zprávy se smˇerovac´ımi informacemi, které pˇricházej´ı od sousedn´ıch smˇerovaˇc˚ u. Nejprve zkontroluje, jestli je kaˇzd´ y záznam legáln´ı, tedy jestli se nejedn´ a o IP adresu smyˇcky (Loopback), adresy tˇr´ıdy E nebo D apod. Následnˇe dojde k porovn´ an´ı adresy s adresami v smˇerovac´ı tabulce. Pokud se v n´ı taková adresa jeˇstˇe nevyskytuje, vytvoˇr´ı se nov´ y z´ aznam a nastav´ı se mu ˇcasovaˇc Timout. Pokud jiˇz adresa s´ıtˇe v tabulce existuje, zkontroluje se metrika. V pˇr´ıpadˇe, ˇze záznam má menˇs´ı metriku, neˇz záznam v tabulce, dojde k aktualizaci záznamu. Nakonec dojde k restartován´ı ˇcasovaˇce Timeout. 38

Cel´ y postup zobrazuje diagram aktivit na obrázku 4.2. Pˇr´ıklad konfigurace je uveden v pˇr´ıloze D.

4.2

Implementace redistribuce

V rámci této pr´ ace byla naprogramována redistribuce cest z protokolu OSPF do protokolu RIP. Tuto ˇcinnost prov´ ad´ı metoda getOSPFRoutes(). Pro jej´ı správnou ˇcinnost byla vytvoˇrena struktura RIPRedistribution: struct RIPRedistribution { bool redistrinute; char * protocol; int metric; };

; je nastavena redistribuce? ; redistribuovan´ y protokol ; metrika redistribuovan´ ych cest

Pˇri inicializaci se do struktury naˇctou z konfiguraˇcn´ıho souboru informace o redistribuci. Zaznamen´ av´ a, jestli v˚ ubec bude redistribuce prob´ıhat, s jak´ ym protokolem bude redistribuce prob´ıhat (v naˇsem pˇr´ıpadˇe pouze OSPF), a jakou metriku budou m´ıt nové RIP záznamy po redistribuci. Metoda getOSPFRoutes() zkontroluje, jestli poloˇzka protocol je nastavena na ospf. Pokud ano zaˇcne proch´ azet z´ aznamy smˇerovac´ı tabulky a kontrolovat jejich zdroj na hodnotu OSPF. Takové cesty zaznamen´ a do struktury RouteEntry zm´ınˇené u zpráv RIPPacket a metriku dopln´ı na hodnotu uloˇzenou ve struktuˇre RIPRedistribution. Takto vytvoˇrené záznamy se pak pˇred´ avaj´ı k dalˇs´ımu zpracován´ı, zaˇclenˇen´ı do RIP zprávy a odeslán´ı soused˚ um. Pˇr´ıklad konfigurace redistribuce pro jeden smˇerovaˇc je: ospf <Metric>4

4.3

; redistribuovan´ y protokol ; RIP metrika redistribuovan´ ych cest

Shrnut´ı kapitoly

Tato kapitola nast´ınila implementaci protokolu RIP a redistribuce. Protokol RIP byl implementov´ an dle RFC 1058 [5]. Implementace splnila vˇsechny jeho poˇzadavky aˇz na autosumarizaci. Ta by pˇr´ıpadnˇe mohla b´ yt v budoucnu doimplementována. Pro naˇse potˇreby simulace bychom ji ale nevyuˇzili a aktuáln´ı implementace nám bude plnˇe dostaˇcovat. D´ ale byl naimplementov´ an Split Horizon. V budoucnu by bylo moˇzné implementaci rozˇs´ıˇrit také o dalˇs´ı ochrann´ y prostˇredek Poison Reverse. V r´ amci této pr´ ace byla naimplementována redistribuce z protokolu RIP do protokolu OSPF. Pro plné vyuˇzit´ı redistribuce se poˇc´ıtá s vyuˇzit´ım implementace redistribuce z protokolu RIP do protokolu OSPF, která je souˇcást´ı jiné bakaláˇrské práce [4], a implementace z bakal´ aˇrské pr´ ace [14], kter´ a zajist´ı zas´ılán´ı informac´ı o zmˇenˇe v smˇerovac´ı tabulce. 39

Kapitola 5

Simulace v prostˇ red´ı Packet Tracer a OMNeT++ V této kapitole prakticky vyuˇzijeme naimplementované tˇr´ıdy a simulaˇcn´ı modely. Nejprve si definujeme vlastnosti, které chceme ovˇeˇrit simulac´ı: dostupnost a stabilita s´ıtˇe. Následnˇe provedeme simulaci v obou zmiˇ novan´ ych nástroj´ıch – Packet Tracer a OMNeT++. Pro popis simulaci tˇechto vlastnost´ı pouˇzijeme referenˇcn´ı obrázek 5.1.

Obr´ azek 5.1: Topologie simulovan´ı s´ıtˇe.

5.1

Dostupnost

Základn´ım poˇzadavkem pro kaˇzdou s´ıt’ je dostupnost. Abychom mohli s´ıt’ plnˇe vyuˇz´ıvat, mus´ıme si b´ yt jisti, ˇze za jak´ ychkoliv podm´ınek jsou vˇsechny segmenty s´ıtˇe odkudkoliv dostupné. Proto je vhodné vyuˇz´ıvat záloˇzn´ı linky a podobná opatˇren´ı. V následuj´ıc´ıch simulac´ıch budeme uvaˇzovat, ˇze dojde k pádu linky mezi smˇerovaˇci R1 a R2. Dostupnost mezi s´ıtˇemi 192.168.8.0/24 a 192.168.17.0/24 by mˇel záloˇznˇe zajistit smˇerovaˇc R3. Ovˇeˇrovat ji budeme zas´ıl´ an´ım ICMP1 paket˚ u mezi obˇema s´ıtˇemi.

5.1.1

Simulace dostupnosti v n´ astroji Packet Tracer

V PT jsme si vytvoˇrili pomoc´ı funkce Add Complex PDU scénáˇr, ve kterém bude poˇc´ıtaˇc PC4 periodicky (35 sekund) zas´ılat ICMP pakety poˇc´ıtaˇci PC0, viz. obrázek 5.1. Spustili 1 Anglicky Internet Control Message Protocol, pouˇz´ıv´ a se pro odes´ıl´ an´ı chybov´ ych zpr´ av (poˇzadovan´ a sluˇzba/host/s´ıt’ nen´ı dostupn´ a apod.).

40

jsme simulaci a sledovali pr˚ ubˇeh cesty paketu. Podle oˇcekáván´ı byl paket smˇerován pˇres smˇerovaˇce R1 a R2 (obr´ azek 5.2a). V simulaˇcn´ım ˇcase 35.011 jsme zastavili simulaci, pˇreˇsli jsme do CLI2 smˇerovaˇce R2 a pomoc´ı pˇr´ıkaz˚ u R2(config)#int s0/1/0 R2(config-if)#shutdown

Obrázek 5.2: V´ ypis pr˚ uchodu ICMP paketu s´ıt’ov´ ymi zaˇr´ızen´ımi. a) Linky jsou v poˇrádku. b) Pˇri cestˇe paketu zpˇet doˇslo k pádu linky. c) Linka mezi R1 a R2 je nefunkˇcn´ı.

jsme vypnuli rozhran´ı s0/1/0 vedouc´ı k smˇerovaˇci R1. ICMP paket se v té dobˇe nacházel v poˇc´ıtaˇci PC0. Pˇri cestˇe zpˇet k PC4 smˇerovaˇc R2 jeˇstˇe neznal novou cestu do s´ıtˇe 192.168.8.0 /24, proto smˇerovaˇc vr´ atil poˇc´ıtaˇci PC0 ICMP paket typu Destination Unreachable (obrázek 5.2b). Dalˇs´ı ICMP paket, kter´ y byl vyslán v ˇcase 70 sekund, byl smˇerován novou cestou, která se mezit´ım ustanovila, tedy pˇres smˇerovaˇce R1, R3 a R2 (obrázek 5.2, c). Simulaci jsme znovu zopakovali. Tentokrát jsme um´ıstili na rozhran´ı s0/1/1 (ve smˇeru od R3) smˇerovaˇce R2 ACL. Zadali jsme ho v CLI takto: R2(config)#access-list 101 deny icmp any 192.168.17.0 0.0.0.255 R2(config)#access-list 101 permit ip any any R2(config)# R2(config)#int s0/1/1 R2(config-if)#ip access-group 101 in

Po té co byla simulace spuˇstˇena se vˇsemi funkˇcn´ımi linkami, se s´ıt’ chovala jako pˇri pˇredchoz´ım testu. Po té jsme znovu vypnuli rozhran´ı mezi smˇerovaˇci R1 a R2. Tentokrát se s´ıt’ 192.168.17.0/24 stala nedostupnou (obrázek 5.3). Pˇrestoˇze paket byl pˇredán ze smˇerovaˇce R1 na R3, tak n´ asleduj´ıc´ı smˇerovaˇc R2 dle nastaveného ACL paket zahodil. 2

Rozhran´ı s pˇr´ıkazovou ˇra ´dkou urˇcené pro konfiguraci Cisco zaˇr´ızen´ı, zejména smˇerovaˇc˚ u a pˇrep´ınaˇc˚ u.

41

Obrázek 5.3: V´ ypis pr˚ uchodu ICMP paketu s´ıt’ov´ ymi zaˇr´ızen´ımi. ACL na smˇerovaˇci R2 paket zahodil.

5.1.2

Simulace dostupnosti v n´ astroji OMNeT++

Pro simulace v OMNeT++ vyuˇzijeme manaˇzer stav˚ u linek (tˇr´ıda InterfaceStateManager), kter´ y vznikl v r´ amci bakal´ aˇrské práce M. Danka [4]. Tato tˇr´ıda umoˇzn ˇuje vytvoˇren´ı scén´ aˇre simulace pomoc´ı XML souboru. Zde je ukázka XML souboru, kter´ y vyuˇzijeme pro tuto simulaci: <scenario>

V souboru uv´ ad´ıme, ˇze v simulaˇcn´ım ˇcase 200 sekund dojde k vypnut´ı rozhran´ı eth1 na smˇerovaˇci R2. V simulaˇcn´ım ˇcase 300 sekund dojde k jeho opˇetovnému zapnut´ı. Pro zas´ıl´ an´ı ICMP paket˚ u jsme vyuˇzili aplikaci Ping (tˇr´ıda pingApp) na poˇc´ıtaˇci H11. Ten v pravideln´ ych intervalech zas´ılá ICMP pakety typu Echo poˇc´ıtaˇci H21 (obrázek 5.1). Simulace vypisovala trasy, kter´ ymi putoval ICMP paket: -----------------------------------------------Time = 19.208472580648 H11 : Ping 0 to 192.168.17.21 Path: H11 - DROP ----------------------------------------------- -----------------------------------------------Time = 89.208472580648 42

H11 : Ping 2 to 192.168.17.21 Path: H11 - R1A - R1 - R2 - R2B - H21 - H21 - R2B - R2 ----------------------------------------------- -----------------------------------------------Time = 194.208472580648 H11 : Ping 5 to 192.168.17.21 Path: H11 - R1A - R1 - R2 - R2B - H21 - H21 - R2B - R2 - ICMP ERROR -----------------------------------------------Time = 229.208472580648 H11 : Ping 6 to 192.168.17.21 Path: H11 - R1A - R1 - R3 - R2 - R2B - H21 - H21 - R2B - R1A - H11 ----------------------------------------------- -----------------------------------------------Time = 299.208472580648 H11 : Ping 8 to 192.168.17.21 Path: H11 - R1A - R1 - R3 - R2 - R2B - H21 - H21 - R2B - H11 -----------------------------------------------Time = 334.208472580648 H11 : Ping 9 to 192.168.17.21 Path: H11 - R1A - R1 - R2 - R2B - H21 - H21 - R2B - R2 ------------------------------------------------

- R1 - R1A - H11

- R2 - R2B - H21 -

- R2 - R3 - R1 -

- R2 - R1 - R1A -

- R1 - R1A - H11

V simulaˇcn´ım ˇcase 19 sekund jeˇstˇe smˇerovaˇce nemˇely naplnˇené smˇerovac´ı tabulky, smˇerovaˇc R1A neznal cestu k poˇc´ıtaˇci H21 (192.168.17.21), a proto byl ICMP paket zahozen. V simulaˇcn´ım ˇcase 89 sekund jsou vˇsechny linky funkˇcn´ı. ICMP paket je zaslán nejkratˇs´ı cestou ze smˇerovaˇce R1A, pˇres smˇerovaˇce R1, R2, R2B, aˇz k c´ılovému poˇc´ıtaˇc H21. Cesta zpˇet je totoˇzn´ a. ICMP paket zaslan´ y v ˇcase 194 sekund se dostal stejnou cestou k poˇc´ıtaˇci H21. V ˇcase 200 sekund dojde p´ adu linky mezi smˇerovaˇci R1 a R2. ICMP paket Echo-Reply je smˇerov´ an zpˇet z H21 na smˇerovaˇc R2. Smˇerovaˇc R2 jeˇstˇe nedostal novou informaci o s´ıti 192.168.8.0/24. Tuto s´ıt’ nezn´ a a proto poˇsle poˇc´ıtaˇci H21 nazpˇet ICMP paket typu Destination Unreachable (c´ıl nen´ı dostupn´ y). V ˇcase 229 sekund je jiˇz ustanovena nová cesta. ICMP paket je ze smˇerovaˇce R1 pˇreposl´ an na smˇerovaˇc R3, n´ aslednˇe na smˇerovaˇc R2. V ˇcase 299 sekund je linka mezi smˇerovaˇci R1 a R2 st´ ale nefunkˇcn´ı, proto ICMP paket putuje pˇres smˇerovaˇc R3. V ˇcase 300 sekund dojde k obnoven´ı funkˇcnosti linky a zpˇet jiˇz putuje paket p˚ uvodn´ı cestou, tedy ze smˇerovaˇce R2 na smˇerovaˇc R1. Dalˇs´ı test provedeme za pouˇzit´ı ACL um´ıstˇeného na smˇerovaˇci R2. Modul ACL byl vytvoˇren v r´ amci bakal´ aˇrské pr´ ace T. Suchomela [15]. ACL 110 je nastaven na portu eth2 smˇerovaˇce R2 (ve smˇeru od R3). Zápis v konfiguraˇcn´ım souboru: <entry seq_no="15"> 43

deny 0.0.0.0 192.168.17.0 <WC_src>255.255.255.255 <WC_dst>0.0.0.255 <protocol>icmp <entry seq_no="20"> permit 0.0.0.0 0.0.0.0 <WC_src>255.255.255.255 <WC_dst>255.255.255.255 <protocol>ip eth2

V´ ystup simulace je: -----------------------------------------------Time = 159.208472580648 H11 : Ping 4 to 192.168.17.21 Path: H11 - R1A - R1 - R2 - R2B - H21 - H21 - R2B - R2 - R1 - R1A - H11 -----------------------------------------------Time = 194.208472580648 H11 : Ping 5 to 192.168.17.21 Path: H11 - R1A - R1 - R2 - R2B - H21 - H21 - R2B - R2 - R2 - R2B - H21 - ICMP ERROR -----------------------------------------------Time = 229.208472580648 H11 : Ping 6 to 192.168.17.21 Path: H11 - R1A - R1 - R3 -----------------------------------------------Time = 264.208472580648 H11 : Ping 7 to 192.168.17.21 Path: H11 - R1A - R1 - R3 -----------------------------------------------Time = 299.208472580648 H11 : Ping 8 to 192.168.17.21 Path: H11 - R1A - R1 - R3 -----------------------------------------------Time = 334.208472580648 H11 : Ping 9 to 192.168.17.21 Path: H11 - R1A - R1 - R2 - R2B - H21 - H21 - R2B - R2 - R1 - R1A - H11 44

Poˇc´ ateˇcn´ı a koneˇcn´ y stav v´ ypisu je podobn´ y jako pˇri prvn´ı simulaci. V ˇcase 229 sekund, kdy je nefunkˇcn´ı linka mezi R1 a R2, je paket poslán pˇres smˇerovaˇc R3. Ten pˇredá paket smˇerovaˇci R2, kter´ y ale paket d´ıky ACL zahod´ı. Závˇereˇcn´ y v´ ypis statistiky pouˇzitého ACL (simulaˇcn´ı ˇcas 474 sekund): IP IP IP IP -

datagrams received: 142 packets permitted without ACL action: 122 packets permitted by ACL action: 17 packets denied by an ACL action: 3 rule has been used: 3x rule has been used: 17x Z v´ ypisu je zˇrejmé, ˇze pravidlo zakazuj´ıc´ı vstup ICMP paket˚ u bylo aplikováno tˇrikr´ at.

5.2

Stabilita

Následuj´ıc´ı simulace se zamˇeˇr´ı na stabilitu linky. I v této kapitole se zamˇeˇr´ıme na linku mezi smˇerovaˇci R1 a R2. Budeme vyb´ırat r˚ uzné ˇcasové intervaly mezi zap´ınán´ım a vyp´ınán´ım rozhran´ı eth1 (d´ ale jen ∆t) na smˇerovaˇci R2 (ve smˇeru k R1), ˇc´ımˇz budeme mˇenit stupeˇ n nestability linky a sledovat chován´ı s´ıtˇe. C´ılem simulace je zjistit, zda m˚ uˇze nestabilita ovlivnit dostupnost s´ıtˇe, i kdyˇz máme záloˇzn´ı linky.

5.2.1

Simulace stability v n´ astroji Packet Tracer

Simulace této vlastnosti v PT by byla velmi nároˇcná. Museli bychom vˇzdy mˇeˇrit ˇcas, po kterém je tˇreba zmˇenit stav linky, v tento ˇcas zastavit simulaci a v CLI smˇerovaˇce R2 vˇzdy ruˇcnˇe vypnout ˇci zapnout potˇrebné rozhran´ı. Avˇsak ani tato moˇznost nen´ı zcela provediteln´ a, protoˇze PT je diskrétn´ı simulátor. D´ıky tomu, ˇze docház´ı ke krokov´ ym zmˇen´ am v ˇcase pˇri ud´ alostech, nelze provést zastaven´ı simulace v námi poˇzadovan´ y ˇcas. Z tohoto d˚ uvodu jsme simulaci stability v PT neprovádˇeli.

5.2.2

Simulace stability v n´ astroji OMNeT++

Pro tuto simulaci jsme pouˇzili manaˇzer stav˚ u linek [4]. Do souboru XML jsme zapsali ˇcasové odstupy mezi zap´ın´ an´ım a vyp´ın´ an´ım rozhran´ı eth1 na smˇerovaˇci R2. Postupnˇe jsme volili ∆t rovno 250, 100, 50, 25, 20, 10, 5 a 1 sekunda. Zat´ımco bude linka mezi smˇerovaˇci R1 a R2 nestabiln´ı, budeme testovat dostupnost mezi s´ıtˇemi 192.168.8.0/24 a 192.168.17.0/24 pomoc´ı zas´ıl´ an´ı ICMP paket˚ u. Oproti simulaci dostupnosti jsme sn´ıˇzili ˇcas mezi zas´ılán´ım ICMP paket˚ u na 15 sekund, abychom mohli preciznˇeji sledovat zmˇeny v dostupnosti s´ıtˇe. Tento ˇcas byl vybrán z toho d˚ uvodu, ˇze odesl´ an´ı ICMP Echo a pˇr´ıjem ICMP Echo-Reply trvá pˇres 10 sekund. Kdybychom pouˇzili kratˇs´ı ˇcasovou prodlevu, v´ ypisy simulace by byly chaotické a nepouˇzitelné. V prvn´ı sérii test˚ u jsme nechali RIP konvergovat do ˇcasu 100 sekund. V tomto ˇcase jsou smˇerovac´ı tabulky vˇsech smˇerovaˇc˚ u v s´ıti naplnˇeny vˇsemi cestami a s´ıt’ je plnˇe funkˇcn´ı. Po tomto ˇcase doˇslo k vyp´ın´ an´ı a zap´ınán´ı rozhran´ı ve v´ yˇse uveden´ ych intervalech. Simulace byla prov´ adˇena od ˇcasu 0 po 250 sekund. Protoˇze namˇeˇrené hodnoty byly pro vˇsechny pokusy v rozmez´ı od 0 do 100 sekund stejné, tabulka 5.1 uvád´ı hodnoty namˇeˇrené aˇz od simulaˇcn´ıho ˇcasu 100 sekund. P´ısmeno X v této i následuj´ıc´ıch tabulkách zastupuje simulaci s´ıtˇe bez padaj´ıc´ıch linek. 45

Doba mezi zmˇenami stavu linky (∆t) [s]

X

250

100

50

25

20

15

5

1

Poˇcet zmˇen stavu linky v ˇcase 100 - 250 s

0

0

2

3

6

7

10

30

150

Poˇcet doruˇcen´ ych paket˚ u

10

10

8

8

6

4

2

2

0

Poˇcet nedoruˇcen´ ych paket˚ u

0

0

2

2

4

6

8

8

10

Paket jde bˇeˇznou cestu

10

10

3

3

3

2

2

2

0

Paket jde z´ aloˇzn´ı cestou (pˇres R3)

0

0

5

5

3

2

0

0

0

Tabulka 5.1: V´ ysledky prvn´ıho mˇeˇren´ı v ˇcase 100 - 250 sekund (posláno 10 paket˚ u).

Dále jsme testovali, jak se v´ ysledky zmˇen´ı pokud se nezaˇcnou pos´ılat ICMP pakety od ˇcasu 0 sekund, ale pozdˇeji. Jako startovn´ı ˇcas pro pravidelné odes´ılán´ı ICMP paket˚ u jsme zvolili 3, 6, 9 a 12 sekund. Tabulka 5.2 ukazuje, jak se pˇri tˇechto ˇcasov´ ych posunech mˇenil poˇcet doruˇcen´ ych paket˚ u. Doba mezi zmˇenami stavu linky (∆t) [s]

100

50

25

20

15

5

1

Startovn´ı ˇcas v nula sekund

8

8

6

4

2

2

0

Startovn´ı ˇcas v tˇrech sekund´ ach

8

7

7

5

0

0

0

Startovn´ı ˇcas v ˇsesti sekund´ ach

8

7

7

5

0

0

0

Startovn´ı ˇcas v dev´ıti sekund´ ach

8

6

6

3

2

2

0

Startovn´ı ˇcas v dvan´ acti sekundách

8

6

5

5

3

0

0

Pr˚ umˇern´ y poˇcet pˇrijat´ ych paket˚ u

8

6,8

6,2

4,4

1,4

0,4

0

Tabulka 5.2: Poˇcet doruˇcen´ ych paket˚ u v závislosti na startovn´ım ˇcase periodického zas´ıl´ an´ı ICMP paket˚ u (simulaˇcn´ı ˇcas 100 - 250 sekund). ˇ Casovaˇ c Trigger je zapnut v pˇr´ıpadˇe, ˇze doˇslo k pádu nˇekteré linky nebo zmˇenˇe cesty. Po jeho uplynut´ı zaˇsle smˇerovaˇc informace o celé svoj´ı smˇerovac´ı tabulce vˇsem sv´ ym soused˚ um. Délka tohoto intervalu se vol´ı n´ ahodnˇe v rozmez´ı nula aˇz pˇet sekund pro pˇr´ıpad, ˇze by v brzké dobˇe doˇslo k dalˇs´ı zmˇenˇe. Zabr´ an´ı se tak lavinovému zas´ılán´ı zpráv v pˇr´ıpadˇe mnoha zmˇen, které pˇrich´ azej´ı rychle za sebou. V pˇr´ıpadˇe, ˇze je linka vysoce nestabiln´ı (interval mezi zmˇenami je pod 10 sekund), hraje tento ˇcasovaˇc v´ yznamnou roli pˇri informován´ı soused˚ u o zmˇen´ ach smˇerovac´ıch tabulek a t´ım pádem i v mnoˇzstv´ı doruˇcen´ ych paket˚ u. Stejnˇe tak ovlivˇ nuje mnoˇzstv´ı doruˇcen´ ych paket˚ u v pˇr´ıpadˇe, ˇze posouváme startovn´ı ˇcas odes´ıl´ an´ı ICMP paket˚ u. V pˇr´ıpadˇe ∆t = 5 je to nejzˇretelnˇejˇs´ı (tabulka 5.2). Uvaˇzujme, ˇze v ˇcase nula by byly naplnˇeny smˇerovac´ı tabulky. Kdyby v ˇcase pˇet sekund spadla linka, do ˇcasu ˇsest sekund, tj. do jedné sekundy po pádu linky, se s nejvˇetˇs´ı pravdˇepodobnost´ı nestihnou zaslat aktualizace (ˇcasovaˇc Trigger by musel b´ yt nastaven na ˇcas menˇs´ı neˇz jedna sekunda). V ˇcase devˇet sekund, tj. ˇctyˇri sekundy po pádu linky, jsou aktualizace rozeslány s mnohem vˇetˇs´ı pravdˇepodobnost´ı (Trigger by musel b´ yt nastaven v rozmez´ı nula aˇz ˇctyˇri sekundy), proto pˇri tomto posunu doˇslo k pˇr´ıjmu nejv´ıce, tj. dvou, paket˚ u. Po té jsme provedli podobnou sérii simulac´ı, s t´ım rozd´ılem, ˇze linka byla nestabiln´ı uˇz od zah´ ajen´ı simulace, tedy od simulaˇcn´ıho ˇcasu 0 + ∆t. ∆t nab´ yvala postupnˇe hodnot 50, 25, 20, 10, 5 a 1 sekunda. ∆t = 100 a 250 sekund jsme vynechali, protoˇze pro tyto ˇcasy by byla situace stejn´ a jako v pˇredeˇslé sérii simulac´ı. Frekvence zas´ılán´ı ICMP paket˚ u z˚ ustala 46

stejná. Tabulka 5.3 uv´ ad´ı hodnoty namˇeˇrené simulac´ı od simulaˇcn´ıho ˇcasu 0 po 250 sekund. Doba mezi zmˇenami stavu linky (∆t) [s]

X

50

25

20

10

5

1

Poˇcet zmˇen stavu linky v ˇcase 0 - 250 s

0

5

10

12

25

50

250

Poˇcet u ´spˇeˇsnˇe doruˇcen´ ych paket˚ u

12

12

9

8

6

2

0

Poˇcet nedoruˇcen´ ych paket˚ u

4

4

7

8

10

14

16

Paket jde bˇeˇznou cestu

12

6

5

5

2

2

0

Paket jde z´ aloˇzn´ı cestou (pˇres R3)

0

6

4

3

4

0

0

Tabulka 5.3: V´ ysledky druhého mˇeˇren´ı v ˇcase 0 - 250 sekund (posláno 16 paket˚ u). I kdyˇz je s´ıt’ stabiln´ı (X), dojde ke ztrátˇe ˇctyˇr paket˚ u. Tato ztráta je zp˚ usobena t´ım, ˇze na poˇc´ atku simulace smˇerovaˇc R1A nezná cestu do s´ıtˇe 192.168.17.0/24, a proto pakety zahod´ı. Následuj´ıc´ı tabulka 5.4 uv´ ad´ı ˇcasy, ve kter´ ych doˇslo k naplnˇen´ı smˇerovac´ı tabulky smˇerovaˇce R1A cestou do s´ıtˇe 192.168.17.0/24 a t´ım pádem z´ıskán´ı potenciáln´ı moˇznosti smˇerovat ICMP pakety. Mˇeˇren´ı jsme provádˇeli prost´ ym sledován´ım smˇerovac´ıch tabulek pˇri simulaci. Ve chv´ıli, kdy se objevila cesta v tabulce smˇerovaˇce R1A, zaznamenali jsme ˇcas do tabulky. Doba mezi zmˇenami stavu linky (∆t) [s]

X

50

25

20

10

5

1

Simulaˇcn´ı ˇcas z´ısk´ an´ı cesty k c´ılové s´ıti [s]

60

60

30

30

30

22

12

Tabulka 5.4: Simulaˇcn´ı ˇcasy, ve kter´ ych byla z´ıskána cesta do s´ıtˇe 192.168.17.0/24.

5.3

Shrnut´ı kapitoly

V této kapitole jsme si pˇredvedli, jak jde simulaˇcn´ı modely vytvoˇrené podle návrhov´ ych vzor˚ u firmy Cisco vyuˇz´ıt k simulaci dostupnosti a stability linek. Vybrali jsme typické vlastnosti s´ıtˇe, které se v praxi ovˇeˇruj´ı, nebot’ jsou kl´ıˇcové pro správnou funkˇcnost s´ıtˇe. Pokud to bylo moˇzné, provedli jsme simulaci vybran´ ych vlastnost´ı v nástroj´ıch OMNeT++ a PT. V´ ysledky jsme si pˇredvedli na v´ ypisech simulátor˚ u. V pˇr´ıpadˇe simulace stability by se jednalo o mnoho dlouh´ ych v´ ypis˚ u, proto jsme v´ ysledky shrnuli v pˇrehledn´ ych tabulkách.

47

Kapitola 6

V´ ysledky simulac´ı v n´ astroj´ıch OMNeT++ a Packet Tracer V této kapitole porovn´ ame v´ ysledky simulac´ı v nástroj´ıch OMNeT++ a Packet Tracer. Zhodnot´ıme simulaˇcn´ı moˇznosti obou nástroj˚ u a nakonec se zamˇeˇr´ıme na pˇr´ınos simulace pro praktickou anal´ yzu poˇc´ıtaˇcov´ ych s´ıt´ı.

6.1 6.1.1

V´ ysledky simulac´ı V´ ysledky simulace dostupnosti

Pˇri simulaci dostupnosti jsme provedli dvˇe simulace. Nejprve jsme zjiˇst’ovali, co se stane, pokud spadne linka mezi R1 a R2. Dle pˇredpoklad˚ u byla vyuˇzita záloˇzn´ı cesta pˇres smˇerovaˇc R3. Uk´ azalo se, ˇze smˇerovaˇce nebyly schopné okamˇzitˇe pˇresunout provoz na záloˇzn´ı linku. V nejhorˇs´ım pˇr´ıpadˇe mus´ıme vyˇckat pˇribliˇznˇe 30 sekund, coˇz je implicitn´ı délka ˇcasovaˇce Update. To je pˇr´ıpad, kdy se aktualizaˇcn´ı zprávy pos´ılaly tˇesnˇe pˇred pádem linky. Obvykle je ale tento ˇcas niˇzˇs´ı. Dok´ azali jsme t´ım, ˇze protokol RIP konverguje pomalu. Pˇri druhé simulaci jsme vyuˇzili ACL na rozhran´ı eth2 smˇerovaˇce R2, které blokovalo vˇsechny ICMP pakety smˇeˇruj´ıc´ı do s´ıtˇe 192.168.17.0/24. Po pádu linky pˇresmˇerovali smˇerovaˇce znovu provoz na smˇerovaˇc R3. Ten odeslal ICMP pakety na smˇerovaˇc R2 stejnˇe jako v pˇredchoz´ı simulaci. ACL na smˇerovaˇci R2 ale tyto pakety zahazoval. S´ıt’ 192.168.17.0 /24 se stala nedostupnou. Touto simulaci jsme chtˇeli uk´ azat, ˇze i kdyˇz máme pro provoz mezi s´ıtˇemi LAN záloˇzn´ı linku a pˇredpokl´ ad´ ame, ˇze bude vyuˇzita v pˇr´ıpadˇe poruchy hlavn´ı linky, nemus´ı to b´ yt vˇzdy pravda. M˚ uˇze se st´ at, ˇze vlivem dalˇs´ıch parametr˚ u, které jsme si neuvˇedomili (jako je nastavené ACL), se mohou stát s´ıtˇe nedostupné. Z tohoto d˚ uvodu je vhodné provést ’ podobnou simulaci pro vlastn´ı s´ıt . V´ ysledky simulace dostupnosti v nástroj´ıch OMNeT++ a Packet Tracer byly shodné.

6.1.2

V´ ysledky simulace stability

Pˇri simulace stability s´ıtˇe jsme se zamˇeˇrili na zkoumán´ı mnoˇzstv´ı ICMP paket˚ u, které byly v poˇrádku doruˇceny zpˇet poˇc´ıtaˇci H11. Namˇeˇrené hodnoty z tabulky 5.1 jsou znázornˇeny v grafu 6.1. S´ıt’ divergovala. Se zvyˇsuj´ıc´ı stabilitou linky se zvyˇsoval poˇcet doruˇcen´ ych paket˚ u ’ aˇz dosáhl poˇctu vˇsech odeslan´ ych paket˚ u. Porovnán´ım tabulek 5.1 a 5.3 zjist´ıme, ˇze s´ıt se chovala obdobnˇe, at’ uˇz byla linka nestabiln´ı od poˇcátku, nebo aˇz po naplnˇen´ı smˇerovac´ıch 48

tabulek. Pˇri nestabilitˇe linky se z´ atˇeˇz bˇeˇzné a záloˇzn´ı linky rozdˇelila pˇribliˇznˇe na polovinu. Pr˚ umˇerné hodnoty z tabulky 5.2 m˚ uˇzeme vidˇet v grafu 6.2. Z tohoto grafu je zˇrejmé, ˇze pˇri ∆t menˇs´ım neˇz 25 sekund se poˇcet doruˇcen´ ych paket˚ u rapidnˇe sniˇzoval. Smˇerovaˇce si totiˇz nemohli korektnˇe zas´ılat aktualizace, které se zas´ılaj´ı jednou za 30 sekund.

Obr´ azek 6.1: Graf z´ avislosti poˇctu pˇrijat´ ych paket˚ u na ∆t dle tabulky 5.1.

Nastaven´ı ˇcasovaˇce Trigger m´ a také vliv na poˇcet doruˇcen´ ych paket˚ u zm´ınˇen´ y v pˇredchoz´ı kapitole, viz tabulka 5.2. Tento ˇcasovaˇc se ale podle RFC 1058 [5] nedá nastavit napevno, n´ ybrˇz se nastavuje n´ ahodnˇe. Proto, pokud se data nebudou pos´ılat pravidelnˇe jako v naˇs´ı simulaci, je poˇcet pˇrenesen´ ych paket˚ u za ˇcas v´ıceménˇe vˇec´ı náhody. Dále jsme doˇsli k zaj´ımavému zjiˇstˇen´ı, ˇze se zvyˇsuj´ıc´ı se nestabilitou (zmenˇsuj´ıc´ım se ˇcasem mezi zmˇenami stavu linky) s´ıtˇe se sniˇzuje ˇcas, ve kterém smˇerovaˇc R1A z´ıská cestu do s´ıtˇe 192.168.17.0/24 (tabulka 5.4). Nast´ın´ıme si situaci u stabiln´ı s´ıtˇe. V ˇcase 0 sekund rozeˇslou smˇerovaˇce soused˚ um informace o pˇr´ımo pˇripojen´ ych s´ıt´ıch. Pˇri dalˇs´ım zas´ılán´ı aktualizac´ı v ˇcase 30 sekund uˇz zas´ılaj´ı smˇerovaˇce nejen své pˇr´ımo pˇripojené s´ıtˇe, ale i cesty od sv´ ych soused˚ u, proto se v tomto ˇcase dozv´ı smˇerovaˇce R1 o s´ıti 192.168.17.0/24. Smˇerovaˇci R1A tuto informaci pˇred´ a aˇz pˇri dalˇs´ı aktualizaci v ˇcase 60 sekund. ˇ Casovaˇc Update nen´ı nastaven pˇresnˇe na 30 sekund, ale k tomuto ˇcasu se pˇrid´ av´ a krátká prodleva (je souˇc´ ast´ı implementace) v rozmez´ı nula aˇz jedna sekunda, aby vˇsechny smˇerovaˇce nezas´ılaly aktualizace ve stejn´ y ˇcas. T´ım pádem nen´ı pˇredem jasné, kter´ y smˇerovaˇc dˇr´ıve zaˇsle informaci sousedovi. Pokud by v simulaˇcn´ım ˇcase 30 sekund nejprve z´ıskal smˇerovaˇc R1 informaci o cestˇe do s´ıtˇe 192.168.17.0/24 a aˇz následnˇe zaslal smˇerovac´ı informace smˇerovaˇci R1A, mohly by smˇerovaˇc R1A znát cesty do vˇsech s´ıt´ı jiˇz v tomto ˇcase. Takov´ yto stav by mohl ale nastat aˇz pozdˇeji pˇri simulaci, kdy se rozestupy mezi zas´ılán´ım aktualizac´ı jednotliv´ ymi smˇerovaˇci zvˇetˇs´ı. Na poˇcátku simulace odeˇsle smˇerovaˇc R1 smˇerovaˇci R1A aktualizace dˇr´ıve, neˇz zpracuje pˇr´ıchoz´ı informace. Podobnˇe jako v pˇr´ıpadˇe stabiln´ı s´ıtˇe se s´ıt’ chová i tehdy, je-li ∆t vˇetˇs´ı neˇz 30 sekund. Je-li ale tento ˇcas niˇzˇs´ı, situace se mˇen´ı. Vezmˇeme si jako pˇr´ıklad ∆t = 20 sekund. V ˇcase nula se smˇerovaˇc R3 dozv´ı pˇr´ımé s´ıtˇe od smˇerovaˇc˚ u R2 a R1, s´ıt’ 192.168.17.0/24 nezn´ a. V ˇcase 20 sekund dojde k v´ ypadku linky mezi R1 a R2. Oba smˇerovaˇce zaˇcnou zas´ılat sv´ ym 49

Obrázek 6.2: Graf z´ avislosti pr˚ umˇerného poˇctu pˇrijat´ ych paket˚ u na ∆t dle tabulky 5.2.

soused˚ um své aktualizace. Smˇerovaˇc R3 se tak dozv´ı od R2 o s´ıti 192.168.17.0/24. V ˇcase 30 sekund dojde k zas´ıl´ an´ı pravideln´ ych aktualizac´ı vˇsem sv´ ym soused˚ um a tak se smˇerovaˇc R1, následnˇe i R1A, dozv´ı od smˇerovaˇce R3 o existenci s´ıtˇe 192.168.17.0/24. Jeˇstˇe zaj´ımavˇejˇs´ı situace nast´ avá pˇri intervalu ∆t = 5 sekund. V ˇcase nula se smˇerovaˇce dozv´ı pˇr´ımé s´ıtˇe sv´ ych soused˚ u. Smˇerovaˇc R2 se dozv´ı o s´ıti 192.168.17.0/24. V ˇcase 5 sekund dojde k p´ adu linky. V ˇcase 10 sekund dojde k zprovoznˇen´ı linky. Pˇri této zmˇenˇe smˇerovaˇce zaˇcnou zas´ılat celé své tabulky vˇsem sv´ ym soused˚ um, R2 vˇsak nestihne zaslat informaci smˇerovaˇci R1 z d˚ uvodu delˇs´ıho intervalu ˇcasovaˇce Trigger. V ˇcase 20 sekund, kdy dojde znovu k obnovˇe linky, jiˇz R2 zaˇsle smˇerovaˇci R1 informaci o s´ıti 192.168.17.0/24. R1 zaˇsle zpr´ avu o této cestˇe ihned smˇerovaˇci R1A.

6.2

Porovn´ an´ı n´ astroj˚ u OMNeT++ a Packet Tracer

Pro simulace jsme pouˇzili n´ astroje OMNeT++ i PT. Simulován´ım jsme ovˇeˇrili, ˇze oba nástroje neposkytuj´ı stejné simulaˇcn´ı moˇznosti. V praxi se ukázalo, ˇze Packet Tracer je vhodnˇejˇs´ı jako n´ astroj pro modelován´ı s´ıt´ı neˇz pro jejich simulaci. Za to nástroj OMNeT++ prokázal, ˇze je ryz´ım simulaˇcn´ım nástrojem. Simulace v OMNeT++ byla jednoduchá hlavnˇe d´ıky manaˇzeru stav˚ u linek [4]. Do XML souboru jsme popsali, jak chceme aby simulace prob´ıhala. D´ıky manaˇzeru bylo moˇzné provést simulaci p´ adu linek v jakémkoliv simulaˇcn´ım ˇcase, s jakoukoliv frekvenc´ı a hlavnˇe v jakémkoliv mnoˇzstv´ı. Pˇri simulaci stability s´ıtˇe jsme mohli simulovat vˇsechny stupnˇe nestability (vˇsechny ∆t) pˇri jedné simulaci. Pro vˇetˇs´ı pˇrehlednost jsme ale této moˇznosti nevyuˇzili. Abychom z´ıskali vhodn´ y v´ ystup, ukazuj´ıc´ı jakou cestou byl paket smˇerován, bylo tˇreba dopsat p´ ar ˇr´ adk˚ u k´ odu do jednoduch´ ych modul˚ u pˇredstavuj´ıc´ıch s´ıt’ovou vrstvu (Network Layer). Informace o pr˚ ubˇehu simulace se pak vypisovaly do konzolového okna, ze kterého se daly jednoduˇse pˇrekop´ırovat a uchovat pro dalˇs´ı pouˇzit´ı. Pˇri simulaci v PT se informace o pr˚ ubˇehu simulace vypisuj´ı do okna Even List (obrázek 1.6) a nen´ı moˇzné je nijak exportovat, coˇz je velmi nepraktické. Proto jsme museli vyuˇz´ıt 50

sn´ımán´ı obrazovky (Print Screen) a do této práce vloˇzit v´ ysledky jako obrázek. Hlavn´ı nev´ yhoda PT ale tkv´ı v tom, ˇze nen´ı moˇzné nijak naplánovat simulaci. Narozd´ıl od OMNeT++ nen´ı ani moˇzné doprogramovat modul, kter´ y by simulaci ovládal. V pˇr´ıpadˇe, ˇze chceme simulovat p´ ady a obnoven´ı linky, je nutné vˇzdy simulaci zastavit a ruˇcnˇe zapsat pˇr´ıkaz pro zapnut´ı/vypnut´ı rozhran´ı pro kaˇzd´ y smˇerovaˇc a rozhran´ı zvláˇst’. Simulov´ an´ı nestability linky je proto v tomto nástroji nemoˇzné.

Obr´ azek 6.3: Model s´ıtˇe, kterou vyuˇz´ıváme v simulac´ıch. Pˇrepokl´ adejme, ˇze bychom chtˇeli simulovat dostupnost z jedno PC na vˇsechna dalˇs´ı PC v s´ıti. V naˇs´ı s´ıti (obr´ azek 6.3) máme ˇsest PC (n = 6), kaˇzdé PC by zas´ılalo pakety dalˇs´ım pˇeti PC. To znamen´ a, ˇze bychom museli provést 5 x 6 simulaci. Pro obecn´ y poˇcet PC je to (n − 1)n = n2 − n,

(6.1)

coˇz vede na kvadratickou sloˇzitost O(N 2 ). Dále bychom zkoumali, jak se bude s´ıt’ chovat v pˇr´ıpadˇe p´ adu jakékoliv jedné linky po cestˇe mezi dvˇema PC. V naˇs´ı topologii to znamen´ a sedm linek ke kaˇzdému ze ˇctyˇr poˇc´ıtaˇc˚ u v jiné s´ıti LAN a dvˇe linky k poˇc´ıtaˇci ve stejné s´ıti LAN. To je v pr˚ umˇeru ˇsest linek. Tuto hodnotu oznaˇc´ıme jako r. V naˇsem pˇr´ıpadˇe r = 6, tedy r = n. Hodnotou r mus´ıme vynásobit poˇcet simulac´ı dostupnosti mezi dvˇema PC: (n2 − n)r

(6.2)

Sloˇzitost simulace m˚ uˇzeme vypoˇc´ıtat následovnˇe: (n2 − n)n = n3 − n2

(6.3) O(N 3 ).

Simulace dostupnosti vˇsech s´ıt´ı v PT vede na kubickou sloˇzitost Pouˇzijemeli vzorec 6.2 m˚ uˇzeme vypoˇc´ıtat, ˇze pro naˇs´ı topologii bychom museli provést celkem 180 simulac´ı. V pˇr´ıpadˇe, ˇze bychom se rozhodli simulovat nefunkˇcnost vˇsech moˇzn´ ych variac´ı linek po cestˇe (kromˇe situace, kdy by byly nefunkˇcn´ı vˇsechny linky na trase), mus´ıme provést 2n − 1

(6.4)

simulac´ı pro jednu dvojici poˇc´ıtaˇc˚ u. V pˇr´ıpadˇe, ˇze bychom simulovali také dostupnost mezi vˇsemi poˇc´ıtaˇci v s´ıti, bylo by tˇreba provést 51

(n2 − n)(2n − 1)

(6.5)

simulac´ı. T´ım p´ adem se dost´ aváme k exponenciáln´ı sloˇzitosti O(2N ). Pro naˇs´ı topologii bychom museli provést 1890 simulac´ı. Z tohoto d˚ uvodu m˚ uˇzeme prohlásit PT za nevhodn´ y nástroj pro praktickou simulaci poˇc´ıtaˇcov´ ych s´ıt´ı. V nástroji OMNeT++ je pouze nutné zopakovat simulaci pro kaˇzdou dvojici poˇc´ıtaˇc˚ u, tedy provést 30 simulac´ı (podle vzorce 6.1).

6.3

Pˇ r´ınos simulace pro praktickou anal´ yzu poˇ c´ıtaˇ cov´ ych s´ıt´ı

Jak jsme si v pˇredchoz´ı sekci dok´ azali, nástroj PT nelze pro praktickou anal´ yzu poˇc´ıtaˇcov´ ych s´ıt´ı pouˇz´ıt. N´ astroj OMNeT++ má v tomto smˇeru mnohem lepˇs´ı vyhl´ıdky. Implementac´ı protokolu RIP a redistribuce jsme v´ yraznˇe rozˇs´ıˇrili moˇznosti tohoto n´ astroje. Spoleˇcnˇe s OSPF [4], EIGRP [16], ACL [15], manaˇzeru linek [4] a Cisco smˇerovaˇce [14] se z obecného diskrétn´ıho simulátoru stal plnohodnotn´ y simulátor poˇc´ıtaˇcov´ ych s´ıt´ı. D´ıky konfiguraˇcn´ımu souboru [13] podobnému CLI je simulátor pˇripraven na modelov´ an´ı a simulaci s´ıt´ı sloˇzen´ ych z Cisco smˇerovaˇc˚ u. Rozhodneme-li se otestovat r˚ uzné vlastnosti s´ıtˇe, je vyuˇzit´ı simulátoru OMNeT++ se vˇsemi v´ yˇse jmenovan´ ymi doplˇ nkov´ ymi modely rozhodnˇe dobr´ ym ˇreˇsen´ım. Nen´ı nutné naruˇsovat chod velké s´ıtˇe testovac´ımi ACL ˇci pády linek. Nˇekteré vlastnosti se na reálné s´ıti testuj´ı jen velmi tˇeˇzce. Rozhodneme-li se testovat stabilitu s´ıtˇe, neexistuje jednoduch´ y zp˚ usob, kter´ ym bychom nasimulovali nestabilitu na reálné s´ıti. Pˇri pouˇzit´ı simulátoru se nem˚ uˇze nic pokazit ani zniˇcit, m˚ uˇzeme tedy simulátor povaˇzovat za nejlevnˇejˇs´ı variantu pro testován´ı s´ıtˇe. Vˇetˇsina simul´ ator˚ u uveden´ ych v sekci 1.1 se pouˇz´ıvá k simulován´ı r˚ uzn´ ych vˇeci, nejen s´ıt´ı, proto m´ a vˇetˇsina tˇechto simulátor˚ u omezené nebo ˇzádné moˇznosti smˇerován´ı. Naopak OMNeT++ je pˇripraven na simulaci bˇeˇzn´ ych Cisco s´ıt´ı. Protokol RIP byl naimplementován podle pˇr´ısluˇsného RFC a tak je plnˇe kompatibiln´ı s implementaci nejen v bˇeˇzn´ ych smˇerovaˇc´ıch. S´ıtˇe v OMNeT++ se chovaj´ı podobnˇe jako s´ıtˇe reálné.

6.4

Shrnut´ı kapitoly

V této kapitole jsme si shrnuli a od˚ uvodnili v´ ysledky, ke kter´ ym jsme doˇsli pˇri simulaci v pˇredeˇslé kapitole. V pˇr´ıpadˇe dostupnosti jsme ukázali, ˇze pouˇzit´ım simulace je moˇzné odhalit nˇekteré parametry, které mohou ovlivnit dostupnost s´ıtˇe. Prokázali jsme, ˇze dostupnost s´ıtˇe také z´ avis´ı na stabilitˇe linek. Pˇrestoˇze pˇri v´ ypadku linky se nab´ızelo pouˇz´ıt´ı záloˇzn´ı linky, protokol RIP ji nedok´ azal vyuˇz´ıt. Tento protokol totiˇz konverguje pˇr´ıliˇs pomalu, a tak po v´ ypadu linky nedok´ azal ihned pˇresmˇerovat data na záloˇzn´ı linku. T´ımto jsme dokázali, ˇze záloˇzn´ı linka nen´ı vˇzdy z´ arukou dostupnosti s´ıt´ı a protokol RIP nen´ı vhodn´ ym smˇerovac´ım protokolem pro nestabiln´ı s´ıtˇe. Dokázali jsme také, ˇze se sniˇzuj´ıc´ım se ˇcasem mezi zmˇenami stavu linek se zkracuje ˇcas z´ısk´ an´ı smˇerovac´ıch informac´ı o vˇsech s´ıt´ıch. Porovnali jsme n´ astroje PT a OMNeT++ z hlediska moˇznost´ı pˇri simulac´ıch s´ıt´ı. Ukázalo se, ˇze pouˇzit´ı n´ astroje PT pro hlubˇs´ı simulace námi namodelovan´ ych topologi´ı, je prakticky nemoˇzné. Simulovat v nˇem nestabiln´ı linky je neproveditelné. Pˇri simulaci dostupnosti v PT se m˚ uˇzeme pˇri prov´ adˇen´ı simulac´ı pro jednotlivé situace dostat ke kubické nebo aˇz exponenciáln´ı sloˇzitosti. Na z´ avˇer jsme zhodnotili moˇznosti nástroje OMNeT++ pro praktickou anal´ yzu poˇc´ıtaˇcov´ ych s´ıt´ı. Uk´ azalo se, ˇze implementac´ı protokolu RIP, jsme v´ yraznˇe obohatili n´ astroj v oblasti simulace smˇerován´ı s´ıt´ı. 52

Z´ avˇ er V rámci této pr´ ace jsme detailnˇe prostudovali smˇerovac´ı protokoly RIP a OSPF, nalezli návrhové vzory firmy Cisco, které pracuj´ı s tˇemito protokoly, seznámili se s nástroji PT a OMNeT++ a jejich moˇznostmi na poli modelován´ı a simulace. C´ılem této pr´ ace bylo vytvoˇrit simulaˇcn´ı modely v praxi pouˇziteln´ ych s´ıt´ı v tˇechto nástroj´ıch a simulován´ım model˚ u pˇredvést moˇznosti n´ astroj˚ u pro praktickou anal´ yzu poˇc´ıtaˇcov´ ych s´ıt´ı.

Vlastn´ı pˇ r´ınos Nejprve jsem se sezn´ amila s modelovac´ımi a simulaˇcn´ımi moˇznostmi nástroj˚ u PT, OMNeT++ a framework INET proˇcten´ım dostupn´ ych manuálu a vyzkouˇsen´ım ˇrady simulac´ı. Ukázalo se, ˇze pro modelov´ an´ı s´ıt´ı vyuˇz´ıvaj´ıc´ıch Cisco zaˇr´ızen´ı je vhodnˇejˇs´ı PT od téˇze firmy. Modelov´ an´ı v OMNeT++ je nároˇcnˇejˇs´ı d´ıky nutnosti nauˇcit se programovac´ı jazyk NED a C++ a pˇredevˇs´ım d´ıky nedostateˇcn´ ym informac´ım k framework INET. Na z´ akladˇe n´ avrhov´ ych vzor˚ u pro smˇerován´ı firmy Cisco jsem vytvoˇrila simulaˇcn´ı modely v n´ astroji PT. Abych mohla vytvoˇrit stejné modely i pro nástroj OMNeT++, bylo nejdˇr´ıve nutné naimplementovat moduly, které se nenacházely v knihovnˇe OMNeT++ ani v framework INET. Jednalo se protokol RIP a redistribuci mezi protokolem OSPF a protokolem RIP. Po peˇclivém nastudov´ an´ı RFC 1058 jsem naimplementovala v jazyce C++ chov´ an´ı modulu RIPRouting, kter´ y zajiˇst’uje smˇerován´ı na základˇe protokolu RIP. Podobnˇe jsem doimplementovala i redistribuci z protokolu OSPF do protokolu RIP. Pro modul jsem také vytvoˇrila popis v jazyce NED. Poté, co jsem chybˇej´ıc´ı vlastnosti naimplementovala, vytvoˇrila jsem v jazyce NED simulaˇcn´ı modely také pro nástroj OMNeT++ a provedla jsem nastaven´ı vˇsech smˇerovaˇc˚ u v XML konfiguraˇcn´ıch souborech. Kdyˇz jsem mˇela pˇripraveny vˇsechny simulaˇcn´ı modely, definovala jsem si vlastnosti, které budu simulovat. Nˇekteré tˇr´ıdy z framework INET jsem doplnila o kód, kter´ y umoˇzn ˇuje vypisovat trasy ICMP paketu. Vybrala jsem si simulaˇcn´ı model vyuˇz´ıvaj´ıc´ı smˇerovac´ı protokol RIP a provedla jsem simulace dostupnosti a stability v obou simulaˇcn´ıch nástroj´ıch. Pro simulace v OMNeT++ jsou vytvoˇrila ˇradu simulaˇcn´ıch scénáˇr˚ u v jazyce XML. V´ ysledky simulac´ı jsou zaznamen´ any v pˇr´ısluˇsné kapitole. Zhodnotila jsem v´ ysledky simulac´ı. Ukázala jsem, ˇze pˇri zkoumán´ı dostupnosti se mohou naskytnout jevy, se kter´ ymi jsme na poˇcátku nepoˇc´ıtali (ACL). Dále jsem ukázala, ˇze nestabilita linky m´ a negativn´ı vliv na dostupnost linky a pozitivn´ı vliv na rychlost z´ıskán´ı poˇc´ ateˇcn´ıch smˇerovac´ıch informac´ı. Pˇri tˇechto simulac´ıch se nástroj PT ukázal jako nevhodn´ y simulaˇcn´ı n´ astroj. Simulaci je totiˇz tˇreba pro kaˇzd´ y pád linky opakovat, tento postup dosahoval aˇz exponenci´ aln´ı sloˇzitosti. Naopak OMNeT++ obohacen´ y o mou implementaci dokáˇze plnohodnotnˇe simulovat s´ıtˇe vyuˇz´ıvaj´ıc´ı smˇerovac´ı protokoly RIP a OSPF. M˚ uˇze tak pomoci pˇri praktické anal´ yze 53

s´ıt´ı a v pˇr´ıpadˇe nestabiln´ıch linek se m˚ uˇze stát jednou z mála moˇznost´ı, jak s´ıt’ otestovat.

Dalˇ s´ı v´ yvoj Tato pr´ ace vznikla v r´ amci projektu ANSA [26], kter´ y se zamˇeˇruje na automatizované metody verifikace s´ıt´ı zaloˇzené na konfiguraci s´ıt’ov´ ych zaˇr´ızen´ı a s´ıt’ové topologie. Tato práce se m˚ uˇze v tomto smˇeru d´ ale rozv´ıjet a projektu nab´ıdnout dalˇs´ı funkce a moduly pro automatizovanou simulac´ı s´ıtˇe. V pˇr´ıpadˇe protokolu RIP by bylo moˇzné implementaci rozˇs´ıˇrit o autosumarizaci, kter´ a pro uv´ adˇené simulace nebyla potˇreba, a také o Poison Reverse, kter´ y by se mohl volitelnˇe pouˇz´ıt m´ısto implementovaného Split Horizon. V rámci této práce byl naimplementov´ an pouze protokol RIP verze jedna, dále by se implementace mohla rozˇs´ıˇrit o verzi dvˇe. Pro simulaci jako takovou by bylo vhodné napsat tˇr´ıdu, která by dokázala vypisovat informace, o tom, co se v s´ıti komu zas´ılá. Bylo by to vhodnˇejˇs´ı, neˇz zásah do existuj´ıc´ıch tˇr´ıd z framework INET, kter´ y jsem kv˚ uli simulaˇcn´ım v´ ypis˚ um provedla já.

54

Literatura [1] Internetwork Design Guide: RIP and OSPF Redistribution [online]. [cit. 2009-02-13]. URL http://www.cisco.com/en/US/docs/internetworking/design/guide/nd2014.pdf [2] CCNA Exploration 4.0: Routing Protocols and Concepts [online]. 2007, Pˇr´ıstupn´ y pro studenty a vyuˇcuj´ıc´ı kurzu CCNA2 po pˇrihláˇsen´ı na. URL http://www.cisco.com/web/learning/netacad/index.html [3] Packet Tracer 5.0 Help. 2008, souˇcást instalace programu Packet Tracer 5.0. [4] Danko, M.: Modelov´ an´ı smˇerovac´ıch protokol˚ u OSPF v simul´ atoru OMNeT++. Bakal´ aˇrsk´ a pr´ ace, FIT VUT v Brnˇe, 2009. [5] Hedrick, C.: RFC 1058: Routing Information Protocol. 1988. URL http://tools.ietf.org/html/rfc1058 [6] Hedrick, C.: An Introduction to IGRP. 1991. URL http://www.cisco.com/en/US/tech/tk365/technologies_white_ paper09186a00800c8ae1.shtml [7] Lomnick´ y, M.; Vesel´ y, V.: Smˇerován´ı a smˇerovac´ı protokoly [online]. 2007, [cit. 2008-11-20]. URL http://netacad.fit.vutbr.cz/texty/ccna-moduly/ccna2-6.pdf [8] Malkin, G.: RFC 2453: RIP Version 2. 1998. URL http://tools.ietf.org/html/rfc2453 [9] Moy, J.: RFC 2328: OSPF Version 2. 1998. URL http://tools.ietf.org/html/rfc2328 [10] Oran, D.: RFC 1142: OSI IS-IS Intra-domain Routing Protocol. 1990. URL http://tools.ietf.org/html/rfc1142 [11] Peringer, P.: Modelov´ an´ı a simulace IMS, studijn´ı opora. 2006. [12] Ryˇsav´ y, O.: Network Modeling and Simulation [online]. 2008, [cit. 2008-11-20]. URL https://wis.fit.vutbr.cz/FIT/st/course-files-st.php/course/ISA-IT/ lectures/isa11-simulace.pdf [13] Scherfel, P.: Simulace chov´ an´ı s´ıtˇe na z´ akladˇe analýzy konfiguraˇcn´ıch soubor˚ u aktivn´ıch s´ıt’ových zaˇr´ızen´ı. Bakaláˇrská práce, FIT VUT v Brnˇe, 2009.

55

[14] Siv´ ak, V.: Model Cisco smˇerovaˇce v simulaˇcn´ım n´ astroji OMNeT++. Bakaláˇrská pr´ ace, FIT VUT v Brnˇe, 2009. [15] Suchomel, T.: Rozˇs´ıˇren´ı simul´ atoru OMNeT++ o filtrovac´ı pravidla ACL. Bakaláˇrsk´ a pr´ ace, FIT VUT v Brnˇe, 2009. [16] Tlolka, M.: Simulace EIGRP protokolu v prostˇred´ı OMNeT++. Bakaláˇrská práce, FIT VUT v Brnˇe, 2009. [17] Varga, A.: OMNeT++ Descrete Event Simulation System. User manual version 4.0. 2008. [18] WWW str´ anky: About GloMoSim. [cit. 2009-04-25]. URL http://pcl.cs.ucla.edu/projects/glomosim/ [19] WWW str´ anky: The CNET network simulator. [cit. 2009-04-25]. URL http://www.csse.uwa.edu.au/cnet/ [20] WWW str´ anky: Erlang Traffic and Queuing Software. [cit. 2009-04-25]. URL http://members.iinet.net.au/~clark/ [21] WWW str´ anky: GTNetS. [cit. 2009-04-25]. URL http://www.ece.gatech.edu/research/labs/MANIACS/GTNetS/ [22] WWW str´ anky: JiST - Java in Simulation Time / SWANS. [cit. 2009-04-25]. URL http://jist.ece.cornell.edu/ [23] WWW str´ anky: OMNeT++ Community Site. [cit. 2009-04-25]. URL http://www.omnetpp.org/ [24] WWW str´ anky: Packet Tracer. [cit. 2009-04-25]. URL http: //www.cisco.com/web/learning/netacad/course_catalog/PacketTracer.html [25] WWW str´ anky: Performance Prophet - A Performance Modeling and Prediction System for Cluster and Grid Computing. [cit. 2009-04-25]. URL http://www.dps.uibk.ac.at/projects/prophet/ [26] WWW str´ anky: Project ANSA, Brno University of Technology. [cit. 2009-05-10]. URL https://nes.fit.vutbr.cz/ansa/pmwiki.php [27] WWW str´ anky: Scalable Network Technologies: Creators of QualNet Simulator. [cit. 2009-04-25]. URL http://www.scalable-networks.com/ [28] WWW str´ anky: Tetcos software - NetSim. [cit. 2009-04-25]. URL http://www.tetcos.com/software.html [29] WWW str´ anky: UCLA Parsec Programming Language. [cit. 2009-04-25]. URL http://pcl.cs.ucla.edu/projects/parsec/

56

Pˇ r´ıloha A

Obsah DVD V následuj´ıc´ı tabulce A.1 je uveden obsah pˇriloˇzeného DVD. doc\

Programov´ a dokumentace v formátu HTML vygenerovaná programem Doxygen.

INET\

Rozbalen´ a a pˇreloˇzená knihovna INET i s upraven´ ymi soubory, doimplementovan´ ymi knihovny a vlastn´ımi pˇr´ıklady simulac´ı. V tomto stavu se vyuˇz´ıvala pro tuto práci.

instalation\

Instalaˇcn´ı soubory pro PT, OMNeT++ a INET.

models omnet\

Simulaˇcn´ı modely pro OMNeT++. Jsou také vloˇzeny ve struktuˇre sloˇzky INET.

models PT\

Simulaˇcn´ı modely pro PT.

rip\

Tˇr´ıdy implementuj´ıc´ı protokol RIP a redistribuci. Jsou také vloˇzeny ve struktuˇre sloˇzky INET.

tex\

Zdrojové soubory této práce psané v LATEX.

doc.chm

Programov´ a dokumentace v formátu CHM vygenerovaná programem Doxygen.

projekt.pdf

Elektronick´ a verze této práce v formátu PDF.

readme.txt

Obsah DVD. Tabulka A.1: Obsah pˇriloˇzeného DVD.

57

Pˇ r´ıloha B

Instalaˇ cn´ı pˇ r´ıruˇ cka Tato instalaˇcn´ı pˇr´ıruˇcka by v´ am mˇela pomoci s instalac´ı simulaˇcn´ıch nástroj˚ u, které se vyuˇz´ıvali v r´ amci této pr´ ace. Vˇsechny simulace byly provádˇeny pod operaˇcn´ım systémem Windows XP, proto jsou zde uvedeny jen instalaˇcn´ı postupy pouˇz´ıvané pod t´ımto operaˇcn´ım systémem.

B.1

Instalace programu PacketTracer 5.0

Packet Tracer je simulaˇcn´ı n´ astroj od firmy Cisco volnˇe dostupn´ y pro studenty a instruktory Cisco Networking Academy. Ti si mohou po pˇrihláˇsen´ı na stránkách firmy Cisco stáhnout instalátor nejnovˇejˇs´ı verze Packet Tracer 5.0 [24] (dále jen PT). Na v´ ybˇer je instalátor obsahuj´ıc´ı pouze samotn´ y program, verze s mnoha demo pˇr´ıklady, která je vhodná pˇredevˇs´ım pro zaˇc´ınaj´ıc´ı uˇzivatele, ˇci verze obsahuj´ıc´ı instalátor spoleˇcnˇe s tutoriály. Je zde dostupn´ ych i nˇekolik dokument˚ u ve form´ atu .pdf, které ale maj´ı pouze obecn´ y seznamovac´ı charakter a uˇzivatel se s v nich nedozv´ı ˇzádnou podstatnou informaci, která by mu zjednoduˇsila uˇz´ıván´ı programu. Nejnovˇejˇs´ı verze PT je distribuována jak pro operaˇcn´ı systém Windows, tak pro Linux. Verze pro Linux jsou ke staˇzen´ı tˇri – konkrétnˇe pro Ubuntu 7.10, Fedoru 7 a pro Linux s jádrem verze 2.6 a vyˇsˇs´ı. Postup instalace: 1. Spust´ıme soubor PacketTracer5_setup.exe. 2. Pˇreˇcteme si licenˇcn´ı ujedn´ an´ı (EULA) a odsouhlas´ıme jej. 3. Vybereme c´ıl instalace. Implicitnˇe je nastaveno na sloˇzku C:\Program Files\ Packet Tracer 5.0. 4. N´ aslednˇe jsme dot´ az´ an´ı, jestli si pˇrejeme vytvoˇrit sloˇzku v Start menu. 5. Nakonec se n´ as program zeptá, jestli si pˇrejeme vytvoˇrit ikonu na ploˇse (desktop icon) nebo ikonu v panelu snadného spuˇstˇen´ı (quick lunch icon). 6. N´ asleduje samotn´ a instalace.

58

B.2

Instalace n´ astroje OMNeT++

Instalaˇcn´ı soubor pro Windows nebo bal´ık pro systémy UNIX lze stáhnout, ze stránek OMNeT++ [23]. Pro Windows stáhnˇete archiv omnetpp-4.0-src-windows.zip (161 MB) a rozbalte ho. Instalace obsahuje kromˇe knihovny OMNeT++ také IDE a MinGW, kter´ y umoˇzn´ı instalaci pod OS Windows. Postup instalace: 1. Spust´ıme instalaˇcn´ı prostˇred´ı s bash shell mingwenv.cmd. 2. Provedeme kontrolu nastaven´ı pomoc´ı configure. 3. Pˇr´ıkazem make provedeme pˇreklad. 4. Zkontrolujeme funkˇcnost spuˇstˇen´ım vzorov´ ych ukázek. Pˇrejdeme do sloˇzky s pˇr´ıklady pomoc´ı cd samples/dyna a spust´ıme je pˇr´ıkazem ./dyna. 5. IDE m˚ uˇzeme spustit z pˇr´ıkazové ˇrádky pˇr´ıkazem omnetpp.

B.3

Instalace framework INET

Nejnovˇejˇs´ı verze framework INET má název INETMANE 20080920. Pro jeho správnou funkˇcnost je nutné m´ıt nainstalovan´ y OMNeT++ 4.0. Ze stránek OMNeT++ stáhnˇete soubor INETMANET-20080920.tbz2 a rozbalte jej. Import do IDE: 1. Otevˇreme IDE. 2. V menu vyberte poloˇzku File -> Import... 3. V oknˇe se naléz´ a stromov´ a struktura. V n´ı vyberte General -> Existing Projects into Workspace a stisknˇete tlaˇc´ıtko Next. 4. V n´ asleduj´ıc´ım oknˇe ponechte zatrˇzenou moˇznost Select Root Directory a pomoc´ı volby Browse... naleznˇete sloˇzku, do které jste rozbalili INET. Zatrhnˇete INET project a stisknˇete tlaˇc´ıtko Finish. 5. INET je nyn´ı souˇc´ asti nového projektu.

59

Pˇ r´ıloha C

Implementace RIPRouting V této pˇr´ıloze uv´ ad´ıme kompletn´ı hlaviˇckov´ y soubor k tˇr´ıdˇe RIPRouting (bez vloˇzen´ ych knihoven). // Struktura pˇ redstavuje intern´ ı tabulku rozhran´ ı. struct RIPinterface { int intID; // Identifik´ ator rozhran´ ı. IPvXAddress addr; // IP adresa na rozhran´ ı. IPvXAddress mask; // Maska na rozhran´ ı. bool broadcast; // Umoˇ zˇ nuje broadcast? bool loopback; // Jde o loopback? bool passive; // M˚ uˇ zou se na rozhran´ ı zas´ ılat RIP zpr´ avy ? InterfaceEntry*entry; // Struktura popisuj´ ıc´ ı rozhran´ ı. }; // Struktura spojuje cestu ze smˇ erovac´ ı tabulky s ˇ casovaˇ cem protokolu RIP. struct RIPRouteTimer { IPRoute * route; // Cesta ze smˇ erovac´ ı tabulky. ˇ RIPTimer * timer; // Casovaˇ c pˇ riˇ razen´ y k cestˇ e. }; // Struktura zaznamen´ av´ a dvˇ e r˚ uzn´ e cesty do jedn´ e s´ ıtˇ e. struct RIPRouteTwins { IPRoute * route1; IPRoute * route2; }; // Struktura nese podstatn´ e informace o redistribuci. struct RIPRedistribution { char * protocol; // Redistribuovan´ y protokol (napˇ r. OSPF). int metric; // Metrika nov´ ych RIP cest. bool redistrinute; // Je zapnuta redistribuce? 60

}; class RIPRouting: public UDPAppBase, protected INotifiable { private: std::vectorrouteTimer; std::vector network; std::vector ripIft; std::vectorintDown; std::vector routeTwins; RIPTimer * triggerTimer; IRoutingTable *rt; IInterfaceTable *ift; NotificationBoard *nb; UDPControlInfo *udpCtrl; int localPort; int destPort; const char * hostname; RIPRedistribution redistr; // zpracovan´ ı RIP zpr´ av void processPacket(cMessage *msg); void processRequest(RIPPacket *msg); void processResponse(RIPPacket *msg); // odes´ ıl´ an´ ı a tvorba RIP zpr´ av void sendPacket(int command, IPAddress destAddr); RIPPacket* createPacket(int command, InterfaceEntry * entry); std::vector fillNetworks(InterfaceEntry * entry); // nacteni konfigurace, redistribuce, notifikace bool LoadConfigFromXML(const char * filename); std::vector getOSPFRoutes(); void receiveChangeNotification(int category, const cPolymorphic *details); // pomocn´ e metody void sendTrigger(); bool checkTwin(IPRoute * entryRT); RIPTimer * updateTimer(int type, RIPRouteTimer * entry); int getRouteRT (RIPTimer *timer); int getTimerRT (IPRoute *route); void insertIft(InterfaceEntry * entryIFT); protected: virtual virtual virtual public: virtual

int numInitStages() const {return 4;} void handleMessage(cMessage *msg); void initialize(int stage); ~RIPRouting();

}; 61

Pˇ r´ıloha D

Konfiguraˇ cn´ı soubory D.1

Konfiguraˇ cn´ı soubor pro OSPF model

Uveden´ y model je pouˇzit u simulaˇcn´ıho modelu, kter´ y vyuˇz´ıvá smˇerovac´ı protokol OSPF a rozdˇelen´ı s´ıtˇe do ˇctyˇr OSPF oblast´ı. Uvád´ıme jen konfiguraci pro smˇerovaˇc R1. 130.10.8.1 <Mask>255.255.255.0 point-to-point 1 10 40 5 1 Null 0x00 130.10.62.1 <Mask>255.255.255.248 point-to-point 1 10 40 5 1 Null 0x00 130.10.63.1 <Mask>255.255.255.248 point-to-point 62

1 10 40 5 1 Null 0x00 130.10.63.0 <Wildcard>0.0.0.255 130.10.62.0 <Wildcard>0.0.0.255 130.10.8.0 <Wildcard>0.0.0.255

D.2

Konfiguraˇ cn´ı soubor pro RIP model

Uveden´ y model je pouˇzit u simulaˇcn´ıho modelu, kter´ y vyuˇz´ıvá smˇerovac´ı protokol RIP. Uvád´ıme jen konfiguraci pro smˇerovaˇc R1. 130.10.8.1 63

<Mask>255.255.255.0 130.10.62.1 <Mask>255.255.255.0 130.10.63.1 <Mask>255.255.255.0 130.10.0.0

D.3

Konfiguraˇ cn´ı soubor pro redistribuˇ cn´ı model

Uveden´ y model je pouˇzit u simulaˇcn´ıho modelu, kter´ y vyuˇz´ıvá smˇerovac´ı protokoly RIP a OSPF a vz´ ajemnou redistribuci cest. Uvád´ıme jen konfiguraci pro smˇerovaˇc R1. 130.10.8.1 <Mask>255.255.255.0 130.10.62.1 <Mask>255.255.255.0 broadcast 1 1 10 40 5 1 Null 0x00 130.10.63.1 <Mask>255.255.255.0 broadcast 1 64

1 10 40 5 1 Null 0x00 130.10.62.0 <Wildcard>0.0.0.255 130.10.63.0 <Wildcard>0.0.0.255 130.10.0.0 <Passive-interface>eth1 <Passive-interface>eth2 ospf <Metric>4

65

FAKULTA INFORMAČNÍCH TECHNOLOGIÍ

Recommend Documents