MASARYKOVA UNIVERZITA

Transkript

1 MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY DIPLOMOVÁ PRÁCE BRNO 2013 IVO KOLOMAZNÍK

2 Monitorování stavu dynamických routovacích procesů Prohlášení Prohlašuji, že tato práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj. Ivo Kolomazník Poděkování Na tomto místě bych velmi rád poděkoval vedoucímu diplomové práce panu RNDr. Václavu Lorencovi a panu Mgr. Davidu Rohlederovi za jejich odbornou pomoc, rady a především vstřícné jednání, kterými přispěli k vypracování této diplomové práce.

3 Abstrakt V úvodu této diplomové práce jsou představeny směrovací protokoly OSPF a BGP a je rozebráno jejich fungování v síti. Následně jsou teoreticky popsány možné chyby v jejich konfiguraci. Druhá část práce se zabývá možnostmi automatické detekce chybné konfigurace a implementací nástroje, který za pomocí SNMP protokolu zmapuje topologii sítě, konfiguraci směrovačů a zjištěné nastavení porovná z hlediska možných konfiguračních chyb. Klíčová slova Směrovací protokoly, směrování, OSPF, BGP, SNMP, konfigurační chyby, automatická detekce chyb

4 Obsah Obsah Úvod OSPF Hierarchická struktura protokolu Typy směrovačů v OSPF síti OSPF oblasti Virtuální linky OSPF databáze Navazování komunikace mezi sousedními směrovači Sousedé Vztahy mezi sousedními směrovači Minimalizace OSPF provozu v rámci segmentu OSPF pakety Autentizace Sumarizace Redistribuce Diskrepance v OSPF konfiguraci Neshodující se síťové masky Rozdílné hodnoty hello a dead intervalů Rozdílná velikost MTU Nesprávná konfigurace autentizace Rozdílně konfigurované oblasti a typy oblastí Rozdílné oblasti sousedních směrovačů Stub oblasti Nepřipojení oblastí k oblasti Duplikátní RID na sousedních směrovačích Priorita směrovačů Pasivní síťové rozhraní Blokování paketů BGP Výběr optimální cesty ebgp vs. ibgp Stavy BGP procesu Typy zpráv Algoritmus výběru BGP atributy

5 4.2.1 Lokální preference Multi-exit discriminator (MED) Origin-type AS_path Next-hop Community Weight Další vlastnosti protokolu Synchronizace Route reflector BGP konfederace Chyby při konfiguraci BGP protokolu Nedostupné next-hop směrovače Rozdílná autentizace Filtrování a blokování komunikace Blokování BGP portu BGP filtrování Problémy se synchronizací Špatná konfigurace autonomního systému Automatické hledání chyb v konfiguraci směrovačů Simple Network Management Protokol Management Information Base Algoritmus mapování topologie sítě Získání topologických informací Získání konfiguračních dat Detekce chyb konfigurace OSPF protokolu IP-MIB IF-MIB OSPF-MIB ENTITY-MIB Chyby konfigurace BGP protokolu Zpracování získaných dat Implementace Testování a výsledky Rozšíření Závěr Literatura Seznam elektronických příloh

6 1 Úvod Směrovací protokoly představují jeden ze základních kamenů soudobých počítačových sítí. S jejich pomocí je umožněna komunikace v rozsáhlých sítích i mezi samotnými sítěmi. Ta by v případě statického směrování nebyla prakticky možná, neboť směrovací tabulky dnešních směrovačů mohou obsahovat až stovky tisíc záznamů. Cílem směrovacích protokolů je najít co nejefektivnější cestu k požadovanému cíli. Způsob, jakým toho dosáhnou, je záležitostí konkrétního směrovacího protokolu. Nesprávná konfigurace směrovacích protokolů na směrovačích v síti může způsobit rozsáhlé problémy se směrováním a nedostupností některých oblastí. V dnešní době existuje mnoho směrovacích protokolů. Cílem této diplomové práce je detailní rozbor dvou z nejčastěji používaných protokolů, OSPF a BGP. Na základě jejich specifikací a další rešerše budou hledány možné chyby způsobené nesprávnou konfigurací nebo použitím směrovacích protokolů. Nalezené chyby budou zanalyzovány a na základě jejich analýzy bude navržen způsob, jakým by bylo možné tyto chyby automaticky detekovat. Poslední část diplomové práce se bude zabývat implementací nástroje, který bude schopný zmapovat topologii sítě, zjistit potřebná konfigurační data směrovačů a alespoň některé z případů nesprávné konfigurace automaticky detekovat a upozornit na ně a tím předejít nesprávnému směrování, či nedostupnosti dalších sítí. 3

7 2 OSPF Open Shortest Path First (OSPF) je otevřeným dynamickým směrovacím protokolem navrženým pro TCP/IP sítě, který patří do skupiny protokolů směrujících na základě stavu linek (link-state routing protocols). Jedná se o jeden z nejužívanějších protokolů pro distribuci směrovacích informací uvnitř autonomního systému (AS). [7] Diskuze o protokolu, který by nahradil protokoly směrující dle vektoru vzdálenosti (distance vector routing protocols), jež se ukázaly jako nevhodné pro neustále se rozrůstající heterogenní sítě, byla započata roku 1988 a návrh první verze protokolu byl vytvořen v roce Jeho základem se stal Dijsktrův algoritmus hledání nejkratších cest (Shortest Path First, SPF). V roce 1998 byla představena jeho druhá verze OSPFv2 a o deset let později i implementace pro IPv6 sítě označovaná jako OSPFv3. OSPF protokol je definován v RFC [26] Jak již bylo řečeno, jedná se protokol směrující na základě stavu linek. Tento typ protokolů informuje ostatní směrovače v síti pouze v případě změn topologie. K tomu OSPF využívá tzv. Link State Advertisements (LSA), jež jsou zasílány na multicastovou adresu všem ostatním směrovačům v rámci stejné oblasti (viz dále) a informují o připojených rozhraních, o vztahu k sousedním směrovačům, či o používaných metrikách. Tyto LSA si každý směrovač uchovává v databázi Link State Database (LSDB) a zároveň je přeposílá všem dalším směrovačům v síti. Dle této databáze mají všechny směrovače přehled o ostatních směrovačích v síti a znají ceny jednotlivých linek k ostatním uzlům. To jim umožňuje za pomocí Dijkstrova SPF algoritmu nejdříve efektivně vypočítat SPF strom a z něj poté zvolit nejlepší (nejkratší) cestu, která bude uložena do směrovacích tabulek. Na rozdíl od protokolů směrujících na základě vektoru vzdálenosti se tedy nemusí OSPF směrovače spoléhat na směrovací informace získané od svých sousedů, ale rozhodují se nezávisle na základě znalosti kompletní topologie svojí sítě (oblasti). [15] [17] 2.1 Hierarchická struktura protokolu Každý OSPF směrovač si uchovává následující informace [15]: Tabulka OSPF sousedů (OSPF neighbor table) seznam všech přímo připojených sousedních směrovačů. Využívá se zejména v případě ztráty spojení s některým ze sousedů. Směrovač v této situaci zneplatní všechny cesty, které vedou přes tohoto souseda, a vypočítá nové na základě ostatních dostupných směrovačů. LSDB informace o všech ostatních směrovačích v síti (oblasti) a o sítích k nim připojených. 4

8 Seznam nejkratších cest do všech dostupných cílových sítí vypočítaný dle SPF algoritmu. Tento seznam je uchován v rámci LSDB a nejkratší cesty jsou poskytnuty směrovacím tabulkám. Protože si každý směrovač uchovává kompletní informace o topologii celé sítě a počítá možné cesty do všech cílových destinací, je zřejmé, že zejména v rozlehlých sítích může být tato vlastnost OSPF protokolu velice paměťově náročná. Rovněž směrovací tabulky mohou být obrovské, především pokud není využívána sumarizace, kterou OSPF defaultně nepoužívá. Protože každý směrovač při změnách v síti musí podle SPF algoritmu přepočítat nejkratší cesty, stává se i toto jednou z nevýhod, neboť v případě rozlehlých sítí mohou tyto výpočty spotřebovat značný čas procesoru jednotlivých směrovačů. [15] [17] Abychom předešli výše zmiňovaným problémům, rozděluje OSPF celou síť do oblastí. Je využíván dvouvrstvý hierarchický model. Celá OSPF síť je rozdělena do jednotlivých oblastí, přičemž každá z těchto oblastí musí být připojena k hlavní oblasti označované jako oblast 0 nebo páteřní (backbone) oblast. Každá oblast je v síti identifikována svým jednoznačným 32 bitovým číslem uváděným buď dekadicky, nebo v IP formátu. [15] LSDB jednotlivých směrovačů obsahují pouze informace o směrovačích v rámci jedné oblasti a rovněž LSA, které jsou záplavově šířeny sítí, jsou propagovány jen směrovačům spadajícím do dané oblasti. V důsledku toho je i výpočet nejkratších cest rychlejší a snadnější, protože SPF algoritmus pracuje pouze s daty dané oblasti. [15] Typy směrovačů v OSPF síti V závislosti na tom, kde se konkrétní zařízení v OSPF síti nachází, rozlišujeme tři druhy směrovačů [15]: Internal Router (IR) všechna rozhraní směrovače se nacházejí uvnitř jedné oblasti, tedy celý směrovač je pouze uvnitř jedné oblasti. Speciálním případem IR je směrovač, který se nachází uvnitř oblasti 0. Tento je někdy nazýván jako Backbone Router (BR). Všechny směrovače uvnitř jedné oblasti mají stejné LSDB. Area Border Router (ABR) směrovač, jehož rozhraní se nacházejí uvnitř více než jedné oblasti, přičemž jednou z nich musí být oblast 0. ABR si tedy musí uchovávat informace o všech připojených oblastech; pro každou oblast má vlastní LSDB. ABR zajišťuje směrování mezi jednotlivými oblastmi, distribuci informací o lokální oblasti do oblasti 0 a zpětně distribuci směrovacích informací z oblasti 0 do lokální oblasti. ABR jsou rovněž jedinými směrovači, kde je možné aplikovat sumarizaci adres dané oblasti a rozdělují také zóny, 5

9 ve kterých jsou šířeny LSA, neboť LSA jsou propagovány pouze v rámci oblastí. Doporučuje se, aby ABR spojoval v ideálním případě pouze dvě oblasti; maximální počet by neměl přesáhnout tři oblasti. Antonomous System Boundary Router (ASBR) směrovač, který se nachází na hranici autonomních systémů. Tyto směrovače zajišťují redistribuci informací mezi OSPF a ostatními směrovacími protokoly, mezi různými OSPF instancemi či redistribuci statických směrovacích informací a distribuci těchto informací v rámci svého autonomního systému. Zpravidla na nich běží také některý z protokolů pro směrování mezi autonomními systémy (Exterior Gateway Protocol, EGP), např. Border Gateway Protocol (BGP) OSPF oblasti Jak bylo již v úvodu řečeno, navrhujeme-li OSPF síť s více oblastmi, musí jednou z nich být páteřní oblast 0, k níž musí být všechny ostatní oblasti fyzicky připojeny. Důvodem tohoto konceptu návrhu sítě je snadná distribuce směrovacích informací mezi jednotlivými oblastmi, kdy každá oblast propaguje informace do oblasti 0 a ta následně zpětně propaguje tyto informace ostatním připojeným oblastem. [17] OSPF rozlišuje čtyři typy cest v závislosti na tom, odkud byla informace o dané cestě získána [17]: Intra-area route směrovací informace generované danou oblastí. Jedná se o směrování do takových cílových sítí, které patří do této oblasti. Inter-area (summary) route směrovací informace, které byly distribuovány z jiných oblastí. External route jedná se o směrovací informace redistribuované z jiných směrovacích protokolů či jiných instancí OSPF. Existují dva typy externích cest. Liší se v tom, jakým způsobem je počítána metrika těchto cest (viz kapitola 2.7). V případě, že existuje více směrovacích informací do stejné cílové sítě, jsou preferovány intra-area cesty před inter-area, inter-area před externí cestou typu 1 a typ 1 má vyšší prioritu než typ 2. [17] Oblast 0 Jedná se o páteřní oblast, jejíž hlavním účelem je spojení ostatních typů OSPF oblastí a rychlý přenos dat mezi nimi. Oblast 0 zpravidla neslouží k připojení koncových uživatelů. [15] Běžné (nepáteřní) oblasti Na rozdíl od oblasti 0 je jejich hlavním účelem připojení koncových uživatelů. Zpravidla funkčně nebo geograficky kopírují konkrétní skupiny. Běžné oblasti nedovolují směrování datových toků 6

10 cílených do jiné oblasti než lokální, protože veškeré směrování do sítí mimo lokální oblast musí probíhat přes oblast 0. Existuje několik podtypů nepáteřních oblastí [15]: Standardní defaultní typ běžné oblasti s interními i externími cestami. Stub oblast, která nedovoluje, aby do jejího směrování byly přidány externí sítě jiných autonomních systémů. Směrování mimo autonomní systém zajišťuje defaultní cesta (default route). Ve stub oblasti se nesmí nacházet ASBR. Výjimkou je případ, kdy ASBR je současně ABR. Totally stubby Cisco proprietární typ oblasti. Stejně jako stub oblast nedovoluje, aby do jejího směrování byly přidány externí sítě jiných autonomních systémů, a rovněž nedovoluje ASBR v oblasti, pokud se nejedná o ABR. Nepřijímá ani distribuci směrovacích informací ostatních oblastí svého autonomního systému. Not-so-stubby (NSSA) tato oblast definuje speciální typ LSA 7 (viz kapitola 2.2). Stejně jako stub area nepřijímá externí směrování a využívá defaultní cesty ke směrování mimo autonomní systém. Na rozdíl od stub oblasti se v NSSA mohou nacházet ASBR. Totally stubby NSSA Cisco proprietární typ oblasti. Jak název napovídá, jedná se o kombinaci typů oblastí totally stubby a NSSA. Informace o externím směrování a směrování mimo lokální oblast nejsou přijímány, avšak v oblasti se může nacházet ASBR Virtuální linky Jak bylo řečeno, OSPF koncept vyžaduje, aby všechny oblasti byly fyzicky připojené k oblasti 0, přičemž oblast 0 se v rámci celé sítě vyskytuje právě jednou. Aby bylo možné tyto podmínky dodržet i v případě neplánovaných změn v návrhu sítě, byly zavedeny tzv. virtuální linky (virtual links). Existují dva typy použití virtuálních linek [17]: V prvním případě se jedná o logické připojení oblastí, které nemohou být fyzicky spojeny s oblastí 0. Logická linka je nakonfigurována mezi dvěma ABR, z nichž jeden musí být připojen k páteřní oblasti. Oblast, která zajišťuje připojení k oblasti 0, se nazývá tranzitní oblast. Druhým typem virtuální linky je spojení více oblastí 0 do jedné tak, aby síť odpovídala OSPF specifikaci. Virtuální linky jsou chápány jako záložní či dočasné řešení a nedoporučuje se s nimi počítat v samotném návrhu topologie sítě. Virtuální linky také nemohou procházet stub oblastmi a nemohou 7

11 vést více než jednou tranzitní oblastí. Je možné konfigurovat virtuální linku přes více tranzitních oblastí tak, že pro každou tranzitní oblast je konfigurována samostatná virtuální linka. [15] 2.2 OSPF databáze V úvodu byl představen základní koncept protokolů směrujících na základě stavů linek a OSPF protokolu. Ty ke své správné činnosti, k uchování směrovacích informací a k výměně informací o stavu připojených linek se svými sousedy využívají zmíněné LSA a LSDB. Tato kapitola se zabývá základním popisem jednotlivých typů LSA a tím, jak ovlivňují finální podobu LSDB. Každý LSA představuje záznam databáze a dohromady tvoří celou LSDB databázi, která reprezentuje celou OSPF síť (oblast). V současné době je definováno jedenáct LSA typů. [15] LSA-1 LSA-2 LSA-3 LSA-4 LSA-5 LSA-6 LSA-7 LSA-8 LSA-9 LSA-10 LSA-11 Router LSA Síťový LSA Sumarizační LSA Externí LSA Multicast OSPF LSA LSA pro NSSA LSA pro BGP Rezervované Tabulka 2-1 Typy LSA Router LSA, LSA-1 každý směrovač zasílá tyto LSA do všech k němu připojených oblastí. Tento typ LSA obsahuje informace o linkách spojujících směrovač s danou oblastí, a proto se liší v závislosti na tom, pro kterou oblast jsou generované. Router LSA pro konkrétní oblast jsou propagovány pouze do této oblasti. Síťový LSA, LSA-2 LSA generované DR směrovači (viz kapitola 2.3.3) v multiaccess sítích. Obsahuje seznam všech směrovačů připojených k danému multiaccess segmentu sítě. Síťové LSA jsou propagovány v rámci oblasti, do níž konkrétní segment spadá. Sumarizační LSA, LSA-3 a LSA-4 - jedná se o LSA generované ABR směrovači. LSA-3 popisuje informace o cestách do sítí dané oblasti, LSA-4 cesty k ASBR směrovačům. Sumarizační LSA jsou propagovány přes oblast 0 ostatním připojeným oblastem OSPF sítě. 8

12 Z definicí OSPF oblastí je zřejmé, že LSA-3 nejsou propagovány do oblastí typu totally stubby a totally stubby NSSA a LSA-4 nejsou propagovány do žádné z oblastí typu stubby. Externí LSA (Antonomous system external LSA), LSA-5 LSA generované ASBR směrovači. Obsahují informace o externích cestách do sítí mimo daný autonomní systém. Stejně jako LSA-4 nejsou ani LSA-5 propagovány do žádného typu stubby oblastí. Multicast OSPF LSA, LSA-6 využíváno pro OSPF multicastové aplikace NSSA LSA, LSA-7 tento typ LSA může existovat pouze v NSSA oblasti. LSA-7 jsou generovány ASBR směrovačem a na hranici oblasti je ABR překládá na typ LSA-5, který může být propagován i v dalších oblastech. LSA-7 distribuuje externí směrovací informace do svojí OSPF domény. LSA pro Border Gateway Protocol (BGP), LSA-8 speciální typ LSA pro využití spolu s BGP Rezervované, LSA-9, LSA-10 a LSA-11 poslední tři typy LSA jsou rezervované pro budoucí užití a pro aplikačně specifické LSA. 2.3 Navazování komunikace mezi sousedními směrovači Sousedé Sousedy (neighbors) jsou nazývány takové směrovače, které sdílejí společný síťový segment. Sousední směrovače komunikují pomocí tzv. hello protokolu. Hello pakety jsou odesílány periodicky z každého rozhraní daného směrovače. Směrovače se stanou vzájemnými sousedy v okamžiku, kdy navzájem vidí informaci o sobě samých v hello paketech souseda. [15] Existuje několik nutných podmínek, které musí směrovače v rámci segmentu splňovat, aby se mohly vzájemně stát svými sousedy [15][26]: Síťová rozhraní sousedních směrovačů sdílející stejný segment musí spadat do stejné oblasti. Nutnou podmínkou je samozřejmě také to, aby byla rozhraní konfigurována ve stejné podsíti a se stejnou síťovou maskou. Je-li konfigurována autentizace (viz kapitola 2.5), musejí směrovače na daném segmentu sdílet stejné heslo. 9

13 Shodné hello a dead intervaly sousední směrovače musejí sdílet stejné hodnoty hello a dead intervalů. Hello interval udává, v jaké periodě směrovač zasílá hello pakety. Dead interval udává dobu, po které směrovač v případě, že neobdrží hello paket souseda, pokládá tohoto souseda za odpojeného. Stejný typ oblasti směrovače musí spadat do stejného typu oblasti, aby se mohly stát svými sousedy. Pokud se směrovače na stejném segmentu neshodují v konfiguraci některé z výše zmíněných hodnot, je tzv. neighboring proces 1 přerušen a směrovače se nemohou stát vzájemnými sousedy. [26] Vztahy mezi sousedními směrovači Dříve než si směrovače začnou vyměňovat směrovací informace, musí ustavit vzájemné vztahy mezi sebou. Poté, co projdou neighboring procesem, přichází na řadu ustavení vztahu adjacency 2. Ten probíhá v několika krocích [15]: Down nejsou dostupné žádné informace o jakémkoliv aktivním sousedovi na daném segmentu. Init směrovač obdržel hello paket od jiného směrovače ze svého segmentu. Nutno ustavit obousměrnou komunikaci. Two-way poté, co směrovač vidí sebe sama (své router ID, viz kapitola 2.3.3) v hello paketu souseda, je obousměrná komunikace navázána. Exstart v tomto stavu si směrovače ustanoví sekvenční číslo a vzájemné master/slave role pro budoucí komunikaci. Master směrovač poté vyzývá slave směrovač k zasílání informací. Exchange směrovače si vzájemně vyměňují informace o svých LSDB pomocí database description (DBD) paketů. Ty obsahují pouze hlavičky LSA. Loading dokončování výměny informací. Je využíváno dvou seznamů. První z nich, link-state request, obsahuje všechny informace, které jsou nekompletní nebo zastaralé a které bude směrovač žádat po svých sousedech znovu. Druhý seznam, link-state retransmission, obsahuje seznam informací, které směrovač zasílá svým sousedům a u kterých čeká na potvrzení přijetí. Full dokončení ustavení adjacency vztahu. Směrovače v tomto stavu sdílejí stejnou LSDB. 1 Neighboring proces proces vzájemného objevování sousedních routerů na daném segmentu. 2 Adjacency vztah vztah dvou sousedních směrovačů, ve kterém jsou schopny vyměňovat si vzájemně směrovací informace. 10

14 2.3.3 Minimalizace OSPF provozu v rámci segmentu Jak bylo řečeno v předchozích kapitolách, směrovače v adjacency stavu vzájemně sdílejí LSDB. Abychom se vyhnuli přílišnému zahlcení sítě, kdy každý směrovač segmentu komunikuje s každým dalším, přichází OSPF s konceptem centralizace informací v rámci síťového segmentu. Protokol zvolí pro daný segment tzv. designated router (DR), se kterým následně komunikují všechny ostatní směrovače. Kromě ustavení DR je zvolen také záložní backup DR (BDR), který nahrazuje DR v případě výpadku. [17] DR a BDR směrovače jsou voleny během two-way stavu budování adjacency vztahu pomocí hello paketů. Směrovač s nejvyšší OSPF prioritou se stává DR. Defaultně má každý směrovač prioritu nastavenu na hodnotu 1. V případě, že všechny směrovače v rámci segmentu mají stejnou OSPF prioritu, stává se DR ten směrovač, který má nejvyšší router ID (viz dále). Při výběru BDR se postupuje analogicky. Směrovač, který má OSPF prioritu nastavenu na hodnotu 0, se nemůže stát DR ani BDR a je označován jako DROTHER. [17] Router ID (RID) je unikátním 32 bitovým identifikátorem směrovače v dané síti. OSPF nespecifikuje způsob výběru daných identifikátorů, a proto se výběr může lišit v závislosti na implementaci. Zpravidla se jako RID používá některá z IP adres konfigurovaných na rozhraních daného zařízení. Cisco implementace volí jako RID nejvyšší IP adresu konfigurovanou na rozhraních daného směrovače. Je-li na směrovači konfigurováno loopback rozhraní, je jako RID použita adresa tohoto rozhraní i v případě, že ostatní rozhraní mají vyšší IP adresu, čímž je docíleno větší stability. V případě jiných OSPF implementací mohou být naopak za RID voleny nejmenší IP adresy daného směrovače. Je-li rozhraní s IP adresou použitou jako RID odstraněno nebo přestane komunikovat, je vybráno nové RID a směrovač zasílá znovu své směrovací informace s novým RID. [17] [26] V případě point-to-point spojení není konceptu DR a BDR využíváno. 2.4 OSPF pakety Existuje 5 typů OSPF paketů [15]: Hello tento typ paketů, jak již bylo v předchozích kapitolách uvedeno, slouží k nalezení sousedů v rámci segmentu a k navázání adjacency vztahů. Database description (DBD) zajišťuje synchronizaci LSDB mezi jednotlivými směrovači. Link-state request (LSR) odesílá žádosti o konkrétní záznamy LSDB sousedního směrovače. 11

15 Link-state update (LSU) odesílá konkrétní záznamy LSDB vyžádané sousedy. Link-state acknowledgement (LSAck) OSPF vyžaduje spolehlivý přenos dat. Definuje vlastní systém potvrzování přijetí paketů pomocí LSAck. Obrázek 2-1 Hlavička OSPF paketu Jak je znázorněno na obrázku 2-1 hlavička OSPF paketu se skládá z osmi polí; devátým polem paketu je pole s daty [26]: Číslo verze verze protokolu. Hodnota 2 pro OSPFv2 pro IPv4, hodnota 3 pro OSPFv3 pro IPv6. Typ typ OSPF paketu. Velikost paketu velikost paketu v bytech. Router ID směrovač, odkud daný paket pochází. ID oblasti ID oblasti, ze které paket pochází. Kontrolní součet detekce chyb paketu. Typ autentizace bez autentizace, plain-text heslo nebo MD5 hashování. Autentizace autentizační řetězec. Data v závislosti na tom, o jaký typ paketu se jedná, obsahuje toto pole rozdílná data: o o o o o Hello pakety seznam známých sousedů. DBD přehled LSDB odesílajícího směrovače. LSR obsahuje typ žádaného LSU a ID žádajícího směrovače. LSU nese LSA záznamy o LSDB. Jeden LSU může přenášet více LSA záznamů. LSAck datové pole je v případě tohoto typu paketu prázdné. 12

16 2.5 Autentizace OSPF umožňuje využívat vzájemnou autentizaci směrovačů při výměně směrovacích informací. Defaultně je autentizace vypnutá, ale je možné využít dvou základních typů [15][26]: Autentizace s použitím hesla v čistém textovém formátu pro každou oblast je možné definovat autentizační heslo, které musí být stejné pro všechny směrovače v rámci jedné oblasti. Heslo je po síti přenášeno nešifrovaně, a tak je zvolená metoda náchylná k pasivním útokům. Autentizace za pomocí MD5 hashování směrovač vytvoří hash přenášeného paketu a připojí jej k němu. Autentizační klíč v tomto případě není přenášen po sítí. Na každém směrovači musí být konfigurován autentizační klíč a spolu s ním také ID tohoto klíče 3. To zajišťuje možnost plynulé změny klíčů bez přerušení provozu, protože v případě, že je konfigurován nový klíč s novým ID, odesílá směrovač více kopií paketu, kdy každou z nich hashuje rozdílnými klíči až do doby, než všechny ostatní směrovače používají nově nakonfigurovaný klíč. 2.6 Sumarizace Sumarizace umožňuje propagování více cest pomocí jedné. Sumarizace je zpravidla uplatňována na ABR směrovačích. Cesty je možné sumarizovat mezi kterýmikoliv dvěma oblastmi, ale doporučuje se, aby sumarizace probíhala na ABR ve směru do oblasti 0. V takovém případě je oblast 0 zahlcována méně informacemi, protože seznam cest obdrží již sumarizovaný a rovněž jej sumarizovaný propaguje do dalších oblastí. [17] Sumarizace je rozdělována na dva typy [17]: Mezioblastní sumarizace v rámci AS. Sumarizace externích cest redistribuovaných do OSPF. 2.7 Redistribuce Redistribuce umožňuje zahrnutí směrovacích informací z jiných směrovacích protokolů a jejich propagaci v rámci OSPF jako externích směrovacích informací. 3 Nazýváno kryptografické sekvenční číslo nebo autentizační sekvenční číslo. 13

17 Jak bylo řečeno v kapitole OSPF oblasti, existují dva typy redistribuce a dva typy externích cest, které závisí na způsobu počítání metrik těchto externích cest. [17] Externí cesty typu 1 typ jedna počítá metriku externí cesty jako součet ceny externí redistribuované cesty a ceny cesty v rámci AS nutné k dosažení této externí cesty. Externí cesty typu 2 v tomto případě je cena cesty vždy stejná v rámci celého AS. Jedná se o cenu redistribuované cesty bez závislosti na ceně interní cesty v rámci AS. Obrázek 2-2 Redistribuce. Zdroj: [17] Obrázek 2-2 znázorňuje rozdíl ve výpočtu cen cest v závislosti na typu externí linky. V případě první sítě S1 je cena cesty k dosažení cílové sítě na směrovači RTA rovna hodnotě x, na směrovači RTB x+y a na směrovači RTC x+y+z. Cena cesty k dosažení druhé sítě S2 je shodně na všech směrovačích rovná hodnotě x. 14

18 3 Diskrepance v OSPF konfiguraci V konfiguraci OSPF protokolu mohou nastat situace, kdy sousední směrovače nejsou schopny vzájemné komunikace nebo si nevyměňují informace takovým způsobem, jak bylo při návrhu sítě zamýšleno. Následující kapitola se zaměřuje na teoretický rozbor některých takových případů. 3.1 Neshodující se síťové masky K ustavení adjacency vztahu mezi směrovači je nutné, aby se konfigurace základních parametrů síťových rozhraní sousedních směrovačů shodovala. Kromě hello a dead intervalů (viz následující kapitola 3.2) je tímto parametrem také síťová maska. V případě, že není nastavena u obou stran komunikace na stejnou hodnotu, není další komunikace umožněna. Zjistí-li přijímající směrovač, že síťová maska v příchozím hello paketu se neshoduje s jeho vlastní, paket neprodleně zahazuje. [26] OSPF: Rcv hello from area 0 from FastEthernet0/ OSPF: Mismatched hello parameters from OSPF: Dead R 40 C 40 Hello R 10 C 10 Mask R C Obrázek 3-1 Neshodující se síťové masky Jak je znázorněno na obrázku 3-1 přijímající směrovač detekuje neshodu v základních hello parametrech. Maska rozhraní souseda (Mask R) je nastavena na hodnotu , maska přijímajícího směrovače (Mask C) na Vytváření adjacency vztahu nemůže pokračovat. 3.2 Rozdílné hodnoty hello a dead intervalů Jak bylo naznačeno v předchozí kapitole, dalšími hodnotami, které se musí u komunikujících sousedů shodovat, jsou hello a dead intervaly. V případě, že je některý z intervalů nakonfigurován na jinou hodnotu, je postup stejný jako v případě rozdílných masek, přijatý paket není dále zpracováván a je ihned zahozen. [26] 15

19 OSPF: Rcv hello from area 0 from FastEthernet0/ OSPF: Mismatched hello parameters from OSPF: Dead R 40 C 40 Hello R 15 C 10 Mask R C Obrázek 3-2 Rozdílné hodnoty hello intervalů OSPF: Rcv hello from area 0 from FastEthernet0/ OSPF: Mismatched hello parameters from OSPF: Dead R 100 C 40 Hello R 10 C 10 Mask R C Obrázek 3-3 Rozdílné hodnoty dead intervalů Obrázky 3-2 a 3-3 ukazují rozdíly v hello, resp. dead intervalech. Stejně jako v případě rozdílných síťových masek detekuje směrovač neshodu v základních hello parametrech a budování adjacency vztahu sousedů dále neprobíhá. 3.3 Rozdílná velikost MTU Dalším parametrem, který se musí u komunikujících stran shodovat, je hodnota MTU 4. Protože není specifikována v rámci základních hello parametrů, projdou směrovače úspěšně počátečním neighboring procesem a dostanou se do dalšího stavu budování adjacency vztahu. [19] Hodnota MTU je součástí hlavičky DBD paketu, který popisuje obsah LSDB odesílajícího směrovače (viz kapitola 2.4). Pokud se MTU hodnoty rozhraní sousedů neshodují, mohou nastat dva případy ve změně stavů komunikujících směrovačů [21]: Patří-li rozhraní s nižší hodnotou MTU slave směrovači (viz kapitola 2.3.2), zahazuje DBD paket s vyšším MTU od master směrovače a oba směrovače zůstávají ve stavu Exstart. Jiná situace nastane, patří-li rozhraní s nižším MTU master směrovači. Master směrovač odesílá první DBD paket sousednímu slave směrovači. Ten tento DBD paket přijímá a potvrzuje přijetí odesláním svého DBD paketu master směrovači. Potvrzením přijetí 4 Maximum transmission unit maximální přenosová jednotka 16

20 přechází slave směrovač do následujícího stavu Exchange. Master směrovač přijímá DBD paket s vyšším MTU, ten zahazuje a zůstává dále v Exstart stavu. Velikost MTU je uplatňována především v případě zasílání LSU paketů. Ty mohou obsahovat více jednotlivých LSA záznamů. Každý LSU je vytvářen právě do velikosti hodnoty MTU. Jedinou výjimkou jsou případy, kdy jeden LSA záznam přesahuje velikost MTU. V takovém případě OSPF vytváří LSU větší než je velikost MTU a fragmentaci ponechá na nižší vrstvě komunikace. [16] OSPF: Rcv DBD from on FastEthernet0/0 seq 0x534c opt 0x52 flag 0x7 len 32 mtu 1600 state EXSTART OSPF: Nbr has larger interface MTU Obrázek 3-4 Rozdílná hodnota MTU na rozhraních sousedních směrovačů 3.4 Nesprávná konfigurace autentizace Jak bylo zmíněno v kapitole 2.5, OSPF protokol umožňuje vzájemnou autentizaci komunikujících směrovačů. Aby byla autentizovaná komunikace umožněna, musí se sousední směrovače shodovat jak v typu autentizace, tak v autentizačním řetězci (klíči), resp. v řetězci a ID klíče v případě autentizace pomocí MD5 hashování. Z této podmínky vyplývají dva možné typy chybné OSPF konfigurace [39]: První z nich je případ, kdy každá strana komunikace používá jiný typ autentizace. Obrázek 3-5 znázorňuje situaci, kdy příchozí OSPF paket používá plain-text autentizaci (typ 1) a přijímající směrovač autentizaci nepoužívá (typ 0). Obrázek 3-6 ukazuje případ, kdy vysílající směrovač autentizuje pomocí MD5 hashe (typ 2) a přijímající směrovač využívá plain-text autentizaci (typ 1). OSPF: Rcv pkt from , FastEthernet0/0 : Mismatch Authentication type. Input packet specified type 1, we use type 0 Obrázek 3-5 Plain-text autentizace a nepoužívaná autentizace OSPF: Rcv pkt from , FastEthernet0/0 : Mismatch Authentication type. Input packet specified type 2, we use type 1 Obrázek 3-6 Plain-text autentizace a pomocí MD5 hashe 17

21 Druhým případem chybné konfigurace je neshoda v autentizačním řetězci. Obrázek 3-7 ukazuje situaci, kdy jsou na komunikujících zařízeních nastavena různá plain-text hesla. Další chybou, jež ukazuje obrázek 3-8, je neshoda v ID klíče v případě autentizace pomocí MD5 hashe. Přijímající směrovač detekuje chybu, neboť na vstupním rozhraní nemá konfigurován klíč s ID 1. Na obrázku 3-9 vidíme poslední typ chyby autentizace. Jedná se o případ, kdy mají komunikující směrovače nastaveny shodné ID klíče, ale hash přijatého paketu se neshoduje s hashem vytvořeným přijímajícím směrovačem, což indikuje chybu v hashovacím klíči. OSPF: Rcv pkt from , FastEthernet0/0 : Mismatch Authentication Key - Clear Text Obrázek 3-7 Rozdílná plain-text hesla OSPF: Rcv pkt from , FastEthernet0/0 : Mismatch Authentication Key - No message digest key 1 on interface Obrázek 3-8 Neshoda ID klíče v případě autentizace pomocí MD5 hashe OSPF: Rcv pkt from , FastEthernet0/0 : Mismatch Authentication Key - Message Digest Key 2 Obrázek 3-9 Neshodný MD5 hash 3.5 Rozdílně konfigurované oblasti a typy oblastí V případě návrhu OSPF sítě a její následné konfigurace je možné setkat se s více typy chybného nastavení. Tím může být jak chyba v samotné konfiguraci sousedních směrovačů, tak chyba návrhu sítě, kdy konfigurace odpovídá předepsanému síťovému rozvržení, ale směrování nefunguje dle předpokladů. Následující kapitola rozebírá nejčastější případy. [39] 18

22 3.5.1 Rozdílné oblasti sousedních směrovačů Pro správnou činnost OSPF sítě je nutné, aby sousední směrovač v rámci jednoho segmentu byly konfigurovány se stejným číslem a typem oblasti (viz kapitola 2.1). V případě, že se některá z hodnot přijatého paketu neshoduje s hodnotou konfigurovanou na rozhraní přijímajícího směrovače, komunikace a výměna směrovacích informací není umožněna. Chybu způsobenou rozdílným číslem oblasti rozhraní dvou komunikujících směrovačů je možné rozdělit na další dva podtypy [40]: Prvním z nich je případ, kdy ani jedno rozhraní komunikujících stran není nastaveno v oblasti 0. Jak bylo uvedeno dříve, je nutné, aby každá z oblastí byla připojena k oblasti 0, a proto není komunikace v tomto případě úspěšná. Směrovače v tomto případě negenerují chybové hlášení upozorňující na neshodu v číslech oblasti. V případě, že na daném segmentu není jiný směrovač, se kterým by bylo možné navázat komunikaci, hlásí směrovač pouze tuto skutečnost (viz obrázek 3-10). OSPF: No full nbrs to build Net Lsa for interface FastEthernet0/1 Obrázek 3-10 Žádný ze sousedních směrovačů není nastaven v oblasti 0 Ve druhém podtypu případu chybně konfigurované oblasti patří rozhraní jedné z komunikujících stran do oblasti 0, ale rozhraní druhé strany komunikace je konfigurováno v jiné oblasti. Obrázek 3-11 ukazuje chybu generovanou směrovačem mimo oblast 0. Směrovač indikuje neshodu v čísle oblasti (area ID) a chybějící virtuální linku (viz kapitola 2.1.3), která by mohla spojení s oblastí 0 zprostředkovat. Směrovač, jenž náleží do oblasti 0, tuto chybu negeneruje. Stejně jako v předchozím případě indikuje směrovač nemožnost další komunikace, pokud není žádný další směrovač v segmentu. [20] OSPF-4-ERRRCV: Received invalid packet: mismatch area ID, from backbone area must be virtual-link but not found from , FastEthernet0/0 Obrázek 3-11 Směrovač mimo oblast 0 připojený k oblasti 0 19

23 Dalším typem chybné konfigurace je rozdílný typ oblastí (viz kapitola2.1.2) nastavený na komunikujících směrovačích pro konkrétní oblast. Ani v tomto případě nejsou sousední směrovače schopny další komunikace a výměny směrovacích informací a hlásí chybu neshody v oblastech. [18] OSPF: Rcv hello from area 1 from FastEthernet0/ OSPF: Hello from with mismatched Stub/Transit area option bit Obrázek 3-12 Rozdílný typ oblastí na rozhraních sousedních směrovačů Stub oblasti Kromě chybné konfigurace způsobené neshodou sousedních směrovačů v typu oblasti, která byla popsána v předchozí kapitole, je možné u všech typů stub oblastí vidět ještě další problém způsobený chybným návrhem sítě. Jelikož stub oblasti ze své definice nepodporují směrování mimo autonomní systém, resp. mimo samotnou oblast v případě Cisco proprietárních stubby oblastí, je nutné zajistit směrování do externích 5 destinací defaultní cestou. Nenastavení defaultní cesty může způsobit rozsáhlé směrovací problémy v rámci sítě, a jelikož se nejedná o chybu v samotné konfiguraci směrovačů, může být velice těžce detekovatelná Nepřipojení oblastí k oblasti 0 Jedná se o specifický případ chyby popsané v kapitole Z definice OSPF protokolu je nutné, aby všechny oblasti byly připojeny k oblasti 0. V opačném případě nebude směrování v síti probíhat korektně. Detekce tohoto problému probíhá analogicky k tomu, jak bylo popsáno v kapitole Duplikátní RID na sousedních směrovačích Jak již bylo řečeno, RID je unikátním identifikátorem směrovače v rámci OSPF sítě a není dovoleno, aby dva směrovače v sítí měly stejné ID. Hodnota RID se nachází v hlavičce každého OSPF paketu a značí směrovač, který daný paket odeslal. V rámci duplikátních RID je možné detekovat dva typy chyb [38]: Prvním případem je duplikátní RID na dvou (či více) směrovačích v rámci jedné oblasti. V tomto případě směrovač generuje chybu znázorněnou na obrázku Externí sítí je v tomto kontextu v případě stub oblasti myšlena síť mimo daný autonomní systém; v případě totally stubby oblasti je to síť mimo danou oblast. 20

24 OSPF-4-DUP_RTRID1: Detected router with duplicate router ID in area 0 Obrázek 3-13 Duplikátní RID v rámci oblasti. Zdroj: [38] Druhým typem duplikátních RID je případ, kdy dva (či více) směrovačů sdílí stejný identifikátor v rámci OSPF sítě, avšak v rámci jiných oblastí. V tomto případě směrovač generuje chybu oznamující, že detekoval duplikátní RID v LSA-4, které popisuje sítě dostupné mimo oblast. OSPF-4-DUP_RTRID2: Detected router with duplicate router ID in Type-4 LSA advertised by Obrázek 3-14 Duplikátní RID v různých oblastech. Zdroj: [38] 3.7 Priorita směrovačů V kapitole byl vysvětlen koncept DR a BDR směrovačů a postup při jejich volbě. V prvním kroku je jako DR vybírán ten směrovač, který má nejvyšší OSPF prioritu. V případě, že má směrovač prioritu nastavenu na hodnotu 0, nemůže být zvolen DR ani BDR. Problém nastává ve chvíli, kdy mají všechny směrovače v rámci segmentu nastavenu prioritu na hodnotu 0. V takovém případě není možné zvolit DR ani BDR, směrovače zůstávají v two-way stavu a nepokračují v budování adjacency vztahu se svými sousedy. [39] Obrázek 3-15 znázorňuje hlášení o nezvolení DR a BDR směrovačů. OSPF: DR/BDR election on FastEthernet0/0 OSPF: Elect BDR OSPF: Elect DR DR: none BDR: none Obrázek 3-15 Nezvolení DR a BDR 21

25 R2(config-if)#do sh ip ospf ne Neighbor ID Pri State Dead Time Address Interface WAY/DROTHER 00:00: FastEthernet0/0 Obrázek 3-16 Směrovače zůstávají v two-way stavu 3.8 Pasivní síťové rozhraní Pasivní síťové rozhraní označuje rozhraní, které nemůže přijímat ani odesílat hello pakety a tedy směrovač nemůže vytvářet adjacency vztahy s ostatními směrovači na daném segmentu připojeném k pasivnímu rozhraní. Díky tomu je dovoleno propagovat podsíť daného segmentu dále do OSPF domény i v případech, že tato podsíť se dále neúčastní OSPF směrování. V případě, že je pasivní rozhraní konfigurováno mezi dvěma sousedními směrovači, které mají dle návrhu OSPF sítě komunikovat, není tato komunikace umožněna, neboť směrovač s pasivním rozhraním se ve vztahu k sousednímu směrovači chová, jako by se OSPF směrování neúčastnil. [17] 3.9 Blokování paketů OSPF jako protokol směrující na základě stavů linek potřebuje ke své činnost znát kompletní topologie celé sítě (oblasti). Na jejím základě jednotlivé směrovače počítají nejkratší cesty do cílových podsítí. V případě, že se informace o topologii mezi jednotlivými směrovači neshodují, mohou se v rámci směrování vyskytnout smyčky nebo slepé oblasti, do kterých není z určitých částí sítě vůbec směrováno. Nekompletní informace o topologii sítě se mohou vyskytovat v případě, že je část OSPF provozu v síti blokována. To může být způsobeno nevhodným filtrováním paketů, kdy je část datových toků mezi sousedními směrovači blokována. I v tomto případě nemusí být směrovače schopny navázat adjacency vztah a tudíž ani vzájemně vyměňovat směrovací informace. [9] 22

26 4 BGP Border Gateway Protocol (BGP) je směrovacím protokolem využívaným zejména pro výměnu směrovacích informací mezi autonomními systémy. BGP je používáno pro internetové směrování a pro směrování mezi poskytovateli internetového připojení (ISP), kdy pro směrování v zákaznických sítích je využíváno některého z protokolů pro směrování uvnitř AS (Interior Gateway Protocol, IGP). BGP je možné využívat dvěma způsoby. Prvním z nich je zmiňované směrování mezi autonomními systémy; tehdy je BGP nazýváno jako externí BGP (ebgp). V případě, že se BGP využívá ke směrování uvnitř autonomního systému, jedná se o interní BGP (ibgp). [15] BGP je velice robustním směrovacím protokolem. Počet cest ve směrovacích tabulkách BGP využívaného v internetu čítá v dnešní době stovky tisíc záznamů [4]. K zajištění správného a stabilního směrování při obrovském počtu možných destinací a cest využívá BGP mnoho atributů, na základě kterých se při výběru správné cesty rozhoduje. Kromě atributů je využíváno také beztřídního směrování (Classless Interdomain Routing, CIDR), které umožňuje redukci počtu směrovacích informací v případě sumarizace adres, ale také rozdělení dříve třídních adres do většího počtu podsítí, což počet směrovacích informací v tabulkách naopak výrazně zvyšuje. [15] V současné době se používá čtvrtá verze protokolu BGP (BGP-4), která je definována v RFC 4271, jenž nahradilo původní dokument RFC [29] 4.1 Výběr optimální cesty BGP využívá TCP protokolu na portu 179. Poté, co mezi sebou dva směrovače zahájí komunikaci, stávají se z nich tzv. peer směrovače (sousední směrovače, sousedé). Následně si sousedé dohodnou parametry k umožnění BGP komunikace. Směrovače si vyměňují veškeré své směrovací informace uložené v BGP směrovacích tabulkách. BGP nepoužívá periodické aktualizování mezi peer směrovači, ale jsou zasílány pouze změny ve směrovacích informacích. Jsou používána čísla verzí směrovacích tabulek k zajištění aktuálnosti informací a tato čísla musejí být stejná v rámci všech BGP peerů. Číslo verze je inkrementováno s každou aktualizací BGP směrovacích tabulek. [3] BGP směrovače sdílí se svými sousedy informace o dostupnosti cílových sítí. Ty jsou reprezentovány celkovou cestou k dané cílové síti vyjádřenou čísly BGP autonomních systémů, kterými prochází. Tato informace je následně použita k vytvoření grafu bezsmyčkových (loop-free) cest autonomními systémy. [15] 23

27 4.1.1 ebgp vs. ibgp Jak již bylo v úvodu řečeno, BGP je možné využívat dvěma způsoby. Prvním z nich je směrování mezi autonomními systémy, kdy každý z komunikujících peer směrovačů spadá do jiného autonomního systému a BGP je v tomto případě označováno jako externí (ebgp). [15] Druhým případem jsou směrovače ze stejného autonomního systému, kdy je BGP nazýváno jako interní (ibgp). Autonomní systém, v němž ibgp běží, figuruje jako tranzitní a přenáší směrovací informace mezi jinými autonomními systémy. Stejného cíle lze dosáhnout redistribucí směrovacích informací z BGP do IGP protokolu na vstupu do tranzitního autonomního systému a následnou redistribucí zpět z IGP do BGP na výstupu. Použití ibgp v rámci autonomního systému poskytuje možnost využívat BGP atributy pro rozhodování o nejlepší cestě a např. preferovat určité výstupní body sítě (viz kapitola 4.2). Toto řešení však klade značné paměťové nároky na ibgp směrovače. V případě ibgp nepropagují směrovače cesty zjištěné od svých ibgp sousedů ostatním ibgp peer směrovačům v rámci autonomního systému. [15] Stavy BGP procesu Dříve než si začnou BGP směrovače vyměňovat směrovací informace, musí spolu navázat komunikační spojení. Celý proces je rozdělen do šesti stavů [15][29]: Idle iniciální stav BGP spojení. BGP směrovač, který se nachází v tomto stavu, se pokouší o navázání TCP spojení se svým peerem. Odmítá všechny příchozí BGP spojení až do doby tzv. spouštěcí události. Poté alokuje potřebné zdroje pro spojení se svým peer směrovačem, začíná navazovat spojení a současně naslouchá komunikaci iniciované sousedním peerem. Následně přechází do stavu connect. Spouštěcí událost je definovaná jako manuální či automatické spuštění BGP spojení s peerem. Pokud se v jakémkoliv stavu objeví chyba, je BGP spojení přerušeno a proces se dostává právě do tohoto stavu. Pokud se proces není schopen dostat z idle stavu dále, příčinou může být neotevřený TCP port 179 nebo nesprávně konfigurovaná adresa sousedního peeru či autonomního systému. Connect během tohoto stavu je dokončováno TCP spojení. Pokud se podaří TCP spojení úspěšně navázat, odesílá směrovač svému sousedovi open zprávu a přechází do stavu opensent. Pokud se během dokončování TCP spojení vyskytne jakákoliv chyba, přechází BGP proces do stavu active. Active pokud se BGP proces nachází v tomto stavu, snaží se směrovač se svým sousedním peerem navázat TCP spojení, které bylo v předchozím stavu neúspěšné. Po úspěšném 24

28 dokončení je stejně jako ve stavu connect odesílána open zpráva a BGP proces přechází do stavu opensent. OpenSent BGP směrovač, který se nachází v tomto stavu, čeká na open zprávu od svého peer směrovače. Po obdržení ověřuje její validitu. Musí se shodovat ve verzi uvedené v hlavičce příchozí open zprávy, číslo autonomního systému musí odpovídat autonomnímu systému konfigurovanému k danému peeru a autentizační řetězec musí být shodný. V tomto stavu je rozhodováno, zda je sousední směrovač ze stejného autonomního systému (ibgp) nebo z jiného (ebgp). Obrázek 4-1 Konečný automat znázorňující přechody mezi stavy BGP protokolu OpenConfirm směrovač nacházející se v tomto stavu čeká na keepalive zprávu od svého souseda. Jakmile ji obdrží, přechází do stavu established. Neobdrží-li keepalive zprávu do doby stanovené časovačem hold timer (viz kapitola 4.1.3), odesílá svému sousedovi oznámení o vypršení časovače a přechází do iniciálního stavu idle. 25

29 Established stav, který značí úspěšné spojení BGP směrovačů. Established je jediným stavem, ve kterém si směrovače mohou vyměňovat směrovací informace. Pokud směrovač neobdrží chybové hlášení od svého souseda nebo nevyprší-li jeho hold timer, setrvává BGP proces v tomto stavu Typy zpráv BGP protokol využívá při komunikaci mezi sousedními směrovači čtyři typy zpráv [15][29]: Open jak bylo uvedeno v předchozí kapitole, open zpráva je první zprávou, jež směrovač zasílá svému peer směrovači po navázání TCP spojení. Pokud sousední směrovač open zprávu přijme, zasílá zpět keepalive zprávu jako potvrzení. Jakmile je open zpráva potvrzena, mohou si směrovače vyměňovat všechny ostatní typy zpráv. Tento typ zprávy nese mimo jiné informace o verzi BGP protokolu, hodnotu časovače hold timer nebo informaci o BGP ID. BGP ID je 32 bitové číslo ve formátu IP adresy a je využívána některá z adres konfigurovaných na daném směrovači. Update tento typ zprávy je využíván k přenosu směrovacích informací mezi jednotlivými směrovači. Keepalive jedná se o zprávy, kterými si sousední směrovače ověřují vzájemnou dostupnost. Keepalive zprávu musí směrovač obdržet před vypršením časovače hold timer, jinak je sousední směrovač považován za nedostupný. Keepalive zprávy nesmí být dle specifikace zasílány častěji než jednou za sekundu. Je-li hold timer nastaven na hodnotu 0, nesmí být keepalive zprávy vůbec zasílány. Notification typ zprávy, který je odesílán sousednímu směrovači v případě detekování chyby v komunikaci. BGP spojení je okamžitě po odeslání zprávy ukončeno a BGP proces přechází do stavu idle. Všechny typy zpráv sdílejí stejnou hlavičku paketu o třech polích [29]: Marker šestnácti bytové pole sloužící pro zpětnou kompatibilitu. Dle definice nastaveny všechny bity na hodnotu 0. Velikost paketu celková velikost paketu v bytech. Typ typ přenášené BGP zprávy (open, update, keepalive, notification). 26

30 Obrázek 4-2 Hlavička BGP paketu společná pro všechny typy zpráv Algoritmus výběru Jelikož může BGP dostat různé směrovací informace do cílových sítí, je nutné, aby byl aplikován mechanizmus, který vybere nejlepší cestu z nabízených. Ta je poté umístěna do směrovací tabulky směrovače a propagována dále sousedům. Následuje postup výběru nejlepší cesty. [2] Atributy použité při výběru budou popsány v následující kapitole 4.2. Jestliže cesta k cíli vede přes next-hop 6 směrovač, který není dostupný, je zahozena. Existují-li dvě cesty do cílové sítě, je preferována ta, jež má vyšší hodnotu atributu lokální preference. Je-li atribut lokální preference shodný, preferuje BGP kratší cestu v závislosti na parametru AS_Path. Shodují-li se cesty i v parametru AS_path, dává BGP přednost cestě s nižší hodnotou atributu origin-type. Jsou-li hodnoty origin-type shodné, vybírá BGP cestu s nejnižší hodnotou atributu MED. Jestliže jsou hodnoty MED stejné, preferuje BGP externí cestu před interní. Shodují-li se cesty i nadále, je vybrána cesta přes nejbližší IGP směrovač. Posledním výběrem je preference cesty přes směrovač s nejnižším BGP ID. Jednotlivé BGP implementace mohou k základnímu výběru přidat vlastní rozhodování. Cisco implementace BGP protokolu přidává vlastní atribut weight a při výběru nejlepší cesty dává v prvním kroku přednost cestě s nejvyšší hodnotou tohoto atributu. [2] 6 Next-hop router první nejbližší router v cestě k danému cíli. 27

31 4.2 BGP atributy V předchozí kapitole byl představen algoritmus výběru nejlepší cesty. Rozhodování probíhá na základě mnoha atributů. Jednotlivé atributy budou popsány v následující kapitole Lokální preference Atribut lokální preference umožňuje upřednostňovat určitý výstupní bod (směrovač) z autonomního systému a je propagován mezi všemi BGP směrovači v rámci tohoto autonomního systému. Obdrží-li více směrovačů daného AS informaci o cestě do stejné cílové destinace, porovnává BGP hodnoty lokální preference a v případě, že jsou nastaveny na jiné hodnoty, upřednostňuje cestu, která vede přes směrovač s vyšší hodnotou tohoto atributu. [15] Multi-exit discriminator (MED) Multi-exit descriminator (MED) atribut informuje externí autonomní systém o preferovaném vstupním bodě do daného autonomního systému, který tento atribut propaguje. Externí autonomní systém není povinný se tímto atributem striktně řídit, neboť v rámci výběru nejlepší cesty může upřednostnit jinou cestu do autonomního systému v závislosti na jiném atributu (viz předchozí kapitola). V případě, že je tento atribut brát v potaz, je upřednostňována cesta, která propaguje nižší MED hodnotu pro vstup do daného autonomního systému. [15] Origin-type Origin-type atribut nese informaci u původu dané cesty. Může nabývat tří hodnot: IGP značí interní cestu do podsítě daného autonomního systému. EGP cesta distribuovaná z externího autonomního systému (ebgp). Incomplete hodnota, jež značí cesty redistribuované do BGP V případě výběru cesty v závislosti na atributu origin-type jsou preferovány cesty s nižší hodnotou, kdy IGP je nižší než EGP a EGP hodnota je nižší než incomplete. [3] AS_path Atribut AS_path využívá uspořádaný seznam, do nějž BGP postupně ukládá čísla autonomních systémů, kterými daná cesta prochází. Detekuje-li směrovač číslo svého autonomního systému v atributu AS_path, zahazuje tuto aktualizaci, čímž předchází vytváření směrovacích smyček (routing loops). [3] 28

32 4.2.5 Next-hop Next-hop atribut obsahuje IP adresu směrovače, přes který je daná cílová síť dostupná. V případě ebgp spojení se jedná o IP adresu směrovače, který generuje informací o této cestě. U ibgp je next-hop atribut přenášen nezměněný v rámci autonomního systému. Směrování v rámci autonomního systému musí poskytovat některý z IGP protokolů, který zajistí dostupnost next-hop směrovače, přes který je cílová podsíť dostupná. [15] Community Community atribut popisuje, jakým způsobem má být daná cesta propagována. Umožňuje sdružovat sítě do skupin a aplikovat na ně pravidla na základě lokální směrovací politiky (preference cest, redistribuce apod.). Community atribut má tři předdefinované hodnoty [15]: No-export cesta je díky tomuto atributu propagována pouze v rámci autonomního systému, který aktualizaci s ní obdržel. Směrovačům do dalších autonomních systémů propagována dále není. No-advertise atribut přijímajícímu směrovači říká, že cestu, kterou obdržel, nemá propagovat ani v rámci svého autonomního systému. Internet cesty s atributem community nastaveným na hodnotu internet jsou propagovány bez omezení v rámci celé sítě Weight Weight atribut je Cisco proprietárním atributem. Je pouze lokální pro konkrétní směrovač, takže není propagován sousedním peer směrovačům. Zjistí-li směrovač přístupnost cílové sítě přes více svých sousedů, vybírá cestu přes souseda, pro kterého má nastavenou vyšší hodnotu atributu weight.[3] 4.3 Další vlastnosti protokolu BGP umožňuje využít loopack rozhraní jako adresu sousedního peer směrovače. Tím zvyšuje stabilitu navázaného spojení mezi dvěma směrovači, neboť spojení je nezávislé na hardwarovém rozhraní. Tohoto konceptu je obvykle využíváno pouze v rámci ibgp spojení. [15] V případě ebgp je někdy nutné navázat peer spojení se směrovačem, který není přímo připojený. V takovém případě umožňuje BGP konfigurovat tzv. multihop, kdy přímo připojený soused daného směrovače není BGP peerem, ale zprostředkovává pouze přístup k tomuto peer směrovači. [3] 29

33 Stejně jako ostatní směrovací protokoly i BGP umožňuje redistribuci směrovacích informací z jiných směrovacích protokolů či redistribuci statických cest. Obrázek 4-3 BGP synchronizace. Převzato a upraveno z: [3] Synchronizace Synchronizace je využívána, pokud daný autonomní systém slouží jako tranzitní oblast pro jiné dva autonomní systémy. V tomto případě je nutné zajistit, aby autonomní systém propagoval příchozí směrovací informace do dalšího autonomního systému až poté, co jsou tyto informace rozšířeny v rámci lokálního autonomního systému i pomocí některého z IGP protokolů. Nesplnění této podmínky může mít za následek nemožnost komunikace mezi autonomními systémy, neboť jak již bylo řečeno v kapitole 4.2.5, next-hop atribut je přenášen v rámci autonomního systému pomocí ibgp v nezměněné podobě a je tedy nutné zajistit správné směrování do cílové podsítě i v rámci tranzitního autonomního systému. [3] Obrázek 4-3 znázorňuje tři propojené autonomní systémy. Směrovač RTC odesílá informace o připojené síti směrovači RTA. Mezi směrovači RTA a RTB běží ibgp a směrovač RTB tedy získá směrovací informace pro danou síť od RTA. Aby RTB mohl směrovat do inzerované sítě, musí zasílat data přes směrovač RTE. Jestliže RTA neredistribuoval informace o síti do IGP, RTE o ní nemá žádné informace. Propaguje-li RTB tuto síť směrovači RTD, jsou všechna data směrována z RTD do sítě na směrovači RTE zahozena, neboť RTE nemá o cílové síti žádné informace. Synchronizace zajišťuje, že směrovač RTB nebude propagovat síť směrovači RTD, dokud o ní nebude informován v rámci lokálního AS pomocí IGP protokolu. (Převzato a upraveno z [3]) 30