IPv6 in una VPN MPLS: tre scelte, non una sola famiglia di indirizzi
Le rotte della VPN del cliente, la sessione BGP tra i PE e il trasporto nel core sono decisioni separate. Una sessione può girare in una famiglia e trasportarne un'altra.
Dite «fai girare un L3VPN IPv6 su BGP IPv6» in una revisione di progetto, e in quella sola frase si nascondono tre decisioni separate. Quali prefissi appartengono alla VPN del cliente, quali indirizzi portano la sessione di routing tra i bordi del provider e quale core muove il pacchetto etichettato sono scelte indipendenti. Possono essere tutte IPv6, possono essere miste, e il misto è permesso di proposito. È districare le tre che trasforma un requisito vago in qualcosa su cui una piattaforma può essere testata.
Separate i tre compiti
Il primo compito è la rotta del cliente: prefissi IPv6 che appartengono a un contesto di routing della VPN e devono restare fuori da ogni altro contesto. Il secondo è la connessione di routing tra i router di bordo del provider che scambiano quei prefissi. Il terzo è il trasporto che porta il pacchetto etichettato del cliente attraverso il core fino al bordo remoto. Nominare solo uno dei tre non è ancora un progetto.
| Job | The question it answers | What confusion looks like |
|---|---|---|
| Customer VPN routes | Which IPv6 prefixes belong to each VPN context, and how are they kept apart? | Prefixes leak into the global table and between customers |
| PE-to-PE BGP session | Which addresses carry the routing connection between the two edges? | A session-family mismatch gets chased as a core transport fault |
| Transport to the remote PE | How does the chosen core move the labelled packet to the far edge? | A route is present and unforwardable in the same moment |
Ogni compito ha la propria famiglia di indirizzi, i propri modi di fallire e spesso il proprio team. La tabella è utile proprio perché una singola frase in un documento di progetto tende a schiacciare tutte e tre le righe in una.
La famiglia della rotta è VPN-IPv6, non IPv6 unicast
RFC 4659 definisce la famiglia BGP/MPLS IPv6 VPN, e appartenerle è più specifico di quanto la parola IPv6 suggerisca. Una rotta lì è un distinguitore di rotta unito a un prefisso IPv6, codificato sotto AFI 2 e SAFI 128. L'IPv6 unicast ordinario è un'altra famiglia, quindi un annuncio che in un looking glass sembra un prefisso può non essere affatto lo stesso oggetto. Leggere male la famiglia è il primo modo in cui questo progetto va storto.
La differenza morde al bordo, dove una rotta deve atterrare nel contesto VPN giusto prima di fare qualsiasi cosa. Ricevere un prefisso dimostra che lo scambio è avvenuto e non dice nulla sull'installazione. Quello scarto produce il rapporto classico in cui la sessione è su e il cliente resta al buio.
La sessione può girare in una famiglia diversa dalla VPN
Niente obbliga la connessione BGP tra due bordi a usare la famiglia della VPN stessa. La specifica permette una sessione IPv4 o IPv6, e il trasporto IPv6 VPN è esso stesso definito sopra entrambi i tipi di core. Una sessione IPv6 quindi non dice nulla sulla famiglia di ciò che trasporta, e non sceglie nemmeno il piano dati. Tre bit indipendenti, e il progetto dovrebbe portarli tutti e tre separatamente.
Questo libera ed è facile da leggere male nello stesso respiro. Le rotte cliente IPv6 possono viaggiare su una sessione indirizzata IPv4, e le rotte IPv4 su una IPv6, purché la piattaforma supporti la combinazione e il next hop si risolva. Quello che non deve succedere è lasciare che la sessione implichi il carico utile, nel documento di progetto o nel monitoraggio che dimostra il servizio più tardi.
Il next hop su un core IPv4 ha la propria codifica
Quando il core sotto la VPN è IPv4, la rotta non compare con un next hop che il bordo di ingresso possa usare direttamente. Arriva in forma IPv6 mappata su IPv4, ed è così che la specifica esprime il bordo di uscita quando il trasporto sotto è IPv4. Il router di ingresso deve quindi trasformare quell'indirizzo mappato in qualcosa che riesca davvero a raggiungere attraverso il core, e la risoluzione è il passo che fallisce in silenzio.
Leggetelo come una dipendenza di inoltro e non come una stringa da copiare tra dispositivi. Confermate tre cose sulla piattaforma che gestite davvero: il next hop annunciato si risolve in un percorso utilizzabile, lo stack di etichette viene accettato e la destinazione atterra nel contesto VPN previsto. Se una di queste fallisce resta una sessione che sembra sana e non inoltra nulla, ed è per questo che il controllo appartiene al collaudo di accettazione e non a un incidente successivo.
Scrivete il requisito in quattro righe
Un requisito che vale la pena testare nomina quattro cose: la famiglia della VPN, il trasporto della sessione, la codifica del next hop e la disposizione del core. Poi nomina un prefisso cliente da seguire da un capo all'altro: attraverso scambio, installazione, risoluzione delle etichette e percorso di ritorno. «Supporta BGP IPv6» non copre nessuna delle quattro e nasconde dove vive davvero la discrepanza.
Una sessione sana senza lo scambio VPN-IPv6 è incompleta, e una rotta VPN ricevuta senza inoltro funzionante lo è altrettanto. Tenerle come righe di accettazione separate rende breve la prossima conversazione di diagnosi, perché la riga che fallisce è già scritta.