Manglende rute i VRF’en: lokal, VPNv4 eller forwarding-tabel?

En kunde siger, at et præfiks mangler efter en ændring af route-target, og det første skærmbillede, de sender, er som regel den forkerte tabel. Tre forskellige tabeller besvarer tre forskellige spørgsmål: om præfikset findes inde i VRF’en, om det blev annonceret og importeret som en VPNv4-rute, og om der faktisk blev installeret en forwarding-post. Læses de ude af rækkefølge, giver det selvsikre og forkerte konklusioner. Denne runbook fører ét lokalt og ét fjernt præfiks gennem alle tre tabeller i rækkefølge og slutter med en tilbagerulningsplan for den RT-ændring, der startede det.

Navngiv præfikset og den tabel, det hører til

Skriv to præfikser ned, før du taster noget. Det ene er lokalt på kundens site, lært fra en tilsluttet grænseflade eller en CE-annoncering. Det andet er fjernt og forventes at ankomme over udbyderens backbone. De tager forskellige veje ind i den samme VRF, og en fejl i det ene siger intet om det andet.

Hold forskellen mellem de to identifikatorer klar, for det meste af forvirringen i disse sager kommer derfra. Route distinguisheren er en del af VPNv4-NLRI’en og findes for at gøre ellers identiske kundepræfikser unikke over backbonen. Route-target er et udvidet community, der bæres som attribut, og det er den, import- og eksportpolitikken matcher på. Det er ikke et andet navn for distinguisheren, og det bæres ikke i kundens pakker.

Trin 1: bevis, at præfikset er i VRF’en

Start med det lokale billede, derefter de RT’er, der styrer import. Hvis det lokale præfiks mangler her, kan intet ovenfor være skyld i det:

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

Et præfiks, der vises som forbundet eller statisk, er lært lokalt, og dets tilstedeværelse siger intet om, hvorvidt det blev eksporteret. Det er den mest almindelige fejllæsning i dette arbejdsforløb: en sund VRF-tabel er kun bevis om lokal læring. Eksportsiden er et separat spørgsmål, som nabo-visningen og det tilknyttede eksport-target besvarer.

Kontrollér RT-listerne på VRF’en, mens du er her. Hvis det tilsigtede import-target ikke er på listen, er alt nedstrøms irrelevant. Hvis det er der, men afviger fra det, den fjerne PE eksporterer, har du fundet fejlen uden at åbne en enkelt pakkeoptagelse.

Trin 2: læs VPNv4-tabellen og dens targets

VPNv4-tabellen viser, hvad kontrolplanet faktisk udvekslede. Led efter det fjerne præfiks under den korrekte distinguisher, og se derefter på de communities, der er knyttet til 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 det rigtige route-target, men uden lokal installation, peger på importpolitik eller på rutevalg, ikke på tilgængelighed. En post, der slet ikke optræder i VPNv4-tabellen, peger opad: den oprindelige PE har måske ikke eksporteret den, eller sessionen bærer ikke adressefamilien.

Der er et tredje tilfælde, som forvirrer folk under ændringer. Nogle platforme begrænser, hvilke VPN-ruter de anmoder om eller beholder, ved hjælp af medlemskabsoplysninger for route-targets, så fraværet af en fjern NLRI i én filtreret visning er ikke bevis på, at annonceringen ikke findes nogen steder. Kontrollér den ufiltrerede tabel og naboens annoncerede ruter, før du konkluderer, at en rute blev trukket tilbage globalt.

Trin 3: bekræft, at noget blev installeret og mærket

En BGP-post er en beslutning, ikke en vej. Forwarding-tabellerne fortæller, om pakkerne har et sted at gå hen:

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 en opløst naboskab og en udgående label betyder, at dataplanstrafik bør virke, og ethvert resterende symptom hører til applikationen eller til filtrering inde i VRF’en. En CEF-post, der viser et uopløst næste hop, betyder, at labelstien er ufuldstændig, selv om BGP ser sundt ud, og det er præcis det tilfælde, hvor et skærmbillede af BGP-tabellen har vildledt en ændringsgennemgang.

Sammenlign den label, den lokale PE pålægger, med den, den fjerne PE forventer at modtage. En uoverensstemmelse mellem de to visninger er et labeltildelings- eller sessionsproblem, og det bliver ikke rettet ved at ændre route-targets, uanset hvor mange gange du gør det.

Rul RT-ændringen tilbage med et erklæret omfang

Hvis fejlen startede med en route-target-ændring, skal du fortryde den som ét bevidst trin og sige, hvilket omfang du ændrer. At fjerne et import-target trækker berettigelse tilbage inde i den VRF. Det sletter ikke VPNv4-annonceringen fra backbonen, og på nogle platforme forbliver ruten holdt i tabellen. Det er forskellige udfald, og den brugersynlige effekt afhænger af, hvilket af dem du mener.

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 blød indgående rekonfiguration er nok, når sessionen allerede gemmer præfikserne; et hårdt reset af en udbydervendt session i arbejdstiden er en beslutning, som en anden bør træffe. På Junos læser de tilsvarende kontroller VRF-tabellen og VPN-tabellen direkte, og tilbagerulningen er en tilbagevenden ved commit snarere end en fortrydelse per kommando, så gem konfigurationsforskellen, før du begynder.

Afslut med de samme tre kommandoer, som du begyndte med, i samme rækkefølge, og registrér deres output med et tidsstempel. En sag, der siger, at RT’en var forkert, og nu er den rigtig, kan ikke genbruges; en der viser præfikset i VRF’en, i VPNv4 og installeret i CEF, er bevis, som den næste person kan sammenligne med. Hvis kun de to første ændrede sig, er ændringen ikke færdig.