EVPN è attivo ma il servizio no: quattro punti di controllo

Raggiungere l'indirizzo del VTEP remoto dimostra che la rete sottostante trasporta pacchetti, e questo è tutto ciò che dimostra. Il servizio del tenant richiede una sessione BGP EVPN con la famiglia di indirizzi corretta, un VNI locale collegato e operativo, una rotta originata e un import all'estremità remota. Sono quattro punti di controllo separati, ciascuno con una riparazione diversa. Trattare una rete sottostante verde come prontezza del servizio è il modo più comune in cui un'implementazione EVPN si blocca.

Leggili in ordine e fermati al primo che non è ciò che il progetto si aspetta. I punti di controllo successivi non possono compensare un guasto precedente.

Punto di controllo 1: il trasporto verso il VTEP

Inizia dalla raggiungibilità tra gli indirizzi di loopback usati come sorgenti VTEP. La rotta deve esistere nella rete sottostante, il percorso deve essere consentito, compreso qualsiasi requisito di incapsulamento, e il percorso di ritorno deve funzionare. Una rotta che esiste ma è filtrata in una direzione produce un guasto asimmetrico che sembra intermittente. Conferma entrambe le direzioni prima di procedere.

Annota gli indirizzi di origine e destinazione che hai controllato. Un passo successivo che risolve un next hop attraverso un indirizzo diverso è un test diverso, e trattarli come uno solo è il modo in cui un next hop risolto viene incolpato di un guasto di trasporto.

Punto di controllo 2: la famiglia EVPN, non il numero di sessioni

Una sessione BGP stabilita non significa che la famiglia di indirizzi EVPN sia stata negoziata. Guarda lo stato specifico della famiglia per il vicino: se la famiglia è abilitata, se è stata negoziata con il peer e se la sessione la trasporta del tutto. Una sessione attiva per IPv4 unicast che non ha mai negoziato EVPN non mostra nulla di sbagliato in un riepilogo generale dei vicini, e la specifica di overlay EVPN tratta le procedure di servizio e controllo come questioni separate dal trasporto.

Controlla anche l'indirizzo di origine della sessione. Un peering costruito su un indirizzo che non è la sorgente VTEP è una discrepanza di progettazione che attende di spiegare un guasto di inoltro.

Punto di controllo 3: il servizio locale è collegato

Il VNI locale deve essere collegato al bridge o al VRF che rappresenta il tenant, e la piattaforma deve segnalarlo come operativo. Lo stato di appartenenza usato dal modello di replica può contare prima che venga appresa qualsiasi MAC dell'host, quindi una tabella degli endpoint vuota non è prova che il servizio sia inattivo.

Poi conferma ciò che il dispositivo origina davvero: la rotta locale per quel VNI con i route target specificati dal progetto. Un VNI collegato ma non annunciato produce un servizio che esiste localmente e in nessun altro luogo.

Punto di controllo 4: l'import nel ricevitore

Sul dispositivo ricevente, confronta i route target esportati e importati invece dei VNI numerici. Un numero di VNI corrispondente non prova che l'istanza ricevente importi l'annuncio, e un route target non corrispondente è invisibile in un elenco di VNI. Risolvi il next hop annunciato attraverso la rete sottostante prima di fidarti della voce di inoltro. Poi leggi lo stato di inoltro dell'overlay per il servizio e non per il dispositivo nel suo insieme.

Una tabella dei peer può anche riflettere dati del piano dati o apprendimento dell'appartenenza specifici dell'implementazione. Leggi la sua origine e il contesto del servizio insieme alla rotta EVPN invece di trattare il numero di righe come prova.

Un record che percorre il percorso

Tieni un record per servizio: stato locale del VNI, il vicino EVPN e la famiglia, la rotta originata e il risultato ricevuto e importato. Percorri quel record dall'origine all'installazione. Quando qualcosa fallisce, il record dice quale dei quattro punti di controllo riparare invece di quale comando provare.

Aggiungi timestamp mentre lo fai. Un import che appare minuti dopo l'annuncio è una questione di policy o di convergenza, mentre uno che non appare mai è una questione di configurazione, e quella differenza è visibile solo se hai annotato quando hai guardato.

Quando il VXLAN statico è la risposta giusta

Un percorso dati VXLAN configurato staticamente può funzionare con peer forniti manualmente mentre la tabella EVPN resta vuota. Non è un deployment EVPN rotto, è un modello di controllo diverso. Decidi quale intende il progetto prima di diagnosticare una tabella vuota come guasto.

Un vicino IGP nella rete sottostante fornisce trasporto e nulla di più. Lo stato del servizio dell'overlay è una cosa separata da costruire e una cosa separata da verificare.