Směrovací protokoly používané v České Republice

Bankovní institut vysoká škola Praha Katedra matematiky, statistiky a informačních technologií

Směrovací protokoly používané v České Republice Diplomová práce

Autor:

Dalibor Nauš Informační technologie a management,

Vedoucí práce:

Praha

Ing. Vladimír Beneš

Duben, 2013

Prohlášení Prohlašuji, že jsem diplomovou práci zpracoval samostatně a v seznamu uvedl veškerou použitou literaturu. Svým podpisem stvrzuji, že odevzdaná elektronická podoba práce je identická s její tištěnou verzí, a jsem seznámen se skutečností, že se práce bude archivovat v knihovně BIVŠ a dále bude zpřístupněna třetím osobám prostřednictvím interní databáze elektronických vysokoškolských prací.

V Praze, dne 20.4.2013

Bc. Dalibor Nauš

Poděkování Děkuji Ing. Vladimíru Benešovi za odborné vedení mé práce a za cenné rady, které mně poskytl.

Anotace Diplomová práce „Směrovací protokoly používané v České Republice“ je rozdělena na dvě části, praktickou a teoretickou. V praktické části jsou rozebrány výsledky šetření používaných směrovacích protokolů v České Republice, které přináší procentuální i komentovaný přehled rozložení využití směrovacích protokolů z různých úhlů pohledu. Teoretická část se věnuje rozšířenému popisu a charakteristice dvou směrovacích protokolů nejčastěji používaných v České Republice. Diplomová práce navazuje a rozšiřuje moji předchozí bakalářskou práci „Směrování v lokálních a globálních sítích“. Klíčová slova: směrovací protokoly, OSPF, BGP.

Annotation The graduation thesis “Routing protocols used in Czech Republic” is divided into practical and theoretical part. The first practical part is devoted to analysis of findings from research the usage of routings protocols in the Czech Republic, which provides percentage as well as an annotated overview of the layout using routing protocols from different perspectives. The second theoretical part of thesis is devoted to expanded description and characteristic of two routing protocols most often used in the Czech Republic. The graduation thesis is referring and extending to my bachelor thesis “Routing in local and global networks”. Key words: routing protocols, OSPF, BGP.

Obsah Úvod práce ....................................................................................................................................................... 6 Zvolené metody zpracování ............................................................................................................................ 7 1.

Používané směrovací protokoly v ČR....................................................................................................... 8

1.1.

Základní předpoklady šetření ............................................................................................................... 8

1.2.

Zvolená metodika šetření ..................................................................................................................... 9

1.3.

Vlastní šetření..................................................................................................................................... 10

1.4.

Interpretace výsledků šetření .............................................................................................................. 12

1.4.1.

Typy společností ............................................................................................................................ 12

1.4.2.

Velikost společností a jejich rozložení ........................................................................................... 14

1.4.3.

Využití interních směrovacích protokolů ....................................................................................... 16

1.4.4.

Využití externích směrovacích protokolů ...................................................................................... 20

1.4.5.

Změny používaných směrovacích protokolů v čase....................................................................... 22

1.4.6.

Zájem o výsledky šetření ............................................................................................................... 29

2.

Směrovací protokoly............................................................................................................................... 31

2.1.

OSPF .................................................................................................................................................. 31

2.1.1.

Úvod do OSPF ............................................................................................................................... 31

2.1.2.

Typy OSPF paketů ......................................................................................................................... 32

2.1.3.

Činnost OSPF směrovače............................................................................................................... 34

2.1.4.

Typy OSPF sítí............................................................................................................................... 41

2.1.5.

Hierarchický model ........................................................................................................................ 45

2.1.6.

Zabezpečení OSPF ......................................................................................................................... 49

2.2.

BGP .................................................................................................................................................... 50

2.2.1.

Úvod do BGP ................................................................................................................................. 50

2.2.2.

Použití BGP protokolu ................................................................................................................... 53

2.2.3.

Navázání BGP peeringu ................................................................................................................. 56

2.2.4.

Path-Vector atributy ....................................................................................................................... 58

2.2.5.

BGP v akci ..................................................................................................................................... 66

2.2.6.

Zabezpečení BGP........................................................................................................................... 71

Závěr............................................................................................................................................................... 75 Seznam použité literatury ............................................................................................................................. 78 Seznam použitých zkratek ............................................................................................................................ 79 Seznam příloh ................................................................................................................................................ 82

5

Úvod práce Cílem diplomové práce je pomocí průzkumu zjistit, které směrovací protokoly jsou v České Republice nejčastěji používány. Na základě výsledku podat ucelený přehled s hodnocením nejčastěji používaných směrovacích protokolů v České Republice. V první části diplomové práce jsem navázal na svoji bakalářskou práci a pomocí nového dotazníkového šetření jsem prověřil její výsledky. Zároveň s ověřením požívaných typů směrovacích protokolů jsem se pokusil zmapovat i dynamiku vývoje a změn v používání směrovacích protokolů v oslovených společnostech a počty směrovačů a směrovacích záznamů. Šetření ve společnostech bylo provedeno osobním rozhovorem anebo telefonicky s následným zasláním dotazníku, který zástupce oslovené společnosti vyplnil. Výsledkem praktické části bude potvrzení, vyvrácení nebo upřesnění zjištěných výsledků bakalářské práce a vyhodnocení využití směrovacích protokolů, a to na základě rozšířeného šetření. Druhá část diplomové práce detailněji popisuje mechanizmy a vlastnosti dvou nejpoužívanějších směrovacích protokolů v ČR. Teoretická část popisuje charakteristické technické principy a jednotlivé vlastnosti směrovacích protokolů OSPF a BGP. Nejdříve je popsán nejčastěji používaný interní směrovací protokol OSPF a následně nejčastěji používaný externí směrovací protokol BGP. Kromě technických vlastností je popsáno i jejich typické použití. Tyto dva směrovací protokoly byly vybrány na základě výsledků z provedeného šetření v první části diplomové práce, proto teoretická část práce následuje až za částí praktickou. Zároveň technická část navazuje a rozšiřuje teoretickou část mé předchozí bakalářské práce. Závěr diplomové práce obsahuje zhodnocení použití směrovacích protokolů v ČR.

6

Zvolené metody zpracování V první části diplomové práce jsem realizoval šetření zaměřené na využití směrovacích protokolů ve vybraných společnostech České Republiky. Toto šetření bylo podobné mému předchozímu průzkum v bakalářské práci. Na rozdíl od prvního průzkumu před dvěma lety, jsem si zvolil metodu přímého oslovení těchto společností. Záměrem bylo mimo jiné i porovnání výsledků obou šetření a vyvrácení, či verifikace námitky, která zazněla při obhajobě mé bakalářské práce, že první metoda průzkumu nebyla objektivní a spolehlivá, jelikož informace byly získány nepřímo, přestože byly od odborných systémových inženýrů společnosti Alef NULA, a.s., namísto od přímých zástupců vybraných společností v České Republice. Nyní šetření spočívalo v osobním oslovení zástupců vybraných společností nebo oslovením telefonickým s následným zasláním webového formulářového dotazníku s použitím portálu SurveyMonkey. S ohledem na skutečnost, že se jedná o citlivé informace, zejména z oblasti bankovního sektoru a státní správy, potýkal jsem se s nedůvěrou a neochotou oslovených organizací sdělovat do průzkumu požadované informace. Přesto se mně podařilo přesvědčit většinu zástupců vybraných společností ke spolupráci a poskytnutí požadovaných údajů. V některých případech bylo ze strany respondentů požadováno jednoznačné ujištění, že společnosti nebudou diplomové práci jmenovitě uvedeny. Z důvodu citlivosti dat a přislíbení anonymity se ve výsledcích šetření objevují data seřazena tak, aby se nedala přiřadit ke konkrétním společnostem, nebo některé společnosti nejsou zmíněny vůbec. Zjištění výsledků bylo časově náročné a sbírání informací trvalo několik měsíců. Druhá část diplomové práce detailněji popisuje vlastnosti dvou nejčastěji používaných dynamických směrovacích protokolů v ČR. Tato část navazuje na moji diplomovou práci a rozšiřuje základní přehled o vybraných směrovacích protokolech OSPF (Open Shortest Path First) a BGP (Border Gateway Protocol). V popisu jsem čerpal především ze svých dlouholetých lektorských a praktických zkušeností a také z anglické literatury uvedené v závěru práce. Vzhledem k tomu, že se jedná o protokoly, jež jsou jasně popsané v několika RFC (Request for Comments) dokumentech, které definují jasné požadavky na chování a vlastnosti těchto protokolů, a vzhledem k omezení délky diplomové práce, jsem se podrobněji nevěnoval detailům, jak a proč jsou tyto protokoly implementovány, ale snažil jsem se popsat dle svého názoru nejdůležitější vlastnosti těchto protokolů. 7

1. Používané směrovací protokoly v ČR Cílem šetření bylo zjistit na vybraném reprezentativním vzorku společností, jaké směrovací protokoly jsou vyžívány v organizacích v České Republice, zjistit dynamiku vývoje a změny v jejich používání. Nezanedbatelným zjištěním může být, i jak rozsáhlé jsou sítě z pohledu počtu směrovačů a počtu směrovacích záznamů na směrovačích a v používaných směrovacích protokolech. V neposlední řadě pak porovnat výsledky nepřímého šetření v mé předchozí bakalářské práci se zjištěním pomocí přímého šetření a ověřit, vyvrátit či upřesnit tak mé původní závěry.

1.1. Základní předpoklady šetření Prvním základním předpokladem a hypotézou pro šetření jsou níže uvedené výsledky a závěry z mé předchozí bakalářské práce: -

Nejčastějším interním směrovacím protokolem je OSPF.

-

Relativně malé využití směrovacího protokolu RIP (Routing Information Protocol).

-

Relativně malé využití protokolů EIGRP (Enhanced Interior Gateway Routing Protocol) a ISIS (Intermediate System-to-Intermediate System).

-

Protokoly ODR (On-Demand Routing) a IGRP (Interior Gateway Routing Protocol) jsou prakticky nepoužívané.

-

BGP protokol se využívá u všech ISP (Internet Services Providers), u ostatních organizací převládá statické směrování.

Druhou hypotézou je, že výsledky a závěry z bakalářské práce se nijak zásadně nebudou lišit od druhého šetření provedeného rozdílnou metodou přímého oslovení. Cílem šetření je na základě nově zjištěných faktů potvrdit nebo vyvrátit stanovené hypotézy skládající se z výše uvedených názorů a zdokumentovat reálný stav věcí v této problematice. Dalším cílem je zjistit, jaká je dynamika a četnost změn ve směrovacích protokolech v závislosti na časovém rozpětí dvou let, v rámci něhož byla obě šetření prováděna, a s vizí do budoucna.

8

1.2. Zvolená metodika šetření V úvodní kapitole „Zvolené metody zpracování“, již bylo zmíněno, že jsem zvolil metodu průzkumu způsobem přímého oslovení. Oslovil jsem konkrétní organizace, respektive jejich zástupce a to buď osobní schůzkou, nebo s využitím elektronického internetového webového formuláře umístěného na portálu SurveyMonkey, po předchozím telefonickém kontaktu, v rámci něhož jsem vysvětlil účel šetření a jeho předpokládaný rozsah. Vlastní dotazník je veden jako příloha č. 1 této diplomové práce. Průzkum probíhal tak, že jsem předem připravil dotazník za využití portálu SurveyMonkey, který se specializuje na realizaci různých nezávislých šetření a průzkumů. Tento dotazník jsem využíval dvěma způsoby. Při osobních schůzkách jsem používal jeho tištěnou verzi, do které jsem zjištěné informace zaznamenával a následně je vložil na portál SurveyMonkey. V případě kombinace kontaktu respondentů pomocí telefonického kontaktu a následně emailu, jsem jim zpřístupnil link na portál SurveyMonkey, kde byl webový formulář on-line dostupný k vyplnění. Mojí snahou bylo oslovit z větší části stejné společnosti jako v prvním průzkumu a získat tak opět 100 validních odpovědí, a to z důvodu, aby bylo možno porovnat, jestli se odpovědi z prvního průzkumu liší od zjištění z přímého šetření. Společnosti byly vybrány tak, aby reprezentovaly různé typy organizací jak z pohledu činnosti, tak z pohledu velikosti. Výsledně se mně podařilo získat 69 odpovědí od stejných společností jako v průzkumu v bakalářské práci. Shoda v obou šetřeních byla ovlivněna ochotou poskytnout citlivé informace zástupci společností v přímém šetření, některé společnosti byly zrušeny nebo sloučeny s jinými. Zbývajících 31 odpovědí jsem získal od nových společností, které se prvního průzkumu nezúčastnily. Celkem jsem oslovil 136 společností, než jsem získal vytýčených 100 platných odpovědí. Výsledkem je překvapivá úspěšnost návratnosti dotazníku ve 2/3 případů, což považuji za uspokojivý výsledek.

9

1.3. Vlastní šetření Pro šetření jsem zvolil 100 reprezentativních společností z různých typů organizací, a to jak z pohledu oboru činnosti a jejich zaměření – banky a finanční instituce, poskytovatelé internetu a mobilních služeb, státní správa, školství a podniky lokální i mezinárodní. Tak i z pohledu velikosti společnosti od menších firem do 100 zaměstnanců až po společnosti čítající více jak 5000 zaměstnanců. Jejich níže uvedený seznam je řazen abecedně. Accenture Central Europe B.V.,

ČEZ, a. s.,

ACTIVE 24, s.r.o.,

Český úřad zeměměřický a katastrální,

AHOLD Czech Republic, a.s.,

Devro s.r.o.,

Alef Nula, a.s.,

DHL International,

ASSA ABLOY EMEA,

Doosan Bobcat Manufacturing s.r.o.,

Asseco Central Europe, a.s.,

Dragon Internet a.s.,

AUTO PALACE Group,

ELMARCO s.r.o.,

AVAST Software a.s.,

ESET software spol. s r.o,

AVG Technologies CZ, s.r.o.,

Fakultní nemocnice v Motole,

AXA Bank Europe,

Fakultní nemocnice Olomouc,

B. Braun Medical s.r.o.,

FEI Czech Republic, s.r.o.,

Bridgestone CR, s.r.o.

České vysoké učení technické v Praze

Casablanka INT.,

Fakulta informačních technologií,

Centrum Praha Jih-Chodov s.r.o,

FORTUNA ENTERTAINMENT

CESA a.s.,

GROUP N.V.,

CESNET, z. s. p. o.,

FOXCONN CZ s.r.o.,

Commerzbank AG,

GC System a.s.,

ČD-Telematika a.s.,

GE Money Bank, a. s.,

ČEPS, a.s.,

Geis CZ s.r.o.,

Česká kancelář pojistitelů,

Generali Pojišťovna a.s.,

Česká národní banka,

Generální ředitelství cel,

Česká spořitelna, a. s.,

Global Payments Europe, s.r.o.,

České Radiokomunikace a.s.,

GTS Czech s.r.o.,

Českomoravská záruční a rozvojová

INTERCOM SYSTEMS a.s.,

banka, a.s.,

INTERNEXT 2000, s.r.o.,

Československá obchodní banka, a. s.,

Interoute Czech s.r.o, 10

Planet A, a.s.,

S A L T O spol. s r.o.,

Kooperativa pojišťovna, a.s.,

Sanofi-aventis, s.r.o.,

Logica,

Seznam.cz, a.s.,

Master Internet s.r.o.,

Slezská univerzita v Opavě,

Mero ČR a.s.,

SMART Comp. a.s.,

Ministerstvo obrany ČR,

SOFTEX GROUP s.r.o.,

Ministerstvo školství, mládeže a

Soitron s.r.o.,

tělovýchovy,

SPAR Česká obchodní společnost, s.r.o.,

MODEL OBALY a.s.,

SYNOT ICT Services, a. s.,

M-SOFT, spol. s r.o.,

Telefónica Czech Republic, a.s.,

Národní knihovna České republiky,

Tesco Stores ČR a.s.,

NEECO s.r.o.,

T-Mobile Czech Republic a.s.,

NIX.CZ, z.s.p.o.,

T-Systems Czech Republic a.s.,

ODP-software, spol. s r.o.,

UPC Česká republika, s.r.o.,

OLYMPUS C&S spol.s.r.o.,

V-COM.CZ, spol. s r.o.,

ORIFLAME CZECH REPUBLIC

EVRAZ VÍTKOVICE STEEL, a.s.,

Penny Market s.r.o.,

Vodafone Czech Republic a.s.,

PODA a.s.,

Dial Telecom a.s.,

Pojišťovna České Spořitelny a.s.,

Vysoká škola báňská - Technická

PricewaterhouseCoopers Česká

univerzita Ostrava,

republika, s.r.o.,

WIA spol. s r.o.,

Raiffeisenbank a.s.,

Západočeská univerzita v Plzni,

Royal Bank of Scotland N.V.,

Zdravotnická záchranná služba

Řízení letového provozu České

Královéhradeckého kraje, p. o.,

republiky, s.p.,

Zentiva Group, a.s.

Pořadí výše jmenovaných společností neodpovídá sestupně ani vzestupně uvedeným hodnotám v tabulce, která je vedena jako příloha č. 3 této diplomové práce. Data ve zmíněné tabulce jsou řazena záměrně náhodně.

11

1.4. Interpretace výsledků šetření Zjištěné výsledky šetření jsou obsaženy v tabulkách, které jsou v příloze č. 2 k diplomové práci, a jsou interpretovány z několika pohledů: -

Typ společností z hlediska jejího zaměření.

-

Velikost společností a jejich rozložení.

-

Využití interních směrovacích protokolů.

-

Využití externích směrovacích protokolů.

-

Změny používání směrovacích protokolů.

-

Zájem o výsledky šetření.

1.4.1. Typy společností Všechny vybrané společnosti byly rozděleny dle jejich primárního zaměření do 4 kategorií: -

Banky/finanční instituce - kategorie zahrnuje převážně banky a pojišťovny.

-

Státní správa - kategorie zahrnuje ministerstva či jiné orgány státní správy a školy.

-

ISP - kategorie zahrnuje poskytovatele internetu nebo jiných datových a hlasových služeb.

-

Podniky - v této kategorii se nacházejí všechny ostatní organizace zahrnuté v tomto šetření.

V následující tabulce „Tabulka č. 1: Typy společností“ i na následném grafu „

12

Graf č. 1: Typy “ je vidět počet i procentuální rozložení jednotlivých organizací, ze kterého následně vycházejí ostatní tabulky a grafy. Tabulka č. 1: Typy společností Typy společností banka podnik ISP státní správa

počet 14 54 23 9 Zdroj: vlastní úprava

13

Graf č. 1: Typy společností

Typy společností 9

banka

14

podnik

23

ISP 54

státní správa

Zdroj: vlastní úprava

1.4.1.1. Porovnání typů společností s průzkumem bakalářské práce Jelikož se nepodařilo, a ani nebylo možné získat identický vzorek odpovědí od stejných 100 společností jako 100 společností jako v bakalářské práci, bylo do šetření zahrnuto dalších 31 nových společností. Snahou bylo společností. Snahou bylo přiblížit se podobnému rozložení vzorku společností jako v bakalářské práci, aby se v bakalářské práci, aby se výsledky daly relevantně porovnat. Přehled rozložení organizací z bakalářské práce z bakalářské práce je v tabulce „Tabulka č. 2: Typy organizací – bakalářská práce“ a na grafu „

14

Graf č. 1: Typy . Tabulka č. 2: Typy organizací – bakalářská práce Typy organizací

Počet 11 58 26 5

banka podnik ISP státní správa

Zdroj: [5] NAUŠ, Dalibor. Směrování v lokálních a globálních sítích. Praha, Duben, 2011.

Bakalářská práce. Bankovní institut vysoká škola Praha. Vedoucí práce [Ing.] Vladimír Beneš. Graf č. 2: Typy organizací – bakalářská práce

Typy organizací 5 11

banka

26

podnik ISP státní správa

58


Bakalářská práce. Bankovní institut vysoká škola Praha. Vedoucí práce [Ing.] Vladimír Beneš. Při porovnání je vidět, že došlo k lehké změně, kdy počet: -

bank a finančních institucí se zvýšil z 11 na 14,

-

podniků se snížil z 58 na 54,

-

ISP se snížil z 26 na 23,

-

zastoupení státní správy se zvýšil z 5 na 9.

Z hlediska celkové statistiky lze říci, že se počty změnily v zanedbatelných jednotkách % a porovnání statistik tak je ve většině případů relevantní.

1.4.2. Velikost společností a jejich rozložení

15

Výběr společností byl z hlediska velikosti náhodný. Bylo to způsobeno tím, že základní seznam společností vycházel z bakalářské práce, kdy jsem tuto okolnost nebral v patrnosti. Dále jsem nemohl významně ovlivnit, které z oslovených společností na šetření zareagují. V následující tabulce „Tabulka č. 3: Velikost

společností“ i na následných grafech „

16

Graf č. 3: Velikost společností v počtu zaměstnanců“ a „Graf č. 4: Velikost společností a rozložení dle typu společnosti“ je vidět počet i procentuální rozložení velikosti jednotlivých společností a jejich rozložení mezi jednotlivé typy společností. Rozdělení pro slovní popis lze ještě zjednodušit na „menší společnosti“ (do 100 a do 500), „střední společnosti“ (do 1000 a do 2000) a „velké společnosti“ (do 5000 a více). Tabulka č. 3: Velikost společností Velikost společností Typ společností Banka Podnik ISP Státní správa Celkem

Počet zaměstnanců Menší spol. Střední spol. Větší spol. Celkem do 100 do 500 do 1000 do 2000 do 5000 více 5000 1 3 2 2 3 3 14 9 18 9 5 6 7 54 12 4 3 1 1 2 23 1 1 3 0 1 3 9 23 26 17 8 11 15 100 Zdroj: vlastní úprava

Na grafu níže můžeme vidět, že skoro dvě čtvrtiny společností jsou menší společnosti. Druhé dvě čtvrtiny připadají na střední a větší společnosti a dalo by se říci, že rozložení je relativně rovnoměrné a každá skupina má reprezentativní zastoupení.

17

Graf č. 3: Velikost společností v počtu zaměstnanců Velikost společností v počtu zaměstnanců do 100

15%

23%

do 500

11%

do 1000

8%

do 2000 26%

do 5000

17%

více 5000


Na dalším grafu je možné si všimnout, že všechny typy společností mají alespoň jednoho zástupce v každé z velikostní kategorie. Zajímavé je například rozložení zastoupení podniků. Polovina jsou menší společnosti a zbytek je rovnoměrně rozložen mezi střední a velké společnosti, ve většině kategorií mají většinu až na kategorii do 100 zaměstnanců, v které lehce převažují ISP společnosti reprezentované menšími regionálními poskytovateli internetu. Graf č. 4: Velikost společností a rozložení dle typu společnosti 18 18 16 14

12

12 9

10

Banka

9

8 6 3

4 2

1

1

5

4 1

2

3 3

2

ISP

3 1

Podnik

7

6 3 1 1

2

3

0 do 100

do 500

do 1000

do 2000

do 5000

Počet zaměstnanců


18

více 5000

Státní správa

1.4.3. Využití interních směrovacích protokolů Výsledky šetření využití interních směrovacích protokolů dokládají, jaké jsou nejčastěji používané interní směrovací protokoly v podnikových sítích různých společností. Získané výsledky jsou v tabulce „Tabulka č. 4: Využití interních směrovacích protokolů“, kde lze vidět, že protokoly ODR a IGRP jsou používané minimálně, jen v jednotkách %. Dále lze zjistit, že ve 100 společnostech je spuštěno nebo používáno více jak 270 směrovacích protokolů. U 79 společností je využito více souběžných směrovacích protokolů, minimálně jsou to 2 (jeden statický a jeden dynamický), zatímco jen u 21 společností je použit jeden směrovací protokol, z toho v pěti případech OSPF a v 16 případech statické směrování. Tabulka č. 4: Využití interních směrovacích protokolů Interní směrovací protokoly počet Statické směrování 92 ODR 3 RIP 1/2 14 IGRP 2 EIGRP 25 OSPF 71 ISIS 11 iBGP 53 více protokolů současně 79

banka [%] 85,7 7,1 14,3 7,1 35,7 71,4 0,0 57,1 85,7

jen 16 0 0 0 0 5 0 0 79

podnik [%] 88,9 1,9 7,4 1,9 24,1 68,5 5,6 40,7 74,1

ISP [%] 100,0 4,3 30,4 0,0 30,4 87,0 34,8 87,0 95,7

státní správa [%] 100,0 0,0 11,1 0,0 0,0 44,4 0,0 33,3 55,6


Z tabulky je patrné, že nejrozšířenější je statické směrování, které je využito v 92 případech. Nejčastějším dynamickým protokolem je OSPF, jež je využito v 71 případech. Následuje protokol iBGP (Internal Border Gateway Protocol), který se objevil v 53 případech. IBGP je interním směrovacím protokolem, jeho využívání se však zpravidla váže s použitím eBGP (External Border Gateway Protocol).

19

Graf č. 5: Využití interních směrovacích protokolů

Interní směrovací protokoly Statické směrování

ISIS 4%

iBGP 20%

OSPF 26% EIGRP 9%

ODR Statické směrování 34%

RIP 1/2 IGRP EIGRP OSPF

ODR RIP 1% IGRP 1/2 1% 5% Zdroj: vlastní úprava

V grafu „

20

ISIS iBGP

Graf č. 5: Využití interních směrovacích protokolů“ je vidět procentuální využití interních směrovacích protokolů. Nejčastěji je využíváno statické směrování v kombinaci s dynamickým směrovacím protokolem OSPF. V celkovém součtu lze říci, že se používají skoro tři směrovací protokoly na jednu společnost. Z detailnější analýzy pak lze zjistit, že se většinou jedná o jeden až dva dynamické směrovací protokoly doplněné o statické směrování. Graf č. 6: Počet použitých směrovacích protokolů

Počet použitých směrovacích protokolů 5%

3% 2% 21%

11%

1 2 3 4 5

25%

6 7

33%


Z grafu „Graf č. 6: Počet použitých směrovacích protokolů“ můžeme zjistit, že skoro 60 % společností má spuštěny do 3 směrovacích protokolů. Z toho je zpravidla statické směrování doplněno ze ¾ protokolem OSPF. V případě spuštění 2 souběžných protokolů se jedná ve 12 případech o kombinaci statické směrování a OSPF z celkem 25 případů, což je cca polovina. V případě spuštění 3 souběžných protokolů se jedná ve 26 případech o kombinaci statického směrování, OSPF a iBGP z celkem 33 případů, což jsou více jak ¾ případů. Kombinace statického směrování, OSPF a iBGP je celkem v 45 případech. Na grafu „Graf č. 7: Počet použitých směrovacích protokolů dle typu společnosti“ je vidět, že 5 a více směrovacích protokolů má spuštěno 7 ISP z 10 případů. Za povšimnutí stojí jedna finanční instituce se 7 směrovacími protokoly, což pro její pracovníky musí být náročné na znalosti a administraci. Graf č. 7: Počet použitých směrovacích protokolů dle typu společnosti 21

19

20

14

15

14 Banka

10

Podnik

7 4

5 2

5

4

5

4

3

2

1

ISP 4

2

2

3

Státní správa

3 1

1

0 1

2

3

4

5

6

7

Počet směrovacích protokolů Zdroj: vlastní úprava

1.4.3.1. Porovnání využití interních směrovacích protokolů s průzkumem bakalářské práce Pro názornost porovnání poměru využití interních směrovacích protokolů byla zvolena demonstrace na dvou grafech. Graf „

22

Graf č. 8: Poměr využití interních směrovacích protokolů“ znázorňuje výsledky aktuálního šetření.

23

Graf č. 8: Poměr využití interních směrovacích protokolů Interní směrovací protokoly 100 80 60 40 20 0

92

79

71

3

14

25

53 11

2


Zatímco graf „Graf č. 9: Poměr využití interních směrovacích protokolů – bakalářská práce“ znázorňuje výsledky průzkumu v bakalářské práci z doby před dvěma lety. Graf č. 9: Poměr využití interních směrovacích protokolů – bakalářská práce Interní směrovací protokoly 100 80 60 40 20 0

84 64

50 0

11

13

0

46 6


Bakalářská práce. Bankovní institut vysoká škola Praha. Vedoucí práce [Ing.] Vladimír Beneš. Porovnáním grafů je vidět, že poměry využití směrovacích protokolů zůstaly zhruba stejné. Pořadí četnosti jednotlivých směrovacích protokolů zůstalo také stejné. Dále je patrné, že došlo k nárůstu u všech protokolů, a to o jednotky až desítky u OSPF.

24

Při porovnání je dobré zmínit, že došlo ke změnám v celkovém nárůstu u: -

OSPF, kde se zvýšil počet z 50 na 71, což je největší změna, která je však pochopitelná, jelikož se jedná o nejpoužívanější interní dynamický směrovací protokol.

-

Statického směrování se zvýšil počet z 84 na 92, což není změna výrazná a do budoucna pro změnu už moc prostoru nezbývá.

-

EIGRP se zvýšil počet z 13 na 25, což je nárůst skoro 100 %. Ovšem z analýzy počtu směrovačů s EIGRP a počtu směrovacích záznamů v EIGRP je patrné, že se využívá stále v menší míře.

-

ISIS se zvýšil z 6 na 11, což je nárůst také skoro 100 %.

-

IGRP a ODR se zvýšilo z 0 na 2 a 3, jedná se však o menší sítě s jednotkami, maximálně desítkami směrovačů a směrovacích záznamů.

Z hlediska celkové statistiky lze říci, že se počty změnily celkově o cca 25 %. Z toho je cca 15 % přiznaná změna za uplynulé dva roky, což je zmíněno v kapitole „1.4.5 Změny používaných směrovacích protokolů v čase“, a cca 10 % se na rozdílu podílí chyby z průzkumu z bakalářské práce a chyby z aktuálního šetření. Proto považuji porovnání za relevantní a výsledky porovnání použití interních směrovacích protokolů za téměř shodné v obou typech prováděných šetření.

1.4.4. Využití externích směrovacích protokolů Výsledky šetření použití externích směrovacích protokolů dokládají, jaké jsou nejčastěji používané externí směrovací protokoly mezi podnikovými sítěmi, respektive AS (Autonomus System) různých společností. Zjednodušeně lze říci, že jde o porovnání použití externího dynamického směrovacího protokolu eBGP a statického směrování. Získané výsledky jsou v tabulce „

25

Tabulka č. 5: Využití externích směrovacích protokolů“, kde lze vidět, že statické směrování je častěji využíváno než externí protokol eBGP mezi AS. Dále ve 100 společnostech je využito ve 26 případech současně statické směrování i eBGP mezi AS, což je v porovnání s interními směrovacími protokoly daleko méně časté využití více protokolů najednou. To je pravděpodobně způsobeno tím, že v externích protokolech je menší možnost volby.

26

Tabulka č. 5: Využití externích směrovacích protokolů Externí směrování protokoly Statické směrování eBGP obojí

počet 64 56 26

jen 38 30 26

banka podnik ISP státní správa [%] [%] [%] [%] 85,7 66,7 39,1 77,8 64,3 40,7 100,0 22,2 50,0 16,7 39,1 11,1


Graf č. 10: Využití externích směrovacích protokolů

Externí směrování protokoly

eBGP 47%

Statické směrování 53%

Statické směrování eBGP


V grafu „Graf č. 10: Využití externích směrovacích protokolů“ je vidět procentuální využití externího směrovacího protokolu oproti statickému směrování. Statické směrování je využíváno častěji oproti dynamickému eBGP, i když jen nepatrně.

1.4.4.1. Porovnání využití externích směrovacích protokolů s průzkumem bakalářské práce Pro porovnání využití externích směrovacích protokolů byly zvoleny také dva grafy. Graf „

27

Graf č. 11: Poměr využití externích směrovacích protokolů“ znázorňuje výsledky aktuálního šetření.

28

Graf č. 11: Poměr využití externích směrovacích protokolů

Externí směrovací protokoly 100 64

56

50

26

0 Statické směrování

eBGP

obojí


Zatímco graf „Graf č. 12: Poměr využití externích směrovacích protokolů – bakalářská práce“ znázorňuje výsledky průzkumu v bakalářské práci z doby před dvěma lety. Graf č. 12: Poměr využití externích směrovacích protokolů – bakalářská práce

Externí směrovací protokoly 100 80 60 40 20 0

63

55 18

Statické směrování

eBGP

obojí


Bakalářská práce. Bankovní institut vysoká škola Praha. Vedoucí práce [Ing.] Vladimír Beneš. Porovnáním grafů je vidět, že poměry využití směrovacích protokolů zůstaly prakticky stejné. Zvýšil se nepatrně počet společností používajících oba protokoly. Lze tedy konstatovat, že celkově se počty ani statistiky nezměnily.

1.4.5. Změny používaných směrovacích protokolů v čase Jedním z cílů stanovených na začátku přípravy diplomové práce bylo zjistit, jak časté jsou změny ve směrovacích protokolech používaných v České Republice. Toto zjištění mělo

29

zaprvé úkol pomoct při správném porovnání dvou šetření provedených s dvouletým odstupem a zadruhé podívat se a ukázat na dynamiku vývoje používaných směrovacích protokolů v čase jakožto nový pohled, který může indikovat potřeby spojené se správou sítí jednotlivých společností. Zvolené sledované období změn bylo: -

Dva roky zpět – důvodem byla, možnost porovnání údajů v prvním průzkumu.

-

Dva roky do budoucnosti – toto období víceméně vyplynulo z odpovědí, jelikož nikdo z respondentů neudal změnu v delším horizontu, což se dalo předpokládat, jelikož plánování podobných změn je otázkou cca 1 roku, u větších společností 2 let a vlastní realizace také, a to v závislosti na velikosti sítě.

V tabulce „Tabulka č. 6: Odpovědi na dotaz - Proběhla v posledních 2 letech nějaká změna?“ a v grafu „Graf č. 13: Odpovědi na dotaz - Proběhla v posledních 2 letech nějaká změna?“ jsou uvedeny údaje z odpovědí na první sledované období 2 roky zpět. Z výsledku je vidět, že 28 % společností provedlo nějakou změnu v používaných směrovacích protokolech v uplynulých 2 letech. Tabulka č. 6: Odpovědi na dotaz - Proběhla v posledních 2 letech nějaká změna? Typ společnosti Banka ISP Podnik Státní správa Celkem

NE 9 20 35 8 72

ANO Celkem 5 14 3 23 19 54 1 9 28 100

NE [%] 64 87 65 89 72

ANO [%] 36 13 35 11 28


Graf č. 13: Odpovědi na dotaz - Proběhla v posledních 2 letech nějaká změna?

30

89%

87% 64%

65%

100% 80%

NE

20%

ANO

11%

13%

40%

35%

36%

60%

0% Banka

ISP

Podnik

Státní správa


V tabulce „Tabulka č. 7: Odpovědi na dotaz - Uvažujete o změně v horizontu 2 let?“ a v grafu „Graf č. 14: Odpovědi na dotaz - Uvažujete o změně v horizontu 2 let?“ jsou uvedeny údaje z odpovědí na druhé sledované období dvouletého výhledu. Z výsledku je vidět, že 16 % společností plánuje nějakou změnu v používání směrovacích protokolů v horizontu cca 2 let. Tabulka č. 7: Odpovědi na dotaz - Uvažujete o změně v horizontu 2 let? Typ společnosti Banka ISP Podnik Státní správa Celkem

NE 11 17 49 7 84

ANO Celkem 3 14 6 23 5 54 2 9 16 100

NE [%] 79 74 91 78 84

ANO [%] 21 26 9 22 16


Graf č. 14: Odpovědi na dotaz - Uvažujete o změně v horizontu 2 let?

31

78% 9%

21%

26%

60%

22%

80% 40%

91%

74%

79%

100%

20%

NE ANO

0% Banka

ISP

Podnik

Státní správa


Rozdíl mezi 28 % udávaných změn za poslední 2 roky a mezi 16 % udávaných plánovaných změn si vysvětluji tím, že v menších společnostech se změny mohou dít v kratším časovém intervalu, a tím, že se o možných změnách neuvažovalo a změny mohou přijít jako nařízení od mateřské společnosti nebo při akvizicích či rozdělování společností. Pokud údaje z obou období spojíme dohromady, dostaneme se k údaji, kdy cca 41 % společností provede změnu v používaných směrovacích protokolech nebo ji alespoň plánuje, tak jak je vidět na grafu „Graf č. 15: Počet společností, které plánují změnu v průběhu 4 let“. Graf č. 15: Počet společností, které plánují změnu v průběhu 4 let

Změna v průběhu 4 let

41%

NE 59%

ANO


Za změnu uváděnou výše je považováno použití nového směrovacího protokolu, zrušení některého směrovacího protokolu nebo významná změna poměru využití jednoho

32

směrovacího protokolu vůči druhému směrovacímu protokolu. Některé společnosti uváděly i více paralelních změn za sledované období. Následující graf „Graf č. 16: Změna v průběhu 4 let nově/zrušeno“ znázorňuje typy těchto změn. Graf č. 16: Změna v průběhu 4 let nově/zrušeno

Změna v průběhu 4 let -8

nově 33

-16

poměr více zrušeno poměr méně

11


Podíváme-li se detailněji na jednotlivé změny ve směrovacích protokolech ve sledovaných obdobích, jež jsou znázorněny v grafu „Graf č. 17: Změny ve směrovacích protokolech dle období, typu změny a protokolu“, tak vidíme, že nejvíce se nově používá směrovací protokol OSPF, který nově zavedlo 8 společností a 4 společnosti jej zavést plánují. Dochází však i k jeho rušení, ale nijak zásadnímu, jelikož jen jedna společnost ho za 2 roky zrušila a jedna tento krok plánuje. Druhým rozvíjejícím se směrovacím protokolem je eBGP, kde 7 společností ho v posledních dvou letech zavedlo a dvě další společnosti jej zavést plánují. K rušení eBGP, jak vyplývá z šetření, nedochází. Jak jsem zmínil již dříve, tak s eBGP úzce souvisí iBGP, které společnosti začaly používat v 5 případech a v jednom ho zavést plánují. Ke zrušení iBGP došlo v jednom případě a v plánu zrušit iBGP není. Směrovací protokol EIGRP začaly používat 3 společnosti v posledních 2 letech a v plánu ho nově používat nikdo z dotázaných nemá. Ke zrušení došlo ve 2 případech za 2 roky a v plánu to mají ještě 2 společnosti do 2 let. Z toho ve výsledku vyplývá, že EIGRP poměrově zůstává cca na stejné úrovni anebo ho lehce ubývá.

33

Směrovací protokol RIP se dle zjištěných údajů nerozvíjí, ale naopak ve dvou případech byl zrušen. O jeho dalším rušení se neuvažuje, což si vysvětluji tím, že 7 společností, jež RIP používají, jsou ISP, kteří tímto protokolem podporují ostatní společnosti používající RIP, a zbývajících 7 společností je tak relativně malý počet na to, aby se tyto změny dostaly do statistiky. Posledním protokolem, o němž se zmíním, je statické směrování, které se ve 4 případech zrušilo v posledních dvou letech, a v horizontu 2 let plánují jeho zrušení ještě 2 společnosti. Změny v poměru využívání jednotlivých směrovacích protokolů nejsou rozebrány, jelikož je těžké je posoudit a je jich méně a lehce kopírují výše zmíněné trendy. V grafu zmíněné „x“ jsou respondentem neuvedené směrovací protokoly a vyjadřují tedy jen kvantitativní změnu, nikoli konkrétní protokol.

34

Graf č. 17: Změny ve směrovacích protokolech dle období, typu změny a protokolu

25 EIGRP, 3 20 IBGP, 5 15

x EBGP, 7

Statika x, 1 ISIS, 2 IBGP, 1 EBGP, 2

10

5

OSPF, 8

0

x, 2 IBGP, 2 EBGP, 1 OSPF, 1

OSPF, 4 OSPF, -1 IBGP, -1 EIGRP, -2

RIP ISIS IBGP EBGP

OSPF, 2

OSPF, -1 Statika, -1 x, -2

OSPF, -1 EIGRP, -2 Statika, -2 x, -1

RIP, -2

-5

EIGRP

x, 1 ISIS, 2 OSPF, -2 IBGP, -1 x, -1

Statika, -4 -10 nově

poměr více

zrušeno

poměr méně

nově

Proběhla v posledních 2 letech změna?

poměr více

zrušeno

Uvažujete o změně v horizontu 2 let?


35

poměr méně

OSPF

Na grafu „Graf č. 18: Změny ve směrovacích protokolech dle protokolu a typu změny“ je jinak reprezentovaný pohled na změny v průběhu celých 4 let, a to dle jednotlivých směrovacích protokolů. Tak jak bylo zjištěno, že směrovací protokol OSPF je nejčastěji používán, tak i změny v OSPF protokolu jsou nejčastější. Dále jsou nejčastější změny v protokolu BGP, a to jak iBGP, tak eBGP. U OSPF i BGP se zejména jedná o změny pozitivní. Graf č. 18: Změny ve směrovacích protokolech dle protokolu a typu změny 15 3

10

1

12

2

5

9 6

poměr více 2 2

0

-2

-1 -1

3

3

1 -1

-2

-4

-6

-3

-3

-5 -1

-10 OSPF

IBGP

EBGP

ISIS

EIGRP

RIP


36

Statika

x

nově poměr méně zrušeno

1.4.6. Zájem o výsledky šetření Jedna z otázek při obhajobě bakalářské práce před dvěma lety byla, zda průzkum někoho zajímá a jestli může mít nějaký praktický dopad. Proto jsem při osobním šetření položil i já stejný dotaz. Výsledek celkového zájmu ukázal, že 2/3 oslovených mají zájem o výsledky tohoto průzkumu, jak je vidět na grafu „Graf č. 19: Celkový zájem o výsledky šetření“. Graf č. 19: Celkový zájem o výsledky šetření

Zajímjí vás výsledky šetření?

34%

NE ANO

66%


Nezájem 1/3 oslovených respondentů vidím hlavně v tom, že se mně nepodařilo oslovit vždy osobu konkrétně zodpovědnou za sítě nebo v menších společnostech zodpovědná osoba má gesci za celé ICT (Information and Communication Technologies) a sítě jsou jen jednou okrajovou částí, jíž se pravidelně nezabývá. Slovní popis, kde respondenti měli vyjádřit, co je na průzkumu zajímá a čím pro ně může být přínosný, jsem rozdělil do 5 skupin odpovědí, které jsou: -

Zvědavost.

-

Celkový přehled.

-

Výsledky a porovnání.

-

Trendy.

-

Bez určení – přestože byl vyjádřen zájem o výsledky, nebyl uveden důvod.

Na grafu „Graf č. 20: Vyjádřené důvody zájmů respondentů“ je vidět, že více jak 30 % chce získat celkový přehled o směrovacích protokolech a dalších 30 % se zajímá

37

o konkrétní výsledky, dalších skoro 30 % pak neuvádí primární důvod svého zájmu o výsledky šetření. Graf č. 20: Vyjádřené důvody zájmů respondentů

Co vás na průzkumu zajímá? 8%

zvědavost

27%

celkový přehled 32%

3%

výsledky porovnání trendy bez určení

30%


38

2. Směrovací protokoly V teoretické části diplomové práce, která navazuje na moji bakalářskou práci „Směrování v lokálních a globálních sítích“ bakalářského studia oboru Informační technologie ve studijním roce 2010/2011, jsem se zaměřil na představení a popis dvou směrovacích protokolů OSPF a BGP, jež jsou nejčastěji používány v České Republice. Výběr popisovaných směrovacích protokolů vychází ze závěrů zjištěných v předchozí bakalářské práci, které jsou potvrzené výsledky aktuálního šetření v první části této diplomové práce.

2.1. OSPF 2.1.1. Úvod do OSPF Směrovací protokol Open Shortest Path First (OSPF) byl definován standardem v roce 1989 v RFC 1131 po dvou letech jeho vývoje organizací IETF (Internet Engineering Task Force). V roce 1991 byl definován standard jeho druhé verze OSPF v2 v RFC 1247, jež se teprve začala používat. Vývoj OSPF se tím nezastavil a v roce 1998 byla v RFC 2328 definována zatím poslední rozsáhlejší změna OSPFv2. Dále se však pracuje na doplňování rozličných vlastností tohoto nejpoužívanějšího protokolu. Vývoj OSPF byl veden snahou nahradit protokol RIP, který již nevyhovoval vlastnostmi ani škálovatelností požadavkům nových a rozsáhlých interních podnikových sítí. Základ OSPF protokolu je velice podobný protokolu ISIS, respektive pracují na podobných principech. Na začátku vývoje OSPF se neočekávalo jeho velké rozšíření, jelikož měl zajišťovat směrování pro nový IP (Internet Protocol)

protokol,

zatímco

se

předpokládal

rozvoj

protokolů

CLNS/CMNS

(Connectionless Network Service / Connection-Mode Network Service) definovaných RM OSI (Referenční Model – Open System Interconnection). Proto vznikla úzká spolupráce mezi vývojovými týmy protokolů ISIS a OSPF. Z hlediska významných vlastností můžeme OSPF protokol charakterizovat jako: -

Dynamický – Link-State směrovací protokol.

-

Interní – zajišťuje výměnu sítí uvnitř AS.

-

Multicast přenos – rezervované IP adresy 224.0.0.5 a 224.0.0.6.

-

Rychlá konvergence – lze dosáhnout konvergence pod vteřinu.

-

Multi-Path – podpora více paralelních cest v síti.

39

-

Class-Less – podpora VLSM (Variable Lenght Subnet Mask) a sumarizace.

-

Autentifikace – prostý text nebo MD5 hash.

-

Hierarchický – podporuje hierarchické členění.

-

Otevřený standard – definovaný v RFC a podporovaný většinou výrobců.

Hlavním úkolem směrovacího protokolu OSPF je tedy dynamická výměna interních směrovacích informací uvnitř podnikové sítě. OSPF je nejpoužívanější interní dynamický směrovací protokol v současném síťovém prostředí. Tento Link-State směrovací protokol se používá ve velkých a středních podnikových sítích, ale i v relativně jednoduchých síťových prostředích. Důvodem jeho obliby je jeho rychlá konvergence a relativně nízký režijní provoz. Dalším nezanedbatelným důvodem jeho obliby je inter-operabilita, takže ho lze nasadit v heterogenním prostředí různých výrobců síťových zařízení. Směrovací protokol OSPF si dostupné sítě a sousedy udržuje v interních databázích, ze kterých na základě metriky vybírá nejkratší cesty do cílových sítí. Metrika OSPF, neboli Cost je zpravidla odvozena z rychlosti linky. Rychlý výběr nejkratší cesty do cílové sítě zajišťuje OSPF Dijkstra algoritmus, jenž velice dobře reaguje na vzniklé změny v síti a dokáže eliminovat možné síťové smyčky a zacyklení ve složitějších topologiích. Logicky můžeme OSPF protokol rozčlenit do dvouvrstvé hierarchie pomocí různých oblastí, tzv. Area. Tyto hranice vytvořených oblastí můžeme s výhodou využít pro síťové sumarizace a filtrace cílových sítí.

2.1.2. Typy OSPF paketů Pro svůj transport a doručení směrovacích informací využívá OSPF přímo protokol IP s číslem protokolu 89. Není tedy přenášen servisními IP protokoly TCP (Transmission Control Protocol) nebo UDP (User Datagram Protocol), ale OSPF protokol je na jejich úrovni, jak je vidět na následujícím obrázku.

40

Obrázek č. 1: OSPF v IP paketu Frame Payload Frame Header

IP Header

Protocol Number

Packet Payload

C R C

89 — OSPF 6 — TCP 17 — UDP

Zdroj: [10] www.cisco.com,vlastní úprava

V OSPF existuje 5 různých typů paketů a jsou to: -

Typ 1 „Hello“ paket – slouží pro nalezení OSPF sousedů, Hello protokol je popsán dále detailněji.

-

Typ 2 „Database Description“ (DBD) paket – přenáší informace o Link-State databázi.

-

Typ 3 „Link-State Request“ paket – slouží pro vyžádání chybějících informací v Link-State databázi.

-

Typ 4 „Link-State Update“ paket – přenáší informace o jednotlivých Link-State Advertisementech.

-

Typ 5 „Link-State Acknowledgment“ paket – slouží jako spolehlivý mechanizmus pro potvrzení přenosu jednotlivých OSPF paketů.

Všechny typy OSPF paketů pro IPv4 mají stejnou hlavičku, v níž jsou přenášeny následující informace: -

„Version“ = vždy nabývá hodnoty 2.

-

„Type“ = může nabývat hodnoty 1 až 5 a určuje tím, o který z výše uvedených 5 OSPF paketů se jedná.

-

„Packet length“ = délka paketu v oktetech.

-

„Router ID“ = IP adresa identifikující konkrétní směrovač (RID).

-

„Area ID“ = číslo Area z které paket pochází.

-

„Checksum“ = kontrolní součet.

-

„AuType“ = může být 0 až 2, a to dle typu použité autentifikace.

-

„Authentication“ = obsah záleží na poli AuType.

41

Data v OSPF paketu jsou závislá na typu OSPF paketu. Každý typ OSPF paketu slouží a zajišťuje specifickou část OSPF komunikace mezi OSPF směrovači. Jak již bylo zmíněno, číslo OSPF protokolu v IP je 89. Všechny OSPF pakety mají TTL (Time To Live) = 1, což znamená, že OSPF pakety nemohou být dále směrovány, ale zůstávají jen v segmentu sítě, v níž byly vygenerovány. Dále všechny OSPF pakety mají nastavenu hodnotu ToS (Type of Services) = 6, což je zařazuje z hlediska QoS (Quality of Services) do třídy „Internetwork Control“, a podle toho se k OSPF paketům směrovač chová v případě zahlcení linky.

2.1.3. Činnost OSPF směrovače Jak již bylo zmíněno, hlavní činností směrovacího protokolu OSPF je dynamická výměna směrovacích informací. Aby mohl protokol OSPF tuto činnost zajistit, musí uskutečnit několik kroků, které jsou: -

Spuštění OSPF, respektive Hello protokolu na rozhraních směrovače a nalezení OSPF sousedů.

-

Navázání sousedského vztahu Adjacencies s vybranými sousedy, a to na základě typu sítě, na níž se OSPF sousedé nachází.

-

Vytvoření a poslání LSA (Link-State Advertisemen) přes všechny vytvořené Adjacencies.

-

Pomocí procesu Link-State Flooding všechny OSPF směrovače obdrží LSA od všech OSPF směrovačů a uloží si je v Link-State databázi, kterou tak mají všechny OSPF směrovače pro určitou oblast Area stejnou.

-

Jakmile mají všechny OSPF směrovače stejnou Link-State databázi, spustí každý směrovač SPF (Shortest Path First) algoritmus, pomocí něhož vypočítá nejkratší a bez-smyčkové cesty do všech sítí v Link-State databázi.

-

Na základě SPF algoritmu pak nejlepší cesty vloží do směrovací tabulky.

2.1.3.1. Hello protokol Po zapnutí OSPF na směrovači se začnou posílat Hello pakety na všechna rozhraní směrovače, kde je OSPF zapnuto. Pomocí Hello protokolu OSPF objevuje sousedy na daném segmentu sítě. Když na některém z OSPF rozhraní směrovač obdrží Hello paket

42

od jiného OSPF směrovače, stanou se z nich sousedé, za předpokladu, že se jim budou shodovat parametry v Hello paketech. Tyto parametry jsou: -

„Area ID“.

-

„Authentication“.

-

„Hello“ interval.

-

„Dead“ interval.

-

„Network Mask“.

-

„Options“ – některé bity (typ Area).

Dále Hello protokol slouží jako Keepalive k detekci funkčnosti OSPF souseda nebo linky mezi sousedy. Hello pakety se posílají mezi sousedy pravidelně, a to v intervalu 10 nebo 30 vteřin, což závisí na typu sítě. Hodnota zmíněného Dead intervalu výše, se odvozuje od Hello intervalu a je standardně 4x hodnota Hello intervalu. Hello protokol se také využívá pro volbu DR (Designated Router) a BDR (Backup Designated Router) směrovačů v Broadcast a NBMA (Nonbroadcast Multi-Access) OSPF sítích.

2.1.3.2. Navázání Adjacencies mezi OSPF směrovači Navázání vztahu Adjacency mezi OSPF směrovači probíhá automaticky. Každý OSPF směrovač může navázat sousedský vztah Adjacency se sousedním směrovačem, ale není podmínkou, že všechny OSPF směrovače musí mezi sebou navázat sousedské vztahy. Jsou definována jasná pravidla, kdo s kým a na jakém typu sítě Adjacency navazuje. Směrovač naváže Adjacency s druhým OSPF směrovačem v případě že: -

Se nachází na Point-to-Point síti.

-

Se nachází na Point-to-Multipoint síti.

-

Ukončuje virtuální link.

-

Sám je DR.

-

Sám je BDR.

-

Soused je DR.

-

Soused je BDR.

Teprve na základě ustanovených Adjacencies se uskutečňuje výměna směrovacích informací. Ustanovení Adjacency prochází čtyřmi obecnými fázemi: -

Nalezení OSPF sousedů - uskutečňuje se pomocí Hello protokolu.

43

-

Navázání obousměrné komunikace - nastává, když směrovače vidí své RID (Router IDentification) v Hello paketu svého souseda.

-

Synchronizace Link-State databáze - je proces výměny DBD (Database Description), LSR (Link-State Request), LSU (Link-State Update) paketů, dokud nemají stejné Link-State databáze.

-

Full Adjacency – nastává po úspěšné synchronizaci Link-State databáze.

Navazování sousedského vztahu Adjacency z hlediska OSPF směrovače prochází několika níže definovanými stavy: -

„DOWN“ – je počáteční stav, kdy nebyl ještě poslán žádný Hello paket.

-

„ATTEMPT“ – je stav pro OSPF sousedy v NBMA sítích, jenž posílá pravidelně Hello pakety v Poll intervalu OSPF sousedům, které má nakonfigurovány, ale neodpovídají mu.

-

„INIT“ – je stav, kdy OSPF směrovač obdržel Hello paket od souseda, ale není v něm ještě obsaženo jeho RID.

-

„2-WAY“ – je stav dvou OSPF sousedů, pokud navzájem vidí své RID v Hello paketech, ale nebudou spolu navazovat Adjacency do Full stavu.

-

„EXSTART“ – v tomto stavu se určuje, kdo bude při komunikaci Master/Slave, nastaví se „Database Description sequence number“. Masterem se stane směrovač s vyšším RID.

-

„EXCHANGE“ – v tomto stavu se posílají DBD pakety s popisem Link-State databáze a LSAck (Link-State Acknowledgment), potvrzení.

-

„LOADING“ – je stav, v němž se zasílají LSR pakety pro získání detailnějších informací o LSA a zasílají se LSU pakety s detailními informacemi o LSA, dokud nemají oba OSPF směrovače shodné Link-State databáze.

-

„FULL“ – je stav poté, co je provedena výměna všech potřebných informací a jsou identické Link-State databáze.

Vztahy, posloupnost a přechody mezi jednotlivými stavy OSPF směrovačů při navazování sousedského vztahu Adjacency jsou znázorněny na obrázku níže.

44

Obrázek č. 2: Proces navazování OSPF Adjacencies Down Stav

Start v NBMA

Attempt Stav

Obdrží Hello

Obdrží Hello

Obdrží Hello

Init Stav Loading Stav Ne Je LS databáze shodná ? Rozhodnutí

Bude navázáno Adjacency ? Rozhodnutí Změna

Ne

2-Way Stav

Výměna DBD

Ano ExStart Stav

Master Slave

Exchange Stav

LS databáze je shodná !

Ano Full Stav

Zdroj: [1] DOYLE, Jeff a Jennifer CARROLL. Routing TCP/IP: Volume I. Cisco Press, 2005. Second

Edition. ISBN 15-870-5202-4., vlastní úprava

2.1.3.3. Link-State Advertisementy Link-State Advertisementy (LSA) vytváří každý OSPF směrovač a popisuje v nich všechny své rozhraní, linky, sítě a sousedy. Tyto směrovací informace v podobě jednotlivých LSA si OSPF směrovače vyměňují v LSU paketech. V OSPF je více typů sítí, například NBMA, Point-to-Point, … více typů směrovacích informací, například Intra-Area, Inter-Area, External, … a více rolí směrovačů, například Backbone, ABR (Area Border Router), ASBR (Autonomous System Border Router), … tak je definováno i více typů LSA. LSA je 11 typů přenášejících odlišné informace: -

Typ 1 Router Link Advertisements.

-

Typ 2 Network Link Advertisements.

-

Typ 3 Summary Link Advertisements (ABRs).

-

Typ 4 Summary Link Advertisements (ASBRs).

-

Typ 5 Autonomous Systems (AS) External Link Advertisements.

-

Typ 6 Group Membership LSA.

-

Typ 7 Not-So-Stubby Areas (NSSA).

-

Typ 8 External Attributes LSA.

-

Typ 9 Link-local Opaque LSA.

-

Typ 10 Area-local Opaque LSA.

-

Typ 11 AS Opaque LSA.

45

Všechny obdržené LAS se ukládají do Link-State databáze. OSPF směrovač udržuje samostatnou Link-State databázi pro každou oblast, Area. Link-State databáze všech směrovačů v Area musí být shodná, aby při výpočtu SPT (Shortest Path First Tree) z LinkState databáze algoritmem SPF nedošlo ke vzniku smyčky. Pro každou Area se vypočítává vlastní SPT. LSA se posílají při navázání Adjacency dvou směrovačů v průběhu synchronizace Link-State databází nebo při změně stavu rozhraní, OSPF linky, sítě nebo souseda. Další takzvaná udržovací LSA se posílá jednou za 30 minut, pokud nenastane pro konkrétní LSA nějaká změna. V Link-State databázi nemohou být dvě LSA stejná, proto je jedinečnost LSA zaručena poli: -

„Type“ – typ LSA 1 až 11.

-

„Link State ID“ – obsah je závislý na typu LSA.

-

„Advertising Router“ – IP adresa směrovače (RID) kde LSA vzniklo.

Je zde i potřeba sledovat aktuálnost LSA, tedy jeho platnost, která je zaručena poli: -

„Age“ – stáří, čas v sekundách od vzniku LSA, jenž je postupně zvyšován.

-

„Sequence Number“ - zvětšující se pořadové číslo, kde platí, že LSA s vyšším sekvenčním číslem je aktuálnější.

-

„Checksum“ – kontrolní suma.

Pokud stáří některého LSA dosáhne hodnoty „MaxAge“, což je 1 hod, je LSA z Link-State databáze odstraněno.

2.1.3.4. Link-State Flooding Link-State Flooding je proces, kterým OSPF směrovač zajistí rozesílání změn topologie v síti. Když nastane změna v OSPF topologii, směrovač, jehož se změna přímo dotýká, vygeneruje nový LSA a ten ihned po zjištění této změny odesílá OSPF sousedům. V procesu Link-State Flooding se používají dva typy OSPF paketů: -

Typ 4 – „Link-State Update“ paket obsahující LSA.

-

Typ 5 – „Link-State Acknowledgment“ paket, který obsahuje LSAck, potvrzení o úspěšném doručení LSA v LSU paketech.

Jeden LSU může přenášet více LSA najednou. Sousední OSPF směrovač, jenž obdrží informaci LSA, si ji uschová do své lokální Link-State databáze, potvrdí příjem LSAck paketem a kopii LSA odešle svým dalším sousedům. Takto se změna projeví v celé OSPF 46

síti. V případě, že je OSPF síť stabilní, posílají se pravidelně takzvaná Link-State Refresh LSA, a to jednou za 30 minut, což je polovina standardní životnosti LSA v Link-State databázi.

2.1.3.5. Shortest Path First (Dijkstra) algoritmus Algoritmus Shortest Path First pro výpočet nejkratší cesty, používaný OSPF procesem, pracuje na základě E. W. Dijkstrova1 shortest path algoritmu. SPF algoritmus použije pro výpočet bezsmyčkových cest představujících strom anglicky Tree jako základ, Root neboli kořen počítaného stromu, ten směrovač, na kterém je SPF spuštěn. Výpočet nejkratších cest do všech cílových sítí je na bázi součtu metriky Cost linek vedoucích do cílové sítě. Výsledkem výpočtu algoritmu SPF je vytvořený strom s minimální celkovou délkou mezi „n“ uzly, kde kořenem je směrovač realizující výpočet. Výsledný strom je graf jen s jednou cestou mezi každými dvěma uzly. V databázi je každá linka specifikována třemi údaji: -

„Router ID“ – IP adresa směrovače, jenž do databáze vložil informace o lince.

-

„Neighbor ID“ – IP adresa sousedního směrovače, který je na druhé straně linky, u multi-point linek se používá IP adresa DR směrovače.

-

„Cost“ – metrika, ohodnocení linky na základě její rychlosti na straně směrovače, jenž linku do databáze vložil. Hodnota nemusí být symetrická na obou stranách linky.

Při SPF výpočtu se používají dynamicky tři databáze, mezi kterými se linky průběžně přesouvají, což jsou: -

„Link-State“ databáze – seznam všech linek, počáteční databáze, ze kterých se provádí výpočet (topologická databáze), viz obrázek níže.

-

„Candidate“ databáze – průběžná databáze, do níž jsou přidávány linky z Link-State databáze a následně jsou přesunuty, na základě výpočtu, do Tree databáze, nebo jsou zahozeny.

-

„Tree“ databáze – výsledná databáze, seznam linek zařazených do vypočteného stromu Tree nejkratších cest. Jedná se o výsledek výpočtu SPF algoritmu nazvaný Shortest Path Tree, viz dva obrázky na následující straně.

1

Edsger Wybe Dijkstra – Holandský počítačový vědec narozený roku 1930 v Rotterdamu http://en.wikipedia.org/wiki/Edsger_W._Dijkstra. 47

Obrázek č. 3: Topologie OSPF v Link-State databázi pro výpočet SPF

A 2

2 B

3 4

4

8

2

C 3

5 2 D

5

5

E 2

1


Jak bylo řečeno, pro SPF je důležitý parametr Cost každé linky, na základě kterého vypočítává nejkratší cesty do cílových sítí. V příkladu na obrázku výše je patrné, že každé rozhraní směrovače má svoji Cost, metriku, jež může být rozdílná na jednotlivých stranách linky. Cost se vždy sčítá a dává výslednou metriku cílové sítě od počátečního směrovače. Vždy se sčítá Cost odchozího rozhraní směrem k cílové síti a je zpravidla odvozena z šířky pásma Bandwidth daného rozhraní. OSPF na rozhraní odvodí Cost ze vzorce 108/Bandwidth. Obrázek č. 4: SPT topologie z pohledu směrovače „A“ po SPF výpočtu

A 2

B

3 4

C

D

E

„Shortest Path Tree“ směrovače A RA,RA,0 RA,RB,2 RA,RC,3 RA,RD,4 RD,RE,1

1 Zdroj: vlastní úprava

Jak je patrné na těchto dvou obrázcích, každý směrovač může vidět OSPF topologii sítě různým způsobem. Například směrovač „A“ vidí nejkratší cestu ke směrovači „E“ přes směrovač „D“, zatím co směrovač „E“ vidí nejkratší cestu ke směrovači „A“ přes směrovače „D“ a „B“. To je způsobeno tím, že metrika zpáteční cesty nemusí být identická, jelikož jak bylo zmíněno dříve, Cost na obou stranách jedné linky nemusí být stejná.

48

Obrázek č. 5: SPT topologie z pohledu směrovače „E“ po SPF výpočtu

A

C

2 B

2

E 2

„Shortest Path Tree“ směrovače E RE,RE,0 RE,RD,2 RD,RC,2 RD,RB,2 RB,RA,2

2 D Zdroj: vlastní úprava

2.1.3.6. Vytvoření/update IP směrovací tabulky Nejkratší cesty, které OSPF vybere pomocí procesu SPF algoritmu, jsou vloženy do IP směrovací tabulky. V případě, že existuje v OSPF více cest se stejnou metrikou, vloží OSPF do směrovací tabulky i další cesty. Než jsou OSPF cesty vloženy do IP směrovací tabulky, zjišťuje si směrovač, zda některý jiný směrovací protokol s nižší AD (Administrativ Distanc) nezná stejné cílové sítě. V případě, že jiný směrovací protokol zná stejnou cílovou síť, je do IP směrovací tabulky vložena ta cesta, která je ze směrovacího protokolu s nižší AD. Standardní OSPF AD je nastavena na hodnotu 110, AD je detailněji popsána v mé bakalářské práci [5] NAUŠ, Dalibor. Směrování v lokálních a globálních sítích. Praha, Duben, 2011. Bakalářská práce. Bankovní institut vysoká škola Praha. Vedoucí práce [Ing.] Vladimír Beneš.

2.1.4. Typy OSPF sítí V síťovém prostředí se setkáváme s různými typy fyzických médií a linek s různými vlastnostmi, přes něž musíme OSPF pakety transportovat. Proto OSPF definuje pět typů sítí: -

„Broadcast“ sítě.

-

„NBMA“ sítě.

-

„Point-to-Point“ sítě.

-

„Point-to-Multipoint“ sítě.

-

„Virtual links“.

49

2.1.4.1. Broadcast sítě Broadcast sítě nebo přesněji Broadcast Multi-Access sítě propojují více zařízení současně a je zde možno využít jednoho speciálního paketu vyslaného na Broadcast (nebo Multicast) adresu, který je doručen všem (více vybraným) zařízením v dané síti. Broadcast MultiAccess sítě musíme odlišovat od NBMS sítí, jež toto neumožňují a u nichž komunikace musí probíhat vždy mezi dvěma konkrétními zařízeními. OSPF v Broadcast sítích volí DR a BDR pomocí Hello protokolu. Pro zajištění optimální výměny směrovacích informací a pro komunikaci mezi směrovači používá Multicast komunikaci na adresách 224.0.0.5 a 224.0.0.6. Všechny směrovače na sebe musí mít plnou konektivitu. Typickým příkladem Broadcast sítí jsou Ethernet, Token Ring nebo FDDI (Fiber Distributed Data Interface) sítě. Obrázek č. 6: Příklad Broadcast Multi-Access sítí

Ethernet

Broadcast Multi-Access


2.1.4.2. Nonbroadcast Multi-Access sítě „Nonbroadcast Multi-Access“ (NBMA) sítě propojují více zařízení současně bez podpory Broadcast (Multicast) přenosů a zařízení musí mezi sebou využít Unicast komunikaci. Přesto i zde v NBMA sítích OSPF směrovače mezi sebou volí DR a BDR pomocí Hello protokolu, ale pomocí Unicast adres. Všechny směrovače na sebe musí mít plnou konektivitu. Typickým příkladem NBMA sítí jsou X.25, Frame Relay nebo ATM (Asynchronous Transfer Mode) sítě. S vývojem technologií a podporou nových vlastností i na těchto typech sítí je možné zapnout podporu přenosu Broadcast, respektive Multicast komunikace.

50

Obrázek č. 7: Příklad Nonbroadcast Multi-Access sítí

Nonbroadcast Multi-Access

X.25, ATM, Frame Relay


2.1.4.3. Point-to-Point sítě Point-to-Point sítě propojují navzájem dvě zařízení. OSPF sousedé na Point-to-Point síti budou vždy navazovat Adjacency a komunikace je zajištěna mezi směrovači pomocí Multicast paketů posílaných na adresu 224.0.0.5. Typickým příkladem Point-to-Point sítí jsou T1, DS-3 nebo SONET (Synchronous Optical NETwork) linky. Obrázek č. 8: Příklad Point-to-Point sítí

DS-3

Point-to-Point Zdroj: vlastní úprava

2.1.4.4. Point-to-Multipoint sítě Point-to-Multipoint sítě jsou speciální konfigurací NBMA sítí, kde se sítě tváří jako Pointto-Point linky. Směrovače zde nevolí DR a BDR, a OSPF pakety jsou posílány na Unicast adresy. Obrázek č. 9: Příklad Point-to-Multipoint sítí

Point-to-Multipoint X.25, ATM, Frame Relay


51

2.1.4.5. Virtual link Virtual link je speciálním, virtuálním typem linky, která je interpretovaná jako neočíslovaná Point-to-Point linka, linka bez IP adresace. OSPF pakety jsou posílány na Unicast adresy uvnitř této virtuální linky. Virtuální link je řešení nestandardního designu. Využívá se v případě, když nemůžeme zajistit, aby Backbone oblast Area byla konzistentní, tedy spojitá, a Virtual link dvě její části propojí do jedné spojité, tak jak je znázorněno na následujícím obrázku. Obrázek č. 10: Virtual link propojující dvě Area 0 v jednu

Virtual Link Area 0 Backbone

Area 1 ABR

Non-Backbone

ABR

Area 0 Backbone


Dále Virtual link využijeme v případě, kdy Non-Backbone oblast není přímo připojena do Backbone oblasti, jak je vyžadováno správným designem, ale je připojena do jiné Non-Backbone oblasti, kde pomocí Virtual link protáhneme Backbone oblast, a tím ji připojíme, jak je znázorněno na následujícím obrázku. Obrázek č. 11: Virtual link připojující Area 2 k Area 0

Virtual Link Area 2 Non-Backbone

Area 1 ABR

Non-Backbone


52

ABR

Area 0 Backbone

2.1.5. Hierarchický model Interní směrovací protokol OSPF se nasazuje do podnikových sítí, kde skupina směrovačů v takovém podniku tvoří doménu, nebo taky AS, kde je jednotná směrovací politika. Pokud je podniková síť rozsáhlejší z hlediska počtu směrovačů, sítí, lokalit a přenášených informací, je zde potřeba aplikovat nějaké členění a hierarchii. OSPF podporuje dvouúrovňovou hierarchii. To znamená, že lze OSPF doménu rozdělit do několika oblastí, tzv. Area, což jsou konfiguračně nastavené logické skupiny sousedních směrovačů. Mezi oblastmi je jedna, která má speciální postavení a význam, nazývá se Backbone Area, má vždy číslo „0“ a tvoří první stupeň hierarchie. Všechny další oblasti k ní musí být přímo připojeny, mohou mít libovolné číselné označení a tvoří druhý stupeň hierarchie. Tak jak je vidět na následujícím obrázku. Obrázek č. 12: Hierarchické člení OSPF domény do oblastí Area OSPF doména první úroveň druhá úroveň

Area 0 Backbone

Area 1

Area 12

Area 33


Takové to členění má několik důvodů a výhod. Snižuje režijní provoz OSPF, jelikož zabraňuje Floodingu, přeposílání všech LSA na všechny směrovače v OSPF doméně. Tím snižuje zatížení CPU (Central Processing Unit) jednotlivých směrovačů a nutnost pokaždé spouštět SPF výpočet. Dalším pozitivním důsledkem je zmenšení jejich Link-State databáze a směrovací tabulky. Všechny tyto zmíněné efekty vedou ke zrychlení celkové konvergence v OSPF doméně.

53

Jakmile se pustíme do hierarchie v OSPF, musíme definovat několik různých typů oblastí, role směrovačů a chování dříve zmíněných několika typů LSA. V OSPF definujeme tyto typy OSPF směrovačů: -

„Internal Router“ (IR) – je směrovač, který má všechna rozhraní v jedné stejné oblasti, jež není Backbone.

-

„Backbone Router“ (BR) – je směrovač mající alespoň jedno rozhraní v Backbone oblasti. Tuto podmínku splňuje každý ABR směrovač a IR v Area 0.

-

„Area Border Router“ (ABR) – je směrovač, který je součástí více oblastí zároveň a jedna z nich musí být Backbone. Propojuje dvě nebo více oblastí mezi sebou.

-

„Autonomous System Border Router“ (ASBR) – je směrovač, jenž je alespoň v jedné jakékoli OSPF oblasti (Backbone, non-Backone) a je na něm zapnuta redistribuce cest z jiného směrovacího protokolu (včetně statických a přímo připojených sítí) do OSPF. ASBR propojuje OSPF doménu s jinými AS. ASBR směrovač nemůže být zároveň IR v Stub oblasti, s výjimkou NSSA (Not-So-Stubby Area), jinak může být jak interním nebo Backbone směrovačem, tak i ABR směrovačem zároveň. Obrázek č. 13: Typy směrovačů v OSPF

Area 0

Area 1

ASBR

ABR Internal Router (IR) Backbone Router (BR) Internal Router (IR)

BGP RIP IGRP EIGRP Static Connected


V OSPF definujeme tyto typy OSPF oblastí: -

„Backbone Area“ – oblast mající výsadní postavení v OSPF hierarchii. přes Area 0 jde veškerá komunikace mezi ostatními oblastmi a všechny oblasti k ní musí být přímo připojeny.

-

„Area“ – oblast, která nemá žádné speciální charakteristiky a omezení.

54

-

„Stub Area“ – oblast, do níž se neposílají externí směrovací informace z redistribuce na ASBR směrovači reprezentované typem LSA 5. Místo toho do Stub Area posílá ABR směrovač „Default rout“ (0.0.0.0).

-

„Totally-Stubby Area“ – oblast, do které se neposílají ani externí směrovací informace z redistribuce na ASBR směrovači reprezentované typem LSA 5, ani inter-area směrovací informace reprezentované typem LSA 3/4 z ostatních oblastí. Místo toho do Totally-Stubby Area posílá ABR směrovač Default Rout (0.0.0.0).

-

„Not-So-Stubby Area“ – oblast mající stejnou charakteristiku jako Stub Area, to znamená, že nepodporuje externí LSA 5, s tím, že je do NSSA oblasti připojen ASBR hraniční směrovač. Jelikož v NSSA není podpora externích LSA 5, jsou externí informace redistribuované ASBR směrovačem do NSSA oblasti přenášena typem LSA 7 a ABR směrovač je konvertuje do Backbone oblasti na standardní externí LSA 5.

-

„Totally Not-So-Stubby Area“ – oblast fungující stejně jako NSSA, akorát navíc do ní neposílají inter-area směrovací informace reprezentované typem LSA 3/4 z ostatních oblastí a ABR směrovač do Totally Not-So-Stubby Area posílá Default rout (0.0.0.0).

Každá oblast Area je tvořena souborem směrovačů majících stejný area identifikátor, jenž je definován 32 bitovým číslem. Všechny směrovače v jedné oblasti musí mít stejnou Link-State databázi. Také platí, že skrz jakoukoli variantu Stub oblasti nelze transportovat Virtual link. Obrázek č. 14: Typy OSPF oblastí Area 2 Stub

NO LSA5 LSA3 DG 0.0.0.0

ABR LSA3/4/5

Area 1 Non-Backbone

ABR

Area 0 ABR Backbone LSA5

External AS

LS A7

ABR LSA3 NO LSA5

Area 4 NSSA


55

Area 3 Totally Stubby NO LSA3/4/5 DG 0.0.0.0

OSPF informace se šíří přesně definovanými typy LSA, přičemž mezi základní zahrnujeme: -

Typ 1 Router Link LSA1 – popisuje stav a cenu linek směrovačů v oblasti. Všechny linky jednoho směrovače jsou popsané v jednom LSA1. LSA1 jsou posílána pouze v oblasti, kde vznikla, ne dále.

-

Typ 2 Network Link LSA2 – je generováno pro každou tranzitní síť typu Broadcast a NBMA a vytváří jej DR směrovač. LSA2 jsou posílána jen v oblasti, kde vznikla, ne dále.

-

Typ 3 Summary Link LSA3 – je vytvářeno ABR směrovačem z LSA1/2 a popisuje sítě mimo lokální oblast. Posílá se do všech oblastí, včetně Stub oblasti, ale mimo Totally Stubby oblasti.

-

Typ 4 Summary Link LSA4 – je informace o ASBR směrovačích a vytváří ho ABR směrovač. Posílá se do oblastí mimo všech variací Stub oblastí.

-

Typ 5 Autonomous Systems (AS) External Link LSA5 – popisuje externí sítě v jiných autonomních systémech a je generováno ASBR směrovačem. Posílá se do oblastí mimo všech variací Stub oblastí.

-

Typ 7 Not-So-Stubby Areas LSA7 – popisuje externí sítě v jiných autonomních systémech a je generováno ASBR směrovačem v NSSA oblasti. Posílá se jen v NSSA oblast a NSSA ABR směrovač ho transformuje na LSA5 a posílá do dalších oblastí které LSA5 podporují. Obrázek č. 15: Posílání jednotlivých typů LSA v OSPF Area 2 Stub LSA1/2 LSA3

Area 1 Non-Backbone LSA1/2 LSA5 ASBR

External AS

LSA3/4/5

ABR Area 0

LSA3 DG 0.0.0.0 LSA3

Backbone

ABR

ABR

LSA1/2/3/4/5

DG 0.0.0.0

LSA3/4/5 LSA3/4/5

LSA7 ASBR

ABR

LSA3

LSA1/2 NSSA

Area 4 Zdroj: vlastní úprava

56

Area 3 Totally Stubby LSA1/2

2.1.6. Zabezpečení OSPF Zabezpečení výměny směrovacích informací je velmi důležitou vlastností každého směrovacího protokolu, který je v současnosti v sítích používán, jelikož je to ochrana proti podvržení neplatných směrovacích informací nebo částečná ochrana proti lidské chybě. OSPF nabízí tři možnosti, a to buď bez zabezpečení anebo dva typy autentifikace. Jednodušší a méně bezpečný způsob pomocí prostého sdíleného textu a druhý bezpečnější pomocí MD5 hash, kontrolního součtu. Použitá hesla musí být shodná mezi sousedy na téže lince, ale mohou být rozdílná v rámci oblasti. OSPF oblast musí být zabezpečena jedním typem autentifikace, ale v rámci OSPF domény mohou být oblasti autentifikovány rozlišnými metodami. OSPF autentifikace je přenášena v záhlaví OSPF paketu. Jsou v ní vyčleněna dvě pole, AuType a Authentication. Pole AuType přenáší informaci, jaký typ autentifikace je použit a může nabývat hodnot: -

Typ 0 Null (no authentication) – bez autentifikace.

-

Typ 1 Simple (clear text) Password Authentication – autentifikace prostým textem.

-

Typ 2 Cryptographic (MD5) Checksum – autentifikace MD5 kontrolním součtem.

Pole Authentication přenáší v případě autentifikace Typu 1 Clear text heslo a v případě autentifikace Typu 2 MD5 hash. V případě autentifikace Typu 2 MD5 algoritmus vypočítá „hash“ hodnotu z obsahu OSPF paketu a hesla, které je nastaveno na rozhraní, vlastní heslo se tak vůbec v OSPF paketu nepřenáší a nelze ho zpětně z MD5 heshe získat.

57

2.2. BGP 2.2.1. Úvod do BGP Směrovací protokol Border Gateway Protocol (BGP), standardizovaný již v roce 1989 v RFC 1105, nahradil původní protokol EGP (Exterior Gateway Protocol) v3, který do té doby zajišťoval směrování mezi AS. Důvodem pro nahrazení protokolu EGP protokolem BGP byla jeho neschopnost vyhovět požadavkům růstu a rozšiřování velkého množství AS a sítí v nich, jež byly čím dále složitěji propojeny. Protokol BGP prodělal značný vývoj od své první verze z roku 1989 až k dnes používané BGP verzi 4 definované v RFC 4271, která je stále rozšiřována o nové vlastnosti. Z hlediska významných vlastností je BGP: -

Dynamický – hybridní (Advanced Distance Vector) směrovací protokol.

-

Externí – zajišťuje převážně výměnu sítí mezi AS.

-

Spolehlivý – přenos updatů pomocí TCP spojení (port 179).

-

Path-Vector – bohatá metrika (Atributy) přiřazené k jednotlivým cestám.

-

Multi-Path – podpora více paralelních cest v síti.

-

Class-Less – podpora CIDR (Classless Inter-Domain Routing).

-

Plochý – bez hierarchického členění.

Primárním účelem směrovacího protokolu BGP je výměna směrovacích informací mezi externími AS. AS lze chápat jako skupinu několika sítí a směrovačů pod jednou technickou správou (skupinou síťových administrátorů), kde je spuštěn typicky jeden interní směrovací protokol a jsou prosazovány jednotné směrovací a filtrovací politiky. Obrázek č. 16: AS a jejich propojení BGP protokolem AS

AS

OSPF BGP


58

EIGRP

Interní směrovací protokoly (např. OSPF, EIGRP…) zajišťují výměnu směrovacích informací uvnitř AS, zatímco externí směrovací protokoly mezi AS. Z pohledu BGP je AS definován unikátním číslem ASN (Autonomus Systém Number), který každý AS dostane přidělený. Přidělování jedinečných čísel AS zajišťuje například mezinárodní organizace RIPE (Réseaux IP Européens). V případě, že není potřeba veřejné číslo AS, je možno pro BGP využít čísel AS z privátního rozsahu. BGP je Advanced Distance Vector směrovací protokol, jelikož TCP protokolem navázaným mezi BGP sousedy zajišťuje spolehlivý přenos směrovacích informací. Tato spolehlivá výměna umožňuje BGP směrovači zaslat sousedovi všechny směrovací informace jen jedenkrát, a to ihned po sestavení BGP spojení se sousedem. Tedy při první výměně směrovacích informací. Běžný Distance Vector IGP (Interior Gateway Protocol) posílá směrovací informace pravidelně, zatímco BGP je posílá jen při změně nebo na vyžádání BGP souseda. BGP si udržuje informace nejen o nejlepší cestě do cílové sítě jejími všemi atributy, ale také i o dalších cestách a jejich atributech do cílové sítě. Z uvedeného důvodu tento BGP mechanizmus nazýváme Path-Vector. Jelikož BGP neposílá směrovací informace v pravidelných intervalech jako některé jiné IGP, je implementován mechanizmu Keepelive, který zajišťuje kontrolu stavu TCP spojení mezi BGP sousedy. Protokol BGP byl designován pro velké sítě, například Internet. Cílem bylo zajistit stabilitu, bezpečnost a ovladatelnost šíření BGP směrovacích informací. Tedy stabilita při výměně velkého množství cest, při relativně častých změnách topologií rozsáhlých sítí, podpora Class-Less směrování se sumarizací a možnost nasazení rozličných směrovacích politik byly hlavními motivátory vývoje BGP protokolu, tak jak ho známe teď. Stále objevující se nové požadavky na nové vlastnosti a funkčnost BGP protokolu je důvodem k jeho dalšímu rozvoji a vylepšování stávajících schopností. Internet je největší nezávislou sítí dnešního světa, kde jediným směrovacím protokolem BGP si tisíce různě velkých ISP a spousta dalších nezávislých společností vyměňují směrovací informace o svých sítích. Velikost Internetu můžeme vyjádřit počtem sítí ve směrovací tabulce směrovače, RIB (Routing Information Base), které musí BGP protokol směrovat. Těch je v současné době více než 450 000. Lze ho vyjádřit i počtem aktivních AS, jichž je více než 43000, jak můžeme vidět na následujících grafech.

59

Obrázek č. 17: Počet aktivních AS v Internetu

Zdroj: http://www.potaroo.net/tools/asn32/, 14. 4. 2013

Obrázek č. 18: Počet sítí směrovaných BGP protokolem v Internetu

Zdroj: http://bgp.potaroo.net/bgprpts/rva-index.html, 14. 4. 2013

60

2.2.2. Použití BGP protokolu Z předchozího úvodu vyplívá, kdo a kde BGP protokol využije. Směrovací protokol BGP využívají především ISP pro výměnu externích směrovacích informací mezi sebou i dalšími AS. ISP jsou zpravidla takové AS, kterými datové pakety jen procházejí do jiných AS, většina provozu v sítích ISP nevzniká ani zde nekončí, jsou to tzv. tranzitní AS. Často také BGP protokol nasazují při výměně směrovacích informací se svými zákazníky, což bývají většinou rozsáhlejší společnosti, které získaly svůj vlastní AS nebo potřebují dvě a více linek k jednomu nebo více různým ISP a potřebují mít datový tok ovladatelný. Společnosti rozdělujeme podle typu připojení k ISP na Single-Home a Multi-Home.

2.2.2.1. Single-Home Případ, kdy má společnost jen jednu linku (připojení) k jednomu ISP, nazýváme jako Single-Home, což je většina případů. V takovém scénáři není nutný BGP protokol a vystačíme s použitím statického směrování mezi společností a ISP. Přesto i v některých takovýchto případech je BGP protokol použit, například, když zákazník má již přidělené vlastní veřejné číslo AS a PI (Provider Independent) IP adresy a chce být vidět jako samostatná entita v Internetu. Obrázek č. 19: Single-Home připojení organizace k ISP

Single-Homing AS AS

Statické směrování

ISP

společnost BGP


61

2.2.2.2. Multi-Home Případ, kdy má společnost dvě a více linek pro připojení k ISP, se nazývá Multi-Home. Tento typ připojení je vyžadován zejména u velkých společností, které mají vysoké požadavky na redundanci a dostupnost svých sítí a služeb. Redundantního připojení je možno využít k jednomu ISP. V takovém případě využijeme BGP, pokud potřebujeme dynamický směrovací protokol pro detekci výpadku linky k ISP. Zde lze využít i privátního AS a PD (Provider Dependent) IP adres. V jednoduchých případech nám postačí i statické směrování. Zvolíme-li připojení k více různým ISP pro zvýšení spolehlivosti připojení a eliminaci případného výpadku celé sítě jednoho z ISP, dynamický směrovací protokol BGP je skoro ve všech případech nezbytný. Zákazník by měl vlastnit veřejné číslo AS a PI IP adresy. Obrázek č. 20: Multi-Home připojení organizace k ISP

Multi-Homing AS AS

ISP

BGP

společnost

AS BGP

ISP


2.2.2.3. Tranzitní AS Tranzitním AS jsou všichni ISP. Ti se mezi sebou různě propojují, aby zajistili propojení svých zákazníků se zbytkem Internetu. Propojení tranzitních AS vyžaduje výměnu

62

směrovacích informací pomocí protokolu BGP. Důvodem je korektní přenos informací o zákaznických sítích, jež se nazývají atributy. Obrázek č. 21: Propojení tranzitních AS ISP

Tranzitní AS AS

AS BGP

ISP

ISP

AS

BGP

BGP ISP


2.2.2.4. eBGP a iBGP BGP je primárně určeno pro výměnu směrovacích informací mezi AS. Navázané BGP mezi dvěma AS nazýváme External BGP (eBGP). S BGP se můžeme potkat i uvnitř jednoho AS a pak ho nazýváme Internal BGP (iBGP). Znázornění obou rozdílných BGP spojení je znázorněno na následujícím obrázku. Interní BGP využijeme hlavně v tranzitních AS anebo v AS, které mají redundantní nejen linky k ISP, ale i redundantní směrovače. Obrázek č. 22: Interní a externí BGP AS 20

AS 10 eBGP

iBGP


63

AS 30 eBGP

2.2.3. Navázání BGP peeringu Jelikož směrovací protokol BGP propojuje různé AS mající zpravidla různé směrovací politiky, jedná se o různé společnosti, tak zde není automatický mechanizmus pro navázání BGP peeringu (spojení) a výměny směrovacích informací. Tento proces musí být pod kontrolou příslušných administrátorů, kteří se o nastavení BGP protokolu starají. BGP směrovací protokol tedy spojení vždy navazuje s jasně definovanými BGP sousedy, na základě nastavených IP adres. Výměna směrovacích informací následně probíhá na základě Unicast komunikace z těchto nastavených IP adres na port 179 protokolu TCP. Oba BGP sousedi iniciují BGP spojení a obě tato spojení musí být úspěšně navázána. Následně zůstane aktivní jen jedna z těchto navázaných TCP komunikací, a to ta, kterou inicioval BGP směrovač s vyšším BGP ID (IDentification), druhé TCP spojení je poté ukončeno. K navázání BGP komunikace a pro udržování spojení s BGP sousedem se používá 4 typů zpráv: -

„Open“ – zpráva slouží pro navázání BGP komunikace a obsahuje verzi BGP protokolu, číslo AS, Hold-Time, BGP ID a další volitelné (Optional) parametry.

-

„Keepelive“ – slouží pro kontrolu stavu BGP souseda, udržování TCP relace a posílá se u Cisco směrovačů standardně každých 60 vteřin.

-

„Update“ – pomocí nichž se posílají vlastní směrovací informace, NLRI (Network Layer Reachability Information), a to nové sítě nebo sítě, které se mají odstranit, a změněné Path-Attributes.

-

„Notification“ – slouží pro přenos chybových zpráv, nestandardních situací nebo při ukončení BGP spojení.

Vlastní navázání BGP peeringu začíná ve stavu Idle, prochází několika dalšími definovanými stavy a úspěšně končí stavem Established. Stavy, jimiž BGP prochází, jsou: -

„Idle“ – je počáteční stav BGP nebo se v něm nachází BGP spojení v případě, že směrovač neví, jak se dostat k definovanému BGP sousedovi nebo z nějakého důvodu se BGP spojení nepodařilo zdárně uskutečnit. Následujícím stavem je stav Connect.

-

„Connect“ – v tomto stavu BGP směrovač čeká na první sestavení TCP spojení s BGP sousedem. Následujícím stavem je stav OpenSent nebo Active.

64

-

„Active“ – v tomto stavu BGP směrovač čeká při dalších pokusech o sestavení TCP spojení s BGP sousedem, tedy v případě prvního neúspěšného sestavení spojení ve stavu Connect, a to po dobu 4 minut – Connect Retry timer. Následujícím stavem je stav Connect nebo OpenSent.

-

„OpenSent“ – v tomto stavu BGP směrovač posílá Open zprávu, čeká na Open zprávu od BGP souseda a po její obdržení provádí její kontrolu Je-li vše v pořádku, posílá se Keepelive a nastavuje se Hold time na nižší hodnotu. Následujícím stavem, pokud je vše v pořádku, je stav OpenConfirm.

-

„OpenConfirm“ – v tomto stavu BGP směrovač čeká na Keepalive nebo Notification od BGP souseda. V případě obdržení zprávy Keepalive, je následující stav Established, ale v případě obdržení zprávy Notification, je následující stav Idle.

-

„Established“ – tento stav BGP spojení znamená, že všechny fáze navázání BGP peeringu proběhly v pořádku a BGP je sestaveno. Následně je možné zahájit výměnu směrovacích informací pomocí zpráv Update, posílat pravidelné zprávy Keepalive nebo servisní chybové zprávy Notification.

Jednotlivé zmíněné stavy a jejich vzájemné vztahy jsou znázorněny na vývojovém grafu níže. Obrázek č. 23: Vývojový diagram navázání BGP peeringu

Zdroj: http://en.wikipedia.org/wiki/Border_Gateway_Protocol, 30. 3. 2013

65

2.2.4. Path-Vector atributy BGP při výměně směrovacích informací (NLRI) pro každou přenášenou síť má připojeny další dodatečné informace nazývající se Path-Attributes. U BGP hovoříme o „bohaté metrice“, jelikož na základě většiny atributů BGP vybírá nejlepší cestu do cílové sítě. Podobně jako většina interních směrovacích protokolů využívá svoji specifickou metriku, typicky jednu hodnotu, pro nalezení nejlepší cesty. Ne všechny atributy jsou ale v BGP využity k výběru nejlepší cesty, neboť některé jsou pouze informativní nebo slouží k jiným účelům.

2.2.4.1. Typy atributů Atributy můžeme rozdělit do dvou základních skupin: -

„Well-Know“ – jsou atributy, které musí být rozpoznány všemi implementacemi BGP protokolu, a jsou tedy všeobecně podporované.

-

„Optional“ – jsou atributy, jež nemusí být rozpoznány všemi implementacemi BGP protokolu, a jsou tedy volitelné, mohou být proprietární a neočekává se, že budou rozpoznány všemi implementacemi.

Well-Known atributy se dělí dále na: -

„Mandatory“ – mezi atributy, které musí být obsaženy ve všech BGP updatech, patří: o AS-Path o „Next-Hop“ o “Origin“

-

„Discretionary“ – atributy, které jsou volitelné, mohou se objevit v updatech, avšak nemusí, zahrnují: o „Local Preference“ o „Atomic Aggregate“

Optional atributy se dělí dále na: -

„Transitive“ – atributům, jež jsou propagovány ostatním BGP sousedům, i v případě, nejsou-li rozpoznány, se nastaví „Partial bit“ z důvodu indikace, že tyto

66

atributy nebyly v cestě rozpoznány. V případě rozpoznání jsou propagovány beze změny, jsou to: o „Aggregator“ o “Communities” o „AS4_AGGREGATOR“ a AS4_PATH“ -

„Non-Transitive“ – atributy, nejsou-li rozpoznány, jsou zahozeny (BGP Update jich bude zbaven), rozpoznané Optional atributy jsou propagovány ostatním sousedům na základě jejich významu a jsou to: o „Multi_Exit_Discriminator“ (MED) o „Cluster-List“ o „Originator-ID“

Výčet atributů výše není úplný, ale jede o atributy nejčastěji používané a některé z nich jsou dále detailněji popsané.

2.2.4.2. AS-Path Jeden ze dvou nejdůležitějších atributů je Well-Know, Mandatory atribut AS-Path. V atributu AS-Path se zaznamenávají čísla AS, kterými BGP cesta prošla. Atribut AS-Path je prázdný, když je lokální cesta vložena do BGP. Lokální číslo svého AS je připojeno do AS-Path atributu BGP směrovačem v momentě, kdy je BGP update odeslán do sousedního AS, přes eBGP. V případě, že se BGP update posílá uvnitř jednoho AS, přes iBGP, do AS-Path atributu se číslo AS nezaznamenává. Ve většině případů BGP vybere za nejlepší cestu do cílové sítě tu, která má nejkratší AS-Path, tedy prošla nejmenším počtem AS. To bude detailněji popsáno v kapitole „2.2.5.3 Výběr nejlepší BGP cesty“. Výběr na základě nejkratší AS-Path nastává zpravidla, pokud nijak výběr cesty neovlivňujeme a necháme ho ve standardním stavu. Příjemce BGP směrovací informace může použít AS-Path atribut k určení, přes které AS vede cesta do cílové sítě, a na základě toho může aplikovat svoji směrovací politiku. Důvodem, proč je AS v BGP AS-Path reprezentován jako jeden „hop“, je skrytí topologických detailů uvnitř AS. AS-Path atribut je základem pro detekci vzniku smyčky v síti a BGP proces na jeho základě dokáže zacyklení zabránit. Jedná se o „Loop Detection“ mechanizmus. Funguje tak, že pokud přijme AS update se směrovací informací, kde v atributu AS-Path je číslo

67

jeho vlastního AS, tak tento update ignoruje a zahodí ho. Tato situace je znázorněna na následujícím obrázku. Obrázek č. 24: Detekce směrovací smyčky v BGP pomocí AS-Path

BGP AS-Path loop detection

AS 20

AS 10

NLRI=10.0.0.0/8 AS-Path=20 10

.0/8 .0.0 I=10 10 R L N ath= AS-P

10.0.0.0/8 NLR AS-P I=10.0 ath= .0.0/ 8 30 2 0 10

AS 30

Zdroj: [10] www.cisco.com, vlastní úprava

2.2.4.3. Next-hop Druhý z nejdůležitějších Well-Know, Mandatory atributů je atribut Next-Hop. IP adresa, na kterou se posílají data do cílové sítě, se přenáší právě v atributu Next-Hop. V atributu Next-Hop se IP adresa v průběhu cesty mění na základě jasně definovaných pravidel a nastavení BGP směrovačů. Next-Hop IP adresa je zpravidla nastavena na IP adresu odesílajícího rozhraní BGP směrovače a to v případě eBGP spojení. Může být však nastaven i na jinou IP adresu a to kvůli optimalizaci posílání datového provozu do cílové sítě. Toto nastává v případě, kdy Next-Hop IP adresa má být nastavena na jinou Next-Hop IP adresu, která však je ze stejné IP sítě jako již nastavená Next-Hop IP adresa, jak je vidět na příkladu v následujícím obrázku. Směrovač „A“ v AS 20 při posílání cesty 10.0.0.0/8 do AS 40 nemění Next-Hop adresu na 123.0.0.2, což je jeho odchozí rozhraní, ale ponechává v atributu adresu 123.0.0.1, jelikož je ze stejné IP sítě jako jeho rozhraní, zatímco do AS 30 Next-Hop adresu mění standardním způsobem na IP adresu svého odchozího rozhraní. Datový provoz z AS 40 do AS 10 jde optimální cestou přímo, přesto z hlediska směrování vidíme v cestě i AS 20.

68

Atribut Next-Hop se standardně nemění při posílání BGP updatu přes iBGP spojení, pokud není BGP konfiguračně nastaveno jinak. Obrázek č. 25: Změna IP adresy v atributu Next-Hop

iBGP

AS 20

NLRI=10.0.0.0/8 Next-Hop=123.0.0.1

Ne NL xt- RI= Ho 10 p = . 0. 11 0.0 1. 0 / 8 .0. 2

111.0.0.0/24

.3

.2

AS 30

.0.0.0/8 NLRI=10 .0.0.1 p=123 Next-Ho .1 .2 123.0.0.0/24 /8 0.1 0.0 3.0. . 0. 10 =12 RI= op NL xt-H Ne

A

eBGP

AS 10 10.0.0.0/8

datový provoz

AS 40 .4


2.2.4.4. Origin Třetím a posledním Well-Know, Mandatory atributem, ale spíše již historickým, je atribut Origin. Atribut Origin obsahuje informaci o tom, jak se do BGP dostala informace o cílové síti. V případě, že BGP směrovač zná více cest do jedné cílové sítě, může atribut Origin ovlivnit rozhodnutí, která z cest bude preferovaná. Atribut Origin může nabývat tří hodnot: -

„IGP“ – cesta byla naučena z IGP v původním AS, v BGP tabulce je označená „i“ a má nejvyšší preferenci.

-

„EGP“ – cesta byla naučena z EGP v původním AS, v BGP tabulce je označená „e“, hodnota EGP je preferována po IGP.

-

„Incomplete“ – cesta byla redistribuovaná do BGP, v BGP tabulce je označená „?“, má nejnižší preferenci.

Pořadí

preference

hodnot

atributu

Origin

můžeme

vyjádřit

„IGP (i) < EGP (e) < Incomplete (?)“, kdy nižší hodnota je preferovanější.

69

vztahem

2.2.4.5. Local Preference Local Preference je Well-Know, Discretionary atribut, jenž je použit pro výběr cesty uvnitř AS a pomáhá snadněji prosadit jednotnou směrovací politiku uvnitř tohoto AS. Jednoduchost spočívá v tom, že stačí změnit hodnotu Local Preference na jednom BGP směrovači, který tuto informaci pomocí iBGP přepošle všem ostatním, namísto toho, abychom nastavovali nebo měnili směrovací politiku na všech směrovačích v AS. Atribut Local Preference se nastavuje na defaultní hodnotu při obdržení cesty přes eBGP a je posílán jen přes iBGP uvnitř AS. Hodnotu Local Preference můžeme změnit na BGP směrovači při přijmu nebo odeslání BGP updatu. Cesta s nastavenou vyšší hodnotou Local Preference je více preferovaná uvnitř AS. Jak můžeme vidět na obrázku, AS 40 dostává informaci o síti 10.0.0.0/8 z AS 10 ze tří směrů. Standardně by si všechny směrovače v AS 40 vybraly cestu do sítě 10.0.0.0/8 s nejkratší AS-Path, tedy přes směrovač „A“. Tím, že jsme na směrovači „C“ nastavili hodnotu Local Preference na vyšší hodnotu 150, a směrovače si tuto informaci pomocí iBGP mezi sebou vyměnily, ovlivnili jsme výběr cesty v AS 40 tak, že směrovač „A“ i „B“ budou posílat data do sítě 10.0.0.0/8 přes směrovač „C“, jak naznačují zelené šipky. Obrázek č. 26: Ovlivnění výběru cesty atributem Local Preference

AS 40

AS 30

NLRI=10.0.0.0/8 AS-Path=30 20 10

LP 150 C

LP 100 A

NLRI=10.0.0.0/8 AS-Path=10

AS 10 10.0.0.0/8

LP 100 B 8 0/ .0. 10 0.0 th= I=1 S-Pa R NL A

NLRI=10.0.0.0/8 AS-Path=20 10

NL R AS I=1 - P 0. 0 at .0 h= . 0 20 /8 10

AS 20 Zdroj: vlastní úprava

70

2.2.4.6. Atomic Aggregate Atomic Aggregate je také Well-Know, Discretionary atribut, který se k cestě zapíše v případě, že provedeme agregaci nebo také sumarizaci, sloučení více cest do jedné, a upozorňuje nás na ztrátu některých informací, například informací z atributu AS-Path u sumarizovaných cest. Agregace nám tak skryje topologické informace při sumarizaci několika cest tím, že dojde k vytvoření nové cesty, jež má atribut AS-Path prázdný. Tím by také mohlo dojít v některých případech k zacyklení nebo jiným incidentům, proto se přidává atribut Atomic Aggregate indikující ztrátu některých informací. V případě, že zajistíme přenesení informací z atributu AS-Path sumarizovaných cest do AS-Path nové cesty, atribut Atomic Aggregate se nenastavuje. Obrázek č. 27: Nastavení atributu Atomic Aggregate při BGP sumarizaci .0/ .0.1 I=10 NLR ath=10 AS-P 24

NLRI=10.0.0.0/8, AS-Path=„ “, Atomic-Aggregate

NLR I AS-P =10.0.3 .0 ath= 30 /24

NLRI=10.0.2.0/24 AS-Path=20


2.2.4.7. Aggregator S atributem Atomic Aggregate nepřímo souvisí i atribut Aggregator, který je Optional, Transitive. Atribut Aggregator se přiřazuje k cestě také v případě sumarizace cest v BGP. Atribut Aggregator obsahuje informace o tom, ve kterém AS byla sumarizace aplikována, a IP adresu BGP směrovače, na němž sumarizace vznikla. Tyto informace se dají využít v případě hledání příčin některých směrovacích incidentů spojených s BGP sumarizací.

71

2.2.4.8. Multi Exit Discriminator Další Optional, Non-Transitive atribut je Multi Exit Discriminator (MED). Atribut MED je metrika, tak jak je známá u interních směrovacích protokolů. Stejně jako u metriky IGP, tak i u atributu MED platí, že nižší hodnota je preferovanější, jelikož indikuje, jak daleko je cílová síť. K BGP cestě se hodnota atributu MED dostane tak, že se do něj překopíruje aktuální hodnota metriky IGP cesty, která se do BGP na směrovači vkládá. Atribut MED se posílá přes iBGP a přes eBGP spojení jen v případě, pokud BGP cesta pochází z lokálního AS. V případě, že BGP cesta nepochází z lokálního AS, tak se standardně přes eBGP neposílá a z BGP updatu se odstraňuje. Výjimkou je případ, kdy hodnotu MED konfiguračně nastavujeme na nějakou námi definovanou hodnotu. Atribut MED můžeme využít k ovlivnění výběru cesty v sousedním AS, to znamená, že ovlivníme výběr cesty pro návratový provoz do našeho AS. Atributem MED ukazujeme našemu sousednímu AS, kterou návratovou cestu preferujeme a kterou by měl použít. Atribut MED je ovšem relativně slabá metrika a sousední AS má několik možností, jak nám poslat provoz dle jeho definované směrovací politiky, bez ohledu na to, jakou hodnotu atributu MED dostává. Obrázek č. 28: Ovlivnění návratového provozu atributem MED

AS 10 A

AS 20 C

eBGP B

FE

D

NLRI=10.0.0.0/8 MED=50

10.0.0.0/8

NLRI=10.0.0.0/8 MED=50 GE

NLRI=10.0.0.0/8 MED=150

Zdroj:[10] www.cisco.com, vlastní úprava

Na obrázku výše vidíme situaci, kdy AS 10 posílá ze směrovače „A“ cestu s atributem MED 50 a ze směrovače „B“ cestu s atributem MED 150, jelikož chce preferovat rychlejší GE (Gigabit Ethernet) linku před FE (Fast Ethernet) linkou. Směrovače v AS 20 si tuto

72

informaci také vymění přes iBGP a pokud nemají nastavenu jinou směrovací politiku, provoz do AS 10 budou posílat na základě nižší hodnoty v atributu MED přes GE linku mezi směrovačem „A“ a „C“, jak naznačuje zelená šipka. Obdrží-li směrovače v jednom AS atribut MED z několika různých AS, standardně je mezi sebou neporovnávají. Toto chování se dá ve specifických případech pomocí konfigurace BGP protokolu změnit.

2.2.4.9. Communities Community je Optional, Transitive atribut. Atribut Community je značka ve formě 32 bitového čísla, která se přidá k BGP cestě. Sama o sobě nemá žádný specifický význam a záleží na administrátorovi, jaký význam přiřazené číselné značce, Community, přidělí. Ve výsledku tedy Communities můžou vyjadřovat skoro libovolnou informaci o BGP cestě uvnitř nebo mezi AS. Administrátor tak vytvoří skupinu BGP cest, kterou identifikuje vytvořená Community. Na základě Communities můžeme směrovací informace v BGP filtrovat, preferovat, měnit nebo jim přidávat nové parametry a atributy, případně realizovat s nimi další manipulace. Takovýchto značek, Communities, může být k jedné BGP cestě přiřazeno i více najednou. Několik Communities je definováno jako Well-Known Communities, které již mají přesně daný význam. Jedná se o tyto čtyři Communities: -

„NO_EXPORT“ (4294967041 nebo 0xFFFFFF01) – cesta, která má nastavenu tuto hodnotu se nepošle žádnému BGP směrovači přes eBGP, ale pošle se do Sub-Confederation AS a také všem BGP směrovačům přes iBGP.

-

„NO_ADVERTISE“ (4294967042 nebo 0xFFFFFF02) – cesta mající nastavenu tuto hodnotu se nepošle žádnému dalšímu BGP směrovači.

-

„NO_EXPORT_SUBCONFED“ (4294967043 nebo 0xFFFFFF03) – cesta, jež má nastavenu tuto hodnotu se nepošle žádnému BGP směrovači přes eBGP, ani se nepošle do Sub-Confederation AS, ale pošle se BGP směrovačům přes iBGP, tedy pouze v rámci lokálního AS.

-

„INTERNET“ – je všeobecná Community, do které patří všechny BGP cesty a nemá specifickou hodnotu.

73

Na obrázku je naznačeno, přednastavené chování BGP směrovačů v případě, že obdrží BGP cesty s nastaveným atributem Communities. Směrovač „A“ na obrázku obdržel čtyři BGP cesty, kde každá reprezentuje jednu z Well-Known Communities. Je patrné, že směrovač „A“ přeposílá všechny BGP cesty přes iBGP směrovači „B“ až na tu, která má přiřazenu značku NO_ADVERTISE, tu, jak je popsané výše, nepošle přes žádnou BGP relaci dále. Směrovač „B“ ze zbývajících tří obdržených BGP cest přeposílá všechny BGP cesty přes Intra-Confederation eBGP směrovači „C“ až na tu, jež má přiřazenu značku NO_EXPORT_SUBCONFED. Směrovač „C“ ze zbývajících dvou BGP cest přeposílá přes eBGP do sousedního AS jen tu, která nemá přiřazenu značku NO_EXPORT. Tyto tři zmíněné Well-Known Communities“ jsou z hlediska propagace restriktivní a každý BGP směrovač standardně ví, jakým způsobem má podle nich filtrovat. Obrázek č. 29: Propagace BGP sítí na základě Well-Know atributů Communities NLRI=2.0.0.0/8 Com.=NO_ADVERTISE

NLRI=3.0.0.0/8 Com.=NO_EXPORT_SUBCONFED

B

NLRI=4.0.0.0/8 Com.=INTERNET

Co

m NLR .= I= NO 1. _ E 0. 0 XP . 0 / N OR 8 Co L R I m =4 T . = .0 IN .0 TE .0 RN /8 ET

AS 30

Co NLR m I=4 . = .0 IN .0 TE . 0 RN /8 ET

NLRI=1.0.0.0/8 Com.=NO_EXPORT

NLRI=1.0.0.0/8 Com.=NO_EXPORT

C

AS 22

A

AS 10

NLRI=3.0.0.0/8 Com.=NO_EXPORT_SUBCONFED

NLRI=4.0.0.0/8 Com.=INTERNET

AS 21

AS 20


2.2.5. BGP v akci Jakmile je navázáno BGP spojení, může začít vlastní výměna směrovacích informací a udržování jejich aktuálnosti. Tento proces probíhá po celou dobu co má BGP směrovač navázáno spojení alespoň s jedním BGP sousedem. Zmíněný proces můžeme rozdělit do několika fází nebo v různých intervalech opakujících se činností, jak je vidět na obrázku níže. Uvedené činnosti jsou: -

Příjem směrovacích BGP updatů.

-

Vytvoření BGP tabulky.

-

Výběr nejlepší BGP cesty.

74

-

Propagace nejlepších BGP cest.

-

Vytvoření/update IP směrovací tabulky.

-

Propagace lokálních sítí do BGP. Obrázek č. 30: BGP v akci

8

0.0 /

1.0 . PF OS

NLRI=10.0.0.0/8 Attr... NLRI=20.0.0.0/8 Attr... ... Příjem směrovacích BGP updatů

BGP table: *NLRI=1.0.0.0/8 Attr... *NLRI=10.0.0.0/8 Attr... *NLRI=20.0.0.0/8 Attr... … Vytvoření BGP tabulky

Update IP směrovací tabulky

/8 0.0 /8 .0. 10 0.0.0 . PBG P - 20 BG

Propagace lokálních sítí do BGP

Routing table (RIB): OSPF - 1.0.0.0/8 BGP - 10.0.0.0/8 BGP - 20.0.0.0/8 …

Best Route Selection

NLRI=1.0.0.0/8 Attr... NLRI=10.0.0.0/8 Attr... NLRI=20.0.0.0/8 Attr... ... Propagace nejlepších BGP cest

Výběr nejlepší BGP cesty


Jednotlivé fáze a činnosti jsou detailněji rozepsány dále v jednotlivých kapitolách.

2.2.5.1. Příjem směrovacích BGP updatů Jak již bylo zmíněno, po sestavení BGP spojení dojde k výměně celých BGP tabulek mezi BGP sousedy. Po této počáteční výměně si BGP sousedé vyměňují už jen změny v BGP tabulkách, tedy informace o nově naučených BGP cestách, o cestách, které přestaly platit a již nejsou dostupné, nebo o změnách v jejich parametrech. Vyvolat znovu poslání celé BGP tabulky se dá i manuálním příkazem administrátora v případě změny směrovací politiky. Také již bylo zmíněno, že u každé BGP cesty musí být minimálně 3 Well–Know Mandatory Path-Attributes. Jsou to AS-Path, Next-Hop a Origin. BGP směrovač při přijetí updatu kontroluje, zda některá z cest neobsahuje v atributu AS-Path vlastní číslo AS a nejedná se o směrovací smyčku.

75

2.2.5.2. Vytvoření BGP tabulky Všechny BGP cesty od všech BGP sousedů, které nebyly zakázány (detekce smyčky, filtry…), jsou vkládány do BGP tabulky. BGP tabulka obsahuje i několik různých cest od různých BGP sousedů do jedné cílové sítě a každá z těchto cest může, respektive má, jiné atributy a parametry, na základě kterých BGP směrovač cesty mezi sebou porovnává a vyhodnocuje. Při každé změně BGP tabulky se mění i číslo verze BGP tabulky, které následně slouží k tomu, aby byla kontrola, jaká je aktuální lokální verze BGP tabulky a jestli směrovač všem BGP sousedům poslal poslední verzi své BGP tabulky.

2.2.5.3. Výběr nejlepší BGP cesty Jakmile BGP směrovač obdrží a zpracuje BGP update a vloží z něj cesty cílových sítí do BGP tabulky, musí pro každou cílovou síť vybrat nejlepší známou cestu. Proces vyhodnocování se nazývá „Best Path Selection“ a provádí se na základě BGP Path-Attributes. BGP směrovač při výběru nejlepší cesty do cílové sítě atributy vyhodnocuje vždy v přesně daném pořadí. Než je však začne vyhodnocovat, tak z výběru vyřadí cesty, které nemají platnou Next-Hop IP adresu, respektive ty, u kterých směrovač neví, jak se k IP adrese v Next-Hop atributu dostat, což nastane, když síť Next-Hop IP adresy nemá v IP směrovací tabulce, RIB. Dále vyřadí cesty, jež nejsou synchronizovány, je-li synchronizace zapnuta. Synchronizace je proces, kdy BGP kontroluje, jestli cesty naučené přes iBGP spojení jsou známy ve směrovací tabulce pomocí nějakého interního směrovacího protokolu, IGP. Tato kontrola má zabránit vzniku směrovacích černých děr uvnitř AS. Synchronizace je však již historická záležitost vycházející z dřívějších návrhů a praktik při zajištění směrování uvnitř AS a to v důsledku malé výkonnosti směrovačů. Dnes se synchronizace již téměř nepoužívá, jelikož výkonnost směrovačů je dostatečná a praktikují se již jiné a moderní principy návrhů směrování uvnitř AS. Po kontrole Next-Hop adres a synchronizaci se BGP směrovač dostává k vlastnímu výběru Best Path Selection na základě BGP Path-Attributes. V případě, že první nebo jakékoli další pravidlo/atribut nerozhodne, jelikož cesty mají stejnou hodnotu atributu nebo pravidlo nelze použít, přechází se bez rozhodnutí na následující rozhodovací kritérium.

76

Vyhodnocení se provádí v tomto pořadí: -

Preferuj nejvyšší Weight (lokální rozhodnutí na směrovači) – atribut Weight nebyl zmíněn, neboť se neposílá v žádném BGP updatu, je to lokální nástroj administrátora, kterým může manuálně ovlivnit lokální výběr cesty, aniž by ovlivnil jiné směrovače. Atribut je Cisco proprietární.

-

Preferuj nejvyšší Local Preference (globální rozhodnutí uvnitř AS) – atribut funguje tak, jak je popsáno v kapitole „2.2.4.5 Local Preference“.

-

Preferuj cestu pocházející z lokálního směrovače – v případě, že Local Preference je stejná a nerozhodně, bude směrovač preferovat tu cestu, kterou se naučil přes některý IGP. Toto není informace ve smyslu atributu, ale říká, jestli síť byla na tomto směrovači vložena do BGP příkazem network nebo agregací.

-

Preferuj cestu s kratší AS-Path – směrovač porovná počet AS, jež jsou v cestě do cílové sítě. AS jsou do AS-Path zapisovány tak, jak je popsáno v kapitole „2.2.4.2 AS-Path“.

-

Preferuj nejnižší Origin atribut – zde platí IGP (i) < EGP (e) < Incomplete (?), tak jak je popsáno v kapitole „2.2.4.4 Origin“.

-

Preferuj nejnižší MED – jak je zmíněno v kapitole „2.2.4.8 Multi Exit Discriminator“, je MED metrikou, tak jak ji známe u IGP.

-

Preferuj eBGP cesty před iBGP cestami.

-

V případě, že se jedná o iBGP cesty, preferuj cesty s kratší cestou k BGP Next-Hop adrese, což je cesta s nižší IGP metrikou k Next-Hop směrovači.

-

V případě, že se jedná o eBGP cesty, preferuj nejstarší cestu – směrovač preferuje stabilnější cestu do cílové sítě.

-

Jestliže ani jedno z pravidel nerozhodne, preferuj cestu s nižším BGP Router ID. V případě použití RR (Route Reflector) atributu se použije Originator ID.

-

Jestliže Router ID nebo Originator ID jsou stejné, použije se cesta, jež má kratší Cluster-list.

-

V případě, že žádné z pravidel nerozhodlo o výběru nejlepší cesty, použije se ta, která má nižší Neighbor adresu. To je IP adresa BGP souseda, na níž je navázáno BGP TCP spojení.

Tento proces Best Path Selection může být modifikován některými konfiguračními úpravami BGP protokolu. Zdroj: [10] www.cisco.com.

77

2.2.5.4. Propagace BGP cest Jen nejlepší cesty vybrané BGP pomocí procesu Best Path Selection, což je vždy jen jedna do jedné cílové sítě, jsou vloženy do BGP updatu a odeslány sousedním BGP směrovačům. Platí zde již dříve zmíněné, že BGP posílá kompletní update jen po sestavení BGP peeringu, poté posílá jen inkrementální změny, nebo na manuální vyžádání BGP sousedem. V případě posílání inkrementálních změn jsou BGP updaty posílány pro eBGP kumulovaně jednou za 30 vteřin a u iBGP jednou za 5 vteřin. Obsah BGP updatu může být také modifikován aplikovanými filtry, takže některé z vybraných „Best Rout“ nemusí být sousedu odeslány.

2.2.5.5. Vytvoření/update IP směrovací tabulky Nejlepší cesty, jež BGP vybere pomocí procesu Best Path Selection, jsou vloženy do IP směrovací tabulky. V případě, že v BGP je povolen BGP Multi-Path, může BGP do směrovací tabulky vložit i další cesty, které mají shodné parametry Weight, Local Preference, délku AS-Path, Origin, MED. Další drobné podmínky, jež je potřeba splnit, jsou závislé na tom, zda se jedná o iBGP nebo o eBGP Multi-Path. Než jsou BGP cesty vloženy do IP směrovací tabulky, ještě se zjišťuje, zda některý jiný směrovací protokol s nižší AD nezná stejné cílové sítě. Zná-li jiný směrovací protokol stejnou cílovou síť, je do směrovací tabulky vložena ta cesta, která je ze směrovacího protokolu s nižší AD. AD eBGP je standardně nastavena na hodnotu 20, zatímco iBGP má standardní hodnotu AD nastavenu na 200. AD je detailněji popsána v mé bakalářské práci [5] NAUŠ, Dalibor. Směrování v lokálních a globálních sítích. Praha, Duben, 2011. Bakalářská práce. Bankovní institut vysoká škola Praha. Vedoucí práce [Ing.] Vladimír Beneš.

2.2.5.6. Propagace lokálních sítí do BGP Chceme-li nějakou z našich sítí vložit a propagovat protokolem BGP sousedům, máme dvě základní možnosti. První je příkazem network a druhá možnost je využít redistribuci. Příkaz network v BGP funguje odlišně od IGP protokolů, v nichž příkazem network spouštíme IGP protokol na všech lokálních rozhraních směrovače, které příkaz network 78

v sobě zahrnuje. V BGP je proces „BGP Router“, jenž pravidelně (každou vteřinu) kontroluje směrovací tabulku, RIB, směrovače, a v případě, že se v směrovací tabulce specifikovaná síť objeví, vloží tuto síť do BGP protokolu. Do BGP je vložena jako lokální síť, přestože tato síť může být naučena jakýmkoli IGP nebo to může být statická routa. Nemusí se tedy jednat jen o sítě na lokálních rozhraních směrovače. Tyto sítě následně BGP propaguje sousedům dle nastavených BGP pravidel a filtrů. Jestliže se ze směrovací tabulky síť ztratí, odstraní se i z BGP. Redistribuce je druhou možností pro případ, že chceme do BGP dynamicky vkládat všechny nebo většinu sítí z nějakého zdroje směrovacích informací, což mohou být IGP protokoly (např. RIP, OSPF, ISIS…), statické routy nebo přímo připojené sítě. V BGP si vybereme jeden nebo více zdrojů směrovacích informací a všechny IP sítě ve směrovací tabulce naučené vybraným protokolem vložíme do BGP. Výhodou je, že nemusíme definovat velké množství jednotlivých sítí, nevýhodou může být nekontrolovatelná propagace sítí z IGP do BGP. Kontrolu takto dynamicky redistribuovaných sítí do BGP můžeme zajistit použitím ACL (Access Control Lists) nebo Route-Map. Ztratí-li se některá síť naučená vybraným IGP ze směrovací tabulky, odstraní se i z BGP.

2.2.6. Zabezpečení BGP Zabezpečení BGP tak jako i jiných směrovacích protokolů je důležitou součástí celkové bezpečnosti v síťovém prostředí a BGP můžeme zabezpečit pomocí několika metod, podle hrozby jíž chceme eliminovat. Metody zabezpečení BGP protokolu jsou zejména: -

Infrastrukturní ACL (Access Control Lists) nebo uRPF (unicast Reverse-Path Forwarding).

-

MD5 autentifikace.

-

TTL Security.

-

BGP přes IPSec (IP Security).

-

Secure Origin BGP (soBGP).

Častěji používané metody jsou dále podrobněji popsány či znázorněny.

79

2.2.6.1. Infrastrukturní ACL a uRPF Možnostmi jak zabezpečit BGP Control Plane v infrastruktuře jsou například Access Control Lists (ACL) nebo unicast Reverse-Path Forwarding (uRPF) nasazené na BGP směrovačích nebo v celé infrastruktuře. ACL se dají dobře využít pro definici IP adres, z nichž mohou, nebo naopak nesmějí, být BGP sousedé. ACL se aplikují, pokud máme jednotný IP prostor, se kterým pracujeme, což je většinou u iBGP. U eBGP je to však více administrativně náročné zejména na udržování aktuálnosti při různých změnách. Zabezpečení pomocí ACL se doporučuje kombinovat s dalšími možnostmi zabezpečení BGP. Vlastnost uRPF zajistí, že směrovač po zapnutí kontroluje přicházející pakety a v nich jejich zdrojové IP adresy a porovnává je se záznamy ve směrovací tabulce, RIB. Funkci můžeme vidět na obrázku níže, kde v prvním případě přijde IP paket ze zdrojové adresy „SA“ přes rozhraní „int.1“. uRPF zkontroluje oproti směrovací tabulce, zda zdrojová adresa „SA“ je směrovaná přes rozhraní „int.1“. Výsledkem je shoda a IP paket může být odeslán dle cílové adresy „D“. Zatímco v druhém případě přijde IP paket ze zdrojové adresy „SB“ přes rozhraní „int.1“. uRPF zkontroluje oproti směrovací tabulce, zda zdrojová adresa „SB“ je směrovaná přes rozhraní „int.1“. Výsledkem není shoda a IP paket bude zahozen. Obrázek č. 31: Funkce unicast Reverse-Path Forwardingu

Routing table (RIB): Dest Path SA int. 1 SB int. 2 … SZ int. null0 int. 1 SA D data

Routing table (RIB): Dest Path SA int. 1 SB int. 2 … SZ int. null0

int. 3 int. 2

int. 1

SA D data

int. 3 int. 2

SB D data

SB D Source IP =/= rx int.

ta

OK

da

Source IP = rx int.

DROP


80

Tím je například ošetřen případ, kdy by se útočník snažil podvrhnout BGP pakety z internetu a zdrojová adresa byla z našeho interního IP rozsahu.

2.2.6.2. MD5 autentifikace BGP můžeme zabezpečit pomocí MD5 autentifikace. Autentifikují se TCP pakety přenášející BGP informace. Nejde zde však o zabezpečení obsahu BGP paketů před jejich přečtením, ale o autenticitu odesílajícího směrovače a znemožnění pozměnění nebo podvržení neplatných BGP informací. MD5 autentifikace je prováděna na základě shodného klíče mezi dvěma BGP sousedy. Vlastní klíč není mezi BGP sousedy přenášen, ale na základě klíče je matematickou operací MD5 vypočtena hash, která je připojena k odesílanému TCP paketu BGP směrovačem. Přijímající BGP směrovač provede stejnou matematickou operaci za použití svého klíče a porovná obě MD5 hashe. V případě, že přijatá i vypočítaná MD5 hash je shodná, BGP paket je normálně zpracován. Není-li MD5 hash shodný, je paket zahozen. Přesná specifikace zabezpečení BGP spojení pomocí „TCP MD5 Signature Option“ je popsána v RFC 2385, respektive nově v RFC 5925 „TCP Authentication Option“.

2.2.6.3. TTL Security Dalším zabezpečením BGP TCP spojení prostřednictvím Time To Live (TTL), před útokem spočívajícím v podvržení BGP dat je metoda „TTL Security“. Jedná se o zabezpečení eBGP TCP spojení. U eBGP spojení zpravidla platí, že BGP sousedé jsou přímo propojeni na jedné L3 síti. Z hlediska TCP spojení je to 1 hop, kdy se TTL hodnota v IP paketu sníží právě o 1. Spojení eBGP standardně generuje IP pakety s TTL = 1. TTL Security vychází z obecného mechanismu, kdy každý L3 prvek (typicky směrovač) v IP paketu sníží jeho TTL o 1. TTL Security u eBGP zapne generování IP paketů s TTL 255, tedy s maximální hodnotou TTL. Protější BGP směrovač po zapnutí TTL Security očekává IP paket s TTL 254, jak je znázorněno na obrázku níže, který nemůže vygenerovat nikdo jiný než přímo připojený soused. Vychází se tedy z toho, že potencionální útočník nemá šanci vytvořit takový IP paket, který by na cílovém BGP směrovači měl TTL 254, pokud by se nedostal do přímo připojené sítě, což je nepravděpodobné, jelikož infrastruktura bývá pod dobrou kontrolou a útočníci zpravidla využívají anonymity rozsáhlého Internetu. Přesná specifikace TTL Security je popsána v RFC 5082.

81

Obrázek č. 32: Zabezpečení BGP pomocí TTL Security

AS 10

AS 20

NLRI=20.0.0.0/8 TTL=254

NLRI=10.0.0.0/8 TTL=253

NLRI=10.0.0.0/8 TTL=254


2.2.6.4. BGP přes IPSec V případě, že by nám nestačilo zabezpečení pomocí MD5 nebo TTL, je možné mezi BGP sousedy provoz zašifrovat pomocí IPSec protokolu. Zašifrováním datového provozu pomocí IPSec protokolu zajistíme, že nikdo BGP provoz nebude schopen přečíst, modifikovat nebo podvrhnout neplatné BGP směrovací informace, jelikož nezná klíč k dešifrování provozu přenášeného IPSec protokolem. Znázornění přenosu BGP uvnitř IPSec tunelu je na obrázku níže. Specifikace IPSec protokolu je popsána v RFC 6071. Obrázek č. 33: Přenos BGP zabezpečený IPSec protokolem

AS 20

AS 10 BGP

IPSec


82

Závěr Z výsledků provedeného šetření vyplývá, že ke směrování se nejčastěji používá dynamický směrovací protokol OSPF a následně pak protokol BGP. OSPF se používá ve více jak 70 % sítí, je nejpoužívanějším interním směrovacím protokolem ve všech typech společností, nejčastěji je používán v sítích do 100 směrovačů a směruje nejčastěji do 1000 směrovacích záznamů. Nejčastěji uváděným důvodem pro používání OSPF je jeho stabilita. BGP se používá častěji pro směrování externích sítí, ale hojně se využívá i jako interní směrovací protokol. Setkáme se s ním ve více jak 55 % sítí a je druhým nejvíce používaným dynamickým směrovacím protokolem ve všech typech společností. Nejčastěji je v sítích spuštěn na jednotkách směrovačů, které jsou typicky hraničními směrovači AS. Externí BGP přenáší nejčastěji více jak 100 000 směrovacích záznamů, tedy plnou Internetovou tabulku, zatím co interní BGP je v počtu přenášených směrovacích záznamů překvapivě vyrovnané mezi všechny definované skupiny. Nejčastěji uváděným důvodem pro používání BGP jsou jeho jedinečné vlastnosti a interoperabilita. Aby byl výčet kompletní, je potřeba uvést, že se statickým směrováním se setkáme ve více jak 90 % sítí, nejedná se však o dynamický směrovací protokol a jeho využití se zpravidla omezuje na jednotky směrovačů a jsou jím směrovány jednotky až desítky směrovacích záznamů. Jako nejčastěji uváděným důvodem pro používání statického směrování je jeho jednoduchost. Chceme-li odpovědět na první předpoklad, tedy hypotézy stanovené v kapitole „1.1 Základní předpoklady šetření“, můžeme konstatovat tato zjištění: -

OSPF je nejčastějším interním směrovacím protokolem. Toto zjištění je v souladu s hypotézou stanovenou v kapitole „1.1 Základní předpoklady šetření“ i se zjištěním v předchozí bakalářské práci.

-

RIP je relativně málo využívaným směrovacím protokolem. Toto zjištění je v souladu s hypotézou stanovenou v kapitole „1.1 Základní předpoklady šetření“ i se zjištěním v předchozí bakalářské práci.

83

-

EIGRP a ISIS jsou relativně málo využívané protokoly. Toto zjištění je v souladu s hypotézou stanovenou v kapitole „1.1 Základní předpoklady šetření“, avšak oproti zjištěním v předchozí bakalářské práci je jejich četnost dvojnásobná. Přesto ani oba směrovací protokoly dohromady zdaleka nedosahují četnosti použití protokolů OSPF ani BGP.

-

ODR a IGRP jsou prakticky nepoužívané protokoly. Toto zjištění je v souladu s hypotézou stanovenou v kapitole „1.1 Základní předpoklady šetření“, avšak oproti zjištěním v předchozí bakalářské práci bylo alespoň zaznamenáno jejich využití v jednotkách případů.

-

BGP protokol se využívá u všech ISP, u ostatních organizací převládá statické směrování. Toto zjištění je v souladu s hypotézou stanovenou v kapitole „1.1 Základní předpoklady šetření“ i se zjištěním v předchozí bakalářské práci.

Odpověď na druhý předpoklad šetření, jehož cílem bylo potvrdit nebo vyvrátit správnost výsledků a závěrů z předchozí bakalářské práce, která byla realizovaná nepřímou metodou dotázání se síťových specialistů, můžeme odpovědět takto. Přímé šetření z velké části potvrdilo a prokázalo stejné výsledky používání směrovacích protokolů jako průzkum nepřímou metodou u síťových specialistů. Našly se drobné odchylky způsobené především provedením přímého šetření v odstupu dvou let a změnou cca 1/3 (31) oslovených společností. Cílem šetření bylo také zjistit, jaká je dynamika a četnost změn v používaných směrovacích protokolech a v čase. Výsledkem je zjištění, které udává, že v průběhu 4 let dojde u cca 40 % společností k nějaké změně v používaných směrovacích protokolech. Detailněji jsou zjištění popsána v kapitole „1.4.5 Změny používaných směrovacích protokolů v čase“. Přínos diplomové práce spočívá především v tom, že na základě zmapování stavu a vývoje používaných směrovacích protokolů v ČR si správci sítí mohou porovnat využití směrovacích protokolů ve svých sítích s ostatními. Dále získají podklady a inspiraci pro další rozvoj síťové infrastruktury a mohou plánovat potřebné změny a odhadnout jejich četnost v čase.

84

Příloha č. 1

Závěr je ponechán číslům v tabulce „Tabulka č. 8: Nejčastější důvody pro používání jednotlivých směrovacích protokolů“, na jejichž základě si každý může porovnat vlastní důvody používání směrovacích protokolů ve své síti s důvody, které definovali respondenti v realizovaném šetření. Pro rychlejší orientaci jsou modře označeny nejčetnější odpovědi pro každý směrovací protokol.

Směrovací protokol Statické interní směrování Statické externí směrování ODR RIP1/2 IGRP EIGRP OSPF ISIS Interní BGP Externí BGP

počet 72 45 0 9 1 7 25 2 7 6

[%] 80,0 75,0 0,0 64,3 50,0 28,0 35,2 18,2 13,2 10,9

počet 3 2 0 0 0 5 27 2 26 29

[%] 3,3 3,3 0,0 0,0 0,0 20,0 38,0 18,2 49,1 52,7

počet 6 2 2 1 0 10 25 5 32 33

[%] 6,7 3,3 66,7 7,1 0,0 40,0 35,2 45,5 60,4 60,0

počet 46 29 0 0 0 10 34 6 23 24


85

[%] 51,1 48,3 0,0 0,0 0,0 40,0 47,9 54,5 43,4 43,6

počet 13 9 0 1 0 7 30 4 22 33

[%] 14,4 15,0 0,0 7,1 0,0 28,0 42,3 36,4 41,5 60,0

počet 24 16 1 6 1 11 14 2 4 5

[%] 26,7 26,7 33,3 42,9 50,0 44,0 19,7 18,2 7,5 9,1

počet 4 3 0 2 0 4 8 2 7 7

[%] 4,4 5,0 0,0 14,3 0,0 16,0 11,3 18,2 13,2 12,7

Celkem odpovědí

Nevím

Nařízení

Historicky

Interoperabilita

Stabilita

Jedinečné vlastnosti

Komplexnost

Jednoduchost

Vlastnost

Tabulka č. 8: Nejčastější důvody pro používání jednotlivých směrovacích protokolů

počet 1 1 0 0 0 0 0 0 0 0

[%] 1,1 1,7 0,0 0,0 0,0 0,0 0,0 0,0 0,0 0,0

počet 90 60 3 14 2 25 71 11 53 55

Příloha č. 1

Seznam použité literatury Literatura [1] DOYLE, Jeff a Jennifer CARROLL. Routing TCP/IP: Volume I. Cisco Press, 2005. Second Edition. ISBN 15-870-5202-4. [2] DOYLE, Jeff a Jennifer DEHAVEN CARROLL. Routing TCP/IP: Volume II. Cisco Press, 2001. ISBN 1-57870-089-2. [3] DOYLE, Jeff. OSPF and IS-IS: choosing an IGP for large-scale networks. Upper Saddle River, NJ: Addison-Wesley, 2006. ISBN 03-211-6879-8. [4] WHITE, Russ, Danny, MCPHERSON a Sangli SRIHARI. Practical BGP. Boston: Addison-Wesley, 2004. ISBN 03-211-2700-5. Akademická práce [5] NAUŠ, Dalibor. Směrování v lokálních a globálních sítích. Praha, Duben, 2011. Bakalářská práce. Bankovní institut vysoká škola Praha. Vedoucí práce [Ing.] Vladimír Beneš. Internetové zdroje [6] Internetworking Technology Handbook. Cisco. [online]. 16 October 2012 [cit. 2013-03-28]. Dostupný z WWW: [7] IP Routing, Design Tech Notes. Cisco. [online]. [cit. 2013-03-29]. Dostupný z WWW: [8] WikipediE Otevřená enciklopedie [online]. [cit. 2013-03-30]. Dostupná z WWW: [9] BGP Statistics from Route-Views Data. [online]. 14 Apr 2013 [cit. 2013-04-14]. Dostupný z WWW: 86

[10] Cisco Systems, Inc. [online]. 14 Apr 2013 [cit. 2013-04-14]. Dostupný z WWW:

Seznam použitých zkratek Zkratka / pojem ABR ACL AD Adjacency Area AS ASBR ASN ATM Bandwidth BDR BGP BR CIDR CLNS CMNS Cost CPU CRC DBD DR DS-3 EBGP EGP EIGRP FDDI FE Frame Relay GE IBGP ICT ID IETF IGP IGRP IP IPSec IR ISIS

Plný název / význam Area Border Router Access Control Lists Administrative Distance sousedský vztah oblast Autonomus System Autonomous System Border Router Autonomus Systém Number Asynchronous Transfer Mode šířka pásma (rychlost) linky Backup Designated Router Border Gateway Protocol Backbone Router Classless Inter-Domain Routing Connectionless Network Service Connection-Mode Network Service cena linky Central Processing Unit Cyclic Redundancy Check Database Description Designated Router standard pro přenos dat rychlostí 1.544 Mb/s External Border Gateway Protocol Exterior Gateway Protocol Enhanced Interior Gateway Routing Protocol Fiber Distributed Data Interface Fast Ethernet protokol pro tvorbu a přenos paketů ve WAN Gigabit Ethernet Internal Border Gateway Protocol Information and Communication Technologies IDentification Internet Engineering Task Force Interior Gateway Protocol Interior Gateway Routing Protocol Internet Protocol IP Security Internal Router Intermediate System-to-Intermediate System 87

ISP LP LSA LSAck LSR LSU MD5 MED NBMA NLRI NSSA ODR OSPF PD PI QoS RFC RIB RID RIP RIPE RM OSI routing RR soBGP SONET SPF SPT T1 TCP TCP/IP ToS TTL UDP uRPF VLSM X.25

Internet Services Providers Local Preference Link-State Advertisement Link-State Acknowledgment Link-State Request Link-State Update Message-Digest Algorithm Multi Exit Discriminator Nonbroadcast Multi-Access Network Layer Reachability Information Not-So-Stubby Area On-Demand Routing Open Shortest Path First Provider Dependent Provider Independent Quality of Services Request for Comments Routing Information Base Router IDentification Routing Information Protocol Réseaux IP Européens Referenční Model – Open System Interconnection směrování Route Reflector Secure Origin BGP Synchronous Optical NETwork Shortest Path First Shortest Path First Tree standard pro přenos dat rychlostí 1.544 Mb/s Transmission Control Protocol Transmission Control Protocol / Internet Protocol Type of Services Time To Live User Datagram Protocol unicast Reverse-Path Forwarding Variable Lenght Subnet Mask protokol pro tvorbu a přenos paketů ve WAN

Seznam obrázků Obrázek č. 1: OSPF v IP paketu ...................................................................................................................... 33 Obrázek č. 2: Proces navazování OSPF Adjacencies ...................................................................................... 37 Obrázek č. 3: Topologie OSPF v Link-State databázi pro výpočet SPF ......................................................... 40 Obrázek č. 4: SPT topologie z pohledu směrovače „A“ po SPF výpočtu ....................................................... 40 Obrázek č. 5: SPT topologie z pohledu směrovače „E“ po SPF výpočtu ........................................................ 41 Obrázek č. 6: Příklad Broadcast Multi-Access sítí .......................................................................................... 42 Obrázek č. 7: Příklad Nonbroadcast Multi-Access sítí .................................................................................... 43 Obrázek č. 8: Příklad Point-to-Point sítí .......................................................................................................... 43 Obrázek č. 9: Příklad Point-to-Multipoint sítí ................................................................................................. 43 Obrázek č. 10: Virtual link propojující dvě Area 0 v jednu............................................................................. 44 Obrázek č. 11: Virtual link připojující Area 2 k Area 0 .................................................................................. 44 88

Obrázek č. 12: Hierarchické člení OSPF domény do oblastí Area .................................................................. 45 Obrázek č. 13: Typy směrovačů v OSPF......................................................................................................... 46 Obrázek č. 14: Typy OSPF oblastí .................................................................................................................. 47 Obrázek č. 15: Posílání jednotlivých typů LSA v OSPF ................................................................................. 48 Obrázek č. 16: AS a jejich propojení BGP protokolem ................................................................................... 50 Obrázek č. 17: Počet aktivních AS v Internetu................................................................................................ 52 Obrázek č. 18: Počet sítí směrovaných BGP protokolem v Internetu ............................................................. 52 Obrázek č. 19: Single-Home připojení organizace k ISP ................................................................................ 53 Obrázek č. 20: Multi-Home připojení organizace k ISP ................................................................................. 54 Obrázek č. 21: Propojení tranzitních AS ISP .................................................................................................. 55 Obrázek č. 22: Interní a externí BGP .............................................................................................................. 55 Obrázek č. 23: Vývojový diagram navázání BGP peeringu ............................................................................ 57 Obrázek č. 24: Detekce směrovací smyčky v BGP pomocí AS-Path .............................................................. 60 Obrázek č. 25: Změna IP adresy v atributu Next-Hop .................................................................................... 61 Obrázek č. 26: Ovlivnění výběru cesty atributem Local Preference ............................................................... 62 Obrázek č. 27: Nastavení atributu Atomic Aggregate při BGP sumarizaci ..................................................... 63 Obrázek č. 28: Ovlivnění návratového provozu atributem MED .................................................................... 64 Obrázek č. 29: Propagace BGP sítí na základě Well-Know atributů Communities ........................................ 66 Obrázek č. 30: BGP v akci .............................................................................................................................. 67 Obrázek č. 31: Funkce unicast Reverse-Path Forwardingu ............................................................................. 72 Obrázek č. 32: Zabezpečení BGP pomocí TTL Security ................................................................................ 74 Obrázek č. 33: Přenos BGP zabezpečený IPSec protokolem .......................................................................... 74

Seznam tabulek Tabulka č. 1: Typy společností ........................................................................................................................ 12 Tabulka č. 2: Typy organizací – bakalářská práce........................................................................................... 13 Tabulka č. 3: Velikost společností ................................................................................................................... 14 Tabulka č. 4: Využití interních směrovacích protokolů .................................................................................. 16 Tabulka č. 5: Využití externích směrovacích protokolů .................................................................................. 21 Tabulka č. 6: Odpovědi na dotaz - Proběhla v posledních 2 letech nějaká změna? ........................................ 23 Tabulka č. 7: Odpovědi na dotaz - Uvažujete o změně v horizontu 2 let? ...................................................... 24 Tabulka č. 8: Nejčastější důvody pro používání jednotlivých směrovacích protokolů ................................... 77

Seznam grafů Graf č. 1: Typy společností ............................................................................................................................. 13 Graf č. 2: Typy organizací – bakalářská práce ................................................................................................ 13 Graf č. 3: Velikost společností v počtu zaměstnanců ...................................................................................... 15 Graf č. 4: Velikost společností a rozložení dle typu společnosti ..................................................................... 15 Graf č. 5: Využití interních směrovacích protokolů ........................................................................................ 17 Graf č. 6: Počet použitých směrovacích protokolů .......................................................................................... 17 Graf č. 7: Počet použitých směrovacích protokolů dle typu společnosti ......................................................... 18 Graf č. 8: Poměr využití interních směrovacích protokolů .............................................................................. 19 Graf č. 9: Poměr využití interních směrovacích protokolů – bakalářská práce ............................................... 19 Graf č. 10: Využití externích směrovacích protokolů...................................................................................... 21 Graf č. 11: Poměr využití externích směrovacích protokolů ........................................................................... 22 Graf č. 12: Poměr využití externích směrovacích protokolů – bakalářská práce............................................. 22 Graf č. 13: Odpovědi na dotaz - Proběhla v posledních 2 letech nějaká změna? ............................................ 23 Graf č. 14: Odpovědi na dotaz - Uvažujete o změně v horizontu 2 let? .......................................................... 24 Graf č. 15: Počet společností, které plánují změnu v průběhu 4 let................................................................. 25 Graf č. 16: Změna v průběhu 4 let nově/zrušeno............................................................................................. 25 Graf č. 17: Změny ve směrovacích protokolech dle období, typu změny a protokolu .................................... 27 Graf č. 18: Změny ve směrovacích protokolech dle protokolu a typu změny ................................................. 28 Graf č. 19: Celkový zájem o výsledky šetření ................................................................................................. 29 Graf č. 20: Vyjádřené důvody zájmů respondentů .......................................................................................... 30

89

Seznam příloh Příloha č. 1: Příloha č. 2: Příloha č. 3:

Dotazníkové šetření – "Směrovací protokoly používané v České Republice". Výsledky dotazníkového šetření ze SurveyMonkey. Tabulka „Výsledná data z šetření směrovacích protokolů ve vybraných společnostech“.

90

Příloha č. 1 Dotazníkové šetření – "Směrovací protokoly používané v České Republice".

1

Příloha č. 1

2

Příloha č. 1

3

Příloha č. 1

4

Příloha č. 2 Výsledky dotazníkového šetření ze SurveyMonkey.

1

Příloha č. 2

2

Příloha č. 2

3

Příloha č. 2

4

Příloha č. 2

5

Příloha č. 3 Tabulka „Výsledná data z šetření směrovacích protokolů ve vybraných společnostech“.

číslo 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41

Použitý směrovací protokol statika BGP ODR RIP1/2 IGRP EIGRP OSPF ISIS Interní Externí DG Interní Externí x x x x

x x x

x

x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x

x x x x x x x x

x

x

x

x

x

x x x

x x x x x

x

x

x

x

x

x

x

x

x

x x

x x x x x x

x x x

x x

x

x x x x x x x x x x x x x

x x x

x x x

x x x x x x

x x x x x

x x x x x x x x

x

x x x x x

x

x

x x

x x x x x x x x x x x

x x x x x

1

x x x x x x

x

x x x x x x x

x x x x x x x x x x x x x x x x x x x x x x x x x x x x

Příloha č. 3 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87

x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x

x

x x

x x x x x x

x x

x x x x

x x

x

x x x x x x

x x x x x x x x x

x x x x x x x

x x

x x

x x

x x x

x

x

x

x

x

x x

x

x x

x

x x x

x x x x

x x x x x x x x

x

x

x

x x x

x x

x

x

x

x

x x x x x x x x x x

x x

x x

x

x x

x

x

x

x x

x

x

x x

x x x

x

x x x x

x x

x

2

Příloha č. 3 88 89 90 91 92 93 94 95 96 97 98 99 100 Celkem

x x x x x x x x x x x x x 92

x x x x x x x x x x

x x x

x x x

x x

x x

x

x x x

64

x x

3

14

2


3

25

71

11

x

x

53

56

Směrovací protokoly používané v České Republice

Recommend Documents