Il tunnel RSVP-TE è attivo, ma la L3VPN del cliente non ha alcun percorso

Due team possono avere entrambi ragione quando il cliente segnala che la VPN è giù e il team trasporto segnala che il tunnel è a posto. Un LSP con ingegneria del traffico e una MPLS L3VPN rispondono a domande diverse: uno sposta pacchetti etichettati attraverso il core, l’altro decide a quale contesto di routing appartiene un pacchetto. Quando vengono confusi, la discussione gira in tondo perché ciascuna parte misura un oggetto diverso ed entrambe le misure sono valide.

Trasporto attivo e servizio giù è uno stato normale

Un LSP può essere stabilito, trasportare traffico ed essere visibile in ogni sistema di monitoraggio, mentre il servizio del cliente resta inutilizzabile. Nulla di quella combinazione è contraddittorio, perché il tunnel non ha opinioni sull’esistenza di un prefisso remoto, sulla sua accettazione da parte di una policy di importazione o sul passaggio dei frame da parte del circuito di aggancio.

Il sintomo che di solito rivela la confusione è asimmetrico: i ping dal loopback del PE riescono mentre un host sulla LAN del cliente non riceve nulla, o viceversa. Annota quali indirizzi hanno funzionato prima di formulare una teoria. Quando ti accorgi che stai testando due oggetti diversi, il passo successivo è leggere lo stack di etichette invece di discutere su quale grafo sia corretto. Due indirizzi, due proprietari e di solito due persone diverse che ciascuna crede che l’altra abbia rotto qualcosa.

Leggi lo stack come due responsabilità

L’etichetta inferiore appartiene al servizio e quella superiore appartiene al percorso. La RFC 4364 descrive la sequenza in modo semplice: prima viene imposta l’etichetta della rotta VPN, poi quel pacchetto etichettato viene incapsulato in tunnel verso il next hop BGP, dove un tunnel di ingegneria del traffico spinge la propria etichetta sopra.

Al PE remoto l’etichetta di servizio seleziona il trattamento, che può essere una ricerca VRF o una decisione di aggancio. Quell’etichetta non può essere sostituita con una che attraversa soltanto il core, e le due non sono intercambiabili anche quando compaiono nello stesso stack sulla stessa interfaccia.

Cosa dimostra il successo di RSVP e cosa no

RSVP-TE stabilisce LSP con routing esplicito, con o senza prenotazioni di risorse, il che è una garanzia concreta e utile sul percorso che un pacchetto compie attraverso il core. Non è un’affermazione sulle rotte del cliente, e un nome di tunnel configurato non è affatto una rotta.

Nemmeno la presenza di RSVP fornisce una promessa di prestazioni end-to-end. La prenotazione di banda su un LSP non dice nulla sul circuito di aggancio, sulla linea di accesso del cliente stesso o sul comportamento delle code al bordo remoto. Trattarla come una garanzia produce risposte sicure a domande che nessuno ha posto. Se il requisito è davvero un impegno di banda, deve essere composto dai pezzi che lo impongono davvero, e l’LSP è solo il centro di quella catena.

Verifica in ordine, poi fermati

Lavora dal trasporto verso l’esterno e fermati al primo passo che fallisce, perché ogni passo successivo presuppone che i precedenti abbiano tenuto. Prima conferma che l’LSP sia stabilito e che l’ingresso di inoltro del prefisso del servizio punti davvero a esso. Poi conferma che la rotta VPN esista nella tabella corretta, che il suo binding di etichetta sia presente e che la policy di importazione l’abbia accettata. Poi conferma l’aggancio: l’interfaccia, l’incapsulamento e, dove applicabile, l’identificatore VLAN che appartiene a quel contratto.

show mpls lsp
show mpls forwarding-table 10.60.0.0 24
show bgp vpnv4 unicast vrf CUSTOMER 10.60.0.0/24
show ip vrf detail CUSTOMER

La sintassi dei comandi varia in base alla piattaforma, quindi tratta quelle quattro righe come le quattro domande e non come uno script. La parte importante è che ciascuna interroga un oggetto diverso, ed è questo che fa sì che un guasto indichi un proprietario specifico.

Segui una richiesta consentita e conserva le buone prove

Concludi con una singola richiesta reale del cliente, consentita dalla policy, e la sua risposta. Un flusso funzionante end-to-end risolve più di una pagina di letture di contatori, ed esercita la combinazione invece di ogni pezzo isolatamente.

Quando una fase successiva fallisce, conserva l’osservazione riuscita dell’LSP invece di ricostruire il trasporto. Ricostruire un tunnel funzionante non può riparare un prefisso remoto assente, un aggancio VRF errato o una regola di accesso alla destinazione, e distrugge la prova che in primo luogo ti aveva detto che il trasporto era sano.