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.121-3.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.122-2.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.122-2.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é.
Transcript
MPLS a VPNPetr Grygárek, RCNA FEI VŠB-TU Ostrava, 2004
Platformy a ověřené verze IOSG-PIOS (tm) C2600 Software (C2600-JS56I-M), Version 12.1(3)T, RELEASE SOFTWARE (fc1)System image file is "flash:c2600-js56i-mz.121-3.T.bin"
I-PEIOS (tm) 4500 Software (C4500-JS-M), Version 12.2(2)T4, RELEASE SOFTWARE (fc3)System image file is "flash:c4500-js-mz.122-2.T4.bin"
J-PEIOS (tm) 4500 Software (C4500-JS-M), Version 12.2(2)T4, RELEASE SOFTWARE (fc3)System image file is "flash:c4500-js-mz.122-2.T4.bin"
Historická poznámkaCisco 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 ipojmenovávání příkazů souvisejících s MPLS. Novější IOSy mají také alternativní příkazypojmenová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ýchIOS 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 DistributionProtocol) 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šakfunkce 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é.
Základní funkce MPLS
Zapojte síť podle obrázku. V síti zajistěte směrování protokolem OSPF (area 0).
Konfigurace MPLS
Podmínkou pro funkci MPLS je aktivace CEF (Cisco Express Forwarding) v globálnímkonfigurač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íchrouteru 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 prodistribuci 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é cestynabí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 cestulokálním routerem.
S0I-PE G-P
S0S1/0 S1/1e0 e0
e1 e1J-PE
1.0.0.0/24 2.0.0.0/24
.1.1 .2 .2
SW
SW
SW
SW
10.0.0.1/24
10.0.1.1/24
20.0.0.1/24
20.0.1.1/24
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 retentionmode). Tedy i značka od routeru, který má cestu do dané sítě horší, než náš vlastní router (a tatocesta 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ímpropagují routery se značkou imp-null, čímž říkají sousedním routerům, že má z paketů dotěchto sítí značku odstranit (operace POP). Tím přijímající router nemusí při příchodu paketu propřímo připojené sítě provádět vyhledávání v tabulce značek jen proto, aby zjistil, že má značkuodstranit a cíl poté ještě normálně vyhledat ve směrovací tabulce podle cílové IP adresy – jdepří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 av Remote bindings pro všechny sítě přímo připojené k sousedovi, který danou značku (zde imp-null) 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žimuprostřednictvím ACL.
• Propagování značky pro default route lze povolit z globálního konfiguračního režimu příkazemtag-switching ip default-route.
Do forwarding tabulky (LFIB-Label Forwarding Information Base) jsou převzaty jen ty značky zLIB, 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 jeuvedeno dále. Je uveden obsah LIB a LFIB pro všechny routery. Prostudujte si souvislosti LIB,LFIB a směrování.
Z položky tsr (Tag-Switch Router) vidíme, že značky k I-PE propaguje pouze soused s ID 2.0.0.1(router G-P).Pro přímo připojené sítě 1.0.0.0/24, 10.0.0.0/24 a 10.0.1.0/24 je Local binding imp-null. Pro přímopřipojenou síť souseda 2.0.0.0/24 je remote binding imp-null. Router G-P nabízí značky i pro cestyvedoucí směrem k I-PE (smyčka): pro sítě 10.0.0.0/24 a 10.0.1.0/24 s jednoznačnými značkami 18a 19, pro síť 1.0.0.0/24 se značkou imp-null (je k G-P přímo připojena). Cesty do sítí 20.0.0.0/24 a20.0.1.0/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 Prefix Bytes tag Outgoing Next Hoptag tag or VC or Tunnel Id switched interface16 Pop tag 2.0.0.0/24 0 Se0 point2point17 16 20.0.0.0/24 0 Se0 point2point18 17 20.0.1.0/24 0 Se0 point2pointI-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ýmihodnotami 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íť2.0.0.0/24 (soused G-P je posledním skokem a propaguje značku imp-null). Pakety do sítí20.0.0.0/24 a 20.0.1.0/24 přicházející se značkami 17, resp. 18 budou odcházet rozhraním Se0 seznačkou 16, resp. 17.
Značky k J-PE propaguje pouze soused s ID 2.0.0.1 (tsr router G-P).Pro přímo připojené sítě 2.0.0.0/24, 20.0.0.0/24 a 20.0.1.0/24 je local binding imp-null. Pro přímopřipojenou síť souseda 1.0.0.0/24 je remote binding imp-null. Router G-P nabízí značky i pro cestyvedoucí směrem k J-PE (smyčka): pro sítě 20.0.0.0/24 a 20.0.1.0/24 s jednoznačnými značkami 16a 17, pro síť 2.0.0.0/24 se značkou imp-null (je k G-P přímo připojena). Cesty do sítí 10.0.0.0/24 a10.0.1.0/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-tableLocal Outgoing Prefix Bytes tag Outgoing Next Hoptag tag or VC or Tunnel Id switched interface16 Pop tag 1.0.0.0/24 0 Se0 point2point17 18 10.0.0.0/24 0 Se0 point2point18 19 10.0.1.0/24 0 Se0 point2pointJ-PE#
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íť 1.0.0.0/24 (sousedG-P je posledním skokem a propaguje značku imp-null). Pakety do sítí 10.0.0.0/24 a 10.0.1.0/24budou odcházet se značkou 18, resp. 19.
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ě 1.0.0.0/24 a 2.0.0.0/24.Remote binding je imp-null pro sítě, které jsou k sousedovi, který je propaguje, přímo připojeny.
G-P#show tag-switching forwarding-tableLocal Outgoing Prefix Bytes tag Outgoing Next Hoptag tag or VC or Tunnel Id switched interface16 Pop tag 20.0.0.0/24 0 Se1/1 point2point17 Pop tag 20.0.1.0/24 0 Se1/1 point2point18 Pop tag 10.0.0.0/24 0 Se1/0 point2point19 Pop tag 10.0.1.0/24 0 Se1/0 point2pointG-P#
Pakety pro sítě 1.0.0.0/24 a 2.0.0.0/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 vLFIB 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čkabude předtím odstraněna (operace POP).
Sledování provozu MPLSPro sledování zacházení se značkami můžeme využít příkazu debug na P-routeru G-P neboprotokolového analyzátoru. Značky jsou neseny v MPLS záhlavích, které se vyskytuje v datové částirá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 3.0.0.0/24 a zahrňtejej 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ělprovoz do sítí 20.0.0.0/24 a 20.0.1.0/24 procházet Ethernetem Sériová linka mezi I-PE a G-P senyní neuplatní. Zkontrolujte také v LFIB.
Připojte do HUBu síťový analyzátor. Pošlete z routeru I-PE ping do sítí 20.0.0.0/24 a 20.0.1.0/24 asledujte 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 danoucestu 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č).
Konfigurace MPLS/VPN
Síť poskytovatele zahrnuje přípojné body Ostrava a Tachov a tranzitní síť mezi nimi. Poskytovatelposkytuje 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ícidokonce 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énopříslušného routeru:
Každé VRF přiřadíme Route Distinguisher (RD), který zajistí globální jednoznačnost adres. Projednoduchý případ nepřekrývajících se VPN můžeme volit RD společný vždy pro obě VRF u VPNobou 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ůžemeoznač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 cestypropagované z dané VRF ostatním PE routerům. Zde můžeme cesty z obou VRF CustomerAoznač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 doVRF 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ů – 3.0.0.1 pro I-PE a 3.0.0.2 pro J-PE. Obě budou s maskou /32. Použití loopback rozhraní se zde jeví býtpodmínkou funkčnosti.
10.0.0.1/24
S0I-PE
Customer AG-P
S0S1/0 S1/1e0 e0
e1 e1
10.0.0.1/24
Customer A Customer B
Customer B
J-PE
10.0.1.1/24
10.0.2.1/24
1.0.0.0/24 2.0.0.0/24
.1.1 .2 .2
OSTRAVA TACHOV
Všechny výše určené parametry jsou shrnuty na následujícím obrázku:
Základní konfigurace
Zapojte a zprovozně síť podle obrázku. Směrovací protokol OSPF poběží pouze v páteřiposkytovatele, 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 MPLSAktivujte 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ýmiparametry:
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šechnycesty 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ů dopříslušných VRF. Pak na ně již můžeme vložit i duplicitní IP adresy – směrování se děje projednotlivé VRF nezávisle.
I-PE
interface Ethernet0 ip vrf forwarding CustomerA-I ip address 10.0.0.1 255.255.255.0
interface Ethernet1 ip vrf forwarding CustomerB-I ip address 10.0.0.1 255.255.255.0
J-PE
interface Ethernet0 ip vrf forwarding CustomerB-J ip address 10.0.1.1 255.255.255.0!interface Ethernet1 ip vrf forwarding CustomerA-J ip address 10.0.2.1 255.255.255.0
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é VRFnezávislá:
show ip route
Globální směrovací tabulka bude obsahovat pouze přímo připojené páteřní segmenty a informace opáteři naučené z OSPF. Nebude však již obsahovat sítě přímo připojené k lokalitám jednotlivýchzá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 naobou PE-routerech vloženými do příslušných VRF. Předpokládejme, že vnitřní struktura aadresování v lokalitách zákazníků je taková, jak ukazuje následující obrázek:
Potřebné statické cesty nakonfigurujeme v globálním konfiguračním režimu takto:
Předávání cest mezi VRF pomocí MP-BGPDále bude potřeba zprovoznit relaci Multiprotocol BGP (MP-BGP) mezi PE routery. Tento protokolbude cesty mezi jednotlivými VRF distribuovat. Protože se principiálně jedná a relace interníhoBGP (IBGP), musí být relace mezi PE routery konfigurovány v topologii „každý s každým“. RelaceIBGP nakonfigurujte mezi loopback rozhraními routerů I-PE a J-PE:
Příkazem no bgp default ipv4-unicast protokolu BGP zakážeme, aby okamžitě navázal relaci sdefinovaný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ázalspojení 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 oRD 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 2.0.0.2 send-community extended
Tím se dovolí předávání atributu COMMUNITY na daného peera (což je implicitně zakázáno) ataké 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 jednupro každou na routeru definovanou VRF. Sekce pro každou VRF obsahuje implicitně příkazy noauto-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ýchVRF redistribuovat statické cesty směřující k jednotlivým lokalitám zákazníků. Protože chcemezajistit i dosažitelnost spojovacích linek mezi ISP a lokalitami zákazníků, budeme redistribuovat ipřímo připojené sítě:
Měl by být vidět jeden soused ve stavu Established a relace pracující pro adresovou rodinu VPNv4Unicast.
Na obou routerech si vypište cesty naučené z MP-BGP (budou uspořádány podle RD, který bude ukaž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ánypatř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 routetarget 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 narouter druhé lokality cizího přístupového bodu stejné VPN. Na CE routerech nakonfigurujte pouzehostname, 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émurouteru.
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ýtpouž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 zdrojovouadresu žá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ů nadomé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.
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ě:
Local Outgoing Prefix Bytes tag Outgoing Next Hop tag tag or VC or Tunnel Id switched interface 16 Pop tag 3.0.0.1/32 17094 Se1/0 point2point 17 Pop tag 3.0.0.2/32 16339 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
Gateway of last resort is not set
1.0.0.0/24 is subnetted, 1 subnetsC 1.0.0.0 is directly connected, Serial1/0 2.0.0.0/24 is subnetted, 1 subnetsC 2.0.0.0 is directly connected, Serial1/1 3.0.0.0/32 is subnetted, 2 subnetsO 3.0.0.2 [110/782] via 2.0.0.2, 00:41:30, Serial1/1O 3.0.0.1 [110/782] via 1.0.0.1, 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ě:
Globální směrovací tabulka routerů I-PE i J-PE obsahuje pouze přímo připojenou páteřní síť aloopback rozhraní a sítě páteře naučené z OSPF:
I-PE#sh ip route
Gateway of last resort is not set
1.0.0.0/24 is subnetted, 1 subnetsC 1.0.0.0 is directly connected, Serial0 2.0.0.0/24 is subnetted, 1 subnetsO 2.0.0.0 [110/845] via 1.0.0.2, 00:42:28, Serial0 3.0.0.0/32 is subnetted, 2 subnetsO 3.0.0.2 [110/846] via 1.0.0.2, 00:42:28, Serial0C 3.0.0.1 is directly connected, Loopback0I-PE#
J-PE#sh ip route
Gateway of last resort is not set
1.0.0.0/24 is subnetted, 1 subnetsO 1.0.0.0 [110/845] via 2.0.0.1, 00:46:19, Serial0 2.0.0.0/24 is subnetted, 1 subnetsC 2.0.0.0 is directly connected, Serial0 3.0.0.0/32 is subnetted, 2 subnetsC 3.0.0.2 is directly connected, Loopback0O 3.0.0.1 [110/846] via 2.0.0.1, 00:46:19, Serial0
Směrovací tabulka odpovídající VRF CustomerA-I, resp. Customer A-J obsahuje statickou cestu dopř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
Gateway of last resort is not set
100.0.0.0/24 is subnetted, 2 subnetsS 100.0.0.0 [1/0] via 10.0.0.2B 100.0.2.0 [200/0] via 3.0.0.2, 00:46:15 10.0.0.0/24 is subnetted, 2 subnetsB 10.0.2.0 [200/0] via 3.0.0.2, 00:46:15C 10.0.0.0 is directly connected, Ethernet0
J-PE#sh ip route vrf CustomerA-J
Gateway of last resort is not set
100.0.0.0/24 is subnetted, 2 subnetsB 100.0.0.0 [200/0] via 3.0.0.1, 00:45:43S 100.0.2.0 [1/0] via 10.0.2.2 10.0.0.0/24 is subnetted, 2 subnetsC 10.0.2.0 is directly connected, Ethernet1B 10.0.0.0 [200/0] via 3.0.0.1, 00:45:43
Směrovací tabulka odpovídající VRF CustomerB-I, resp. CustomerB-J obsahuje statickou cestu dopř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
Gateway of last resort is not set
100.0.0.0/24 is subnetted, 2 subnetsS 100.0.0.0 [1/0] via 10.0.0.2B 100.0.1.0 [200/0] via 3.0.0.2, 00:46:19 10.0.0.0/24 is subnetted, 2 subnetsC 10.0.0.0 is directly connected, Ethernet1B 10.0.1.0 [200/0] via 3.0.0.2, 00:46:19
J-PE#sh ip route vrf CustomerB-J
Gateway of last resort is not set
100.0.0.0/24 is subnetted, 2 subnetsB 100.0.0.0 [200/0] via 3.0.0.1, 00:45:47S 100.0.1.0 [1/0] via 10.0.1.2 10.0.0.0/24 is subnetted, 2 subnetsB 10.0.0.0 [200/0] via 3.0.0.1, 00:45:47C 10.0.1.0 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 toprovést např. na routeru I-PE příkazem
I-PE#sh ip bgp neighbor
BGP neighbor is 3.0.0.2, remote AS 100, internal link BGP version 4, remote router ID 2.0.0.2 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
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 Routedistinguishery. Všimněte si, že next hop do sítí ve druhém přípojném bodu odpovídá loopbackadrese druhého PE-routeru; nejedná se o přímo připojený router. To je v souladu s chovánímprotokolu 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 3.0.0.1Status codes: s suppressed, d damped, h history, * valid, > best, i -internalOrigin codes: i - IGP, e - EGP, ? - incomplete
J-PE#sh ip bgp vpnv4 allBGP table version is 65, local router ID is 2.0.0.2Status codes: s suppressed, d damped, h history, * valid, > best, i -internalOrigin codes: i - IGP, e - EGP, ? - incomplete
Pro ověření funkce MPLS-VPN je vhodné vypsat tabulku protokolu BGP ve formátu, kdy kjednotlivým cestám budou uvedeny i očekávané vstupní a vkládané vystupní značky.
Next-hop 0.0.0.0 označujte „tento“ router a je uveden u řádků pro sítě přímo připojené k routeru. Se značkou v příchozím paketu, která v tomto případě jednoznačně určuje VRF na přijímajícímrouteru, 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-hoppatří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 CErouteru, 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 bodudo 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íť 10.0.2.0/24 značkou 19 a pakety pro síť 100.0.2.0/24 značkou 17.Následně je zasílá na next-hop 3.0.0.2. Pro tuto adresu najde v LFIB odchozí značku 17, kterou kpaketu rovněž připojí (zásobník značek pak bude obsahovat 2 úrovně-na vrcholu bude značka prosmě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 PErouteru bude pod vrcholem). Z LFIB routeru G-P vidíme, že G-P u paketů došlých od I-PE seznačkou 17 značku odstraní (POP) a pošle je rozhraním k routeru J-PE. J-PE tak dostane paketpouze 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íť 10.0.2.0/24 a vstupní značku 17 pro síť 100.0.2.0/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 10.0.2.2 rozhraním Ethernet 1, zatímco pro paket s příchozí značkou 19 seprovede operace Aggregate a vyhledání dalšího skoku ve směrovací tabulce. Protože se jedná opřímo připojenou síť, bude před odesláním konečnému příjemci také nutné sáhnout do ARP tabulkypříslušného rozhraní.
Obdobné návaznosti značek můžete vysledovat pro přenos paketů z tachovského přípojného bodudo 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-PEa určených pro sítě v lokalitách připojených k protějšímu routeru. Značka zapsaná nejvíce vlevo jena vrcholu zásobníku:
Pakety odcházející z I-PE ke G-P:
[17,20] : pakety pro síť 10.0.1.0/24 zákazníka B na PE-routeru J-PE[17,18] : pakety pro síť 100.0.1.0/24 zákazníka B na PE-routeru J-PE[17,19] : pakety pro síť 10.0.2.0/24 zákazníka A na PE-routeru J-PE[17,17] : pakety pro síť 100.0.2.0/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íť 10.0.0.0/24 zákazníka B na PE-routeru I-PE[16,24] : pakety pro síť 100.0.0.0/24 zákazníka B na PE-routeru I-PE[16,23] : pakety pro síť 10.0.0.0/24 zákazníka A na PE-routeru I-PE[16,22] : pakety pro síť 100.0.0.0/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:
Uvedený výpis odpovídá průchodu zprávy echo-request (ping) ze sítě 10.0.0.0/24 CustomerA-I naněkterou adresu sítě 10.0.2.0/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é napříkazu trace:
Vnější label 17 identifikuje exit point z páteře, vnitřní labely 19, resp. 20 identifikují VRF v routeruJ-PE.
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 tag or VC or Tunnel Id switched interface 20 Pop tag 2.0.0.0/24 0 Se0 point2point 21 17 3.0.0.2/32 0 Se0 point2point 22 Untagged 100.0.0.0/24[V] 1518 Et0 10.0.0.2 23 Aggregate 10.0.0.0/24[V] 1258985 24 Untagged 100.0.0.0/24[V] 1283 Et1 10.0.0.2 25 Aggregate 10.0.0.0/24[V] 7034
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řizasí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-PEodstraní značku pro směrování v páteři, dojde na I-PE paket označkovaný pouze některou z těchtovnitřních značek. Operace Aggregate uvedená u značek 23 a 25 odpovídá zaslání paketu naspojovací 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íť 2.0.0.0/24 je penultimate hop behavior avyužil by se v případě, že by k routeru I-PE byl připojen ještě další MPLS router, který by prodoručení paketů do sítě 2.0.0.0/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 Prefix Bytes tag Outgoing Next Hop tag tag or VC or Tunnel Id switched interface 16 Pop tag 1.0.0.0/24 0 Se0 point2point 17 Untagged 100.0.2.0/24[V] 1394 Et1 10.0.2.2 18 Untagged 100.0.1.0/24[V] 1856 Et0 10.0.1.2 19 Aggregate 10.0.2.0/24[V] 1276128 20 Aggregate 10.0.1.0/24[V] 10080 21 16 3.0.0.1/32 0 Se0 point2point J-PE#
Mimo značek pro jednotlivé sítě obou VPN obsahuje LFIB obou routerů i odchozí značky prodoruč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.
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 nichnakonfigurovaných statických cest. Někdy je však výhodnější propagovat cesty ze zákaznické sítě zCE routeru na PE router s použitím dynamického směrovacího protokolu. IOS v současné době protyto účely počítá s protokoly OSPF, RIP v.2 a externím BGP.
Příklad 1: RIP v.2 u obou lokalit CustomerAZměňme nyní přechozí konfiguraci obsahující redistribuci statických záznamů na PE routerech doMP-BGP tak, aby cesty z ostravské i tachovské lokality zákazníka CustomerA byly na PE routerypropagovány pomocí RIP v.2.
Z routerů I-PE a J-PE odstraníme statické cesty do sítě zákazníka CustomerA z VRF CustomerA-I aCustomerA-J.
Na CE routerech E a D nakonfigurujeme normální RIP verze 2:
E:router rip version 2 network 10.0.0.0 network 100.0.0.0 no auto-summary
D:router rip version 2 network 10.0.2.0 network 100.0.2.0 no auto-summary
Na routerech I-PE a J-PE musíme provozovat několik „instancí“ protokolu RIP – vždy jednunezávislou pro každou VRF. Protože RIP je v IOS implementován tak, že jeho proces může býtspouš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éhoprocesu RIP.
I-PE:
10.0.0.0/24e1
10.0.0.0/24
J-PE
10.0.1.0/24OSTRAVA TACHOV
C-CE
D-CE
E-CE
F-CE
lo0
lo0
lo0
lo0
100.0.0.1/24
100.0.0.1/24
100.0.1.1/24
10.0.2.0/24 100.0.2.1/24
.1.2
.1.2
I-PE
.1.2
.1.2
CustomerA
CustomerACustomerB
CustomerBRIP v.2
RIP v.2
router rip version 2 ! address-family ipv4 vrf CustomerA-I version 2 redistribute bgp 100 metric 10 network 10.0.0.0 no auto-summary exit-address-family!
J-PE: router rip version 2 ! address-family ipv4 vrf CustomerA-J version 2 redistribute bgp 100 metric 10 network 10.0.0.0 no auto-summary exit-address-family!
Protože do protokolu RIP chceme k CE routeru redistribuovat i cesty do vzdálené lokality zákazníkaCustomerA, přidali jsme do konfigurace směrovacího kontextu v protokolu RIP příkaz redistributebgp pro redistribuci cest získaných do příslušné VRF prostřednictvím MP-BGP do protokolu RIP (simplicitní 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-PEpřidáme příkaz
redistribute rip
Z adresové rodiny MP-BGP pro VRF CustomerA-I, resp. CustomerA-J také na PE routerechodstraníme redistribuci přímo připojených sítí a statických cest (redistribute static a redistributeconnected), které zde zbyly z předešlé konfigurace.
Kontrola funkčnostiNa routerech I-PE, J-PE zkontrolujeme obsah VRF CustomerA-I, resp. CustomerA-J příkazem
sh ip route vrf CustomerA-I
resp.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ýchsítích propagovaných z CE routeru protokolem RIP.
Na routerech E a D si vypište směrovací tabulku příkazemsh ip route
Zde by měly být vidět od protokolu RIP naučené cesty do sítí ve druhé lokalitě zákazníkaCustomerA. Ty byly do RIPu redistribuovány z příslušné VRF na přilehlém PE routery, do níž sedostaly pomocí protokolu MP-BGP.
E#sh ip route
Gateway of last resort is not set 100.0.0.0/24 is subnetted, 2 subnetsC 100.0.0.0 is directly connected, Loopback0R 100.0.2.0 [120/10] via 10.0.0.1, 00:00:09, Ethernet0 10.0.0.0/24 is subnetted, 2 subnetsR 10.0.2.0 [120/10] via 10.0.0.1, 00:00:09, Ethernet0C 10.0.0.0 is directly connected, Ethernet0
D#sh ip route
Gateway of last resort is not set
100.0.0.0/24 is subnetted, 2 subnetsR 100.0.0.0 [120/10] via 10.0.2.1, 00:00:10, Ethernet0C 100.0.2.0 is directly connected, Loopback0 10.0.0.0/24 is subnetted, 2 subnetsC 10.0.2.0 is directly connected, Ethernet0R 10.0.0.0 [120/10] via 10.0.2.1, 00:00:10, Ethernet0
Příklad 2: RIPv2 v ostravském lokalitě a OSPF v tachovské lokalitě CustomerBZá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 projednoduchost využívat pouze jediné (páteřní) oblasti – area 0. Propagování cest z obou lokalitCustomerB zůstává jako v předchozím případě pomocí protokolu RIPv2.
Konfigurace CE routerů F (Ostrava) a C (Tachov) zákazníka CustomerB jsou následující:
F: router rip version 2 network 10.0.0.0 network 100.0.0.0 no auto-summary
C:router ospf 1 network 10.0.1.0 0.0.0.255 area 0 network 100.0.1.0 0.0.0.255 area 0
Konfigurace RIP na routeru I-PE bude obdobná jako v předchozím příkladu pro zákazníkaCustomerA – do procesu RIP musíme přidat samostatný routing context pro VRF CustomerB-I aredistribuovat 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 10.0.0.0 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.
no redistribute staticno redistribute connectedredistribute 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ě zpřilehlé lokality zákazníka CustomerB naučené od RIP a sítě ze vzdálené lokality zákazníkaCustomerB naučené od protokolu MP-BGP:
I-PE#sh ip route vrf CustomerB-IGateway of last resort is not set 100.0.0.0/24 is subnetted, 1 subnetsR 100.0.0.0 [120/1] via 10.0.0.2, 00:00:01, Ethernet1 10.0.0.0/24 is subnetted, 2 subnetsC 10.0.0.0 is directly connected, Ethernet1B 10.0.1.0 [200/0] via 3.0.0.2, 01:11:29I-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. DoOSPF budeme redistribuovat informace z MP-BGP; naopak z MP-BGP budeme redistribuovatinformace do OSPF, aby tachovská lokalita CustomerB získala cesty do sítí lokality ostravské:
Redistribuci cest z procesu OSPF 2 do MP-BGP musíme přidat i do address family MP-BGPodpovídající VRF CustomerB-J. Přitom z této adresové rodiny odstraníme redistribuci přímopř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 neighborNeighbor ID Pri State Dead Time Address Interface100.0.1.1 1 FULL/DR 00:00:34 10.0.1.2 Ethernet0J-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 10.0.1.1 and Domain ID 0.0.0.2 Supports only single TOS(TOS0) routes Supports opaque LSA Connected to MPLS VPN Superbackbone
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-JGateway of last resort is not set
100.0.0.0/8 is variably subnetted, 2 subnets, 2 masksO 100.0.1.1/32 [110/11] via 10.0.1.2, 00:03:48, Ethernet0B 100.0.0.0/24 [200/1] via 3.0.0.1, 00:07:02 10.0.0.0/24 is subnetted, 2 subnetsB 10.0.0.0 [200/0] via 3.0.0.1, 01:21:19C 10.0.1.0 is directly connected, Ethernet0J-PE#
Ve směrovací tabulce J-PE můžeme vidět cestu do vnitřní sítě naučenou od OSPF, přímopř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-IGateway of last resort is not set
100.0.0.0/8 is variably subnetted, 2 subnets, 2 masksB 100.0.1.1/32 [200/1] via 3.0.0.2, 00:03:42R 100.0.0.0/24 [120/1] via 10.0.0.2, 00:00:02, Ethernet1 10.0.0.0/24 is subnetted, 2 subnetsC 10.0.0.0 is directly connected, Ethernet1B 10.0.1.0 [200/0] via 3.0.0.2, 00:03:42I-PE#
Ve směrovací tabulce I-PE můžeme vidět cestu do vnitřní sítě naučenou od RIPv2, přímopřipojenou spojovací linku a cesty do tachovské lokality naučené z OSPF a redistribuované přesMP-BGP.
Všimněte si ještě směrovacích tabulek na routerech F a C:
F#sh ip routeGateway of last resort is not set
100.0.0.0/8 is variably subnetted, 2 subnets, 2 masksR 100.0.1.1/32 [120/1] via 10.0.0.1, 00:00:22, Ethernet0C 100.0.0.0/24 is directly connected, Loopback0 10.0.0.0/24 is subnetted, 2 subnetsC 10.0.0.0 is directly connected, Ethernet0R 10.0.1.0 [120/1] via 10.0.0.1, 00:00:22, Ethernet0F#
Cesty do tachovské lokality, které se I-PE naučil přes MP-BGP, byly správně redistribuovány doRIP.
C#sh ip routeGateway of last resort is not set
100.0.0.0/24 is subnetted, 2 subnetsO E2 100.0.0.0 [110/1000] via 10.0.1.1, 00:16:33, Ethernet0C 100.0.1.0 is directly connected, Loopback0 10.0.0.0/24 is subnetted, 2 subnetsO E2 10.0.0.0 [110/1000] via 10.0.1.1, 00:16:33, Ethernet0C 10.0.1.0 is directly connected, Ethernet0C#
Cesty do ostravské lokality, které se J-PE naučil přes MP-BGP, byly správně redistribuovány doOSPF jako externí cesty.
Poznámka
Pokud bychom provozovali tímto způsobem OSPF v obou lokalitách jedné VPN, získali bychom zpohledu směrování dva nezávislé autonomní systémy OSPF, mezi nimiž by MP-BGP redistribuovalcesty 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 jedenautonomní 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émtypu OSPF cesty se přenáší ve k tomu vyhrazených atributech MP-BGP.
Překrývající se VPN
Vyzkoušejme ještě možnost překrývajících se VPN. Mimo vzájemné konektivity mezi lokalitamikaždého zákazníka chceme nyní navíc zajistit konektivitu mezi tachovskými lokalitami zákazníkůCustomerA a Customer B (tj. VRF CustomerA-J a CustomerB-J). Tento způsob překrytí VPN simůžeme dovolit, jelikož při něm nedochází k překrytí adresních rozsahů IP pro žádnou dvojicivzájemně dostupných lokalit.
Nejprve ověříme, zda route distinguishers tak, jak jsou navrženy, zajišťují jednoznačnost adres. Vnašem případě tomu tak je, protože shodné IP adresy jsou pouze v ostravských lokalitách obouzákazníků a příslušné VRF se liší route distinguishery.
Jednotlivé VRF budou do MP-BGP exportovány pod jednoznačnými Route Targets. První čáslicebude označovat zákazníka (1=CustomerA, 2=CustomerB), druhá pak lokalitu (1=Ostrava-router I, 2=Tachov-router J):
Route Targets:
CustomerA-I: 100:11CustomerB-I: 100:21
CustomerA-J: 100:12
CustomerB-J: 100:22
Přiřazení parametrů jednotlivým VRF vidíme na následujícím obrázku:
Jednotlivé VRF pak budou importovat informace z těchto ostatních VRF:
CustomerA-I:
100:12 (Customer A-J)
CustomerB-I: 100:22 (Customer B-J)
10.0.0.1/24
S0I-PE
Customer AG-P
S0S1/0 S1/1e0 e0
e1 e1
10.0.0.1/24
Customer A Customer B
Customer B
J-PE
10.0.1.1/24
10.0.2.1/24
1.0.0.0/24 2.0.0.0/24
.1.1 .2 .2lo0 lo03.0.0.1/32 3.0.0.2/32
VRFCustomerA-I
VRFCustomerA-JVRF
CustomerB-I
VRFCustomerB-J
RD 100:2RT 100:21
RD 100:2RT 100:22
RD 100:1RT 100:11
RD 100:1RT 100::12
OSTRAVA TACHOV
CustomerA-J:
100:11 (CustomerA-I) 100:22 (CustomerB-J) *
CustomerB-J:
100:21 (CustomerB-I)
100:12 (CustomerA-J) *
Položky označené hvězdičkou zajišťují požadované překrytí VPN. Všimněte si, že komunikacemusí být obousměrná, takže pokud do VRF CustomerA-J naimportujeme cesty z VRF CustomerB-J, musíme i do VRF CustomerB-J naimportovat cesty z VRF CustomerA-J.
Export a import do jednotlivých VRF na obou routerech I-PE a J-PE nakonfigurujeme takto:
Kontrola funkčnostiFunkčnost zkontrolujeme jednak pohledem do směrovacích tabulek odpovídajících jednotlivýmVRF na routerech I-PE a J-PE a dále pak napojením na každý z CE routeru pomocí Telnetu aověřením identity routeru, na který jsme se napojili.
I-PE#sh ip route vrf CustomerA-I
Gateway of last resort is not set 100.0.0.0/24 is subnetted, 2 subnetsS 100.0.0.0 [1/0] via 10.0.0.2B 100.0.2.0 [200/0] via 3.0.0.2, 00:00:20 10.0.0.0/24 is subnetted, 2 subnetsB 10.0.2.0 [200/0] via 3.0.0.2, 00:00:20C 10.0.0.0 is directly connected, Ethernet0
Zákazník A v Ostravě vidí pouze dvě cesty z tachovské pobočky zákazníka A.
I-PE#sh ip route vrf CustomerB-I
Gateway of last resort is not set 100.0.0.0/24 is subnetted, 2 subnetsS 100.0.0.0 [1/0] via 10.0.0.2B 100.0.1.0 [200/0] via 3.0.0.2, 00:00:56 10.0.0.0/24 is subnetted, 2 subnetsC 10.0.0.0 is directly connected, Ethernet1B 10.0.1.0 [200/0] via 3.0.0.2, 00:00:56
Zákazník B v Ostravě vidí pouze dvě cesty z tachovské pobočky zákazníka B.
J-PE#sh ip route vrf CustomerA-J
Gateway of last resort is not set
100.0.0.0/24 is subnetted, 3 subnetsB 100.0.0.0 [200/0] via 3.0.0.1, 00:07:41B 100.0.1.0 is directly connected, 00:07:41S 100.0.2.0 [1/0] via 10.0.2.2 10.0.0.0/24 is subnetted, 3 subnetsC 10.0.2.0 is directly connected, Ethernet1B 10.0.0.0 [200/0] via 3.0.0.1, 00:07:41B 10.0.1.0 is directly connected, 00:07:41, Ethernet0
Zákazník A v Tachově správně vidí dvě cesty ostravské pobočky zákazníka A (via 3.0.0.1) a dvědalší cesty do tachovské pobočky zákazníka B (B+directly connected).
J-PE#sh ip route vrf CustomerB-JGateway of last resort is not set
100.0.0.0/24 is subnetted, 3 subnetsB 100.0.0.0 [200/0] via 3.0.0.1, 00:01:15S 100.0.1.0 [1/0] via 10.0.1.2B 100.0.2.0 is directly connected, 00:01:31 10.0.0.0/24 is subnetted, 3 subnetsB 10.0.2.0 is directly connected, 00:01:31, Ethernet1B 10.0.0.0 [200/0] via 3.0.0.1, 00:01:15C 10.0.1.0 is directly connected, Ethernet0
Zákazník B v Tachově správně vidí dvě cesty ostravské pobočky zákazníka B (via 3.0.0.1) a dvědalší cesty do tachovské pobočky zákazníka A (B+directly connected).
Globální směrovací tabulky I-PE a J-PE by měly obsahovat pouze páteřní sítě:J-PE#sh ip routeGateway of last resort is not set
1.0.0.0/24 is subnetted, 1 subnetsO 1.0.0.0 [110/845] via 2.0.0.1, 00:08:36, Serial0 2.0.0.0/24 is subnetted, 1 subnetsC 2.0.0.0 is directly connected, Serial0 3.0.0.0/32 is subnetted, 2 subnetsC 3.0.0.2 is directly connected, Loopback0O 3.0.0.1 [110/846] via 2.0.0.1, 00:08:36, Serial0
I-PE#sh ip routeGateway of last resort is not set
1.0.0.0/24 is subnetted, 1 subnetsC 1.0.0.0 is directly connected, Serial0 2.0.0.0/24 is subnetted, 1 subnetsO 2.0.0.0 [110/845] via 1.0.0.2, 00:09:03, Serial0 3.0.0.0/32 is subnetted, 2 subnetsO 3.0.0.2 [110/846] via 1.0.0.2, 00:09:03, Serial0C 3.0.0.1 is directly connected, Loopback0
Připojte nyní k PE routerům CE routery a nakonfigurujte na nich adresu rozhraní k PE routeru ajednu další síť simulovanou loopbackem podle následujícího obrázku:
Nakonfigurujte static default route na PE router. Pojmenujte router a umožněte telnet na něj. Pakvyzkoušejte ze všech C routerů možnost telnetového spojení na ostatní C routery. Zkuste vždy telnetna interface připojený k PE routeru na na loopback interface simulující zákaznickou síť. Podlehostname zobrazovaného jako prompt vždy ověřte, zda jste se dostali na ten fyzický router, na kterýjste očekávali.
Příklad konfigurace pro C-router D:
hostname D!interface Loopback0 ip address 100.0.2.1 255.255.255.0 no shutdown!interface Ethernet0 ip address 10.0.2.2 255.255.255.0 no shutdown!ip route 0.0.0.0 0.0.0.0 10.0.2.1!line vty 0 4 password cisco login
10.0.0.0/24
e1
10.0.0.0/24
J-PE
10.0.1.0/24OSTRAVA TACHOV
C-CE
D-CE
E-CE
F-CE
lo0
lo0
lo0
lo0
100.0.0.1/24
100.0.0.1/24
100.0.1.1/24
10.0.2.0/24
100.0.2.1/24
.1.2
.1.2
I-PE
.1.2
.1.2
CustomerA
CustomerACustomerB
CustomerB
Slovníček příkazů tag-switching – MPLStag-switching ip mpls ip
sh tag-switching interfaces sh mpls interfaces
sh tag-switching tdp neighbor sh mpls ldp neighbors
sh tag-switching forwarding-table sh mpls forwarding-table
