Manglande rute i VRF-en: lokal, VPNv4 eller vidaresendingstabell?

Ein kunde seier at eit prefiks manglar etter ei endring av rutemålet, og det første skjermbiletet dei sender er vanlegvis feil tabell. Tre ulike tabellar svarar på tre ulike spørsmål: om prefikset finst inne i VRF-en, om det vart annonsert og importert som ei VPNv4-rute, og om ei vidaresendingsoppføring faktisk vart installert. Å lese dei ut av rekkjefølgje gjev trygge og gale konklusjonar. Denne runboka fører eitt lokalt og eitt eksternt prefiks gjennom alle tre tabellane i rekkjefølgje, og sluttar med ein tilbakerullingsplan for RT-endringa som starta det.

Namngje prefikset og tabellen det høyrer til

Skriv ned to prefiks før du tastar noko. Det eine er lokalt på området til kunden, lært frå eit tilkopla grensesnitt eller ei CE-kunngjering. Det andre er eksternt og vert venta over stamnettet til leverandøren. Dei tek ulike vegar inn i den same VRF-en, og ein feil i det eine seier ingenting om det andre.

Hald skiljet mellom dei to identifikatorane klart, for det meste av forvirringa i desse sakene kjem derifrå. Rutemarkøren er ein del av VPNv4-NLRI-en og finst for å gjere elles identiske kundeprefiks unike over stamnettet. Rutemålet er eit utvida fellesskap som vert bore som attributt, og det er dette import- og eksportpolicyn matchar på. Det er ikkje eit anna namn for markøren og det vert ikkje bore i pakkane til kunden.

Steg 1: prov at prefikset er i VRF-en

Start med den lokale visinga, deretter RT-ane som styrer import. Om det lokale prefikset manglar her, kan ingenting ovanfor vere skulda:

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

Eit prefiks som viser seg som tilkopla eller statisk er lært lokalt, og tilstadeværet seier ingenting om kor vidt det vart eksportert. Det er den vanlegaste feillesinga i dette arbeidsløpet: ein sunn VRF-tabell er berre prov om lokal læring. Eksportsida er eit eige spørsmål, som nabo-visinga og det tilknytte eksportmålet svarar på.

Sjekk RT-listene på VRF-en medan du er her. Om det tiltenkte importmålet ikkje er i lista, er alt nedanfor irrelevant. Om det er der, men avvik frå det den eksterne PE-en eksporterer, har du funne feilen utan å opne ein einaste pakkefangst.

Steg 2: les VPNv4-tabellen og måla hans

VPNv4-tabellen viser kva kontrollplanet faktisk utveksla. Sjå etter det eksterne prefikset under rett markør, og sjå deretter på fellesskapa som er knytte 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

Ei oppføring med rett rutemål, men utan lokal installasjon, peikar på importpolicyn eller på rutervalet, ikkje på tilgjenge. Ei oppføring som ikkje viser seg i det heile i VPNv4-tabellen, peikar oppover: kjelde-PE-en eksporterte ho kanskje ikkje, eller sesjonen ber ikkje adressefamilien.

Det finst eit tredje tilfelle som forvirrar folk under endringar. Nokre plattformer avgrensar kva VPN-ruter dei ber om eller held på, ved hjelp av medlemsskapsinformasjon for rutemål, så fråværet av ein ekstern NLRI i éi filtrert vising er ikkje prov for at annonseringa ikkje finst nokon stad. Sjekk den ufiltrerte tabellen og dei annonserte rutene til naboen før du konkluderer med at ei rute vart trekt attende globalt.

Steg 3: stadfest at noko vart installert og merkt

Ei BGP-oppføring er eit vedtak, ikkje ein veg. Vidaresendingstabellane fortel om pakkane har ein stad å 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

Ei CEF-oppføring med oppløyst naboskap og ei utgåande etikett tyder at dataplanstrafikk skal fungere, og eitkvart attverande symptom høyrer til applikasjonen eller filtrering inne i VRF-en. Ei CEF-oppføring som viser eit uoppløyst neste hopp tyder at etikettvegen er ufullstendig sjølv om BGP ser sunt ut, og det er nettopp tilfellet der eit skjermbilete av BGP-tabellen har villa leidd ei endringsvurdering.

Samanlikn etiketten den lokale PE-en påfører med den den eksterne PE-en ventar å få. Eit avvik mellom dei to visingane er eit problem med etikettildeling eller sesjon, og det vert ikkje retta ved å endre rutemål, korkje kor mange gonger du gjer det.

Rull tilbake RT-endringa med eit oppgjeve omfang

Om feilen starta med ei endring av rutemålet, angre ho som eitt medvite steg og sei kva omfang du endrar. Å fjerne eit importmål dreg attende retten inne i den VRF-en. Det slettar ikkje VPNv4-annonseringa frå stamnettet, og på nokre plattformer vert ruta halden tilbake i tabellen. Dette er ulike utfall, og den brukarsynlege effekten avheng av kva av dei du meiner.

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

Ei mjuk inngåande omkonfigurering er nok når sesjonen alt lagrar prefiksa; ein hard nullstilling av ein leverandørvend sesjon i arbeidstida er eit vedtak nokon andre bør ta. På Junos les dei tilsvarande kontrollane tabellen per VRF og VPN-tabellen direkte, og tilbakerullinga er ein tilbakegang ved commit snarare enn ein angring per kommando, så fang konfigurasjonsskilnaden før du byrjar.

Avslutt med dei same tre kommandoane som du byrja med, i same rekkjefølgje, og registrer utdataa med eit tidsstempel. Ei sak som seier at RT-en var feil og no er rett, kan ikkje brukast om att; ei som viser prefikset i VRF-en, i VPNv4 og installert i CEF, er prov som neste person kan samanlikne med. Om berre dei to første endra seg, er endringa ikkje ferdig.