Models of Routing Protocols for Network Simulation and Analyze

(1)

VYSOK ´

E U ˇ

CEN´I TECHNICK ´

E V BRN ˇ

E

BRNO UNIVERSITY OF TECHNOLOGY

FAKULTA INFORMA ˇ

CN´ICH TECHNOLOGI´I

´

USTAV INFORMA ˇ

CN´ICH SYST ´

EM ˚

U

FACULTY OF INFORMATION TECHNOLOGY DEPARTMENT OF INFORMATION SYSTEMS

MODELY SM ˇ

EROVAC´ICH PROTOKOL ˚

U PRO S´I ˇ

TOV ´

Y

SIMUL ´

ATOR A ANAL ´

YZU CHOV ´

AN´I S´IT ˇ

E

BAKAL ´

A ˇ

RSK ´

A PR ´

ACE

BACHELOR’S THESIS

AUTOR PR ´

ACE

JAN ˇ

SAF ´

A ˇ

R

AUTHOR

(2)

VYSOK ´

E U ˇ

CEN´I TECHNICK ´

E V BRN ˇ

E

BRNO UNIVERSITY OF TECHNOLOGY

FAKULTA INFORMA ˇ

CN´ICH TECHNOLOGI´I

´

USTAV INFORMA ˇ

CN´ICH SYST ´

EM ˚

U

FACULTY OF INFORMATION TECHNOLOGY DEPARTMENT OF INFORMATION SYSTEMS

MODELY SM ˇ

EROVAC´ICH PROTOKOL ˚

U PRO S´I ˇ

TOV ´

Y

SIMUL ´

ATOR A ANAL ´

YZU CHOV ´

AN´I S´IT ˇ

E

MODELS OF ROUTING PROTOCOLS FOR NETWORK SIMULATION AND ANALYZE

BAKAL ´

A ˇ

RSK ´

A PR ´

ACE

BACHELOR’S THESIS

AUTOR PR ´

ACE

JAN ˇ

SAF ´

A ˇ

R

AUTHOR

VEDOUC´I PR ´

ACE

Ing. JAROSLAV R ´

AB

SUPERVISOR

(3)

Abstrakt

Práce se zabývá zp˚usobem implementace smˇerovac´ıho protokolu RIP do simulátoru s´ıtˇe ns-2

Kl´ıˇ

cov´

a slova

NS2, RIP, simulace, implementace smˇerovac´ıho protokolu

Abstract

Thesis describes the way of implementation of new routing protocol for network simulator ns-2

Keywords

NS2, RIP, simulation, routing protocol implementation

Citace

Jan ˇSafáˇr: Modely smˇerovac´ıch protokol˚u pro s´ıt’ový simulátor a analýzu chován´ı s´ıtˇe, ba-kaláˇrská práce, Brno, FIT VUT v Brnˇe, 2008

(4)

Modely smˇ

erovac´ıch protokol˚

u pro s´ıt’ov´

y simul´

ator

a anal´

yzu chov´

an´ı s´ıtˇ

e

Prohl´

aˇ

sen´ı

Prohlaˇsuji, ˇze jsem tuto bakaláˇrskou práci vypracoval samostatnˇe pod veden´ım pana Jaro-slava Rába

. . . . Jan ˇSaf´aˇr 9. kvˇetna 2008

c

Jan ˇSaf´aˇr, 2008.

Tato práce vznikla jako ˇskoln´ı d´ılo na Vysokém uˇcen´ı technickém v Brnˇe, Fakultˇe in-formaˇcn´ıch technologi´ı. Práce je chránˇena autorským zákonem a jej´ı uˇzit´ı bez udˇelen´ı oprávnˇen´ı autorem je nezákonné, s výjimkou zákonem definovaných pˇr´ıpad˚u.

(5)

Obsah

1 Uvod´ 3

2 Smˇerovac´ı protokoly 4

2.1 Smˇerov´an´ı. . . 4

2.2 Distance vector protokoly . . . 5

2.2.1 RIP . . . 7

2.3 Protokoly stavu linky . . . 11

2.3.1 OSPF . . . 12

2.4 Path vector protokoly . . . 12

2.4.1 BGP . . . 12

2.5 Konfigurace na zaˇr´ızen´ıch Cisco . . . 13

2.5.1 Konfigurace bez z´avislosti na protokolu . . . 14

2.5.2 RIP . . . 15

3 Simul´ator s´ıtˇe ns-2 18 3.1 Z´akladn´ı prvky . . . 18

3.2 Smˇerovac´ı struktura . . . 19

3.3 Dostupn´e unicastov´e smˇerovac´ı protokoly . . . 21

3.4 Pˇr´ıklad skriptu . . . 21

3.5 Nedostatky v˚uˇci IPv4 . . . 23

4 N´avrh a implementace 24 4.1 Koncept rozˇs´ıˇren´ı . . . 24

4.2 Podp˚urn´e prvky a struktury . . . 24

4.2.1 IPv4 adresy . . . 25

4.2.2 Klasifik´ator . . . 25

4.2.3 Smˇerovac´ı modul . . . 26

4.2.4 Nov´y rtObject . . . 27

4.2.5 Pˇripojen´e s´ıtˇe . . . 28

4.2.6 Statick´e smˇerov´an´ı . . . 29

4.3 Smˇerovac´ı protokol RIP . . . 30

4.3.1 Nov´y typ paket˚u . . . 30

4.3.2 Hlavn´ı tˇr´ıda . . . 32

4.3.3 Seznam rozhran´ı . . . 33

4.3.4 Propojen´ı C++ a OTcl tˇr´ıd . . . 35

4.3.5 Chov´an´ı procesu . . . 35

4.4 Implementace uˇzivatelsk´eho rozhran´ı . . . 36

(6)

4.5 Debuggován´ı proces˚u . . . 38 4.6 Koneˇcné úpravy. . . 39 5 Testy 40 5.1 Návrh test˚u . . . 40 5.2 Test ˇc. 1 . . . 40 5.3 Test ˇc. 2 . . . 41 5.4 Test ˇc. 3 . . . 43 6 Závˇer 45

(7)

Kapitola 1

´

Uvod

Motivace

Tématem této práce bylo zdokumentovat souˇcasné moˇznosti s´ıt’ového simulátoru ns-2 si-mulovat smˇerován´ı v IPv4 s´ıt´ıch. Tyto moˇznosti mˇeli být rozˇs´ıˇreny o skuteˇcný smˇerovac´ı protokol RIP spoleˇcnˇe s uˇzivatelským rozhran´ım podobnému tomu na s´ıt’ových prvc´ıch spoleˇcnosti Cisco. Spoleˇcnˇe s implementac´ı by tato práce mˇela být návodem pro dalˇs´ı rozˇsiˇrovan´ı s´ıt’ového simulátoru.

Na tuto práci navazuje implementace pˇr´ıstupových seznam˚u ˇreˇsených v rámci diplomové práce Bc. Jiˇr´ım Mack˚u. Tato práce spoleˇcnˇe s pˇr´ıstupovými seznamy by mˇeli být pouˇzity v rámci projektu ANSA, Automated Network-wide Security Analysis, kde by mˇely slouˇzit jako souˇcást procedury analýzy bezpeˇcnosti s´ıtˇe.

Struktura dokumentu

Kapitola ‘Smˇerovac´ı protokoly’ slouˇz´ı jako pˇredstaven´ı r˚uzných smˇerovac´ıch protokol˚u a jejich chován´ı. D˚uraz je kladen na distance vector protokoly a konkrétnˇe na RIP, z d˚uvodu, ˇ

ze byl pˇredmˇetem implementace. D´ale je zde uveden zp˚usob konfigurace RIPu na Cisco zaˇr´ızen´ıch.

V kapitole ‘Simulátor s´ıtˇe ns-2’ je popsán simulátor ns-2, jeho základn´ı prvky, popis implementace smˇerován´ı a rozd´ıl v˚uˇci IPv4 prostˇred´ı.

‘Návrh a implementace’ obsahuje definici vlastnost´ı, které by mˇela implementace ob-sahovat. Dále pak popisuje samotnou implementaci smˇerovac´ıho protokolu spoleˇcnˇe s jeho integrac´ı do stávaj´ıc´ı struktury s´ıt’ového simulátoru ns-2.

(8)

Kapitola 2

Smˇ

erovac´ı protokoly

´ Uvod

Pˇred samotnou implementac´ı smˇerovac´ıho protokolu je nutné pochopit k ˇcemu vlastnˇe smˇerovac´ı protokoly slouˇz´ı a jakým zp˚usobem protokoly pracuj´ı. Stejnˇe tak je nutné pro-studovat jejich konfiguraci na Cisco zaˇr´ızen´ıch, jelikoˇz uˇzivatelské rozhran´ı, které se bude implementovat má být podobné rozhran´ı na Cisco zaˇr´ızen´ı.

2.1 Smˇ

erov´

an´ı

Smˇerován´ı je proces výbˇeru cesty od zdroje k zadanému c´ıli skrz obecnou s´ıt’. Tento do-kument je ale konkrétnˇe zamˇeˇren na s´ıtˇe poˇc´ıtaˇcové. V poˇc´ıtaˇcových s´ıt´ıch se procesu smˇerován´ı úˇcastn´ı vˇsechny prvky a pˇredávaj´ı si informace ve formˇe paket˚u. Prvky rozum´ıme smˇerovaˇce, pˇrep´ınaˇce, PC atd. Prvky vˇsak vˇetˇsinou nehledaj´ı celou cestu k c´ıli z d˚uvodu, ˇze m˚uˇze být aˇz pˇr´ıliˇs sloˇzitá, ale pouze se rozhodnout na základˇe smˇerovac´ı tabulky, kterému dalˇs´ımu prvku paket pˇredaj´ı.

Tabulka 2.1: Pˇr´ıklad smˇerovac´ı tabulky Identifik´ator c´ıle Cena Dalˇs´ı uzel

10.0.0.0/8 1 192.168.3.6

10.3.0.0/16 2 192.168.2.1

Smˇerovac´ı tabulka je datová struktura jej´ıˇz záznamy obsahuj´ı identifikátor (ip adresu) c´ıle, cenu cesty k dosaˇzen´ı tohoto c´ıle a dalˇs´ı uzel na cestˇe k jeho dosaˇzen´ı. Pˇri vyhledáván´ı ve smˇerovac´ı tabulce maj´ı pˇrednost záznamy s vˇetˇs´ım s´ıt’ovým prefixem, tzn. specifiˇctˇejˇs´ı záznamy. S´ıt’ový prefix je zkrácený zápis s´ıt’ové masky, pˇresnˇeji souˇcet jedniˇcek v n´ı. S´ıt’ová maska vymezuje, která ˇcást z adresy je adresa s´ıtˇe a která adresa prvku, pomoc´ı bitové operace AND. V tabulce 2.2 je vidˇet pˇr´ıklad pouˇzit´ı tˇechto pojm˚u. Zkrácenˇe zapisujeme záznamy ve tvaru s´ıt’/prefix.

Pokud se pomoc´ı smˇerovac´ı tabulky z obrázku2.1bude vyhledávat dalˇs´ı skok pro paket, s c´ılovou adresou prvku 10.3.1.4, bude vybrán záznam 10.3.0.0/16, i kdyˇz by mohl být poslán do s´ıtˇe 10.0.0.0/8, na základˇe vyˇsˇs´ıho prefixu

Otázka je, na základˇe ˇceho si kaˇzdý prvek vytvoˇr´ı svoj´ı smˇerovac´ı tabulku? M˚uˇze být samozˇrejmˇe vytvoˇrena ruˇcnˇe, u osobn´ıch poˇc´ıtaˇc˚u s jedn´ım s´ıt’ovým je to pomˇernˇe

(9)

jedno-Tabulka 2.2: Aplikace s´ıt’ov´e masky

IP adresa 00001100.00000010.00000101.00100101

S´ıt’ov´a maska 11111111.11111111.11111100.00000000

S´ıt’ 00001100.00000010.00000100.00000000

Prefix 22

duché, staˇc´ı definovat cestu k bránˇe, na kterou maj´ı smˇerovat vˇsechny pakety, které nejsou urˇcené pro pˇripojenou s´ıt’. U zaˇr´ızen´ı s v´ıce rozhran´ımi nen´ı situace tak snadná, protoˇze administrátor mus´ı definovat cesty ke vˇsem s´ıt´ım do kterých chce m´ıt pˇr´ıstup. A pokud velikost smˇerovac´ı tabulky pˇresáhne urˇcitou velikost, m˚uˇze se stát jej´ı správa nároˇcnou. To-muto zp˚usobu se ˇr´ıká manuáln´ı smˇerovan´ı, protoˇze m˚uˇze zmˇenit pouze lidským zásahem. Je moˇzné se setkat i s pojmem statické smˇerován´ı.

Východiskem pro prvky, kde by ruˇcn´ı definován´ı tabulky bylo pˇr´ıliˇs zdlouhavé nebo nevýhodné, leˇz´ı ve smˇerovac´ıch protokolech. Smˇerovac´ı protokoly slouˇz´ı k výmˇenˇe smˇerovac´ıch informac´ı mezi uzly v s´ıt´ı a tedy k propagaci cesty k c´ıl˚um. Jejich výhodou oproti manuáln´ımu smˇerován´ı je, ˇze mohou aktivnˇe reagovat na zmˇeny v s´ıt´ı a mˇenit smˇerovac´ı tabulku na základˇe tˇechto zmˇen, napˇr´ıklad výpadek prvku nebo linky. Z toho d˚uvodu se smˇerován´ı pomoc´ı smˇerovac´ıch protokol˚u nazývá dynamické.

Smˇerovac´ı protokoly v prostˇred´ı internetu se daj´ı rozdˇelit, na základˇe parametr˚u, do r˚uzných skupin. Nejˇcastˇeji se rozdˇeluj´ı podle m´ısta pouˇzit´ı a to do 2 skupin. EGP, exterior gateway protocol nebo-li vnˇejˇs´ı smˇerovac´ı protokol, slouˇz´ı ke smˇerovan´ı mezi autonomn´ımi systémy, zkrácenˇe AS. AS je ˇcást s´ıtˇe s jednotnou smˇerovac´ı politikou v˚uˇci zbytku internetu, který je vlastnˇe s´ıt´ı autonomn´ıch systém˚u. Typicky tuto politiku ˇr´ıd´ı nˇejaká organizace, napˇr´ıklad poskytovatel internetu, ISP.

Druhou skupinou jsou IGP, interior gateway protocol nebo-li vnitˇrn´ı smˇerovac´ı protokol, který se pouˇz´ıvá pro smˇerován´ı uvnitˇr autonomn´ıho systému.

Také se daj´ı rozdˇelit podle zp˚usobu jakým jednotlivé uzly vymˇeˇnuj´ı smˇerovac´ı informace.

2.2 Distance vector protokoly

Distance vektor protokoly vyuˇz´ıvaj´ı Bellman-Ford˚uv algoritmus pro výpoˇcet smˇerovac´ı ta-bulky. Protokoly pracuj´ı na jednoduchém principu, prvek zná nejprve pouze pˇripojené s´ıtˇe a cenu cesty k nim. Tyto informace periodicky, po urˇcitém definovaném intervalu, rozes´ılá svým soused˚um, na kterých také bˇeˇz´ı instance tohoto protokolu. Prvky si uchovávaj´ı in-formaci o nejlepˇs´ı cestˇe k danému c´ıli nebo cenu ke vˇsem c´ıl˚um skrz vˇsechny své sousedy, oba pˇr´ıstupy jsou moˇzné. Prvku, kterému dojde zpráva od procesu na jiném prvku si zak-tualizuje informace, které má ve své databázi s´ıt´ı, které se dov´ıdá prostˇrednictv´ım daného souseda. Pokud si uchovává pouze nejlepˇs´ı cestu, zkontroluje zda cesta ve zprávˇe má lepˇs´ı, menˇs´ı, metriku. Takto nauˇcené informace propaguje dál, ale pouze nejlepˇs´ı variantu pro daný c´ıl. Smˇerovac´ı tabulka obsahuje pouze nejlepˇs´ı varianty.

Kv˚uli takovému zp˚usobu uˇcen´ı s´ıt´ı, nazýváme tento typ smˇerován´ı jako ’smˇerován´ı pomoc´ı zvˇesti’ (routing by rumor), protoˇze uzel d˚uvˇeˇruje informac´ım, které zaslechl od svého souseda. Bohuˇzel to vede k problému poˇc´ıtán´ı do nekoneˇcna (count-to-infinity problem).

(10)

Obrázek 2.1: Poˇc´ıtán´ı do nekoneˇcna Poˇc´ıtán´ı do nekoneˇcna

Problém poˇc´ıtán´ı do nekoneˇcna bude vysvˇetlen pomoc´ı pˇr´ıkladu, v kterém pouˇzijeme to-pologii z obrázku2.1.

Cestu k D, popˇr´ıpadˇe do s´ıtˇe mezi C a D, zná z poˇcátku pouze C. Ta propaguje tuto informaci ke svým soused˚um A a B. Pˇredpokládejme, ˇze zvýˇsen´ı ceny za pˇrechod pˇres jednu linku je 1. A a B tedy v´ı, ˇze cesta k D je pˇres C s cenou 2. Tuto informaci dále propaguj´ı. Výsledná tabulka informac´ı pro uzel C je vidˇet v tabulce 2.2. Co se ale stane pˇr´ı výpadku linky mezi C a D? Uzel C si smaˇze informace o cestách skrz D. Od uzlu A nebo B se dozv´ı, ˇ

ze nejlepˇs´ı cena do D je 2 skrz C, protoˇze oni se nemˇeli jak dozvˇedˇet, ˇze linka mezi C a D je nefunkˇcn´ı. C si aktualizuje smˇerovac´ı tabulku, ˇze D je k dispozici skrz A, popˇr´ıpadˇe B, a tuto metriku, 3 (2 + 1 za cenu linky), odes´ılá dál. A a B si poté aktualizuj´ı záznamy o D skrz A, ta stoupne ze 2 na 4 (3 + 1 za cenu linky), C dostane zase tuto informace zvýˇs´ı cenu na 5 a propaguje dál aˇz do nekoneˇcna. Pakety urˇcené pro D mezit´ım koluj´ı mezi tˇemito 3 uzly a zbyteˇcnˇe vytˇeˇzuj´ı zdroje.

A B D

skrz A 1 2 2

srkz B 2 1 2

srkz D 3 3 1

Z d˚uvodu, ˇze se s t´ımto problémem setkávali distance vector protokoly jiˇz od svého vzniku, a toto chován´ı bylo znaˇcnˇe neˇzádouc´ı, vzniklo nˇekolik technik, které se snaˇz´ı zabránit tomuto ˇskodlivému chován´ı.

Maxim´aln´ı metrika - maximum count

Pokud cena cesta k s´ıt´ı pˇresáhne urˇcitou mez, je povaˇzována za nedostupnou a pakety urˇcené pro n´ı se zahazuj´ı. V´ıce jak maximáln´ı metrika se nikdy nepropaguje.

Rozdˇelen´y horizont - split horizont

Technika, která zabraˇnuje odes´ılán´ı informac´ı o cestách k s´ıt´ım zpˇet uzlu od kterého byli z´ıskaný. Pokud se tedy vrát´ıme k obrázku 2.1, A a B nebudou informovat C o cestˇe k D, protoˇze tuto informaci z´ıskali od C.

(11)

Zneplatnˇen´ı zpˇetn´e cesty - poison reverse

Tato technika se pouˇz´ıvá spoleˇcnˇe s technikou rozdˇeleného horizontu. Informace o s´ıt´ıch se znovu propaguj´ı zpˇet k prvku od kterého byly z´ıskány, ale s metrikou, která v daném protokolu znaˇc´ı nedostupnost.

Aktualizace nez´avisle na ˇcasovaˇci - triggered updates

Kdykoliv se prvku zmˇen´ı metrika do urˇcité s´ıtˇe, informuje okamˇzitˇe o této zmˇenˇe své sou-sedy, bez toho aby ˇcekal na dobu kdy má pos´ılat pravidelnou aktualizaci.

Dalˇs´ı ˇcasovaˇce - timers ˇ

Casovaˇc zneplatnˇen´ı cesty (invalid timer), vyprˇs´ı pokud s´ıt’, nebyla dlouho uvedena v ˇzádné aktualizaci. Po vyprˇsen´ı se jej´ı metrika nastav´ı na hodnotu která oznaˇcuje nekoneˇcno. Ale záznam z˚ustává stále ve smˇerovac´ı tabulce. V pˇr´ıpadˇe ˇze cesta je zneplatnˇena, at’ uˇz ˇ

casovaˇcem nebo aktualizac´ı s nekoneˇcnou metrikou od prvku, od kterého jsme informaci o s´ıti z´ıskali, m˚uˇze být aktivován ˇcasovaˇc typu holddown, bˇehem kterého nejsou pˇrij´ımány ˇ

zádné aktualizace týkaj´ıc´ıho se tohoto c´ıle od jiných zdroj˚u neˇz brány (prvku, který nám informace o této s´ıt´ı zas´ılá.

Jeˇstˇe se pouˇz´ıv´a ˇcasovaˇc expirace (flush timer), kdy je cesta ´uplnˇe odstranˇena ze smˇerovac´ı tabulky.

Pˇri pouˇzit´ı výˇse uvedených technik se stabilita smˇerovac´ıho protokolu znaˇcnˇe zvyˇsuje, ale i tak byli zdokumentovány pˇr´ıpady, kdy tento problém m˚uˇze nastat.

2.2.1 RIP

RIP, routing information protocol, se pouˇz´ıvá jako IGP. Komunikuje pomoc´ı UDP paket˚u na portu 520 Jako metriku vyuˇz´ıvá poˇcet skok˚u, poˇcet uzlu, které jsou mezi n´ım a c´ılovou s´ıt´ı. Maximáln´ı hodnota, kterou m˚uˇze metrika nab´ıt je 15, 16 je jiˇz povaˇzováno za nekoneˇcno. Pˇr´ımo pˇripojené s´ıtˇe maj´ı metriku 0. Aktualizace si mezi sebou uzly vymˇeˇnuj´ı periodicky kaˇzdých 30 sekund a pokud s´ıt’ nen´ı uveden v aktualizac´ıch v´ıce jak 180 vteˇrin, 6 krát aktualizaˇcn´ı ˇcas, je zneplatnˇena popˇr´ıpadˇe vyhozena ze smˇerovac´ı tabulky. Pouˇz´ıvá vˇetˇsinu výˇse uvedených zp˚usob˚u k zabránˇen´ı poˇc´ıtán´ı do nekoneˇcna.

RIP existuje ve dvou verz´ıch, verze 1 a 2, kter´e se mezi sebou liˇs´ı v nˇekolika bodech: • RIPv1 nepodporuje VLSM, RIPv2 ano

• RIPv1 nepodporuje autentizaci, RIPv2 ano

• RIPv1 pos´ıl´a aktualizace na adresu 255.255.255.255, RIPv2 na adresu 224.0.0.9 • RIPv1 nepodporuje znaˇcen´ı z´aznam˚u

Podpora VLSM, variable length subnetmask, tedy masek s r˚uznou d´elkou prefixu,

zna-mená, ˇze v rámci 1 tˇr´ıdn´ı s´ıtˇe mohou existovat prefixy r˚uzné délky. Podpora VLSM je v RIPv2 doc´ılena t´ım, ˇze v aktualizac´ıch jsou uvedeny i prefixy jednotlivých s´ıt´ı.

(12)

Tabulka 2.3: Paket RIPu verze 1

1 octet 1 octet 2 octet 2 octet 2 octet 4 octet 4 octet 4 octet 4 octet

command version – AFI – IP

address – – metric

Tabulka 2.4: Paket RIPu verze 2

1 octet 1 octet 2 octet 2 octet 2 octet 4 octet 4 octet 4 octet 4 octet

command version – AFI tag IP

address subnet mask next hop metric Form´at paket˚u

V tabulk´ach2.3 a2.4 je vidˇet struktura paket˚u obou verz´ı RIPu. Vysvˇetlen´ı jednotliv´ych pol´ı v paket˚u:

• Command - pˇr´ıkaz - urˇcuje typ paketu, zda se jedná o dotaz nebo odpovˇed’ • Version - verze - urˇcuje verzi procesu RIPu, který daný paket poslal

• AFI - rodina adres - RIP ma podporu i jak pro Token Ring s´ıtˇe tak pro Ethernet s´ıtˇe • tag - pouze RIPv2, slouˇz´ı pro rozliˇsen´ı s´ıt´ı nauˇcen´ych skrz RIP nebo extern´ıch zdroj˚u • IP address - adresa s´ıtˇe

• subnet mask - maska pods´ıtˇe - pouze RIPv2, toto pole zajiˇst’uje podporu VLSM • next hop - adresa dalˇs´ıho skoku smˇerem k dan´e s´ıt´ı - pouze RIPv2

• metric - metrika - cena cesty k s´ıti

Kromˇe prvn´ıch 3 bunˇek, jsou následuj´ıc´ı buˇnky vlastnˇe záznamem smˇerovac´ı tabulky. Tato ˇcást, od AFI pole vˇcetnˇe, se m˚uˇze aˇz 25 krát opakovat. Jeden paket tak m˚uˇze nést informaci o v´ıce s´ıt´ıch. Hodnota AFI pro ethernetové s´ıtˇe je 0x2.

Pakety jsou v podstatˇe dvou typu, dotaz, hodnota v poli command je 1, a odpovˇed’, hod-nota 2. Pakety typu dotaz jsou pouˇz´ıvány pro vyˇzádán´ı celé smˇerovac´ı tabulky, popˇr´ıpadˇe konkretn´ı s´ıtˇe. Vys´ılá se vˇetˇsinou pokud se nˇekteré ze s´ıt’ových rozhran´ı prvku stalo aktivn´ı. Paket typu odpovˇed’ se pos´ılá na vyˇzádán´ı, pomoc´ı paketu dotaz, ale jeho hlavn´ı pouˇzit´ı spoˇc´ıvá v tom, ˇze je pravidelnˇe zas´ılán soused˚um s informacemi o s´ıt´ıch, které uzel má ve smˇerovac´ı tabulce.

Pokud je aktivov´ana autentizace, m´ısto prvn´ıho z´aznamu s´ıtˇe jsou uvedeny autentizaˇcn´ı

(13)

Obr´azek 2.2: Pˇr´ıklad topologie

Zp˚usob vytv´aˇren´ı odpovˇedi

RIP implementuje nˇekolik technik, které zabraˇnuj´ı poˇc´ıtán´ı do nekoneˇcna. Ale jejich aktivaci komplikuje rozes´ılán´ı aktualizac´ı. Pokud by nebyly tyto techniky aktivovány, mohly by se ze vˇsech rozhran´ı, ke vˇsem soused˚um pos´ılat stejné aktualizace. Pokud jsou ale aktivn´ı je nutné vytváˇret aktualizace pro kaˇzdé rozhran´ı zvláˇst’ s ohledem na aktivované techniky.

Dalˇs´ım problémem je semi-podpora VLSM v RIPv1, alespoˇn na smˇerovaˇc´ıch Cisco. Ta zp˚usobuje, ˇze je moˇzné odeslat informaci o s´ıt´ı na rozhran´ı leˇz´ıc´ı ve stejné tˇr´ıdn´ı s´ıt´ı a má stejný prefix jako propagovaná s´ıt’.

Pr˚ubˇeh rozhodován´ı je zachycen n´ıˇze. • S´ıt’ podléhá rozdˇelenému horizontu

– tuto s´ıt’ nepˇrid´avej

– pˇridej tuto s´ıt’, ale zmˇen metriku na nekoneˇcnou (pokud je zapnut´e otr´aven´ı cesty)

• S´ıt’ nepodléhá rozdˇelenému horizontu

– S´ıt’ bude propagována do s´ıtˇe spadaj´ıc´ı do r˚uzné tˇr´ıdn´ı s´ıtˇe ∗ pˇreved’ s´ıt’ na tˇr´ıdn´ı (u RIPv2 se muˇze, ale nemus´ı pˇrevádˇet) ∗ pˇridej s´ıt’ do aktualizace

– S´ıt’ bude propagov´ana do s´ıtˇe spadaj´ıc´ı do stejn´e tˇr´ıdn´ı s´ıtˇe

∗ S´ıt’ má stejný prefix, jako s´ıt’ do které se bude pos´ılat aktualizace · pˇridej s´ıt’ do aktualizace

∗ S´ıt’ má r˚uzný prefix neˇz s´ıt’ do které se bude pos´ılat aktualizace · RIPv1 - nepˇridávej s´ıt’ do aktualizace

· RIPv2 - pˇridej s´ıt’ do aktualizace

(14)

Pˇr´ıklad

Jednotlivá pravidla si bl´ıˇz vysvˇetl´ıme na obrázku 2.2 s pˇr´ıkladem topologie. Smˇerovaˇc ve stˇredu chce zaslat pravidelnou aktualizace do vˇsech pˇripojených s´ıt´ı. Rozebereme vytvoˇren´ı aktualizace pro horn´ı smˇerovaˇc.

Horn´ı smˇerovaˇc leˇz´ı na s´ıt´ı 10.2.0.0/24.

• 10.1.0.0/24 - Bude v aktualizaci, je ve stejné tˇr´ıdn´ı s´ıti, ale má stejný prefix jako s´ıt’ na kterou je zas´ılána aktualizace

• 10.2.0.0/24 - Nebude v aktualizaci nebo bude, ale s nekoneˇcnou metrikou, protoˇze

podléhá rozdˇelenému horizontu

• 10.3.0.0/16 - Nebude v aktualizaci, sice je ve stejné tˇr´ıdn´ı s´ıti, ale má rozd´ılný prefix • 192.168.2.128/27 - Bude v aktualizaci, ale bude pˇrevedena na s´ıt’ 192.168.2.0/24 U takto vytvoˇrené odpovˇedi se uˇz pouze zvýˇs´ı metrika u vˇsech záznam˚u a odpovˇed’ se odeˇsle.

Zp˚usob kontroly autentizace paket˚u

Po aktivac´ı autentizace na rozhran´ı smˇerovaˇc pˇrij´ımá pouze takové smˇerovac´ı informace, které se prokáˇz´ı platným heslem nebo hashem.

Autentizace nen´ı podporována RIPem verze 1 coˇz m˚uˇze zp˚usobit nestabilitu v s´ıt´ı. RIPv1 prvn´ı záznam, ten který obsahuje autentizaˇcn´ı údaje, ignoruje a zpracovává dalˇs´ı záznamy.

Pokud je aktivn´ı RIP verze 2 bez aktivn´ı autentizace na rozhran´ı a pˇrijde paket s

autentizaˇcn´ım z´aznamem, je paket okamˇzitˇe zahozen. Ostatn´ı pakety, verze 1 a verze 2 bez autentizace, jsou pˇrijaty

Pˇri aktivované autentizaci jsou veˇskeré neautentizované pakety zahozeny u ostatn´ıch je kontrolována autentizaˇcn´ı hlaviˇcka dle nastaven´ı. Zda jsou hesla nebo vypoˇc´ıtané hashe totoˇzné.

Zp˚usob zpracov´an´ı odpovˇedi

Paket, který projde autentizaˇcn´ı kontrolou, je dále zpracováván. Jednotlivé záznamy se porovnávaj´ı s aktuáln´ım stavem databáze a pokud jsou nutné zmˇeny je databáze aktuali-zována. Záznamy jsou zpracovávány postupnˇe, jak jsou uvedeny v paketu. Jako dalˇs´ı skok je pouˇzita zdrojová adresa v ip hlaviˇcce paketu.

Kontrola s databázi prob´ıhá následuj´ıc´ım zp˚usobem: • Záznam je jiˇz ve smˇerovac´ı tabulce

– Stejn´a br´ana

∗ V paketu je jin´a metrika

· zmˇen metriku ve smˇerovac´ı tabulce, aby odpov´ıdala metrice v odpovˇedi · poˇsli aktualizaci soused˚um

∗ resetuj ˇcasovaˇc zneplatnˇen´ı ∗ pˇrejdi na dalˇs´ı z´aznam

(15)

– Nestejn´a br´ana

∗ Metrika v paketu je lepˇs´ı

· zmˇen informace ve smˇerovac´ı tabulce · resetuj ˇcasovaˇc zneplatnˇen´ı

· poˇsli aktualizaci soused˚um ∗ pˇrejdi na dalˇs´ı z´aznam

• Z´aznam nen´ı ve smˇerovac´ı tabulce – Metrika je nekoneˇcn´a

∗ pˇrejdi na dalˇs´ı z´aznam – Metrika nen´ı nekoneˇcn´a

∗ pˇridej novou s´ıt’ do smˇerovac´ı tabulky ∗ aktivuj ˇc´ıtaˇc zneplatnˇen´ı

∗ pˇrejdi na nový záznam Zp˚usob zpracován´ı dotazu

Pokud dotaz obsahuje pouze 1 z´aznam s hodnotou v poli AFI 0 a s nekoneˇcnou metrikou,

je zaslána zpˇet celá smˇerovac´ı tabulka. Tento zp˚usob dotazu je v praxi nejpouˇz´ıvanˇejˇs´ı. V pˇr´ıpadˇe, ˇze záznam˚u je v´ıc, zpracováván´ı prob´ıhá t´ım zp˚usobem, ˇze se vytvoˇr´ı od-povˇed’, která obsahuje záznamy z dotazu. Pokud záznam z dotazu je ve smˇerovac´ı tabulce, tak je v odpovˇedi uveden s metrikou ze smˇerovac´ı tabulky. Pokud ve smˇerovac´ı tabulce nen´ı, je u nˇeho uvedená nekoneˇcná metrika.

2.3 Protokoly stavu linky

Koncept protokol˚u stavu linky spoˇc´ıvá v tom, ˇze si vˇsechny prvky v s´ıti vytvoˇr´ı stejný graf s´ıtˇe, z kterého si vypoˇc´ıtaj´ı poˇc´ıtaj´ı cestu ke vˇsem ostatn´ım prvk˚um/s´ıt´ım. Rozd´ıl mezi protokoly stavu linky a distance vektor protokoly, spoˇc´ıvá v tom, ˇze distance vektor protokoly si vymˇeˇnuj´ı smˇerovac´ı tabulky. Protokoly stavu linky si vymˇeˇnuj´ı pouze informace potˇrebné k vytvoˇren´ı onoho grafu s´ıtˇe.

Výhoda tˇechto protokol˚u je, ˇze jsou pouˇzitelné i do vˇetˇs´ıch s´ıt´ıch, na rozd´ıl od distance vektor protokol˚u, kterým trvá aˇz pˇr´ıliˇs dlouho neˇz celá s´ıt’ zkonverguje, ustál´ı se do jed-notného stavu. U vˇetˇs´ıch s´ıt´ıch m˚uˇze být i velkou nevýhodou omezen´ı maximáln´ıho poˇctu skok˚u u distance vektor protokol˚u, kdy s´ıt’ bude vˇetˇs´ı neˇz tento maximáln´ı poˇcet skok˚u.

Obecn´y protokol stavu linky

Obecn´y protokol stavu linky funguje na n´asleduj´ıc´ım principu:

• Prvek si nejprve zjist´ı pomoc´ı nˇejakého protokolu, které prvky leˇz´ı na pˇr´ımo pˇripojených s´ıt´ıch.

• Prvek rozes´ılá informace o pˇr´ımo pˇr´ıpojených prvc´ıch do celé s´ıtˇe. • Prvek pˇrij´ımá informace, které pos´ılaj´ı ostatn´ı prvky.

(16)

• Aˇz celá s´ıt’ zkonverguje, vˇsechny uzly maj´ı stejný graf, vypoˇc´ıtaj´ı si prvky nejkratˇs´ı cestu ke vˇsem prvk˚um pomoc´ı Dijkstrova algoritmu. Výsledky si um´ıst´ı do smˇerovac´ı tabulky

V pˇr´ıpadˇe nˇejaké zmˇeny v s´ıt´ı, prvek, který tuto zmˇenu zaznamená, si zmˇen´ı sv˚uj graf s´ıtˇe a rozeˇsle informaci o zmˇenˇe do celé s´ıtˇe. Prvky si poté pˇrepoˇc´ıtaj´ı svoji smˇerovac´ı tabulku.

2.3.1 OSPF

Open shortest path first protokol se pouˇz´ıvá jako IGP. Protokol komunikuje na unicastových IP adresách a multicastových adresách 224.0.0.5 a 224.0.0.6, nevyuˇz´ıvá vˇsak sluˇzeb TCP ani UDP, ale pˇr´ımo IP, skrz IP protokol 89. D´ıky tomu si mus´ı, ale zajistit zpracován´ı chyb a pˇrepos´ılán´ı nedoruˇcených zpráv.

Obecný protokol stavu linky rozˇsiˇruje o oblasti, s´ıt’ poté nen´ı plochá, tzn. vˇsechny uzly vid´ı vˇsechny ostatn´ı, ale je hierarchicky strukturovaná. Graf s´ıtˇe se poté vytváˇr´ı pro kaˇzdou oblast zvláˇst’. Na hranic´ıch mezi oblastmi jsou takzvané hraniˇcn´ı prvky, které zajiˇst’uj´ı výmˇenu informac´ı mezi oblastmi. Existuje nˇekolik speciáln´ıch typu oblast´ı:

• Páteˇrn´ı oblast - vˇsechny ostatn´ı oblasti mus´ı být pˇripojeny k této oblasti. Zajiˇst’uje výmˇenu smˇerovac´ıch informac´ıch mezi ostatn´ımi oblastmi.

• Pahýln´ı oblast - Stub oblast - nedostává smˇerovac´ı informace o s´ıt´ıch, které se ospf pro-ces dozvˇedˇel od ostatn´ıch smˇerovac´ıch protokol˚u, ale smˇerovac´ı informace z ostatn´ıch ospf oblast´ı se do této oblasti dostanou.

• Uplný pahýl - Totally stubby oblast - Pouze implicitn´ı cesta, smˇer kudy se budou pos´ılat vˇsechny pakety, pro které nen´ı c´ılová s´ıt’ ve smˇerovac´ı tabulce, se m˚uˇze propa-govat do této oblasti

• Ne tak pah´yln´ı oblast - Not-so-stubby oblast - Skrz oblast se mohou exportovat do

p´ateˇrn´ı oblasti extern´ı cesty, ale ne z p´ateˇrn´ı s´ıtˇe do n´ı.

Jako metrika se pouˇz´ıv´a souˇcet cen linek mezi zdrojem a c´ılem. Cena linky je rovna pod´ılu 100Mbps dˇeleno rychlost linky.

2.4 Path vector protokoly

Path vector protokoly, neboli protokoly vektoru cesty, se pouˇz´ıvaj´ı zejména jako EGP pro-tokoly. Princip má nˇekteré vlastnosti spoleˇcné s distance vektor protokoly. V autonomn´ım systému existuje prvek, mluvˇc´ı, který vytváˇr´ı a inzeruje smˇerovac´ı tabulku ostatn´ım prvk˚um. Rozd´ıl je v tom, ˇze pouze mluvˇc´ı maj´ı právo mezi sebou komunikovat. U tohoto typu proto-kol˚u se nepouˇz´ıvá metrika, nam´ısto n´ı je pouˇzit vektor cesty, vektor autonomn´ıch systému, který popisuje cestu k dané koncové s´ıti. Preferovanou cestou do s´ıtˇe se stává ta, na n´ıˇz se mus´ı proj´ıt nejmenˇs´ım mnoˇzstv´ı autonomn´ıch systém˚u.

2.4.1 BGP

BGP, border gateway protokol, se pouˇz´ıvá jako smˇerovac´ı protokol v internetu, mezi ISP. Komunikuje na unicastových adresách na portu 179 a vyuˇz´ıvá sluˇzeb TCP. U tohoto pro-tokolu je výbˇer cesty k s´ıti, ˇr´ızen na báz´ı politik, sp´ıˇse neˇz na bázi metriky, nejkratˇs´ı cesty.

(17)

Vzhledem k tomu, ˇze se dané smˇerovac´ı politiky aplikuj´ı v kaˇzdém autonomn´ım systému, m˚uˇze být výsledná cesta pomˇernˇe vzdálená cestˇe nejkratˇs´ı.

BGP je pomˇernˇe robustn´ı protokol a ne kaˇzdý prvek ho bude schopný provozovat, i kdyˇz také záleˇz´ı na velikost´ı smˇerovac´ı tabulky. Pro pˇredstavu, smˇerovac´ı tabulka internetu má pˇres 245,000 záznam˚u. U velkých provozovatel˚u internetu toto ˇc´ıslo m˚uˇze stoupnout i o 50%, kv˚uli smˇerován´ı ve vnitˇrn´ı s´ıt´ı a mezi zákazn´ıky.

2.5 Konfigurace na zaˇ

r´ızen´ıch Cisco

Konfigurace na zaˇr´ızen´ıch Cisco se provád´ı pˇres konzoly, dá se pouˇz´ıt ´ı webové rozhran´ı, ale konfigurace pˇres pˇr´ıkazový ˇrádek je stále nejpouˇz´ıvanˇejˇs´ı. Na poˇc´ıtaˇci, z kterého se bude provádˇet konfigurace s´ıt’ového prvku mus´ı bˇeˇzet program, který um´ı emulovat VT100 ter-minál. Napˇr´ıklad HyperTerminal nebo PuTty. Program mus´ı nastavit parametry sériového portu, skrz který se bude komunikovat se zaˇr´ızen´ım na následuj´ıc´ı hodnoty:

• Rychlost v baudech - 9600 • Poˇcet datových bit˚u - 8 • Parita - ˇzádná

• Poˇcet stop bit˚u - 1 • Kontrola toku - ˇz´adn´a

Propojen´ı prvku se pot´e provede kabelem s koncovkou RJ-45 na stranˇe prvku a DB-9

na stranˇe PC.

Uˇzivatel se poté octne v uˇzivatelském modu, indikovaným znakem ‘>’ za názvem prvku. V tomto modu má uˇzivatel k dispozici pouze omezenou sadu pˇr´ıkaz˚u k základn´ı diagnostice smˇerovaˇce.

Router>

Pro vstup do privilegovaného reˇzimu, je nutné zadat pˇr´ıkaz enable. Po zadán´ı m˚uˇze být uˇzivatel vyzván k zadan´ı hesla. Oproti uˇzivatelskému módu je k dispozici detailnˇejˇs´ı diagnostika smˇerovaˇce a moˇznost pˇrej´ıt do konfiguraˇcn´ıho reˇzimu, odkud se dá mˇenit kon-figurace prvku. Privilegovaný mód má indikaˇcn´ı znak ‘#’. Pro opuˇstˇen´ı privilegovaného reˇzimu m˚uˇzeme pouˇz´ıt pˇr´ıkaz disable

Router> enable Password: Router#

Router# disable Router>

Do konfiguraˇcn´ıho reˇzimu, pˇrejdeme pˇr´ıkazem configure terminal. Pˇr´ıtomnost v kon-figuraˇcn´ım reˇzimu lze t´ım, ˇze mezi názvem prvku a znakem ‘#’ je pˇr´ıtomna sekvence znaku (config). Z globáln´ıho konfiguraˇcn´ıho reˇzimu se poté pˇrecház´ı do jednotlivých spe-cifických mód˚u, napˇr do konfigurace smˇerovac´ıch protokol˚u, rozhran´ı atd. Pro opuˇstˇen´ı konfiguraˇcn´ıho reˇzimu slouˇz´ı 2 pˇr´ıkazy exit a end. Exit vrát´ı uˇzivatele o jednu úroveˇn zpˇet, napˇr. ze konfigurace smˇerovac´ıho protokolu zpˇet do globáln´ıho konfiguraˇcn´ıho reˇzimu nebo z globáln´ıho konfiguraˇcn´ıho reˇzimu zpˇet do privilegovaného. Pˇr´ıkaz end vrát´ı uˇzivatele okamˇzitˇe zpˇet do reˇzimu privilegovaného

(18)

Router# configure terminal Router(config)#

Router(config)# exit Router#

Konfiguraˇcn´ı moˇznosti Cisco zaˇr´ızen´ı jsou velice rozsáhlé a podrobný popis vˇsech by byl aˇz pˇr´ıliˇs rozsáhlý. Následuj´ıc´ı ˇcást se proto bude vˇenovat pouze konfiguraci smˇerovac´ıho protokolu RIP a nˇekolika moˇznostem, které jsou pouˇzitelné vˇsemi smˇerovac´ımi protokoly nebo maj´ı významný vliv na smˇerován´ı.

2.5.1 Konfigurace bez z´avislosti na protokolu

Statick´e smˇerov´an´ı

Cisco zaˇr´ızen´ı nab´ızej´ı podporu pro manuáln´ı specifikován´ı smˇerovac´ı tabulky. Konfigurace statických cest se provád´ı pˇr´ıkazem následuj´ıc´ım zp˚usobem¨

ip route network net_mask { next_hop_address | interface } [distance] [tag] [permament]

Bˇeˇznˇe se vˇsak posledn´ı 2 volitelné parametry nepouˇz´ıvaj´ı. Parametr distance oznaˇcuje administrativn´ı vzdálenost. Ta jako moc je daný zdroj smˇerovac´ıch informac´ı preferován.

ˇ

C´ım niˇzˇs´ı vzdálenost t´ım je zdroj kvalitnˇejˇs´ı. Kaˇzdý smˇerovac´ı protokol má pˇriˇrazenou admi-nistrativn´ı vzdálenost, kterou je vˇsak moˇzné mˇenit. Implicitn´ı nastaven´ı administrativn´ıch vzdálenost´ı nˇekterých protokol˚u je v tabulce 2.5. Maximáln´ı hodnota je 255.

Tabulka 2.5: Administrativn´ı vzd´alenosti protokol˚u

Protokol Implicitn´ı adm. vzd´alenost

Pˇripojen´e s´ıtˇe 0 Statick´e cesty 1 BGP 20 OSPF 110 RIP 120 Pˇr´ıklad: Router(config)# ip route 192.168.5.0 255.255.255.0 10.3.4.2 150

Moˇznost specifikovat administrativn´ı vzdálenost (distance) se vyuˇz´ıvá hlavnˇe pˇri pouˇz´ıt´ı záloˇzn´ıch linek, kdy se vytvoˇr´ı statická cesta do urˇcité s´ıtˇe s vyˇsˇs´ı vzdálenost´ı neˇz je pouˇz´ıvaný dynamický smˇerovac´ı protokol. Pokud se d˚usledkem nedostupnosti hlavn´ı linky, smaˇze cesta do s´ıtˇe ze smˇerovac´ı tabulky, je pouˇzita ta s vyˇsˇs´ı vzdálenosti skrz záloˇzn´ı linku. Existuje speciáln´ı s´ıt’ 0.0.0.0 s prefixem 0, na kterou, pokud je uvedena ve smˇerovac´ı tabulce, se odes´ılaj´ı veˇskeré pakety jej´ıˇz c´ılová s´ıt’ nen´ı ve smˇerovac´ı tabulce.

Kl´ıˇcenky

Kl´ıˇcenky jsou struktury, které jsou vyuˇz´ıvány na uskladˇnován´ı hesel, pouˇz´ıvaných pˇri au-tentizaci smˇerovac´ıch informac´ı. Definice kl´ıˇcenky se provád´ı v globáln´ım konfiguraˇcn´ım reˇzimu pˇr´ıkazem:

(19)

Router(config)# key chain keychain_name Router(config-keychain)#

Po definici kl´ıˇcenky je nutné vytvoˇrit jednotlivé kl´ıˇce pomoc´ı identifikátoru, ˇc´ısla. Kaˇzdý kl´ıˇc ma vlastn´ı konfiguraˇcn´ı reˇzim.

Router(config-keychain)# key id Router(config-keychain-key)#

Definov´an´ım kl´ıˇce prvek pˇreˇsel do konfiguraˇcn´ıho reˇzimu kl´ıˇce, kde je moˇzn´e definovat jeho vlastnosti. Hodnotu pomoc´ı pˇr´ıkazu key-string string a ˇcasy platnosti pomoc´ı dvou

pˇr´ıkazu accept-lifetime a send-lifetime.

Ukazka konfigurace:

Router(config)# key chain RIPhesla Router(config-keychain)# key 1

Router(config-keychain-key)# key-string rip

Router(config-keychain-key)# accept-lifetime 12:00:00 Jan 25 2007 infinite

2.5.2 RIP

Konfigurace RIPu se provád´ı v jednom z mód˚u konfiguraˇcn´ıho reˇzimu Cisco zaˇr´ızen´ı. K pˇrechodu do tohoto módu je nutné zadat pˇr´ıkaz router rip.

Spuˇstˇen´ı procesu

Router(config)# router rip Router(config-router)#

Pro spuˇstˇen´ı RIP procesu, je nutné zadat s´ıtˇe, které budou zahrnuty v aktualizac´ıch a zároveˇn do kterých se budou vys´ılat aktualizace. S´ıt’ se pˇridává pomoc´ı pˇr´ıkazu network x.x.x.x, kde x.x.x.x je adresa s´ıtˇe. Pokud je nutné odebrat nˇekterou ze s´ıt´ı, slouˇz´ı k tomu z negovaný pˇr´ıkaz no network x.x.x.x. Pˇridán´ı vˇsech okoln´ıch s´ıt´ı z obrázku2.2do procesu RIPu by vypadalo následovnˇe:

Router(config-router)# network 10.1.0.0 Router(config-router)# network 10.2.0.0 Router(config-router)# network 10.3.0.0 Router(config-router)# network 192.168.2.0

Nastaven´ı verze

Po pˇridán´ı s´ıt´ı uˇz RIP proces pos´ılá aktualizace verze 1 do zadaných s´ıt´ı a pˇrij´ımá aktuali-zace ve verzi 1 i 2. Pro zmˇenu globáln´ı verze je moˇzné zadat pˇr´ıkaz version ˇc´ıslo verze. Zmˇena verze ale mˇen´ı p˚uvodn´ı nastaven´ı a proces pˇrij´ımá pouze zprávy zadané verze. K základn´ımu nastaven´ı je moˇzné se vrátit zadan´ım pˇr´ıkazu no version

Router(config-router)# version 2 Router(config-router)# no version

Verzi je moˇzné mˇenit i na jednotlivých rozhran´ıch, kde je k dispozici detailnˇejˇs´ı konfigu-race. Je moˇzné specificky nastavit, které verze se maj´ı pˇrij´ımat i odes´ılat. Nejprve je vˇsak nutné pˇrej´ıt do konfiguraˇcn´ıho reˇzimu rozhran´ı. To se provede následuj´ıc´ım zp˚usobem:

(20)

Router(config-router)# exit

Router(config)# interface FastEthernet 0/0 Router(config-if)#

Pˇr´ıkaz interface název rozhran´ı ˇc´ıslo slotu/ˇc´ıslo portu zpˇr´ıstupnil konfiguraci 0. rozhran´ı FastEthernetu a kartˇe s poˇradovým ˇc´ıslem 0. Nyn´ı lze zadat pˇr´ıkazy pro zmˇenu vys´ılaných a pˇrij´ımaných verz´ı. K tomu slouˇz´ı pˇr´ıkazy ip rip send version ˇc´ıslo verze a ip rip receive version ˇc´ıslo verze, s t´ım ˇze mohou být uvedeny obˇe verze oddˇelené mezerou. Obrácené verze pˇr´ıkaz˚u vrac´ı zpˇet implicitn´ı nastaven´ı. Pˇr´ıklad demonstruje zp˚usob jakým by se zapsalo implicitn´ı nastaven´ı.

Router(config-if)# ip rip send version 1 Router(config-if)# ip rip receive version 1 2

Rozdˇelen´y horizont

Dalˇs´ı pomˇernˇe d˚uleˇzitý pˇr´ıkaz, který se konfiguruje v reˇzimu rozhran´ı je ip split-horizont, který aktivuje rozdˇelený horizont, naopak pˇr´ıkaz no ip split-horizont ho deaktivuje. Zda je rozdˇelený horizont implicitnˇe aktivn´ı/neaktivn´ı je dáno typem zapouzdˇren´ı na roz-hran´ı, pro s´ıtˇe typu Ethernet je aktivn´ı.

Router(config-if)# no ip split-horizont

Autentizace

Autentizace zajiˇst’uje, ˇze v rámci s´ıtˇe bude prvek dostávat smˇerovac´ı informace pouze od prvk˚u se kterými sd´ıl´ı kl´ıˇc. Zabraˇnuje se tak pˇr´ıpadným neautorizovaným zmˇenám do smˇerovac´ıch tabulek prvk˚u, které by mohly být vyuˇzity pˇri nˇejakém typu útoku.

Aby bylo moˇzné nakonfigurovat autentizaci pro RIP je nutné nejprve definovat kl´ıˇcenku a alespoˇn jeden kl´ıˇc. Zp˚usob vytvoˇren´ı byl jiˇz uveden. Po vytvoˇren´ı je nutné kl´ıˇcenku propojit s RIPem a rozhran´ım pomoci pˇr´ıkazu v konfiguraˇcn´ım módu rozhran´ı ip rip authentication key-chain keychain name.

RIP také nab´ız´ı podporu v´ıce typ˚u autentizaci. Heslo je bud’ v paketech zas´ılané v textové podobˇe nebo je nam´ısto nˇeho pouˇzit hash, vytvoˇrený ze zprávy a hesla, z d˚uvodu vˇetˇs´ı bezpeˇcnosti. Zp˚usob zabezpeˇcen´ı se konfiguruje pˇr´ıkazem ip rip authentication mode {text|mode}. Pokud nen´ı mód autentizace specifikován, uvaˇzuje se implicitnˇe textové podoba hesla.

Router(config-if)# ip rip authentication key-chain RIPkeys Router(config-if)# ip rip authentication mode md5

Podpora pro autentizaci je pouze u paketu RIPv2. Proto pokud pˇrijde smˇerovac´ı paket verze 1 na rozhran´ı, kde je zapnut´a autentizace, je automaticky zahozen.

Pasivn´ı rozhran´ı

Je nutné ale zm´ınit jeˇstˇe nˇekolik pˇr´ıkaz˚u, které se zadávaj´ı v konfiguraˇcn´ım reˇzimu RIPu. Pokud na pˇripojené s´ıt´ı nen´ı ˇzádný dalˇs´ı aktivn´ı prvek, který by potˇreboval aktualizace smˇerovac´ıch informac´ı, lze vypnout zas´ılán´ı zpráv na rozhran´ı pomoc´ı pˇr´ıkazu passive-interface název rozhran´ı ˇc´ıslo slotu/ˇc´ıslo portu. Zprávy ale budou nadále pˇrij´ımány. Pokud je m´ısto názvu rozhran´ı zadáno kl´ıˇcové slovo default jsou vˇsechna rozhran´ı nastavena jako

(21)

pasivn´ı. Jednotlivá rozhran´ı, která chceme m´ıt aktivn´ı poté aktivujeme pomoc´ı obráceného pˇr´ıkazu no passive-interface název rozhran´ı ˇc´ıslo slotu/ˇc´ıslo portu.

Router(config-router)# passive-interface FastEthernet 0/1

Automatick´a sumarizace

V kapitole o RIPu bylo zm´ınˇeno, ˇze RIPu pˇrevád´ı adresy s´ıt´ı na tˇr´ıdn´ı, pokud se pˇrekraˇcuje hranice mezi tˇr´ıdn´ımi s´ıtˇemi, a také ˇze u RIPv2 lze tuto funkci vypnout. K tomu slouˇz´ı funkce no auto-summary. RIPv2 poté propaguje s´ıtˇe s nezmˇenˇenými prefixy i pˇres tˇr´ıdn´ı hranice. Na verzi 1 tato funkce nemá vliv, ta sumarizuje vˇzdy.

Router(config-router)# no auto-summary

ˇ

Casovaˇce

Posledn´ı d˚uleˇzitá funkce se týká manipulace s ˇcasovaˇci. V p˚uvodn´ım nastaven´ı maj´ı ˇcasovaˇce tyto hodnoty:

• ˇcas aktualizac´ı - 30 sekund • ˇcas zneplatnˇen´ı - 180 sekund • ˇcas potlaˇcen´ı - 180 sekund • ˇcas vyplaven´ı - 240 sekund

Pˇr´ıkaz pro zmˇenu tˇechto hodnot je timers basic a z p v kde a, z, p, v jsou nové hodnoty jednotlivých ˇcas˚u. Pˇr´ıkazem no timers basic je obnoveno p˚uvodn´ı nastaven´ı. Podle doporuˇcen´ı by ˇcas zneplatnˇen´ı a potlaˇcen´ı mˇel být alespoˇn 3x vˇetˇs´ı neˇz ˇcas mezi aktualizacemi a ˇcas vyplaven´ı by mˇel alespoˇn stejnˇe dlouhý jako souˇcet ˇcas˚u aktualizaci a potlaˇcen´ı.

Router(config-router)# timers basic 20 120 120 160

Shrnut´ı

V kapitole byly pˇredstaveny jednotliv´e rodiny smˇerovac´ıch protokol˚u. D˚ukladnˇeji byl pˇredstaven smˇerovac´ı protokol RIP, protoˇze je pˇredmˇetem implementace, a zp˚usob jeho konfigurace na Cisco prvc´ıch.

(22)

Kapitola 3

Simul´

ator s´ıtˇ

e ns-2

´ Uvod

Implementovaný smˇerovac´ı protokol by mˇel být rozˇs´ıˇren´ım s´ıt’ového simulátoru. Je nutné se tedy seznámit s jeho strukturou, jakým zp˚usobem je ˇreˇseno smˇerován´ı, odes´ılán´ı paket˚u atd.

Pˇredstaven´ı simul´atoru

NS-2, network simulator, je diskrétn´ı simulátor zamˇeˇrený na výzkum s´ıt´ı. NS by mˇel nab´ızet znaˇcnou podporu pro simulaci TCP, UDP, smˇerován´ı a multicastové protokoly a to jak pro klasické drátové i bezdrátové s´ıtˇe. Jeho ned´ılnou souˇcást´ı je NAM, network animator, který slouˇz´ı ke zobrazen´ı výsledk˚u simulace v grafickém reˇzimu. Podporuje zmˇeny rozm´ıstˇen´ı prvk˚u, animován´ı jednotlivých paket˚u atd. D´ıky spojen´ı tˇechto dvou nástroj˚u, se m˚uˇzeme obˇcas setkat s názvem NSNAM.

Simulátor je napsán ve dvou jazyc´ıch, OTcl, coˇz je Tcl rozˇs´ıˇrené o objekty, a C++. C++ slouˇz´ı jako výpoˇcetn´ı ˇcást a OTcl jako uˇzivatelské rozhran´ı. Vzhledem k tomu, ˇze oba jazyky jsou objektové existuj´ı zde 2 hierarchie objekt˚u, které v nˇekterých m´ıstech koresponduj´ı mezi sebou.

Scénáˇr simulace se vytváˇr´ı ve formˇe OTcl skriptu. Je moˇzné ovlivˇnovat dobu simulace, chovan´ı jednotlivých objekt˚u, stav linek atd.

3.1 Z´

akladn´ı prvky

NS poskytuje základn´ı stavebn´ı kameny pro vytváˇren´ı topologii a to prvky, linky, které je spojuj´ı a procesy, které na nich bˇeˇz´ı.

Uzly

Uzel je základn´ı stavebn´ı prvek topologie, m˚uˇze reprezentovat kaˇzdý s´ıt’ový prvek. Pˇri vy-tvoˇren´ı je mu pˇridˇeleno jedineˇcné ID a adresa. Na uzly jsou navázány dalˇs´ı komponenty, klasifikátory a agenti.

Linky

Zajiˇst’uj´ı spojen´ı mezi jednotlivými uzly. Skládá se z komponent poskládaných do ˇretˇezu, kde kaˇzdá komponenta má jinou funkci, napˇr. fronta, zpoˇzdˇen´ı atd.

(23)

Obr´azek 3.1: Network animator Agenti

Agent reprezentuje procesy, které bˇeˇz´ı na jednotlivých uzlech. Moˇzná jeˇstˇe obecnˇeji se dá ˇr´ıct, ˇze se jedná o m´ısto kde vznikaj´ı, jsou zpracovávány a zanikaj´ı pakety. M˚uˇze zastupovat funkce r˚uzných aplikac´ı, smˇerovac´ıch i transportn´ıch protokol˚u

Pakety

Zprávy, které si mezi sebou vymˇeˇnuj´ı jednotlivý agenti. Specifikum ns-2 je, ˇze paket obsa-huje hlaviˇcky vˇsech nadefinovaných protokol˚u. Agent, kterému takový paket pˇrijde muˇze si rovnou pˇreˇc´ıst svoji hlaviˇcku, a na jej´ım základˇe zkoumat zda je to paket, který pˇrij´ımá. Agent tedy nemus´ı zkoumat bit po bitu daný paket.

Nevýhodou tohoto pˇr´ıstupu je, ˇze pakety jsou velké a pˇri velkých simulac´ıch zp˚usobuj´ı velké vyt´ıˇzen´ı zdroj˚u. Hlaviˇcky se daj´ı, ale selektivnˇe vypnout a ponechat si pouze ty, které pro konkretn´ı simulaci potˇrebujeme.

3.2 Smˇ

erovac´ı struktura

Smˇerovac´ı struktura v ns-2 se skládá z nˇekolika ˇcást´ı. Klasifikátor

Klasifikuje pakety na základˇe nejr˚uznˇejˇs´ıch informaci a poté pˇredává, na základˇe tˇechto informac´ı, pakety dál. Lze si ho pˇredstavit jako demultiplexor.

Uzel obsahuje vˇetˇsinou minimálnˇe 2, jeden který klasifikuje na základˇe adresy a pln´ı v podstatˇe funkci smˇerovac´ı tabulky, a druhý, který klasifikuje podle c´ılového portu, pokud

(24)

Obr´azek 3.2: Smˇerovac´ı struktura ns-2

je paket urˇcen pro tento uzel. Krom tˇechto 2 m˚uˇze být napˇr´ıklad pˇr´ıtomen klasifikátor multicastových paket˚u. Klasifikátory poté tvoˇr´ı stromovou strukuru.

rtModule - smˇerovac´ı modul

Smˇerovac´ı modul ˇr´ıd´ı klasifikátor, a to jak jeho operace, pˇridávan´ı a odeb´ırán´ı cest, tak jeho vytváˇren´ı a instalaci do uzlu. Uzel m˚uˇze obsahovat v´ıce modul˚u, stejnˇe jako klasifikátoru. Ty potom vytváˇrej´ı ˇretˇez, po kterém se propaguj´ı informace ke vˇsem smˇerovac´ım modul˚um.

Smˇerovac´ı protokoly

Jedn´a se vlastnˇe o agenty, kteˇr´ı si vymˇeˇnuj´ı zpr´avy s ostatn´ımi instancemi protokolu. rtObject

Dává dohromady databáze smˇerovac´ıch protokol˚u a vytváˇr´ı z nich jedinou smˇerovac´ı ta-bulku. Upozorn´ı poté uzel, ˇze si má zmˇenit cestu k urˇcitému c´ıli. Uzel poté upozornˇen´ı poˇsle poté zprávu na ˇretˇez smˇerovac´ıch modul˚u a ty zmˇen´ı informace v klasifikátoru.

RouteLogic

(25)

3.3 Dostupn´

e unicastov´

e smˇ

erovac´ı protokoly

Static

Vyuˇz´ıvá Dijkstr˚uv algoritmus, cesty k jednotlivým uzl˚um se vypoˇc´ıtaj´ı pˇri spuˇstˇen´ı simulace a kaˇzdý uzel si je pˇridá do klasifikátoru.

Session

Pracuje na podobném principu jako Statické smˇerován´ı, ale s t´ım rozd´ılem, ˇze pˇri kaˇzdé zmˇenˇe v topologii si uzly zmˇen´ı cesty k jednotlivým uzl˚um. ˇS´ıˇren´ı této informace nen´ı nijak zpracováno, pˇredpokládá se, ˇze vˇsechny uzly zaznamenaj´ı jakoukoliv zmˇenu v topologii. DV

Forma distance vektor protokolu. Uzly si pravidelnˇe zas´ılaj´ı svoje smˇerovac´ı tabulky. Zmˇeny se v topologi´ı neˇs´ıˇr´ı okamˇzitˇe, jednotlivé uzly si mus´ı tyto zmˇeny pˇreposlat. Protokol, ale zjednoduˇsuje pos´ılán´ı zpráv mezi jednotlivými subjekty. Existuje ‘globáln´ı’ databáze zpráv, a uzly si mezi sebou pouze vymˇeˇnuj´ı informace o tom, kterou zprávu si máji vyzvednout.

3.4 Pˇ

r´ıklad skriptu

V pˇr´ıkladu je uvedena jednoduchá kruhová topologie, se zapnutým distance vektor smˇerován´ım. Prvn´ı ˇrádek vytvoˇr´ı novou instanci simulátoru. Ve druhém a tˇret´ım je urˇceno, které výstupy ze simulace se budou ukládat a kam.

set ns [new Simulator] #vytvoreni simulatoru

set nf [open DV.nam w] #otevreni trace souboru pro NAM

$ns namtrace-all $nf

Jak jiˇz název procedury napov´ıdá, spouˇst´ı se na konci simulace a jej´ım úkolem je spustit NAM s novˇe z´ıskanými výsledky.

proc finish {} { global ns nf $ns flush-trace close $nf

exec nam DV.nam & exit 0

}

Následuje vytvoˇren´ı uzl˚u, linek mezi nimi a agent˚u. Poˇrad´ı parametr˚u pˇri vytváˇren´ı linek je rychlost, zpoˇzdˇen´ı a typ fronty. Null agent pouze zahazuje veˇskeré pakety, které mu pˇrijdou.

#Vytvoreni uzlu

for {set i 0} {$i < 5} {incr i} { set n($i) [$ns node] }

(26)

#Vytvoreni linek $ns duplex-link $n(0) $n(1) 1Mb 10ms DropTail $ns duplex-link $n(1) $n(2) 1Mb 10ms DropTail $ns duplex-link $n(2) $n(3) 1Mb 10ms DropTail $ns duplex-link $n(3) $n(4) 1Mb 10ms DropTail $ns duplex-link $n(4) $n(0) 1Mb 10ms DropTail #Vytvoreni UDP agentu

for {set i 0} {$i < 5} {incr i} { set udp($i) [new Agent/UDP] $ns attach-agent $n($i) $udp($i) }

#Vytvoreni Null agentu

for {set i 0} {$i < 5} {incr i} { set null($i) [new Agent/Null] $ns attach-agent $n($i) $null($i) }

#Pripojeni aplikace k agentovi

set cbr(13) [new Application/Traffic/CBR] $cbr(13) set packetSize_ 500

$cbr(13) set interval_ 0.005 $cbr(13) attach-agent $udp(1) #Propojeni dvou agentu

$ns connect $udp(1) $null(3)

#Aktivace distance vektor smerovani pro vsechny uzly $ns rtproto DV

Posledn´ı blok pˇr´ıkaz˚u definuje chován´ı simulace. Kdy se maj´ı zaˇc´ıt pos´ılat data z jed-notlivych aplikaci, kdy maj´ı být linky neaktivn´ı a kdy ma simulace skonˇcit atd. Nakonec se celá simulace pˇr´ıkazem run instance simulátoru spust´ı.

#zacate behu aplikace

$ns at 0.5 "$cbr(13) start" $ns at 4.5 "$cbr(13) stop" #zmena stavu linky

$ns at 1.5 down $n(1) $n(2) $ns at 2.5 up $n(1) $n(2) #delka simulace $ns at 5.0 "finish" #spusteni simulace $ns run

(27)

3.5 Nedostatky v˚

uˇ

ci IPv4

Ns pˇr´ıliˇs nekoresponduje s IPv4 prostˇred´ım. Následuje výˇcet nedostatk˚u, které má ns-2 bez proveden´ı jakýchkoliv zmˇen:

• Pouze uzly maj´ı adresy, rozhran´ı jsou neadresovateln´a.

• Pakety vcházej´ı do uzly pouze 1 vstupem, rozhran´ı lze rozliˇsit pouze výstupu. • Rozhran´ı na výstupu má formu pouhé linky.

• Smˇerován´ı neprob´ıhá nad s´ıtˇemi, ale na uzly. Ve smˇerovac´ı tabulce jsou uvedeny uzly a cesty k nim, nam´ısto s´ıt´ı. Toto také plyne z toho ˇze pouze uzly mohou m´ıt adresu Shrnut´ı

V této kapitole byl pˇredstaven simulátor s´ıtˇe ns-2 a byli adresovány jeho nedostatky v˚uˇci IPv4 prostˇred´ı, které budou muset být pˇred implementaci napraveny.

(28)

Kapitola 4

N´

avrh a implementace

´ Uvod

V této kapitole jsou uvedeny poˇzadavky na aplikaci spoleˇcnˇe s návrhem moˇzné implemen-tace. Dále je tu popsán zp˚usob implementace jednotlivých vlastnost´ı.

4.1 Koncept rozˇ

s´ıˇ

ren´ı

N´avrh

Zámˇerem této práce je rozˇs´ıˇren´ı stávaj´ıc´ıch moˇznost´ı ns-2 a ne úplná zmˇena ns-2 a proto by mˇela být implementace koncipována tak, aby ji bylo moˇzné selektivnˇe aktivovat ˇci de-aktivovat. A v pˇr´ıpadˇe, ˇze bude deaktivována nijak neovlivˇnovala bˇeh simulace.

Implementace

Soubor: ns-lib.tcl, ns-route.tcl

Aby byla dodrˇzena podm´ınka rozˇs´ıˇren´ı, tedy ˇze implementace nebude ovlivˇnovat p˚uvodn´ı strukturu ns-2, byla zavedena promˇenná simulátoru IPv4 . Na základˇe jeho hodnoty se akti-vuje nová IPv4 struktura nebo z˚ustane p˚uvodn´ı. Aktivace nové struktury se provád´ı volán´ım metody simulátoru IPv4 s parametry ON. Metoda deaktivuje základn´ı, Base, smˇerovac´ı mo-dul a aktivuje nový IPv4 modul. Pro zjiˇstˇen´ı zda je rozˇs´ıˇren´ı aktivováno slouˇz´ı metoda simuáltor IPv4?, která vrac´ı hodnotu ON, pokud je rozˇs´ıˇren´ı aktivn´ı.

Pˇr´ıklad zad´an´ı do skriptu:

$ns IPv4 ON

Bylo nutné zasáhnout do stávaj´ıc´ıch kód˚u ns-2 a zmˇenit chován´ı smˇerovac´ı logiky, Rou-teLogic, tak aby pˇri spuˇstˇen´ı IPv4 rozˇs´ıˇren´ı vytvoˇrila instance nových rtObject˚u na vˇsech uzlech.

4.2 Podp˚

urn´

e prvky a struktury

Protoˇze ns-2 nemá pro IPv4 prostˇred´ı dostateˇcnou podporu, bylo nutné implementovat nové prvky smˇerovac´ı struktury, které jiˇz IPv4 podporuj´ı.

(29)

4.2.1 IPv4 adresy

N´avrh

Uzly by mˇeli být adresovatelné v´ıce adresami, ne pouze jednou jako tomu je v p˚uvodn´ı ns-2. Uzly by mˇeli m´ıt strukturu pro uchováván´ı adres rozhran´ı a také by mˇeli pˇrij´ımat pakety, které jsou urˇceny pro tyto adresy. Stejnˇe tak by mˇeli podporovat pˇrij´ımán´ı broadcastových zpráv.

Implementace

Soubor: ns-nodeIPv4.tcl

Adresy jednotlivých rozhran´ı jsou uloˇzeny v asociativn´ım poli, kde je jako kl´ıˇc pouˇz´ıt sou-sedn´ı uzel. Nevýhodou tohoto pˇr´ıstupu je moˇznost m´ıt pouze jedno rozhran´ı k jakémukoliv uzlu, ale vzhledem k uloˇzen´ı linek v samotném simulátoru, pomoc´ı id poˇcáteˇcn´ıho a kon-cového uzlu, neumoˇzˇnuje ani samotná ns-2 podporu pro v´ıce rozhran´ı mezi uzly. Výhodou je snadná orientace v linkách a pˇri vytváˇren´ı skript˚u.

Po zadáni adresy rozhran´ı je záznam pˇreveden na tvar adresa/maska a uloˇzen do asoci-ativn´ıho pole. Nav´ıc je pˇridána informace o s´ıt´ı na které rozhran´ı leˇz´ı, z d˚uvodu ˇze se tato informace ˇcasto vyuˇz´ıvá. Odpadá tak nutnost ji znovu poˇc´ıtat pˇri kaˇzdém jej´ım pouˇzit´ı.

4.2.2 Klasifik´ator

N´avrh

Klasifikátor s podporou IPv4 mus´ı, pokud mu pˇrijde paket, ze své smˇerovac´ı tabulky vybrat s´ıt’, ve které se nacház´ı uzel, pro který je paket urˇcen. Klasifikátor mus´ı udrˇzovat cesty k jednotlivým s´ıt´ım, ne uzl˚um jako to je v implicitn´ım klasifikátoru v ns-2. Dále by mˇel vyhledávat ve své smˇerovac´ı tabulce od nejspecifiˇctˇejˇs´ıch záznamu, záznamu s nejdelˇs´ım prefixem.

Implicitn´ı klasifikátor v ns-2 mˇel jeˇstˇe jeden nedostatek, pokud nenaˇsel c´ıl pro daný paket, volal proceduru no-route, která zastavila simulaci a vypsala na standardn´ı výstup zprávu o tom, ˇze daná cesta neexistuje. Toto chován´ı ale nen´ı vhodné pro IPv4 s´ıtˇe a je nutné ho odstranit. Zaˇr´ızen´ı v reálných s´ıt´ıch by v tomto pˇr´ıpadˇe odesilateli zaslalo zprávu o tom, ˇze daná s´ıt’ nen´ı k dispozici.

Implementace

Soubory: classifier-ipv4.{h, cc}, classifier-port.{h, cc}

Klasifikátor, který smˇeruje na základˇe IP adres do s´ıt´ı byl jiˇz implementován pˇri vytváˇren´ı modelu BGP pro tento simulátor. Autory tohoto modelu a i klasifikátoru jsou Rob Ballatyne a Tony Dongliang Feng. Klasifikátor vˇsak nepodporuje rozes´ılán´ı paketu v´ıce c´ıl˚um naráz, multicast a broadcast, ale tuto vlastnost nebude potˇreba implementovat. Klasifikátor se ale choval podobnˇe jako implicitn´ı klasifikátor v pˇr´ıpadˇe, ˇze pˇrijal paket jehoˇz c´ılovou adresu, nebo alespoˇn s´ıt’ do které spadá, nemˇel ve smˇerovac´ı tabulce. Tuto vlastnost bylo tˇreba zmˇenit.

Pokud do klasifikátoru pˇrijde paket je na nˇej volána metoda classify jej´ıˇz návratová hodnota urˇcuje na který slot v klasifikátoru se daný paket odeˇsle. Jakým zp˚usobem se hodnota tohoto slotu z´ıská je ˇcistˇe na autorovi klasifikátoru.

(30)

Metoda classify je volána z metody find, která na základˇe slotu vrac´ı objekt na který se má paket poslat dále. Pokud vˇsak metoda classify vrátila hodnotu, která znaˇcila, ˇze ˇ

zádný slot nebyl nalezen, byla volána právˇe ona zmiˇnovaná funkce no-route. Tato vlastnost vˇsak neodpov´ıdala návrhu, proto byla zmˇenˇena metoda find zdˇedˇená z rodiˇcovské tˇr´ıdy Classifier. A to u obou pouˇz´ıvaných klasifikátor˚u, jak adres tak port˚u.

4.2.3 Smˇerovac´ı modul

N´avrh

Jak jiˇz bylo zm´ınˇeno, úlohou smˇerovac´ıho modulu je ˇr´ızen´ı klasifikátoru. Mˇel by proto poskytovat rozhran´ı uzlu pro pˇridáván´ı cest do jednotlivých s´ıt´ıch a zároveˇn ˇr´ıdit správu klasifikátoru.

Implementace

Soubory: rtmodule.{h,cc}

Vzheldem k tomu, ˇze klasifikátor od Ballatyna a Fenga mˇel k sobˇe jiˇz vytvoˇrený smˇerovac´ı modul, nebyl implementován nový modul, pouze byl pouˇzitý, ten jiˇz naimplementovaný. V dalˇs´ım textu vˇsak bude popsán zp˚usob jeho intergrace.

Definice nov´eho smˇerovac´ıho modulu - rtmodule.h:

class IPv4RoutingModule : public RoutingModule { public:

IPv4RoutingModule() : RoutingModule() {}

virtual const char* module_name() const {return "IPv4";} virtual int command (int argc, const char* const * argv); protected:

IPv4Classifier *classifier_; };

Je zde definováno zaˇrazen´ı do hieararchie tˇr´ıd a rozhran´ı s OTcl, pomoc´ı funkce command, jej´ı podrobnˇejˇs´ı rozbor je dále v textu aˇz pozdˇeji. Protoˇze pouˇz´ıváme jinou tˇr´ıdu klasi-fikátoru je nutné zde tuto skuteˇcnost uvést. Vzhledem k tomu, ˇze je tato tˇr´ıda implemen-tována v obou jazyc´ıch ns-2, je nutné tyto dvˇe prostˇred´ı propojit. V následuj´ıc´ım bloku kódu v souboru rtmodule.cc definujeme, ˇze pokud se v OTcl vytvoˇr´ı objekt tˇr´ıdy RtModule/IPv4 bude vytvoˇren odpov´ıdaj´ıc´ı objekt tˇr´ıdy IPv4RoutingModule, pomoc´ı volán´ı funkce create.

Propojen´ı OTcl/C++ - rtmodule.h:

static class IPv4RoutingModuleClass : public TclClass { public:

IPv4RoutingModuleClass() : TclClass("RtModule/IPv4") {} TclObject* create(int, const char*const*) {

return ( new IPv4RoutingModule ); }

} class_ipv4_module;

V témˇze souboru je jeˇstˇe potˇreba implementovat funkci command, nejsou nutné zvláˇstn´ı funkce, takˇze ji m˚uˇzeme implementovat podle vzoru BaseRoutingModule.

(31)

OTcl

Soubor: ns-rtModuleIPv4.tcl

Ostatn´ı souˇcásti ns-2 vyuˇz´ıvaj´ı nˇekolik metod smˇerovac´ıho modulu skrz Otcl. Metodu register, která definuje, které klasifikátory se maj´ı pˇridat do uzlu, pokud je daný mo-dul aktivn´ı. Uzly potˇrebuj´ı rozhran´ı pro pˇridáván´ı a odeb´ırán´ı cest z klasifikátoru, toto rozhran´ı je zajiˇstˇeno metodami add-route a delete-route. V tˇechto metodách je poté jiˇz voláno rozhran´ı klasifikátoru.

4.2.4 Nov´y rtObject

N´avrh

P˚uvodn´ı rtObject byl implementován ˇcistˇe v OTcl a skládal z nˇekolika asociativn´ıch pol´ı, kde jako kl´ıˇc byli pouˇzity jednotlivé uzly. Toto ˇreˇsen´ı bylo moˇzné vzhledem k tomu, ˇze poˇcet uzl˚u byl pˇredem znám. Implementac´ı IPv4 prostˇred´ı a smˇerován´ı na bázi s´ıt´ı se stalo toto ˇreˇsen´ı nepouˇzitelným. Musela by se udrˇzovat nˇejaká centráln´ı databáze vˇsech pouˇzitých s´ıt´ı, ke které by mˇeli pˇr´ıstup vˇsechny prvky.

Dalˇs´ı podstatnou vˇec´ı bylo, ˇze vˇsechny smˇerovac´ı protokoly museli m´ıt jednotnou struk-turu asociativn´ıch pol´ı v OTcl, ze kterých si rtObject bral informace cestách k r˚uzným uzl˚um. Pokud si tedy smˇerovac´ı protokol udrˇzoval svoji smˇerovac´ı tabulku v C++, musel m´ıt nutnˇe duplicitn´ı v OTcl, kv˚uli rtObjectu.

Také chybˇela moˇznost ovlivnit, ne který port bude smˇerovac´ı protokol pˇripojen. V p˚uvodn´ı implementaci si smˇerovac´ı protokoly museli nejprve zjistit na kterém portu sou-sedského uzlu bˇeˇz´ı instance tohoto protokolu, protoˇze bylo moˇzné, ˇze jednotliv´ı agenti smˇerovac´ıch protokol˚u byli na r˚uzných portech.

Nový rtObject by mˇel poskytnout podporu pro smˇerován´ı na základˇe s´ıt´ı, a také od-stranit nutnost m´ıt pevnˇe specifikovanou smˇerovac´ı tabulku v OTcl pro smˇerovac´ı proto-koly. Jako vhodný model se zdál být model typu dotaz/odpovˇed, kdy smˇerovac´ı protokoly informuj´ı rtObject o zmˇenách ve svých smˇerovac´ıch tabulkách. On si na základˇe tˇechto upozornˇen´ı mˇen´ı vlastn´ı smˇerovac´ı tabulku a informuje uzel, aby si zmˇenil informace v kla-sifikátoru. Pokud je nutné smazat cestu do nˇekteré s´ıtˇe, mˇel by se zeptat ostatn´ıch protokol˚u zda nemaj´ı cestu do dané s´ıtˇe. Mˇel by také umˇet pˇripojit smˇerovac´ı protokol na konkrétn´ı port.

Z d˚uvodu podobnosti s výpisy z Cisco zaˇr´ızen´ı by bylo vhodné pˇridat také moˇznost specifikovat identifikátor smˇerovac´ıho protokolu, napˇr. C pro pˇripojené s´ıtˇe, R pro RIP atd. Implementace

Soubor: ns-rtObjectIPv4.tcl

Nový model rtObjectu je zaloˇzen na komunikaci formou dotaz/odpovˇed’ mezi rtObjectem a smˇerovac´ımi protokoly, kde odpovˇedi od smˇerovac´ıch protokol˚u nemus´ı být vˇzdy vyˇzádané. Smˇerovac´ı protokoly pomoc´ı odpovˇedi informuj´ı rtObject o zmˇenách svých databáz´ı. Vzhle-dem k tomu, ˇze rtObject nepracuje s pakety, ale pouze se smˇerovac´ımi informacemi, nebyl d˚uvod implementovat jeho ˇcást v C++, která je ve vˇetˇsinˇe pˇr´ıpadu urˇcena pro zpracováván´ı jednotlivých paket˚u.

S´ıtˇe jsou uloˇzeny v asociativn´ım poli kde jako kl´ıˇc slouˇz´ı s´ıt’/prefix. V dalˇs´ıch pol´ıch jsou uloˇzeny pot´e informace o dalˇs´ım skoku, preference protokolu a jeho metrika.

(32)

Metoda smˇerovac´ıho protokolu, která se pouˇz´ıvá jako dotaz na cestu k s´ıt´ı a kterou mus´ı implementovat kaˇzdý smˇerovac´ı protokol, má tvar volan´ı Protocol notify-about-route s´ıt’ prefix. Jako odpovˇed’ smˇerovac´ıch protokol˚u rtObjectu se pouˇz´ıvá stejnojmenná me-toda, ale v tomto pˇr´ıpadˇe se jedná o metodu rtObjectu. Jej´ı parametry jsou vˇsak rozˇs´ıˇrené.

Jej´ı volán´ı má tvar rtObject notify-about-route identifikátor s´ıt’ prefix adresa dalˇs´ıho

skoku preference metrika. Pokud je v odpovˇedi hodnota metriku -1 je to sign´al pro

sma-zan´ı cesty do urˇcen´e s´ıtˇe.

Dalˇs´ı metodou, kterou mus´ı implementovat smˇerovac´ı protokoly je Protocol clear-route s´ıt’ prefix, kterou ˇzádá rtObject o smazan´ı urˇcité cesty ze smˇerovac´ı tabulky. Pokud je hodnota parametru s´ıt’ rovna all, je to ˇzádost o vymazán´ı celé databáze. O smazan´ı jiˇz nemus´ı být rtObject jiˇz informován.

Metoda intf-changed z˚ustala v podstatˇe nezmˇenˇena, pouze v n´ı nen´ı explicitnˇe voláno compute-routes vˇsech protokol˚u. Nové protokoly by mˇeli reagovat na tuto zmˇenu, a ne na volán´ı funkce compute-routes

Implementace musela obsahovat funkce, které by slouˇzili jako rozhran´ı pro ostatn´ı kom-ponenty simulátoru. Ve vˇetˇsinˇe pˇr´ıpad˚u se shoduj´ı se starým rtObjectem, pouze metoda add-proto byla rozˇs´ıˇrena o moˇznost pˇripojit smˇerovac´ı protokol na konkrétn´ı port. Pro ´

uplnou podporu pˇripojen´ı agenta na konkretn´ı port v demultiplexoru port˚u bylo nutné jeˇstˇe zmˇenit metodu simulátoru attach-agent, definovanou v ns-lib.tcl. Metodˇe byl pˇridán volitelný parametr, který urˇcuje, na který port má být agent pˇripojen. Nen´ı-li jeho hodnota specifikována, agent se pˇripoj´ı na prvn´ı moˇzný port.

Pokud se smaˇze cesta do nˇekteré s´ıtˇe rtObject poˇsle dotaz vˇsem protokol˚um na novou cestu do této s´ıtˇe. Je nutné si, ale uvˇedomit ˇze toto nastává okamˇzitˇe po obdrˇzen´ı zprávy o zmˇenˇe, a ˇze rtObject se dotazuje vˇsech smˇerovac´ıch protokol˚u, i toho který zprávu o smazan´ı cesty odeslal. M˚uˇze totiˇz nastat situace, ˇze smˇerovac´ı protokol má tuto cestu jeˇstˇe v databázi a pˇri dotazu na tuto s´ıt’ odpov´ı právˇe mazanou cestou. To vede k nejr˚uznˇejˇs´ım problém˚um.

Pˇrehled funkc´ı, které je nutné implementovat do nových smˇerovac´ıch protokol˚u: • intf-changed

• notify-about-route • clear-route

4.2.5 Pˇripojen´e s´ıtˇe

N´avrh

Kaˇzdý uzel by mˇel znát s´ıtˇe, které má k sobˇe pˇr´ımo pˇripojené. V p˚uvodn´ım ns-2 znal uzel svoje sousedské uzly. To bylo realizováno ‘smˇerovac´ım’ protokolem Direct.

Podobný princip je nutné zaˇr´ıdit i pro pˇr´ımo pˇripojené s´ıtˇe a proto je nutné implemen-tovat modifikaci smˇerovac´ıho protokolu Direct. Tento protokol by mˇel umˇet nejenom pˇridat pˇripojené s´ıtˇe do klasifikátoru, ale také pˇridat adresy rozhran´ı, tak aby pakety, které jsou smˇerovány na tyto adresy byly pˇredány klasifikátoru port˚u. Dále by mˇel pˇridat i broadcas-tové adresy jednotlivých s´ıt´ı.

Implementace

(33)

Správu pˇripojených s´ıt´ı zajiˇst’uje nová verze protokolu Direct s názvem DirectIPv4. Instance tohoto ‘smˇerovac´ıho’ protokolu vzniká spoleˇcnˇe se vznikem rtObjectu, aby bylo zajiˇstˇeno, ˇze vˇsechny uzly budou znát alespoˇn pˇripojené s´ıtˇe. Pˇri inicializaci také podle návrhu pˇr´ıdává broadcastové adresy a adresy rozhran´ı do klasifikátoru, aby uzel pˇrij´ımal pakety jej´ıˇz c´ılová adresa je rovna adrese rozhran´ı.

Pracuje na jednoduchém principu, kde na základˇe stavu rozhran´ı urˇcuje zda daná s´ıt’ má být pˇridána, pˇr´ıpadnˇe odebrána z rtObjectu. O adresách rozhran´ı pˇredpokládáme ˇze se nemˇen´ı. Na clear-route nereaguje, pˇripojené s´ıtˇe jsou známy i pˇri smazán´ı smˇerovac´ıch databáz´ı.

Protokol Direct je implementován pouze v OTcl, protoˇze nevyuˇz´ıvá zas´ılán´ı paket˚u. Implementovány jsou vˇsechny funkce vyˇzadované pro interakci s rtObjectem.

4.2.6 Statick´e smˇerov´an´ı

N´avrh

Statické smˇerován´ı je oproti RIPu jednoduˇs´ı. Jej´ı instance si nevymˇeˇnuj´ı pakety a pouze uˇzivatel m˚uˇze zmˇenit jeho cesty k s´ıt´ım. Pˇridán´ı statické cesty k s´ıt´ı by mˇelo být co nej-podobnˇejˇs´ı pˇr´ıkazu Cisco IOS ip route x.x.x.x m.m.m.m n.n.n.n p, kde x znaˇc´ı adresu s´ıtˇe, m jej´ı masku, n dalˇs´ı skok ve smˇeru k s´ıt´ı a p volitelnˇe preferenci. Protokol by mˇe pruˇznˇe reagovat na zmˇeny linek vedouc´ı k uzlu a nepropagovat cesty k s´ıt´ım skrz linky, které jsou nedostupné.

Implementace

Soubor: ns-rtProtoStaticIPv4.tcl

Podobnˇe jako Direct ani instance statického smˇerován´ı si mezi sebou nevymˇeˇnuj´ı zprávy o stavu smˇerovac´ıch tabulek a proto je moˇzné i statické smˇerován´ı implementovat jako OTcl tˇr´ıdu. Mus´ı implementovat, stejnˇe jako Direct a dalˇs´ı smˇerovac´ı protokoly, rozhran´ı s

rtObjectem, konkr´etnˇe funkce notify-about-route, clear-route a intf-changed.

Databáze cest se dá implementovat pomoc´ı asociativn´ıch pol´ı s vhodnˇe zvoleným kl´ıˇcem. Kl´ıˇc v podobnˇe s´ıt’/prefix nen´ı bohuˇzel dostateˇcný, protoˇze u statických cest je bˇeˇznou prax´ı m´ıt 2 do stejné s´ıtˇe, ale s r˚uznou preferenc´ı. Pokud linka ve smˇeru s cesty s niˇzˇs´ı preferenc´ı nen´ı funkˇcn´ı, zvol´ı se druhá s preferenc´ı vyˇsˇs´ı.

Kl´ıˇc je tedy nutn´e zvolit jako kombinaci s´ıtˇe prefixu a adresy dalˇs´ıho skoku.

Protokol mus´ı sledovat zmˇeny rozhran´ı, aby protokol oznamoval rtObjectu správné cesty skrz aktivn´ı rozhran´ı, ne skrz ty, které jsou nefunkˇcn´ı. Na metodu clear-route protokol nereaguje, staticky pˇridané cesty, podobnˇe jako pˇr´ımo pˇripojené se ze smˇerovac´ı tabulky nemaˇzou, pouze dynamický nauˇcené cesty.

Pˇrid´an´ı smˇerovac´ıho protokolu do simulace

Na rozd´ıl od protokolu Direct, který je pˇridán vˇzdy, statické smˇerován´ı je moˇzné pˇridat selektivnˇe na urˇcité uzly pomoc´ı pˇr´ıkazu:

$ns rtproto StaticIPv4 $n(1) $n(2)

(34)

Pojmenován´ı je zvoleno tak aby se protokol odliˇsil od p˚uvodn´ıho protokolu Static. Kv˚uli zp˚usobu pˇridán´ı protokolu, skrz volán´ı funkce rtproto, jsou jeho instance vytvoˇreny aˇz po spuˇstˇen´ı simulace a i jeho konfigurace je moˇzná aˇz v simulaˇcn´ım ˇcase.

4.3 Smˇ

erovac´ı protokol RIP

N´avrh

Model smˇerovac´ıho protokolu by mˇel odpov´ıdat funkˇcnˇe RFC dokument˚um [2], [4] a také chován´ı protokolu na Cisco prvc´ıch. Implementace nemus´ı odraˇzet chován´ı úplnˇe pˇresnˇe, z d˚uvodu ˇze se jedná o model protokolu, z toho d˚uvodu je moˇzné si dovolit nˇekterá zjed-noduˇsen´ı.

Implementace

soubory: rtProtoRIP.h, cc, rtProtoRIP packets.h

Implementace RIPu je naps´ana jak v OTcl tak v C++, z d˚uvodu manipulace s pakety. Z

toho plyne, podobnˇe jako v pˇr´ıpade smˇerovac´ıho modulu, nutnost tyto 2 oddˇelené ˇcásti pro-pojit. Také bylo nutné nadefinovat novou hlaviˇcku paketu a zpˇr´ıstupnit nastaven´ı procesu uˇzivatel˚um.

4.3.1 Nov´y typ paket˚u

N´avrh

Aby spolu mohly instance protokolu komunikovat je nutné nadefinovat formát zprávy, RIP hlaviˇcku paketu. Z tabulek2.3 a 2.4je patrné, ˇze vˇetˇsinu pol´ı maj´ı protokoly spoleˇcné. Je tedy moˇzné nadefinovat pouze 1 hlaviˇcku, kterou budou vyuˇz´ıvat obˇe verze protokolu. Pole verze protokolu poskytuje dostateˇcné rozliˇsen´ı jednotlivých verz´ı. Specifická pole verze 2, m˚uˇze verze 1 ignorovat.

Implementace

Obsah paketu je stejný jako obsah paketu RIPv1 obohacený o poloˇzku RIPv2, která urˇcuje délku prefixu dané s´ıtˇe. Oproti plné RIPv2 hlaviˇcce chyb´ı poloˇzka TAG, z d˚uvodu, ˇze v souˇcasné dobˇe nen´ı redistribuce z jiných protokol˚u implementována, ˇzádné dalˇs´ı nejsou zat´ım k dispozici. Také chyb´ı pole dalˇs´ıho skoku, implicitnˇe se vˇzdy vyuˇz´ıvá zdrojové adresy paketu. Zmˇenou oproti tradiˇcn´ı struktuˇre RIP paket˚u, kde je prvn´ı záznam vyuˇzit pro autentizaˇcn´ı údaje, je vytvoˇren´ı samostatné promˇenné, která tyto údaje obsahuje.

Struktura paketu - rtProtoRIP packets.h:

int command_; int version_;

const char * authentication_; RIP_route_list routes_;

Promˇená routes zastupuje záznamy jednotlivých s´ıt´ı v paketu. Kaˇzdý záznam má následuj´ıc´ı strukturu, která odráˇz´ı strukturu záznamu RIPu. Jediným rozd´ılem je ukazatel na dalˇs´ı záznam.