Lo stesso /24 per due clienti? VPNv4 richiede un RD e un’etichetta

Due inquilini numerano la propria sede con lo stesso 10.50.0.0/24, e dopo una modifica la rotta di uno scompare dal bordo del provider mentre quella dell’altro continua a funzionare. La semplificazione dietro quel ticket è di solito eliminare il distinguitore di rotta (RD) perché «l’etichetta identifica già il cliente». Non lo fa. Il RD e l’etichetta rispondono a due domande diverse, e la differenza diventa visibile solo quando gli indirizzi sovrapposti la impongono.

Una rotta dove dovrebbero essercene due

L’unicast IPv4 semplice confronta due percorsi verso lo stesso prefisso e installa il migliore. 10.50.0.0/24 dell’inquilino A e 10.50.0.0/24 dell’inquilino B sono un’unica chiave, quindi uno vince e l’altro sopravvive solo come percorso di riserva. Il protocollo ha fatto ciò che gli è stato detto; al piano di controllo è stato chiesto di memorizzare due rotte diverse sotto un unico identificatore.

Il risultato sembra una rotta mancante più che un errore: il PE che ha perso la competizione inoltra ancora il proprio inquilino localmente, quindi un ping intra-sito riesce e il test tra siti fallisce. Contate le voci per quel prefisso nella tabella VPNv4 prima di toccare qualsiasi politica.

Il RD trasforma una chiave in due

Un distinguitore di rotta di otto byte viene anteposto al prefisso IPv4, e l’oggetto trasportato da BGP diventa un indirizzo VPN-IPv4 invece di un prefisso IPv4. Due inquilini possono mantenere gli stessi 32 bit perché i 64 bit davanti differiscono. Esistono tipi di formato per un RD basato su AS e per uno basato su indirizzo, e la scelta spetta al PE di origine. Un RD basato su AS è comune quando i PE condividono un AS, e uno basato su indirizzo quando non lo fanno.

Non leggete il RD come un’etichetta di appartenenza. Le destinazioni di rotta governano importazione ed esportazione e decidono quali VRF possono installare la rotta; il RD garantisce solo che la rotta abbia un’identità propria. Dare a ogni VRF il proprio RD è la prassi comune perché mantiene quella corrispondenza leggibile in un visualizzatore di rotte.

L’etichetta è un’istruzione di inoltro locale

Ogni annuncio porta anche un’etichetta MPLS, il cui significato è limitato al router che l’ha assegnata. Un altro PE può rilasciare lo stesso numero per una destinazione non correlata. È proprio per questo che l’etichetta non può sostituire l’identità del cliente: il numero è corretto solo accanto al salto successivo e allo stato di inoltro che l’ha installato.

La granularità dell’assegnazione varia con l’implementazione e il progetto: alcune piattaforme assegnano un’etichetta per VRF, altre per prefisso, e l’etichetta può identificare un’azione di inoltro invece di un cliente. Due etichette diverse che raggiungono la stessa destinazione non sono una contraddizione, e lo stesso numero di etichetta su due PE nemmeno.

Perché l’una non può sostituire l’altra

Leggere un annuncio significa guardare quattro cose insieme: il prefisso qualificato dal RD, le destinazioni di rotta, il salto successivo e l’etichetta. Leggere un pacchetto utente significa guardare lo stack installato da quelle informazioni. Un progetto sano mostra i due lati coincidenti, e uno rotto ha di solito un lato giusto e l’altro obsoleto. Quel confronto separa un problema di identità da un problema di inoltro.

Il contrasto netto tra piano di controllo e piano dati è un espediente didattico, non una descrizione della codifica. RFC 8277 colloca l’etichetta dentro la NLRI etichettata, così l’annuncio stesso porta il binding; usarla per l’inoltro è il passo successivo e separato.

Quando manca una rotta di un inquilino, controllate in questo ordine: due voci VPNv4 per il prefisso, la destinazione di rotta corretta su ciascuna, un salto successivo risolvibile e un’etichetta per cui il PE ricevente ha stato. Correggere l’identità con un valore di inoltro, o il contrario, supererà un controllo e fallirà il successivo.