Un host EVPN silenzioso non si risolve mai: seguite l'ARP fino al binding

L'endpoint è collegato, la sua porta è attiva e l'host di monitoraggio continua a non raggiungerlo. Qualcuno esegue un ping dall'altro lato e tutto inizia a funzionare, il che fa sembrare il problema intermittente e la fabric innocente. Questo schema è la firma di un host silenzioso: trasmette raramente, quindi il comportamento di scoperta e aggiornamento della fabric conta più dello stato del suo collegamento. Iniziate con un IP, una MAC e un bridge domain previsti e seguite il successivo scambio di risoluzione.

Seguite il successivo scambio ARP o ND

Per IPv4, osservate lo scambio ARP dell'host richiedente; per IPv6, seguite il Neighbor Solicitation e l'Advertisement. Confermate che la richiesta entri nel segmento locale previsto e nel VNI previsto, perché nessun proxy può rispondere a una richiesta che non raggiunge mai il bridge domain corretto.

Poi guardate cosa sa la fabric del target. Una rotta solo MAC può identificare una destinazione Layer 2 mentre il proxy non ha ancora alcun binding IP-to-MAC per essa. Sono record separati, e controllarne uno non dice nulla sull'altro.

Se esiste un binding valido, il proxy può rispondere secondo la sua politica, ma la MAC in quel binding ha comunque bisogno di un percorso di inoltro attivo. Se il binding è assente, la richiesta deve raggiungere il collegamento dell'endpoint tramite il percorso di flooding o di replica prima che qualcosa possa imparare dalla risposta.

Due record che devono concordare

La rotta MAC risponde a dove vive l'indirizzo Ethernet. La tabella del proxy risponde a quale IP corrisponde a quale MAC. Un host che non ha parlato di recente può avere una rotta MAC perfettamente buona e nessuna voce proxy utilizzabile, ed è esattamente lo stato che produce un fallimento di risoluzione su un collegamento sano.

Al collegamento remoto, verificate se l'endpoint riceve davvero lo scambio e vi risponde. La sua risposta aggiorna l'apprendimento locale e l'annuncio EVPN corrispondente, ed è per questo che il ping manuale sembra sistemare le cose: avete generato il traffico che la fabric aspettava. Questo spiega anche perché la correzione non dura: una volta scaduta la voce aggiornata, l'endpoint torna silenzioso. Un ping pianificato tratta il sintomo e nasconde la lacuna di progettazione.

Dopo la risposta, seguite la rotta selezionata e lo stato di inoltro installato tornando verso il richiedente. Il successo della risoluzione e quello dell'inoltro sono due eventi separati, e un ticket che li confonde vi manda sul livello sbagliato.

Cosa presuppone realmente lo standard

RFC 9161 descrive l'apprendimento dinamico del proxy e il flooding predefinito delle richieste ARP e ND sconosciute. La soppressione completa di quel flooding è limitata alle implementazioni le cui ipotesi di apprendimento o di provisioning la rendono sicura, che è una condizione più stretta di quanto suggeriscano la maggior parte delle guide di configurazione.

Una fabric che si aspetta endpoint appena scoperti ha bisogno di un percorso funzionante per quelle richieste. Se qualcuno ha disabilitato il flooding delle richieste sconosciute per ridurre il traffico BUM, gli host silenziosi sono la popolazione che ne paga il prezzo, e il sintomo arriva settimane dopo come lamentela di raggiungibilità intermittente.

Leggete l'impostazione di soppressione come una dichiarazione su ciò che la fabric promette di sapere. Se nulla fornisce i binding, la promessa non è vera per i mittenti poco frequenti. Confrontate la soppressione configurata con il sistema di provisioning che dovrebbe alimentarla. Quando i due non concordano, la fabric si comporta esattamente come configurato ed è l'aspettativa che va corretta.

Aggiornamento, invecchiamento e l'alternativa statica

Lo standard descrive sonde di aggiornamento supportate prima che le voci dinamiche invecchino. Le risposte aggiornano lo stato pertinente del bridge e del proxy; l'assenza di risposte può legittimamente portare alla rimozione e al ritiro della rotta. Non è un bug da sopprimere allungando ogni timer.

Estendere indefinitamente i timer di invecchiamento scambia un guasto visibile con uno obsoleto: la fabric continua ad annunciare una posizione che l'host ha lasciato. Usate i controlli documentati dell'implementazione e scegliete una durata che corrisponda alla frequenza con cui si può ragionevolmente attendersi che l'endpoint parli.

Per endpoint noti e gestiti, un binding statico o fornito dal controller è un secondo modello legittimo. Richiede un proprietario che gestisca sostituzione e spostamento, perché un record fornito non si aggiorna da solo quando l'host passa a un'altra porta.

Cosa registrare prima del prossimo ticket

Tenete la fonte del binding, l'ora dell'ultimo aggiornamento, la posizione attuale e qualsiasi evento di ritiro accanto alla rotta MAC. Quel record risponde alla domanda che il ticket pone davvero: l'applicazione attende la scoperta, si affida a uno stato obsoleto o non riesce a inoltrare dopo una risoluzione riuscita?

Poi decidete quale dei tre siete disposti a gestire. Scoperta con flooding, aggiornamento con una durata realistica o provisioning con un proprietario sono tutti difendibili. Una fabric configurata per uno e da cui ci si aspetta che si comporti come un altro è il punto in cui gli host silenziosi scompaiono.