Bond activo-respaldo de Linux sobre EVPN all-active: qué se rompe

Ponga un bond activo-respaldo en el servidor y un segmento Ethernet all-active en la fábrica, y la mitad del tráfico de vuelta puede desaparecer sin que se mueva un solo contador de errores. Ninguna de las dos configuraciones es incorrecta por sí sola. El problema está en el traspaso entre ellas, donde un lado elige un único puerto y el otro supone que cada hoja conectada puede entregar. Siga una trama en cada dirección y el desajuste se vuelve evidente.

Qué hace el activo-respaldo con una trama entrante

El modo de bonding 1 mantiene exactamente un esclavo en la ruta de transmisión y lo cambia solo cuando falla el actual. Esa parte es bien conocida. Lo que importa aquí es el lado de recepción: el núcleo solo entrega una trama a la pila si llega por el esclavo activo, y descarta las tramas que aparecen en cualquier otro esclavo. Este all_slaves_active ajuste existe precisamente para relajar esa regla, y por defecto está desactivado. ip -d link show bond0 imprime el valor actual junto al modo.

/proc/net/bonding/bond0 nombra el esclavo activo e informa del estado del enlace de cada esclavo. Ese archivo es la única fuente honesta de qué puerto está llevando tráfico en este momento.

Un host en este modo tiene una sola ruta de recepción utilizable a la vez, elegida localmente sin conocimiento de la fábrica. Si una trama para ese host llega por el otro cable, el puerto del conmutador la cuenta como recibida, la pila del host nunca la ve, y todos los contadores salvo el contador de descartes propio del host parecen perfectamente sanos.

Qué hace el multihoming all-active con un siguiente salto remoto

El multihoming EVPN describe un conjunto de hojas que comparten un segmento Ethernet, identificado por un ESI, y anuncia ese segmento al resto de la fábrica. En el modelo all-active, los pares remotos instalan más de un siguiente salto para las direcciones del segmento. El unicast hacia el servidor puede entonces llegar a cualquiera de las hojas, y la fábrica es libre de elegir por flujo. Ese es todo el sentido del diseño, y también es la suposición que debe cumplir el bond del servidor.

El tráfico inundado sigue otra regla. Las hojas eligen un reenviador designado por segmento, así que broadcast, unicast desconocido y multicast entran normalmente por uno de ellos. Por tanto, unicast e inundación toman dos decisiones separadas, y solo una de ellas aparece en el estado del bond del host.

Dónde discrepan las dos elecciones

El núcleo elige su esclavo activo a partir del estado del enlace y de su propia política. La fábrica elige los siguientes saltos a partir de las rutas EVPN, y un reenviador designado a partir de una elección entre las hojas. Ninguno de los dos procesos consulta al otro. Cuando eligen hojas distintas, el fallo depende de la dirección: lo que el servidor envía sale con normalidad, y las respuestas desaparecen.

Existen dos salidas admitidas, y no son intercambiables. Dé al host un bond que la fábrica pueda tratar como un único enlace lógico, lo que en la práctica significa un bond LACP negociado con las hojas, y ambos enlaces están realmente activos a la vez. O acepte también entrega single-active desde la fábrica, de modo que el segmento siga el mismo modelo de un puerto a la vez que el bond. Lo que no funciona es un segmento all-active delante de un bond que solo escucha en un puerto, a menos que active deliberadamente la recepción en los esclavos inactivos y acepte la entrega duplicada que ello conlleva.

Por qué el cable de respaldo sigue pareciendo sano

Un cable que no lleva tráfico sigue informando de enlace arriba, y un esclavo de reserva en un bond está diseñado para parecer listo. Los operadores lo leen como redundancia y dejan de hacer preguntas.

Pregunte en cambio qué puerto físico usó la trama de vuelta. En el host, cuente los paquetes recibidos por esclavo en lugar de por bond, porque el contador del bond oculta la asimetría. En la hoja, mire las entradas de reenvío del puente para la MAC del servidor y el conjunto de siguientes saltos que transporta la ruta EVPN. Si la entrada apunta a la hoja cuyo enlace con el host es el de reserva, el diseño está entregando en un puerto que el host ignora. Se trata de un desajuste de configuración y no de una avería de hardware, y ninguna cantidad de monitorización del estado del enlace lo sacará a la luz.

Pruebe la entrega en ambas direcciones, no el estado del enlace

Construya una matriz con una fila por fallo y una columna por dirección, y rellénela con tráfico entregado en lugar del estado de la interfaz. La fila uno es la operación normal, y es justo donde se esconde el desajuste, porque el síntoma parece un problema de la aplicación.

Después quite el enlace activo del host, quite una hoja, quite los enlaces ascendentes de esa hoja y restáurelos uno a uno. Tras cada paso, anote el esclavo activo, el estado del segmento EVPN, la entrada de reenvío remota y el caudal observado en ambas direcciones. Una hoja que pierde su ruta hacia la fábrica mientras su enlace con el host sigue arriba es el caso interesante, porque el apeo sigue anunciado y puede convertirse en un callejón sin salida. Pruebe con flujos unicast nuevos y con el tráfico inundado del que depende la aplicación, porque ambos usan decisiones de reenvío distintas.

Acepte el diseño solo cuando la matriz muestre entrega bidireccional por la ruta que pretendía. Dos cables con enlace arriba no son ese resultado.