MPLS LDP na přepínané síti. L2 enkapsulace odchozích paketu, vazba na CEF. Rekonvergence v případě ztráty LDP Hello paketu.

MPLS LDP na přepínané síti. L2 enkapsulace odchozích paketu, vazba na CEF. Rekonvergence v případě ztráty LDP Hello paketu. Martin Hlozák (HLO0010), Lukáš Rygol (RYG0007) Abstrakt: Tato práce poslouží jako studijní dokument popisující teoreticky a prakticky MPLS technologii, která se opírá o podkladovou strukturu CEF a LDP protokol, který je potřebný pro přenos MPLS značek v síti. Klíčová slova: MPLS, LDP, CEF, FIB, LFIB Obsah: 1 Úvod... 2 2 Topologie sítě a minimální nároky na realizaci projektu... 2 2.1 Topologie sítě... 2 2.2 Minimální nároky pro realizaci projektu... 2 3 MPLS... 3 3.1 MPLS LDP... 3 3.1.1 Princip funkce LDP na přepínané síti... 3 4 L2 enkapsulace odchozích paketů a vazba na CEF... 5 4.1 CEF (Cisco Express Forwarding)... 5 5 Rekonvergence v případě ztráty LDP Hello paketu... 8 5.1 Realizace funkčnosti LDP rekonvergence:... 9 5.1.1 Test funkčnosti rekonvergence jedné fyzické linky... 9 5.1.2 Test funkčnosti rekonvergence agregované L3 linky (L3 Port-Channel):... 11 6 Závěr... 15 7 Použitá literatura... 15 listopad 2013 1/15

1 Úvod V této semestrální práci se budeme snažit popsat nejdříve technologii MPLS a její nejznámější LDP protokol pro výměnu MPLS značek. Dále Cisco technologii CEF, která je slouží jako pokladová struktura pro funkci MPLS. V poslední řadě je vyřešená rekonvergence v případě ztráty LDP Hello paketu. 2 Topologie sítě a minimální nároky na realizaci projektu 2.1 Topologie sítě Obr. č. 1: Topologie sítě s adresací. Topologii jsme vytvořili ze čtyř směrovačů a ty propojili podle obrázku č. 1. Pro směrovaní v celé topologii jsme využili protokol OSPF a následně povolili na každém rozhraní funkci MPLS. LDP vazbu jsme navazovali z loopbacku směrovače. Tu jsme zachytili pomocí PC3 na kterém běžel wireshark. Stejně tak jsme zachytávali odchozí MPLS pakety na ethernetu (viz. níže). 2.2 Minimální nároky pro realizaci projektu Proto, abychom zrealizovali projekt, bylo nutné využít minimálně sérii Cisco 2691 (nižší série MPLS nepodporuje). Celý projekt byl realizován na zařízeních série Cisco 2800 s Cisco IOS 15.0 v počítačové laboratoři J257. listopad 2013 2/15

3 MPLS MPLS (MultiProtocol Label Switching) je technologie se využívá především v páteřních sítích. Je označován jako Layer 2.5 Protocol nebo Layer 2+ Protocol. MPLS bylo vytvořeno jako potřeba pro unifikovaný přenos v sítích s přepojováním okruhů i paketů, ve kterých slouží k přenosu dat datagramová služba [1]. V názvu multiprotocol znamená, že může být nasazen v kombinací s jakýmkoliv protokolem síťové vrstvy (IP, IPv6, IPX) a linkové vrstvy (Ethernet, HDLC, PPP, Frame Relay, ATM). Technika MPLS je mnohem efektivnější a rychlejší, než přepínací algoritmus IP, protože směrování paketů neprobíhá pomocí cílové IP adresy v záhlaví paketu, ale podle návěští (značky) tzv. MPLS Label, která se vkládá před pakety. Místo toho aby směrovač při každém směrování paketu vyhledával příslušnou cestu ve směrovací tabulce o velikosti desetitisíc záznamů, stačí mu pro směrování nahlédnout do kratší přepínací tabulky značek. Tuto funkci můžeme přirovnat k ISO/OSI modelu, kdy dojde ke zpracování paketů na úrovní linkové vrstvy, místo klasického zpracování paketů na úrovní třetí vrstvy. Každá takováto značka má pouze lokální význam a průchodem směrovačem. Směrovač na němž je umožněna technologie MPLS se nazývá LSR (Label Switch Router). 3.1 MPLS LDP LDP (Label Distribution Protocol) je signalizační protokol, který je definován v RFC 3036 a slouží k výměně informací o přidělených značkách mezi směrovači LSR. Je definován na třetí vrstvě ISO/OSI. Směrovače LSR pomocí protokolu LDP oznamují sousedům zprávy, ve kterých jsou uvedeny prefixy a k nim odpovídající návěští. Směrovač pomocí tohoto protokolu vysílá zprávu, která říká sousednímu směrovači, že pokud bude odesílat paket na tento prefix, má použít návěští MPLS, které je uvedeno v aktualizaci LDP. LDP aktualizace je spuštěná ve chvíli, kdy se v IP směrovací tabulce objeví nový prefix sítě. 3.1.1 Princip funkce LDP na přepínané síti 1. Vyhledání sousedních LSR, na kterých je aktivní LDP K vyhledání LSR se využívají LDP Hello zprávy, které se posílají na UDP/646 a na víceměrové IP adrese 224.0.0.2, periodicky co 5sec. Každý LSR se identifikuje pomocí nejvyšší IP adresy z rozhraní loopback (pokud není tak pomocí nejvyšší aktivní IP adresa na fyzickém rozhraní). Obr. č. 2: LDP Hello paket. listopad 2013 3/15

2. Navazování a udržování spojení mezi sousedními LSR Využívá se keepalive zpráv, které se posílají na TCP s cílovým portem 646, periodicky co 30sec. Zasílaní těchto zpráv je již realizováno jednosměrově. Obr. č. 3: LDP Keepalive paket. 3. Výměna značek přiřazených jednotlivým prefixům Nejdřív se každému prefixu v ve směrovací tabulce přiřadí MPLS značka a ta je poté přenášená LDP zprávou jednosměrově na TCP s cílovým portem 646. Obr. č. 4: LDP Address Message Label - výměna MPLS značek. listopad 2013 4/15

4 L2 enkapsulace odchozích paketů a vazba na CEF Nejdříve se podíváme na princip směrování čistých IP paketů pomocí mechanizmu CEF, pak navážeme na technologii MPLS, která se opírá o podkladovou strukturu a logiku expresního zasílání CEF (Cisco Express Forwarding). 4.1 CEF (Cisco Express Forwarding) Je rozšířená L3 přepínací technologie, kterou využívají Cisco L3 zařízení. Zvyšuje rychlost přepínaní rámců, díky tomu, že se používá HW obvodu ASIC. V tomto HW obvodu se využívá FIB (Forwarding Information Base) a tabulky sousedství. FIB je někdy nazývaná jako CEF tabulka. Technologie CEF je automaticky povolená na všech Cisco L3 prvcích a každé rozhraní Cisco směrovače má tento HW obvod. Obr. č. 5: Mechanizmus CEF Z obrázku č. 5 lze vidět, že pro směrování paketů se nepoužívá kontrolní úroveň (CPU a RIB), ale všechno je řešeno v datové úrovni (hardwarem) pomocí FIB a tabulky sousedství. Tím dojde ke zrychlení přepínaní paketů, kratšímu zpoždění a vyšší propustnosti směrovače v paketech za sekundu. Princip funkce: Ze směrovací tabulky (RIB), která je umístěná v Control Plane, se vloží každý cílový prefix IP do FIB databáze. Součástí FIB databáze je definována IP adresa dalšího přeskoku a odchozí rozhraní pro každý cílový prefix. Navíc je definována tabulka přilehlosti CEF (tabulka sousedství) a v ní je uvedena IP adresa dalšího přeskoku s odchozím rozhraním a hlavička linkové vrstvy. V přepínané síti se v této tabulce přilehlosti udržuje MAC adresa dalšího přeskoku (sousední MAC adresa rozhraní). Ta se získává pomocí ARP cache, díky ARP protokolu. Pro každý paket, směrovač vyhledá odpovídající položku FIB, poté najde MAC adresu dalšího přeskoku z tabulky sousedství, na kterou se položka FIB odkazuje, a nakonec podle ní odešle paket. To můžeme vidět na obrázku č. 6. listopad 2013 5/15

Obr. č. 6: Směrování IP paketu na základě technologie CEF [2]. Výše uvedený příklad se opíral o směrování čistých IP paketů. Nicméně při zasílání MPLS paketů, využívá směrovač LSR navíc informační databázi MPLS LFIB (Label Forwarding Information Base), která slouží pro směrování příchozích paketů s MPLS návěštími. LFIB je opět databáze, která je umístěná v datové úrovní jako FIB databáze. V obou jsou potřebné informace k návěštím a také údaje o odchozím rozhraní a o dalším přeskoku. Obr. č. 7: Princip směrování IP paketů a MPLS paketů na základě technologie CEF [4]. Prakticky pro každý IP prefix z FIB databáze si každý LSR zvolí hodnotu značky (local binding) a tu pak pošle pomocí LDP sousedním LSR (remote binding). Každý LSR uchovává své lokálně vygenerované značky i značky přijaté od sousedů v tzv. tabulce LIB (Label Information Base) [3]. listopad 2013 6/15

Protože LSR může mít v LIB více značek od různých sousedních LSR pro stejný prefix, vybere si pro značkování paketů tu značku, která je přijata od LSR, který je podle směrovací tabulky "next hop" směrovačem pro příslušný prefix. Tuto značku si daný LSR uloží do tabulky LFIB (Label Forwarding Information Base) jako odchozí hodnotu. Jako předpokládaná příchozí hodnota značky se použije lokálně vybraná hodnota značky.[3] Podle databáze LFIB dochází k přepínaní MPLS paketů. Podobně jako u FIB, databáze LFIB se odkazuje na svou tabulku sousedství, kde je uvedena IP adresa dalšího přeskoku s odchozím rozhraním, přiřazené MPLS návěští, nebo MAC adresa dalšího přeskoku. Princip přepínaní MPLS návěští s využitím FIB a LFIB databázi, můžeme vidět níže na obrázku č. 8. Obr. č. 8: Princip fungování jednotlivých databází [2]. Průběh zpracování paketu v jednotlivých databázích: 1. Hraniční směrovač R1 příjme IP paket bez návěští s cílovou IP adresou 192.168.1.1 a porovná ho s databázi FIB. Podle této databáze zjistí, že se IP adresa 192.168.1.1 nejvíce shoduje z prefixem 192.168.1.1 v tabulce. Než se paket vyšle na rozhraní Fa0/0 přidá se před paket návěští 25 (push). Obr. č. 9: MPLS zapouzdření mezi R1 a R2. 2. Směrovač R2 obdrží paket s návěštím 25 a porovnává ho v databázi LFIB, kde zjistí, že návěští 25 má vyměnit za návěští 34 (swap) a odeslat ho na rozhraní Fa0/0. Obr. č. 10: MPLS zapouzdření mezi R2 a R3. 3. Směrovač R3 příjme paket s návěštím 34. Ve směrovací databázi LFIB je uvedena akce pro odebrání návěští 34 (pop). Proto dojde k odebrání návěští a paket je již směrován bez návěští na rozhraní Fa0/1. listopad 2013 7/15

Obr. č. 11: MPLS zapouzdření mezi R3 a R4. Jak již bylo výše zmíněno, na Cisco zařízeních technologie MPLS výhradně potřebuje ke své funkci, využívat technologii CEF. Pokud vypneme funkci CEF příkazem no ip cef, vypneme také podporu CEF FIB a MPLS LFIB. 5 Rekonvergence v případě ztráty LDP Hello paketu Díky ztracení několika LDP Hello paketů, dojde k vymazání všech MPLS značek na LSR směrovači. Jak již bylo zmíněno, k vyhledání LSR se využívají LDP Hello zprávy (Link Hello), které se posílají na UDP/646 a na vícesměrovou IP adresu 224.0.0.2, periodicky co 5sec. Jelikož LDP využívá UDP protokol nezaručuje se, že se LDP Hello paket neztratí. Pokud by došlo ke ztracení LDP Hello paketu, je možné explicitně definovat na Cisco směrovači navíc zasílání cílených(targeted), neboli podpůrných LDP Hello paketů. Základní vlastnosti cílového LDP Hello Paketu: Je zasílán jednosměrově sousednímu směrovači. Zasílá se periodicky co 15 sec. Holdtime je nastavený na 90 sec. Zdrojová IP adresa a cílová IP adresa je definována podle LSR-ID (LSR-ID je známy z vícesměrových LDP Hello paketů) listopad 2013 8/15

5.1 Realizace funkčnosti LDP rekonvergence: 5.1.1 Test funkčnosti rekonvergence jedné fyzické linky Obr. č. 12: Topologie sítě pro testování rekonvergenci LDP spojení. R1(config)# mpls ldp session protection duration infinite R2(config)# mpls ldp session protection duration infinite Řetězec infinite v příkazu výše, chrání LDP relaci, poté co se rozpadne Link discovery mezi sousedními směrovači LSR. Obr. č. 13: Zachycení cíleného LDP Hello paketu, který posílá R1 směrovač. Proto, abychom si ověřili funkčnost rekonvergence, provedeme filtraci vícesměrových LDP Hello zpráv, díky ACL na obou směrovačích: R1(config)# access-list 101 deny ip host 10.0.0.2 host 224.0.0.2 R1(config)# access-list 101 permit ip any any R1(config)# interface FastEthernet0/1 R1(config-if)# ip access-group 101 in V podstatě jsme touto konfiguraci řekli směrovači R1, že pokud příjme paket ze zdrojovou IP adresou 10.0.0.2 (tj. IP adresa sousedního směrovače R1) a cílovou vícesměrovou IP adresou 224.0.0.2 na rozhraní FA0/1, zahodí se. Všechen ostatní provoz je povolen. listopad 2013 9/15

R2(config)# access-list 101 deny ip host 10.0.0.1 host 224.0.0.2 R2(config)# access-list 101 permit ip any any R2(config)# interface FastEthernet0/1 R2(config-if)# ip access-group 101 in Podobně jsme nakonfigurovali ACL na směrovači R2, který říká, že pokud příjme paket ze zdrojovou IP adresou 10.0.0.1 (tj. IP adresa sousedního směrovače R1) a cílovou vícesměrovou IP adresou 224.0.0.2 na rozhraní FA0/1, zahodí se. Všechen ostatní provoz je povolen. Pozn. Po konfiguraci ACL jsme si mohli všimnout z výpisu obou směrovačů, že byla inicializována podpůrná LDP relace, poté co vypršel patnáctisekundový LDP Hold-Time (viz. níže). R1# *Dec 19 20:22:11.491: %LDP-5-SP: 2.2.2.2:0: session hold up initiated R2# *Dec 19 20:30:53.758: %LDP-5-SP: 1.1.1.1:0: session hold up initiated Ověření funkčnosti ACL: R1#debug mpls ldp transport events interface fa0/1 *Dec 19 20:10:36.931: ldp: Rcvd ldp dir hello to 1.1.1.1 from 2.2.2.2 (2.2.2.2:0); FastEthernet0/1; opt 0xF *Dec 19 20:10:40.379: ldp: Send ldp hello; FastEthernet0/1, src/dst 10.0.0.1/224.0.0.2, inst_id 0 *Dec 19 20:10:44.539: ldp: Send ldp hello; FastEthernet0/1, src/dst 10.0.0.1/224.0.0.2, inst_id 0 *Dec 19 20:10:46.827: ldp: Rcvd ldp dir hello to 1.1.1.1 from 2.2.2.2 (2.2.2.2:0); FastEthernet0/1; opt 0xF R2#debug mpls ldp transport events interface fa0/1 *Dec 19 20:17:14.731: ldp: Rcvd ldp dir hello to 2.2.2.2 from 1.1.1.1 (1.1.1.1:0); FastEthernet0/1; opt 0xF *Dec 19 20:17:15.447: ldp: Send ldp hello; FastEthernet0/1, src/dst 10.0.0.2/224.0.0.2, inst_id 0 *Dec 19 20:17:20.107: ldp: Send ldp hello; FastEthernet0/1, src/dst 10.0.0.2/224.0.0.2, inst_id 0 *Dec 19 20:17:23.451: ldp: Rcvd ldp dir hello to 2.2.2.2 from 1.1.1.1 (1.1.1.1:0); FastEthernet0/1; opt 0xF Příchozí vícesměrové LDP Hello pakety jsou nyní filtrovány na obou směrovačích. Tím, že máme povolené příkazem výše podpůrné jednosměrové LDP Hello pakety, dojde k rekonvergenci LDP relace. Díky tomu, že došlo k rekonvergenci LDP relace, LSR směrovače by si stále měli udržovat pro každou podsíť, MPLS značku (remote binding) od sousedních směrovačů: R1#sh mpls ldp bindings lib entry: 1.1.1.1/32, rev 2 remote binding: lsr: 2.2.2.2:0, label: 16 lib entry: 2.2.2.2/32, rev 6 local binding: label: 16 remote binding: lsr: 2.2.2.2:0, label: imp-null lib entry: 10.0.0.0/30, rev 4 remote binding: lsr: 2.2.2.2:0, label: imp-null listopad 2013 10/15

R2#sh mpls ldp bindings lib entry: 1.1.1.1/32, rev 6 local binding: label: 16 remote binding: lsr: 1.1.1.1:0, label: imp-null lib entry: 2.2.2.2/32, rev 2 remote binding: lsr: 1.1.1.1:0, label: 16 lib entry: 10.0.0.0/30, rev 4 remote binding: lsr: 1.1.1.1:0, label: imp-null Z výpisu výše vidíme, že podpůrná LDP relace stále udržuje MPLS značky v databázi LIB. Chceme-li uvést původní LDP relaci do provozu, stačí na rozhraní odebrat příkaz ip access-group 101 in. V tomto případě směrovač automaticky vypíše obnovení původní LDP relace: R1# *Dec 19 20:21:47.187: %LDP-5-SP: 2.2.2.2:0: session recovery succeeded R2# *Dec 19 20:30:33.970: %LDP-5-SP: 1.1.1.1:0: session recovery succeeded 5.1.2 Test funkčnosti rekonvergence agregované L3 linky (L3 Port-Channel): Obr. č. 14: Topologie sítě pro testování rekonvergence LDP spojení agregované L3 linky. Opět využijeme příkazu, který chrání LDP relaci, poté co se rozpadne Link discovery mezi sousedními směrovači LSR: R1(config)# mpls ldp session protection duration infinite R2(config)# mpls ldp session protection duration infinite Definice rozhraní, která použijeme k agregaci L3 linky: R1(config)# interface FastEthernet0/1 R1(config-if)# channel-group 1 R1(config)# interface FastEthernet0/0 R1(config-if)# channel-group 1 listopad 2013 11/15

Konfigurace rozhraní agregované L3 linky: R1(config)# interface Port-channel 1 R1(config-if)# ip address 10.0.0.1 255.255.255.252 R1(config-if)# ip ospf 1 area 0 R1(config-if)# mpls ip Podobnou konfiguraci provedeme na směrovači R2: R2(config)# interface FastEthernet0/1 R2(config-if)# channel-group 1 R2(config)# interface FastEthernet0/0 R2(config-if)# channel-group 1 R2(config)# interface Port-channel 1 R2(config-if)# ip address 10.0.0.1 255.255.255.252 R2(config-if)# ip ospf 1 area 0 R2(config-if)# mpls ip Při konfiguraci bylo zjištěno, že agregovaná L3 linka si ve skutečnosti rozděluje různé LDP pakety mezi těmito dvěma fyzickými linkami, což můžeme vidět z programu Wireshark: Obr. č. 15: Zachycení vícesměrových LDP Hello paketů na fyzické rozhraní FA0/1. Obr. č. 16: Zachycení cílených LDP Hello paketů a LDP keepalive zpráv na fyzickém rozhraní FA0/0. Ve skutečnosti by se mohlo zdát, že pokud se porouchá linka FA0/0, cílené LDP Hello pakety a LDP keepalive zprávy se přestanou odesílat. Nicméně pokud jsme tento problém nasimulovali, výpis níže ukazuje, ve wiresharku že všechny posílané LDP zprávy převezme linka FA0/1. listopad 2013 12/15

Obr. č. 17: Zachycení cílených LDP Hello paketů a LDP keepalive zpráv na fyzickém rozhraní FA0/0. Stejná situace nastane pokud dojde k poruše linky FA0/0 - linka FA0/1 převezme plnou odpovědnost linky FA0/0. Po konfiguraci bychom měli pro každou podsíť dostat od sousedního směrovače MPLS značku (remote binding): R1#sh mpls ldp bindings lib entry: 1.1.1.1/32, rev 2 remote binding: lsr: 2.2.2.2:0, label: 16 lib entry: 2.2.2.2/32, rev 6 local binding: label: 16 remote binding: lsr: 2.2.2.2:0, label: imp-null lib entry: 10.0.0.0/30, rev 4 remote binding: lsr: 2.2.2.2:0, label: imp-null R2#sh mpls ldp bindings lib entry: 1.1.1.1/32, rev 6 local binding: label: 16 remote binding: lsr: 1.1.1.1:0, label: imp-null lib entry: 2.2.2.2/32, rev 2 remote binding: lsr: 1.1.1.1:0, label: 16 lib entry: 10.0.0.0/30, rev 4 remote binding: lsr: 1.1.1.1:0, label: imp-null Stejným způsobem si ověříme funkčnost rekonvergence s použitím agregované L3 linky, provedeme filtraci vícesměrových LDP Hello zpráv, díky ACL na obou směrovačích: R1(config)# access-list 101 deny ip host 10.0.0.2 host 224.0.0.2 R1(config)# access-list 101 permit ip any any R1(config)# interface Port-channel 1 R1(config-if)# ip access-group 101 in R2(config)# access-list 101 deny ip host 10.0.0.1 host 224.0.0.2 R2(config)# access-list 101 permit ip any any R2(config)# interface Port-channel 1 R2(config-if)# ip access-group 101 in listopad 2013 13/15

Opět jsme si mohli všimnout z výpisu obou směrovačů, že byla inicializována podpůrná LDP relace, poté co vypršel patnáctisekundový LDP Hold-Time (viz. níže). R1# *Dec 19 22:32:12.955: %LDP-5-SP: 2.2.2.2:0: session hold up initiated R2# *Dec 19 22:33:06.191: %LDP-5-SP: 1.1.1.1:0: session hold up initiated Ověření funkčnosti ACL: R1#debug mpls ldp transport events interface port-channel 1 *Dec 19 22:30:55.951: ldp: Rcvd ldp dir hello to 1.1.1.1 from 2.2.2.2 (2.2.2.2:0); Port-channel1; opt 0xF *Dec 19 22:31:00.023: ldp: Send ldp hello; Port-channel1, src/dst 10.0.0.1/224.0.0.2, inst_id 0 *Dec 19 22:31:04.463: ldp: Rcvd ldp dir hello to 1.1.1.1 from 2.2.2.2 (2.2.2.2:0); Port-channel1; opt 0xF R2#debug mpls ldp transport events interface port-channel 1 *Dec 19 22:40:47.703: ldp: Rcvd ldp dir hello to 2.2.2.2 from 1.1.1.1 (1.1.1.1:0); Port-channel1; *Dec 19 22:40:56.775: ldp: Send ldp hello; Port-channel1, src/dst 10.0.0.2/224.0.0.2, inst_id 0 *Dec 19 22:40:57.263: ldp: Rcvd ldp dir hello to 2.2.2.2 from 1.1.1.1 (1.1.1.1:0); Port-channel1; opt 0xF Příchozí vícesměrové LDP Hello pakety jsou nyní filtrovány na obou směrovačích. Tím, že máme povolené příkazem výše podpůrné jednosměrové LDP Hello pakety, dojde k rekonvergenci LDP relace. Jak lze vidět z výpisu, oba LSR směrovače nepřijímají vícesměrové LDP Hello pakety. Z výpisu níže vidíme, že podpůrná relace LDP stále udržuje MPLS značky sousedního směrovače v LIB databázi: R1#sh mpls ldp bindings lib entry: 1.1.1.1/32, rev 2 remote binding: lsr: 2.2.2.2:0, label: 16 lib entry: 2.2.2.2/32, rev 6 local binding: label: 16 remote binding: lsr: 2.2.2.2:0, label: imp-null lib entry: 10.0.0.0/30, rev 4 remote binding: lsr: 2.2.2.2:0, label: imp-null R2#sh mpls ldp bindings lib entry: 1.1.1.1/32, rev 6 local binding: label: 16 remote binding: lsr: 1.1.1.1:0, label: imp-null lib entry: 2.2.2.2/32, rev 2 remote binding: lsr: 1.1.1.1:0, label: 16 lib entry: 10.0.0.0/30, rev 4 remote binding: lsr: 1.1.1.1:0, label: imp-null listopad 2013 14/15

Chceme-li uvést původní LDP relaci do provozu, stačí stejným způsobem na rozhraní, odebrat příkaz ip access-group 101 in. V tomto případě směrovač automaticky vypíše obnovení původní LDP relace: R1# *Dec 19 22:59:06.723: %LDP-5-SP: 2.2.2.2:0: session recovery succeeded R2# *Dec 19 22:58:53.155: %LDP-5-SP: 1.1.1.1:0: session recovery succeeded Pokud by bylo potřeba, je možné nastavit čas (v sekundách) periodického zasílání cílených LDP Hello zpráv pomocí příkazu: R1(config)# mpls ldp discovery targeted-hello interval 2 Stejně tak je možné definovat čas (v sekundách) vypršení (Hold-Timer) pro cílené LDP Hello zprávy: R1(config)# mpls ldp discovery targeted-hello holdtime 10 6 Závěr Cíl našeho projektu spočíval popsat funkci protokolu LDP, který využívá technologie MPLS k výměně MPLS značek. Tuto problematiku jsme zpracovali nejen teoreticky, ale i prakticky, což dokládají výpis z programu Wireshark. Předtím, než jsme si ukázali, jak je takovýto paket směrován MPLS síti, bylo nutné vědět, že toto zapouzdření probíhá jen díky mechanizmu CEF, o který se technologie MPLS opírá. Rekonvergence v případě ztráty LDP Hello paketů byla rovněž vyřešena a prakticky ukázána, což dokládají ladící příkazy (debug) a výpis z jednotlivých LIB databází LSR směrovačů. 7 Použitá literatura [1] PETŘÍK, Michal. Technologie MPLS. Https://dsn.felk.cvut.cz [online]. 26.11.2007 [cit. 2013-06- 19]. Dostupné z: https://dsn.felk.cvut.cz/wiki/_media/vyuka/cviceni/x36mti/petrim2-doc.pdf [2] Přepínaný protokol MPLS. Knihy.cpress.cz [online]. 10.3.2009 [cit. 2013-06-19]. Dostupné z: knihy.cpress.cz/?p=actions&action=download/file&value=files&id=96963 [3] MACHNÍK, Petr. Technologie MPLS. Http://moodle.kat440.vsb.cz/ [online]. 2.10.2012 [cit. 2013-06-19]. Dostupné z: http://moodle.kat440.vsb.cz/pluginfile.php/4426/mod_resource/content/3/sps_121002_kap itola1.pdf [4] MPLS Control and Data Plane Components. Http://mpls-configuration-on-cisco-ios-soft ware.org.ua [online]. 2005 [cit. 2013-11-24]. Dostupné z: http://mpls-configuration-on-cisco-iossoftware.org.ua/1587051990/ch01lev1sec4.html listopad 2013 15/15