Použití RSVP TE pro sestavování Label Switch Path u technologi MPLS

Transkript

1 Použití RSVP TE pro sestavování Label Switch Path u technologi MPLS Marek Malysz Abstrakt: Cílem práce je prozkoumat funkci signalizačního protokolu RSVP, především jeho rozšíření, které se používá při sestavování explicitních směrovacích cest v MPLS sítích. Jsou zde popsány i základní operace MPLS TE, kterým tento protokol slouží. Klíčová slova: MPLS, traffic engineering, RSVP, LSP, fast reroute 1 Úvod MPLS Traffic Engineering Rozšíření IGP protokolů Výpočet cest Signalizace cest Resource Reservation Protocol RSVP TE Směrování provozu Fast Reroute (FRR) Rozšíření RSVP pro podporu FRR Zachycená komunikace Zpráva Path Zpráva Resv FRR Konfigurace LSP na Cisco směrovačích Postup vytvoření LSP Explicitní cesta Fast Reroute Závěr Zdroje Příloha A: Konfigurace FRR...10 prosinec /12

2 1 Úvod Abychom ve své síti zaručili dostupnost a odolnost proti výpadkům, navrhujeme sítě s redundantními spoji. Nad touto topologii pracuje interní směrovací protokol, který informuje směrovače o nejvýhodnějších cestách. Takto vyhodnocené cesty se snadno zahltí, pokud nedisponují požadovaným přenosovým pásmem, zatímco alternativní zůstanou nevyužité. Pro zmírnění dopadu zahazování paketů na ucpané cestě lze na vstupu do sítě aplikovat tzv. policy routing. V technologii MPLS problematiku řeší rozšíření zvané řízení provozu (Traffic Engineering TE). O technologii MPLS (Multi Protocol Label Switching), která po vzoru ATM přepíná pakety podle značek, víme, že má za úkol urychlit rozhodování směrovačů a z názvu lze také vyčíst, že vytváří vrstvu umožnující transportovat obecně více síťových protokolů. Vnitřní směrovače v MPLS síti budují svou přepínací tabulku na základě dostupných síťových prefixů v síti, k vzájemné výměně značek pak slouží protokoly jako jsou: LDP (Label Distribution Protocol), BGPv4, RSVP TE a další. Značky obecně mohou korespondovat i s jinými parametry cesty jako např. QoS. Na vstupu do MPLS sítě se paketu podle určitých pravidel přiřadí značka, další uzly v síti se už rozhodují výhradně podle této značky, kterou mohou pozměnit nebo na výstupu odstranit. MPLS technologie navíc umožňuje stohovat hlavičky se značkami za sebe, čehož se využívá např. v MPLS VPN. 2 MPLS Traffic Engineering Traffic Engineering lze taky chápat jako planování efektivního využití provozu. MPLS TE přichází s mechanizmy, jak vhodně rozložit zátěž a v důsledku předcházet zahlcení a ztrátám paketů. MPLS TE nám umožňuje směrovat provoz přes předem definované uzly v síti. Směrovače zahrnuté v MPLS síti nazýváme LSR Label Switching Router a cesty, kterými přenášíme data LSP Label Switchd Path. Dále rozšiřuje možnosti řízení provozu o směrování se zohledněním určitých omezení (constraint based routing, CBR). Podporuje taky preempci mezi LSP s různou prioritou. K signalizaci těchto cest lze využít rozšíření RSVP protokolu nebo nebo protokolu CR LDP. Následující kapitoly popisují 4 základní funkce zahrnuté v MPLS TE: distribuce informací o linkách, vyhledání vhodné cesty, její signalizace a směrování vybraného provozu. 2.1 Rozšíření IGP protokolů Pro účely constraint based routingu potřebují všechny LSR znát detailní informace o využití jednotlivých spojů a dostupném přenosovém pásmu. K tomu lze využít rozšíření již existujících link state IGP. Jedná se o protokoly IS IS a OSPF. Pro OSPF se vyvinulo rozšíření, které využívá LSA typu 10 a šíří informace v rámci celé oblasti. Definuje taky nový typ LSA Traffic Engineering LSA, který v obsahu přenáší např: Traffic engineering metric sekundární TE metrika pro danou linku, Maximum bandwidth, Maximum reservable bandwidth, Unreserved bandwidth, Administrative group hodnota definována admistrátorem, pro rozhodování o zahrnutí nebo vyloučení linek do výpočtu CBR a další. Více v RFC 3630 Traffic Engineering (TE) Extensions to OSPF Version 2, nebo v RFC 3784 pro IS IS. 2.2 Výpočet cest Topologická databáze s výše uvedenými informacemi nám poslouží jako základ, na který aplikujeme modifikovaný SPF algoritmus, constraint based, shortest path first (CSPF). Vstupní uzel v MPLS síti do výpočtu nezahrne linky, které nevyhovují požadavkům datového toku, pracuje tedy nad jakousi redukovanou topologii. V praxi se definuje např. minimální propustnost požadovanou pro datový tok. Administrátor je prosinec /12

3 schopen explicitně určit uzly, kterými má provoz probíhat. Výsledkem je pak nejkratší LSP splňující zároveň všechny požadavky. 2.3 Signalizace cest Pokud byla v síti nalezena cesta (způsobem popsaným v předchozí kapitole), vstupní uzel zahájí její signalizaci. Cílem je vytvořit mezi směrovači po cestě vazbu na příchozí a odchozí značku. Teprve pak budeme schopni touto cestou přeposílat pakety. Pro účely signalizace LSP se používá rozšíření protokolu RSVP o další objekty, m.j. práci se značkami Resource Reservation Protocol Protokol samotný vychází z architektury IntServ, která zakládá na rezervací prostředků v síti podle požadavků aplikace. Mezi základní vlastnosti RSVP patří: zahájení rezervace je závislé na příjemci, oddělení rezervace od vlastního rozhodování, které pakety tyto prostředky využijí, potřeba obnovování rezervací a jiné. Zde je třeba zdůraznit, že v kontextu signalizace LSP označujeme jakýkoli uzel, ze kterého vede jednoznačná LSP, právě jako odesílatele. Příjemce bude ten, u koho daná LSP končí Typy RSVP zpráv Každá RSVP zpráva obsahuje hlavičku a alespoň jeden objekt. Objekty se mohou vnořovat. Zpráva Path Resv Funkce Zahájení relace. Odesílatel generuje Path state k příjemci. Signalizace platné rezervace. Příjemce generuje Resv state zpět k odesílateli. ResvConf Potvrzení úspěšné rezervace PathTear ResvTear PathErr ResvErr Ruší stav vytvořený Path zprávou Ruší rezervační stav Podává zprávu o chybě ve směru k odesílateli Podává zprávu o chybě ve směru k příjemci Tabulka 1: Přehled RSVP zpráv Zpráva Path prochází postupně jednotlivými uzly(patřicími do LSP), na kterých vytváří tzv. Path state, jenž obsahuje m.j. IP adresu odesílatele. Pokud koncový uzel rezervaci přijme vygeneruje Resv zprávu. Uzly na zpáteční cestě tuto rezervaci ověří a v kladném případě je poslána na IP adresu z Path state RSVP TE MPLS TE rozšiřuje RSVP protokol o následující objekty: RSVP Objekt RSVP zpráva Popis LABEL_REQUEST Path Požadavek o značku odeslaný sousednímu uzlu ve směru k odesílateli LABEL Resv MPLS značka přidělená sousedním LSR EXPLICIT_ROUTE Path Seznam uzlů určující LSP cestu RECORD_ROUTE Path, Resv Seznam uzlů/značek zaznamenaných během sestavení LSP SESSION_ATTRIBUTE Path Vyžadované LSP atributy (priorita, ochrana, a další) Tabulka 2: Nové typy RSVP objektů podporující MPLS TE V inicializačních zprávách putují požadavky na rezervaci, a v odpovědi Resv se pak buduje LSP a zároveň se plní label forwarding information base (LFIB), popř. rezervuje požadované pásmo. prosinec /12

4 Ilustrace 1: Ukázka RSVP TE zobrazuje průběh RSVP signalizace z počátečního uzlu A (headend) k cíli D (tailend). Na zpáteční cestě směrovač D informuje podle pravidla PHP (Penultimate Hop Popping), sousední směrovač C, aby k němu pakety neznačkoval. Směrovač C vygeneruje novou značku 20 a v přepínací tabulce značek (LFIB, Label Forwarding Information Base) si poznamená, že příchozí paket s touto značkou bude přeposílat na rozhraní k směrovači D (pro tentokrát bez značky). Směrovač B taky vygeneruje novou značku 50, kterou oznámí směrovači A a do LFIB si poznamená, že pakety se značku 50 bude přeposílat na rozhraní 0 se značkou 20 získanou od směrovače C. Takto si směrovače vymění značky zpět až k počátečnímu uzlu headendu. Ilustrace 1: Ukázka RSVP TE 2.4 Směrování provozu MPLS TE rozděluje samotné vytvoření LSP a rozhodování o tom, který tok dat bude touto cestou směrovat. Toto rozhodování přináleží uzlu, který danou LSP vytvořil. Na Cisco směrovačích se ke konfiguraci LSP používá tunel rozhraní, kterému se přiřazuje MPLS TE parametry. Pro směrování tímto tunelem lze využít statických cest nebo policy routingu. V konfiguraci tunel rozhraní lze uvést paramter autoroute, jež sdělí směrovacímu procesu, aby jej použil pro dosažení tailendu a sítí jím nabízených. 3 Fast Reroute (FRR) MPLS TE podporuje náhradní scénáře v případě výpadku uzlu nebo linky na cestě LSP. FRR využívá předem signalizované záložní LSP, která se použije v případě poruchy. Uzel sousedící poškozenému směrovači nebo lince se stává vstupním bodem do připraveného LSP. Nazýváme jej Point of local repair (PLR). Uzel na konci záložního LSP se nazývá merge point (MP) a v něm se data přijatá ze záložní linky přesměrují do původního LSP. Ochranu cesty lze rozdělit na: ochrana spoje záložní cesta vede na následující uzel (next hop), ochrana uzlu záložní cesta vede až na další uzel za následujícím (next next hop). V dalších kapitolách je diskutována první, jednodušší, varianta. Pro detekci a informování o chybě lze použít např. signalizaci pomocí RSVP Hello zpráv nebo protokolu BFD (Bidirectional Forwarding Detection). Dále v příkladu je uvedeno použití RSVP Hello zpráv. Zpoždění do zahájení používání obchozí cesty je řadově v desítkách milisekund pokud se jedná o detekci výpadku přímo připojené sítě. V případě výpadku celého uzlu aktivace objížďky bude z důvodu pozdějšího ohlášení pomalejší. Existují dvě techniky pro přemostění cest: facility backup náhradní cesta využívá stohování MPLS hlaviček, umožňuje přenášet více LSP, one to one každá chráněná cesta vyžaduje vlastní vyhrazenou záložní cestu. Ilustrace 2: Ukázka FRR znázorňuje situaci, ve které mezi směrovači B a C nastal výpadek linky (znázorněno křížkem na spoji RB RC). Data přenášená ze směrovače A do D byly přesměrovány na záložní cestu, přičemž byl použit způsob facility backup. Na směrovači RB se MPLS hlavička změní následujícím způsobem. Bude použita záložní cesta, paket bude odeslán rozhraním č. 2. Na záložní cestě bude paket obsahovat 2 MPLS hlavičky, přičemž vnitřní obsahuje prosinec /12

5 značku, kterou běžně očekává MP (RC očekává značku 20 ). A vnější značka symbolizuje záložní LSP (značka 17 ). Na směrovači RE se použije pravidlo PHP (vnější značka bude odstraněna) a MPLS paket dorazí do RC už s pouze jednou hlavičkou. Směrovač RC dále přepíná značku 20 na 10. Níže uvedené platí pro jeden směr. Ilustrace 2: Ukázka FRR Nicméně FRR přináší na síť množství požadavků, které nelze vždy jednoduše zaručit. Jedná se o volnou kapacitu na záložních linkách, která v době běžného provozu je uměle zadržena pro případné použití. 3.1 Rozšíření RSVP pro podporu FRR Protokol RSVP v konfiguraci vyžadované pro FRR přidává Fast_reroute objekt a rozšiřuje některé stávající: RSVP Objekt RSVP zpráva FRR funkce FAST_REROUTE Path Určuje vlastnosti záložní cesty: priority, max. počet hopů, šířku pásma a jiné. Dále určuje požadovanou techniku zálohy (oneto one nebo facility backup) RECORD_ROUTE Path, Resv Zaznamenává možnosti ochrany na jednotlivých uzlech SESSION_ATTRIBUTE Path Určuje, zda LSP vyžaduje ochranu (linky, uzlu nebo šířky pásma) Tabulka 3: Rozšíření RSVP pro podporu FRR Objekt Fast_reroute se v komunikaci nevyskytl, zato v Session_attribute lze vidět očekávané informace. V příchozím paketu (Resv) pak náležitě vyplněnou Record_route. Ukázky jsou uvedeny v následujících kapitolách. 4 Zachycená komunikace Následující výstupy pocházejí z programu Wireshark. Výstupy navazují na konfiguraci FRR i ilustraci, uvedenou v příloze A. (Výstupy byly zkrácen o nesouvísející části.) 4.1 Zpráva Path Zachycuje RSVP zprávu PATH odeslanou ze směrovače RA do RD. V objektu Explicit_route je vidět přesný seznam uzlů, přes které má signalizace procházet. IP adresy uzlů jsou výsledkem CSPF algoritmu, který zohlednil předem definovaný seznam router ID. Je zde i objekt Label_request. RSVP Header. PATH Message. SESSION: IPv4 LSP, Destination , Tunnel ID 100, Ext ID EXPLICIT ROUTE: Length: 52 Object class: EXPLICIT ROUTE object (20) prosinec /12

6 C type: 1 IPv4 Subobject , Strict IPv4 Subobject , Strict IPv4 Subobject , Strict IPv4 Subobject , Strict IPv4 Subobject , Strict IPv4 Subobject , Strict LABEL REQUEST: Basic: L3PID: IP (0x0800) SESSION ATTRIBUTE: Length: 20 Object class: SESSION ATTRIBUTE object (207) C type: 7 IPv4 LSP (No Resource Affinities) Setup priority: 7 Hold priority: 7 Flags: 0x = Local protection desired = Směrova č vyžaduje na signalizované LSP záložní objížďku = Label recording desired = vyžaduje zahrnutí informací o značkách v objektu Record_route = SE style desired = Bandwidth protection not desired = Node protection not desired Name: Z_RA_do_RD RECORD ROUTE: IPv Zpráva Resv Tento výstup navazuje na zprávu Path z předchozí kapitoly. Je zde zobrazena odpověď RESV z RB do RA Objekt Record_route obsahuje atributy rozšířené o možnosti ochrany uzlů. Směrovač RB oznamuje značku 22, kterou bude rozpoznávat komunikaci přes signalizovanou LSP. RSVP Header. RESV Message. SESSION: IPv4 LSP, Destination , Tunnel ID 100, Ext ID LABEL: 22 RECORD ROUTE: Length: 100 Object class: RECORD ROUTE object (21) C type: 1 IPv4 Subobject , Local Protection Available, Local Protection In Use Label Subobject 22,, Local Protection Available IPv4 Subobject Label Subobject 21,, Local Protection Available IPv4 Subobject Label Subobject 0,, Local Protection Available Lze zde opět vidět chování PHP směrovač RD ( ) nebude očekávat značku. Informace o Record_route objektu jsou dostupné i v Cisco CLI: RA#show s Name: Z_RA_do_RD (Tunnel100) Destination: OutLabel : FastEthernet0/0, 22 RSVP Signalling Info: Src , Dst , Tun_Id 100, Tun_Instance 20 RSVP Path Info: My Address: Explicit Route: Record Route: NONE RSVP Resv Info: Record Route: (22) (21) (0) prosinec /12

7 4.3 FRR Nad topologii z Přílohy A bylo odzkoušeno použití objížďky v přípdě přerušení linky RB RC. Testování probíhalo nejdříve pomocí příkazu traceroute, kterým jsem sledoval použití MPLS značek na primární LSP z do RD. Následně, během odesílání ICMP zpráv příkazem ping, byla linka RB RC manuálně deaktivována příkazem shutdown. Výpadek byl zachycen ve výstupu a způsobil jednu nezodpovězenou ICMP zprávu. Následně byl znovu spuštěn příkaz traceroute pro ověření záložní cesty. Ve výsledku je vidět přidání vnější MPLS hlavičky (značka č. 23) na záložní cestě. Ve výstupu jsou zobrazeny přenášené značky na jednotlivých linkách. RA#traceroute v /32 Tracing MPLS Label Switched Path to /32, timeout is 2 seconds MRU 1500 [Labels: 21/implicit null Exp: 0/0] L MRU 1500 [Labels: 24 Exp: 0] 12 ms L MRU 1504 [Labels: implicit null Exp: 0] 16 ms! ms RA# RA#ping repeat 500 Sending 500, 100 byte ICMP Echos to , timeout is 2 seconds:!!!!!!!.!!!!!!!!!!!!. (stisknuto Ctrl C) Success rate is 90 percent (19/21), round trip min/avg/max=404/778/1024 ms RA# RA#traceroute v /32 Tracing MPLS Label Switched Path to /32, timeout is 2 seconds MRU 1500 [Labels: 21/implicit null Exp: 0/0] L MRU 1496 [Labels: 23/24 Exp: 0/0] 12 ms L MRU 1504 [Labels: 24 Exp: 0] 12 ms L MRU 1504 [Labels: implicit null Exp: 0] 16 ms! ms RA# Používané značky v LSP lze zjistit příkazy, popř. v LFIB: RA#show s tunnel 100 include OutLabel OutLabel : FastEthernet0/1, 21 s jakou značkou posílá směrova č RA RB#show s tunnel 99 include OutLabel OutLabel : FastEthernet0/1, 23 značka posílaná objížďkou z RB 5 Konfigurace LSP na Cisco směrovačích Pro upřesnění vztahu LSP a tunel rozhraní, které jsem zmínil v kapitole 2.4 Směrování provozu, je zde nutno zdůraznit, že LSP lze považovat za abstrakci, jejiž realizace je uskutečněna tunel rozhraním. 5.1 Postup vytvoření LSP 1. V rámci MPLS TE mraku je třeba jednoznačně identifikovat jednotlivé uzly, k tomuto účelu je nejvhodnější použití loopback rozhraní. int Loopback0 ip address nutná maska /32 2. TE se zavádí v rámci aktuální oblasti. mpls traffic eng area O 3. Určení stabilního rozhraní pro účely IGP s podporou MPLS TE. mpls traffic eng router id Loopback0 4. Aktivace MPLS na rozhraních. (if)# 5. Zapnutí podpory TE na směrovači, nutno uvést v konfiguračním režimu i na všech rozhraních, na kterých chceme provozovat TE. (conf)# prosinec /12

8 (if)# 6. Vytvoření tunelu interface Tunnel 1! lokalni konec tunelu si převezme IP adresu z loopback rozhraní ip unnumbered Loopback0! cílová IP adresa tunelu (vhodná je zde protější Router ID adresa) tunnel destination ! povinný příkaz pro aktivaci MPLS TE tunnel mode mpls traffic eng! oznámí možnost dosažení uzl ů směrovacímu procesu tunnel mpls traffic eng autoroute announce! LSP bude vypočítána dynamicky tunnel mpls traffic eng path option 1 dynamic Položek path option lze definovat více, preferována bude volba s nižším číslem. Alternativně lze definovat seznam uzlů, ukázka je uvedena v další kapitole. Při definici LSP můžeme definovat prioritu pro vytváření tunelu i jeho udržování (setup, holding). Platí, že nová LSP s vyšší prioritou zavedení zruší již existující LSP s nižší prioritou udržování. Směrovač, na kterém tato kolize vznikla, pošle RSVP ResvTear zprávu k směrovači, který danou LSP inicioval. Priorita může nabývat hodnot 0 7, číselně nižší znamená větší prioritu. Výchozí hodnota je 7. Příklad: tunnel mpls traffic eng priority 7 [7] 5.2 Explicitní cesta Příkazem ip explicit path <jmeno> lze v konfiguračním režimu vytvořit seznam uzlů, přes které se má (nebo taky nesmí) LSP postupně signalizovat. Vkládání IP adres provádíme jednotlivými next address <IP_adresa> (případně pak exclude address <IP_adresa> ). Tento pojmenovaný seznam pak můžeme použít v definici tunelu pomocí příkazu: tunnel mpls traffic eng path option 10 explicit <jmeno> 5.3 Fast Reroute V konfiguraci tunelu, který vyžaduje ochranu, je nutné uvést řádek, který zajistí odesílání objektu Fast_Reroute v RSVP zprávě. (tunel)#tunnel mpls traffic eng fast reroute Na uzlu PLR (point of local repair), na kterém budeme využívat možnosti FRR, je třeba připravit obchozí LSP. Příslušné kroky byly okomentovány v kapitole 4.1 Vytvoření LSP. Dále na PLR v konfiguraci pochybného rozhraní nastavíme: (if)#mpls traffic eng backup path <tunel> Pro úpěšnou detekci sousedů s použitím RSVP Hello zpráv na chráněné lince a rychlé přesměrování provozu na linku záložní je nutné doplnit konfiguraci o následující příkazy v globálním režimu i na rozhraní diskutované linky. (conf)#ip rsvp signalling hello (if)#ip rsvp signalling hello 6 Závěr Otestoval jsem základní konfiguraci tunelů pro přenos paketů nad MPLS a sledoval RSVP komunikaci mezi směrovači. V Cisco směrovačích 2801 je podpora Fast Reroute podporována v IOS od verze 12.4(22). Mezi nevýhody lze zařadit to, že protokol RSVP je ze své podstaty jednosměrně orientovaný, tudiž pro zajištění běžné komunikace je třeba vytvářet velmi podobné konstrukce vždy i z druhého konce. prosinec /12

9 7 Zdroje ALVAREZ, Santiago. Qos for IP/MPLS Networks. 1st edition. [s.l.] : Cisco Press, s. ISBN MPLS Traffic Engineering and Enhancements [online]. [2008] [cit ]. Dostupný z WWW: < MPLS Traffic Engineering [online]. [2008] [cit ]. Dostupný z WWW: < Multiprotocol Label Switching on Cisco Routers [online]. [2008] [cit ]. Dostupný z WWW: < AWDUCHE, D., et al. Requirements for Traffic Engineering Over MPLS [online] [cit ]. Dostupný z WWW: < OSBORNE, Eric, SIMHA, Ajay. Traffic Engineering with MPLS [online]. Cisco Press, 2002 [cit ]. Dostupný z WWW: < KACÁLEK, Jan. RSVP Zprávy [online]. c2006 [cit ]. Dostupný z WWW: < AWDUCHE, D., et al. RSVP TE: Extensions to RSVP for LSP Tunnels [online] [cit ]. Dostupný z WWW: < prosinec /12

10 8 Příloha A: Konfigurace FRR ho RA interface fa 0/1 ip address int loop0 ip add router ospf 1 mpls traffic eng area 0 mpls traffic eng router id Loopback0 interface Tunnel100 description Z_RA_do_RD ip unnumbered Loopback0 tunnel destination tunnel mode mpls traffic eng tunnel mpls traffic eng autoroute announce tunnel mpls traffic eng path option 1 explicit name Z_RA_do_RD tunnel mpls traffic eng fast reroute ip explicit path name Z_RA_do_RD enable next address next address next address exit ho RB ip rsvp signalling hello interface FastEthernet0/0 ip address interface FastEthernet1/0 desc nestabilni_linka_rb_rc ip address ip rsvp signalling hello prosinec /12

11 mpls traffic eng backup path tunnel 99 interface FastEthernet0/1 ip address int loop0 ip add router ospf 1 mpls traffic eng area 0 mpls traffic eng router id Loopback0 interface Tunnel99 description BACKUP_WHEN_Link R2 R3_DOWN ip unnumbered Loopback0 tunnel destination tunnel mode mpls traffic eng tunnel mpls traffic eng path option 1 explicit name BACKUP_R2_TO_R3 ip explicit path name BACKUP_R2_TO_R3 enable next address next address exit ho RC ip rsvp signalling hello interface FastEthernet1/1 desc nestabilni_linka_rc_rb ip address ip rsvp signalling hello mpls traffic eng backup path tunnel499 interface FastEthernet0/0 ip address interface FastEthernet1/0 ip address int loop0 ip add router ospf 1 mpls traffic eng area 0 mpls traffic eng router id Loopback0 interface Tunnel499 description BACKUP_WHEN_Link RB RC_DOWN_two ip unnumbered Loopback0 tunnel destination tunnel mode mpls traffic eng tunnel mpls traffic eng path option 1 explicit name BACKUP_RB_TO_RC_zpet prosinec /12

12 ip explicit path name BACKUP_RB_TO_RC_zpet enable next address next address exit ho RD interface FastEthernet0/0 ip address int loop0 ip add router ospf 1 mpls traffic eng area 0 mpls traffic eng router id Loopback0 interface Tunnel400 description Z_RD_do_RA ip unnumbered Loopback0 tunnel destination tunnel mode mpls traffic eng tunnel mpls traffic eng autoroute announce tunnel mpls traffic eng path option 1 explicit name Z_RD_do_RA tunnel mpls traffic eng fast reroute ip explicit path name Z_RD_do_RA enable next address next address next address exit ho RE interface FastEthernet1/1 ip address interface FastEthernet1/0 ip address int loop0 ip add router ospf 1 mpls traffic eng area 0 mpls traffic eng router id Loopback0 exit prosinec /12