KAPITOLA 19. Přepínaný protokol MPLS

KAPITOLA 19 Přepínaný protokol MPLS Témata zkoušky probíraná v této kapitole: Tato kapitola rozebírá následující dílčí ta písemné zkoušky Cisco CCIE Routing and Switching. Podrobnější informace k tům uvedeným v jednotlivých kapitolách a k jejich kontextu v rámci zkoušky najdete v kompletním přehledu zkouškové osnovy, v tabulce I.1 v úvodu knihy. LSR (Label Switching Router) Trasa LSP (Label Switched Path) Rozlišovač cesty (Route Distinguisher) Formát návěští Vytvoření a zrušení návěští Distribuce návěští

656 Část VIII Protokol MPLS Protokol pro přepínání podle návěští MPLS (Multiprotocol Label Switching) zůstává neodmyslitelnou součástí sítí u mnoha poskytovatelů služeb, stále si nicméně získává na oblibě i ve světě podnikových sítí, zejména internetových sítí velkých podniků. V této kapitole se seznámíme se základními principy MPLS, zejména v souvislosti s jednosměrovým zasíláním IP a se sítěmi MPLS VPN. Test dosavadních znalostí Tabulka 19.1 shrnuje hlavní části této kapitoly a k nim uvádí příslušné otázky Testu dosavadních znalostí. Tabulka 19.1: Základní ta hlavní části kapitoly a odpovídající čísla otázek Základní části kapitoly Otázky probírané v této části Skóre Jednosměrové zasílání MPLS IP 1 4 Virtuální privátní sítě MPLS VPN 5 8 Ostatní aplikace protokolu MPLS 9 Celkové skóre Předběžný test dosavadních znalostí si udělejte ještě před započetím studia kapitoly a své výsledky v něm hodnoťte poctivě. Odpovědi na otázky najdete v příloze A. 1. Představte si síť MPLS pro zasílání rámců, v níž je konfigurováno prosté jednosměrové zasílání IP, a ve které jsou zapojeny čtyři směrovače R1, R2, R3 a R4. Mezi směrovači je vedena úplná síť linek, takže jsou všechny vzájemně přímo propojeny. R1 oznamuje ostatním směrovačům v protokolu LDP prefix 1.1.1.0/24, návěští 30. Jaká podmínka musí být splněna, aby mohl návěští prefixu 1.1.1.0/24 oznamovat v protokolu LDP naopak R2 směrovači R1? A. R2 se musí dozvědět cestu IGP do sítě 1.1.1.0/24. B. R2 nebude návěští směrovači R1 oznamovat, a to díky pravidlu rozdělení horizontu. C. R2 může oznámit návěští zpět do R1 jen předtím, než se sám dozví cestu IGP do sítě 1.1.1.0/24. D. R2 se nejprve musí dozvědět cestu do sítě 1.1.1.0/24 z protokolu MP- BGP a teprve poté může návěští oznamovat. 2. Ve stejné síti MPLS pro zasílání rámců, v níž je konfigurováno jednosměrové zasílání IP, přijme směrovač R1 paket s návěštím o hodnotě 55. Které z následujících tvrzení je pravdivé? A. Pro rozhodnutí o směrování porovná směrovač R1 paket s prefixy IPv4 zapsanými v informační bázi FIB. B. Pro rozhodnutí o směrování porovná směrovač R1 paket s prefixy IPv4 zapsanými v bázi LFIB.

Kapitola 19 Přepínaný protokol MPLS 657 C. Pro rozhodnutí o směrování porovná směrovač R1 paket s návěštími MPLS zapsanými v bázi FIB. D. Pro rozhodnutí o směrování porovná směrovač R1 paket s návěštími MPLS zapsanými v bázi LFIB. 3. Zařízení R1, R2 a R3 jsou směrovače MPLS LSR, pracují v protokolu LDP a jsou připojeny ke stejné síti LAN. Žádný z nich neoznamuje transportní IP adresu. Které z následujících tvrzení o činnosti protokolu LDP je pravdivé? A. Každý směrovač LSR rozpoznává zbývající dva směrovače pomocí zpráv LDP Hello, zasílaných na IP adresu 224.0.0.20. B. Každá dvojice směrovačů LSR vytvoří spojení TCP; teprve poté mohou vzájemně oznamovat návěští MPLS. C. Všechny tři směrovače musí pro jakékoli spojení LDP TCP používat IP adresu svého rozhraní sítě LAN. D. Zprávy LDP Hello používají port 646, zatímco spojení TCP používají port 711. 4. V síti MPLS pro zasílání rámců, v níž je konfigurováno prosté jednosměrové zasílání IP, bylo pro veškerý provoz zapnuto šíření (propagace) životnosti MPLS TTL. Které z následujících tvrzení je pravdivé? A. Příkaz traceroute zadaný z vnějšku sítě MPLS vypíše IP adresy směrovačů LSR umístěných uvnitř sítě MPLS. B. Příkaz traceroute zadaný z vnějšku sítě MPLS nevypisuje IP adresy směrovačů LSR umístěných uvnitř sítě MPLS. C. U žádného paketu IP s hlavičkou IP, který vstupuje do sítě MPLS z vnější sítě, se pole IP TTL nebude kopírovat do pole MPLS TTL. D. Ve zprávě ICMP Echo zaslané do sítě MPLS z vnější sítě se pole IP TTL zkopíruje do pole MPLS TTL. 5. Která z následujících položek je rozšířením pole NLRI z protokolu BGP? A. Tabulka VRF. B. Rozlišovač cesty (Route Distinguisher). C. Určení cesty (Route Target). D. Rozšířená komunita BGP (Extended Community). 6. Která z následujících položek určuje, do jaké tabulky VRF zapisuje hranový směrovač PE cesty při příjmu aktualizace IBGP od jiného PE? A. Rozlišovač cesty (Route Distinguisher). B. Určení cesty (Route Target). C. Metrika IGP. D. Délka cesty AS Path. 19 Přepínaný protokol MPLS

658 Část VIII Protokol MPLS 7. Vstupní hranový směrovač PE v internetové síti, kde je konfigurována síť MPLS VPN, přijme paket bez návěští. Co s tímto paketem udělá? A. Zanese (injektuje) do něj jednu hlavičku MPLS. B. Zanese do něj nejméně dvě hlavičky MPLS. C. Zanese do něj přinejmenším návěští sítě VPN, které pak využívají případné další mezilehlé směrovače poskytovatele (P). D. Pomocí informačních bází FIB a LFIB vyhledá všechna povinná návěští a poté je vloží před hlavičku IP. 8. V internetové síti, kde je konfigurována podpora sítí MPLS VPN, pracuje mechanismus PHP. Vstupní hranový směrovač PE přijme paket bez návěští a před dalším odesláním do vlastní sítě MPLS do něj zanese jedno nebo více odpovídajících návěští. Které z následujících tvrzení o tomto paketu je pravdivé? A. Počet návěští MPLS v paketu se změní až v okamžiku, kdy paket dorazí k výstupnímu hranovému směrovači PE, který z něj vyjme celou hlavičku MPLS. B. Počet návěští MPLS v paketu se změní ještě před jeho příchodem k výstupnímu hranovému směrovači PE. C. Díky zapnuté funkci PHP se bude výstupní hranový směrovač PE chovat jiným způsobem než bez PHP. D. Žádná z těchto odpovědí není správná. 9. Která z následujících položek pomáhá definovat, jaké pakety jsou u sítí MPLS VPN ve stejné třídě ekvivalence MPLS FEC? A. Prefix IPv4. B. Bajt ToS. C. Tabulka VRF. D. Tunel TE. Základní ta Mechanismy MPLS definují protokoly, které směrovačům diktují naprosto jiný přístup k zasílání paketů. Namísto zasílání paketů podle jejich cílové IP adresy tak MPLS definuje rozesílání paketů podle návěští (MPLS label). Je zde tedy zrušena pevná vazba všech rozhodnutí o směrování jen na cílové IP adresy a směrovače se mohou rozhodovat podle jiných faktorů, jako je řízení provozu, požadavky na kvalitu služeb QoS nebo požadavky na soukromí mnoha zákazníků připojených ke stejné síti MPLS, i když nadále pracují i s tradičními informacemi zjišťovanými pomocí směrovacích protokolů. Součástí MPLS je široké spektrum aplikací a každá z nich pracuje s jedním nebo více možnými faktory, které mají vliv na rozhodování MPLS o zasílání. Pro účely písemné zkoušky CCIE Routing and Switching se kniha věnuje dvěma takovým aplikacím hned v prvních dvou hlavních částech této kapitoly:

Kapitola 19 Přepínaný protokol MPLS 659 Jednosměrové zasílání MPLS IP. Virtuální privátní sítě MPLS VPN. 19 V závěru kapitoly si pak stručně představíme ostatní aplikace MPLS. A jako obvykle se podívejte na adresu http://www.ciscopress.com/title/9781587201967, kde najdete nejnovější verzi přílohy C; podle ní si pak můžete přečíst případná další ta k MPLS. Poznámka Přepínaný protokol MPLS Do standardů MPLS spadá MPLS pro zasílání rámců (frame-mode) a buňkové MPLS (cellmode), v této kapitole se nicméně zaměříme jen na MPLS pro rámce. Zdánlivě obecné komentáře v textu tak pro buňkové MPLS nemusí platit. Jednosměrové zasílání MPLS IP Sítě MPLS je možné využít pro prosté jednosměrové zasílání IP (MPLS Unicast IP Forwarding); logika MPLS se ovšem při zasílání paketů rozhoduje podle návěští. Při výběru rozhraní, přes která budou pakety odeslány, uvažuje ale MPLS jen cesty zapsané v jednosměrové směrovací tabulce IP, takže konečným výsledkem MPLS je, že pakety putují po úplně stejné cestě jako bez MPLS (s tím, že všechny ostatní faktory jsou nezměněné). Jednosměrové zasílání MPLS IP nepřináší tedy samo o sobě žádnou výraznou výhodu; mnohé ze smysluplnějších aplikací MPLS, jako jsou například sítě MPLS VPN nebo řízení provozu MPLS TE (traffic engineering), je ale využívají jako součást celkového řešení sítě MPLS. Chcete-li proto plně porozumět standardům MPLS v podobě jejich typické implementace, musíte nejprve důkladně proniknout do jejich nejzákladnější podoby, a sice jednosměrového zasílání MPLS IP. Mechanismy MPLS zjišťují pomocí protokolů řídicí roviny (například OSPF a LDP) návěští paketů, dávají je do souvislosti s konkrétními cílovými prefixy a nakonec sestavují správné tabulky pro rozesílání. Pro činnost MPLS je také nutná zásadní změna logiky zasílání v datové rovině (data plane). Tuto část textu zahájíme tudíž právě rozborem datové roviny, která definuje logiku zasílání paketů; poté se podíváme na protokoly řídicí roviny (control plane), zejména na protokol LDP (Label Distribution Protocol) pomocí nich si směrovače MPLS vyměňují návěští pro jednosměrové prefixy IP. Zasílání MPLS IP: datová rovina Jak jsme si řekli, MPLS diktuje naprosto jiný přístup k zasílání paketů. Hostitelé ovšem pakety s návěštím nikdy neuvidí nemohou je ani odesílat, ani přijímat takže v nějakém okamžiku musí nějaký směrovač doplnit k paketu návěští a později, v jiném okamžiku, jiný směrovač jej musí opět odebrat. To jsou směrovače MPLS, které zanášejí (injektují, push ), odebírají (pop) či rozesílají pakety podle jejich návěští, v souladu s logikou zasílání MPLS. Mechanismy MPLS se opírají o podkladovou strukturu a logiku expresního zasílání CEF (Cisco Express Forwarding), i když zmíněnou logiku i datové struktury také významně rozšiřují. Nejprve bude tedy dobré si zopakovat CEF a poté se podíváme na novou datovou strukturu, nazývanou informační báze MPLS, Label Forwarding Information Base (LFIB).

660 Část VIII Protokol MPLS Opakování expresního zasílání CEF Řídicí rovina jednosměrového zasílání IP ve směrovači vytváří s pomocí směrovacích protokolů, statických cest a přímo připojených cest informační bázi RIB (Routing Information Base). Pokud je ve směrovači zapnuté zasílání CEF, jde zpracování v řídicí rovině ještě o krok dále a vytváří bázi CEF FIB (Forwarding Information Base), do níž přidává položku FIB pro každý cílový prefix IP ve směrovací tabulce. Součástí položky FIB jsou veškeré detailní informace nezbytné pro zasílání, tedy směrovač dalšího přeskoku a odchozí rozhraní. Navíc je definována tabulka přilehlosti CEF; v ní je uvedena nová hlavička vrstvy datových spojů (linkové vrstvy), kterou směrovač bude před dalším zasíláním kopírovat na začátek paketů. V datové rovině porovnává směrovač CEF cílovou IP adresu paketu s bází CEF FIB, takže klasickou směrovací tabulku IP úplně ignoruje. Uspořádání báze FIB je přitom v mechanismu CEF optimalizováno, takže vyhledání správné položky trvá směrovači velmi krátkou dobu výsledkem je kratší zpoždění při zasílání a vyšší propustnost směrovače v paketech za sekundu. Pro každý paket směrovač vyhledá odpovídající položku FIB, poté najde položku tabulky sousednosti, na kterou se položka FIB odkazuje, a nakonec podle ní odešle paket. Celý proces je znázorněn na obrázku 19.1. Směrovací tabulka Přímo připojené, statické, ze směrovacích protokolů Nejlepší cesty Prefix 10.3.3.0/24 Další přeskok 192.168.11.1 Odchozí rozhraní S0/0/1 Paket: cíl = 10.3.3.1 Přidává 1 položku FIB na každý prefix CEF FIB Prefix 10.3.3.0/24 Přilehlá IP adresa 192.168.11.1 Detaily k zapouzdření a odeslání Tabulka přilehlosti CEF Další přeskok 192.168.11.1 Odchozí rozhraní S0/0/1 Nová hlavička vrstvy 2 (detaily vynechány) Obrázek 19.1: Směrovací tabulka IP a informační báze CEF FIB bez MPLS Po tomto základním přehledu se v následujícím textu podíváme, jak se celý proces zasílání změní v MPLS s návěštími paketů. Přehled jednosměrového zasílání MPLS IP Mechanismus zasílání MPLS při svém přístupu předpokládá, že hostitelé generují pakety bez návěští MPLS. Poté nějaký směrovač po cestě návěští doplní, další směrovače paket podle návěští směrují a nakonec jiný směrovač návěští odstraní. O existenci MPLS tak v konečném důsledku hostitelské počítače vůbec neví. Pro lepší pochopení celého procesu zasílání se nyní podíváme na obrázek 19.2, kde je v jednotlivých krocích naznačeno zasílání paketu s MPLS.

Kapitola 19 Přepínaný protokol MPLS 661 2 IP 3 22 IP 4 39 IP 5 IP 19 IP CE1 PE1 P1 PE2 LSR LSR LSR CE2 6 IP Přepínaný protokol MPLS 1 A B Obrázek 19.2: Zasílání paketů s MPLS od začátku do konce 10.3.3.3 A nyní si vysvětlíme jednotlivé kroky z obrázku podrobněji: 1. Hostitel A vygeneruje a odešle paket bez návěští s cílovou adresou hostitele 10.3.3.3. 2. CE1, v jehož konfiguraci nejsou zapnuty žádné funkce MPLS, odešle paket bez návěští normálním způsobem, tedy podle cílové IP adresy a opět bez návěští. ( CE1 může, ale nemusí používat CEF.) 3. Paket bez návěští přijde do směrovače PE1, který je již s podporou MPLS a jenž se v rámci zasílání MPLS rozhodne, že do něj doplní nové návěští (s hodnotou 22) a odešle jej dál. 4. Upravený paket s návěštím přijde do mezilehlého směrovače MPLS P1, který vymění návěští za novou hodnotu 39 a odešle paket dál. 5. Paket s novým návěštím přijde do směrovače MPLS PE2, jenž návěští odstraní a odešle jej dál směrem k CE2. 6. CE2 opět MPLS nepodporuje a odesílá paket již zpět bez návěští běžným způsobem podle cílové IP adresy. (Také CE2 může, ale nemusí používat CEF.) Proces znázorněný na obrázku 19.2 je relativně jednoduchý, ale přitom si na něm velmi dobře můžeme zavést několik nových pojmů. Výraz směrovač LSR (Label Switch Router) označuje jakýkoli směrovač, který podporuje návěští MPLS a podle potřeby je také doplňuje na obrázku jsou to například PE1, P1 a PE2. V tabulce 19.2 jsou uvedeny různé varianty pojmu LSR spolu s jejich významem. Tabulka 19.2: Přehled názvosloví směrovačů MPLS LSR Typ LSR Jaké operace tento LSR provádí LSR (Label Switch Router) Libovolný směrovač, jenž k paketům doplňuje návěští, odebírá je, anebo jednoduše zasílá pakety s návěštím. Hranový LSR (E-LSR) Vstupní (ingress) E-LSR LSR na hraně sítě MPLS; to znamená, že tento směrovač zpracovává pakety s návěštím i bez návěští. Pro určitý paket takto označujeme směrovač, který jej přijme bez návěští a poté před hlavičku IP doplní návěští.

662 Část VIII Protokol MPLS Typ LSR Výstupní (egress) E-LSR ATM-LSR ATM E-LSR Jaké operace tento LSR provádí Pro určitý paket takto označujeme směrovač, který jej přijme s návěští, veškerá návěští MPLS z něj odstraní a poté jej dále odesílá bez návěští. LSR, na jehož řídicí rovině běží protokoly MPLS pro vytvoření virtuálních okruhů ATM. Zasílá pakety s návěštím v podobě buněk ATM. Hranový směrovač LSR, který zároveň provádí funkce ATM segmentace a opětovného sestavení SAR (Segmentation and Reassembly). Zasílání MPLS s informační bází FIB a LFIB Při zasílání paketů podle obrázku 19.2 využívají směrovače LSR obě informační báze, CEF FIB a MPLS LFIB. V obou jsou potřebné informace k návěštím a také údaje o odchozím rozhraní a o dalším přeskoku. Obě báze FIB a LFIB se liší v tom, že podle jedné tabulky směrovače odesílají příchozí pakety bez návěští a podle druhé příchozí pakety s návěštími: FIB slouží pro příchozí pakety bez návěští. Systém Cisco IOS hledá shodu cílové IP adresy paketu s nejlepším prefixem ve FIB a podle této položky odešle paket dál. LFIB slouží pro příchozí pakety s návěštími. Zde Cisco IOS porovnává návěští v příchozím paketu se seznamem návěští v LFIB a paket odešle podle takto nalezené položky LFIB. Na obrázku 19.3 si ukážeme, jak tři směrovače LSR z obrázku 19.2 pracují s příslušnými FIB a LFIB. Poznamenejme, že na tomto obrázku je znázorněna FIB jen na směrovači LSR, který odesílá paket podle FIB, zatímco LFIB je u dvou LSR, jež jej zpracovávají podle LFIB, i když jinak jsou FIB i LFIB ve všech třech směrovačích. PE1 CEF FIB Prefix 10.3.3.0/24 Akce Push Odchozí Odchozí návěští rozhraní 22 S0/0/1 P1 LFIB Vstupní návěští 22 Akce Swap Odchozí Odchozí návěští rozhraní 39 S0/0/1 PE2 LFIB Prefix 39 Akce Pop Odchozí Odchozí návěští rozhraní N/A F a0/1 Cíl 10.3.3.3 IP 22 IP 39 IP IP PE1 P1 PE2 S0/0/1 S0/1/0 Fa0/1 Obrázek 19.3: Jak se používají báze CEF FIB a MPLS LFIB pro zasílání paketů Jednotlivé směrovače pracují podle obrázku s bázemi FIB a LFIB takto: PE1: Jakmile směrovač PE1 přijme paket bez návěští, podívá se do báze FIB a vyhledá zde položku, která se shoduje s cílovou adresou paketu 10.3.3.3 tedy konkrétně položku sítě 10.3.3.0/24. Tato položka FIB obsahuje mimo jiné instrukce pro zanesení (push) správného návěští MPLS na začátek paketu. PE: Protože směrovač P1 již přijímá paket s návěštím, podívá se do báze LFIB; najde zde hodnotu návěští 22 a zjistí, že ji má vyměnit (swap) za hodnotu 39.

Kapitola 19 Přepínaný protokol MPLS 663 PE2: Také směrovač PE2 pracuje s bází LFIB, protože přijímá paket s návěštím; v příslušné shodné položce LFIB je uvedena akce odebrání (pop), a proto návěští odejme a odešle směrovači CE2 již paket bez návěští. Všimněte si, že směrovače P1 a PE1 v tomto příkladu skutečně během procesu zasílání nekontrolují cílovou IP adresu paketu. A protože se zasílání o cílovou adresu nijak neopírá, může MPLS provádět zasílání i podle jiných parametrů; například podle sítě VPN, z níž paket pochází, může odesílat v souladu s vyrovnáváním řízeného provozu nebo odesílat provoz po různých linkách podle požadavků QoS. 19 Přepínaný protokol MPLS Hlavička a návěští MPLS Hlavička MPLS je 4bajtová a zapisuje se bezprostředně před hlavičku IP. Mnozí lidé označují celou tuto hlavičku jako návěští, MPLS label, ale skutečné návěští je jen 20bitové pole v hlavičce. Celé hlavičce se někdy také říká vložená hlavička (shim header). Strukturu hlavičky znázorňuje obrázek 19.4 a jednotlivá pole definuje tabulka 19.3. Obrázek 19.4: Hlavička MPLS 20 3 1 8 Label EXP S TTL Tabulka 19.3: Pole hlavičky MPLS Pole Délka (bitů) Význam Návěští (Label) 20 Identifikuje část přepínané trasy LSP. Experimentální (EXP) 3 Používá se pro značkování QoS; dnes se již tedy pole nepoužívá výhradně pro experimentální účely. Dno zásobníku 1 Pokud je tento příznak roven 1, znamená to, že toto návěští (Bottom-of-Stack, S) bezprostředně předchází hlavičce IP. Životnost 8 Má stejný význam jako pole TTL v hlavičce IP. (Time-to-Live, TTL) První dvě ze čtyř polí hlavičky MPLS, tedy pole Label a EXP, by nám již měla být dobře známá. Dvacetibitové pole Label se ve výpisech příkazu show zpravidla zobrazuje jako desítková hodnota. Bity EXP v hlavičce MPLS slouží ke značkování QoS, které můžeme zajistit pomocí mechanismu CB Marking, rozebíraného v kapitole 12. Význam bitu S si lépe vysvětlíme, až se seznámíme s činností sítí MPLS VPN, ale stručně můžeme říci, že pokud pakety obsahují několik hlaviček MPLS, pozná směrovač LSR podle tohoto bitu poslední hlavičku MPLS před hlavičkou IP. A nakonec zde máme pole životnosti TTL, kterému se budeme v následujícím odstavci věnovat podrobněji. Pole MPLS TTL a šíření hodnoty MPLS TTL Životnost, tedy pole TTL v hlavičce IP zajišťuje dvě velmi důležité funkce: jednak je mechanismem pro rozpoznání paketů zasílaných ve smyčce a jednak je metodou, pomocí níž může příkaz traceroute zjistit IP adresu každého směrovače v konkrétní cestě ze zdroje do cíle. Pole TTL v hlavičce MPLS slouží ke stejným účelům koneckonců, při výchozích hodnotách

664 Část VIII Protokol MPLS všech parametrů nemá přítomnost či nepřítomnost směrovačů MPLS LSR v síti žádný vliv na konečné výsledky žádného z popsaných procesů souvisejících s hodnotou TTL. Mechanismus MPLS potřebuje pole TTL z jediného důvodu, a sice aby směrovače LSR mohly při zasílání paketů IP úplně ignorovat zapouzdřenou hlavičku IP. e LSR tak při průchodu paketu sítí MPLS dekrementují pole MPLS TTL, nikoli pole IP TTL. Platí-li výchozí hodnoty parametrů, spolupracují všechny vstupní směrovače E-LSR, ostatní běžné LSR a výstupní E-LSR takto: Vstupní E-LSR: Jakmile vstupní směrovač E-LSR dekrementuje pole IP TTL, zapíše do paketu bez návěští nové návěští a původní pole IP TTL zkopíruje do pole TTL v hlavičce MPLS. Ostatní E-LSR: Pokud směrovač LSR vymění hodnotu návěští, dekrementuje pole TTL v hlavičce MPLS a pole TTL v hlavičce IP vždy ignoruje. Výstupní E-LSR: Paket se dostane do výstupního směrovače E-LSR; ten dekrementuje pole MPLS TTL, odstraní závěrečnou hlavičku MPLS a nakonec zkopíruje hodnotu MPLS TTL do pole TTL hlavičky IP. Podívejme se na obrázek 19.5, kde do směrovače PE1 přichází paket bez návěští s hodnotou IP TTL 4. Bubliny v obrázku znázorňují nejdůležitější operace směrovačů LSR ve tří hlavních rolích, popsaných v předcházejícím seznamu. Dekrementovat IP TTL na 3 Zapsat novou hlavičku MPLS Zkopírovat TTL do nového pole MPLS Ignorovat pole IP TTL (stále je 3) Dekrementovat pole MPLS TTL na 2 Dekrementovat pole MPLS TTL na 1 Odebrat hlavičku MPLS Zkopírovat pole MPLS TTL do IP TTL IP TTL 3 IP TTL 3 1 IP TTL 4 2 MPLS TTL 3 3 MPLS TTL 2 4 IP TTL 1 CE1 PE1 P1 PE2 CE2 Vstupní E-LSR LSR Výstupní E-LSR Obrázek 19.5: Příklad šíření hodnoty MPLS TTL Výrazem propagace neboli šíření hodnoty MPLS TTL (propagation) rozumíme přitom celou logiku podle obrázku. Fakticky tak směrovače MPLS šíří po celé síti MPLS jednu stejnou hodnotu TTL a to vždy stejnou hodnotu TTL, jaká by se přenášela bez MPLS. Jak vás nyní jistě napadne, u paketu pohybujícího se ve smyčce se musí nakonec snížit TTL na 0 a musí být tedy zahozen. Navíc, příkaz traceroute by v takovém případě dostával od všech směrovačů na obrázku zprávy ICMP Time Exceeded, směrovače LSR nevyjímaje. Mnozí síťoví konstruktéři ale nechtějí, aby hostitelé vně samotné sítě MPLS mohli příkazem traceroute nahlížet dovnitř. Poskytovatelé služeb zpravidla pomocí sítí MPLS zajišťují služby sítí WAN na vrstvě 3 a jejich zákazníci jsou umístěni právě vně sítě MPLS. Jestliže takovýto zákazník bude moci zjistit IP adresy směrovačů MPLS LSR, bude to pro zákazníka jednak zbytečné (protože ten chce vidět jen svoje směrovače), jednak se tím může vytvořit bezpečnostní hrozba pro poskytovatele.

Kapitola 19 Přepínaný protokol MPLS 665 V konfiguraci směrovačů Cisco je možné šíření hodnot MPLS TTL zakázat. V takovém případě zapíše vstupní směrovač E-LSR do pole TTL hlavičky MPLS hodnotu 255 a výstupní E-LSR ponechává původní pole TTL hlavičky IP nezměněné. Celá síť MPLS se tak z pohledu hodnoty TTL jeví jako jediný přeskok mezi směrovači a na jednotlivé směrovače uvnitř sítě MPLS zákazník po zadání příkazu traceroute neuvidí. Na obrázku 19.6 vidíme stejný příklad jako v obrázku 19.5, tentokrát ale s vypnutým šířením hodnot MPLS TTL. Dekrementovat IP TTL na 3 Zapsat novou hlavičku MPLS s hodnotou TTL = 255 Ignorovat pole IP TTL (stále je 3) Dekrementovat pole MPLS TTL na 254 Dekrementovat pole MPLS TTL na 253 Odebrat hlavičku MPLS 19 Přepínaný protokol MPLS IP TTL 3 IP TTL 3 1 IP TTL 4 2 MPLS TTL 255 3 MPLS TTL 254 4 IP TTL 3 CE1 PE1 P1 PE2 CE2 Vstupní E-LSR LSR Výstupní E-LSR Obrázek 19.6: Příklad s vypnutým šířením hodnot MPLS TTL Zařízení Cisco podporují možnost zakázat šíření hodnot MPLS TTL pro dvě třídy paketů. Většina poskytovatelů služeb MPLS totiž potřebuje zakázat šíření TTL u paketů odeslaných zákazníkem, ale zároveň potřebuje povolit šíření TTL u paketů odeslaných jejich vlastními směrovači. Vraťme se nyní k obrázku 19.5 a uvažujme, že se síťový inženýr u poskytovatele přihlásí ke směrovači PE1, aby zde zadal příkaz traceroute. V konfiguraci PE1 bude zapnuto šíření TTL pro lokálně vytvořené pakety, takže příkazem traceroute zadaným z PE1 se správně vypíší všechny směrovače v síťovém prostoru MPLS. Zároveň bude ale v PE1 vypnuto šíření TTL pro zasílané pakety, tedy pro pakety přijaté od zákazníků, aby tak zákazníci neměli možnost zjistit IP adresy směrovačů uvnitř sítě MPLS. (Příslušný příkaz je no mpls ttl-propagation [local forwarded].) Poznámka V našem příkladu je sice šíření hodnoty TTL vypnuté ve směrovači PE1, ale pro konzistentní výsledky šíření TTL by mělo být vypnuté také ve všech směrovačích příslušné domény MPLS. Zasílání MPLS IP: řídicí rovina Má-li s informačními bázemi spolupracovat také čisté směrování IP, musí směrovače nejprve pomocí protokolů řídicí roviny (jako jsou směrovací protokoly) naplnit směrovací tabulku IP a poté podle ní naplnit bázi CEF FIB. Podobně se o protokoly řídicí roviny opírá i zasílání MPLS: zjišťuje z nich, která návěští MPLS použít pro cestu do každého z prefixů IP, a poté správnými návěštími naplňuje báze FIB a LFIB. Mechanismus MPLS podporuje celou řadu různých protokolů řídicí roviny. Konkrétní řídicí protokol budeme ale nejčastěji volit podle provozované aplikace MPLS, nikoli podle detailního porovnávání jejich funkcí. Sítě MPLS VPN pracují tak například se dvěma protokoly řídicí roviny, a sice LDP a víceprotokolový BGP neboli MP-BGP.

666 Část VIII Protokol MPLS Zatímco u některých aplikací MPLS je možné uplatnit i několik různých protokolů řídicí roviny, jednosměrové zasílání MPLS IP používá jen protokol IGP a jeden speciální protokol řídicí roviny MPLS, a sice LDP. A protože i tato část textu je zaměřena na jednosměrové zasílání IP, vysvětlíme si distribuci návěští protokolem LDP. Poznámka Nejstarší verze protokolu LDP, ještě před přijetím standardu, se nazývala Tag Distribution Protocol (TDP); namísto výrazu přepínání podle návěští (label switching) se totiž běžně říkalo přepínání podle značek (tag switching). Základy protokolu MPLS LDP U jednosměrového směrování IP protokol LDP jednoduše oznamuje návěští ke každému prefixu, uvedenému ve směrovací tabulce IP. K tomu směrovače LSR zasílají protokolem LDP sousedům zprávy, v nichž uvádějí prefixy IP a k nim odpovídající návěští. Tím, že směrovač LSR oznámí prefix IP a návěští, v podstatě sousedovi říká: Pokud chceš odesílat pakety do tohoto prefixu IP, odešli je ke mně s návěštím MPLS, uvedeným v této aktualizaci LDP. Oznámení LDP se spouští v okamžiku, kdy se v jednosměrové směrovací tabulce IP objeví nová cesta IP. Po zjištění nové cesty jí směrovač LSR přiřadí (alokuje) návěští je to takzvané lokální návěští, které na tomto jednom směrovači reprezentuje prefix IP, právě zapsaný do směrovací tabulky. Všechno si vysvětlíme na příkladu. Na obrázku 19.7 je mírně rozšířená varianta sítě MPLS ze začátku této kapitoly; vidíme zde základní proces, který nastupuje, jakmile se směrovač LSR (PE2) dozví novou cestu (10.3.3.0/24) a spustí proces oznámení nového lokálního návěští (39) v protokolu LDP. P1 Hmmm, já už návěští 39 nepoužívám... oznámím tedy návěští 39 u prefixu 10.3.3.0/24 LDP: 10.3.3.0/24, 39 CE1 PE1 PE2 CE2 3 2 1 Aktualizace IGP: cesta do prefixu 10.3.3.0/24 P2 Obrázek 19.7: Proces LDP spuštěný novou jednosměrovou cestou IP 3 LDP: 10.3.3.0/24, 39 B 10.3.3.0/24 Ve směrovači PE2 probíhá následující jednoduchý proces, naznačený pomocí tří kroků: 1. Nejprve se směrovač PE2 dozví novou jednosměrovou cestu IP, kterou zapíše do směrovací tabulky IP.

Kapitola 19 Přepínaný protokol MPLS 667 2. Poté PE2 alokuje nové lokální návěští; tím je návěští, jež tento směrovač LSR momentálně neoznamuje. 3. Dále PE2 oznámí protokolem LDP všem sousedům LDP mapování (přiřazení) mezi prefixem IP a návěštím. Samotný proces je sice jednoduchý, je zde ale důležité poznamenat, že směrovač PE2 musí být připraven zpracovávat příchozí pakety, v nichž bude hodnota nového lokálního návěští. Na obrázku 19.7 tak například musí být PE2 připraven k zasílání přijatých paketů s návěštím 39; tyto pakety odešle PE2 do stejného dalšího přeskoku a přes stejné odchozí rozhraní, jaké zde zjistil z aktualizace IGP v kroku 1. Celý proces na obrázku 19.7 nám ale ukazuje jen oznámení jednoho segmentu celé přepínané trasy s návěštími (label switched path, LSP). Trasa MPLS LSP je přitom sjednocení množin návěští, pomocí nichž je možné pakety korektně zaslat do cíle. Na obrázcích 19.2 a 19.3 jsme tak viděli krátkou trasu LSP s hodnotami návěští 22 a 39, přes kterou se odesílaly pakety do podsítě 10.3.3.0/24. Obrázek 19.7 ukazuje tedy oznámení jen jedné části neboli segmentu trasy LSP. 19 Přepínaný protokol MPLS Poznámka Trasy LSP jsou vždy jednosměrné. Hmmm, já už návěští 22 nepoužívám... oznámím tedy návěští 22 u prefixu 10.3.3.0/24 5 Aktualizace LDP v kroku 5: LDP: 10.3.3.0/24, 22 5 P1 Aktualizace IGP: cesta do 10.3.3.0/24 (4) 4 S0/1/1 5 5 6 S0/1/1 6 PE1 PE2 CE2 6 LDP: 10.3.3.0/24, 86 P2 Aktualizace LDP v kroku 6: 4 Aktualizace IGP: cesta do 10.3.3.0/24 B 10.3.3.0/24 Hmmm, já už návěští 86 nepoužívám... oznámím tedy návěští 86 u prefixu 10.3.3.0/24 Obrázek 19.8: Dokončení procesu oznamování celé trasy LSP

668 Část VIII Protokol MPLS e v síťovém prostoru MPLS musí nejprve z vhodného směrovacího protokolu IP zjistit cesty IP a teprve poté mohou spustit proces oznamování návěští v LDP. U jednosměrového směrování MPLS IP zjistíme zpravidla veškeré cesty IP prostřednictvím protokolu IGP a poté spustíme proces oznamování příslušných návěští. Podívejme se na obrázek 19.8, který začíná tam, kde obrázek 19.7 skončil: směrovač PE2 zde oznamuje cestu do prefixu 10.3.3.0/24 pomocí protokolu EIGRP, takže ostatní směrovače pak protokolem LDP začnou oznamovat návěští. Na obrázku jsou vyznačeny následující kroky (číslování pokračuje z obrázku 19.7): 4. PE2 v protokolu EIGRP oznámí cestu do prefixu 10.3.3.0/24 směrovačům P1 a P2. 5. V reakci na nově zjištěnou cestu alokuje P1 nové lokální návěští (22) a pomocí protokolu LDP oznámí mapování prefixu 10.3.3.0/24 na návěští 22. Všimněte si, že P1 oznamuje toto návěští všem sousedům. 6. Také směrovač P2 reaguje na nově zjištěnou cestu alokací nového návěští, a to 86, a opět protokolem LDP oznámí mapování prefixu 10.3.3.0/24 na návěští (86). I směrovač P2 oznámí toto návěští všem svým sousedům. Tento stejný proces proběhne na každém ze směrovačů LSR a pro každou cestu ve směrovací tabulce LSR. Pokaždé, kdy se LSR dozví nějakou novou cestu, alokuje tedy nové lokální návěští a poté oznámí mapování prefixu na návěští všem svým sousedům i když je třeba zřejmé, že oznámení návěští nebude k ničemu dobré. Na obrázku 19.8 tak například směrovač P2 oznamuje návěští pro prefix 10.3.3.0/24 i zpětně směrovači PE2; to sice nemá žádný velký smysl, ale přesně takto směrovače MPLS LSR v síti pro zasílání rámců fungují. Jakmile se protokolem IGP o daném prefixu dozví všechny směrovače, a jakmile protokol LDP oznámí mapování návěští na prefixy (neboli vazby) všem ostatním sousedním směrovačům LSR, má již každý LSR dostatek informací pro přepínání paketů s návěštími ze vstupního E-LSR do výstupního E-LSR. Stejný proces datové roviny z obrázků 19.2 a 19.3 tak například může proběhnout, jestliže směrovač PE1 přijme paket bez návěští s cílovou adresou v síti 10.3.3.0/24. Návěští oznámená na obrázcích 19.7 a 19.8 dokonce záměrně odpovídají původním obrázkům datové roviny MPLS (tedy 19.2 a 19.3). Abychom ale pochopili úplně celý proces, musíme si ještě vysvětlit, co přesně se děje uvnitř jednotlivého směrovače, zejména v datové struktuře nazývané MPLS LIB (Label Information Base). Vstup informací do FIB a LFIB z informační báze MPLS LIB e LSR si ukládají návěští a s nimi spojené informace do zvláštní datové struktury, nazývané LIB (Label Information Base, informační báze návěští). V ní jsou fakticky uložena všechna návěští a další informace, které mohou sloužit k zasílání paketů. Každý směrovač LSR musí ale zvolit nejlepší návěští a odchozí rozhraní, které skutečně použije, a poté tyto informace zapsat do bází FIB a LFIB. To znamená, že FIB a LFIB obsahují jen návěští pro aktuálně použitý nejlepší segment trasy LSP, zatímco LIB obsahuje veškerá návěští, jež daný LSR zná, ať už se návěští používá pro zasílání nebo ne. Při rozhodování o tom, které návěští bude nejlépe použít, se směrovače LSR opírají o rozhodnutí směrovacího protokolu o nejlepší cestě. Díky tomu mohou LSR využít funkce směrova-

Kapitola 19 Přepínaný protokol MPLS 669 cího protokolu pro zabránění vzniku smyček a mohou také reagovat na cesty, nově vybrané při konvergenci. Stručně můžeme rozhodnutí směrovače LSR popsat takto: Pro každou cestu ve směrovací tabulce najdi odpovídající informaci o návěští v LIB, a to podle odchozího rozhraní a směrovače dalšího přeskoku uvedeného v cestě. Nalezenou informaci o návěští zapiš do bází FIB a LFIB. Abychom lépe pochopili, jak vlastně směrovač LSR zapisuje informace do bází FIB a LFIB, budeme pokračovat stejným příkladem jako v předchozí části kapitoly. Podíváme se na výsledky několika příkazů show; nejprve si ale řekneme něco podrobnějšího k ukázkové síti a její konfiguraci. Na obrázku 19.9 opakujeme stejnou síť z předchozích obrázků kapitoly, navíc jsou tu ovšem doplněny IP adresy a názvy rozhraní. Je zde také naznačeno, na kterých rozhraních je MPLS zapnuto (čárkované spojnice) a na jakých ne (plné čáry). 19 Přepínaný protokol MPLS LID 2.2.2.2 Všechny IP adresy začínají prefixem 192.168, není-li uvedeno jinak. S0/1/1 S0/1/0 P1 12.2 23.2 S0/1/1 24.2 LID 1.1.1.1 LID 3.3.3.3 S0/1/1 S0/1/0 12.1 23.3 15.5 15.1 36.3 36.6 14.1 CE1 PE1 34.3 PE2 CE2 F a0/1 F a0/1 S0/1/1 S0/1/1 10.3.3.1 24.4 14.4 S0/1/0 S0/1/1 34.4 S0/1/1 P2 LID 4.4.4.4 B 10.3.3.10/24 Legenda: Linky se zapnutým MPLS Linky bez zapnutého MPLS Obrázek 19.9: Ukázková síť pro výklad informačních bází LIB, FIB a LFIB Konfigurace jednosměrového směrování MPLS IP je poměrně jednoduchá. V našem případě běží ve všech šesti směrovačích protokol EIGRP a oznamuje všechny podsítě. Čtyři směrovače LSR mají zapnuté MPLS, a to jednak globálně, jednak na linkách naznačených čárkovaně. Pokud ve směrovači LSR chceme využívat MPLS pro prosté jednosměrové zasílání IP, jak jsme zatím v této kapitole hovořili, stačí jednoduše zapnout zasílání CEF, globálně zapnout MPLS a poté ještě zapnout MPLS nad každým požadovaným rozhraním. Navíc, protože systém IOS používá jako výchozí namísto protokolu LDP protokol TDP, musíme v této konfiguraci potlačit výchozí nastavení a zapnout LDP. Vzorovou obecnou konfiguraci si prohlédneme v příkladu 19.1. Příklad 19.1: Konfigurace MPLS na směrovači LSR pro podporu jednosměrového zasílání IP! První tři příkazy zapínají globálně CEF a MPLS, a namísto TDP! zapínají protokol LDP ip cef mpls ip mpls label protocol ldp!! Další dva řádky je nutné opakovat pro každé rozhraní se zapnutým MPLS

670 Část VIII Protokol MPLS interface type x/y/z mpls ip! Zde je normální konfigurace protokolu EIGRP tu je nutno provést pro všechna rozhraní router eigrp 1 network... Nyní se podíváme, jak směrovače LSR naplňují báze FIB a LFIB. Opět budeme uvažovat podsíť 10.3.3.0/24 a podíváme se na síť MPLS z pohledu směrovače PE1. Ten zjistil cestu do uvedené podsítě z protokolu 10.3.3.0/24; pomocí protokolu LDP zjistil také dvě návěští, která může použít pro zasílání paketů s cílem v podsíti 10.3.3.0/24 jedno návěští zjistil od sousedního směrovače LSR P1 a druhé od sousedního LSR P2. Detailně jsou tyto informace uvedeny v příkladu 19.2; všimněte si, že se návěští shodují s obrázky a příklady v dosavadním textu kapitoly. Příklad 19.2: Báze LIB a směrovací tabulka IP ve směrovači PE1 PE1# show ip route 10.0.0.0 Routing entry for 10.0.0.0/24, 1 known subnets Redistributing via eigrp 1 D 10.3.3.0 [90/2812416] via 192.168.12.2, 00:44:16, Serial0/0/1 PE1# show mpls ldp bindings 10.3.3.0 24 tib entry: 10.3.3.0/24, rev 28 local binding: tag: 24 remote binding: tsr: 2.2.2.2:0, tag: 22 remote binding: tsr: 4.4.4.4:0, tag: 86 Ve výpisu z příkladu 19.2 je několik nepříliš zajímavých informací a také několik věcí, u kterých se zastavíme. Za prvé, v příkazu show ip route nejsou uvedeny žádné nové nebo různé informace pro síť MPLS (oproti konfiguraci bez MPLS), je ale dobré si všimnout, že nejlepší cesta ze směrovače PE1 do prefixu 10.3.3.0/24 vede přes P1. Příkazem show mpls ldp bindings 10.3.3.0 24 vypíšeme položky LIB pro prefix 10.3.3.0/24. Všimněte si, že jsou zde uvedeny dvě vzdálené vazby jedna od směrovače P1 (LDP ID 2.2.2.2) a jedna od směrovače P2 (LDP ID 4.4.4.4). Tento příkaz vypisuje zároveň lokální vazbu, v níž je uvedeno návěští, které PE1 alokoval a oznámil svým sousedům. Poznámka Výraz vzdálená vazba označuje vazbu návěští a prefixu, zjištěnou protokolem LDP od některého ze sousedů LDP. Z příkladu 19.2 vidíme, že směrovač PE1 bude při zasílání paketů do podsítě 10.3.3.0/24 používat návěští s hodnotou 22 a odchozí rozhraní S0/0/1. Jak přesně dospěje PE1 k tomuto závěru, to naznačuje schéma na obrázku 19.10. V obrázku jsou znázorněny následující kroky: 1. Ve směrovací tabulce je u podsítě 10.3.3.0/24 uvedena IP adresa dalšího přeskoku 192.168.12.2. PE1 porovná tuto informaci o dalším přeskoku se seznamem adres IP rozhraní jednotlivých sousedů LDP a vyhledá takového souseda LDP, jehož IP adresa je rovna 192.168.12.2. 2. Nyní ve výsledcích stejného příkazu show mpls Idp neighbor vidíme identifikátor LDP ID (LID) tohoto souseda, konkrétně 2.2.2.2.

Kapitola 19 Přepínaný protokol MPLS 671 PE1#show mpls Idp bindings 10.3.3.0 24 tib entry: 10.3.3.0/24, rev 28 local binding: tag: 24 remote binding: tsr: 2.2.2.2:0, tag: 22 remote binding: tsr: 4.4.4.4:0, tag: 86 PE1#show ip route include 10.3.3.0 D 10.3.3.0 [90/2812416] via 192.168.12.2, 00:04:33, Serial0/0/1 3 1 19 Přepínaný protokol MPLS PE1#show mpls Idp neighbor 4 Peer LDP Ident: 2.2.2.2:0; Local LDP Ident 1.1.1.1:0 TCP connection: 2.2.2.2.60635-1.1.1.1.646 State: Oper; Msgs sent/rcvd: 75/76; Downstream Up time: 00;35;20 LDP discovery sources: Serial0/0/1, Src IP addr: 192.168.12.2 2 Addresses bound to peer LDP Ident: 192.168.12.2 2.2.2.2 192.168.1.112 192.168.24.2 192.168.23.2 Peer LDP Ident: 4.4.4.4:0; Local LDP Ident 1.1.1.1:0 TCP connection: 4.4.4.4.11711-1.1.1.1.646 State: Oper; Msgs sent/rcvd: 26/30; Downstream Up time: 00:06:17 LDP discovery sources: Serial0/1/1, Src IP addr: 192.168.14.4 Addresses bound to peer LDP Ident: 192.168.14.4 4.4.4.4 192.168.24.4 192.168.34.4 Obrázek 19.10: Proces, v němž směrovač PE1 stanoví návěští odchozího paketu 3. PE1 si všimne, že pro jeden stejný prefix 10.3.3.0/24 obsahuje LIB jedno lokální návěští a dvě vzdálená návěští. 4. Z těchto známých návěští pro prefix 10.3.3.0/24 bylo jedno zjištěno od souseda s LID 2.2.2.2, a to s návěštím neboli značkou 22. Poznámka Mnohé z příkazů systému IOS používá dosud staré názvosloví proto jsou labels, tedy návěští, ve výpisech označena jako tags, tedy značky, a proto jsou také směrovače LSR (Label Switch Routers) označeny na obrázku 19.10 jako TSR (Tag Switch Routers). Po dokončení těchto kroků PE ví, že při zasílání paketů do podsítě 10.3.3.0/24 má používat odchozí rozhraní S0/0/1 a návěští 22. Příklady položek FIB a LFIB Jak jsme si již v kapitole řekli, při vlastním procesu zasílání paketu se již nepoužívá klasická směrovací tabulka IP (které se také říká Routing Information Base, RIB) ani báze LIB; pro zasílání paketů, jež přišly bez návěští, se používá báze FIB a pro zasílání paketů již s návěštím

672 Část VIII Protokol MPLS se používá LFIB. V této části textu kapitoly se podíváme na výpisy z několika příkazů show a dáme je do souvislostí s konceptuálním pohledem na datové struktury FIB a LFIB, které byly znázorněny na obrázku 19.3. Opět se zaměříme na směrovač PE1. Ten jednoduše do báze FIB přidá informaci, podle níž má k paketům doplnit hlavičku MPLS s návěštím o hodnotě 22. Kromě toho si PE1 naplňuje bázi LFIB; do té rovněž zapíše položku k podsíti 10.3.3.0/24, a to se stejným návěštím 22 a odchozím rozhraním S0/0/1. Obsah obou tabulek vypíšeme v příkladu 19.3. Příklad 19.3: Položky FIB a LFIB pro podsíť 10.3.3.0/24 ve směrovači PE1! Tento následující příkaz zobrazí položku FIB, v níž je uvedeno lokální návěští! 24, přiřazené značky neboli návěští a odchozí rozhraní. PE1# show ip cef 10.3.3.0 10.3.3.0/24, version 65, epoch 0, cached adjacency to Serial0/0/1 0 packets, 0 bytes tag information set local tag: 24 fast tag rewrite with Se0/0/1, point2point, tags imposed: {22} via 192.168.12.2, Serial0/0/1, 0 dependencies next hop 192.168.12.2, Serial0/0/1 valid cached adjacency tag rewrite with Se0/0/1, point2point, tags imposed: {22}! Druhým příkazem vypíšeme položku LFIB pro podsí 10.3.3.0/24, kde jsou uvedeny! stejné základní informace lokální návěští, odchozí návěští a odchozí rozhraní. PE1# show mpls forwarding-table 10.3.3.0 24 Local Outgoing Prefix Bytes tag Outgoing Next Hop tag tag or VC or Tunnel Id switched interface 24 22 10.3.3.0/24 0 Se0/0/1 point2point Vrátíme-li se nyní k datové rovině obrázku 19.3, zde směrovač PE1 přijal paket bez návěští a odeslal jej do P1 s návěštím 22. Stejné logice odpovídají i informace v horní části příkladu 19.3 s výpisem báze FIB: vidíme, že PE1 bude zapisovat značku (návěští) s hodnotou 22. Dále se v příkladu 19.4 podíváme na LFIB ve směrovači P1. Jak bylo znázorněno na obrázku 19.3, P1 vymění příchozí návěští 22 za odchozí návěští 39. Pro doplnění souvislostí jsou v příkladu uvedeny také položky LIB pro prefix 10.3.3.0/24. Příklad 19.4: Položky LFIB a LIB pro prefix 10.3.3.0/24 ve směrovači P1 P1# show mpls forwarding-table 10.3.3.0 24 Local Outgoing Prefix Bytes tag Outgoing Next Hop tag tag or VC or Tunnel Id switched interface 22 39 10.3.3.0/24 0 Se0/1/0 point2point P1# show mpls ldp bindings 10.3.3.0 24 tib entry: 10.3.3.0/24, rev 30 local binding: tag: 22 remote binding: tsr: 1.1.1.1:0, tag: 24 remote binding: tsr: 4.4.4.4:0, tag: 86 remote binding: tsr: 3.3.3.3:0, tag: 39 Ve zvýrazněném řádku výsledků příkazu show mpls forwarding-table vidíme příchozí návěští (to je zde 22) a odchozí návěští (39). Všimněte si, že příchozí návěští je uvedeno pod záhlavím Local tag ; to znamená, že uvedenou značku neboli návěští alokoval lokálně tento směrovač (P1) a oznámil je ostatním směrovačům pomocí protokolu LDP, jak bylo vidět na obrázku 19.8. Návěští 22 původně alokoval a oznámil právě P1 a sousedním směrovačům tím

Kapitola 19 Přepínaný protokol MPLS 673 řekl, aby pakety s cílem 10.3.3.0/24 zasílaly do P1 s návěštím 22. Nyní P1 ví, že pokud přijme paket s návěštím 22, musí je vyměnit a přes rozhraní S0/1/0 již paket odeslat s návěštím 39. Položky LIB v příkladu 19.4 také podtrhují princip, podle něhož si směrovače MPLS LSR (v síti pro zasílání rámců) uchovávají v bázích LIB všechna zjištěná návěští, ale v bázi LFIB již jen ta návěští, která momentálně skutečně používají. V LIB je tak uvedeno lokální návěští směrovače P1 (22) a tři vzdálená návěští, která se P1 dozvěděl od tří svých sousedů LDP. Při vytvoření položky LFIB postupoval P1 podle stejné logiky jako na obrázku 19.10: dal tedy informace ve směrovací tabulce a v LIB do souladu a pro zasílání paketů do cíle 10.3.3.0/24 zvolil hodnotu návěští 39 a odchozí rozhraní S0/1/0. Jako příklad operace odebrání návěští (pop) uvážíme nyní bázi LFIB ve směrovači PE2, zachycenou v příkladu 19.5. Jakmile PE2 obdrží paket s návěštím od směrovače P1 (má návěští 39), pokusí se jej odeslat dále podle své LFIB. Při naplňování LFIB ovšem PE2 snadno pochopí, že musí návěští odstranit a paket již bez návěští odeslat přes rozhraní Fa0/1. Důvody jsou mimo jiné takové, že v PE2 není nad rozhraním Fa0/1 zapnuté MPLS a že se PE2 od směrovače CE2 nedozvěděl žádná návěští. V příkladu 19.5 je skutečně na místě odchozího návěští (značky) uveden výraz untagged, bez značky. 19 Přepínaný protokol MPLS Příklad 19.5: Položky FIB a LFIB pro cíl 10.3.3.0/24 ve směrovači PE2 PE2# show mpls forwarding-table 10.3.3.0 24 Local Outgoing Prefix Bytes tag Outgoing Next Hop tag tag or VC or Tunnel Id switched interface 39 Untagged 10.3.3.0/24 0 Fa0/1 192.168.36.6 Poznamenejme, že v příkladu 19.5 jsme sice vypisovali jen položky báze LFIB, jinak si ale každý směrovač LSR sestavuje pro každý prefix jak odpovídající položku LFIB, tak i FIB, protože může kdykoli přijmout paket bez návěští i s návěštím. Přehled vlastností protokolu LDP Abychom mohli s klidným svědomím dokončit výklad jednosměrového zasílání MPLS IP, měli bychom si ještě říct něco málo o samotném protokolu LDP. Zatím jsme si v této kapitole ukázali, co LDP dělá, ale neřekli jsme si příliš, jak to dělá. Nyní se tedy vrátíme k hlavním myšlenkám protokolu a poukážeme na zbývající vlastnosti. Protokol LDP využívá při své činnosti kontaktní zprávy Hello, pomocí nichž rozpoznává sousedy a stanovuje, na jakou IP adresu má nové spojení TCP vést. Tyto zprávy Hello odesílá LDP vícesměrově na IP adresu 224.0.0.2, přičemž pro LDP platí číslo portu UDP 646 (pro TDP se používá UDP port 711). Ve zprávě Hello je vždy uveden identifikátor LDP ID (LID) příslušného směrovače LSR, který je tvořen 32bitovým číslem v tečkové desítkové notaci a 2bajtovým číslem prostoru návěští (label space number). (U sítí MPLS pro zasílání rámců je číslo prostoru návěští rovno 0.) LSR může ve zprávě Hello uvádět také transportní adresu, což je IP adresa, kterou bude LSR používat pro veškerá spojení LDP TCP. Pokud směrovač transportní adresu neuvádí, použijí ostatní směrovače v roli IP adresy pro spojení TCP první 4 bajty z LDP ID. Jakmile se sousedé vzájemně rozpoznají prostřednictvím zpráv LDP Hello, navážou mezi sebou spojení TCP, opět na portu 646 (v TDP je to 711). Protože spojení TCP pracuje s jednosměrovými adresami tedy buďto s transportní adresou oznámenou sousedem, nebo

674 Část VIII Protokol MPLS s adresou v LID musí být tyto adresy dosažitelné podle směrovací tabulky IP. Po navázání spojení TCP oznámí každý směrovač všechny svoje vazby lokálních návěští a prefixů. e Cisco volí IP adresu v LDP ID stejně jako ID směrovače OSPF. Protokol LDP volí použitou IP adresu jako součást svého LID podle přesně stejné logiky jako OSPF, jak je spolu s dalšími detaily uvedeno v tabulce 19.4. Tabulka 19.4: Přehled vlastností protokolu LDP Vlastnost LDP Transportní protokoly Čísla portů Cílová adresa zpráv Hello 224.0.0.2 Kdo iniciuje spojení TCP Kterou adresu používá spojení TCP LDP ID je stanoven podle těchto pravidel, v pořadí priority Implementace LDP UDP (Hello), TCP (aktualizace) 646 (LDP), 711 (TDP) Nejvyšší LDP ID. Transportní IP adresu (pokud je konfigurována), případně LDP ID, pokud transportní adresa chybí. Konfigurace. Nejvyšší IP adresa na zpětnovazební rozhraní ve stavu up/up při spouštění protokolu LDP. Nejvyšší IP adresa na jiné než zpětnovazební rozhraní ve stavu up/up při spouštění protokolu LDP. Tím se výklad jednosměrového zasílání MPLS IP v této kapitole dostává ke konci. Dále se v textu zaměříme na jeden z velmi oblíbených typů uplatnění MPLS, který shodou okolností také využívá jednosměrové zasílání IP: jsou to virtuální privátní sítě MPLS VPN. Virtuální privátní sítě MPLS VPN Jednou z nejrozšířenějších aplikací sítí MPLS jsou virtuální privátní sítě MPLS VPN, jejichž prostřednictvím může poskytovatel služeb nebo i velký podnik poskytovat služby sítí VPN na vrstvě 3. Moderní službou MPLS VPN poskytovatelé služeb (SP) zejména často nahrazují starší služby sítí WAN na vrstvě 2, jako jsou Frame Relay a ATM. Se službami MPLS VPN má poskytovatel možnost nabízet svým zákazníkům mnohem širší doplňkové služby, protože sítě MPLS VPN znají adresy vrstvy 3 v sítích zákazníků. Navíc, i v MPLS VPN je možné zajišťovat soukromí, jaké je běžné ve službách WAN na vrstvě 2. Sítě MPLS VPN používají uvnitř sítě poskytovatele jednosměrové zasílání MPLS IP a na hraně mezi poskytovatelem a zákazníkem využívají další funkce postavené na MPLS. Navíc, sítě MPLS VPN překonávají díky protokolu MP-BGP jisté problémy, které vznikají při připojení velkého počtu internetových sítí IP u zákazníků do vlastní sítě IP tedy problémy, mezi něž patří nutnost obsluhy duplicitních adresových prostorů IP. Tuto část výkladu kapitoly zahájíme proto diskusí o některých problémech spojených se zajišťováním služeb vrstvy 3, a poté se podíváme na nejdůležitější funkce MPLS, jež na tyto problémy přinášejí řešení.

Kapitola 19 Přepínaný protokol MPLS 675 Problém: duplicitní intervaly adres u zákazníků Jestliže poskytovatel služeb připojí široký okruh zákazníků prostřednictvím služby WAN na vrstvě 2 jako je Frame Relay nebo ATM, o vnitřní adresování IP a podsítě u těchto zákazníků se nezajímá. Pokud má nyní stejné zákazníky převést na službu WAN vrstvy 3, musí od jednotlivých zákazníků intervaly adres zjistit a poté příslušné cesty oznámit do své vlastní sítě. I kdyby se ale poskytovatel chtěl dozvědět o všech podsítích od všech zákazníků, vzniká problém s tím, že mnoho podniků používá stejný interval adres což jsou konkrétně privátní čísla sítí IP, včetně nejoblíbenější sítě 10.0.0.0. Pokud bychom se pokusili zajistit služby pro širší okruh zákazníků pomocí MPLS se samotným jednosměrovým směrováním IP, vznikal by ve směrovačích zmatek kvůli překrývajícím se prefixům, jak jasně vidíme na obrázku 19.11. Zde uvnitř centrálního síťového prostoru vidíme pět směrovačů u poskytovatele; dále jsou zde tři zákazníci, A, B a C, z nichž každý má k poskytovateli připojeny dva směrovače. Všichni tři zákazníci používají ovšem privátní síť 10.0.0.0, přičemž tři pracoviště na pravé straně používají shodně podsíť 10.3.3.0/24. 19 Přepínaný protokol MPLS CE-A1 Která cesta do sítě 10.3.3.0/24 je lepší? IGP IGP IGP 10.3.3.0/24 CE-A2 Zákazník A Podsíť 10.3.3.0/24 Zákazník A CE-A4 Zákazník B CE-B1 Zákazník C CE-C1 PE1 IGP IGP P1 P2 IGP PE2 IGP PE4 IGP 10.3.3.0/24 CE-B2 CE-C2 Zákazník B Podsíť 10.3.3.0/24 Zákazník C Podsíť 10.3.3.0/24 Síť poskytovatele služeb IGP 10.3.3.0/24 Obrázek 19.11: Hlavní problém se zajištěním sítí VPN na vrstvě 3 Prvním a nejzákladnějším cílem služeb sítí VPN na vrstvě 3 je umožnit pracovištím (podsítím) zákazníka A komunikovat s jinými pracovišti zákazníka A tedy jen s pracovišti zákazníka A. Síť na obrázku 19.11 ovšem tento cíl splnit nedokáže, a to hned z několika důvodů. Vzhledem k překryvu adresových prostorů nastává u několika směrovačů poskytovatele problém, že by potřebovaly zvolit za nejlepší cestu jen cestu do podsítě 10.3.3.0/24 od jednoho zákazníka a cestu do stejné podsítě u jiného zákazníka by měly ignorovat. PE2 se například dozví dva různé prefixy 10.3.3.0/24. Pokud si nyní vybere z těchto dvou možných cest jen jednu dejme tomu, že by jako nejlepší vybral třeba cestu do směrovače CE-A2 nemohl by již směrovat pakety do sítě 10.3.3.0/24 u zákazníka B, přes směrovač CE-B2. Ještě horší ale je, že hostitel na pracovišti jednoho zákazníka by si takto mohl vyměňovat pakety s hostiteli v síti jiného zákazníka: v našem příkladu tak třeba hostitelé na pracovištích