Manglende rute i VRF-en: lokal, VPNv4 eller videresendingstabell?

En kunde sier at et prefiks mangler etter en endring av rutemålet, og det første skjermbildet de sender er vanligvis feil tabell. Tre forskjellige tabeller svarer på tre forskjellige spørsmål: om prefikset finnes inne i VRF-en, om det ble annonsert og importert som en VPNv4-rute, og om en videresendingspost faktisk ble installert. Å lese dem ute av rekkefølge gir selvsikre og gale konklusjoner. Denne runboken fører ett lokalt og ett eksternt prefiks gjennom alle tre tabellene i rekkefølge, og avslutter med en tilbakerullingsplan for RT-endringen som startet det.

Navngi prefikset og tabellen det hører til

Skriv ned to prefikser før du taster noe. Det ene er lokalt på kundens område, lært fra et tilkoblet grensesnitt eller en CE-annonsering. Det andre er eksternt og forventes å komme over leverandørens stamnett. De tar forskjellige veier inn i den samme VRF-en, og en feil i det ene sier ingenting om det andre.

Hold skillet mellom de to identifikatorene klart, for det meste av forvirringen i disse sakene kommer derfra. Rutemarkereren er en del av VPNv4-NLRI-en og finnes for å gjøre ellers identiske kundeprefikser unike over stamnettet. Rutemålet er et utvidet fellesskap som bæres som attributt, og det er dette import- og eksportpolicyen matcher på. Det er ikke et annet navn for markøreren og det bæres ikke i kundens pakker.

Trinn 1: bevis at prefikset er i VRF-en

Start med det lokale bildet, deretter RT-ene som styrer import. Hvis det lokale prefikset mangler her, kan ingenting ovenfor være skylden:

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 prefiks som vises som tilkoblet eller statisk er lært lokalt, og tilstedeværelsen sier ingenting om hvorvidt det ble eksportert. Det er den vanligste feillesningen i dette arbeidsforløpet: en sunn VRF-tabell er bare bevis om lokal læring. Eksportsiden er et eget spørsmål, som nabo-visningen og det tilknyttede eksportmålet svarer på.

Sjekk RT-listene på VRF-en mens du er her. Hvis det tiltenkte importmålet ikke er i listen, er alt nedenfor irrelevant. Hvis det er der, men avviker fra det den eksterne PE-en eksporterer, har du funnet feilen uten å åpne en eneste pakkefangst.

Trinn 2: les VPNv4-tabellen og målene dens

VPNv4-tabellen viser hva kontrollplanet faktisk utvekslet. Se etter det eksterne prefikset under riktig markør, og se deretter på fellesskapene som 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 riktig rutemål, men uten lokal installasjon, peker på importpolicyen eller på rutervalget, ikke på tilgjengelighet. En post som ikke vises i det hele tatt i VPNv4-tabellen, peker oppover: kilde-PE-en eksporterte den kanskje ikke, eller sesjonen bærer ikke adressefamilien.

Det finnes et tredje tilfelle som forvirrer folk under endringer. Noen plattformer begrenser hvilke VPN-ruter de ber om eller beholder, ved hjelp av medlemskapsinformasjon for rutemål, så fraværet av en ekstern NLRI i én filtrert visning er ikke bevis for at annonseringen ikke finnes noe sted. Sjekk den ufiltrerte tabellen og naboens annonserte ruter før du konkluderer med at en rute ble trukket tilbake globalt.

Trinn 3: bekreft at noe ble installert og merket

En BGP-post er en beslutning, ikke en vei. Videresendingstabellene forteller om pakkene har et sted å gå:

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 oppløst naboskap og en utgående etikett betyr at dataplanstrafikk skal fungere, og ethvert gjenværende symptom tilhører applikasjonen eller filtrering inne i VRF-en. En CEF-post som viser et uoppløst neste hopp betyr at etikettveien er ufullstendig selv om BGP ser sunt ut, og det er nettopp tilfellet der et skjermbilde av BGP-tabellen har villedet en endringsgjennomgang.

Sammenlign etiketten den lokale PE-en påfører med den den eksterne PE-en forventer å motta. Et avvik mellom de to visningene er et problem med etikettildeling eller sesjon, og det blir ikke rettet ved å endre rutemål, uansett hvor mange ganger du gjør det.

Rull tilbake RT-endringen med et oppgitt omfang

Hvis feilen startet med en endring av rutemålet, angre den som ett bevisst trinn og si hvilket omfang du endrer. Å fjerne et importmål trekker tilbake berettigelsen inne i den VRF-en. Det sletter ikke VPNv4-annonseringen fra stamnettet, og på noen plattformer blir ruten holdt tilbake i tabellen. Dette er forskjellige utfall, og den brukersynlige effekten avhenger av hvilket av 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 myk inngående rekonfigurering er nok når sesjonen allerede lagrer prefiksene; en hard nullstilling av en leverandørvendt sesjon i arbeidstiden er en beslutning noen andre bør ta. På Junos leser de tilsvarende kontrollene tabellen per VRF og VPN-tabellen direkte, og tilbakerullingen er en tilbakegang ved commit snarere enn en angring per kommando, så fang konfigurasjonsforskjellen før du begynner.

Avslutt med de samme tre kommandoene som du begynte med, i samme rekkefølge, og registrer utdataene med et tidsstempel. En sak som sier at RT-en var feil og nå er riktig, kan ikke gjenbrukes; en som viser prefikset i VRF-en, i VPNv4 og installert i CEF, er bevis som neste person kan sammenligne med. Hvis bare de to første endret seg, er endringen ikke ferdig.