Bond activo-reserva de Linux sobre EVPN all-active: que se rompe

Poña un bond activo-reserva no servidor e un segmento Ethernet all-active na fábrica, e a metade do tráfico de volta pode desaparecer sen que se mova un só contador de erros. Ningunha das dúas configuracións é incorrecta por si soa. O problema está no traspaso entre elas, onde un lado escolle un único porto e o outro supón que cada folla conectada pode entregar. Siga unha trama en cada dirección e o desaxuste faise evidente.

Que fai o activo-reserva cunha trama entrante

O modo de bonding 1 mantén exactamente un escravo na ruta de transmisión e só o cambia cando falla o actual. Esa parte é ben coñecida. O que importa aquí é o lado de recepción: o núcleo só entrega unha trama á pila se chega polo escravo activo, e descarta as tramas que aparecen en calquera outro escravo. Este all_slaves_active axuste existe precisamente para relaxar esa regra, e por defecto está desactivado. ip -d link show bond0 imprime o valor actual xunto ao modo.

/proc/net/bonding/bond0 nomea o escravo activo e informa do estado da ligazón de cada escravo. Ese ficheiro é a única fonte honesta de que porto está a levar tráfico neste momento.

Un host neste modo ten unha soa ruta de recepción utilizábel á vez, escollida localmente sen coñecemento da fábrica. Se unha trama para ese host chega polo outro cable, o porto do conmutador cóntaa como recibida, a pila do host nunca a ve, e todos os contadores agás o contador de descartes propio do host parecen perfectamente sans.

Que fai o multihoming all-active cun seguinte salto remoto

O multihoming EVPN describe un conxunto de follas que comparten un segmento Ethernet, identificado por un ESI, e anuncia ese segmento ao resto da fábrica. No modelo all-active, os pares remotos instalan máis dun seguinte salto para os enderezos do segmento. O unicast cara ao servidor pode entón chegar a calquera das follas, e a fábrica é libre de escoller por fluxo. Ese é todo o sentido do deseño, e tamén é a suposición que debe cumprir o bond do servidor.

O tráfico inundado segue outra regra. As follas elixen un reenviador designado por segmento, así que broadcast, unicast descoñecido e multicast entran normalmente por un deles. Por tanto, unicast e inundación toman dúas decisións separadas, e só unha delas aparece no estado do bond do host.

Onde discrepan as dúas eleccións

O núcleo elixe o seu escravo activo a partir do estado da ligazón e da súa propia política. A fábrica elixe os seguintes saltos a partir das rutas EVPN, e un reenviador designado a partir dunha elección entre as follas. Ningún dos dous procesos consulta o outro. Cando elixen follas distintas, o fallo depende da dirección: o que o servidor envía sae con normalidade, e as respostas desaparecen.

Existen dúas saídas admitidas, e non son intercambiábeis. Dea ao host un bond que a fábrica poida tratar como un único enlace lóxico, o que na práctica significa un bond LACP negociado coas follas, e ambos os enlaces están realmente activos á vez. Ou acepte tamén entrega single-active desde a fábrica, de modo que o segmento siga o mesmo modelo dun porto á vez que o bond. O que non funciona é un segmento all-active diante dun bond que só escoita nun porto, a menos que active deliberadamente a recepción nos escravos inactivos e acepte a entrega duplicada que iso conleva.

Por que o cable de reserva segue parecendo san

Un cable que non leva tráfico segue informando de ligazón arriba, e un escravo de reserva nun bond está deseñado para parecer listo. Os operadores len iso como redundancia e deixan de facer preguntas.

Pregunte en cambio que porto físico usou a trama de volta. No host, conte os paquetes recibidos por escravo en lugar de por bond, porque o contador do bond oculta a asimetría. Na folla, mire as entradas de reenvío da ponte para a MAC do servidor e o conxunto de seguintes saltos que transporta a ruta EVPN. Se a entrada apunta á folla cuxa ligazón co host é a de reserva, o deseño está a entregar nun porto que o host ignora. Trátase dun desaxuste de configuración e non dunha avaría de hardware, e ningunha cantidade de monitorización do estado da ligazón o sacará á luz.

Probe a entrega en ambas as direccións, non o estado da ligazón

Construía unha matriz cunha fila por fallo e unha columna por dirección, e enchérea con tráfico entregado en lugar do estado da interface. A fila un é a operación normal, e é xusto onde se agocha o desaxuste, porque o síntoma parece un problema da aplicación.

Despois quite a ligazón activa do host, quite unha folla, quite os enlaces ascendentes desa folla e restáureos un a un. Tras cada paso, anote o escravo activo, o estado do segmento EVPN, a entrada de reenvío remota e o caudal observado en ambas as direccións. Unha folla que perde a súa ruta cara á fábrica mentres a súa ligazón co host segue arriba é o caso interesante, porque o apeo segue anunciado e pode converterse en silencio nun calexón sen saída. Probe con fluxos unicast novos e co tráfico inundado do que depende a aplicación, porque ambos usan decisións de reenvío distintas.

Acepte o deseño só cando a matriz mostre entrega bidireccional pola ruta que pretendía. Dous cables con ligazón arriba non son ese resultado.