Směrovací protokol BGP

Cíl kapitoly

Cílem kapitoly je seznámit se s dělením Internetu na autonomní systémy (AS) a pochopit princip směrování mezi AS s použitím směrovacího protokolu BGP. Čtenář bude schopen zvážit potřebu přidělení samostatného AS síti a navrhnout základní konfiguraci směrovacího protokolu BGP na hraničních směrovačích autonomního systému.

Prekrekvizity

Studium této kapitoly předpokládá obecnou znalost problematiky směrování a představu o způsobu fungování směrovacích protokolů třídy IGP.

Vnitřní a vnější směrovací protokoly

Směrovací protokoly dělíme na vnitřní (Interior Gateway Protocol-IGP) a vnější (Exterior Gateway Protocol-EGP). Abychom plně pochopili smysl tohoto dělení, musíme se nejprve seznámit s pojmem autonomního systému.

Autonomní systémy a hierarchické směrování

Současný Internet je natolik rozsáhlý a proměnlivý, že není reálné udržovat ve směrovačích úplnou informaci o jeho topologii. Navíc by tato informace byla velmi nestabilní, protože by se měnila s výpadkem nebo zapojením linky kdekoli na světě. Proto bylo rozhodnuto směrování v Internetu řešit hierarchickým způsobem. Předpokladem jeho použití je rozdělení Internetu do tzv. autonomních systémů (AS). Autonomním systémem rozumíme souvislou skupinu sítí a směrovačů, které jsou pod společnou správou a řídí se společnou směrovací politikou. Pod společnou směrovací politikou si představme zejména dohodnutý vnitřní směrovací protokol (např. OSPF nebo RIP), ale také speciální požadavky administrátorů na směrování některých druhů provozu (traffic engineering, load balancing). Příkladem autonomního systému tak může být autonomní systém jednoho konkrétního poskytovatele Internetu (ISP) nebo velké firmy.

Při směrování v rámci jednotlivých autonomních systémů se používají tzv. vnitřní (interior) směrovací protokoly - Interior Gateway Protocols, IGP. Naopak pro směrování mezi autonomními systémy se používají vnější (exterior) směrovací protokoly - Exterior Gateway Protocols, EGP.

Princip hierarchického směrování spočívá v tom, že z pohledu externích směrovacích protokolů jsou autonomní systémy chápány jako základní jednotky, jejichž struktura již není mimo hranice autonomního systému známa. U každého autonomního systému se pouze eviduje, které adresy sítí autonomní systém obsahuje. Autonomní systémy jsou číslovány celosvětově jednoznačnými šestnáctibitovými čísly. Cílem je vždy doručit paket určený pro některou ze sítí autonomního systému na hranice tohoto autonomního systému. O další směrování ke konkrétní síti uvnitř AS se již postará vnitřní směrovací protokol, který topologii (nebo alepoň cesty ke všem sítím) svého vlastního AS zná. Směrovač, který je na hranici autonomního systému a účastní se jak na vnějším, tak na vnitřním směrovacím protokolu, se nazývá hraniční směrovač (angl. border gateway).

Poznámka:
Každý autonomní systém propaguje pomocí vnějšího směrovacího protokolu všechny své sítě, které mají být z vnějšího světa dostupné. Protože těchto sítí může být velké množství, je výhodné, když mají tyto sítě společný prefix adresy a mohou být propagovány společně jako jediná supersíť (supernet).

Typy autonomních systémů

Podle počtu linek, kterými je autonomní systém připojen k okolnímu světu, můžeme autonomní systémy rozdělit na tzv. single-homed a multi-homed . Single-homed autonomní systém je připojen jedinou linkou k jinému AS (typicky poskytovatel Internetu, angl. Internet Service Provider - ISP), zatímco multi-homed systém je připojen více linkami. Linky multi-homed autonomního systému mohou vést k tomutéž ISP nebo (častěji) k více různým ISP. Autonomní systém, který dovoluje průchod provozu, který v něm nezačíná ani nekonční, se nazývá tranzitní autonomní systém. Tranzitní samozřejmě mohou být pouze multi-homed AS. Ne každý multi-homed AS je však používán jako tranzitní - multi-homed AS je např. každý AS firmy, která chce mít záložní spojení k více než jednomu ISP. Firma však nemusí mít zájem na tranzitu cizího provozu přes svou síť. Naopak tranzitní systém samozřejmě musí být multi-homed (single-homed AS je připojen pouze jedinou linkou, takže přes něj nemůže žádný provoz procházet).

Single-homed AS

U single-homed AS hraniční směrovač poskytovatele Internetu (ISP) propaguje sítě uvnitř AS zákazníka pomocí vnějšího směrovacího protokolu dál do Internetu (obr. XXX). Směrovače uvnitř AS zákazníka obvykle směrují k sítím vně AS s použitím default cesty, protože je zbytečné zahlcovat vnitřní směrovače v AS kompletními směrovacími tabulkami Internetu - beztoho existuje pouze jediná cesta z AS ven.

Sítě, které má směrovač poskytovatele propagovat dále do Internetu, mohou být na směrovači ISP staticky nakonfigurovány, nebo se o nich může dozvědět prostřednictvím směrovacího protokolu na lince ISP-zákazník. Na této lince může být provozován nějaký vnitřní směrovací protokol (např. OSPF) - obr. XXXX. Pomocí něj se do BGP redistribují cesty ke všem sítím zákazníka, které jsou právě funkční a viditelné protokolu OSPF.

Pokud si zákazník přeje snadněji ovlivňovat sítě, které ze svého AS propaguje, nebo které naopak přijímá do svých směrovacích tabulek, může na lince k ISP provozovat protokol BGP (obr. XXX).

Všimněte si, že v tomto případě není obvykle z důvodu úspory čísel AS zákazníkovi zpravidla přiděleno jednoznačné číslo AS, ale číslo z rozsahu tzv. privátních autonomních systémů (64512 - 65535).

Čísla privátních AS se v Internetu mohou opakovat. S privátními čísly AS se totiž manipuluje pouze v rámci AS poskytovatele, který privátní AS přidělil a sám již má veřejné číslo AS. Navenek se sítě v privátním AS jeví, jako by byly částí AS poskytovatele (obr. XXX). Privátní AS může být použit pouze tehdy, když je AS připojen k poskytovateli jedinou linkou nebo více linkami k témuž poskytovateli.

Pokud k tomu není speciální důvod, nepřiděluje se síti každého zákazníka zvláštní AS. Naopak sítě zákazníků bývají často součástí AS poskytovatele (obr. XXX).

K žádosti o vlastní jednoznačné číslo AS zákazník typicky přistupuje pouze v případě, že se v budoucnu hodlá připojit k více různým poskytovatelům.

Netranzitní multi-homed AS

Netranzitní multihomed AS se použije tehdy, když má být síť připojena z důvodu odolnosti proti výpadku k více různým poskytovatelům. Autonomní systém však nepřipouští tranzit cizího provozu. Jak je naznačeno na obrázku XXX, AS24 možnost přístupu k sítím AS ISP2 prostřednictvím sebe do ISP1 vůbec neoznamuje.

Poznámka
Všimněte si, že i když AS24 nepropaguje cesty k sítím v AS ISP2 do AS ISP1, může se ISP1 provoz pro ISP2 autonomnímu systému AS24 pro tranzit vnutit explicitně (např. statickým směrováním). Proto se u netranzitních multihomed AS často instalují na vstupní linky filtry, které nepropouštějí pakety určené pro sítě vně tohoto netranzitního AS.

Tranzitní multi-homed AS

Příklad použití tranzitního AS je na obrázku XXX. Vidíme zde, že AS1 je si vyměňuje směrovací informaci s autonomními systémy ISP1 a ISP2. Na obrázku XXX je šipkami znázorněno, které sítě jsou propagovány do kterých AS.

Směrovací protokol BGP

Směrovací informace se mezi autonomními systémy vyměňuje prostřednictvím hraničních routerů, angl. border gateway. Z tohoto názvu je odvozeno i jméno v současnosti prakticky jediného používaného vnějšího směrovacího protokolu: Border Gateway Protocol - BGP. Pomocí BGP si hraniční směrovače vyměňují informace o sítích v jednotlivým autonomních systémech a o tom, přes které autonomní systémy se lze k jednotlivým sítím dostat (obr. X). V dnešní době se používá téměř výhradně protokol BGP ve verzi 4 (RFC XXXX).

Protokol BGP podporuje beztřídní adresování (CIDR). S každým prefixem (adresou sítě, resp. jejich prvních bitů) se totiž šíří i délka příslušného prefixu. Díky tomu může BGP realizovat i agregaci adres.

Vyhledávání cest a směrovací politiky

Protokol BGP nepracuje s grafem propojení jednotlivých směrovačů a sítí (jako to dělá např. OSPF), ale s grafem propojení autonomních systémů. V tomto grafu jsou pak vyhledávány cesty mezi sítěmi v různých autonomních systémech. Cestou (AS PATH) k nějaké síti se v terminologii BGP rozumí posloupnost čísel autonomních systémů, přes které se lze k cílové síti dostat.

Na rozdíl od vnitřních směrovacích protokolů nemá BGP jednoznačnou metriku, podle níž by za všech okolností automaticky volil nejkratší cesty do jednotlivých cílových sítí, jako to dělají směrovací protokoly třídy IGP. Při směrování mezi AS totiž směrujeme provoz přes cizí AS, jejichž provozovatelé mají nejrůznější zájmy a provozní i obchodní podmínky. Respektováním všech těchto faktorů pak určíme tzv. směrovací politiku (angl. routing policy). Směrovací politika například určuje

do kterých AS necháme tranzitovat provoz přes náš AS
ze kterých zdrojových AS necháme tranzitovat provoz přes náš AS
kterou výstupní linkou z našeho AS necháme odcházet provoz k daným sítím
kterou vstupní linkou do našeho AS necháme vstupovat provoz ke kterým sítím

Protože je třeba do konfigurace protokolu BGP všechny faktory směrovací politiky zahrnout, je jeho konfigurace mnohem více manuální, než je tomu u protokolů třídy IGP. U protokolů IGP jsou obvykle sousední směrovače vyhledávány automaticky a předpokládá se, že komunikovat spolu mohou všechny nalezené směrovače a že cesty do jednotlivých cílových sítí nejsou omezeny žádnými dodatečnými podmínkami, než je minimální hodnota metriky. Naopak u BGP jsou sousední směrovače konfigurovány manuálně, stejně jako transformace prováděné nad cestami předávanými mezi jednotlivými sousedy.

Suboptimální směrování

Všimněme si, že z pohledu počtu přeskoků, resp. cen spojů či jiné metriky není směrování v Internetu optimální. Optimalita směrování však v praxi není z mnoha důvodů dosažitelná a kvůli potřebě aplikace různých směrovacích politik ani žádaná. Základním technickou komplikací pro dosažení optimálního směrování je neexistence společně interpretované metriky - každý vnitřní směrovací protokol používá svou, s ostatními nesrovnatelnou, metriku (např. hop-count, cena, kompozitní metrika). Suboptimální hierarchické směrování je naopak výhodné, protože omezuje počet záznamů ve směrovací tabulce s využitím položky default pro všechny sítě mimo autonomní systém.

Funkce směrovacího protokolu BGP

Vnitřní směrovací protokoly se tradičně rozdělují na distance-vector a link-state. Z pohledu úrovně znalosti topologie sítě, způsobu předávání i obsahu směrovací informace se protokol BGP řadí na jejich pomezí. Někdy bývá označován jako protokol speciální třídy, nazývané path-vector. Path vector je potom posloupnost čísel autonomních systémů, přes které vede cesta k nějaké síti. Spolu s každou cestou je šířen i její path vector, který se postupně prodlužuje, jak se cesta šíří do stále vzdálenějších autonomních systémů. Protože cesta nesmí obsahovat smyčku, může se číslo autonomního systému v path vector objevit nejvýše jednou. Smyčky se automaticky odstraňují tak, že AS zahazuje cesty, které již v path vectoru obsahují jeho vlastní číslo autonomního systému.

Path vector také slouží k výběru nejkratší cesty do jednotlivých sítí. Nejkratší cesta zde bude ta, která prochází co nejmenším počtem autonomních systémů. Při výběru tedy budou preferovány ty cesty, jejichž path vector je kratší.

Směrovací informace (routing updates) se v BGP vyměňuje vždy mezi sousedními, tzv. peer směrovači. BGP směrovače jsou vždy na hranicích autonomního systému. Každému BGP směrovači jsou při konfiguraci manuálně přiřazeni sousedé (peer routers), se kterými si bude směrovací informaci vyměňovat. Aby výměna této informace byla spolehlivá, probíhá s použitím protokolu TCP (port 179).

Po navázání spojení mezi sousedy se mezi těmito sousedy vymění kompletní směrovací informace, která je oběma známa. Dále pak již probíhá pouze inkrementální výměna.

Každý směrovač si periodicky (obvykle 1x za minutu) testuje dostupnost každého svého souseda pomocí tzv. keepalive zpráv. Pokud soused přestane být dostupný, musí směrovač odstranit všechny cesty vedoucí přes tohoto souseda a informovat o změně všechny své ostatní sousedy.

Zprávy protokolu BGP

Existují 4 typy zpráv, které si mezi sebou mohou sousedé vyměňovat. Všechny zprávy se šíří mezi (logicky) sousedními směrovači. O tom, které směrovače budou sousedy, rozhoduje administrátor při konfiguraci BGP. Zprávy se vyměňují prostřednictvím k tomu účelu navázaného TCP spojení a mají společnou hlavičku. V hlavičce je mimo jiné pole podporující autentikaci sousedů.

Protokol BGP definuje tyto zprávy:

OPEN - zpráva vyměňovaná při zřizování vazby mezi sousedními směrovači. V ní se například dohaduje verze používaného protokolu BGP a sousední směrovače se také vzájemně informují o číslech AS, do nichž patří.
UPDATE - zpráva nesoucí samotnou směrovací informaci. Ta se sestává z několika dvojic < prefix,délka_prefixu >. Sítě s IP adresou začínající inzerovaným prefixem jsou dostupné přes AS, jehož hraniční směrovač zprávu UPDATE zaslal. Dále může být ve zprávě také proměnný počet tzv. atributů , které jsou společně přiřazeny všem uvedeným cestám. Zpráva dále obsahuje sekci "Withdrawn Routes", která obsahuje cesty, jež přestaly být použitelné a mají být odstraněny.
Všimněte si, že při změně hodnoty nějakého atributu se nejprve cesta s původní hodnotou atributu musí odstranit uvedením cesty v sekci Withdrawn Routes a až následně se cesta znovu uvede s novou (změněnou) hodnotou atibutu.
KEEPALIVE - zpráva vyměňována periodicky pro ověřování funkčnosti linky mezi sousedy. Typicky se vysílá každých 60 sekund. Spojení se považuje za nefunkční, pokud od souseda nepřišla zpráva KEEPALIVE po dobu HoldTime dohodnutou předtím pomocí zprávy OPEN.
NOTIFICATION - zpráva indikující chybu v činnosti BGP. Vysílá se také při absenci zprávy KEEPALIVE po dobu HoldTime. Po vyslání zprávy NOTIFICATION dojde k ukončení vazby mezi sousedy rozpojením TCP spojení.

Informace o cestách získaných od sousedů se směrovač ukládá do databáze. Do každé sítě směrovač volí některou z cest uložených v databázi a ukládá si tuto cestu jako záznam směrovací tabulky. Cesty, které směrovač sám používá (tj. vybral si je do směrovací tabulky) pak propaguje svým sousedům.

Externí a interní BGP (IBGP)

Směrovací informace se prostřednictvím zpráv UPDATE postupně šíří mezi dvojicemi hraničních směrovačů sousedních autonomních systémů. Pokud je hraničních směrovačů v jednom AS více, je třeba, aby se směrovací informace šířila nejen přes hranice AS (mezi BGP peery v různých AS), ale i mezi hraničními směrovači téhož AS. Ty mohou být od sebe vzdálené a vzájemně dostupné pouze zprostředkovaně přes vnitřní infrastrukturu autonomního systému (tj. přes síť směrovačů s nějakým IGP směrovacím protokolem). Vazbu (session) mezi BGP směrovači v různých AS nazýváme externí BGP (EBGP), vazbu mezi BGP směrovači v tomtéž AS potom interní BGP (IBGP). Všimněte si, že u IBGP je vazba pouze logická, směrovače v tomto případě nemusí být přímými sousedy.

U externího BGP zamezujeme cyklickým cestám tak, že do AS nepřijímáme cesty, jejichž path vector již obsahuje číslo tohoto AS. Tuto metodu však nemůžeme uplatnit v případě předávání informace mezi více směrovači v témže AS (IBGP). Proto jsou jsou na předávní směrovací informace v rámci AS definovány dodatečné podmínky:

Informace přijatá z IBGP se šíří na EBGP peery, nešíří se však na IBGP peery.
Informace přijatá z EBGP se šíří na ostatní EBGP peery i na všechny IBGP peery.

Z důvodu podmínky 1 musí být konfigurovány vazby mezi všemi dvojicemi IBGP peerů v AS (full mesh).

Příklad realizace podmínky propojení všech dvojic IBGP peerů v AS vidíme na obr. XXX. Přesto, že poskytovatel má propojeny přípojné body (POP) v San Jose, San Francisco a Los Angeles do lineárního řetězce, musí existovat sousedství i mezi POP v LA a SJ. Jinak by směrovač v SF informaci získanou od SJ nepředal do LA a LA by neznal cesty, které se SJ naučil od cizího AS prostřednictvím EBGP.

Atributy

Vyhledávání cest na základě algoritmu path-vector umožní nalézt nejkratší cesty do všech autonomních systémů. Abychom však byli schopni explicitně ovlivňovat směrovací politiky, je potřebný mechanismus, kterým bychom vyjádřili preferenci, resp. zákaz některých cest podle nejrůznějších kritérií. K tomuto účelu v protokolu BGP slouží tzv. atributy , které můžeme každému záznamu o cestě k cílové síti (dále jen "cestě") přiřadit. Je definováno několik atributů, z nichž některé jsou povinné a některé nepovinné. Atributy dělíme do čtyřech kategorií:

Well-known mandatory - musí být povinně připojeny ke každé cestě a každá implementace BGP jim musí rozumět
Well-known discretionary - každá implementace BGP jim musí rozumět, avšak jejich připojení k cestě není povinné
Optional transitive - ne každá implementace BGP jim musí rozumět. V případě, že jim nerozumí, předává se atribut dále beze změny
Optional nontransitive - ne každá implementace BGP jim musí rozumět. V případě, že jim nerozumí, atribut se dále nepředává.

Ke každé cestě musí být přiřazeny všechny well-known mandatory atributy a dále volitelně i libovolné jiné atributy. Nejčastěji používané atributy jsou uvedeny v tabulce XXXXX.

Zpracování atributů

Politika směrování mezi AS se vynucuje manupulací s atributy cest přijímaných od jednotlivých peerů, resp. propagovaných k jednotlivým peerům a také filtraci těchto cest. Atributy jsou nastavovány a zpracovávány při přijetí update od souseda v tzv Input Processing Engine a před odesláním update sousedovi v tzv. Output Processing Engine (obr. XXX). U každého souseda můžeme samostatně stanovit, jaké transformace atributů se mají dít při příchodu update od tohoto souseda a při formulování update pro tohoto souseda.

Hodnoty atributů a prefixy cest mohou být testovány na různé podmínky a při shodě vhodným způsobem měněny hodnoty jiných atributů. Na základě hodnot atributů nebo prefixů cest mohou být také některé cesty filtrovány. Toto testování a nastavování se děje nezávisle při přijetí cesty nebo před její propagací.

Na obrázku XXX je vidět, jak BGP směrovač pracuje s cestami. Cesty přijímané od sousedů jsou zpracovávány podle politik přiřazených jednotlivým sousedům v tzv. Input Policy Engine. Zpracováváním rozumíme filtraci cest nebo manipulaci s jejich atributy. Následně se takto upravené cesty uloží do databáze, zde označované jako BGP tabulka. Z alternativních cest do jednotivých sítí se způsobem popsaným dále vyberou nejlepší a ty se instalují do směrovací tabulky. Výběr nejlepších cest je ovlivňován hodnotami atributu přiřazených k jednotlivým cestám. Vybrané nejlepší cesty se poté propagují o sousedům s tím, že jsou předtím zpracovány v tzv. Output Policy Engine. Zde se opět pro každého souseda zvlášť může provádět filtrace cest a manipulace s atributy.

Poznámka
Všimněte si, že vektor cesty je rovněž atributem. Nazývá se AS_PATH a je typu well-known mandatory.

Poznámka
Output processing engine rozlišuje mezi peery, s nimiž je navázán vztah IBGP a EBGP. Jak bylo uvedeno výše, na IBGP peery se cesty získaných od jiných IBGP sousedů nešíří.

Atribut AS_PATH

AS_PATH je well-known mandatory atribut, musí být tedy povinně uveden u každé cesty. Je základem funkce algoritmu path-vector. Obsahuje postupně řetězec čísel autonomních systémů, přes které vede cesta k cílové síti. Každý AS, přes nějž cesta prochází, na začátek AS_PATH přidá své číslo. Pokud se cesta dostane do AS, jehož číslo je již v AS_PATH uvedeno, cesta se ignoruje. Tímto způsobem se odstraňují cesty obsahující smyčku.

Pokud se vybírá z cest lišících se pouze v AS_PATH, volí se vždy cesta s "kratším" AS_PATH, tedy s hodnotou AS_PATH obsahující menší počet čísel AS.

Hodnota AS_PATH se v input a output policy engine chápe jako řetězec, který lze testovat např. na výskyt definovaného podřetězce pomocí regulárních výrazů. Takto lze např. vyloučit nebo naopak preferovat cesty procházející přes některé konkrétní AS. Také lze řetězec AS_PATH modifikovat, např. uměle jej prodlužovat vícenásobným vkládáním čísel AS. Tím můžeme uměle "prodloužit" a tím znevýhodnit cesty procházející přes některé AS.

Atribut NEXT_HOP

NEXT_HOP je well-known mandatory atribut, musí být tedy povinně uveden u každé cesty.

U směrovacích protokolů třídy IGP, zejména distance vector, se předpokládá, že adresa nejbližšího souseda na cestě k cílové síti (next hop) je adresa některého bezprostředně sousedícího směrovače-u protokolů třídy distance vector toho směrovače, který cestu poskytl (obr. XXX). Naopak u BGP se jako next hop zachovává adresa hraničního směrovače, který informaci o cestě do AS zaslal (tedy adresa směrovače z cizího AS). Proto je třeba, aby IGP cestu k tomutu směrovači znal. Často se tedy do IGP propagují i adresy spojovacích linek mezi AS.

Všimněte si, že NEXT_HOP směrovač nemusí být přímým sousedem, takže vyhledávání ve směrovací tabulce může být rekurzovní.

NEXT_HOP na síti typu broadcast

Předpokládejme tři směrovače RTA,RTB a RTC na společné síti (obr. XXX). Mezi RTA a RTC je relace EBGP. RTB a RTC patří do téhož AS a vyměňují si směrovací informace prostřednictvím nějakého směrovacího protokolu třídy IGP, v tomto případě OSPF. RTC pak na LAN jako next hop k síti 11.11.11.0/24 neinzeruje sám sebe, jak bycho mohli očekávat, ale přímo RTB, přestože RTB protokol BGP vůbec neprovozuje. Tím se omezí provoz na LAN a vyloučí zbytečný přeskok přes RTC.

Problém synchronizace BGP s IGP protokolem

U tranzitních systémů, kde všechny vnitřní směrovače neprovozují BGP, nastává problém. Vnitřní směrovače tötiž nemají úplné směrovací tabulky. Cílové adresy v tranzitujících paketech sice zná BGP, avšak nikoli IGP provozovaný uvnitř AS (obr. XXX). BGP směrovač tak zašle tranzitující paket správným směrem vnitřnímu směrovači, ten však cílovou adresu ležící mimo AS nezná a paket zahodí.

Případají v úvahu dvě řešení:

provozovat na všech směrovačích, přes něž prochází tranzitující provoz, protokol BGP. Takto se obvykle situace řeší u tranzitních autonomních systémů ISP.
redistribuovat cesty z BGP do IGP. Tato možnost je však problematická, protože protokoly třídy IGP nejsou pro zvládání tak velkých objemů směrovací informace konstruovány.

Pojem "synchronizace" říká, že IGP vidí stejné cesty jako BGP. Zpravida se implementace BGP v tomto případě chovají tak, že mimo AS šíří jen ty cesty, které "vidí" i přes IGP. Jen tak je totiž zajištěno, že cestu bude znát i IGP protokol uvnitř AS a vnitřní ne-BGP směrovače nebudou pakety určené pro tranzit zahazoovat.

Poznámka
I ve tranzitním AS mohou existovat směrovače, které neprovozují BGP a směrování do sítí mimo vlastní AS zajišťují pomocí default cesty mířící na některý směrovač s BGP. Jedná se samozřejmě jen o směrovače v okrajových částech AS, které neslouží pro tranzit, ale připojují lokální sítě tohoto tranzitního systému. Toto řešení samozřejmě vede k suboptimálnímu směrování, avšak to vzhledem k jeho jednoduší administraci není podstatné.

Agregace v BGP

V BGP lze agregovat cesty do jediné položky s kratším prefixem. Samozřejmě i zde platí, že agregovat lze jen tam, kde celý rozsah adres leží za agregujícím směrovačem. Agregovaná cesta se (podle AS_PATH) jeví, jako by vzešla z autonomního systému, kde byla agregace provedena.

Směrovač provádějící agregaci se v cestě obvykle identifikuje připojením svého ROUTER_ID v atributu AGREGATOR. Původní vektory (AS_PATH) agregovaných cest se někdy připojují k agregované cestě v podobě atributu AS_SET. Skutečnost, že cesta vznikla agregací původně nezávislých cest, se v cestě může indikovat nastavením atributu ATOMIC_AGGREGATE na hodnotu TRUE.

Příklad použití agregace je vidět na obr. XXX. Zde jsou sítě 160.11.0.0 v AS 200 a 160.10.0.0 v AS 300 při šíření do AS 100 agregovány jako cesta 160.0.0.0.

Způsoby ovlivňování cest

Umělé prodlužování AS_PATH

vícenásobné vkládání čísla AS
lze vkládat jen číslo vlastního AS

Atribut LOCAL_PREFERENCE

S použitím well-known discretionary atributu LOCAL_PREFERENCE se mohou směrovače (multihomed) autonomního systému dohodnout na společné volbě cesty k nějaké síti, která je dostupná přes více alternativních linek. V situaci podle obrázku XXX chceme preferovat cestu k síti 128.213.0.0 přes rychlejší linku T3 a cestu přes linku T1 použít jen při jejím výpadku. Proto je směrovač u linky T3 nakonfigurován tak, aby připojil k cestě do 128.213.0.0 atribut LOCAL_PREFERENCE s vyšší hodnotou než směrovač u linky T1. Směrovače potom v případě více alternativ vybírají vždy cestu s vyšší hodnotou atributu LOCAL_PREFERENCE.

Všimněte si, že atribut LOCAL_PREFERENCE se nešíří mimo hranice autonomního systému.

Atribut WEIGHT

Atribut LOCAL_PREFERENCE umožňují preferovat některou cestu v rámci všech směrovačů uvnitř AS. Některé implementace BGP (Cisco) implementují také atribut, který lze nastavit v input policy engine a nešíří se mimo směrovač. Lze jím tedy zvýšit nebo snížit preferenci některé cesty v rámci jednoho směrovače. Na obrázku XXX je nastavením vyšší váhy na cestu 170.20.0.0 propagovanou z AS 65000 zajištěno, že směrovač A bude pro provoz do sítě 170.20.0.0 preferovat cestu přes AS 65000.

Atribut MED (Multi-Exit Discriminator)

Zatímco atributy LOCAL_PREFERENCE a WEIGHT ovlivňují cestu pro odchozí provoz, atributem MED lze ovlivnit volbu cesty používanou sousedním AS pro dosažení jednotlivých sítí uvnitř, resp. za naším AS. Na obrázku XXX je vidět síť 180.10.0.0 v AS 300. Pokud správce AS300 preferuje, aby směrovač A v AS100 volil pro provoz do sítě 180.10.0.0 levou linku, bude touto linkou propagovat cestu k 180.10.0.0 s nižší hodnotou MED. Směrovač A v případě existence více cest k jedné síti zvolí cestu s nejnižším MED.

Hodnoty MED mohou být k cestám přiřazeny manuálně, nebo se může převzít hodnota metriky používaného IGP protokolu. Tím se optimalizuje rozhodnutí sousedního AS o volbě nejvhodnější vstupní linky, která je nejblíže cílové síti.

Všimněte si, že hodnoty MED se vzájemně srovnávají pouze na linkách vycházejících z téhož AS - za normálních okolností se tedy MED=50 propagovaný z AS400 nebude s MED z AS300 porovnávat a cesta přes AS400 se z důvodu delšího AS_PATH nepoužije.

Všimněte si, že na rozdíl od atributu LOCAL_PREFERENCE se atribut MED šíří přes hranice autonomního systému.

Atribut ORIGIN

Atribut ORIGIN říká, odkud se informace o cestě v BGP vzala. Může nabývat hodnot IGP (cesta pochází z vnitřního směrovacího protokolu), EGP (cesta získána redistribucí z dnes již nepoužívaného externího směrovacího protokolu EGP) nebo INCOMPLETE (původ cesty není znám).

Výběr cest

Pokud má směrovač k dispozici více alternativních cest k nějaké síti, musí vybrat jednu z nich do směrovací tabulky. Postupně se rozhoduje podle jednotlivých kritérií v následujícím pořadí:

vyšší hodnota atributu WEIGHT
vyšší hodnota atributu LOCAL_PREFERENCE
preference cesty generovaná routerem samotným (a pocházející z jeho AS) - získaná např. redistribucí z IGP
kratší AS_PATH (menší počet čísel AS v hodnotě AS_PATH)
preferovanější hodnota atributu ORIGIN (nejpreferovanější IGP, následuje EGP a INCOMPLETE)
nižší hodnota atributu MED
cesty získané z EBGP preferovány před cestami z IBGP
next_hop dostupný přes kratší cestu vnitřkem AS
preferováno nižší ROUTER_ID. ROUTER_ID je identifikátor směrovače, kterým BGP jednotlivé směrovače jednoznačně označuje. Typicky se jako ROUTER_ID bere nejvyšší hodnota IP adresy konfigurovaná na rozhraních směrovače. Router_ID se v rozhodovacím procesu pomocně používá pro definitivní rozhodnutí v případě, že podle žádného "rozumnějšího" kritéria nebylo možné rozhodnout.

Kritérium uvedené s vyšším číslem se uplatní jen v případě, že se podle kritéria s nižším číslem nedalo rozhodnout.

Poznámka: Všimněte si, že délka AS_PATH je až čtvrtým kritériem v pořadí.

Symetrie směrování a vyvažování zátěže

Na závěr si všimněte, že manipulací s atributy můžeme nezávisle ovlivňovat, kterými linkami bude procházet provoz ven z AS a provoz dovnitř AS. Můžeme také dosáhnout jistého vyvažování zátěže, např. použití jedné linky pro provoz k některým sítím a druhé linky k sítím ostatním. Při tom však musíme mít na zřeteli, že z mnoha důvodů je velmi dobré udržet symetrii směrování, tj. provoz do sítí odcházející určitou linkou by se měl touto linkou také vracet. Požadavky na vyvažování zátěže a symetrii směrování bývají často protichůdné, proto je obvykle třeba hledat vhodný kompromis.