VPNv4 richiede MPLS nel core? Non necessariamente

Attivare la famiglia di indirizzi VPNv4 tra due router crea solo un contesto di distribuzione delle rotte e nient’altro. Non installa un percorso di inoltro e non dice quale incapsulamento porterà un pacchetto client fino all’endpoint remoto. Una volta separati questi due fatti, la domanda «serve MPLS nel core» diventa più stretta e ricevibile di risposta, riguardo al piano dati supportato dalla piattaforma.

Che cosa negozia davvero la famiglia di indirizzi

BGP multiprotocollo trasporta le informazioni di raggiungibilità del livello di rete VPNv4 sotto AFI 1 e SAFI 128, e ogni voce accoppia un distinguitore di rotta con un prefisso e un’etichetta. La sessione negozia che entrambi gli interlocutori possono codificare e decodificare tali informazioni. Ciò che non negozia è un piano dati. Tutto ciò che segue questo paragrafo riguarda l’inoltro, e nulla di esso è deciso dall’attivazione della sessione.

Quindi una sessione riuscita è prova di capacità del piano di controllo, non dell’inoltro. Un router può mantenere migliaia di voci VPNv4 e comunque scartare ogni pacchetto client, ed è per questo che le due classi di guasto vengono confuse fin dall’inizio.

Osservate l’etichetta nell’NLRI. È un’etichetta di servizio, legata a un prefisso all’interno di una VRF, e ha un ruolo di inoltro quando il pacchetto raggiunge l’endpoint di uscita. Se qualche dispositivo di transito la legga è una decisione di progetto separata.

Ricezione, importazione e inoltro sono tre passaggi

Ricevere una rotta, essere autorizzati a usarla e poter inoltrare con essa sono compiti di parti diverse dell’apparecchio. BGP memorizza ciò che sente; la politica di importazione e la corrispondenza del target di rotta decidono quale VRF può considerarla; poi il piano di inoltro deve risolvere il salto successivo annunciato in qualcosa che può davvero mettere su un cavo.

È in questo passaggio intermedio che vivono i guasti più sorprendenti. Una rotta può essere presente nella tabella BGP, valida e persino la migliore, mentre la tabella delle rotte della VRF resta vuota perché nessun target di rotta corrispondeva all’elenco di importazione. Nulla registra un errore di protocollo, perché non si è verificato alcun errore di protocollo.

L’ultimo passaggio è dove si vede il supporto della piattaforma. Un salto successivo raggiungibile nel sottostante non è automaticamente risolvibile come trasporto di servizio VPN, e l’apparecchio può richiedere un tipo di tunnel specifico, un’operazione di etichetta specifica o entrambi. Leggere lo stato di risoluzione è più informativo che leggere il numero di rotte.

Un core IP può trasportare uno stack che non commuta mai

La distinzione da conservare è tra «il core non esegue MPLS» e «non esiste alcuna etichetta nel servizio». Sono affermazioni diverse, e solo la prima riguarda i dispositivi di transito. La RFC 4023 definisce il trasporto di MPLS tramite tunnel IP o GRE, ed è il meccanismo che rende possibile la seconda affermazione su un core interamente IP.

customer packet + service label
  encapsulated in GRE, addressed to the egress tunnel endpoint
  forwarded by ordinary IP routers on the outer header
  decapsulated at the endpoint, label still meaningful

I router di transito inoltrano in base alla destinazione IP esterna e non hanno bisogno né dei prefissi dei client né della commutazione di etichette nativa. All’estremità remota il tunnel esterno viene rimosso e l’etichetta di servizio riprende il suo lavoro. Il core ha spostato un carico opaco, ed è esattamente ciò per cui una rete IP è adatta.

Ciò che questo progetto non vi dà è una garanzia universale. Non è prova che ogni router risolva ogni salto successivo VPNv4 attraverso qualsiasi interfaccia GRE, e non è motivo per cancellare una configurazione MPLS nativa funzionante. È un controesempio all’affermazione universale, e la domanda pratica resta locale alla piattaforma. Annotate quella domanda come limite della piattaforma e non come regola del protocollo.

Percorrete la catena sull’apparecchio finché non si rompe

Partite dalla rotta ricevuta e fermatevi al primo passaggio che fallisce, perché i passaggi successivi non possono essere diagnosticati mentre uno precedente è rotto. Quattro comandi coprono gran parte di ciò in un’implementazione tipica.

show bgp vpnv4 unicast all summary
show bgp vrf CUSTOMER_A ip route 198.51.100.0/24
show ip route vrf CUSTOMER_A 198.51.100.0
show mpls forwarding-table vrf CUSTOMER_A

Leggeteli come una sequenza e non come quattro controlli indipendenti. Il primo conferma che la famiglia è attiva e che il peer scambia rotte; il secondo mostra se il prefisso è arrivato con un salto successivo utilizzabile; il terzo prova l’idoneità all’importazione; il quarto mostra se il piano di inoltro vi ha legato un’etichetta o un tunnel.

Poi provate il percorso del carico di lavoro in entrambe le direzioni, con una MTU che sopravviva all’incapsulamento. GRE aggiunge byte di intestazione, e un percorso che supera sonde piccole può fallire su pacchetti a dimensione piena solo in una direzione, il che sembra un guasto applicativo e non di trasporto.

Due note operative chiudono il cerchio. GRE è incapsulamento, non riservatezza, quindi una rete di transito non affidabile necessita di una disposizione di sicurezza supportata sopra, non di un’ipotesi. E annotate quale incapsulamento la piattaforma supporta davvero prima della revisione del progetto, perché quella singola risposta decide se un core solo IP è una scelta valida o un piano che non può inoltrare.