EVPN tipo 2 contro tipo 5: perché un indirizzo IP significa due route
Una route di tipo 2 è indicizzata da un MAC più un IP opzionale; una route di tipo 5 è indicizzata da un prefisso. Leggi la chiave, non la maschera, prima di definire una route di dimensioni host.
Due route sulla stessa macchina possono puntare a 198.51.100.77 e comunque rispondere a domande diverse. Una descrive dove è raggiungibile un indirizzo MAC e, facoltativamente, quale IP vi è associato. L'altra descrive un prefisso che si risolve tramite un next hop, anche quando quel prefisso è un singolo host. Confonderle produce un ticket che sembra un bug di routing ma in realtà è un tipo di route letto male.
Il modo più rapido per distinguerle è leggere la chiave attorno a cui è costruito l'NLRI, non la maschera alla sua estremità.
La chiave della route dice cosa afferma la route
Il tipo 2 è la route di annuncio MAC/IP di RFC 7432, e la sua chiave è l'indirizzo MAC a 48 bit all'interno dell'NLRI. Dietro quella chiave c'è un campo indirizzo IP il cui campo lunghezza può essere 0, 32 o 128 bit, quindi un annuncio di solo MAC è una route completa e non una voce host con pezzi mancanti. Lo stack di etichette che segue punta al contesto di bridging in cui vive quel MAC.
Se il campo IP è compilato cambia ciò che la route dichiara, non che tipo di route sia. Con una lunghezza di 32 o 128 bit, il mittente afferma anche che questo IP appartiene a quel MAC all'interno di un'istanza EVPN. Con lunghezza zero, il mittente non fa alcuna affermazione sull'IP. Nessuna delle due versioni dice che un prefisso è raggiungibile tramite un router.
Il tipo 5 è la route di prefisso IP di RFC 9136, e la sua chiave è un prefisso scritto come lunghezza più altrettanti bit. La lunghezza va da 0 a 32 per IPv4 e da 0 a 128 per IPv6.
Entrambi gli estremi di questo intervallo sono legittimi, e nessuno implica un MAC. Un prefisso di lunghezza zero afferma la raggiungibilità senza nominare un host, mentre un /32 nomina esattamente un indirizzo. L'NLRI porta anche un indirizzo IP di gateway che il lato di uscita usa per costruire l'indice overlay, più un'etichetta per il contesto di inoltro. Non c'è alcun campo MAC su cui commutare, per questo un ricevente tratta il tipo 5 come una destinazione instradata.
Una route di prefisso /32 non è un tipo 2 rinominato
I prefissi di dimensioni host sono normali route di tipo 5. Una route di prefisso /32 e un tipo 2 per lo stesso indirizzo possono coesistere in un'istanza EVPN, e portano informazioni di inoltro diverse.
Prendi 198.51.100.77 in un'istanza EVPN che usa VNI 10100. Un tipo 2 può associarlo al MAC 02:00:00:00:00:77 e a un'etichetta che identifica il dominio bridge in cui quel MAC è stato appreso. Un tipo 5 può annunciare 198.51.100.0/24 per l'intera sottorete, oppure 198.51.100.77/32 solo per quell'indirizzo, con un indirizzo di gateway che punta al VTEP di uscita. Gli indirizzi si sovrappongono di proposito perché le route rispondono a domande diverse.
Una route dice che esiste un binding di endpoint ed è raggiungibile tramite un particolare bridge. L'altra dice che un prefisso è raggiungibile tramite un particolare router, indipendentemente dal fatto che al suo interno sia mai stato appreso un endpoint.
Questa differenza decide dove guardare per primo quando il traffico fallisce. Se un singolo host è irraggiungibile mentre la route della sua sottorete sembra a posto, il tipo 5 non avrebbe mai dovuto trasportare quell'host; cerca il tipo 2 mancante. Se la route dell'host esiste ma l'intera sottorete è irraggiungibile, controlla se il tipo 5 è stato originato. Leggere i campi in ordine è meglio che indovinare dalla lunghezza della maschera.
Leggere entrambe le route senza indovinare
Su NX-OS, show bgp l2vpn evpn route type 2 e show bgp l2vpn evpn route type 5 dividono la tabella esattamente lungo questa linea, e show l2route evpn mac ip mostra i binding locali MAC-IP dietro le route di tipo 2. Su Junos, show evpn database elenca i binding MAC e IP appresi mentre show route table bgp.evpn.0 mostra ciò che è stato annunciato e ricevuto.
Filtra per route distinguisher ed etichetta Ethernet prima di trarre conclusioni. Lo stesso MAC o prefisso può comparire in più istanze EVPN, e una route che sembra sbagliata in un'istanza può essere corretta in un'altra.
Poi leggi l'NLRI in ordine: tipo di route, chiave, campi gateway o etichetta, poi i route target negli attributi. Un tipo 2 che porta un ESI diverso da zero ti dice che il MAC è multi-homed, ed è quel valore a legare insieme gli annunci di router PE diversi. Un tipo 5 che porta un indirizzo di gateway ti dice quale VTEP di uscita deve ricevere il traffico.
Se manca una route, controlla l'origine prima della codifica. Conferma che la sorgente abbia il binding o il prefisso localmente, poi conferma che il route target associato sia importato su questa macchina. La maggior parte delle segnalazioni di un tipo 5 rotto finisce su una politica di importazione, non sul formato dell'NLRI.
Annota il contesto, non solo il tipo di route
Annota insieme il tipo di route, l'istanza EVPN, il route distinguisher, i route target importati ed esportati e il next hop risolto. Un tipo 2 senza la sua istanza è ambiguo, e un next hop senza la famiglia di route invita a una conclusione errata.
Entrambe sono route EVPN anche quando il payload è un indirizzo IPv4. La famiglia di indirizzi dentro l'NLRI e la famiglia di indirizzi della route stessa sono proprietà separate, e un tipo 5 non diventa una route IPv4-unicast o VPN-IPv4 solo perché porta un prefisso IPv4.
Questa distinzione si vede al confine tra un piano di controllo EVPN e un IP-VRF. Il route target decide quale VRF importa il prefisso, mentre l'indirizzo di gateway e l'etichetta decidono come il pacchetto viene incapsulato verso l'uscita. Leggili insieme e la decisione di inoltro smette di sembrare arbitraria.
La prossima volta che un /32 appare nella tabella EVPN, controlla la chiave prima della maschera. Una chiave MAC con un IP opzionale è un binding di tipo 2; una chiave di prefisso è una route di tipo 5 qualunque sia la sua lunghezza. Scrivi accanto il route target e il next hop, e il prossimo ingegnere non dovrà ridefinire tutta la storia.