Agrupación LACP en Linux: configuración, verificación y resolución de problemas

La agrupación LACP en Linux combina varias interfaces Ethernet en un único enlace lógico, lo que proporciona un mayor ancho de banda agregado y conmutación automática por error entre las tarjetas de red físicas. Utiliza el estándar IEEE 802.3ad, en el que ambas partes (servidor y conmutador) negocian qué enlaces están activos y cómo se distribuye el tráfico. Esta entrada explica qué hace realmente LACP, cuándo elegirlo frente a otros modos de enlace de Linux, cómo configurarlo en un servidor Linux moderno y cómo verificar que funciona.

¿Qué es la agregación de enlaces y LACP?

La agregación de enlaces combina múltiples conexiones de red físicas en un único canal lógico. Tiene dos funciones: aumentar el ancho de banda total disponible en todo el grupo de enlaces y proporcionar una conmutación automática por error si se cae cualquier enlace miembro.

LACP, el Protocolo de Control de Agregación de Enlaces, es la versión dinámica de la agregación de enlaces definida por IEEE 802.3ad. En lugar de basarse en una configuración estática en ambos extremos, LACP intercambia paquetes de control llamados LACPDU entre el servidor y el conmutador. Ambas partes negocian qué enlaces se unen a la agregación, supervisan el estado de cada enlace e incorporan o excluyen miembros del grupo a medida que cambian las condiciones.

En un contexto Linux, LACP se ejecuta como modo 4 (802.3ad) del controlador de bonding del kernel. El controlador crea una interfaz lógica (normalmente bond0) que posee la dirección IP, mientras que las interfaces físicas como eth0 y eth1 se convierten en subordinadas del enlace. Desde la perspectiva del sistema operativo, hay una única interfaz de red. Desde la perspectiva del cableado, hay múltiples enlaces Ethernet paralelos.

Hay algunas cosas que LACP no hace específicamente, pero que la gente suele esperar:

• Una única conexión TCP sigue transitando por un solo enlace físico. LACP equilibra los flujos, no los paquetes dentro de un flujo. Dos enlaces 1 GbE agrupados no harán que una sola descarga vaya más rápido de 1 Gbps.
• LACP requiere un conmutador que admita 802.3ad. No formará un enlace con un conmutador no gestionado o que no admita LACP.
• Todos los enlaces miembros deben funcionar a la misma velocidad y en el mismo modo dúplex. No se puede agrupar un puerto de 1 GbE con un puerto de 10 GbE.

Modos de enlace de Linux: cuándo utilizar LACP

El controlador de enlace de Linux admite siete modos. La mayoría de las implementaciones en producción utilizan uno de los tres siguientes.

Modo 1: activo-reserva

Una interfaz miembro está activa, las demás permanecen inactivas. Si la activa falla, otra toma el relevo en unos pocos cientos de milisegundos. No se necesita configuración de conmutadores, lo que lo convierte en la opción adecuada cuando los conmutadores están fuera de su control o no admiten 802.3ad. Se obtiene redundancia, pero no ancho de banda adicional.

Modo 4: 802.3ad (LACP)

Todos los miembros transportan tráfico. El controlador de enlace y el conmutador utilizan LACP para negociar el conjunto activo y detectar fallos. El tráfico saliente se equilibra entre los miembros mediante una política de hash que usted configura. Esta es la opción estándar para servidores dedicados conectados a conmutadores gestionados cuando se desea tanto redundancia como ancho de banda adicional para cargas de trabajo de flujos múltiples.

Modo 6: balance-alb

Equilibrio de carga adaptativo en ambas direcciones, sin necesidad de compatibilidad con el conmutador. El controlador intercepta las respuestas ARP para reescribir las direcciones MAC y distribuir el tráfico entrante. Funciona, pero es frágil en comparación con LACP. Úsalo solo cuando sea realmente imposible configurar el lado del conmutador.

Regla de decisión:

• Sin conmutador gestionado, o si solo necesitas conmutación por error: modo 1 (active-backup).
• Conmutador gestionado, múltiples flujos, se desea tanto ancho de banda como redundancia: modo 4 (LACP).
• No es posible utilizar un conmutador gestionado, pero se necesita equilibrio en ambas direcciones: modo 6 (balance-alb).

Los modos 0 (balance-rr), 2 (balance-xor), 3 (broadcast) y 5 (balance-tlb) existen, pero rara vez son la opción adecuada en el hardware moderno. Elige el modo 1 o el modo 4 a menos que tengas una razón específica para no hacerlo.

Configuración de la agrupación LACP en Linux

En los sistemas modernos de Ubuntu y Debian, LACP se configura a través de netplan. En RHEL, CentOS Stream, AlmaLinux y Rocky Linux, utilice NetworkManager a través de nmcli o editando los archivos de conexión subyacentes.

Netplan (Ubuntu, Debian)

Inserta lo siguiente en /etc/netplan/01-lacp.yaml:

network:
  version: 2
  renderer: networkd
  ethernets:
    eth0:
      dhcp4: no
    eth1:
      dhcp4: no
  bonds:
    bond0:
      interfaces: [eth0, eth1]
      addresses: [10.0.0.5/24]
      gateway4: 10.0.0.1
      parameters:
        mode: 802.3ad
        lacp-rate: fast
        mii-monitor-interval: 100
        transmit-hash-policy: layer3+4

A continuación, aplícalo con netplan apply. Los parámetros clave:

• mode: 802.3ad habilita LACP.
• lacp-rate: fast envía LACPDUs cada segundo en lugar de los 30 segundos predeterminados. Debe coincidir con la configuración del conmutador.
• mii-monitor-interval: 100 sondea el estado del enlace cada 100 ms.
• transmit-hash-policy: layer3+4 distribuye los flujos por IP de origen/destino y puerto TCP/UDP. Esto produce un mejor equilibrio que la layer2 para el tráfico típico de web y bases de datos.

NetworkManager (RHEL, AlmaLinux, Rocky)

nmcli con add type bond ifname bond0 con-name bond0 \
  bond.options "mode=802.3ad,miimon=100,lacp_rate=fast,xmit_hash_policy=layer3+4"
nmcli con add type ethernet ifname eth0 master bond0
nmcli con add type ethernet ifname eth1 master bond0
nmcli con mod bond0 ipv4.addresses 10.0.0.5/24 ipv4.gateway 10.0.0.1 ipv4.method manual
nmcli con up bond0

Lado del conmutador

El conmutador necesita un grupo LAG (a menudo denominado canal de puertos) configurado en modo activo LACP, con el mismo número de puertos miembros que el enlace. La sintaxis exacta varía según el proveedor, pero los requisitos no: los puertos deben estar en la misma VLAN, configurados a la misma velocidad y dúplex, y utilizar el modo activo LACP al menos en un lado. La configuración más segura es que ambos lados estén activos.

En Cisco IOS:

interface range gigabitethernet0/1 - 2
 channel-group 1 mode active
 channel-protocol lacp

En Aruba/ProCurve:

trunk 1-2 trk1 lacp

La lacp_rate configuración del conmutador debe coincidir con la del host. Una discrepancia en este punto es uno de los errores de configuración de LACP más comunes y provoca fluctuaciones intermitentes cada 30 segundos.

Verificación y resolución de problemas de LACP

Comprueba el estado en tiempo real del enlace en el lado de Linux:

cat /proc/net/bonding/bond0

Cuatro cosas que hay que buscar en la salida:

1. Bonding Mode: IEEE 802.3ad Dynamic link aggregation confirma que el modo 4 está cargado.
2. Cada interfaz subordinada aparece en la lista con MII Status: up y link failure count: 0.
3. Un valor distinto de cero Partner Mac Address para cada subordinada. Si aquí todo son ceros, significa que el conmutador no está enviando paquetes LACP en absoluto, ya sea porque el puerto no está en un LAG con LACP activo o porque el cable está en el puerto equivocado.
4. Aggregator ID es el mismo en todos los miembros. Unos ID diferentes significan que los miembros no están realmente combinados, sino que actúan de forma independiente.

La comprobación más rápida para verificar que se está utilizando el ancho de banda es ejecutar iperf3 con múltiples flujos paralelos (iperf3 -P 8) desde otro host. Si el rendimiento total supera la capacidad de un solo enlace, LACP está equilibrando correctamente. Una prueba de un solo flujo que muestre la velocidad de un enlace es el comportamiento esperado, no un error.

Los problemas más comunes de LACP y sus causas:

• La MAC del socio es todo ceros: el puerto del conmutador no está en un LAG con LACP activo, o los cables están mal conectados.
• El enlace se activa, pero el rendimiento se queda estancado en un solo enlace: es probable que la política de hash se haya establecido por defecto en layer2, que solo realiza el hash en la MAC de destino. Cambie a layer3+4.
• Fluctuación intermitente cada 30 segundos: lacp_rate desajuste entre el host y el conmutador.
• Un subordinado funciona, pero el otro nunca transporta tráfico: discrepancia de velocidad/dúplex, o los puertos del conmutador no están en el mismo grupo LAG en el lado del conmutador.

Cuando LACP no es la respuesta adecuada

LACP resuelve un problema específico: agregar múltiples enlaces entre un host y un conmutador (o una pila de conmutadores) para obtener redundancia y ancho de banda por flujo. Hay situaciones en las que no es la herramienta adecuada.

Si solo necesitas redundancia y los conmutadores no admiten 802.3ad, utiliza el modo 1 (activo-reserva) en su lugar. Funciona con cualquier cosa.

Si necesita unir dos conmutadores independientes para obtener redundancia a nivel de chasis, el LACP estándar no abarcará dos conmutadores no relacionados. Necesitas la agregación de enlaces multichasis (MLAG), en la que dos conmutadores se presentan como un único socio LACP lógico. La mayoría de los proveedores de conmutadores empresariales implementan esto bajo su propio nombre: Cisco vPC, Arista MLAG, Juniper MC-LAG.

Si necesitas que un único flujo supere el ancho de banda de un enlace, LACP no puede hacerlo. Las opciones son utilizar un enlace físico más rápido (sustituir 2x 10 GbE por 1x 25 GbE o 1x 40 GbE) o utilizar una tecnología completamente diferente. SR-IOV proporciona a las máquinas virtuales un rendimiento de flujo único cercano a la velocidad de línea al dotar a cada máquina virtual de una NIC virtual acelerada por hardware, pero resuelve un problema diferente y tiene sus propias limitaciones. Ese es un tema para otra entrada.

Para la mayoría de los servidores dedicados y de coubicación que gestionan muchas conexiones simultáneas, LACP sigue siendo la respuesta estándar. Dos enlaces 10 GbE agrupados con layer3+4 hashing gestionan cómodamente más de 18 Gbps de tráfico agregado a través de muchos flujos, al tiempo que resisten un fallo de la NIC o del cable sin perder ni un solo paquete.