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čí témata písemné zkoušky Cisco CCIE Routing and Switching. Podrobnější informace k tématů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.

K1613.indd 655

Směrovač 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í

24.2.2009 12:42

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í témata hlavní části kapitoly a odpovídající čísla otázek Základní téma části kapitoly

Otázky probírané v této části

Jednosměrové zasílání MPLS IP

1–4

Virtuální privátní sítě MPLS VPN

5–8

Ostatní aplikace protokolu MPLS

9

Skóre

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. Směrovač 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. Směrovač R2 se musí dozvědět cestu IGP do sítě 1.1.1.0/24. B. Směrovač R2 nebude návěští směrovači R1 oznamovat, a to díky pravidlu rozdělení horizontu. C. Směrovač 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. Směrovač R2 se nejprve musí dozvědět cestu do sítě 1.1.1.0/24 z protokolu MPBGP 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.

K1613.indd 656

24.2.2009 12:42

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é?

19 Přepínaný protokol MPLS

Kapitola 19 – Přepínaný protokol MPLS

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.

K1613.indd 657

24.2.2009 12:42

658


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í témata 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:

K1613.indd 658

24.2.2009 12:42

659

Jednosměrové zasílání MPLS IP. Virtuální privátní sítě MPLS VPN. 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ší témata k MPLS.



Poznámka 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).

K1613.indd 659

24.2.2009 12:42

660


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ěrovač Přímo připojené, statické, ze směrovacích protokolů Směrovací tabulka Nejlepší cesty

Přidává 1 položku FIB na každý prefix Paket: cíl = 10.3.3.1

Detaily k zapouzdření a odeslání

Prefix

Další přeskok

Odchozí rozhraní

10.3.3.0/24

192.168.11.1

S0/0/1

CEF FIB Prefix

Přilehlá IP adresa

10.3.3.0/24

192.168.11.1

Tabulka přilehlosti CEF Další přeskok

Odchozí rozhraní Nová hlavička vrstvy 2

192.168.11.1

S0/0/1

(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.

K1613.indd 660

24.2.2009 12:42


661

2

CE1

PE1 LSR

IP

1

3

22

IP

4

39

IP

P1 LSR

5

19

IP

PE2 LSR

6

CE2

IP

Přepínaný protokol MPLS

IP

B

A

10.3.3.3

Obrázek 19.2: Zasílání paketů s MPLS – od začátku do konce

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. Směrovač 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í. (Směrovač 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. Směrovač 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 Klíčové téma

Typ LSR

Jaké operace tento LSR provádí

Směrovač 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.

K1613.indd 661

Hranový LSR (E-LSR)

Směrovač 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í.

Vstupní (ingress) E-LSR

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í.

24.2.2009 12:42

662


Typ LSR

Jaké operace tento LSR provádí

Výstupní (egress) E-LSR

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í.

ATM-LSR

Směrovač 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.

ATM E-LSR

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.

Klíčové téma

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

Klíčové téma

Prefix

P1 LFIB Akce

10.3.3.0/24

PE2 LFIB

Odchozí Odchozí

Vstupní

návěští rozhraní

návěští

Push 22

S0/0/1

22

Akce

Odchozí Odchozí

Prefix

Akce

39

Pop

návěští rozhraní Swap 39

Odchozí Odchozí návěští rozhraní

S0/0/1

N/A

Fa0/1

Cíl 10.3.3.3 22

IP

Směrovač PE1

S0/0/1

39

IP

Směrovač P1

IP

S0/1/0

IP

Směrovač PE2

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.

K1613.indd 662

24.2.2009 12:42

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.



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. 20

3

1

8

Label

EXP

S

TTL

Obrázek 19.4: Hlavička MPLS Tabulka 19.3: Pole hlavičky MPLS Klíčové téma

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 (Bottom-of-Stack, S)

1

Pokud je tento příznak roven 1, znamená to, že toto návěští bezprostředně předchází hlavičce IP.

Životnost (Time-to-Live, TTL)

8

Má stejný význam jako pole TTL v hlavičce IP.

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

K1613.indd 663

24.2.2009 12:42

664


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. Směrovač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.

Klíčové téma

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. Ignorovat pole IP TTL (stále je 3) Dekrementovat pole MPLS TTL na 2

Dekrementovat IP TTL na 3 Zapsat novou hlavičku MPLS Zkopírovat TTL do nového pole MPLS

1

IP TTL 4

Směrovač CE1

2

IP TTL 3 MPLS TTL 3

Směrovač PE1

Vstupní E-LSR

3

IP TTL 3 MPLS TTL 2

Směrovač P1

LSR

Dekrementovat pole MPLS TTL na 1 Odebrat hlavičku MPLS Zkopírovat pole MPLS TTL do IP TTL

4

IP TTL 1

Směrovač PE2

Směrovač CE2

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.

K1613.indd 664

24.2.2009 12:42

Klíčové téma

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. Ignorovat pole IP TTL (stále je 3) Dekrementovat pole MPLS TTL na 254

Dekrementovat IP TTL na 3 Zapsat novou hlavičku MPLS s hodnotou TTL = 255

1

IP TTL 4

Směrovač CE1

2

IP TTL 3 MPLS TTL 255

Směrovač PE1

Vstupní E-LSR

3

Dekrementovat pole MPLS TTL na 253 Odebrat hlavičku MPLS

IP TTL 3 MPLS TTL 254

Směrovač P1

LSR

4



IP TTL 3

Směrovač PE2

Směrovač CE2

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.

K1613.indd 665

24.2.2009 12:42

666


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. 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

Směrovač P1

2

1 Aktualizace IGP: cesta do prefixu 10.3.3.0/24

LDP: 10.3.3.0/24, 39 Směrovač CE1

Směrovač PE1

3 Směrovač PE2

3

LDP: 10.3.3.0/24, 39

Směrovač CE2

B

Směrovač P2

10.3.3.0/24

Obrázek 19.7: Proces LDP spuštěný novou jednosměrovou cestou IP

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.

K1613.indd 666

24.2.2009 12:42

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. Klíčové téma



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.

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

Aktualizace IGP: cesta do 10.3.3.0/24 (4)

Směrovač P1

5

4 5

5 S0/1/1

Směrovač PE1

Směrovač PE2

6

S0/1/1

Směrovač CE2

6 4

6 LDP: 10.3.3.0/24, 86

Aktualizace IGP: cesta do 10.3.3.0/24

B

Směrovač P2

Aktualizace LDP v kroku 6:

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

K1613.indd 667

24.2.2009 12:42

668


Směrovač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. Směrovač 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 Klíčové téma

Směrovač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-

K1613.indd 668

24.2.2009 12:42

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).



LID 2.2.2.2 Všechny IP adresy začínají prefixem 192.168, není-li uvedeno jinak.

S0/1/1

S0/1/0

Směrovač P1

23.2 S0/1/1 24.2

12.2 LID 1.1.1.1

LID 3.3.3.3

S0/1/1

S0/1/0 23.3

12.1 15.5

15.1

Směrovač CE1

Směrovač PE1

36.3

14.1

34.3

Směrovač PE2

Fa0/1

36.6

Fa0/1

Směrovač CE2

S0/1/1

S0/1/1

14.4

10.3.3.1

24.4 S0/1/0

S0/1/1

34.4 Směrovač P2

B

S0/1/1

LID 4.4.4.4

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

K1613.indd 669

24.2.2009 12:43

670


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. Směrovač 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.

K1613.indd 670

24.2.2009 12:43

671

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 1 PE1#show mpls Idp bindings 10.3.3.0 24

3

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 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. Směrovač 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

K1613.indd 671

24.2.2009 12:43

672


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 tag tag or VC or Tunnel Id switched interface 22 39 10.3.3.0/24 0 Se0/1/0 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

Next Hop point2point

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

K1613.indd 672

24.2.2009 12:43

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. 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 tag tag or VC or Tunnel Id switched 39 Untagged 10.3.3.0/24 0

Outgoing interface Fa0/1

Next Hop 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.) Směrovač 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

K1613.indd 673

24.2.2009 12:43

674


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ů. Směrovač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 Klíčové téma

Vlastnost LDP

Implementace LDP

Transportní protokoly

UDP (Hello), TCP (aktualizace)

Čísla portů

646 (LDP), 711 (TDP)

Cílová adresa zpráv Hello

224.0.0.2

Kdo iniciuje spojení TCP

Nejvyšší LDP ID.

Kterou adresu používá spojení TCP

Transportní IP adresu (pokud je konfigurována), případně LDP ID, pokud transportní adresa chybí.

LDP ID je stanoven podle těchto pravidel, v pořadí priority

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í.

K1613.indd 674

24.2.2009 12:43


675

Problém: duplicitní intervaly adres u zákazníků


19

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. Která cesta do sítě 10.3.3.0/24 je lepší?

CE-A1

IGP 10.3.3.0/24

CE-A2

IGP

IGP

Zákazník A Podsíť 10.3.3.0/24

Zákazník A PE1

P1

PE2

CE-A4 IGP

Zákazník B

IGP

CE-B2

Zákazník B Podsíť 10.3.3.0/24

IGP 10.3.3.0/24

IGP

CE-B1 P2 Zákazník C CE-C1

IGP

PE4

Síť poskytovatele služeb

CE-C2

Zákazník C Podsíť 10.3.3.0/24

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. Směrovač 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

K1613.indd 675

24.2.2009 12:43

676


či v podsítích zákazníků B a C začnou odesílat pakety do „své“ sítě 10.3.3.0/24, ty ale díky zpracování u poskytovatele skončí ve směrovači CE-A2 u zákazníka A.

Řešení: virtuální privátní síť MPLS VPN Protokoly a standardy definované sítěmi MPLS VPN jsou nejenže řešením problémů znázorněných na obrázku 19.11, ale zároveň nabízejí mnohem širší množinu funkcí. Dokumenty RFC pro MPLS VPN tak zejména definují myšlenku používání několika směrovacích tabulek, které se nazývají tabulky virtuálního směrování a zasílání VRF (Virtual Routing and Forwarding) a jež oddělují cesty jednotlivých zákazníků, a tím řeší problém duplicitních intervalů adres. V této části textu si zavedeme základní názvosloví a seznámíme se také se základními mechanismy sítí MPLS VPN. Roli konkrétního směrovače označujeme při výstavbě sítí MPLS VPN pomocí jednoho ze tří pojmů. Všimněte si, že i názvy směrovačů ve většině obrázků této kapitoly dodržují následující konvenci značení směrovačů CE, PE a P:

Customer edge (CE). Hrana zákazníka. Směrovač, který vůbec nezná protokoly MPLS a nezasílá ani pakety s návěštím, je ale přímo připojen ke směrovači LSR (PE) v síti MPLS VPN. Provider edge (PE). Hrana poskytovatele. Směrovač LSR, který má společnou linku s nejméně jedním směrovačem CE, a tudíž zajišťuje podobné funkce jako hrana MPLS VPN, včetně tabulek iBGP a VRF. Provider (P). Poskytovatel. Směrovač LSR, který nemá přímé spojení se směrovačem CE, takže může zasílat pakety s návěštími a jenž může ignorovat cesty v sítích VPN jednotlivých zákazníků.

Klíčové téma

Pro pochopení obecného mechanismu činnosti sítě MPLS VPN je důležité se zaměřit na rozdíly mezi směrovači PE a P na řídicí rovině. Na obou těchto typech směrovačů pracují protokoly LDP a IGP pro podporu jednosměrového směrování IP – jak jsme o tom hovořili v první polovině této kapitoly. Protokol IGP oznamuje ale jen cesty pro podsítě uvnitř sítě MPLS, bez cest u zákazníků. To znamená, že směrovače P a PE mohou společně přepínat pakety s návěštími po celé cestě od vstupního PE po výstupní PE. Klíčové téma

Směrovače PE mají ovšem i několik dalších povinností, jejichž společným cílem je otázka zjištění cest u zákazníka a sledování, které cesty patří jakým zákazníkům. Směrovače PE si vyměňují cesty s připojenými směrovači CE u různých zákazníků, ať už je to v protokolech eBGP, RIP-2, OSPF nebo EIGRP, přičemž si pamatují, které cesty zjistily od jakých zákazníků. Aby si směrovače PE mohly zapamatovat i případně se překrývající prefixy, neukládají cesty do normální směrovací tabulky IP, nýbrž do samostatných směrovacích tabulek, vytvořených zvlášť pro každého zákazníka – to jsou tabulky VRF. Poté si směrovače PE ve vhodném protokolu iBGP vyměňují tyto zákaznické cesty s jinými PE, ale směrovačům P je nikdy neoznamují. Uvedené principy činnosti řídicí roviny dokresluje obrázek 19.12.

K1613.indd 676

24.2.2009 12:43


677

Pojmem globální směrovací tabulka rozumíme běžnou směrovací tabulku IP, která se normálně používá pro zasílání paketů; tím ji rozlišíme od jednotlivých směrovacích tabulek VRF.

iBGP

Klíčové téma

CE-A1

Zákazník A Podsíť 10.3.3.0/24 CE-A2

IGP nebo eBGP

IGP nebo eBGP

Zákazník A PE1 CE-A4

IGP nebo eBGP

Zákazník C

LDP/ IGP

LDP/ IGP

Zákazník B CE-B1


19

Poznámka

IGP nebo eBGP

P1 LDP/ IGP

P2

PE2

LDP/ IGP LDP/ IGP

Zákazník B Podsíť 10.3.3.0/24 CE-B2

IBGP

LDP/ IGP

iBGP

CE-C1

IGP nebo eBGP

PE4

Zákazník C Podsíť 10.3.3.0/24 CE-C2

Síť poskytovatele služeb Obrázek 19.12: Přehled řídicí roviny sítě MPLS VPN

Také na datové rovině MPLS VPN čeká směrovače PE o trošku více práce a více „přemýšlení“: je to jediná výjimka, která se liší od prostého jednosměrového směrování IP a jež souvisí s tím, že na datové rovině MPLS VPN musí vstupní směrovač PE doplnit do paketu dvě návěští: Klíčové téma

Vnější hlavičku MPLS (S-bit = 0), jehož návěští má takovou hodnotu, podle které bude paket přepínaný do výstupního PE. Vnitřní hlavičku MPLS (S-bit = 1), jehož návěští identifikuje výstupní tabulku VRF, podle které se bude provádět rozhodnutí o zasílání. Na obrázku 19.13 vidíme obě tato návěští i celý proces zasílání z obecného konceptuálního pohledu. Jedná se v podstatě o podmnožinu obrázku 19.12, v níž byla většina symbolů pro přehlednost vynechána. V tomto případě hostitel v síti zákazníka A na levé straně obrázku zasílá paket hostiteli 10.3.3.3 na pravé straně. Tento obrázek zachycuje následující kroky: 1. Směrovač CE1 odešle paket bez návěští do směrovače PE1. 2. PE1 přijme paket na rozhraní přiřazeném k tabulce VRF-A a porovná proto jeho cílovou IP adresu 10.3.3.3 s bází VRF-A CEF FIB, která vychází ze směrovací tabulky VRF-A. Poté PE1 doplní k paketu dvě návěští podle FIB a odešle jej s návěštím dál.

K1613.indd 677

24.2.2009 12:43

678


Příchozí rozhraní v tabulce VRF-A, které uvádí síť 10.3.3.0/24 s návěštími 1111 a 3333.

Klíčové téma

Podle LFIB se mají obě návěští odebrat a paket odeslat do CE2.

LFIB uvádí operaci výměny; vstupní návěští 1111, výstupní návěští 2222

2

3

Vnější: Vnitřní: IP 1111 3333


Směrovač PE1

Směrovač P1

Vnitřní rozhraní VRF-A

4 Směrovač PE2

Vnitřní rozhraní VRF-A IP

1

IP

Směrovač CE1

Směrovač CE2

Obrázek 19.13: Přehled datové roviny sítě MPLS VPN

3. Směrovač P1 pracuje stejně jako u jednosměrového směrování IP a zpracuje tedy přijatý paket s návěštím podle své LFIB, která mu jednoduše nařizuje výměnu návěští. Výsledný paket odešle směrovači PE1. 4. U směrovače PE2 je v položce LFIB pro návěští 2222 uvedena operace odebrání (pop), takže PE2 odstraní vnější návěští. Pro návěští 3333 je v položce LFIB, naplněné podle tabulky VRF sítě VPN u zákazníka A, také uvedena operace odebrání a navíc i odchozí rozhraní. Výsledný paket bez návěští odešle PE2 do směrovače CE2.

Poznámka Ve skutečné praxi vypadají kroky 3 a 4 trochu jinak než v tomto přehledu, a to díky funkci označované jako PHP (penultimate hop popping, odebrání v předposledním přeskoku). Úkolem tohoto příkladu je nicméně jen vysvětlit základní principy; celou logiku se zapnutou funkcí PHP, která je v sítích MPLS VPN při základním nastavení zapnutá, si upřesníme na obrázku 19.23 ke konci této kapitoly.

Z procesů řídicí roviny a datové roviny, zobrazených schematicky na obrázcích 19.12 a 19.13, je zřejmé, jak sítě MPLS VPN fungují. Dále se ve výkladu ponoříme o něco hlouběji a podíváme se na nové datové struktury a procesy řídicí roviny, jež činnost sítí MPLS VPN podporují.

Řídicí rovina MPLS VPN Řídicí rovina MPLS VPN definuje protokoly a mechanismy, které slouží k překonání problémů souvisejících s překryvem adresového prostoru IP jednotlivých zákazníků a jež zároveň rozšiřují funkce MPLS VPN, zejména ve srovnání s tradičními službami WAN na vrstvě 2. Máme-li správně pochopit mechanismy řídicí roviny, musíme dobře rozumět protokolům BGP, IGP a také několika novým myšlenkám popsaným v dokumentech RFC k protokolu MP-BGP a k MPLS. Zejména si v této části textu kapitoly zavedeme a vysvětlíme principy těchto tří komponent MPLS VPN:

K1613.indd 678

24.2.2009 12:43

679

Tabulky VRF. Rozlišovače cesty (Route Distinguisher, RD). Určení cest (Route Targets, RT). Jednotlivá témata probereme (v tomto pořadí) na následujících stránkách knížky. V textu budeme postupně rozvíjet jeden jednoduchý příklad, který nastiňuje, jak se řídicí rovina dozví o cestách do duplicitních podsítí u zákazníků s prefixem 10.3.3.0/24 na pravé straně obrázku 19.12, jak tyto cesty zapíše do tabulek VRF ve směrovači PE2 a jak oznámí cesty s rozlišovači RD směrovači PE1, a jak poté podle určení RT určí, jakým způsobem má PE1 přidat tyto cesty do svých tabulek VRF.



Tabulka virtuálního směrování a zasílání (VRF) Pro zajištění podpory většího množství zákazníků definují standardy sítí MPLS VPN takzvaný virtuální směrovač. Přesněji se jedná o tabulku virtuálního směrování a zasílání (Virtual Routing and Forwarding table, VRF), do níž je možné ukládat cesty odděleně pro sítě VPN jednotlivých zákazníků. Díky odděleným tabulkám vyřešíme významnou část problémů, které jinak mohou vznikat při překrývání síťových prefixů a následném „prosakování“ paketů jednoho zákazníka do sítě druhého zákazníka, a zároveň umožníme vzájemnou komunikaci všech pracovišť v síti VPN stejného zákazníka. Tabulka VRF je uložena vždy v jediném směrovači s podporou MPLS. Směrovač zpravidla potřebuje nejméně jednu. To znamená VRF pro každého zákazníka, který je k němu připojený. Na obrázku 19.12 je tak například směrovač PE2 připojen ke směrovačům CE u zákazníků A a B, už ale ne u zákazníka C, takže tabulku VRF pro zákazníka C nepotřebuje. Směrovač PE1 je oproti tomu připojen ke směrovačům CE u tří různých zákazníků, a proto musí udržovat i tři různé tabulky VRF. Ve složitější síti může jeden směrovač PE potřebovat několik tabulek VRF i pro podporu jediného zákazníka. Vraťme se opět k příkladu na obrázku 19.12 a podívejme se na směrovač PE1, který je připojen ke dvěma směrovačům CE u stejného zákazníka A (CE-A1 a CE-A4). Pokud by hostitelé okolo CE-A1 měli povolen přístup k nějaké centralizované sdílené službě (ta na obrázku není vyznačena), zatímco hostitelé v okolí CE-A4 by tento přístup povolen neměli, potřeboval by směrovač PE1 pro zákazníka A skutečně dvě tabulky VRF – jednu s cestami do podsítě se sdílenou službou a druhou bez těchto cest. Každá tabulka VRF má následující tři hlavní komponenty: Klíčové téma

Směrovací tabulku IP (označovanou zde jako RIB). Bázi CEF FIB, naplněnou podle RIB této tabulky VRF. Samostatnou instanci neboli proces směrovacího protokolu, který si bude vyměňovat cesty se směrovači CE podporovanými touto tabulkou VRF. Na obrázku 19.14 tak vidíme podrobnější informace o směrovači PE2 z obrázku 19.12, tentokrát již po implementaci síti MPLS VPN. V tomto případě bude PE2 v roli protokolu IGP směrem ke směrovači zákazníka A (CE-A2) i ke směrovači zákazníka B (CE-B2) používat protokol RIP-2. (Konkrétní směrovací protokol zvolený pro komunikaci mezi PE-CE je ovšem s ohledem na hloubku našeho výkladu nepodstatný.)

K1613.indd 679

24.2.2009 12:43

680


RIB – VRF-A Další přeskok Odchozí rozhr.

Prefix

3

10.3.3.0/24 192.168.37.7 S0/1/0

Proces VRF-A RIP

1 2

RIP-2 10.3.3.0/24

Zákazník A Směrovač

S0/1/0 —VRF-A

192.168.37.7

CE-A2

Podsíť 10.3.3.0/24

Podsíť 192.168.38.8 CE-B2 10.3.3.0/24

Směrovač PE2 S0/1/1 —VRF-B

Směrovač

2 1

RIB – VRF-B Prefix

Další přeskok Odchozí rozhr.

10.3.3.0/24 192.168.38.8 S0/1/1

3

RIP-2 10.3.3.0/24

Zákazník B

Proces VRF-A RIP

Obrázek 19.14: Přidávání cest zjištěných od CE do tabulky VRF ve směrovači PE2

V obrázku jsou zachyceny tři kroky, které paralelně probíhají u každého ze zákazníků. Neznamená to ale nutně, že by krok 1 musel u obou zákazníků proběhnout přesně ve stejném okamžiku a podobně ani kroky 2 a 3; v krocích se nicméně provádějí stejné operace a časově se mohou překrývat. Vysvětleme si tedy jednotlivé kroky: 1. Směrovač CE-A2, který o nějakém MPLS vůbec neví, oznámí normálně cestu do podsítě 10.3.3.0/24, v tomto případě protokolem RIP-2. 2. Zhruba nahoře uprostřed vidíme krok 2, kdy aktualizace RIP-2 dorazí směrovače PE2, a to na rozhraní S0/1/0, které bylo přiřazeno tabulce VRF zákazníka A (VRF-A). Ve směrovači běží pro každou tabulku VRF samostatný proces, takže zmíněnou aktualizaci bude interpretovat proces VRF-A RIP. Podobně aktualizaci, kterou PE2 přijme na rozhraní S0/1/1 od směrovače CE-B2, bude zpracovávat proces VRF-B RIP. 3. Proces VRF-A RIP v horní části obrázku přidá v kroku 3 položku podsítě 10.3.3.0/24 do báze RIB pro tabulku VRF-A. Podobně dole na obrázku přidá proces VRF-B RIP cestu do prefixu 10.3.3.0/24 do báze VRF-B RIB.

Poznámka Ke každé tabulce VRF je definována také FIB, která na obrázku není zachycena. Systém IOS do ní zapisuje položku ke každé položce RIB.

Protokol MP-BGP a rozlišovače cest (RD) Nyní se tedy PE2 dozvěděl cesty od směrovačů CE-A2 i CE-B2 a dále je potřebuje oznámit ostatním směrovačům, které tak budou vědět, jak směrovat pakety do nově zjištěných podsítí. Protokoly sítí MPLS VPN stanovují pro oznamování cest protokol iBGP – tedy všech cest ze všech tabulek VRF. Původní specifikace BGP ale nijak nepočítají s tím, že i různí zákazníci mohou používat překrývající se prefixy. Sítě MPLS řeší problém překrývajících se prefixů doplněním dalšího čísla před původní prefix neboli BGP NLRI. Každé jiné číslo může reprezentovat jiného zákazníka a hodnoty NLRI jsou tak jednoznačné. K tomu využívá MPLS dokument BGP RFC, nazývaný MP-BGP (RFC 4760), který umožňuje předefinování pole NLRI v aktualizacích BGP. Konkrétně tak povoluje

K1613.indd 680

24.2.2009 12:43

681

doplnit před prefix další číslo s proměnnou délkou, nazývané rodina adres (address family). Dokument MPLS RFC 4364, „BGP/MPLS IP Virtual Private Networks (VPNs)“, pak definuje konkrétní novou rodinu adres pro podporu sítí MPLS VPN nad IPv4 – konkrétně rodinu adres MP-BGP nazývanou rozlišovače cest (Route Distinguishers, RD). Klíčové téma

Pomocí rozlišovačů (RD) může protokol BGP rozlišit i mezi duplicitními prefixy IPv4 a může je také oznamovat. Myšlenka je jednoduchá: každý prefix NLRI se oznámí jako klasický prefix IPv4, ale doplní se k němu nové číslo (RD), které již cestu identifikuje jednoznačně. Nový formát NLRI, nazývaný VPN-V4, má tyto dvě části:



64bitový rozlišovač RD 32bitový prefix IPv4 Na obrázku 19.15 tak pokračujeme v příkladu z obrázku 19.14 a směrovač PE2 zde protokolem MP-BGP oznamuje směrovači PE1 svoje dvě cesty pro prefix IPv4 10.3.3.0/24 – jednu z tabulky VRF-A a druhou z VRF-B. Z aktualizace BGP vidíme formát nové rodiny adres VPN-V4 pro informace NLRI, přičemž rozlišovač RD 1:111 reprezentuje síť VPN-A a 2:222 označuje VPN-B. Směrovač PE2 RIB—VRF-A—RD 1:111 Zdroj

Prefix

RIP

10.3.3.0/24 192.168.37.7 S0/1/0

Další přeskok Rozhraní

Redistribuce RIP do BGP

3 iBGP Směrovač PE1

NLRI


1:111:10.3.3.0/24 3.3.3.3

41

2:222:10.3.3.0/24 3.3.3.3

42

2

Tabulka BGP NLRI

Další přeskok Návěští

1:111:10:3.3.0/24

3.3.3.3

41

2:222:10.3.3.0/24

3.3.3.3

42

1

Tabulka BGP Proces BGP

Redistribuce RIP do BGP

1

RIB—VRF-B—RD 2:222 Zdroj

Prefix

RIP

10.3.3.0/24 192.168.38.8 S0/1/1


Obrázek 19.15: Po doplnění rozlišovače RD jsou prefixy jednoznačné

Poznámka Směrovač PE2 má za další přeskok sebe sama a jako zdroj aktualizací má uvedeno zpětnovazební rozhraní s IP adresou 3.3.3.3.

Kdyby rozlišovač RD součástí VPN-V4 NLRI nebyl, dozvěděl by se směrovač PE1 o dvou identických prefixech BGP (10.3.3.0/24) a musel by jednu z těchto cest zvolit jako nejlepší, takže nakonec by zajistil dostupnost jen pro podsíť 10.3.3.0/24 u jednoho zákazníka. Jakmile je ale VPN-V4 NLRI doplněný o rozlišovač, oznámí již iBGP dva jedinečné NLRI – a to 1:111:10.3.3.0 (z tabulky VRF-A) a 2:222:10.3.3.0 (z VRF-B). V tabulce BGP si tudíž PE1 nechá zapsané oba NLRI. Přesněji můžeme jednotlivé kroky z obrázku 19.15 popsat takto:

K1613.indd 681

24.2.2009 12:43

682


1. Směrovač PE2 redistribuuje do protokolu BGP cesty z příslušných směrovacích protokolů obou instancí VRF (v tomto případě je to RIP-2). 2. Při procesu redistribuce přebírá vždy rozlišovač RD z odpovídající tabulky VRF a doplňuje jej ke všem cestám, redistribuovaným ze směrovací tabulky k VRF. 3. PE2 oznamuje tyto cesty pomocí protokolu iBGP směrovači PE1, který tím pádem zná cesty do obou sítí 10.3.3.0/24, rozlišených podle hodnoty RD.

Poznámka Hodnotu rozlišovače RD je nutné konfigurovat do každé tabulky VRF, k čemuž v systému IOS slouží dílčí příkaz tabulky VRF, rd.

Samotný RD tvoří 8 bajtů dat a platí pro něj jisté povinné konvence formátování. První 2 bajty identifikují, který ze tří možných formátů dále následuje. Protože systém IOS dokáže mezi těmito třemi formáty rozlišit již podle samotné hodnoty zbytku, stačí v dílčím příkazu IOS rd k tabulce VRF zapsat jen celočíselné hodnoty posledních 6 bajtů a systém IOS doplní první 2 bajty (typ) automaticky. Zbývajících 6 bajtů má následující formát, který platí jak pro zadání v příkazu rd, tak i pro výpis v příkazu show:

2bajtové celé číslo:4bajtové celé číslo 4bajtové celé číslo:2bajtové celé číslo 4bajtové číslo v tečkové desítkové notaci:2bajtové celé číslo První hodnotu před dvojtečkou tvoří ve všech třech případech buďto 2bajtové číslo autonomního systému (ASN), nebo 4bajtová adresa IPv4. Druhá hodnota za dvojtečkou již může nabývat libovolné zvolené hodnoty. V rozlišovači RD můžeme například uvést BGP ID směrovače LSR ve třetím formátu, tedy 3.3.3.3:100, anebo využít číslo ASN protokolu BGP, třeba 432:1. V tomto okamžiku se směrovač PE1 podle našeho průběžného příkladu dozvěděl dvě cesty do podsítě 10.3.3.0/24 – jednu pro VPN-A a druhou pro VPN-B – přičemž obě zapsal do tabulky BGP. V následujícím odstavci si řekneme, jak se PE1 rozhodne, do které z tabulek VRF tyto cesty zapsat, a to na základě takzvaného určení cest.

Určení cest (RT) Jedním z nejhůře pochopitelných pojmů je v souvislosti se sítěmi MPLS VPN pro všechny konstruktéry sítí koncept takzvaného určení cesty (Route Target, RT; určení cíle cesty). Pochopit základní myšlenku, co to určení cesty je, není tak těžké, ale proč vlastně MPLS potřebují RT a jak nejlépe volit skutečné hodnoty RT, to už při výstavbě sítě MPLS VPN může být námětem hodně zdlouhavé debaty. Ve skutečnosti ale sítě MPLS díky atributům určení cest RT dokážou podporovat jakkoli složité topologie VPN – některá pracoviště mohou být například dosažitelná z několika různých VPN a tím mohou vznikat takzvané překrývající se VPN. Směrovače PE oznamují určení cest (RT) v aktualizacích BGP v rozšířených atributech trasy, BGP Extended Community Path Attributes (PA). Obecně mají rozšířené komunity BGP délku 8 bajtů a jsou velmi flexibilní, takže se dají používat pro nejrůznější účely. Přesněji

K1613.indd 682

24.2.2009 12:43

683

tak MPLS definuje atribut BGP Extended Community PA s tím, že kóduje jednu nebo více hodnot RT. Hodnoty RT mají stejný základní formát jako hodnoty rozlišovačů RD. Všimněte si ale, že zatímco popisovač RD může být konkrétnímu prefixu přiřazen vždy pouze jeden, určení RT může mít přiřazeno i několik. Význam atributů RT v MPLS nejlépe pochopíme na obecnější definici, po které bude následovat příklad mechanismu, v němž směrovač PE s atributem RT pracuje:



Mechanismus MPLS ve směrovači PE pomocí určení cest (RT) stanoví, do které tabulky VRF zapíše cesty zjištěné protokolem iBGP.

Klíčové téma

Na obrázku 19.16 pokračujeme v příkladu z obrázků 19.14 a 19.15, a tentokrát se zaměříme na to, jak směrovače PE podle hodnot RT stanoví, do které z tabulek VRF cestu zapíší. Konkrétně na obrázku vidíme exportní RT – to je parametr režimu konfigurace VRF – kde pro tabulky VRF-A a VRF-B jsou stanoveny různé hodnoty. Na směrovači PE1 pak vidíme importní RT pro každou VRF (tu opět definujeme v režimu konfigurace VRF) a podle ní se PE1 rozhodne, které položky z tabulky BGP zapíše do RIB v příslušné tabulce VRF. Směrovač PE1

Směrovač PE2

Směrovací tabulka VRF-A Zdroj Prefix

VRF-A Zdroj Prefix

Další přeskok

VRF-A RD 1:111 Importní RT 1:100

1 5

6


RIP 10.3.3.0/24 192.168.37.7 S0/1/0

RIP 10.3.3.0/24 3.3.3.3

Tabulka BGP

NLRI

RT

1:111:10.3.3.0/24

1:100

2:222:10.3.3.0/24

2:200

VRF-A RD 1:111 Exportní RT 1:100

2

3

4 IBGP Tabulka BGP

Redistribuce

NLRI

RT

1:111:10.3.3.0/24

1:100

2:222:10.3.3.0/24

Proces BGP

3

2:200

6 2

3 VRF-B RD 2:222 1 Importní RT 2:200 Zdroj Prefix

5

Další přeskok

VRF-B RD 2:222 1 Exportní RT 2:200 Zdroj Prefix

BGP 10.3.3.0/24 3.3.3.3

RIP

Směrovací tabulka VRF-B

VRF-B

Redistribuce


10.3.3.0/24 192.168.38.8 S0/1/1

Obrázek 19.16: Mechanismus zpracování určení cesty RT

V obrázku se zdánlivě skrývá množství detailů, ale celkový tok informací naštěstí není nijak obtížný. Podívejme se na naznačené kroky: 1. V konfiguraci dvou tabulek VRF na směrovači PE2 jsou definovány exportní hodnoty RT. 2. Proběhne redistribuce tabulek VRF do protokolu BGP. 3. Tento krok pouze upozorňuje, že proces exportu – tedy redistribuce VRF do BGP – zapíše odpovídající hodnoty RT také do tabulky BGP v PE2. 4. Nyní PE2 oznámí cesty protokolem iBGP.

K1613.indd 683

24.2.2009 12:43

684


5. Směrovač PE1 zkontroluje nové položky pro tabulku BGP a porovná hodnoty HT s konfigurovanými importovanými hodnotami RT, podle nichž stanoví, které položky tabulky BGP zapíše do jaké z tabulek VRF. 6. Nakonec PE1 redistribuuje a poté zapíše cesty do odpovídajících tabulek VRF, a to konkrétně cesty, jejichž určení RT se shoduje s importním RT uvedeným v konfiguraci příslušné VRF.

Poznámka Pro snazší pochopení bude dobré si říci, že pojem export znamená „redistribuci ven z VRF do BGP“, zatímco import je „redistribuce dovnitř VRF z BGP“.

Do každé tabulky VRF je nutné exportovat a importovat nejméně jedno určení RT. V příkladu na obrázku 19.16 vidíme ovšem jen jeden směr, a sice export ze směrovače PE2 na pravé straně a import do směrovače PE1 na levé straně. Stejně tak se ale PE2 potřebuje dozvědět cesty do podsítí připojených ke směrovačům CE-A1 a CE-B1, a proto si tyto cesty musí nejprve zjistit od obou CE směrovač PE1, redistribuovat je do protokolu BGP s nějakou exportovanou hodnotou RT, a poté je v protokolu iBGP oznámit směrovači PE2, který pak naimportuje správné cesty do správné tabulky VRF (podle importního RT v PE2). U jednoduchých, obvyklých implementací sítí VPN, kde každou síť VPN tvoří všechna pracoviště jednoho zákazníka, stačí ve většině případů jediná hodnota RT, kterou pak importuje a exportuje každá tabulka VRF pro daného zákazníka.

Poznámka V příkladech této kapitoly jsme do atributů rozlišovače RD a určení RT zapisovali různé hodnoty, aby bylo na pohled jasné, co které číslo znamená. V praxi ovšem můžete do RD a do jednoho RT ke stejné tabulce VRF zapsat stejnou hodnotu.

Překryv sítí VPN Díky atributu určení cesty (RT) dokáže mechanismus MPLS podporovat i překrývající se sítě VPN. K překryvu dochází, jakmile nejméně jedna lokalita umístěná za směrovačem CE musí být dosažitelná ze směrovačů CE v různých VPN. Překrývání sítí VPN má řadu variant. Poskytovatel služeb (SP) může zajišťovat služby pro mnoho zákazníků, takže fakticky implementuje sítě s CE, které potřebují být dosažitelné pro jistou podmnožinu zákazníků. Někteří zákazníci pak třeba požadují možnost připojení k některému ze svých partnerů přes síť MPLS – a zákazník A tak například chce mít možnost zasílat z jistých svých sítí pakety do pracovišť zákazníka B. Bez ohledu na konkrétní věcné cíle může jedna síť MPLS díky atributu RT „protáhnout“ do určité tabulky VRF cesty hned z několika sítí VPN. Protokol BGP podporuje možnost doplnit ke každé položce tabulky BGP atribut trasy BGP Extended Community Path Attributes (PA). Jestliže poté exportujeme jeden prefix s jednou hodnotou RT, v podstatě to znamená, „postarej se, aby se tato cesta dostala do všech tabulek VRF v síti VPN-A“, zatímco pokud

K1613.indd 684

24.2.2009 12:43

685

stejnému prefixu přiřadíme jiné RT, říkáme „protáhni tuto cestu do tabulky VRF některé z překrývajících se sítí VPN“. Na obrázku 19.17 vidíme ukázku základních principů překryvu sítí MPLS VPN a zejména pak návrhový prvek označovaný jako VPN s centrálními službami. Jako vždy mohou všechna pracoviště zákazníka A zasílat pakety všem ostatním pracovištím zákazníka A a podobně i všechna pracoviště zákazníka B odesílat pakety do všech ostatních pracovišť zákazníka B. Kromě těchto obvyklých konvencí mohou ale směrovače CE-A1 a CE-B2 komunikovat se směrovačem CE-Serv, který je napojen na skupinu centralizovaných serverů.

CE-A1

Zákazník A Podsíť 10.3.3.0/24 CE-A2

Směrovač

Směrovač



Směrovač

Zákazník A PE1 CE-A4

PE2 Zákazník B Podsíť 10.3.3.0/24 CE-B2

Směrovač

Směrovač

Zákazník B

Směrovač

CE-B1 Směrovač Směrovač

CE-Serv Podsíť Centralizované 10.4.4.0/24 servery

Obrázek 19.17: Síť VPN s centrálními službami

Pro zajištění těchto cílů návrhu sítě bude každý ze směrovačů PE potřebovat několik tabulek VRF, přičemž každá z nich bude exportovat a importovat více různých určení RT. Směrovač PE1 potřebuje například dvě tabulky VRF pro podporu zákazníka A – jedna VRF bude importovat pouze cesty pro zákazníka A a druhá VRF bude importovat jednak cesty pro zákazníka A, jednak i cesty pro dosažení sítě VPN centrálních služeb. Podobně PE2 potřebuje dvě tabulky VRF pro síť VPN centrálních služeb – jednu potřebuje pro import některých cest do sítí VPN-A a druhou pro VPN-B.

Datová rovina MPLS VPN Ve výkladu tabulek VRF a atributů RD a RT jsme si vysvětlili většinu vlastností řídicí roviny sítí MPLS VPN. Do tabulek VRF si směrovače PE ukládají cesty, zjištěné od různých směrovačů CE, i když se třeba jejich prefixy překrývají. Díky rozlišovači cesty RD může PE oznamovat cesty jako jednoznačné prefixy, přestože se klasické prefixy IPv4 náhodou překrývají. A nakonec určení cesty RT směrovači PE říká, které cesty se mají zapsat do jaké z tabulek VRF; tím je možné přesněji kontrolovat strukturu sítě a jednotlivé lokality mohou být dosažitelné i z několika různých sítí VPN.

K1613.indd 685

24.2.2009 12:43

686


Na konci procesu je ale nutné zajistit rozeslání paketů; k tomu vstupní směrovače PE potřebují příslušné položky FIB a směrovače P a PE potřebují položky LFIB. V této části textu kapitoly si vysvětlíme, jak směrovače LSR při práci v sítích MPLS VPN naplňují informační báze FIB a LFIB. Stejně jako ve zbytku kapitoly budeme i tentokrát přemýšlet, jak odesílat pakety do podsítě 10.3.3.0/24 v síti VPN zákazníka A. Zkoumání datové roviny MPLS VPN zahájíme na obrázku 19.18; ten je opakováním obrázku 19.13, navíc jsou v něm ale uvedeny také jisté detaily o bázi FIB ve vstupním směrovači PE a o bázi LFIB ve směrovači P a odchozím směrovači PE. P1 LFIB

CEF FIB — VRF-A Prefix

Výstupní návěští

10.3.3.0/24 1111, 3333

Odchozí rozhraní

1111

S0/0/1

4

Vstupní návěští Výstupní návěští Odchozí rozhraní

2

1111,2222

S0/1/0

PE2 LFIB Vstupní návěští Akce Odchozí rozhraní 2222

pop

N/A

3333

pop

S0/1/0

3 Směrovač

PE1

2


S0/0/1

3 Směrovač

P1

Vnitřní rozhraní VRF-A

S0/1/0


Směrovač

PE2 Vnitřní rozhraní VRF-A

S0/0/1 IP

1

4

IP

CE-A1

CE-A2

Směrovač

Směrovač

Obrázek 19.18: Báze FIB ve vstupním směrovači PE a báze LFIB v ostatních směrovačích

Jednotlivé kroky jsou na obrázku očíslovány takto: 1. Na rozhraní přiřazené k tabulce VRF-A přichází paket bez návěští, takže vstupní směrovač PE1 provede rozhodnutí o směrování právě podle FIB tabulky VRF-A. 2. Vstupní směrovač PE1 má v položce FIB tabulky VRF-A pro síť 10.3.3.0/24 uvedeno odchozí rozhraní S0/0/1 a zásobník se dvěma návěštími – vnitřní 3333 a vnější 1111. Při odesílání paketu zapíše proto PE1 před hlavičku IP tato dvě návěští. 3. Směrovač P1 načte položku LFIB pro příchozí (lokální) návěští 1111 a tuto hodnotu vnějšího návěští vymění za hodnotu 2222. 4. Směrovač PE2 provádí v bázi LFIB dvojí hledání. Nejprve v tabulce vyhledá návěští 2222, odebere je a ponechá jen vnitřní návěští. Poté v bázi LFIB vyhledá i vnitřní návěští 3333 a u něj najde kromě operace odebrání také odchozí rozhraní. Paket bez návěští odesílá proto přes rozhraní S0/1/0.

Poznámka Podobně jako na obrázku 19.13 se i zde přesný postup kroků 3 a 4 bude v praxi mírně lišit, a to díky funkci PHP (penultimate hop popping, odebrání v předposledním přeskoku), kterou si vysvětlíme na obrázku 19.23 ke konci kapitoly.

K1613.indd 686

24.2.2009 12:43

687

V příkladu tedy jasně vidíme, co se děje v datové rovině po vložení správných položek FIB a LFIB. Ve zbytu tohoto tématu věnovaného datové rovině MPLS VPN se budeme věnovat právě tomu, jak směrovač LSR v MPLS VPN tyto správné položky sestavuje. Při čtení výkladu mějte na paměti, jaký je vlastně v sítích MPLS VPN význam vnitřních a vnějších návěští (inner label, outer label): Klíčové téma

Vnější návěští identifikuje segmenty přepínané trasy LSP mezi vstupním směrovačem PE a výstupním směrovačem PE, nestanovuje ale, jak má výstupní směrovač odesílat paket. Vnitřní návěští popisuje informace o odeslání paketu z výstupního PE, zejména pak odchozí rozhraní pro odeslání výsledného paketu bez návěští.



Sestavení (vnitřního) návěští VPN Klíčové téma

Vnitřní návěští (inner label) identifikuje tedy odchozí rozhraní, přes které má výstupní směrovač PE odeslat paket bez návěští. Tomuto vnitřnímu návěští se říká také návěští VPN a musí být definováno pro každou cestu zapisovanou do tabulky VRF každého zákazníka. Přesněji, směrovač CE u zákazníka oznámí cesty směrovači PE, který si je uloží do VRF tohoto zákazníka. V rámci přípravy paketů k odeslání do podsítí zákazníků musí PE alokovat nové lokální návěští, přiřadit k němu prefix (a také IP adresu dalšího přeskoku a odchozí rozhraní k dané cestě) a všechny tyto informace uložit do báze LFIB. Na obrázku 19.19 vidíme cesty ze směrovače PE2 do prefixu 10.3.3.0/24 v tabulkách VRF-A a VRF-B a také výsledné položky pro LFIB. Z obrázku jsou zřejmé výsledky procesu alokace lokálního návěští pro obě cesty ve směrovači PE2 a také výsledky následného oznámení těchto návěští v protokolu BGP. (Poznamenejme, že báze LFIB neexistuje zvlášť pro každou tabulku VRF; ta existuje pouze jedna pro celý PE2.) Směrovač

Směrovač

S0/1/0 —VRF-A CE-A2

PE2

S0/1/1 —VRF-B

4 Tabulka BGP NLRI

Směrovací tabulka VRF-A Další přeskok

RT

Další přeskok

3333

3.3.3.3

2:222:10.3.3.0/24 2:200

4444

3.3.3.3

1

3

LFIB Vstupní návěští Akce

Směrovací tabulka VRF-B Další přeskok

Návěští

1:111:10.3.3.0/24 1:100 Odch. rozhraní

RIP 10.3.3.0/24 192.168.37.7 S0/1/0

Zdroj Prefix

Podsíť 10.3.3.0/24

Směrovač

iBGP do PE1

Zdroj Prefix

CE-B2

Podsíť 10.3.3.0/24

Odch. rozhraní

RIP 10.3.3.0/24 192.168.38.8 S0/1/1

Další přeskok

Odch. rozhraní

3333

odebrat

192.168.37.7 S0/1/0

4444

odebrat

192.168.38.8 S0/1/1

2

Obrázek 19.19: Vytvoření položky LFIB s návěštím sítě VPN ve výstupním směrovači PE

A jaké kroky jsou na tomto obrázku naznačeny: 1. Jakmile směrovač PE2 přidá do tabulky VRF-A cestu do prefixu 10.3.3.0/24, alokuje lokální návěští (3333), které k této cestě přiřadí. Poté uloží lokální návěští i odpoví-

K1613.indd 687

24.2.2009 12:43

688


dající další přeskok a odchozí rozhraní, jež převezme z cesty pro 10.3.3.0/24 v tabulce VRF-A, do báze LIB (není na obrázku) a LFIB. 2. Stejnou logiku jako v kroku 1 opakuje PE2 pro každou cestu v každé tabulce VRF, včetně cesty z tabulky VRF-B, označené v kroku 2. Jakmile se dozví cestu do sítě 10.3.3.0/24 z tabulky VRF-B, alokuje pro ni jinou hodnotu návěští (4444), k němu přiřadí IP adresu dalšího přeskoku a odchozí rozhraní této cesty, a všechny informace společně přidá do nové položky LFIB. 3. Při redistribuci cest do protokolu BGP přidává PE2 lokální návěští do položek tabulky BGP, jež odpovídají jednotlivým cestám. 4. Nakonec PE2 protokolem iBGP oznámí cesty směrovači PE1, přičemž aktualizace BGP bude obsahovat návěští VPN. Výsledkem prvních dvou kroků na obrázku je, že pokud nyní PE2 přijme paket s návěštím a zjistí v něm hodnotu 3333, dokáže jej správně odeslat do směrovače CE-A2. Přijatý paket s návěštím 4444 umí podobně odeslat do směrovače CE-B2.

Poznámka Kroky 3 a 4 na obrázku 19.19 nemají nic společného se zasíláním paketů ze směrovače PE2; budeme se na ně nicméně odvolávat v dalším textu kapitoly.

Vytvoření položek LFIB pro zasílání paketů na výstupní směrovač PE Vnější návěští definuje přepínanou cestu LSP od vstupního směrovače PE po výstupní PE. Přesněji definuje cestu LSP, po níž se budou zasílat pakety na adresu dalšího přeskoku, oznámenou v aktualizacích BGP. V kostce můžeme říci, že vstupní PE doplní vnější návěští a s ním zadá jádru sítě MPLS požadavek: „Doruč tento paket odchozímu směrovači PE, který oznámil tuto konkrétní adresu dalšího přeskoku podle BGP.“ Sítě MPLS VPN zjišťují z protokolů IGP a LDP cesty a návěští, zejména pak zapisované hodnoty vnějších návěští. Aby nám nyní všechno lépe zapadlo, bude dobré se podívat na celý proces řídicí roviny související s cestou LSP pro vnější návěští, především od kroku 4 dále: 1. Směrovač PE, který bude pro tuto konkrétní cestu výstupním směrovačem PE, zjistí od nějakého CE cesty. 2. Protokolem iBGP oznámí výstupní PE tyto cesty vstupnímu PE. 3. Ve zjištěných cestách iBGP je uvedena jistá IP adresa dalšího přeskoku. 4. Aby sítě MPLS VPN mohly fungovat, musí směrovače PE a P oznámit cestu pro dosažení adresy dalšího přeskoku podle BGP. 5. Další podmínkou činnosti sítí MPLS VPN je, aby směrovače PE a P oznámily protokolem LDP návěští cest pro dosažení adresy dalšího přeskoku podle BGP. 6. Každý ze směrovačů P a PE přidá do své LFIB svou část celé cesty LSP a tím podpoří možnost odesílání paketů ze vstupního směrovače PE do výstupního PE.

K1613.indd 688

24.2.2009 12:43

689

Na obrázku 19.19 jsme tak například viděli, jak PE2 oznamuje směrovači PE1 dvě cesty, obě s IP adresou dalšího přeskoku podle BGP 3.3.3.3. Aby mohla síť MPLS fungovat, musí nyní všechny směrovače PE a P oznámit cestu IGP pro dosažení adresy 3.3.3.3, přičemž návěští oznamují v protokolu LDP; poté je možné zasílat pakety formou přepínání podle návěští až do výstupního PE. Základní proces je znázorněn na obrázku 19.20; uvědomte si ale, že tato část procesu funguje úplně stejně jako jednoduché procesy IGP a LDP pro jednosměrové zasílání IP, které jsme viděli v první polovině této kapitoly.



P1 LFIB

4

Vstupní návěští Akce

1111

Výstupní návěští Odch. rozhraní

vyměnit 2222

S0/1/0

PE2 LFIB Vstupní návěští Akce

2222

Odch. rozhraní

odebrat Loop0

2 5

Směrovač

LDP: 3.3.3.3/32, návěští 1111

3

S0/1/0

LDP: 3.3.3.3/32, návěští 2222

P1

1

Alokuj lokální návěští (2222) pro cestu 3.3.3.3/32

S0/0/1

Směrovač

PE1

PE2

Směrovač

S0/1/1 LDP: 3 3.3.3.3/32, návěští 2222

5

LDP: 3.3.3.3/32, návěští 5555

Loopback0: 3.3.3.3/32

P2 Směrovač

P2 LFIB

4

Vstupní návěští Akce

5555

Výstupní návěští Odch. rozhraní

vyměnit 2222

S0/1/1

Obrázek 19.20: Vytvoření položek LFIB pro dosažení dalšího přeskoku BGP výstupního směrovače PE

Kroky na obrázku, rozebrané na následujících řádcích, se týkají především položek LFIB pro prefix 3.3.3.3/32, který se shoduje s adresou dalšího přeskoku směrovače PE2 podle BGP. Poznamenejme, že na obrázku nejsou zachycena úplně všechna oznámení LDP, ale jen ta, která potřebujeme pro vysvětlení příkladu: 1. Směrovač PE2 se dozví cestu do prefixu 3.3.3.3/32 a alokuje pro ni lokální návěští 2222. 2. Nyní PE2 aktualizuje svou LFIB pro lokální návěští, u něhož si zapíše akci odebrání. 3. Jako obvykle oznámí PE2 svým sousedům LDP vazbu návěští, která sdružuje prefix 3.3.3.3/32 s návěštím 2222. 4. Oba směrovače P1 a P2 se protokolem IGP nezávisle dozví o prefixu 3.3.3.3/32, alokují lokální návěští (1111 na P1 a 5555 na P2) a aktualizují si svoje LFIB. 5. Nakonec i P1 a P2 oznámí svým partnerům vazbu prefixu 3.3.3.3/32 spolu s příslušným lokálním návěštím.

K1613.indd 689

24.2.2009 12:43

690


Na obrázku 19.18 byly uvedeny položky bází FIB a LFIB, potřebné pro zaslání paketu ze směrovače CE-A1 do CE-A2, konkrétně do podsítě 10.3.3.0/24; obrázky 19.19 a 19.20 nám pak v doprovodném textu vysvětlily, jak byly všechny tyto položky LFIB vytvořeny. Dále se podíváme na položku FIB, kterou je potřeba vytvořit ve směrovači PE1.

Vytvoření položek VRF FIB pro vstupní směrovač PE V poslední části analýzy datové roviny se zaměříme na vstupní směrovač PE. Ten při zpracování příchozího paketu bez návěští postupuje podle následující logiky: 1. Zpracuje příchozí paket podle tabulky VRF přiřazené k příchozímu rozhraní (staticky konfigurovanému).

Klíčové téma

2. Odešle paket podle FIB této tabulky VRF. V položce FIB musí být pro podporu sítí MPLS VPN dvě návěští: jednak vnější návěští, které identifikuje cestu LSP, po níž je možné dosáhnout výstupní směrovač PE, jednak vnitřní návěští, které identifikuje položku LFIB obsahující správné odchozí rozhraní výstupního PE. I když už je to možná v tomto okamžiku všem jasné, zopakujeme si pro úplnost, jak vstupní PE zjišťují hodnoty vnějšího a vnitřního návěští:

Vnější návěští je odvozeno od položky LIB, konkrétně od položky LIB pro ten prefix, který se shoduje s IP adresou dalšího přeskoku zjištěnou z protokolu BGP – nikoli tedy s cílovou IP adresou paketu. Vnitřní návěští je odvozeno od položky v tabulce BGP pro cestu v tabulce VRF, která se shoduje s cílovou adresou paketu.

Klíčové téma

Tabulka BGP NLRI

RT

Návěští Další přeskok

1:111:10.3.3.0/24 1:100

3333

3.3.3.3

2:222:10.3.3.0/24 2:200

4444

3.3.3.3

1 3

VRF-A Směrovací tabulka Zdroj

Prefix

BGP

10.3.3.0/24 3.3.3.3

Další přeskok

2 FIB Prefix

Odch. rozhraní Další přeskok

10.3.3.0/24 S0/0/1

3.3.3.3


1111, 3333

5 LIB

4

Vnější:

Vnitřní:

1111

3333

IP

Směrovač P1 Prefix


Odch. rozhraní

3.3.3.3/32

1111

S0/0/1

5555

S0/1/1 S0/0/1

Směrovač PE1

Obrázek 19.21: Vytvoření položky FIB vstupního PE1 pro tabulku VRF-A

K1613.indd 690

24.2.2009 12:43

691

Obrázek 19.21 bude posledním z našeho průběžného příkladu a ukáže nám proces, v němž směrovač PE1 přidá do tabulky VRF-A správnou položku FIB pro prefix 10.3.3.0/24. Tento obrázek zachycuje okamžik, kdy PE1 zjistil veškeré informace z protokolů BGP a LDP a kdy je připraven k naplnění směrovací tabulky VRF a báze FIB. Na směrovači PE1 je v tabulce BGP zapsáno návěští VPN, zatímco v bázi LIB má dvě návěští zjištěná od svých dvou sousedů LDP (jsou to směrovače P1 a P2, a zjistil od nich návěští 1111 a 5555). Nejlepší cesta v PE1, která se shoduje s dalším přeskokem BGP 3.3.3.3, ukazuje náhodou na P1, nikoli na P2, a proto se v tomto příkladu použije návěští 1111 zjištěné od P1.



Vysvětleme si jako obvykle jednotlivé kroky naznačené na obrázku: 1. Směrovač PE1 redistribuuje cestu z protokolu BGP do směrovací tabulky VRF-A (podle importního určení RT). 2. Poté PE1 vytvoří položku VRF-A FIB pro cestu, kterou právě přidal do směrovací tabulky VRF-A. 3. Tato nová položka FIB musí obsahovat návěští VPN, kterou PE1 vyhledá v odpovídající položce tabulky BGP. 4. Dále musí tato nová položka FIB obsahovat vnější návěští, podle něhož je možné dosáhnout IP adresu dalšího přeskoku BGP (3.3.3.3), a proto se PE1 podívá do báze LIB a najde zde nejlepší položku, která odpovídá adrese 3.3.3.3, a převezme z ní návěští (1111). 5. Nakonec vstupní směrovač PE1 vloží hlavičku MPLS včetně skupiny dvou návěští. V tomto okamžiku jakmile PE1 přijme paket na rozhraní přiřazeném tabulce VRF-A, podívá se do báze VRF-A FIB. Pokud je paket určený pro cílovou adresu v prefixu 10.3.3.0/24, nalezne shodnou položku podle obrázku, a poté paket odešle po rozhraní S0/0/1 s návěštími 1111 a 3333.

Mechanismus PHP – odebrání v předposledním přeskoku Činnost datové roviny MPLS VPN je v pořádku, ale procesy na výstupním směrovači PE mohou být docela neefektivní. Příčinou je, že výstupní PE musí po přijetí paketu se dvěma návěštími provést dvojí hledání v bázi LFIB. Na obrázku 19.22 se tak vrátíme k průběžnému příkladu, na němž si zasílání v datové rovině ilustrujeme v celé kapitole, a shrneme logiku zpracování na jednotlivých směrovačích. Všimněte si, že výstupní směrovač PE2 musí skutečně pracovat se dvěma položkami LFIB. 1 Podle VRF-A FIB zapiš do paketu návěští 1111 a 3333.

1111 3333

IP

PE1 Směrovač

3

2 Podle LFIB proveď: 1) Odeber návěští 2222 2) Odeber návěští 3333 a odešli paket přes rozhraní S0/1/0.

Podle LFIB proveď výměnu návěští 1111 za 2222 a odešli paket přes rozhraní S0/1/0.

S0/0/1

2222 3333

IP

P1 Směrovač

S0/1/0

IP

IP

PE2

S0/0/1

Směrovač

Obrázek 19.22: Výstupní směrovač PE musí provádět dvojí hledání v LFIB

K1613.indd 691

24.2.2009 12:43

692


Této práci navíc, kterou by musel provádět poslední směrovač LSR, se síť MPLS umí vyhnout pomocí zvláštní funkce, jíž se říká odebrání v předposledním přeskoku (penultimate hop popping, PHP). Předposlední přeskok je samozřejmě druhý LSR od konce, který zpracovává paket s návěštím. V mechanismu PHP se vnější návěští odstraní již v předposledním přeskoku, takže poslední směrovač LSR, který je zároveň posledním přeskokem, již dostane paket, v němž je zapsáno pouze návěští VPN. A protože návěští je jen jedno, stačí výstupnímu směrovači PE vyhledat v LFIB jen jedinou položku. Upravený tok datové roviny se zapnutým PHP je zachycen na obrázku 19.23. 1

Klíčové téma

1111 3333

IP

Směrovač PE1

2

3

Podle LFIB odeber návěští 1111 a odešli paket přes rozhraní S0/1/0.

Podle VRF-A FIB zapiš do paketu návěští 1111 a 3333.

S0/0/1

Podle LFIB odeber návěští 3333 a odešli paket přes rozhraní S0/1/0.

3333

IP

Směrovač P1

S0/1/0

Předposlední přeskok MPLS

IP

IP

Směrovač PE2

S0/0/1

Poslední přeskok MPLS

Obrázek 19.23: Díky PHP provádí výstupní směrovač PE jediné hledání v LFIB

Ostatní aplikace protokolu MPLS V této poslední a krátké části kapitoly si stručně představíme protokoly, které používá několik dalších aplikací MPLS. Proto si zde vysvětlíme pojem takzvaných tříd ekvivalence Forwarding Equivalence Class (FEC) a řekneme si, jak tyto třídy využívají různé aplikace MPLS. Klíčové téma

Všechno podstatné k pojmu FEC jsme už v kapitole fakticky probrali. Přesto je důležité pojem ještě jednou zdůraznit a vysvětlit, protože si s ním budeme moci lépe porovnat různé aplikace MPLS. Obecně řečeno je třídou FEC množina paketů, kterým se v jednom určitém směrovači LSR dostává stejného zacházení při zasílání. U prostého jednosměrového zasílání MPLS IP je tak každý prefix IPv4 samostatnou třídou FEC. V sítích MPLS VPN je každý prefix v tabulce VRF třídou FEC – takže prefix 10.3.3.0/24 v tabulce VRF-A je jinou třídou než prefix 10.3.3.0/24 v tabulce VRF-B. Podobně při zapnutých mechanismech QoS může být jednou třídou FEC množina paketů v tabulce VRF-A, určená do cíle 10.3.3.0/24, v nichž je zapsána hodnota DSCP EF, zatímco jinou třídu budou tvořit pakety ve stejné VPN do stejné podsítě, ale s jinou hodnotou DSCP. Pro každou třídu FEC musí mít každý směrovač LSR návěští nebo zásobník návěští, která bude používat při zasílání paketů z této třídy. Protože každé třídě přiřadí jedinečné návěští nebo množinu návěští, může tak přiřadit i různé parametry zasílání jako je odchozí rozhraní a směrovač dalšího přeskoku. Jednotlivé aplikace MPLS můžeme porovnat podle informací, z nichž se stanovují třídy FEC. Pomocí aplikace řízení provozu MPLS TE (traffic engineering) se například sítě MPLS mohou rozhodnout, že některé pakety odešlou po jedné cestě LSP a jiné pakety po jiné cestě,

K1613.indd 692

24.2.2009 12:43

693

podle provozního zatížení – dokonce i když konečný cíl obou skupin paketů bude stejný. Takto může poskytovatel služeb řídit toky dat po vysokorychlostních páteřních sítích a pomocí několika alternativních cest předejít problému s přetížením nejlepší cesty, stanovené směrovacím protokolem. Pro dosažení této funkce definuje MPLS TE třídu FEC částečně podle sítí, které jsou dostupné přes definovaný tunel MPLS TE. Dále můžeme porovnávat aplikace MPLS podle protokolů řídicí roviny, z nichž zjišťují informace o návěštích. V této kapitole jsme si například vysvětlili, jak sítě MPLS VPN vyměňují informace o návěštích pomocí protokolů LDP a MP-BGP, zatímco jiné aplikace MPLS používají LDP a jiný protokol – anebo LDP nepoužívají dokonce vůbec. Nejběžnější z mnoha aplikací MPLS uvádí tabulka 19.5 a popisuje, podle jakých informací stanovuje třídy FEC a jakým protokolem řídicí roviny oznamuje vazby FEC na návěští.



Tabulka 19.5: Řídicí protokoly v různých aplikacích MPLS Aplikace

Třídy FEC

Řídicí protokol pro výměnu vazeb FEC na návěští

Jednosměrové směrování IP

Jednosměrové cesty IP v globální směrovací tabulce IP

TDP (Tag Distribution Protocol) nebo LDP (Label Distribution Protocol)

Vícesměrové směrování IP

Vícesměrové cesty v globální vícesměrové směrovací tabulce IP

Rozšíření PIM verze 2

VPN

Jednosměrové cesty IP ve směrovací tabulce příslušné k VRF

MP-BGP

Řízení provozu TE

Tunely MPLS TE (konfigurováno)

RSVP nebo CR-LDP

MPLS QoS

Směrovací tabulka IP a bajt ToS

Rozšíření protokolů TDP a LDP

Shrnutí základů Nezapomeňte si nejprve důkladně prostudovat celou část „Základní témata“ a věnujte také pozornost místům označeným ikonou „Klíčové téma“.

Pro zapamatování Podobně jako všechny písemné zkoušky Cisco CCIE pokrývá i písemná zkouška CCIE Routing and Switching široké spektrum různých témat. Tato část kapitoly uvádí proto některé pomůcky pro opakování zmíněných širších témat, probíraných v jejím textu.

Vyplňte zpaměti tabulky Příloha E, kterou najdete na CD-ROM přiloženém ke knize, obsahuje prázdné verze některých souhrnných tabulek z každé kapitoly. Tuto přílohu si vytiskněte, najděte v ní tabulky

K1613.indd 693

24.2.2009 12:43

694


z této kapitoly a vyplňte je zpaměti. Správné znění odpovědí si můžete zkontrolovat v příloze F, která je také na CD-ROM.

Doplňte definice Dále napište na papír definice následujících pojmů: Báze FIB, báze LIB, báze LFIB, jednosměrové směrování MPLS IP, MPLS VPN, LDP, TDP, cesta LSP, segment LSP, šíření MPLS TTL, lokální návěští, vzdálené návěští, vazba návěští, tabulka VRF, rozlišovač RD, určení RT, překrývající se VPN, vnitřní návěští, vnější návěští, návěští VPN, PHP, FEC, LSR, E-LSR, PE, CE, P, vstupní PE, výstupní PE. Správné odpovědi si ověříte ve slovníčku pojmů.

Zdroje dalších informací Vydavatelství Cisco Press nabízí k problematice sítí MPLS celou řadu publikací, které najdete na webové adrese http://www.ciscopress.com. Stránky s informacemi k MPLS otevřete také přes stránky http://www.cisco.com/go/mpls.

K1613.indd 694

24.2.2009 12:43

KAPITOLA 19. Přepínaný protokol MPLS

Recommend Documents