Leggere un'etichetta VPNv4 al confine AS: quale modello inter-AS vale
Un'etichetta VPNv4 su un router di confine conta solo nel contesto del modello inter-AS implementato. Identifica il modello, percorri un prefisso e annota chi possiede il passaggio.
Leggere un'etichetta VPNv4 su un router di confine AS dice poco finché non si sa quale modello inter-AS implementa il passaggio. L'etichetta non è una proprietà della rotta in sé; registra un accordo su incapsulamento e consegna tra due router. Identifica il modello prima di leggere il display. Altrimenti stai eseguendo il debug di un contratto che nessuno ha messo per iscritto.
Quale modello implementa il confine
La soluzione VRF-to-VRF unisce VRF corrispondenti tramite collegamenti instradati. Ogni lato vede l'altro come vicino customer-edge e si scambiano normali rotte IPv4, quindi a quel confine non serve MPLS.
Una seconda soluzione scambia rotte VPNv4 etichettate tra i router di confine stessi. Funziona solo con un percorso label-switched coerente attraverso l'interconnessione e una distribuzione dei route-target più un modello di fiducia che entrambi i lati accettano. Se manca uno dei due pezzi, il modello non è in uso, qualunque cosa implichi la configurazione.
Il terzo distribuisce la raggiungibilità PE etichettata mentre le rotte VPN viaggiano tra endpoint o route reflector attraverso gli AS. Ognuno dei tre lascia un lavoro diverso al confine, e mescolare il control plane di uno con le assunzioni di interfaccia di un altro è il guasto classico. Quella discrepanza di solito emerge come un'etichetta che sembra giusta da un lato e svanisce dall'altro.
Leggi un prefisso da un capo all'altro
Prendi un singolo prefisso cliente autorizzato e percorrilo. Guarda cosa è stato annunciato, cosa è arrivato, il next hop, l'etichetta e la policy di import che l'ha ammesso. Poi guarda come il router risolve l'inoltro verso quel next hop, perché è lì che un'etichetta diventa un pacchetto. Salta una delle due metà e stai descrivendo un control plane che potrebbe non muovere traffico. Le due letture hanno senso solo insieme.
Il numero è locale. Significa qualcosa in relazione al router che l'ha allocato e al percorso che porta i pacchetti lì, ed è per questo che lo stesso valore può comparire due volte e significare due cose diverse. Confrontalo con ciò che il lato ricevente dice di aver ricevuto.
L'etichetta è locale, e lo è anche la promessa
La capacità si verifica a entrambi i capi dell'interconnessione, non a uno. Un comando sulla tua interfaccia non fa nulla all'interfaccia del provider vicino, e una rotta accettata da BGP non impegna da sola il vicino a inoltrare un pacchetto etichettato.
La RFC 4364 limita il peering VPNv4 etichettato ad accordi fidati e mette in guardia dall'accettare etichette che non sono mai state annunciate a quel peer. È un'affermazione di sicurezza oltre che di protocollo. Tieni la relazione di routing di internet pubblico lontana dallo scambio di rotte VPN private. Se l'interconnessione è IP semplice, non aspettarti che un'etichetta sopravviva. E dove il collegamento è etichettato, verifica che l'etichetta di trasporto esterna sia scambiata correttamente a ogni hop.
Un'etichetta che sembra giusta da un lato e svanisce dall'altro di solito è quella discrepanza, non un bug di routing.
Cosa mettere per iscritto all'accettazione
L'accettazione è un test sul pacchetto, non una revisione della tabella. Segui un pacchetto cliente dentro il VRF remoto e segui la risposta al ritorno, poi annota quale modello implementa il passaggio. Aggiungi i responsabili del passaggio su entrambi i lati e se il confine trasporta IP semplice o traffico etichettato.
Quella nota è ciò che permette all'operatore successivo di leggere correttamente lo stesso display di etichette. Senza, il modello viene inferito dalla configurazione, e le assunzioni inferite sono il modo in cui lo stesso errore si ripete. La sezione inter-AS della RFC 4364 è il posto dove stabilire quale modello fosse inteso.