Perché un solo tenant EVPN può mostrare più route distinguisher
Due RD nello stesso tenant non sono un conflitto. Risalite dall'output della CLI al MAC-VRF o all'IP-VRF che ha originato la rotta, poi controllate l'import RT e il VNI.
Filtrate la tabella EVPN per un solo tenant e le rotte portano due route distinguisher diversi. Il primo istinto è un conflitto di configurazione, e quell'istinto di solito è sbagliato. Il nome di un tenant è un'etichetta di business, non un oggetto unico del piano di controllo, quindi il contesto di bridging e il contesto di routing al suo interno possono annunciarsi legittimamente con identificatori separati. Risalite una rotta alla volta dall'output all'oggetto di servizio locale che l'ha originata e il secondo RD smette di sembrare un errore.
Partite dall'output che vi ha confuso
Scegliete una rotta invece dell'intera tabella. Annotate il tipo di rotta, il RD, i route target esportati e il next hop. Questi quattro campi bastano a identificare quale oggetto locale l'ha annunciata e quale politica remota dovrebbe importarla.
Su un dispositivo in stile NX-OS la vista dettagliata si ottiene con show bgp l2vpn evpn route-type 2 detail o show bgp l2vpn evpn route-type 5 detail. Su Junos le stesse informazioni si trovano in show route table bgp.evpn.0 detail. Sintassi diversa, stessi campi.
Non iniziate rendendo uguali tutti i numeri mostrati. Uniformare i RD è la modifica che rompe la politica di import su un fabric funzionante.
Date a ogni identificatore il suo compito
| Identifier | Question it answers | Where it is used |
|---|---|---|
| Route distinguisher | Which distinct route context contributed this advertisement? | Makes otherwise identical prefixes unique in BGP |
| Route target | Which importing service policy should receive the route? | Extended community matched by import policy |
| VNI | Which VXLAN service context carries the traffic? | Data plane encapsulation and mapping |
Un MAC-VRF conserva le informazioni di inoltro MAC per un servizio di bridging. Un IP-VRF fornisce un contesto di routing IP per un servizio instradato. Un tenant può includere entrambi, per questo un solo tenant può produrre più di un RD senza alcun errore di configurazione.
La RFC 7432 assegna il RD del MAC-VRF annunciante al suo EVPN NLRI e richiede RD distinti tra i MAC-VRF sullo stesso PE. Le procedure route-target sono separate: consentono uno o più attributi RT e si affidano alla politica di import per l'appartenenza. L'uguaglianza dei RD non è ciò che crea l'appartenenza condivisa, e trattarla così è la radice di questa confusione.
Risalite una rotta dall'annuncio all'import
Seguite la rotta in una direzione. Confermate il tipo di rotta, il servizio che l'ha originata, il RD, gli RT esportati e poi la politica di import sul PE che la riceve. Ogni passo risponde a una domanda diversa, e un guasto a qualsiasi passo appare come lo stesso prefisso mancante dall'altro lato.
Una volta che la rotta è presente, ispezionate il contesto di inoltro installato e la mappatura del VNI. Un VNI che coincide su entrambe le estremità dimostra che il piano dati è d'accordo; non dimostra che il piano di controllo abbia importato la rotta con la politica prevista.
Se la rotta compare sul PE remoto ma non passa traffico, il problema è andato oltre EVPN. Controllate il binding VNI-to-VLAN o VNI-to-VRF e il percorso di underlay prima di modificare di nuovo i route target. Partite dalla mappatura, poi l'underlay e solo dopo il piano di controllo. Annullare una modifica di route-target per inseguire un guasto del piano dati è un modo affidabile di rompere un import funzionante.
I prefissi di livello 3 restano rotte EVPN
Un prefisso IP nella tabella EVPN non è BGP IPv4-unicast ordinario. La rotta EVPN IP Prefix è un tipo di rotta a sé, e gli annunci MAC/IP e di prefisso IP viaggiano nella famiglia di indirizzi EVPN, che la RFC 7432 identifica come AFI 25 e SAFI 70.
Questa distinzione conta quando confrontate una rotta della tabella EVPN con una della tabella unicast. Possono descrivere la stessa destinazione ed essere comunque prodotte, filtrate e importate da politiche diverse. Leggere l'una come prova dell'altra è il modo in cui un fabric corretto sembra rotto durante una migrazione.
Verificate la derivazione del fornitore prima di confrontare i numeri
La RFC 9136 estende EVPN con le rotte IP Prefix e specifica se il RD applicabile provenga dal contesto MAC-VRF o IP-VRF. Per questo un'etichetta di servizio L2 e un'etichetta di servizio instradato nello stesso output vanno lette rispetto agli oggetti a cui appartengono, non ridotte a un solo RD per tenant.
La derivazione automatica di RD e RT dipende dal fornitore. Leggete la documentazione del fornitore distribuito per la formula in uso; un valore generato automaticamente visto su un solo switch non è una codifica universale, e confrontare i numeri di due fornitori raramente dimostra qualcosa.
Concludete con una traccia scritta per la rotta con cui avete iniziato: tipo, oggetto di origine, RD, RT esportato, politica di import, VNI installato. Sei campi spiegano l'annuncio a chi leggerà il ticket in seguito, e nessuno di essi richiede che i numeri del tenant coincidano.