Il lab MPLS L3VPN non risponde al ping? Controllate questi cinque salti

Due router del cliente, un paio di apparati provider edge e un ping che muore senza messaggio di errore. In un piccolo lab MPLS L3VPN il guasto si trova quasi sempre su uno dei cinque punti di controllo, e ognuno ha un comando che mostra se la dipendenza funziona o se manca. L’errore è riavviare BGP ogni volta che il ping fallisce invece di provare le dipendenze in ordine. Se saltate subito alla configurazione VRF, potete passare un’ora su un problema nato da un next hop non risolto due apparati più in là.

Lavorate la lista dal basso verso l’alto. Un punto di controllo che passa resta superato, e il primo guasto è quello che vale la pena di diagnosticare.

Punto di controllo uno: i PE si raggiungono

Ogni PE ha bisogno di una rotta verso il loopback dell’altro PE, e quella rotta deve risolversi attraverso qualcosa di reale. Un interior gateway protocol è la via abituale, ma anche una rotta statica funziona, purché la ricerca ricorsiva finisca su una adjacency viva. Sugli apparati in stile IOS, show ip route 10.0.0.2 seguito da show ip cef 10.0.0.2 indica se il prefisso esiste e se dietro c’è una adjacency risolta. Una rotta nella tabella senza adjacency dietro non è raggiungibilità.

Controllate entrambe le direzioni. Costi IGP asimmetrici, una passive interface sul lato sbagliato o una distribute list che filtra il loopback ne rompono ciascuno una sola, e una sola direzione basta a uccidere la sessione. Se i loopback rispondono al ping ma la sessione BGP resta in Active, guardate la update source prima di toccare altro.

Punto di controllo due: esiste un percorso di label

Una rotta IP verso il loopback remoto non dimostra che il trasporto applicherà una label. In un progetto LDP, confermate che il loopback remoto abbia una binding locale e una remota, e che la label in uscita compaia nella forwarding table. show mpls ldp bindings 10.0.0.2 32 mostra le coppie di label, e show mpls forwarding-table 10.0.0.2 mostra che cosa la line card applicherà davvero. Quando il secondo comando non mostra alcuna label o ricade su IP, il trasporto non porta il traffico VPN come il progetto presuppone.

La distinzione nasce da come MPLS separa il forwarding state dai prefissi di destinazione, il modello descritto nella RFC 3031. Se il vostro lab usa RSVP-TE o label adiacenti a BGP invece di LDP, controllate lo stato proprio di quel meccanismo; dare per scontato che LDP distribuisca ogni label del sotto-livello è un modo comune di inseguire un bug fantasma. Un percorso di label rotto di solito emerge più tardi come una rotta VPN presente ma inutilizzabile.

Punto di controllo tre: la rotta VPN è arrivata intatta

Guardate la rotta VPNv4 o VPNv6 del prefisso del cliente esatto, non il riepilogo della sessione. show bgp vpnv4 unicast all 10.10.1.0/24 dovrebbe mostrare il route distinguisher, il next hop impostato sul loopback del PE remoto e una label. Se il prefisso manca, la politica di export sul PE di origine o la politica di import sul PE ricevente è il primo sospetto, e le route target sono il colpevole abituale.

Leggete il controllo della route target separatamente dalla ricezione BGP. Una rotta può arrivare con il next hop giusto e comunque non atterrare nella VRF perché l’import target non corrisponde. Sul PE ricevente show ip route vrf CUSTOMER 10.10.1.0 è il test che conta; la tabella BGP dimostra solo che la rotta ha attraversato il piano di controllo.

Punto di controllo quattro: l’interface è nella VRF

Una definizione VRF con un route distinguisher e delle route target non sposta nessuna interface dentro. L’interface verso il CE ha bisogno dell’assegnazione VRF, e show ip vrf interfaces o show ip interface brief dovrebbe elencarla sotto l’istanza corretta. È il punto di controllo in cui una configurazione copiata sbaglia più spesso, perché il blocco VRF sembra completo mentre l’interface resta nella tabella globale.

Poi confermate che il PE abbia appreso il prefisso del cliente locale in quella VRF, e che il CE abbia una rotta di ritorno attraverso il collegamento. Una default statica sul CE che punta al PE basta per un lab, purché la VRF del PE abbia una rotta verso la LAN del CE. Se manca una delle due metà, il ping fallisce prima che venga applicata qualsiasi label.

Punto di controllo cinque: la risposta trova la strada di casa

Tracciate il pacchetto in andata e poi quello di ritorno, perché usano tabelle diverse. Sul PE di ingresso la sorgente del cliente deve risolversi dentro la VRF verso il prefisso remoto con la label remota. Sul PE di uscita la destinazione deve risolversi dentro la stessa VRF verso l’interface del lato CE. Un ping partito dal PE stesso non è una prova: può uscire dalla tabella globale o da un altro indirizzo sorgente, ed è per questo che ping vrf CUSTOMER 10.10.2.10 source 10.10.1.1 è il test da eseguire.

I firewall degli host, il reverse-path filtering e le access list sul CE valgono ancora. Se il percorso di andata funziona e la risposta muore, il problema è una rotta o un filtro sul lato di ritorno, non il trasporto MPLS.

Tenete una riga per punto di controllo che nomini la prima dipendenza fallita. Quella riga trasforma la lamentela che il cliente non riesce a fare ping in una domanda concreta su raggiungibilità, stato delle label, import delle rotte, appartenenza dell’interface o percorso di ritorno, e impedisce alla sessione di debug successiva di ripetere gli stessi cinque comandi nello stesso ordine.