Da una rotta CE RIP a una VRF remota: dove avviene l’export

Un aggiornamento RIPv2 arriva al bordo del provider, finisce in una tabella di routing VRF e si ferma lì a meno che qualcosa non lo esporti esplicitamente. Tre decisioni avvengono in sequenza e ognuna può rifiutare il prefisso per una propria ragione. Leggerle come un unico evento è il motivo per cui si cerca il dispositivo sbagliato quando un sito remoto non riesce a raggiungere una rete che il CE annuncia chiaramente. Segui la rotta attraverso il PE e la sequenza diventa ovvia.

Che cosa fa il PE con un aggiornamento RIP

Il PE riceve l’aggiornamento sull’interfaccia VRF, verifica che l’origine sia un vicino consentito e installa il prefisso nella tabella di routing VRF con un conteggio dei salti derivato dall’annuncio. Quella tabella è una normale tabella di routing con le proprie distanze amministrative e la propria elezione del percorso migliore. Se il CE annuncia due volte lo stesso prefisso con metriche diverse, solo il migliore sopravvive nella tabella. Nulla in questo passaggio coinvolge il backbone del provider.

Il prefisso ora esiste nel contesto di routing di un solo cliente, il che è molto lontano dall’essere raggiungibile ovunque altro.

L’export è un atto di politica, non una conseguenza del protocollo

Per uscire dalla VRF, una rotta deve essere redistribuita nel processo MP-BGP che trasporta le rotte VPN e necessita di una comunità estesa di route target che identifichi quali VRF remote possono importarla. L’architettura in RFC 4364 mantiene questi scambi separati dal protocollo CE-PE proprio per questo motivo. Usare RIP al bordo non dice nulla su ciò che deve attraversare la rete del provider.

Scrivi il contratto di export prima di configurare qualsiasi cosa: i prefissi dei clienti che devono essere raggiungibili da remoto, le rotte che devono restare locali e qualsiasi default, più specifico o eccezione di servizio condiviso. Confronta quel contratto con la VRF reale anziché con una dallo stesso nome appartenente a un altro cliente.

Il lato import è una seconda politica con i propri route target, e un export corrispondente con un import non corrispondente produce un prefisso che esiste nel backbone e non appare in nessuna tabella remota.

Redistribuzione e origine esplicita si comportano diversamente

La redistribuzione prende le rotte già presenti nella tabella VRF e le copia in BGP, filtrate da una route map. La mappa decide quali prefissi sono idonei e quali attributi portano, e la metrica va impostata esplicitamente perché un conteggio dei salti RIP non ha significato come metrica BGP. Tutto ciò che lasci non impostato viene ereditato in un modo che di solito sorprende chi legge la configurazione sei mesi dopo.

La redistribuzione reciproca è dove avviene il danno silenzioso. Un prefisso esportato in BGP può tornare attraverso un secondo punto di redistribuzione e, senza tag o filtri, la rotta oscilla mentre entrambe le tabelle sembrano plausibili in ogni istante. Filtra sui tag applicati al bordo invece di fidarti della topologia per impedire il percorso di ritorno.

L’origine esplicita sembra più ordinata e non è incondizionata. Un network statement di solito richiede una rotta corrispondente nella tabella di routing prima che il prefisso venga originato, quindi l’annuncio scompare nel momento in cui il CE smette di annunciarlo. Spesso è il comportamento desiderato e non è lo stesso di una rotta statica che resta configurata per sempre. Controlla la regola effettiva della piattaforma invece di dare per scontato l’uno o l’altro comportamento.

In ogni caso, la domanda da porre su ogni prefisso è quale fonte attiva lo rende idoneo e che cosa succede quando quella fonte scompare.

Verifica la catena in quattro punti

Guarda l’annuncio del CE, la tabella di routing VRF, la tabella delle rotte VPN con il suo route target e l’import nella VRF remota, in quest’ordine. Su IOS ciò significa l’output del vicino CE, show ip route vrf CUSTOMER, show ip bgp vpnv4 vrf CUSTOMER, e lo stesso comando sul PE remoto. Su IOS-XR l’output equivalente si trova sotto show bgp vrf CUSTOMER ipv4 unicast. I nomi dei comandi cambiano, i quattro punti di controllo no.

Controlla un prefisso che dovrebbe essere rifiutato con la stessa cura di uno che dovrebbe passare, perché una politica che permette tutto sembra identica a una corretta finché non arriva la prima eccezione. Poi osserva un ritiro: spegni l’interfaccia del CE e conferma che la voce remota scompare entro il timer atteso invece di restare.

Registra chi possiede ogni politica. Quando il provider gestisce il CE, il comportamento fornito appartiene al contratto di servizio, e un protocollo o una politica di ritiro diversi sul dispositivo gestito sono un problema di documentazione prima che di routing.