Rută lipsă în VRF: locală, VPNv4 sau tabelă de redirecționare?

Un client spune că un prefix a dispărut după o modificare a țintei de rută, iar prima captură de ecran pe care o trimite este de obicei tabelul greșit. Trei tabele diferite răspund la trei întrebări diferite: dacă prefixul există în interiorul VRF, dacă a fost anunțat și importat ca rută VPNv4 și dacă a fost instalată într-adevăr o intrare de redirecționare. Citirea lor în altă ordine produce concluzii sigure și greșite. Acest ghid duce un prefix local și unul la distanță prin toate cele trei tabele, în ordine, și se încheie cu un plan de revenire pentru modificarea RT care a început-o.

Numiți prefixul și tabelul căruia îi aparține

Notați două prefixe înainte de a tasta ceva. Unul este local la locația clientului, învățat de la o interfață conectată sau de la un anunț CE. Celălalt este la distanță și se așteaptă să sosească prin backbone-ul furnizorului. Ele iau căi diferite către aceeași VRF, iar o defecțiune într-unul nu spune nimic despre celălalt.

Păstrați clară distincția dintre cei doi identificatori, pentru că de acolo vine cea mai mare parte a confuziei din aceste tichete. Distinguisher-ul de rută face parte din NLRI-ul VPNv4 și există pentru a face unice în backbone prefixele de client care altfel ar fi identice. Ținta de rută este o comunitate extinsă purtată ca atribut, și cu ea se potrivește politica de import și export. Nu este un al doilea nume al distinguisher-ului și nu este purtată în pachetele clientului.

Pasul 1: demonstrați că prefixul este în VRF

Începeți cu vizualizarea locală, apoi cu RT-urile care guvernează importul. Dacă prefixul local lipsește aici, nimic din amonte nu poate fi vinovat:

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

Un prefix care apare ca fiind conectat sau static este învățat local, iar prezența lui nu spune nimic despre dacă a fost exportat. Aceasta este cea mai frecventă citire greșită din acest flux de lucru: un tabel VRF sănătos este doar dovadă despre învățarea locală. Partea de export este o întrebare separată, la care răspund vizualizarea vecinului și ținta de export atașată.

Verificați listele de RT pe VRF cât timp sunteți aici. Dacă ținta de import dorită nu este în listă, tot ce este în aval este irelevant. Dacă există dar diferă de ce exportă PE-ul de la distanță, ați găsit defecțiunea fără a deschide vreo captură de pachete.

Pasul 2: citiți tabelul VPNv4 și țintele lui

Tabelul VPNv4 arată ce a schimbat efectiv planul de control. Căutați prefixul de la distanță sub distinguisher-ul corect, apoi uitați-vă la comunitățile atașate de el:

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

O intrare cu ținta de rută corectă dar fără instalare locală indică politica de import sau selecția rutei, nu accesibilitatea. O intrare care nu apare deloc în tabelul VPNv4 indică în amonte: probabil PE-ul de origine nu a exportat-o, sau sesiunea nu transportă familia de adrese.

Există un al treilea caz care încurcă oamenii în timpul modificărilor. Unele platforme limitează ce rute VPN solicită sau rețin, folosind informații despre apartenența la ținte de rută, așa că absența unei NLRI la distanță într-o vizualizare filtrată nu este dovada că anunțul nu există nicăieri. Verificați tabelul nefiltrat și rutele anunțate ale vecinului înainte de a concluziona că o rută a fost retrasă global.

Pasul 3: confirmați că ceva a fost instalat și etichetat

O intrare BGP este o decizie, nu o cale. Tabelele de redirecționare spun dacă pachetele au unde să meargă:

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

O intrare CEF cu adiacență rezolvată și o etichetă de ieșire înseamnă că traficul planului de date ar trebui să funcționeze, iar orice simptom rămas aparține aplicației sau filtrării din interiorul VRF. O intrare CEF care arată un salt următor nerezolvat înseamnă că drumul etichetei este incomplet deși BGP pare sănătos, și exact acesta este cazul în care o captură a tabelului BGP a indus în eroare o revizuire de modificare.

Comparați eticheta pe care o impune PE-ul local cu cea pe care PE-ul de la distanță se așteaptă să o primească. O nepotrivire între cele două vizualizări este o problemă de alocare a etichetelor sau de sesiune, și nu va fi reparată prin editarea țintelor de rută, oricât de multe ori ați face-o.

Reveniți asupra modificării RT cu un domeniu declarat

Dacă defecțiunea a început cu o editare a țintei de rută, anulați-o ca un singur pas deliberat și spuneți ce domeniu modificați. Scoaterea unei ținte de import retrage eligibilitatea în interiorul acelei VRF. Nu șterge anunțul VPNv4 din backbone, iar pe unele platforme ruta rămâne reținută în tabel. Acestea sunt rezultate diferite, iar efectul vizibil pentru utilizator depinde de care dintre ele este vizat.

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

O reconfigurare soft de intrare este suficientă când sesiunea stochează deja prefixele; o resetare dură a unei sesiuni orientate spre furnizor în timpul orelor de lucru este o decizie pe care ar trebui să o ia altcineva. În Junos verificările echivalente citesc direct tabelul pe VRF și tabelul VPN, iar revenirea este o întoarcere la commit și nu o anulare pe fiecare comandă, așa că salvați diferența de configurație înainte de a începe.

Terminați cu aceleași trei comenzi cu care ați început, în aceeași ordine, și înregistrați-le ieșirea cu o marcă de timp. Un tichet care spune că RT-ul era greșit și acum este corect nu poate fi refolosit; unul care arată prefixul în VRF, în VPNv4 și instalat în CEF este o dovadă cu care următoarea persoană poate compara. Dacă s-au schimbat doar primele două, nu ați terminat modificarea.