Chybějící trasa ve VRF: lokální, VPNv4, nebo forwardingová tabulka?

Zákazník tvrdí, že po změně route targetu zmizel prefix, a první screenshot, který pošle, bývá špatná tabulka. Tři různé tabulky odpovídají na tři různé otázky: zda prefix ve VRF existuje, zda byl inzerován a importován jako trasa VPNv4 a zda byla skutečně nainstalována forwardingová položka. Čtení v nesprávném pořadí vede k sebevědomým a chybným závěrům. Tato příručka provede jeden lokální a jeden vzdálený prefix všemi třemi tabulkami v pořadí a skončí plánem vrácení změny pro úpravu RT, která to spustila.

Pojmenujte prefix a tabulku, do které patří

Než něco napíšete, zapište dva prefixy. Jeden je lokální pro lokalitu zákazníka, naučený z připojeného rozhraní nebo z inzerace CE. Druhý je vzdálený a očekává se, že dorazí přes páteřní síť poskytovatele. Do stejné VRF se dostávají různými cestami a závada v jedné nic neříká o druhé.

Držte rozdíl mezi oběma identifikátory jasný, protože většina zmatku v těchto tiktech z něj pochází. Rozlišovač trasy je součástí NLRI VPNv4 a existuje proto, aby jinak shodné prefixy zákazníků byly v páteřní síti jedinečné. Route target je rozšířená komunita nesená jako atribut a právě s ní porovnává politika importu a exportu. Není to druhé jméno rozlišovače a není nesen v paketech zákazníka.

Krok 1: dokažte, že prefix je ve VRF

Začněte lokálním pohledem, potom RT, které řídí import. Pokud zde lokální prefix chybí, nic výše nemůže být příčinou:

show ip route vrf CUST-A 172.21.4.0 255.255.255.0
show ip route vrf CUST-A | include 172.21.4.0
show ip vrf CUST-A

Prefix, který se zobrazuje jako připojený nebo statický, je naučený lokálně a jeho přítomnost nic neříká o tom, zda byl exportován. To je nejčastější chybné čtení v tomto postupu: zdravá tabulka VRF je důkazem jen o lokálním učení. Strana exportu je samostatná otázka, na kterou odpovídá pohled souseda a přiřazený exportní target.

Zkontrolujte seznamy RT na VRF, dokud jste tady. Pokud zamýšlený importní target v seznamu není, vše níže je irelevantní. Pokud tam je, ale liší se od toho, co exportuje vzdálený PE, našli jste závadu, aniž byste otevřeli jediný packet capture.

Krok 2: přečtěte tabulku VPNv4 a její targety

Tabulka VPNv4 ukazuje, co kontrolní rovina skutečně vyměnila. Hledejte vzdálený prefix pod správným rozlišovačem a potom se podívejte na komunity, které jsou k němu připojené:

show ip bgp vpnv4 all 10.60.9.0/24
show ip bgp vpnv4 all | include 10.60.9.0
show ip bgp vpnv4 vrf CUST-A neighbors 192.0.2.17 advertised-routes

Položka se správným route targetem, ale bez lokální instalace, ukazuje na importní politiku nebo na výběr trasy, ne na dostupnost. Položka, která se v tabulce VPNv4 vůbec neobjeví, ukazuje výše: výchozí PE ji možná neexportoval, nebo relace nenese adresní rodinu.

Existuje třetí případ, který lidi při změnách mate. Některé platformy omezují, které VPN trasy si vyžádají nebo udrží, pomocí informace o členství v route targetech, takže absence vzdálené NLRI v jednom filtrovaném pohledu není důkazem, že inzerce nikde neexistuje. Zkontrolujte nefiltrovanou tabulku a inzerované trasy souseda, než uzavřete, že trasa byla globálně stažena.

Krok 3: potvrďte, že se něco nainstalovalo a označilo

Položka BGP je rozhodnutí, ne cesta. Forwardingové tabulky říkají, zda pakety mají kam jít:

show ip cef vrf CUST-A 10.60.9.0/24
show mpls forwarding-table vrf CUST-A | include 10.60.9.0
show ip bgp vpnv4 vrf CUST-A

Položka CEF s vyřešenou sousedností a odchozím labelem znamená, že provoz v datové rovině by měl fungovat, a jakýkoli zbývající symptom patří aplikaci nebo filtrování uvnitř VRF. Položka CEF s nevyřešeným dalším skokem znamená, že cesta labelu je neúplná, i když BGP vypadá zdravě, a to je právě případ, kdy screenshot tabulky BGP zmátl revizi změny.

Porovnejte label, který lokální PE vkládá, s tím, který vzdálený PE očekává. Neshoda mezi oběma pohledy je problém přidělování labelů nebo relace a neopraví ji úprava route targetů, ať to uděláte kolikrátkoli.

Vraťte změnu RT s deklarovaným rozsahem

Pokud závada začala úpravou route targetu, zrušte ji jako jeden záměrný krok a řekněte, jaký rozsah měníte. Odebrání importního targetu ruší oprávněnost uvnitř dané VRF. Nesmaže inzerci VPNv4 z páteřní sítě a na některých platformách trasa v tabulce zůstává podržena. To jsou různé výsledky a efekt viditelný pro uživatele závisí na tom, který z nich máte na mysli.

configure terminal
vrf definition CUST-A
 address-family ipv4
  no route-target import 65000:410
 end
clear ip bgp vpnv4 vrf CUST-A soft in

Měkká vstupní rekonfigurace stačí, když relace už prefixy uchovává; tvrdý reset relace obrácené k poskytovateli v pracovní době je rozhodnutí, které má udělat někdo jiný. V Junosu ekvivalentní kontroly čtou tabulku pro jednotlivé VRF a tabulku VPN přímo a vrácení je návrat při commitu, ne rušení po jednotlivých příkazech, takže si před začátkem uložte rozdíl konfigurace.

Skončete stejnými třemi příkazy, kterými jste začali, ve stejném pořadí, a zaznamenejte jejich výstup s časovým razítkem. Tiket, který říká, že RT byl špatný a teď je správný, není znovupoužitelný; ten, který ukazuje prefix ve VRF, ve VPNv4 a nainstalovaný v CEF, je důkaz, se kterým se může další člověk porovnat. Pokud se změnily jen první dva, změnu jste nedokončili.