Bond attivo-riserva di Linux su EVPN all-active: cosa si rompe

Mettete un bond attivo-riserva sul server e un segmento Ethernet all-active sul fabric, e metà del traffico di ritorno può sparire senza che un solo contatore di errori si muova. Nessuna delle due configurazioni è sbagliata di per sé. Il problema sta nella consegna tra le due, dove un lato sceglie una sola porta e l’altro presume che ogni foglia collegata possa consegnare. Seguite una trama in ciascuna direzione e la discrepanza diventa evidente.

Che cosa fa l’attivo-riserva a una trama in ingresso

La modalità bonding 1 tiene esattamente uno slave nel percorso di trasmissione e lo cambia solo quando quello attuale si guasta. Quella parte è ben nota. Qui conta il lato ricezione: il kernel consegna una trama allo stack solo se arriva sullo slave attivo, e scarta le trame che compaiono su qualsiasi altro slave. Questa all_slaves_active impostazione esiste proprio per allentare quella regola, ed è disattivata per impostazione predefinita. ip -d link show bond0 stampa il valore corrente accanto alla modalità.

/proc/net/bonding/bond0 nomina lo slave attivo e riporta lo stato del collegamento di ciascuno slave. Quel file è l’unica fonte onesta su quale porta stia attualmente portando traffico.

Un host in questa modalità ha un solo percorso di ricezione utilizzabile alla volta, scelto localmente senza alcuna conoscenza del fabric. Se una trama per quell’host arriva sull’altro cavo, la porta dello switch la conta come ricevuta, lo stack dell’host non la vede mai, e tutti i contatori tranne il contatore di scarto dell’host sembrano perfettamente sani.

Che cosa fa il multihoming all-active a un next hop remoto

Il multihoming EVPN descrive un insieme di foglie che condividono un segmento Ethernet, identificato da un ESI, e annuncia quel segmento al resto del fabric. Nel modello all-active, i peer remoti installano più di un next hop per gli indirizzi del segmento. L’unicast verso il server può quindi arrivare su una foglia qualsiasi, e il fabric è libero di scegliere per flusso. È tutto il senso del progetto, ed è anche l’ipotesi che il bond del server deve soddisfare.

Il traffico inondato segue una regola diversa. Le foglie eleggono un forwarder designato per segmento, quindi broadcast, unicast sconosciuto e multicast entrano normalmente da una di esse. Unicast e inondazione prendono quindi due decisioni separate, e solo una di esse appare nello stato del bond dell’host.

Dove le due elezioni non concordano

Il kernel sceglie il suo slave attivo dallo stato del collegamento e dalla propria politica. Il fabric sceglie i next hop dalle rotte EVPN, e un forwarder designato da un’elezione tra le foglie. Nessuno dei due processi consulta l’altro. Quando scelgono foglie diverse, il guasto dipende dalla direzione: ciò che il server invia esce normalmente, e le risposte spariscono.

Esistono due vie d’uscita supportate, e non sono intercambiabili. Date all’host un bond che il fabric può trattare come un unico collegamento logico, che in pratica significa un bond LACP negoziato con le foglie, ed entrambi i collegamenti sono davvero attivi insieme. Oppure accettate anche la consegna single-active dal fabric, così che il segmento segua lo stesso modello di una porta alla volta del bond. Ciò che non funziona è un segmento all-active davanti a un bond che ascolta solo su una porta, a meno che non attiviate deliberatamente la ricezione sugli slave inattivi e accettiate la consegna doppia che ne deriva.

Perché il cavo di riserva continua a sembrare sano

Un cavo che non porta traffico segnala comunque collegamento attivo, e uno slave di standby in un bond è progettato per sembrare pronto. Gli operatori lo leggono come ridondanza e smettono di fare domande.

Chiedete invece quale porta fisica ha usato la trama di ritorno. Sull’host, contate i pacchetti ricevuti per slave anziché per bond, perché il contatore del bond nasconde l’asimmetria. Sulla foglia, guardate le voci di inoltro del bridge per il MAC del server e l’insieme di next hop che la rotta EVPN trasporta. Se la voce punta alla foglia il cui collegamento host è di riserva, il progetto sta consegnando in una porta che l’host ignora. È una discrepanza di configurazione, non un guasto hardware, e nessuna quantità di monitoraggio dello stato del collegamento la farà emergere.

Testate la consegna in entrambe le direzioni, non lo stato del collegamento

Costruite una matrice con una riga per guasto e una colonna per direzione, poi riempitela con il traffico consegnato anziché con lo stato dell’interfaccia. La riga uno è il funzionamento normale, ed è proprio lì che la discrepanza si nasconde, perché il sintomo sembra un problema dell’applicazione.

Poi togliete il collegamento host attivo, togliete una foglia, togliete gli uplink di quella foglia e ripristinateli uno per uno. Dopo ogni passo, annotate lo slave attivo, lo stato del segmento EVPN, la voce di inoltro remota e il throughput osservato in entrambe le direzioni. Una foglia che perde il percorso verso il fabric mentre il suo collegamento host resta attivo è il caso interessante, perché il collegamento resta annunciato e può diventare silenziosamente un vicolo cieco. Testate con flussi unicast nuovi e con il traffico inondato da cui dipende l’applicazione, perché i due usano decisioni di inoltro diverse.

Accettate il progetto solo quando la matrice mostra una consegna bidirezionale lungo il percorso previsto. Due cavi con collegamento attivo non sono quel risultato.