AFI e SAFI: leggete la coppia prima del nome del servizio

Potete vedere una sessione salire, una rotta comparire e comunque leggere il servizio sbagliato. La coppia di numeri all'inizio di ogni annuncio, l'identificatore di famiglia di indirizzi e l'identificatore della famiglia di indirizzi successiva, decide quale parser legge il payload e quale tabella conserva il risultato. Sbagliate la coppia e la politica di importazione, la corrispondenza del route target e la ricerca del next hop girano tutte contro una struttura che nessuno ha annunciato. Il percorso qui sotto parte da quella coppia e finisce nel risultato dell'inoltro.

Due numeri decidono in quale tabella va la rotta

La coppia compare due volte: dentro la capacità multiprotocollo, dove uno speaker annuncia una famiglia, e davanti a ogni NLRI che quella famiglia trasporta. Questo la rende una proprietà della rotta e non un'impostazione sulla scatola di origine. I fornitori la stampano come nome del tipo Address family VPNv4 Unicast, e la formulazione cambia tra release mentre i numeri restano fermi.

Quattro codifiche coprono quasi ogni caso aziendale: 1 con 128 per VPN-IPv4 etichettata MPLS, 2 con 128 per l'equivalente IPv6, 25 con 65 per VPLS segnalata da BGP e 25 con 70 per EVPN. Il primo errore è supporre che ogni servizio Layer 2 stia dietro 25 con 65, il che nasconde EVPN. Il secondo è trattare le due famiglie IP come un'unica famiglia con un indirizzo più lungo, quando vengono negoziate separatamente e possono essere accettate su peer diversi. Un terzo appare quando si copia un modello da una release che ne conosce solo una. Una ricerca nel registro risolve tutti e tre più in fretta di una congettura costruita sul nome del servizio.

Trattate le quattro righe come esempi del registro IANA, non come il registro stesso. Quando un numero non corrisponde a nulla di noto, cercatelo prima di costruirci attorno una politica.

AFI 25 trasporta due formati NLRI senza rapporto

Entrambe le famiglie Layer 2 stanno sotto AFI 25, e la somiglianza finisce lì. L'NLRI VPLS in RFC 4761 section 3.2.2 trasporta una lunghezza, un distinguitore di rotta, un VE ID, un offset di blocco VE, una dimensione di blocco VE e una base di etichette, che insieme nominano un estremo pseudowire e la sua etichetta. EVPN conserva AFI 25 e passa a SAFI 70, dove il payload è un tipo di rotta: scoperta automatica Ethernet, annuncio MAC/IP, multicast inclusivo, segmento Ethernet, prefisso IP. Lo stesso offset di byte significa quindi cose diverse nelle due famiglie. Un parser scritto per una legge l'altra senza lamentarsi e produce assurdità. La coppia è l'unico avvertimento che l'interpretazione è sbagliata.

Un campo che in una famiglia significa offset di blocco VE non ha controparte nell'altra, e la rotta di annuncio MAC/IP esiste solo in EVPN. Citare un attributo come se valesse per entrambe è il modo in cui una revisione di cattura va storta.

Quando qualcuno vi consegna una cattura o una tabella di fornitore, chiedete a quale famiglia appartiene l'attributo. Poi confermate che l'implementazione ricevente supporti quella famiglia, non il nome del servizio sulla scheda tecnica. Due piattaforme possono entrambe dichiarare il supporto VPLS mentre implementano famiglie di segnalazione diverse. La coppia le separa; l'etichetta del prodotto no.

La famiglia di indirizzi della sessione è una questione separata

VPN-IPv6 viene annunciato di routine su una sessione la cui connessione TCP passa su IPv4, e questo è un progetto supportato, non un guasto. Leggere solo il riepilogo della sessione non dice quindi nulla su quali famiglie VPN si scambiano i peer.

Famiglia NLRI, famiglia di trasporto e famiglia di inoltro sono tre decisioni indipendenti. Un router può parlare IPv4 con il suo peer, accettare la raggiungibilità VPN-IPv6 e installare una rotta il cui next hop è un indirizzo IPv6 raggiungibile per un percorso che non avevate previsto. Ogni livello richiede la propria conferma. I siti che segnalano destinazioni IPv6 irraggiungibili mentre gli annunci sembrano corretti hanno di solito perso la risoluzione del next hop, non la negoziazione delle famiglie.

Provate la famiglia di indirizzi della sessione da sola, poi le famiglie che trasporta, poi ciò che il core può inoltrare. Tenere le tre separate evita la diagnosi errata comune in cui un annuncio corretto viene letto come prova che IPv6 funziona da un capo all'altro. Dimostra solo che un peer ha detto a un altro qualcosa di un prefisso.

Negoziati, ricevuti, importati, installati

Per una rotta attesa, quattro stati devono valere in ordine, e ciascuno è osservabile. La famiglia deve essere negoziata con quel peer, la rotta deve arrivare, un route target deve importarla nel contesto previsto e il next hop deve risolversi perché la rotta si installi. Saltare il primo stato rende gli altri tre senza risposta, perché una famiglia non negoziata non produce rotte da ispezionare. Sulle piattaforme in stile Cisco i riepiloghi di famiglia e le capacità per peer sono comandi separati.

show bgp all summary
show bgp vpnv4 unicast all summary
show bgp l2vpn evpn summary
show bgp neighbors <peer-address> | include Address family

La negoziazione compare nello scambio di capacità stampato per peer, e una sessione stabilita senza alcuna famiglia elencata non trasporta nulla di ciò che avete chiesto. L'importazione è decisa dai route target trasportati come community estese, quindi una coppia corretta con un target digitato male lascia la tabella vuota. L'installazione dipende poi dalla risoluzione del next hop nel contesto ricevente, che può fallire mentre ogni annuncio sembra perfetto.

Confermate il piano dati per ultimo, perché una rotta nella tabella è un'affermazione, non una consegna. Gli stessi quattro stati valgono per ogni famiglia; cambiano solo i comandi e i nomi delle tabelle.

Cosa una coppia di famiglie non dimostra mai

Leggere bene la coppia vi dice come interpretare le informazioni di routing che seguono, e questa è tutta l'affermazione. Non dice nulla sulla raggiungibilità, nulla sulla politica e nulla sulla salute del piano dati. Confondere le due cose produce affermazioni sicure su una rete che nessuno ha verificato. Un disallineamento di route target e un next hop rotto sembrano identici solo guardando la coppia. La coppia è un'istruzione di lettura, mai un verdetto.

Quando escalate, mettete la coppia, il route target e il next hop risolto nella stessa nota. L'ingegnere successivo ha così tre cose indipendenti da provare invece di un nome di servizio da reinterpretare. Se manca la negoziazione lo vedono subito, un target sbagliato lascia l'importazione visibilmente assente e un next hop non risolto lascia la rotta presente ma inutilizzabile.