Saknad rutt i VRF: lokal, VPNv4 eller vidarebefordringstabell?

En kund säger att ett prefix saknas efter en ändring av rutmålet, och den första skärmbild de skickar är oftast fel tabell. Tre olika tabeller svarar på tre olika frågor: om prefixet finns inne i VRF, om det annonserades och importerades som en VPNv4-rutt, och om en vidarebefordringspost verkligen installerades. Att läsa dem i fel ordning ger självsäkra och felaktiga slutsatser. Den här runboken för ett lokalt och ett avlägset prefix genom alla tre tabellerna i ordning, och avslutas med en återställningsplan för den RT-ändring som startade det.

Namnge prefixet och tabellen det hör hemma i

Skriv ned två prefix innan du skriver något. Det ena är lokalt på kundens plats, inlärt från ett anslutet gränssnitt eller en CE-annons. Det andra är avlägset och väntas komma via leverantörens stamnät. De tar olika vägar in i samma VRF, och ett fel i det ena säger ingenting om det andra.

Håll skillnaden mellan de två identifierarna tydlig, för det mesta av förvirringen i dessa ärenden kommer därifrån. Ruturskiljaren är en del av VPNv4-NLRI:n och finns för att göra annars identiska kundprefix unika över stamnätet. Rutmålet är en utökad community som bärs som attribut, och det är mot det som import- och exportpolicyn matchar. Det är inte ett andra namn för urskiljaren och det bärs inte i kundens paket.

Steg 1: bevisa att prefixet finns i VRF

Börja med den lokala vyn, sedan de RT som styr importen. Om det lokala prefixet saknas här kan ingenting ovanför vara orsaken:

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

Ett prefix som visas som anslutet eller statiskt är inlärt lokalt, och dess närvaro säger ingenting om huruvida det exporterades. Det är den vanligaste felläsningen i det här arbetsflödet: en frisk VRF-tabell är bara bevis om lokal inlärning. Exportsidan är en separat fråga, som grannvyn och det kopplade exportmålet svarar på.

Kontrollera RT-listorna på VRF medan du är här. Om det avsedda importmålet inte finns i listan är allt nedanför irrelevant. Om det finns men skiljer sig från det som den avlägsna PE:n exporterar, har du hittat felet utan att öppna en enda paketinsamling.

Steg 2: läs VPNv4-tabellen och dess mål

VPNv4-tabellen visar vad kontrollplanet faktiskt utbytte. Leta efter det avlägsna prefixet under rätt urskiljare och titta sedan på de communities som är kopplade till det:

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

En post med rätt rutmål men utan lokal installation pekar på importpolicyn eller på ruttvalet, inte på nåbarhet. En post som inte alls syns i VPNv4-tabellen pekar uppåt: käll-PE:n kanske inte exporterade den, eller så bär sessionen inte adressfamiljen.

Det finns ett tredje fall som förvirrar folk under ändringar. Vissa plattformar begränsar vilka VPN-rutter de begär eller behåller, med hjälp av medlemskapsinformation för rutmål, så avsaknaden av en avlägsen NLRI i en filtrerad vy är inte bevis för att annonsen inte finns någonstans. Kontrollera den ofiltrerade tabellen och grannens annonserade rutter innan du drar slutsatsen att en rutt drogs tillbaka globalt.

Steg 3: bekräfta att något installerades och märktes

En BGP-post är ett beslut, inte en väg. Vidarebefordringstabellerna säger om paketen har någonstans att ta vägen:

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

En CEF-post med löst grannskap och en utgående etikett betyder att dataplanstrafik borde fungera, och varje kvarvarande symptom hör till applikationen eller till filtrering inne i VRF. En CEF-post som visar ett olöst nästa hopp betyder att etikettvägen är ofullständig trots att BGP ser frisk ut, och det är precis det fall där en skärmbild av BGP-tabellen vilseledde en ändringsgranskning.

Jämför etiketten som den lokala PE:n påtvingar med den som den avlägsna PE:n förväntar sig att ta emot. En avvikelse mellan de två vyerna är ett problem med etikettilldelning eller med sessionen, och det åtgärdas inte genom att ändra rutmål, hur många gånger du än gör det.

Rulla tillbaka RT-ändringen med ett angivet omfång

Om felet började med en ändring av rutmålet, ångra den som ett medvetet steg och säg vilket omfång du ändrar. Att ta bort ett importmål drar tillbaka behörigheten inne i den VRF:en. Det raderar inte VPNv4-annonsen från stamnätet, och på vissa plattformar hålls rutten kvar i tabellen. Det är olika utfall och den användarsynliga effekten beror på vilket av dem du menar.

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

En mjuk inkommande omkonfiguration räcker när sessionen redan lagrar prefixen; en hård återställning av en leverantörsvänd session under arbetstid är ett beslut som någon annan bör fatta. På Junos läser motsvarande kontroller tabellen per VRF och VPN-tabellen direkt, och återställningen är en återgång vid commit snarare än en ångring per kommando, så fånga konfigurationsskillnaden innan du börjar.

Avsluta med samma tre kommandon som du började med, i samma ordning, och registrera deras utdata med en tidsstämpel. Ett ärende som säger att RT var fel och nu är rätt kan inte återanvändas; ett som visar prefixet i VRF, i VPNv4 och installerat i CEF är bevis som nästa person kan jämföra med. Om bara de två första ändrades har du inte avslutat ändringen.