Bonding y teaming de red con NetworkManager: modos, requisitos del switch y verificación

Qué es

El bonding de Linux (el controlador del kernel bonding) presenta varias NIC físicas como una sola interfaz lógica (bondX). NetworkManager puede crear y gestionar una conexión de bond con un tipo de conexión bond y una conexión ethernet por cada esclavo, marcada como puerto del bond. Las opciones del controlador del kernel se guardan en la propiedad bond.options (por ejemplo, mode=802.3ad,miimon=100). El teaming (teamd, tipo de conexión team) es la alternativa más antigua; está obsoleto en RHEL 9 y se elimina en RHEL 10, por lo que las instalaciones nuevas deberían usar bonding.

Por qué importa

Los modos de bonding no son intercambiables, y una mala elección no aporta nada útil o directamente rompe la conectividad:

• active-backup: solo un esclavo está activo a la vez y los demás quedan en espera; si se pierde el enlace, se produce la conmutación por error. No requiere configuración en el switch: cada NIC puede incluso conectarse a un switch distinto, que es además la principal ventaja de este modo en términos de resiliencia.
• 802.3ad (LACP): los esclavos negocian con el switch un grupo de agregación de enlaces dinámico mediante el protocolo LACP. Normalmente todos los esclavos se conectan al mismo switch, y los puertos de ese switch deben configurarse explícitamente como un grupo LACP equivalente. Sin esa configuración en el switch, el tráfico se descarta o en la práctica solo se usa un esclavo.
• Los demás modos equilibran de forma distinta el reparto de carga y los requisitos del switch: balance-rr, balance-xor y broadcast exigen que los puertos del switch estén agrupados como EtherChannel/trunk estático (sin LACP); de lo contrario, el switch ve la misma dirección MAC oscilando entre puertos. balance-tlb y balance-alb no necesitan configuración en el switch.

Cómo aplicarlo

• Elige el modo según lo que el equipo del switch pueda configurar: active-backup cuando una configuración coordinada del switch no es posible o no está disponible; 802.3ad cuando se puede montar un port-channel/EtherChannel LACP adecuado.
• Créalo con nmcli: una conexión bond con bond.options y, después, dos o más conexiones ethernet con connection.master apuntando al bond y connection.slave-type bond.
• Verifica el estado negociado, no solo la configuración: cat /proc/net/bonding/bond0 muestra el modo activo, el estado MII de cada esclavo y, en 802.3ad, el partner LACP y los ID de agregador realmente acordados con el switch.
• Comprueba el comportamiento de la conmutación por error desactivando un esclavo (ip link set eth0 down, como root) y verificando que /proc/net/bonding/bond0 refleja el cambio y que la conectividad se mantiene; vuelve a activarlo con ip link set eth0 up. Haz esta prueba desde una consola, no a través del propio bond: si la conmutación falla, perderás la sesión.

Trampas

• Configurar 802.3ad en el host mientras los puertos del switch siguen en modo independiente (sin agregar): puede que el enlace se levante, pero el tráfico se pierde o se duplica.
• Dar por hecho que /proc/net/bonding refleja la intención de un archivo de configuración; solo refleja lo que el controlador ha negociado en este momento, así que conviene volver a comprobarlo después de cualquier cambio en el switch.