MPLS a VPN. Petr Grygárek, RCNA FEI VŠB-TU Ostrava, 2004

Transkript

1 MPLS a VPN Petr Grygárek, RCNA FEI VŠB-TU Ostrava, 2004 Platformy a ověřené verze IOS G-P IOS (tm) C2600 Software (C2600-JS56I-M), Version 12.1(3)T, RELEASE SOFTWARE (fc1) System image file is "flash:c2600-js56i-mz t.bin" I-PE IOS (tm) 4500 Software (C4500-JS-M), Version 12.2(2)T4, RELEASE SOFTWARE (fc3) System image file is "flash:c4500-js-mz t4.bin" J-PE IOS (tm) 4500 Software (C4500-JS-M), Version 12.2(2)T4, RELEASE SOFTWARE (fc3) System image file is "flash:c4500-js-mz t4.bin" Historická poznámka Cisco IOS implementoval mechanismus MPLS již v době, kdy ještě nebyl zcela standardizován. Mechanismus se v Cisco terminologii nazýval tag switching. Z toho historicky vzniklo i pojmenovávání příkazů souvisejících s MPLS. Novější IOSy mají také alternativní příkazy pojmenovávané již v souladu s názvem MPLS, avšak tyto příkazy jsou často jen jakýmisi makry - ve skutečnosti do konfigurace vloží starou verzi příkazu. Některé příkazy nové verze ve některých IOS ještě nemají. Proto se budeme držet v tomto textu starých příkazů. V závěru je uveden slovníček obou verzí příkazů použitých v tomto textu. Některé starší IOSy rovněž nemají implementován standardní protokol LDP (Label Distribution Protocol) pro distribuci značek (labels). Používají namísto něj proprietární protokol Cisca, nazývaný TDP Tag Distribution Protocol. V konfiguraci uvedené dále byl použit právě TDP. Protože však funkce obou protokolů je identická, není použití TDP namísto LDP na škodu a pro pochopení obecného principu MPLS a MPLS/VPN důležité.

2 Základní funkce MPLS Zapojte síť podle obrázku. V síti zajistěte směrování protokolem OSPF (area 0) / /24 SW SW e0 e /24 I-PE / /24 S0 S1/0 S1/1 S0 G-P J-PE e0 e /24 SW SW Konfigurace MPLS Podmínkou pro funkci MPLS je aktivace CEF (Cisco Express Forwarding) v globálním konfiguračním režimu všech routerů (není-li již aktivováno implicitně): ip cef Aktivujte MPLS na rozhraních PE-routerů I-PE a J-PE vedoucích k P-routeru G-P a na rozhraních routeru G-P: interface S0 tag-switching ip Ověřte, že na daných rozhraních byl MPLS spuštěn a zjistěte, jaký protokol je používán pro distribuci začek (Cisco proprietary TDP/ standardní LDP). Protokol pro distribuci značek si musí mezi sousedy odpovídat. sh tag-switching interfaces Zjistěte TDP ID vlastního routeru (ID zajišťuje jednoznačnost v rámci protokolu TDP): sh tag-switching tdp discovery Ve výpisu současně uvidíte i ID sousedních routerů, které protokol TDP nadetekoval jako sousedy. Zjistěte, s jakými sousedy si protokol TDP/LDP navázal spojení (TCP) pro výměnu značek sh tag-switching tdp neighbor Vypište si tabulku LIB (Label Information Base), obsahující mapování značek pro jednotlivé cesty nabízené všemi TDP/LDP sousedy: sh tag-switching tdp bindings Položka Local binding ve výpisu definuje značku přidělenou a propagovanou pro danou cestu lokálním routerem.

3 V Remote binding jsou značky pro jednotlivé cesty propagované okolními routery. Prostudujte LIB tabulky všech routerů a jejich souvislosti. Všimněte si, že značky jsou v Cisco implementaci jednoznačné v rámci celého routeru (nejen v rámci interface, jako např. u Frame Relay nebo ATM). v LIB jsou uchovávány všechny značky nabízené sousedními routery (tzv. liberal retention mode). Tedy i značka od routeru, který má cestu do dané sítě horší, než náš vlastní router (a tato cesta možná vede přes nás ()). Tato značka samozřejmě nebude převzata do LFIB, ale uchovává se pro případ změny ve směrování. značky se přidělují podle pravidla penultimate hop behavior. Cesty k přímo připojeným sítím propagují routery se značkou imp-null, čímž říkají sousedním routerům, že má z paketů do těchto sítí značku odstranit (operace POP). Tím přijímající router nemusí při příchodu paketu pro přímo připojené sítě provádět vyhledávání v tabulce značek jen proto, aby zjistil, že má značku odstranit a cíl poté ještě normálně vyhledat ve směrovací tabulce podle cílové IP adresy jde přímo do směrovací tabulky. Identifikátor imp-null tedy uvidíte v Local bindings pro všechny sítě přimo připojené k routeru a v Remote bindings pro všechny sítě přímo připojené k sousedovi, který danou značku (zde impnull) propaguje. Poznámky Implicitně router přiděluje a propaguje značky pro všechny cesty, které má ve směrovací tabulce. Propagování značek pro jednotlivé cesty lze omezit v globálním konfiguračním režimu prostřednictvím ACL. Propagování značky pro default route lze povolit z globálního konfiguračního režimu příkazem tag-switching ip default-route. Do forwarding tabulky (LFIB-Label Forwarding Information Base) jsou převzaty jen ty značky z LIB, které nabízí ten soused, jenž je podle směrovacího protokolu next-hop na cestě k dané síti. LFIB lze zobrazit příkazem sh tag-switching forwarding-table Srovnejte obsah informací z LIB a LFIB a s obsahem lokální směrovací tabulky. Příklad fungování MPLS V konkrétním vyzkoušeném případě byly značky cestám jednotlivými routery přiděleny tak, jak je uvedeno dále. Je uveden obsah LIB a LFIB pro všechny routery. Prostudujte si souvislosti LIB, LFIB a směrování. Router I-PE I-PE#show tag-switching tdp bindings tib entry: /24, rev 2 local binding: tag: imp-null remote binding: tsr: :0, tag: imp-null tib entry: /24, rev 4 local binding: tag: 16 remote binding: tsr: :0, tag: imp-null tib entry: /24, rev 10

4 local binding: tag: imp-null remote binding: tsr: :0, tag: 18 tib entry: /24, rev 12 local binding: tag: imp-null remote binding: tsr: :0, tag: 19 tib entry: /24, rev 6 local binding: tag: 17 remote binding: tsr: :0, tag: 16 tib entry: /24, rev 8 local binding: tag: 18 remote binding: tsr: :0, tag: 17 I-PE# Z položky tsr (Tag-Switch Router) vidíme, že značky k I-PE propaguje pouze soused s ID (router G-P). Pro přímo připojené sítě /24, /24 a /24 je Local binding imp-null. Pro přímo připojenou síť souseda /24 je remote binding imp-null. Router G-P nabízí značky i pro cesty vedoucí směrem k I-PE (smyčka): pro sítě /24 a /24 s jednoznačnými značkami 18 a 19, pro síť /24 se značkou imp-null (je k G-P přímo připojena). Cesty do sítí /24 a /24 nabízí G-P s jednoznačnými značkami 16 a 17, I-PE by je nabízel dál s (jinými) jednoznačnými značkami 17 a 18. I-PE#show tag-switching forwarding-table Local Outgoing tag tag or VC Prefix or Tunnel Id Bytes tag Outgoing switched interface Next Hop 16 Pop tag /24 0 Se0 point2point / / Se0 Se0 point2point point2point I-PE# LFIB obsahuje řády pouze pro cesty, pro něž router očekává příchod paketů označených značkou. Všimněte si shody hodnot ve sloupci Local tag pro jednotlivé cesty ve LFIB s příslušnými hodnotami Local binding v LIB. Z důvodu penultimate hop behavior bude I-PE odstraňovat (POP) tag z paketů se značkou 16 pro síť /24 (soused G-P je posledním skokem a propaguje značku imp-null). Pakety do sítí /24 a /24 přicházející se značkami 17, resp. 18 budou odcházet rozhraním Se0 se značkou 16, resp. 17. Router J-PE J-PE#show tag-switching tdp bindings tib entry: /24, rev 2 local binding: tag: 16 remote binding: tsr: :0, tag: imp-null tib entry: /24, rev 4 local binding: tag: imp-null remote binding: tsr: :0, tag: imp-null tib entry: /24, rev 10 local binding: tag: 17 remote binding: tsr: :0, tag: 18 tib entry: /24, rev 12 local binding: tag: 18 remote binding: tsr: :0, tag: 19 tib entry: /24, rev 6 local binding: tag: imp-null remote binding: tsr: :0, tag: 16 tib entry: /24, rev 8 local binding: tag: imp-null remote binding: tsr: :0, tag: 17 J-PE#

5 Značky k J-PE propaguje pouze soused s ID (tsr router G-P). Pro přímo připojené sítě /24, /24 a /24 je local binding imp-null. Pro přímo připojenou síť souseda /24 je remote binding imp-null. Router G-P nabízí značky i pro cesty vedoucí směrem k J-PE (smyčka): pro sítě /24 a /24 s jednoznačnými značkami 16 a 17, pro síť /24 se značkou imp-null (je k G-P přímo připojena). Cesty do sítí /24 a /24 nabízí router G-P s jednoznačnými značkami 18 a 19, J-PE by je nabízel dál s (jinými) jednoznačnými značkami 17 a 18. J-PE#show tag-switching forwarding-table Local Outgoing Prefix Bytes tag Outgoing Next Hop tag tag or VC or Tunnel Id switched interface Pop tag / / Se0 Se0 point2point point2point 18 J-PE# /24 0 Se0 point2point Zkontrolujte shodu hodnot ve sloupci Local tag pro jednotlivé cesty s Local bindings v LIB. Z důvodu penultimate hop behavior bude J-PE odstraňovat tag z paketů pro síť /24 (soused G-P je posledním skokem a propaguje značku imp-null). Pakety do sítí /24 a /24 budou odcházet se značkou 18, resp. 19. Router G-P G-P#show tag-switching tdp bindings tib entry: /24, rev 7 local binding: tag: imp-null remote binding: tsr: :0, tag: imp-null remote binding: tsr: :0, tag: 16 tib entry: /24, rev 8 local binding: tag: imp-null remote binding: tsr: :0, tag: 16 remote binding: tsr: :0, tag: imp-null tib entry: /24, rev 11 local binding: tag: 18 remote binding: tsr: :0, tag: imp-null remote binding: tsr: :0, tag: 17 tib entry: /24, rev 12 local binding: tag: 19 remote binding: tsr: :0, tag: imp-null remote binding: tsr: :0, tag: 18 tib entry: /24, rev 9 local binding: tag: 16 remote binding: tsr: :0, tag: 17 remote binding: tsr: :0, tag: imp-null tib entry: /24, rev 10 local binding: tag: 17 remote binding: tsr: :0, tag: 18 remote binding: tsr: :0, tag: imp-null G-P# Oba sousední routery nabízí routeru G-P značky pro všechny sítě, které mají ve směrovací tabulce. Proto je u každé cesty vždy remote-binding od obou sousedních routerů. Některé by tvořily smyčky. Local binding je imp-null pro přímo připojené sítě /24 a /24. Remote binding je imp-null pro sítě, které jsou k sousedovi, který je propaguje, přímo připojeny.

6 G-P#show tag-switching forwarding-table Local Outgoing Prefix Bytes tag Outgoing Next Hop tag 16 tag or VC Pop tag or Tunnel Id /24 switched 0 interface Se1/1 point2point Pop tag Pop tag / / Se1/1 Se1/0 point2point point2point 19 Pop tag /24 0 Se1/0 point2point G-P# Pakety pro sítě /24 a /24 přicházejí routeru G-P již beze značky (sám G-P pro ně propaguje značku imp-null), proto se pakety pro tyto sítě směrují přímo podle směrovací tabulky a v LFIB nejsou uvedeny. Pro sítě za routery I-PE, resp. J-PE se značkovaný paket vyšle protějším rozhraním s tím, že značka bude předtím odstraněna (operace POP). Sledování provozu MPLS Pro sledování zacházení se značkami můžeme využít příkazu debug na P-routeru G-P nebo protokolového analyzátoru. Značky jsou neseny v MPLS záhlavích, které se vyskytuje v datové části rámce před záhlavím přenášeného IP paketu. Použití příkazu debug Na routeru G-P zadejte příkaz debug tag-switching packets Vyzkoušejte ping z routerů I-PE a J-PE do sítí za G-P. Budou zobrazovány informace o všech paketech přepínaných pouze s použitím LFIB (tj. bez použití směrovací tabulky). Prozkoumejte další možnosti použití příkazu debug tag-switching. Sledování hlavičky MPLS na paketovém analyzátoru Propojte routery I-PE a G-P další linkou Ethernet přes HUB. Segment adresujte /24 a zahrňte jej do směrování pomocí OSPF. Na obou rozhraních nezapomeňte aktivovat MPLS. Zkontrolujte směrovací tabulku routeru I-PE. Díky implicitně nižší ceně linky Ethernet by měl provoz do sítí /24 a /24 procházet Ethernetem Sériová linka mezi I-PE a G-P se nyní neuplatní. Zkontrolujte také v LFIB. Připojte do HUBu síťový analyzátor. Pošlete z routeru I-PE ping do sítí /24 a /24 a sledujte pakety analyzátorem. Pakety by měly být tagované, tj. obsahovat příslušnou značku. Prohlédněte si obsah MPLS hlavičky. Srovnejte značku v hlavičce s odchozí značkou pro danou cestu uvedeném v LFIB I-PE (sh tag-switching forwarding-table). Všimněte si, že odpovědi na ping tagované nejsou (vysvětlete proč).

7 Konfigurace MPLS/VPN OSTRAVA / /24 TACHOV Customer A Customer B e0 e1 I-PE / /24 S0 S1/0 S1/1 S0.1.2 G-P.1.2 J-PE e0 e1 Customer B Customer A / /24 Síť poskytovatele zahrnuje přípojné body Ostrava a Tachov a tranzitní síť mezi nimi. Poskytovatel poskytuje konektivitu pro zákazníky CustomerA a CustomerB, z nichž oba požadují službu virtuální privátní sítě (VPN) v režimu peer-to-peer. Oba zákazníci mají vždy po jedné lokalitě (site) připojené v přípojných bodech Ostrava a Tachov. Obě VPN mají být zcela odděleny; zákazníci dokonce používají překrývající se rozsahy (privátních) adres. Návrh parametrů MPLS/VPN Na routerech I-PE a J-PE vytvoříme samostatné VRF pro lokality obou zákazníků. Jména VRF mají lokální význam, pro přehlednost však do jména zakomponujeme jméno zákazníka i jméno příslušného routeru: I-PE: J-PE: CustomerA-I, CustomerB-I CustomerA-J, CustomerB-J Každé VRF přiřadíme Route Distinguisher (RD), který zajistí globální jednoznačnost adres. Pro jednoduchý případ nepřekrývajících se VPN můžeme volit RD společný vždy pro obě VRF u VPN obou zákazníků. RD je libovolná sekvence bitů, formálně však má tvar AS:číslo. Předpokládejme, že AS poskytovatele je 100. Cesty v rámci VPN CustomerA pak můžeme označovat RD 100:1, cesty z VPN Customer-B RD 100:2. Pro každou VRF musíme dále definovat Route Target (RT), jímž budou označovány cesty propagované z dané VRF ostatním PE routerům. Zde můžeme cesty z obou VRF CustomerA označovat např. 100:10, cesty z obou VRF Customer B 100:20. Dále musíme pro každou VRF rozhodnout, jaké cesty do ní mají být importovány. Zde budeme do VRF importovat pouze cesty z druhé VRF téže VPN, tedy do obou VRF CustomerA cesty označené RT 100:10 a do obou VRF CustomerB cesty s RT 100:20. Na závěr stanovíme pro účely protokolu MP-BGP loopback adresy obou PE routerů pro I- PE a pro J-PE. Obě budou s maskou /32. Použití loopback rozhraní se zde jeví být podmínkou funkčnosti.

8 Všechny výše určené parametry jsou shrnuty na následujícím obrázku: OSTRAVA Customer A Customer B RD 100:1 RT 100:10 VRF CustomerA-I /24 e0 e /24 I-PE VRF CustomerB-I RD 100:2 RT 100: / /24 S0 S1/0 S1/1 S0 G-P J-PE lo0 lo / /32 RD 100:2 RT 100:20 VRF CustomerB-J /24 e0 e /24 VRF CustomerA-J RD 100:1 RT 100:10 TACHOV Customer B Customer A Základní konfigurace Zapojte a zprovozně síť podle obrázku. Směrovací protokol OSPF poběží pouze v páteři poskytovatele, tedy jen mezi routery I-PE, G-P a J-PE. Sítě připojené k Ethernet rozhraním routerů I-PE a J-PE do OSPF propagovány nebudou. Rozhraní loopback do OSPF propagujte. Nevkládejte prozatím IP adresy na Ethernet rozhraní routerů I-PE a J-PE. Jelikož jsou duplicitní, nebylo by jejich vložení možné. Konfigurace MPLS Aktivujte všude CEF (ip cef) a na všech sériových rozhraních spusťte MPLS (tag-switching ip). Ověřte bindings na každém routeru. Konfigurace VPN Routing and Forwarding (VRF) Nakonfigurujte samostatné VRF pro každou lokalitu obou zákazníků v souladu s dříve stanovenými parametry: I-PE ip vrf CustomerA-I rd 100:1 route-target export 100:10 route-target import 100:10 ip vrf CustomerB-I rd 100:2 route-target export 100:20 route-target import 100:20

9 J-PE ip vrf CustomerA-J rd 100:1 route-target export 100:10 route-target import 100:10 ip vrf CustomerB-J rd 100:2 route-target export 100:20 route-target import 100:20 Příkaz route-target export definuje, s jakým RT budou cesty z dané VRF propagovány do MP- BGP. Naopak příkazem route-target import říkáme, že do dané VRF chceme importovat všechny cesty propagované z jiných VRF s určeným RT. Nakonfigurované VRF zkontrolujte příkazem show ip vrf [detail] Dále je třeba přiřadit rozhraní PE routerů vedoucí k lokalitám jednotlivých zákazníků do příslušných VRF. Pak na ně již můžeme vložit i duplicitní IP adresy směrování se děje pro jednotlivé VRF nezávisle. I-PE J-PE interface Ethernet0 ip vrf forwarding CustomerA-I ip address interface Ethernet1 ip vrf forwarding CustomerB-I ip address interface Ethernet0 ip vrf forwarding CustomerB-J ip address interface Ethernet1 ip vrf forwarding CustomerA-J ip address Zkontrolujte, jaká rozhraní jsou k daným VRF přiřazena: show ip vrf interfaces Každá VRF představuje na routeru samostatnou směrovací tabulku. Tu si můžeme vypsat příkazem show ip route vrf <JMENO_VRF> Zatím by měla obsahovat pouze sítě přímo připojené (C) k lokalitám jednotlivých zákazníků. Všimněte si, že globální směrovací tabulka je na směrovacích tabulkách pro jednotlivé VRF nezávislá: show ip route

10 Globální směrovací tabulka bude obsahovat pouze přímo připojené páteřní segmenty a informace o páteři naučené z OSPF. Nebude však již obsahovat sítě přímo připojené k lokalitám jednotlivých zákazníků. PE routery musí znát i cesty do vnitřních sítí každé lokality každého zákazníka. To lze zajistit buď propagací těchto cest od zákazníka pomocí vhodného IGP, nebo jednoduše statickými záznamy na obou PE-routerech vloženými do příslušných VRF. Předpokládejme, že vnitřní struktura a adresování v lokalitách zákazníků je taková, jak ukazuje následující obrázek: OSTRAVA CustomerA E-CE /24 lo /24 e1 I-PE.1 CustomerB F-CE.2 lo / /24 TACHOV /24.2 CustomerB C-CE.1 lo /24 J-PE.1.2 CustomerA D-CE /24 lo /24 Potřebné statické cesty nakonfigurujeme v globálním konfiguračním režimu takto: I-PE J-PE ip route vrf CustomerA-I ip route vrf CustomerB-I ip route vrf CustomerA-J ip route vrf CustomerB-J Předávání cest mezi VRF pomocí MP-BGP Dále bude potřeba zprovoznit relaci Multiprotocol BGP (MP-BGP) mezi PE routery. Tento protokol bude cesty mezi jednotlivými VRF distribuovat. Protože se principiálně jedná a relace interního BGP (IBGP), musí být relace mezi PE routery konfigurovány v topologii každý s každým. Relace IBGP nakonfigurujte mezi loopback rozhraními routerů I-PE a J-PE: I-PE, J-PE router bgp 100 no bgp default ipv4-unicast neighbor <peer-pe-ipaddr-lo0> remote-as 100 neighbor <peer-pe-ipaddr-lo0> update-source Loopback0 neighbor <peer-pe-ipaddr-lo0> activate address-family vpnv4 neighbor <peer-pe-ipaddr-lo0> activate

11 Příkazem no bgp default ipv4-unicast protokolu BGP zakážeme, aby okamžitě navázal relaci s definovanými peery a dohodnul výměnu adresových prefixů adresové rodiny IP v.4 (což běžně dělá). Příkazem neighbor <peer-pe-ipaddr-lo0> activate explicitně přikážeme, aby BGP navázal spojení s peerem s IP adresou <peer-pe-ipaddr-lo0>. Příkazem address-family vpnv4 zajistíme, aby BGP dohodnul předávání adres IP v.4 rozšířených o RD a to s těmi peery, pro něž bylo použití adresové rodiny vpnv4 aktivováno příkazem neighbor activate v sekci address-family vpnv4. Příkaz neighbor activate zadaný v rámci adresové rodiny vpnv4 navíc doplnil do této adresové rodiny příkaz neighbor send-community extended Tím se dovolí předávání atributu COMMUNITY na daného peera (což je implicitně zakázáno) a také použití hodnoty atributu COMMUNITY v rozšířeném (extended) formátu. Protokol BGP totiž implicitně atribut COMMUNITY peerům nepředává, ale pro adresovou rodinu vpnv4 je to potřebné předává se zde totiž route target (RT) příslušné cesty a dále tzv. Site of Origin (SOO), který zabraňuje případnému cyklickému předávání cesty mezi MP-BGP routery. Vypište si nyní konfiguraci (sh running-config). Všimněte si, že s příkazem no bgp default ipv4- unicast router do konfigurace BGP automaticky doplnil sekce dalších adresových rodin, vždy jednu pro každou na routeru definovanou VRF. Sekce pro každou VRF obsahuje implicitně příkazy no auto-summary a no synchronization. Redistribuce cest do MP-BGP Do MP-BGP (resp. do příslušných adresových rodin v rámci protokolu BGP) musíme z jednotlivých VRF redistribuovat statické cesty směřující k jednotlivým lokalitám zákazníků. Protože chceme zajistit i dosažitelnost spojovacích linek mezi ISP a lokalitami zákazníků, budeme redistribuovat i přímo připojené sítě: I-PE J-PE router bgp 100 address-family ipv4 vrf CustomerB-I redistribute connected redistribute static exit-address-family address-family ipv4 vrf CustomerA-I redistribute connected redistribute static exit-address-family router bgp 100 address-family ipv4 vrf CustomerB-J redistribute connected redistribute static exit-address-family address-family ipv4 vrf CustomerA-J redistribute connected redistribute static exit-address-family Do adresových rodin MP-BGP odpovídajících jednotlivým VRF se samozřejmě redistribuují jen cesty z příslušných VRF.

12 Úplná konfigurace MP-BGP na routerech I-PE a J-PE vypadá následovně: I-PE router bgp 100 no bgp default ipv4-unicast neighbor remote-as 100 neighbor update-source Loopback0 neighbor activate address-family ipv4 vrf CustomerB-I redistribute connected redistribute static no auto-summary no synchronization exit-address-family address-family ipv4 vrf CustomerA-I redistribute connected redistribute static no auto-summary no synchronization exit-address-family address-family vpnv4 neighbor activate neighbor send-community extended exit-address-family J-PE router bgp 100 no bgp default ipv4-unicast neighbor remote-as 100 neighbor update-source Loopback0 neighbor activate address-family ipv4 vrf CustomerB-J redistribute connected redistribute static no auto-summary no synchronization exit-address-family address-family ipv4 vrf CustomerA-J redistribute connected redistribute static no auto-summary no synchronization exit-address-family address-family vpnv4 neighbor activate neighbor send-community extended exit-address-family Kontrola funkčnosti MP-BGP Zkontrolujte BGP spojení: sh ip bgp neighbors Měl by být vidět jeden soused ve stavu Established a relace pracující pro adresovou rodinu VPNv4 Unicast.

13 Na obou routerech si vypište cesty naučené z MP-BGP (budou uspořádány podle RD, který bude u každé cesty rovněž zobrazen): sh ip bgp vpnv4 all Výpis lze také filtrovat podle RD nebo jména VRF. Zkontrolujte na obou routerech pro všechny VRF, zda byly do každé VRF z MP-BGP importovány patřičné cesty: sh ip route vrf <JMENO-VRF> Měly by být vidět cesty importované z těch VRF, jejichž export route target odpovídá import route target zkoumané VRF. Cesty budou ve směrovací tabulce označeny písmenem B. Vyzkoušejte konektivitu mezi jednotlivými lokalitami obou zákazníků. Připojte CE routery RC,RD,RE a RF do jednotlivých lokalit a vyzkoušejte z nich ping a Telnet na router druhé lokality cizího přístupového bodu stejné VPN. Na CE routerech nakonfigurujte pouze hostname, IP adresu rozhraní k PE routeru, adresu rozhraní loopback simulujícího vnitřní síť zákazníka a default route na PE router. Podle předem nakonfigurovaného hostname CE routerů ověřte, že i přes duplicitu adres v jednotlivých VPN jste pomocí Telnetu připojeni ke správnému routeru. Můžete vyzkoušet také ping z routerů I-PE a J-PE. Zde je však třeba uvést, která VRF má být použita pro směrování příslušné zprávy: ping vrf <JMENO-VRF> x.x.x.x Ping vrf existuje i v extended verzi ping vrf <JMENO-VRF> Po jeho zadání se IOS zeptá na další parametry (včetně speciálních, např. možnosti určit zdrojovou adresu žádosti o echo) stejně jako u normálního extended ping. Užitečný je také příkaz trace vrf <JMENO-VRF> x.x.x.x Protože nemáme DNS, je vhodné před použitím trace mapování IP adres mezilehlých uzlů na doménová jména vypnout (no ip domain-lookup). Informace předávané pomocí BGP o cestách v adresové rodině vpnv4 můžete sledovat po vložení příkazu debug ip bgp vpnv4 Předání kompletní informace si můžeme vynutit násilným rozpojením relace IBGP pomocí příkazu clear ip bgp * po němž bude následovat nové navázání relace a výměna kompletní informace mezi peery. Upozornění: Při rozpojení a novém navázání relace MP-BGP budou jednotlivým propagovaným cestám přiděleny jiné značky.

14 Příklad fungování MPLS-VPN Všimněte si návaznosti MP-BGP na MPLS v konkrétním vyzkoušeném případě. Router G-P LIB i LFIB routeru G-P obsahuje pouze páteřní sítě: G-P#sh tag-switching tdp bindings tib entry: /24, rev 2 local binding: tag: imp-null remote binding: tsr: :0, tag: 16 remote binding: tsr: :0, tag: imp-null tib entry: /24, rev 4 local binding: tag: imp-null remote binding: tsr: :0, tag: imp-null remote binding: tsr: :0, tag: 20 tib entry: /32, rev 6 local binding: tag: 16 remote binding: tsr: :0, tag: 21 remote binding: tsr: :0, tag: imp-null tib entry: /32, rev 8 local binding: tag: 17 remote binding: tsr: :0, tag: imp-null remote binding: tsr: :0, tag: 21 G-P#sh tag-switching forwarding-table Local Outgoing Prefix Bytes tag Outgoing Next Hop tag 16 tag or VC Pop tag or Tunnel Id /32 switched interface Se1/0 point2point 17 Pop tag / Se1/1 point2point Také směrovací tabulka routeru G-P obsahuje pouze cesty páteřní sítě - o VRF router G-P nic neví: G-P#sh ip route C C O O /24 is subnetted, 1 subnets is directly connected, Serial1/ /24 is subnetted, 1 subnets is directly connected, Serial1/ /32 is subnetted, 2 subnets [110/782] via , 00:41:30, Serial1/ [110/782] via , 00:41:30, Serial1/0 LIB I-PE a J-PE LIB routerů I-PE a J-PE obsahují značky pouze pro páteřní sítě: I-PE#sh tag-switching tdp bindings tib entry: /24, rev 2 local binding: tag: imp-null remote binding: tsr: :0, tag: imp-null tib entry: /24, rev 4 local binding: tag: 20 remote binding: tsr: :0, tag: imp-null tib entry: /32, rev 6

15 local binding: tag: imp-null remote binding: tsr: :0, tag: 16 tib entry: /32, rev 8 local binding: tag: 21 remote binding: tsr: :0, tag: 17 J-PE#sh tag-switching tdp bindings tib entry: /24, rev 4 local binding: tag: 16 remote binding: tsr: :0, tag: imp-null tib entry: /24, rev 2 local binding: tag: imp-null remote binding: tsr: :0, tag: imp-null tib entry: /32, rev 6 local binding: tag: 21 remote binding: tsr: :0, tag: 16 tib entry: /32, rev 8 local binding: tag: imp-null remote binding: tsr: :0, tag: 17 J-PE# Směrovací tabulky I-PE a J-PE Globální směrovací tabulka routerů I-PE i J-PE obsahuje pouze přímo připojenou páteřní síť a loopback rozhraní a sítě páteře naučené z OSPF: I-PE#sh ip route /24 is subnetted, 1 subnets C is directly connected, Serial /24 is subnetted, 1 subnets O [110/845] via , 00:42:28, Serial /32 is subnetted, 2 subnets O [110/846] via , 00:42:28, Serial0 C is directly connected, Loopback0 I-PE# J-PE#sh ip route O C C O /24 is subnetted, 1 subnets [110/845] via , 00:46:19, Serial /24 is subnetted, 1 subnets is directly connected, Serial /32 is subnetted, 2 subnets is directly connected, Loopback [110/846] via , 00:46:19, Serial0 Směrovací tabulka odpovídající VRF CustomerA-I, resp. Customer A-J obsahuje statickou cestu do přilehlé lokality zákazníka A, odpovídající přímo připojenou spojovací linku a z MB-BGP naučené cesty do obou sítí protilehlé lokality zákazníka A: I-PE#sh ip route vrf CustomerA-I /24 is subnetted, 2 subnets S [1/0] via B [200/0] via , 00:46: /24 is subnetted, 2 subnets B [200/0] via , 00:46:15 C is directly connected, Ethernet0

16 J-PE#sh ip route vrf CustomerA-J /24 is subnetted, 2 subnets B [200/0] via , 00:45:43 S [1/0] via /24 is subnetted, 2 subnets C is directly connected, Ethernet1 B [200/0] via , 00:45:43 Směrovací tabulka odpovídající VRF CustomerB-I, resp. CustomerB-J obsahuje statickou cestu do přilehlé lokality zákazníka B, odpovídající přímo připojenou spojovací linku a z MB-BGP naučené cesty do obou sítí protilehlé lokality zákazníka B: I-PE#sh ip route vrf CustomerB-I /24 is subnetted, 2 subnets S [1/0] via B [200/0] via , 00:46: /24 is subnetted, 2 subnets C is directly connected, Ethernet1 B [200/0] via , 00:46:19 J-PE#sh ip route vrf CustomerB-J /24 is subnetted, 2 subnets B [200/0] via , 00:45:47 S [1/0] via /24 is subnetted, 2 subnets B [200/0] via , 00:45:47 C is directly connected, Ethernet0 Relace MP-BGP mezi routery I-PE a J-PE Navázání relace mezi MP-BGP mezi sousedy postačí ověřit na jednou z PE routerů. Můžeme to provést např. na routeru I-PE příkazem I-PE#sh ip bgp neighbor BGP neighbor is , remote AS 100, internal link BGP version 4, remote router ID BGP state = Established, up for 01:10:46 Last read 00:00:46, hold time is 180, keepalive interval is 60 seconds Neighbor capabilities: Route refresh: advertised and received(new) Address family IPv4 Unicast: advertised and received Address family VPNv4 Unicast: advertised and received Received 191 messages, 0 notifications, 0 in queue Sent 191 messages, 0 notifications, 0 in queue Route refresh request: received 0, sent 0 Default minimum time between advertisement runs is 5 seconds For address family: IPv4 Unicast BGP table version 1, neighbor version 1 Index 1, Offset 0, Mask 0x2 0 accepted prefixes consume 0 bytes Prefix advertised 0, suppressed 0, withdrawn 0 Number of NLRIs in the update sent: max 0, min 0

17 For address family: VPNv4 Unicast BGP table version 25, neighbor version 25 Index 1, Offset 0, Mask 0x2 4 accepted prefixes consume 256 bytes Prefix advertised 8, suppressed 0, withdrawn 0 Number of NLRIs in the update sent: max 2, min 0 Všimněte si ve výpisu vyznačených položek, které indikují navázání relace i pro výměnu informací protokolové rodiny vpnv4. V tabulce cest získaných z protokolu BGP uvidíme odděleně cesty označené různými Route distinguishery. Všimněte si, že next hop do sítí ve druhém přípojném bodu odpovídá loopback adrese druhého PE-routeru; nejedná se o přímo připojený router. To je v souladu s chováním protokolu BGP - pro směrování paketů je zde třeba provést rekurzivní vyhledávání ve směrovací tabulce. I-PE#sh ip bgp vpnv4 all BGP table version is 25, local router ID is Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP,? - incomplete Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 100:1 (default for vrf CustomerA-I) *> /24 *>i / ? 0? *> /24 *>i / ? 0? Route Distinguisher: 100:2 (default for vrf CustomerB-I) *> /24 *>i / ? 0? *> /24 *>i / ? 0? J-PE#sh ip bgp vpnv4 all BGP table version is 65, local router ID is Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP,? - incomplete Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 100:1 (default for vrf CustomerA-J) *>i / ? *> /24 *>i / ? 0? *> / ? Route Distinguisher: 100:2 (default for vrf CustomerB-J) *>i / ? *> /24 *>i / ? 0? *> / ? Pro ověření funkce MPLS-VPN je vhodné vypsat tabulku protokolu BGP ve formátu, kdy k jednotlivým cestám budou uvedeny i očekávané vstupní a vkládané vystupní značky.

18 I-PE#sh ip bgp vpnv4 all tags Network Next Hop In tag/out tag Route Distinguisher: 100:1 (CustomerA-I) / /aggregate(CustomerA-I) / / notag/19 22/notag / notag/17 Route Distinguisher: 100:2 (CustomerB-I) / /aggregate(CustomerB-I) / / notag/20 24/notag / notag/18 J-PE#sh ip bgp vpnv4 tags Network Next Hop In tag/out tag Route Distinguisher: 100:1 (CustomerA-J) / notag/ / / /aggregate(CustomerA-J) notag/ / /notag Route Distinguisher: 100:2 (CustomerB-J) / notag/ / / /aggregate(CustomerB-J) notag/ / /notag Next-hop označujte tento router a je uveden u řádků pro sítě přímo připojené k routeru. S e značkou v příchozím paketu, která v tomto případě jednoznačně určuje VRF na přijímajícím routeru, se v tomto případě provede operace Aggregate, tj. odstranění a následné vyhledání další cesty podle cílové adresy v příslušné VRF. Pokud by při operaci Aggregate právě odstraněná značka nebyla poslední v zásobníku, paket se zahodí. Sítě uvnitř lokalit zákazníků (100.0.x.x) jsou uvedeny s výstupní značkou Notag a adresou next-hop patřící do VRF příslušné lokality. Příjde-li tedy na PE router paket se značkou (jednoznačně) určující některou z těchto sítí, přepošle se na uvedený next-hop a to beze značky. Cesty do sítí v protějším přípojném bodě mají jako next-hop loopback adresu protějšího PE routeru. Jedná se vždy o vnitřní síť protější lokality každé VPN a o spojovací linku od PE routeru k CE routeru, k němuž je tato vnitřní síť připojena. Pakety pro tyto sítě budou označovány značkou, určující VRF, podle níž se má paket došlý na protější PE router směrovat. Prozkoumejte značky pro VPN zákazníka A a to pro přenos paketů z ostravského přípojného bodu do tachovského. U paketů přišlých z rozhraní zařazených do VRF CustomerA-I označuje ostravský router I-PE pakety pro síť /24 značkou 19 a pakety pro síť /24 značkou 17. Následně je zasílá na next-hop Pro tuto adresu najde v LFIB odchozí značku 17, kterou k paketu rovněž připojí (zásobník značek pak bude obsahovat 2 úrovně-na vrcholu bude značka pro směrování v páteři a značka určující VRF a konkrétní síť z této VRF v rámci přijímajícího PE routeru bude pod vrcholem). Z LFIB routeru G-P vidíme, že G-P u paketů došlých od I-PE se značkou 17 značku odstraní (POP) a pošle je rozhraním k routeru J-PE. J-PE tak dostane paket pouze s jedinou značkou, která určuje VRF a v ní jednoznačně cílovou síť. Všimněte si, že vstupní značku 19 pro síť /24 a vstupní značku 17 pro síť /24 přidělil tachovský router J- PE a tuto informaci předal pomocí relace MP-BGP ostravskému routeru I-PE. Při pohledu do LFIB routeru J-PE (viz dále) zjistíme, že pro příchozí značku 17 se paket netagovaný pošle na next-hop rozhraním Ethernet 1, zatímco pro paket s příchozí značkou 19 se provede operace Aggregate a vyhledání dalšího skoku ve směrovací tabulce. Protože se jedná o přímo připojenou síť, bude před odesláním konečnému příjemci také nutné sáhnout do ARP tabulky příslušného rozhraní.

19 Obdobné návaznosti značek můžete vysledovat pro přenos paketů z tachovského přípojného bodu do ostravského. U VPN zákazníka B budou návaznosti značek analogické jako u VPN zákazníka A. Pro shrnutí uveďme, jak budou vypadat zásobníky značek paketů odesílaných routerem I-PE a J-PE a určených pro sítě v lokalitách připojených k protějšímu routeru. Značka zapsaná nejvíce vlevo je na vrcholu zásobníku: Pakety odcházející z I-PE ke G-P: [17,20] : pakety pro síť /24 zákazníka B na PE-routeru J-PE [17,18] : pakety pro síť /24 zákazníka B na PE-routeru J-PE [17,19] : pakety pro síť /24 zákazníka A na PE-routeru J-PE [17,17] : pakety pro síť /24 zákazníka A na PE-routeru J-PE Pakety odcházející z J-PE ke G-P: [16,25] : pakety pro síť /24 zákazníka B na PE-routeru I-PE [16,24] : pakety pro síť /24 zákazníka B na PE-routeru I-PE [16,23] : pakety pro síť /24 zákazníka A na PE-routeru I-PE [16,22] : pakety pro síť /24 zákazníka A na PE-routeru I-PE Zásobník značek přidělený PE routerem můžeme ověřit na P routeru G-P výpisem všech paketů, které byly přeposlány tag switchingem: G-P# debug tag-switching packets 04:07:19: TAG: Se1/0: recvd: CoS=0, TTL=255, Tag(s)=17/19 04:07:19: TAG: Se1/1: xmit: CoS=0, TTL=254, Tag(s)=19 04:07:19: TAG: Se1/1: recvd: CoS=0, TTL=255, Tag(s)=16/23 04:07:19: TAG: Se1/0: xmit: CoS=0, TTL=254, Tag(s)=23 Uvedený výpis odpovídá průchodu zprávy echo-request (ping) ze sítě /24 CustomerA-I na některou adresu sítě /24 CustomerA-J a zaslání zprávy echo-reply zpět. Značky, resp. zásobníky značek vkládané do odesílaných paketů PE routery můžeme vidět také na příkazu trace: I-PE#trace vrf CustomerA-I [MPLS: Labels 17/19 Exp 0] 80 msec 76 msec 80 msec msec * 28 msec I-PE# I-PE#trace vrf CustomerB-I [MPLS: Labels 17/20 Exp 0] 80 msec 84 msec 80 msec msec * 28 msec I-PE# Vnější label 17 identifikuje exit point z páteře, vnitřní labely 19, resp. 20 identifikují VRF v routeru J-PE.

20 LFIB I-PE a J-PE Zásobníkům značek uvedeným výše odpovídají i LFIB routerů I-PE a J-PE: I-PE#sh tag-switching forwarding-table Local Outgoing Prefix Bytes tag Outgoing Next Hop tag 20 tag or VC Pop tag or Tunnel Id /24 switched 0 interface Se0 point2point /32 0 Se0 point2point Untagged Aggregate /24[V] /24[V] Et Untagged Aggregate /24[V] /24[V] Et Vstupní značky 25,24,23 a 22 odpovídají jednotlivým sítím v lokalitách připojených k I-PE. Srovnejte je s výše uvedenými zásobníky značek, jak jsou do paketů vkládány routerem J-PE při zasílání směrem k routeru G-P. Poté, co router G-P před zasláním paketu na cílový PE router I-PE odstraní značku pro směrování v páteři, dojde na I-PE paket označkovaný pouze některou z těchto vnitřních značek. Operace Aggregate uvedená u značek 23 a 25 odpovídá zaslání paketu na spojovací linku lokality některého ze zákazníků, naopak přeposílání neznačkovaných paketů rozhraním Ethernet0, resp. Ethernet1 u značek 22, resp. 24 odpovídá zaslání paketu do vnitřní sítě lokalit obou zákazníků. Řádek s operací Pop tag pro síť /24 je penultimate hop behavior a využil by se v případě, že by k routeru I-PE byl připojen ještě další MPLS router, který by pro doručení paketů do sítě /24 využil routerem I-PE nabízené značky 20. Analogicky LFIB routeru J-PE obsahuje záznamy pro značky, které při směrování paketů do sítí lokalit připojených k routeru J-PE přes router G-P vkládá router I-PE jako vnitřní značky. J-PE#sh tag-switching forwarding-table Local Outgoing tag tag or VC Prefix or Tunnel Id Bytes tag Outgoing switched interface Next Hop Pop tag Untagged / /24[V] Se0 Et1 point2point Untagged /24[V] 1856 Et Aggregate Aggregate /24[V] /24[V] J-PE# /32 0 Se0 point2point Mimo značek pro jednotlivé sítě obou VPN obsahuje LFIB obou routerů i odchozí značky pro doručování paketů na loopback protějšího PE-routeru (17, resp. 16). Všimněte si, že cesty do sítí, které tvoří VPN, jsou ve výpisech LFIB označeny symbolem V.

21 Použití dynamických směrovacích protokolů mezi CE a PE V předchozí konfiguraci dosahovaly PE routery zákaznických sítí pomocí na nich nakonfigurovaných statických cest. Někdy je však výhodnější propagovat cesty ze zákaznické sítě z CE routeru na PE router s použitím dynamického směrovacího protokolu. IOS v současné době pro tyto účely počítá s protokoly OSPF, RIP v.2 a externím BGP. Příklad 1: RIP v.2 u obou lokalit CustomerA Změňme nyní přechozí konfiguraci obsahující redistribuci statických záznamů na PE routerech do MP-BGP tak, aby cesty z ostravské i tachovské lokality zákazníka CustomerA byly na PE routery propagovány pomocí RIP v.2. CustomerA /24 lo0 CustomerB /24 lo0 E-CE /24 e1 F-CE.2.2 OSTRAVA.1.1 RIP v.2 I-PE /24 TACHOV / J-PE RIP v C-CE D-CE CustomerB lo /24 CustomerA /24 lo /24 Z routerů I-PE a J-PE odstraníme statické cesty do sítě zákazníka CustomerA z VRF CustomerA-I a CustomerA-J. Na CE routerech E a D nakonfigurujeme normální RIP verze 2: E: router rip version 2 network network no auto-summary D: router rip version 2 network network no auto-summary Na routerech I-PE a J-PE musíme provozovat několik instancí protokolu RIP vždy jednu nezávislou pro každou VRF. Protože RIP je v IOS implementován tak, že jeho proces může být spouštěn pouze jedenkrát, řeší se nezávislé instance RIP pro adresové rodiny odpovídající jednotlivým VRF pomocí oddělených směrovacích kontextů (routing context) v rámci společného procesu RIP. I-PE:

22 J-PE: router rip version 2 address-family ipv4 vrf CustomerA-I version 2 redistribute bgp 100 metric 10 network no auto-summary exit-address-family router rip version 2 address-family ipv4 vrf CustomerA-J version 2 redistribute bgp 100 metric 10 network no auto-summary exit-address-family Protože do protokolu RIP chceme k CE routeru redistribuovat i cesty do vzdálené lokality zákazníka CustomerA, přidali jsme do konfigurace směrovacího kontextu v protokolu RIP příkaz redistribute bgp pro redistribuci cest získaných do příslušné VRF prostřednictvím MP-BGP do protokolu RIP (s implicitní výchozí metrikou 10). Musíme také zajistit, aby se informace o cestách propagovaných pomocí RIP z CE routeru a vložené do VRF zákazníka CustomerA redistribuovaly do protokomu MP-BGP. Proto do sekce adresové rodiny VRF CustomerA-I (resp. CustomerA-J) konfigurace routeru BGP v AS 100 na I-PE i J-PE přidáme příkaz redistribute rip Z adresové rodiny MP-BGP pro VRF CustomerA-I, resp. CustomerA-J také na PE routerech odstraníme redistribuci přímo připojených sítí a statických cest (redistribute static a redistribute connected), které zde zbyly z předešlé konfigurace. Kontrola funkčnosti Na routerech I-PE, J-PE zkontrolujeme obsah VRF CustomerA-I, resp. CustomerA-J příkazem resp. sh ip route vrf CustomerA-I sh ip route vrf CustomerA-J Ve směrovací tabulce každé VRF by měly být záznamy označené písmenem R o zákaznických sítích propagovaných z CE routeru protokolem RIP. Na routerech E a D si vypište směrovací tabulku příkazem sh ip route Zde by měly být vidět od protokolu RIP naučené cesty do sítí ve druhé lokalitě zákazníka CustomerA. Ty byly do RIPu redistribuovány z příslušné VRF na přilehlém PE routery, do níž se dostaly pomocí protokolu MP-BGP.

23 E#sh ip route /24 is subnetted, 2 subnets C is directly connected, Loopback0 R [120/10] via , 00:00:09, Ethernet /24 is subnetted, 2 subnets R [120/10] via , 00:00:09, Ethernet0 C is directly connected, Ethernet0 D#sh ip route R C C R /24 is subnetted, 2 subnets [120/10] via , 00:00:10, Ethernet is directly connected, Loopback /24 is subnetted, 2 subnets is directly connected, Ethernet [120/10] via , 00:00:10, Ethernet0

24 Příklad 2: RIPv2 v ostravském lokalitě a OSPF v tachovské lokalitě CustomerB Zákazník CustomerB bude své cesty k PE routeru v ostravském přípojném bodu propagovat pomocí RIPv2, zatímco k PE routeru v tachovském přípojném bodu pomocí OSPF. OSPF bude pro jednoduchost využívat pouze jediné (páteřní) oblasti area 0. Propagování cest z obou lokalit CustomerB zůstává jako v předchozím případě pomocí protokolu RIPv2. CustomerA /24 lo0 CustomerB /24 lo0 E-CE /24 e1 F-CE.2.2 OSTRAVA.1.1 RIP v.2 I-PE RIP v /24 TACHOV OSPF J-PE RIP v.2 C-CE.2 lo / D-CE CustomerB /24 CustomerA /24 lo /24 Konfigurace CE routerů F (Ostrava) a C (Tachov) zákazníka CustomerB jsou následující: F: C: router rip version 2 network network no auto-summary router ospf 1 network area 0 network area 0 Konfigurace RIP na routeru I-PE bude obdobná jako v předchozím příkladu pro zákazníka CustomerA do procesu RIP musíme přidat samostatný routing context pro VRF CustomerB-I a redistribuovat do něj informace z MP-BGP: I-PE: router rip address-family ipv4 vrf CustomerB-I version 2 redistribute bgp 100 metric 10 network no auto-summary exit-address-family Dále musíme cesty od RIP z VRF CustomerB-I redistribuovat do adresové rodiny BGP odpovídající VRF CustomerB-I. Původní redistribuci přímo připojených sítí a statických cest z této adresové rodiny odstraníme.

25 I-PE: router bgp 100 address-family ipv4 vrf CustomerB-I no redistribute static no redistribute connected redistribute rip exit-address-family Směrovací tabulka VRF CustomerB-I by nyní měla obsahovat mimo přímo připojené sítě také sítě z přilehlé lokality zákazníka CustomerB naučené od RIP a sítě ze vzdálené lokality zákazníka CustomerB naučené od protokolu MP-BGP: I-PE#sh ip route vrf CustomerB-I /24 is subnetted, 1 subnets R [120/1] via , 00:00:01, Ethernet /24 is subnetted, 2 subnets C is directly connected, Ethernet1 B [200/0] via , 01:11:29 I-PE# Na routeru J-PE budeme získávat cesty do sítí tamnější lokality zákazníka CustomerB pomocí OSPF. K tomu účelu nastartujeme samostatný proces OSPF, který svážeme s příslušnou VRF. Do OSPF budeme redistribuovat informace z MP-BGP; naopak z MP-BGP budeme redistribuovat informace do OSPF, aby tachovská lokalita CustomerB získala cesty do sítí lokality ostravské: J-PE: router ospf 2 vrf CustomerB-J network area 0 redistribute bgp 100 metric 1000 subnets Redistribuci cest z procesu OSPF 2 do MP-BGP musíme přidat i do address family MP-BGP odpovídající VRF CustomerB-J. Přitom z této adresové rodiny odstraníme redistribuci přímo připojených cest a statických záznamů, která přetrvala z přechozí konfigurace.: router bgp 100 address-family ipv4 vrf CustomerB-J redistribute ospf 2 metric 1 no redistribute connected no redistribute static exit-address-family Kontrola konektivity Na J-PE zkontrolujeme sousedy procesu 2 protokolu OSPF: J-PE#sh ip ospf 2 neighbor Neighbor ID Pri 1 State FULL/DR Dead Time 00:00:34 Address Interface Ethernet0 J-PE# Výpisem informací o procesu 2 protokolu OSPF zjistíme jeho vazby na MPLS: J-PE#sh ip ospf 2 Routing Process "ospf 2" with ID and Domain ID Supports only single TOS(TOS0) routes Supports opaque LSA Connected to MPLS VPN Superbackbone

26 It is an area border and autonomous system boundary router Redistributing External Routes from, bgp 100 with metric mapped to 1000, includes subnets in redistribution SPF schedule delay 5 secs, Hold time between two SPFs 10 secs Minimum LSA interval 5 secs. Minimum LSA arrival 1 secs LSA group pacing timer 240 secs Interface flood pacing timer 33 msecs Retransmission pacing timer 66 msecs Number of external LSA 2. Checksum Sum 0xD2CD Number of opaque AS LSA 0. Checksum Sum 0x0 Number of DCbitless external and opaque AS LSA 0 Number of DoNotAge external and opaque AS LSA 0 Number of areas in this router is 1. 1 normal 0 stub 0 nssa External flood list length 0 Area BACKBONE(0) Number of interfaces in this area is 1 Area has no authentication SPF algorithm executed 4 times Area ranges are Number of LSA 3. Checksum Sum 0x2010F Number of opaque link LSA 0. Checksum Sum 0x0 Number of DCbitless LSA 0 Number of indication LSA 0 Number of DoNotAge LSA 0 Flood list length 0 Zkontrolujeme směrovací tabulky pro CustomerB na obou PE routerech: J-PE#sh ip route vrf CustomerB-J /8 is variably subnetted, 2 subnets, 2 masks O /32 [110/11] via , 00:03:48, Ethernet0 B /24 [200/1] via , 00:07: /24 is subnetted, 2 subnets B [200/0] via , 01:21:19 C is directly connected, Ethernet0 J-PE# Ve směrovací tabulce J-PE můžeme vidět cestu do vnitřní sítě naučenou od OSPF, přímo připojenou spojovací linku a cesty do ostravské lokality naučené z RIP a redistribuované přes MP- BGP. I-PE#sh ip route vrf CustomerB-I /8 is variably subnetted, 2 subnets, 2 masks B /32 [200/1] via , 00:03:42 R /24 [120/1] via , 00:00:02, Ethernet /24 is subnetted, 2 subnets C is directly connected, Ethernet1 B [200/0] via , 00:03:42 I-PE# Ve směrovací tabulce I-PE můžeme vidět cestu do vnitřní sítě naučenou od RIPv2, přímo připojenou spojovací linku a cesty do tachovské lokality naučené z OSPF a redistribuované přes MP-BGP. Všimněte si ještě směrovacích tabulek na routerech F a C:

27 F#sh ip route R C C R F# /8 is variably subnetted, 2 subnets, 2 masks /32 [120/1] via , 00:00:22, Ethernet /24 is directly connected, Loopback /24 is subnetted, 2 subnets is directly connected, Ethernet [120/1] via , 00:00:22, Ethernet0 Cesty do tachovské lokality, které se I-PE naučil přes MP-BGP, byly správně redistribuovány do RIP. C#sh ip route O E2 C O E2 C C# /24 is subnetted, 2 subnets [110/1000] via , 00:16:33, Ethernet is directly connected, Loopback /24 is subnetted, 2 subnets [110/1000] via , 00:16:33, Ethernet is directly connected, Ethernet0 Cesty do ostravské lokality, které se J-PE naučil přes MP-BGP, byly správně redistribuovány do OSPF jako externí cesty. Poznámka Pokud bychom provozovali tímto způsobem OSPF v obou lokalitách jedné VPN, získali bychom z pohledu směrování dva nezávislé autonomní systémy OSPF, mezi nimiž by MP-BGP redistribuoval cesty a jednotlivé autonomní systémy by je viděly jako cesty externí. Pokud bychom chtěli propojit oblasti OSPF v různých lokalitách tak, aby společně tvořily jeden autonomní systém OSPF, máme principiálně tyto možnosti: dvě původně nezávislé area 0 se propojí do jediné přes ISP provozující MP-BGP ISP s MP-BGP sám tvoří OSPF area 0, v lokalitách jsou pouze nepáteřní oblasti Cesty do odlehlých lokalit v obou těchto případech uvidí jako intra-as cesty. Informace o správném typu OSPF cesty se přenáší ve k tomu vyhrazených atributech MP-BGP.