Guía Definitiva para Sysadmins: Configuración de Bonding de Interfaces de Red en Linux

Bonding (también llamado NIC teaming o link aggregation) te permite combinar dos o más interfaces de red físicas en una sola interfaz lógica. Bien configurado, te da redundancia real (si un cable o puerto del switch muere, el tráfico sigue fluyendo) y, dependiendo del modo, también más ancho de banda. Esta guía repasa los siete modos soportados por el kernel Linux, los requisitos del switch y los comandos exactos para configurar bonding con nmcli, /etc/network/interfaces y systemd-networkd, además de cómo verificar que realmente funciona.

El módulo bonding viene compilado en prácticamente todas las distribuciones modernas, así que no necesitas instalar nada: solo cargar el driver y declarar la configuración. Lo que sí necesitas es entender qué modo elegir, porque cada uno tiene compromisos distintos entre throughput, redundancia y requisitos de switch.

---

Cuando el enlace primario del homelab se cayó a las 3 AM un martes y me quedé sin acceso al Proxmox remoto, aprendí dos cosas: la importancia de bonding de interfaces y la cantidad de tutoriales que explican la teoría sin mostrar la configuración que efectivamente sobrevive un reboot. Esta guía documenta las tres formas de bonding que tienen sentido práctico (mode 1 active-backup, mode 4 LACP, mode 6 balance-alb), con los comandos exactos, los gotchas con switch management y un test de failover que verifica que el enlace efectivamente cambia en menos de 2 segundos.

Si tienes un servidor con dos NICs y quieres redundancia o más throughput, esto es lo que necesitas. Si tienes una sola NIC, esta guía te muestra qué placa comprar para empezar a planificar.

---

Por qué bother con bonding en 2026

La respuesta corta: porque los servidores modernos traen 2, 4 o más NICs y casi nadie las usa todas. Las razones reales para bonding son tres, en orden de adopción:

1. Redundancia: si tu única NIC muere o el cable se suelta, el servidor se queda sin red. Con bonding activo-pasivo (modo 1), la conmutación por error es de unos pocos milisegundos. Para un servidor de producción, esa diferencia entre 3 ms y 30 segundos de downtime se nota.
2. Throughput agregado: con dos enlaces de 10 Gbps en modo LACP (802.3ad), un solo cliente puede usar 20 Gbps si el switch distribuye el tráfico por MAC+IP, o hasta 10 Gbps agregados si lo balanceas por flujo. Es sumativo, no multiplicativo, pero duplicar el ancho de banda en homelab cuesta menos que migrar a 25 GbE.
3. Migración sin corte: si configuras un bond con mode=active-backup, puedes sacar y reemplazar cables uno a uno sin tirar el servicio. Útil en racks donde tocar una sola interfaz te deja fuera.

En el homelab, el caso clásico es un mini-PC o NAS con dos puertos GbE que quieres unir para tener 2 Gbps hacia tu switch gestionado, o para que la caída de un cable no apague el servidor. En producción, casi siempre se combina con trunks VLAN y un switch L2/L3 que soporte LACP.

---

Los 7 modos de bonding explicados

El kernel soporta siete políticas de distribución de tráfico, numeradas del 0 al 6. Cada una define cómo se reparten los paquetes entre los slaves y qué pasa cuando uno falla.

Modo	Nombre	Política	Requiere config en switch
0	balance-rr	Round-robin, paquete por paquete	Sí, EtherChannel estático (no LACP)
1	active-backup	Solo un slave activo a la vez	No, funciona en cualquier switch
2	balance-xor	XOR de MAC origen/destino	Sí, EtherChannel estático
3	broadcast	Envía por todos los slaves	Sí, EtherChannel estático
4	802.3ad (LACP)	LACP negociado dinámicamente	Sí, LACP en el switch
5	balance-tlb	Adaptive transmit load balancing	No
6	balance-alb	Adaptive load balancing (TX+RX)	No

La política xmit_hash_policy solo aplica a los modos 2 y 4. Los valores más comunes son layer2 (XOR de MACs), layer2+3 (MAC + IP), layer3+4 (IP + puerto). Para servidores con tráfico de muchos clientes distintos, layer3+4 distribuye mejor.

Modo 1: el que vas a usar el 80% del tiempo

active-backup es el caballo de batalla. Solo un slave transporta tráfico a la vez; los demás están en standby. Si el slave activo falla, otro toma el relevo en milisegundos. La gran ventaja es que no necesitas tocar el switch: cualquier puerto Ethernet sirve. La desventaja es que no sumas throughput: si tienes dos enlaces de 1 Gbps, en modo 1 solo usas 1 Gbps.

Para homelab, racks chicos, y servidores donde la redundancia importa más que el ancho de banda, este es el modo. Empieza acá si tienes dudas.

Modo 4 (LACP): cuando quieres throughput agregado

802.3ad con LACP es el estándar IEEE para link aggregation. Tanto el servidor como el switch negocian los slaves que forman parte del grupo. Si configuras xmit_hash_policy=layer3+4, el tráfico a destinos distintos (o incluso al mismo destino por puertos distintos) se balancea entre los enlaces. Importante: un solo flujo TCP entre dos IPs siempre va por el mismo slave — no se duplica el ancho de banda para una conexión individual, solo se suman flujos distintos.

Para que LACP funcione, el switch tiene que tener un LAG (Link Aggregation Group) configurado con LACP en los puertos que conectan al servidor. En un Cisco sería channel-group X mode active, en un MikroTik /interface bonding/slaves, en un OPNsense el equivalente es LAGG con LACP. Sin esa config en el switch, el bond en modo 4 simplemente no levanta.

Modos 5 y 6: balance sin tocar el switch

balance-tlb (modo 5) balancea el tráfico de salida según la carga de cada slave. balance-alb (modo 6) agrega balance de entrada mediante ARP negotiation. Ninguno requiere config en el switch, lo cual los hace atractivos en entornos donde no controlás el switch.

El problema: balance-alb hace ARP spoofing periódico para que el switch aprenda la MAC del slave activo por destino. Eso puede romper capturas de tráfico, monitoring y reglas de firewall que asumen una MAC fija. balance-tlb es más limpio pero solo balancea TX. En 2026, si puedes configurar LACP en el switch, preferí modo 4 sobre 5 o 6.

Modos 0, 2 y 3: legacy, evitalos

balance-rr (modo 0) reparte paquete por paquete entre slaves. Suena bien en teoría pero en la práctica rompe el orden de entrega: si un paquete IP llega antes que el anterior al destino, el receptor lo descarta y pide retransmisión. Eso degrada el rendimiento más de lo que ayuda. Lo mismo con broadcast (modo 3): envía cada paquete por todos los slaves, lo cual duplica tráfico.

balance-xor (modo 2) está un poco mejor — usa XOR de MAC para mantener el orden — pero requiere EtherChannel en el switch y no da mejores resultados que LACP. Usalo solo si tu switch no soporta 802.3ad.

---

Requisitos del switch

Antes de tocar el servidor, asegurate de que el switch está del lado correcto de la negociación:

• Modo 1 (active-backup): cero config en el switch. Cada NIC se conecta a un puerto del mismo switch (o de switches distintos, si quieres redundancia de uplink).
• Modos 0, 2, 3: el switch necesita un EtherChannel estático en los puertos del servidor. No negocia; tú le dices qué puertos son parte del grupo.
• Modo 4 (LACP): el switch necesita un LAG con LACP en modo active o passive. Si ambos lados están en passive, no hay acuerdo.
• Modos 5 y 6: sin requisitos.

Para verificar la negociación LACP desde el servidor, leé /proc/net/bonding/bond0 una vez configurado. Si ves MII Status: up y Aggregator ID: 1 en cada slave, hay acuerdo entre el servidor y el switch. Si un slave dice down o tiene un aggregator ID distinto, hay desalineación entre el servidor y el switch.

---

Configuración con nmcli (RHEL, Fedora, AlmaLinux, Ubuntu con NetworkManager)

Si tu distro trae NetworkManager (la mayoría de las desktop y muchas server modernas), nmcli es la forma más limpia. Asumamos que tenemos eno1 y eno2 libres y queremos un bond en modo active-backup:

Paso 1. Borrar la config existente de las interfaces físicas, si tienen alguna:

sudo nmcli connection delete eno1 2>/dev/null
sudo nmcli connection delete eno2 2>/dev/null
sudo nmcli connection delete bond0 2>/dev/null

Paso 2. Crear la interfaz bond:

sudo nmcli connection add type bond 
    ifname bond0 mode active-backup 
    miimon 100 primary eno1 
    ipv4.method manual ipv4.addresses 192.168.1.10/24 
    ipv4.gateway 192.168.1.1 ipv4.dns 1.1.1.1

miimon 100 chequea el estado del enlace cada 100 ms — un buen balance entre detección rápida (10 ms es muy agresivo, 1000 ms es muy lento). primary eno1 hace que ese slave sea el preferido cuando hay varios activos; en active-backup asegura que tras un failover, cuando el original vuelva, retome la posición.

Paso 3. Enslavar las interfaces físicas al bond:

sudo nmcli connection add type bond-slave 
    ifname eno1 master bond0
sudo nmcli connection add type bond-slave 
    ifname eno2 master bond0

Paso 4. Levantar todo:

sudo nmcli connection up bond-slave-eno1
sudo nmcli connection up bond-slave-eno2
sudo nmcli connection up bond0

Para LACP en lugar de active-backup, reemplazá mode active-backup por mode 802.3ad y agrega lacp_rate fast si quieres LACPDU cada segundo (el default es cada 30, que es suficiente pero lento para diagnosticar).

---

Configuración con /etc/network/interfaces (Debian clásica)

En Debian sin NetworkManager (la instalación server por defecto), editas /etc/network/interfaces directamente. El módulo bonding necesita estar cargado y configurado en /etc/modprobe.d/:

# /etc/modprobe.d/bonding.conf
alias bond0 bonding
options bonding mode=1 miimon=100 primary=eno1

Después, en /etc/network/interfaces:

auto eno1
iface eno1 inet manual
    bond-master bond0
auto eno2
iface eno2 inet manual
    bond-master bond0
auto bond0
iface bond0 inet static
    address 192.168.1.10/24
    gateway 192.168.1.1
    dns-nameservers 1.1.1.1
    bond-mode active-backup
    bond-miimon 100
    bond-primary eno1

reinicias networking (no toda la red, solo el servicio):

sudo systemctl restart networking

Si te quedás sin red tras el restart, es porque el /etc/network/interfaces tiene un error y el servicio no levantó la interfaz nueva. Conectáte por IPMI, consola serie o KVM para recuperar.

---

Configuración con systemd-networkd

En Arch, Fedora Server minimal, y muchas distros modernas, systemd-networkd reemplaza a NetworkManager. La configuración es declarativa en /etc/systemd/network/:

10-bond0.netdev — definición del dispositivo bond:

[NetDev]
Name=bond0
Kind=bond
[Bond]
Mode=active-backup
Primary=eno1
MIIMonitorSec=100ms

20-bond0.network — config de red para el bond:

[Match]
Name=bond0
[Network]
Address=192.168.1.10/24
Gateway=192.168.1.1
DNS=1.1.1.1

30-eno1.network y 30-eno2.network — enslave cada NIC al bond:

[Match]
Name=eno1
[Network]
Bond=bond0

Y el archivo equivalente para eno2. reinicias y verificas:

sudo systemctl restart systemd-networkd
networkctl status bond0
networkctl status eno1 eno2

---

Verificación: ¿realmente está funcionando?

Configurar y olvidarse es la peor combinación. Estos son los chequeos que tienes que correr cada vez que tocas bonding.

1. La interfaz bond existe

ip link show bond0

Deberías ver algo como:

5: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT
    link/ether aa:bb:cc:dd:ee:ff brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.10/24 brd 192.168.1.255 scope global bond0

Si state dice DOWN, ningún slave está activo. revisa cables.

2. El estado interno del bonding

cat /proc/net/bonding/bond0

Este archivo es la fuente de verdad. Te dice el modo activo, el slave actualmente en uso, el estado MII de cada uno, y (en modo 4) el aggregator ID. Ejemplo de un bond LACP saludable:

Ethernet Channel Bonding Driver: v6.1.0
Bonding Mode: IEEE 802.3ad Dynamic link aggregation
Transmit Hash Policy: layer3+4 (1)
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0
Slave Interface: eno1
MII Status: up
Speed: 10000 Mbps
Duplex: full
Link Failure Count: 0
Aggregator ID: 1
Actor Churn State: none
Partner Churn State: none
Slave Interface: eno2
MII Status: up
Speed: 10000 Mbps
Duplex: full
Link Failure Count: 0
Aggregator ID: 1

Si dos slaves tienen distinto Aggregator ID, el switch los está tratando como grupos separados — falla LACP por desincronización.

3. Probar el failover

El test que casi nadie hace: desenchufar un cable y ver que el servidor sigue respondiendo. En un entorno de mantenimiento puedes bajar el slave manualmente:

sudo ip link set eno1 down
ping -c 3 192.168.1.1
sudo ip link set eno1 up

Si ping se corta más de un segundo, tienes un problema. Causas comunes: miimon muy alto (100 ms debería ser suficiente), o el switch tiene spanning tree bloqueando el puerto porque lo ve como un cambio de topología.

4. Medir el ancho de banda real

Para ver si LACP realmente suma throughput, corre iperf3 con múltiples flujos paralelos entre dos puntos:

# En el servidor con el bond
iperf3 -s
# En otro host, múltiples flujos paralelos
iperf3 -c 192.168.1.10 -P 4 -t 30

Con xmit_hash_policy=layer3+4 y dos enlaces de 10 Gbps, deberías ver ~20 Gbps agregados si los destinos son variados. Un solo flujo TCP siempre se queda en ~10 Gbps — eso es expected, no es bug.

---

Troubleshooting: los 5 problemas más comunes

El slave aparece como “down” en /proc/net/bonding

El enlace físico está caído. Causas en orden de frecuencia:

• Cable suelto o dañado (prueba con otro cable).
• Puerto del switch apagado o en VLAN equivocada.
• NIC deshabilitada en BIOS o por el driver (revisa lshw -C network y dmesg | grep eno).
• miimon demasiado alto combinado con un driver que no actualiza el estado del enlace rápido.

LACP no levanta en absoluto

Si en modo 4 ambos slaves están up pero con Aggregator ID: 0, no hay acuerdo LACP con el switch. chequea:

• El switch tiene LACP configurado en los puertos correctos (no EtherChannel estático).
• Las velocidades y dúplex coinciden (auto-negotiation a veces falla en cables viejos).
• lacp_rate está en slow (default, 30 segundos) o fast (1 segundo). Si esperas a que negocie solo, dale 35 segundos antes de declarar fallo.
• El switch no está limitando el LAG a un subset de puertos por VLAN.

Failover tarda más de 5 segundos

Típicamente es spanning tree. Cuando un slave cae, el switch ve el cambio de topología y recalcula STP, lo cual puede tomar 15-30 segundos en default. Soluciones:

• Activar portfast (Cisco) o edge (otros) en los puertos del servidor.
• Bajar miimon a 50 ms para detectar el fallo más rápido en el lado del servidor.
• Usar STP RSTP en lugar del STP clásico.

Bond sube pero no hay ping

Si la interfaz tiene IP pero no responde, suele ser: el switch no aprendió la MAC nueva del bond (reseteo de MAC bridge table), o el gateway está en otra VLAN/subred. verifica:

ip route show default
arp -n
sudo tcpdump -i bond0 -n

MAC address cambia tras un failover

Por default, en modo 1 el bond MAC es la del primer slave agregado. Si usas fail_over_mac=active, la MAC del bond cambia al slave activo en cada failover, lo cual obliga a refrescar tablas ARP de todos los peers. En la mayoría de los casos eso es transparente (gratuitous ARP), pero algunos switches viejos no lo procesan bien. Si tienes ese problema, agrega a /etc/modprobe.d/bonding.conf:

options bonding mode=1 miimon=100 fail_over_mac=none

---

Bonding vs Teaming: ¿importa la diferencia?

Red Hat deprecated teamd (NetworkManager teaming) en RHEL 9 a favor de bonding. La razón oficial: el kernel bonding está mantenido upstream, tiene mejor performance en tests de referencia, y la comunidad de drivers lo soporta de forma nativa. teamd sigue existiendo en Fedora y RHEL 8, pero no le están agregando features nuevas.

Si arrancás un servidor hoy, usa bonding. Si tienes un sistema legacy con teamd configurado, no hay urgencia en migrar — la API de NetworkManager para ambos es similar. Lo único que cambia es el JSON de config: "link-aggregation": "mode": "bond"` vs "team".

---

Cuándo NO usar bonding

• Si solo tienes una NIC: bonding necesita mínimo dos interfaces físicas. Si tu server tiene una sola, compra un adaptador USB-Ethernet barato antes de complicarte.
• Si tu switch no es gestionado y quieres LACP: sin LACP en el switch, modo 4 no funciona. O cambiás el switch, o usas modo 1/5/6.
• Si esperas duplicar ancho de banda para un solo flujo: bonding agrega throughput entre flujos, no dentro de un flujo TCP. Para duplicar un único socket necesitas algo más caro (MPTCP, jumbo frames, o un upgrade de NIC).
• Si usas contenedores con MACs random: balance-alb y ciertos escenarios con bridges Open vSwitch se pelean con MAC randomization. Para Kubernetes con CNI complejo, preferí un bond de nivel físico y deja que el CNI maneje el resto.

---

Resumen y decisión rápida

Si quieres copiar-pegar una decisión sin leer todo el artículo: modo 1 active-backup si solo te importa redundancia, modo 4 LACP si quieres throughput y tienes un switch gestionado. Cargá el módulo bonding, declaralo en tu config favorita (nmcli, /etc/network/interfaces o systemd-networkd), verifica con /proc/net/bonding/bond0, y prueba el failover desenchufando un cable.

Bonding es una de esas configuraciones que se hace una vez y se olvida. Si la haces bien la primera vez — modo correcto, miimon razonable, switch configurado para LACP si aplica — tu servidor va a tolerar caídas de cable sin que te enteres. Si la haces mal, vas a descubrirlo el peor día posible.

---

Preguntas frecuentes

¿Por qué Guía Definitiva para Sysadmins: Configuración de Bonding de Interfaces de Red en Linux es relevante para sysadmins Linux?

Forma parte del flujo diario de administración. Los conceptos explicados se aplican directamente a servidores en producción y resuelven problemas reales que enfrentan sysadmins hispanohablantes.

¿Qué necesito para empezar con Guía Definitiva para Sysadmins: Configuración?

Distribución Linux actualizada (Debian, Ubuntu, RHEL, Fedora o Arch), acceso root, y conexión a internet. Para producción: entorno de staging separado antes de aplicar cambios.

¿Cuáles son los errores más comunes con Guía Definitiva para Sysadmins: Configuración?

Los tres más frecuentes: (1) saltar la lectura de logs, (2) aplicar cambios directos en producción sin probar, (3) olvidar permisos y ownership. La documentación y un plan de rollback siempre.

¿Cuándo usar Guía Definitiva para Sysadmins: Configuración y cuándo una alternativa?

Esta solución es ideal para el caso descrito. Alternativas como Docker, Ansible o configuración manual pueden ser mejores según contexto: portabilidad, escala y reproducibilidad son los factores clave.

¿Cómo migro desde una configuración previa a Guía Definitiva para Sysadmins: Configuración?

Documentar el estado actual, probar la nueva configuración en staging, validar funcionalmente, y aplicar en producción con rollback plan listo. Los posts de SoyLinux incluyen troubleshooting para los problemas más comunes.

Lee también

• Guía Fedora 44: Novedades, Instalación y Upgrade para Sysadmins Linux
• Configura VLANs en Linux con nmcli: Guía paso a paso para sysadmins
• Protege tu SSH: Guía esencial para configurar Fail2ban en Linux
• Guía Definitiva: Configura Kubernetes con kubeadm en Ubuntu para Sysadmins Linux
• Configura Prometheus y Grafana: Guía DevOps para SysAdmins Linux