RD contro RT in una VPN MPLS: unicità contro politica di importazione

Due sedi cliente possono annunciare 10.20.0.0/24 ed entrambe restano valide all’interno di un’unica rete del provider. Il route distinguisher mantiene separati questi annunci; il route target decide quale VRF del cliente può prenderne una copia. Appaiono uno accanto all’altro nella configurazione e svolgono compiti del tutto diversi. Confonderli porta a modifiche che sembrano ragionevoli e non risolvono nulla.

Segui una rotta dal bordo del cliente a una VRF remota e la divisione diventa concreta: l’identità viene allegata prima che la rotta entri in BGP, e la politica di distribuzione viene valutata quando la rotta raggiunge il bordo del provider che la riceve.

Una rotta VPN-IPv4 è un RD più un prefisso IPv4

La RFC 4364 definisce la famiglia di indirizzi VPN-IPv4 come un route distinguisher di otto byte seguito da un indirizzo IPv4 di quattro byte. Il RD viene anteposto al prefisso del cliente, così due prefissi identici di sedi diverse diventano due rotte BGP diverse.

Questa costruzione è l’intero meccanismo di unicità. Il provider non ha bisogno che i clienti concordino uno spazio di indirizzi senza sovrapposizioni, e una rotta di una sede non può sostituire silenziosamente un prefisso identico di un’altra sede.

Il formato del RD è di per sé un valore scelto dall’amministratore, di solito un numero di sistema autonomo e un numero locale. La sua forma numerica è una convenzione, non il segno che i due campi condividano un significato con un route target che per caso usa le stesse cifre.

Il RD rende distinguibili i prefissi che si sovrappongono

Considera due annunci per lo stesso prefisso. La sede A porta il RD 65000:101 e la sede B porta il RD 65000:202, entrambi per 10.20.0.0/24. BGP ora detiene due rotte VPN-IPv4 che possono essere confrontate, filtrate e selezionate in modo indipendente.

Il RD non dice quale VRF debba ricevere l’una o l’altra rotta, e non identifica un cliente o un servizio. È un campo di identità della rotta, non un elenco di appartenenza. Il RD di una VRF non deve necessariamente corrispondere al RD di una rotta che importa.

Per questo cambiare un RD perché corrisponda al numero di un’altra sede non risolve nulla. Se una rotta manca dall’altra parte, far coincidere le cifre crea un problema di identità diverso invece di riparare la decisione di importazione.

Il RT è un attributo BGP, non un’etichetta del pacchetto

Una politica di esportazione allega uno o più route target alla rotta come attributi di comunità estesa BGP. Il bordo del provider che riceve confronta questi attributi con la politica di importazione di ogni VRF. Il RT viaggia con la rotta attraverso il piano di controllo. Il confronto avviene interamente nella politica di routing, prima che qualsiasi pacchetto del cliente venga inoltrato.

I pacchetti di dati del cliente non trasportano il RT. Una volta installata una rotta in una VRF, l’inoltro usa la tabella di quella VRF e lo stack di etichette MPLS assegnato dall’architettura. Il bordo del provider non legge un route target da ogni pacchetto del cliente.

Una rotta può portare diversi RT, e una VRF può importarne diversi. La configurazione spesso appare come un breve blocco:

vrf definition CUST-A
 rd 65000:101
 address-family ipv4
  route-target export 65000:500
  route-target import 65000:500

Leggi quel blocco come due istruzioni separate. La riga di esportazione controlla ciò che viene allegato alle rotte in uscita da questa VRF; la riga di importazione controlla ciò che questa VRF è disposta a considerare. Numeri identici sono comodi, non obbligatori.

L’eleggibilità all’importazione non è l’installazione

Una rotta può essere eleggibile per una VRF e comunque non comparire nella sua tabella di inoltro. L’eleggibilità è un filtro; poi il normale processo decisionale di BGP confronta le rotte eleggibili e ne seleziona una. Una rotta più vecchia o meno preferita può perdere contro un altro percorso eleggibile.

Controlla la rotta selezionata, non solo la politica di importazione. Una VRF che importa il RT 65000:500 e non mostra alcuna rotta per 10.20.0.0/24 può aver ricevuto la rotta e averla rifiutata durante la selezione, oppure non averla mai ricevuta.

Questa distinzione conta anche quando compare un prefisso inatteso. Una politica di importazione troppo ampia può attirare rotte che la sede non intendeva usare, e l’unicità del RD non lo impedisce affatto. L’ampiezza della distribuzione è una questione di politica del RT.

Diagnostica una rotta mancante nell’ordine del piano di controllo

Parti dall’annuncio: la VRF di origine esporta il RT previsto, e la rotta esiste come rotta VPN-IPv4 sul reflector di rotte o sul PE che riceve? Poi controlla l’attributo come è stato ricevuto, non come è configurato sul mittente.

Confronta quindi la lista di importazione della VRF che riceve con i valori RT effettivi della rotta. Infine ispeziona la rotta selezionata in quella VRF e il binding dell’etichetta. Ogni passo risponde a una domanda diversa, e saltare al RD di solito salta proprio quello sbagliato.

Annota il RD, il RT esportato, il RT importato e il prossimo salto selezionato per la sede che funziona e per quella che fallisce. Quattro valori affiancati trasformano un vago «la VPN non passa le rotte» nel passo esatto del piano di controllo che differisce.