Rotta assente nella VRF: locale, VPNv4 o tabella di inoltro?

Un cliente dice che un prefisso manca dopo una modifica all’obiettivo di rotta, e la prima schermata che invia è di solito la tabella sbagliata. Tre tabelle diverse rispondono a tre domande diverse: se il prefisso esiste dentro la VRF, se è stato annunciato e importato come rotta VPNv4, e se una voce di inoltro è stata davvero installata. Leggerle fuori ordine produce conclusioni sicure e sbagliate. Questo manuale porta un prefisso locale e uno remoto attraverso le tre tabelle, in ordine, e termina con un piano di rollback per la modifica di RT che l’ha iniziato.

Nomini il prefisso e la tabella a cui appartiene

Annoti due prefissi prima di digitare qualsiasi cosa. Uno è locale nel sito del cliente, appreso da un’interfaccia connessa o da un annuncio CE. L’altro è remoto e si aspetta che arrivi dal backbone del provider. Prendono percorsi diversi verso la stessa VRF, e un guasto in uno non dice nulla sull’altro.

Tenga chiara la distinzione tra i due identificatori, perché da lì viene la maggior parte della confusione in questi ticket. Il distinguisher di rotta fa parte dell’NLRI VPNv4 ed esiste per rendere unici nel backbone prefissi di cliente altrimenti identici. L’obiettivo di rotta è una comunità estesa trasportata come attributo, ed è su di esso che la policy di import ed export fa corrispondenza. Non è un secondo nome del distinguisher e non viene trasportato nei pacchetti del cliente.

Passo 1: dimostri che il prefisso è nella VRF

Parta dalla vista locale, poi dagli RT che governano l’import. Se il prefisso locale manca qui, nulla a monte può essere la causa:

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 prefisso che appare come connesso o statico è appreso localmente, e la sua presenza non dice nulla sull’eventuale export. È la lettura errata più comune in questo flusso di lavoro: una tabella VRF sana è solo prova di apprendimento locale. Il lato export è una domanda separata, a cui rispondono la vista del vicino e l’obiettivo di export associato.

Controlli gli elenchi di RT sulla VRF finché è qui. Se l’obiettivo di import previsto non è nell’elenco, tutto ciò che sta a valle è irrilevante. Se c’è ma differisce da ciò che esporta il PE remoto, ha trovato il guasto senza aprire una sola cattura di pacchetti.

Passo 2: legga la tabella VPNv4 e i suoi obiettivi

La tabella VPNv4 mostra cosa ha realmente scambiato il piano di controllo. Cerchi il prefisso remoto sotto il distinguisher corretto, poi guardi le comunità che vi sono associate:

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

Una voce con l’obiettivo di rotta corretto ma senza installazione locale indica la policy di import o la selezione della rotta, non la raggiungibilità. Una voce che non appare affatto nella tabella VPNv4 indica a monte: forse il PE di origine non l’ha esportata, o la sessione non trasporta la famiglia di indirizzi.

C’è un terzo caso che disorienta le persone durante le modifiche. Alcune piattaforme limitano quali rotte VPN richiedono o mantengono, usando informazioni di appartenenza agli obiettivi di rotta, quindi l’assenza di una NLRI remota in una vista filtrata non è prova che l’annuncio non esista da nessuna parte. Controlli la tabella non filtrata e le rotte annunciate del vicino prima di concludere che una rotta è stata ritirata globalmente.

Passo 3: confermi che qualcosa è stato installato ed etichettato

Una voce BGP è una decisione, non un percorso. Le tabelle di inoltro dicono se i pacchetti hanno dove andare:

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

Una voce CEF con adiacenza risolta ed etichetta in uscita significa che il traffico del piano dati dovrebbe funzionare, e ogni sintomo residuo appartiene all’applicazione o al filtraggio dentro la VRF. Una voce CEF che mostra un next hop non risolto significa che il percorso dell’etichetta è incompleto anche se BGP sembra sano, ed è esattamente il caso in cui una schermata della tabella BGP ha fuorviato una revisione di modifica.

Confronti l’etichetta che il PE locale impone con quella che il PE remoto si aspetta di ricevere. Una discrepanza tra le due viste è un problema di allocazione delle etichette o di sessione, e non si risolverà modificando gli obiettivi di rotta, per quante volte lo faccia.

Annulli la modifica di RT con un ambito dichiarato

Se il guasto è iniziato con una modifica all’obiettivo di rotta, la annulli come un solo passo deliberato e dica quale ambito sta cambiando. Rimuovere un obiettivo di import ritira l’idoneità dentro quella VRF. Non cancella l’annuncio VPNv4 dal backbone, e su alcune piattaforme la rotta resta trattenuta nella tabella. Sono esiti diversi e l’effetto visibile all’utente dipende da quale dei due intende.

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

Una riconfigurazione morbida in ingresso basta quando la sessione memorizza già i prefissi; un reset duro di una sessione rivolta al provider in orario lavorativo è una decisione che deve prendere qualcun altro. Su Junos i controlli equivalenti leggono direttamente la tabella per VRF e la tabella VPN, e il rollback è un ritorno al commit e non un annullamento per comando, quindi catturi il diff di configurazione prima di iniziare.

Termini con gli stessi tre comandi con cui ha iniziato, nello stesso ordine, e ne registri l’output con una marca temporale. Un ticket che dice che l’RT era sbagliato e ora è giusto non è riutilizzabile; uno che mostra il prefisso presente nella VRF, presente in VPNv4 e installato in CEF è una prova con cui la persona successiva può confrontarsi. Se sono cambiati solo i primi due, non ha terminato la modifica.