La Link-Aggregation (LACP) es un mecanismo básico para alcanzar redundancia y rendimiento agregado. La palabra clave principal Link-Aggregation (LACP) se coloca deliberadamente al comienzo: LACP agrupa varios enlaces Ethernet físicos en una conexión lógica (LAG, Link Aggregation Group) y negocia esto mediante tramas LACPDU. En la práctica, los problemas provienen menos del protocolo en sí que de configuraciones accesorias inconsistentes: etiquetado VLAN, MTU, hashing, temporizadores LACP, configuraciones Multi‑Chassis (MLAG/vPC) o protección contra bucles. Esta guía presenta una secuencia de comprobación compacta, patrones de fallo típicos, pruebas concretas y una estrategia pragmática de retroceso para el entorno productivo.
Qué negocia LACP — y qué debe aclarar por separado
LACP (IEEE 802.3ad / 802.1AX) garantiza que ambas partes reconozcan los puertos miembros como parte de una agregación y acuerden qué enlaces físicos estarán activos. LACP regula la asignación de miembros, pero no el etiquetado VLAN, la MTU ni las decisiones de reenvío (hashing). Esta separación es esencial: un LAG puede estar formalmente «activo» mientras que ciertos VLAN, transferencias grandes o sesiones de firewall fallen.
Decisiones antes de la configuración
Topología: Single‑Chassis vs. Multi‑Chassis
Un LAG Single‑Chassis termina en un único switch/stack. Un LAG Multi‑Chassis (MLAG/vPC) reparte miembros entre dos switches físicos, aumenta la disponibilidad, pero crea una dominio de fallo adicional: Peer‑Link, sincronización de estado y protección contra split‑brain. Muchos aparentes deadlocks de LACP son en realidad problemas de sincronización de MLAG.
Modo y temporizadores
Elija el modo LACP (active/passive) de forma deliberada. Active/Active suele ser más fiable en entornos heterogéneos, porque ambas partes envían LACPDUs. Configure la tasa LACP (fast/slow) en ambos extremos: valores de temporizador distintos pueden provocar re‑selecciones inesperadas.
Estrategia ante fallos: Min‑Links, fallback, degradación
Defina Min‑Links (número mínimo de miembros activos) para evitar que un único enlace opere como «banda» y transporte todo el tráfico por sí solo. Evite, en la medida de lo posible, el fallback automático a port‑channels estáticos; esto aumenta el riesgo de bucles si los extremos no están configurados de forma idéntica. Para MLAG, planifique reglas de comportamiento claras ante interrupciones del Peer‑Link.
Trampas típicas — causas prácticas
Inconsistencia VLAN/Trunk
Con mayor frecuencia LACP no falla en la negociación, sino por VLAN faltantes o ajustes diferentes de trunk/access en los puertos miembros. Síntoma: el LAG aparece en verde, pero VLANs o servicios individuales no son accesibles. Compruebe la configuración de troncal (trunk) obligatoriamente en la interfaz LAG, no en puertos individuales.
Desajuste de MTU y Jumbo Frames
La MTU es dependiente de la ruta. Si un enlace o un punto intermedio tiene una MTU menor, el camino fragmenta o descarta paquetes. Consecuencia típica: los paquetes pequeños funcionan, las transferencias grandes se interrumpen. PMTUD falla si los ICMP «Fragmentation needed» se filtran.
El hashing no se ajusta a la carga
LACP distribuye flujos mediante hashing (p. ej. campos L2/L3/L4). Un flujo «elefante» puede saturar un único miembro mientras los otros permanecen inactivos. Esto es operativo y relevante para firewalls, flujos de backup o replicación de almacenamiento.
Problemas físicos y link flapping
Transceptores defectuosos, rotura de fibra, problemas con DAC, desajustes de autonegociación o mecanismos de ahorro de energía provocan flaps y renegociaciones constantes. Aunque LACP puede permanecer en estado activo, STP, el aprendizaje MAC y el reenvío entran en fluctuación continua.
STP y protección contra bucles
STP considera una LAG correctamente formada como un puerto lógico. En caso de mismatch (p. ej. estática vs. LACP), STP puede ver y bloquear los puertos miembros individualmente —esto provoca aparentes deadlocks. Las funciones de protección contra bucles (BPDU Guard, UDLD) pueden poner puertos en err-disable y así dejar el agregado parcialmente inoperativo.
Patrones similares a deadlock y causas técnicas
Deadlock no es un estado de LACP, pero describe situaciones operativas en las que los mecanismos de control y protección se bloquean mutuamente. Cuatro patrones recurrentes:
- LAG activo, sin tráfico/deseado: VLAN/MTU/hashing o fallo de enlace unidireccional.
- Cortes periódicos: desajuste de temporizadores (fast/slow) o ritmos de flapping.
- MAC-flapping / problemas ARP: bucle, MLAG split‑brain o desajuste de Host‑Teaming.
- Miembro seleccionado, pero reenvío bloqueado: STP/Loop‑Protect o UDLD err‑disable.
Ruta de diagnóstico en el incidente — pasos rápidos y reproducibles
Proceda de forma estructurada: desde comprobaciones simples de configuración hasta pruebas Layer‑1/2.
1) Delimitar: ¿Qué está exactamente afectado?
Preguntas: ¿Solo un VLAN? ¿Solo transferencias grandes? ¿Solo un trayecto unidireccional? ¿Solo un miembro? ¿Hubo cambios recientes (firmware, cables, configuración)?
2) Verificar el estado de LACP en ambos extremos
Compare las Actor/Partner‑IDs, la lista de miembros, la Aggregator‑ID y si los puertos están en estado collecting/distributing.
# Beispiel: Linux Bonding-Status und Link-Stats
cat /proc/net/bonding/bond0
for i in eth0 eth1; do
echo "=== $i ===";
ethtool $i;
ethtool -S $i | egrep -i "err|drop|crc|discard|timeout" || true;
done
lldpcli show neighbors
3) Verificar la consistencia de VLAN/Trunk
Compruebe las etiquetas mediante captura en un puerto miembro y pruebe la alcanzabilidad por VLAN. Si faltan etiquetas o aparecen solo en miembros individuales, la configuración del switch es inconsistente.
# VLAN-Tag-Paket sichtbar machen
tcpdump -eni eth0 -c 50 vlan
# Beispiel: VLAN-Subinterface prüfen
ip -d link show bond0.100
4) Probar la MTU del trayecto
Realice pings con DF para verificar la MTU de ruta. Tenga en cuenta: el filtrado ICMP puede alterar PMTUD.
# IPv4: DF-Tests
ping -M do -s 1472 -c 3 198.51.100.10 # MTU 1500
ping -M do -s 8972 -c 3 198.51.100.10 # MTU 9000 (Jumbo)
5) Contadores de errores y errores unidireccionales
Los CRC‑Errors, correcciones FEC o Input‑Errors indican problemas en Layer‑1/2. UDLD puede detectar errores unidireccionales, pero actívelo solo si el comportamiento queda documentado en el tiempo.
6) Comprobar STP/Protección contra bucles
¿Concuerdan las vistas de STP? ¿Se trata la LAG como interfaz o ve miembros individuales en la bridge? Los eventos de BPDU Guard o los Topology Changes suelen correlacionarse con problemas de LACP.
7) MLAG/vPC: el Peer-Link como dominio de fallo independiente
Verifique la estabilidad del Peer‑Link, la VLAN‑Allow‑List en el Peer‑Link, el Keepalive‑Path y las comprobaciones de consistencia. Muchos mecanismos de protección desactivan puertos si el Peer‑Link presenta problemas.
Experimentos dirigidos en operación (refutar hipótesis rápidamente)
Desactivar enlaces miembros uno por uno
Desactive temporalmente miembros individuales para ver si el problema desaparece o se desplaza. Si es así, el trayecto o el dispositivo correspondiente a ese enlace es la causa.
Experimentos de MTU y PMTUD
Pruebe transferencias grandes con pings DF y transferencias de archivos controladas. Si faltan los mensajes de fragmentación (debido a filtros ICMP), los problemas de PMTUD solo se detectarán observando retransmisiones TCP.
Provocar/analizar MAC-Flapping de manera dirigida
Determine si los hosts usan modos de teaming incorrectos. En Linux muestra /proc/net/bonding el modo; las discrepancias entre Switch-LACP y el teaming del host son fuentes clásicas de error.
Ejemplos concretos de configuración y comandos de verificación
Los siguientes ejemplos ayudan a identificar formas de configuración típicas y a verificarlas de forma válida. Adapte la sintaxis a su proveedor y a la versión de su sistema operativo.
Cisco IOS / IOS-XE: Port-Channel con LACP
interface Port-channel10
description LAG to Firewall-Cluster
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 10,20,30
ip mtu 9000
!
interface GigabitEthernet1/0/1
switchport mode trunk
switchport trunk allowed vlan 10,20,30
channel-group 10 mode active
!
interface GigabitEthernet1/0/2
switchport mode trunk
switchport trunk allowed vlan 10,20,30
channel-group 10 mode active
Importante: los ajustes de trunk y MTU se aplican en el Port-Channel. Los miembros individuales no deben tener configuraciones de VLAN o MTU diferentes.
Linux Bonding (active-backup vs. 802.3ad)
# /etc/network/interfaces (Debian-Beispiel)
auto bond0
iface bond0 inet static
address 10.0.0.10/24
bond-mode 802.3ad
bond-miimon 100
bond-lacp-rate fast
bond-slaves eth0 eth1
mtu 9000
Tenga en cuenta: bond-lacp-rate fast corresponde al temporizador LACP rápido. Utilice la misma configuración en el switch.
Guías prácticas y resolución de problemas específicos para Firewalls
Los firewalls son especialmente críticos, porque mantienen sesiones con estado. La pérdida de un solo paquete o un camino asimétrico puede romper sesiones.
1) Comprobar estado de sesiones y del clúster
Compruebe contadores de sesiones, paquetes descartados (drops) y errores de sincronización del clúster en el firewall. En clústeres verifique errores de replicación o de heartbeat — estos suelen correlacionarse con problemas de LACP.
2) Comprobaciones de enrutamiento asimétrico
Asegúrese de que la ruta de retorno y el hashing de ingreso sean consistentes. Si falta simetría, realice trazas de paquetes (tcpdump) en ambos extremos y compare los encabezados TCP e IP.
# Beispiel: Paket-Trace an Firewall-Interface
tcpdump -ni eth0 -w /tmp/fw_eth0.pcap 'tcp and host 10.0.0.5'
# parallel auf Gegenstelle
tcpdump -ni eth1 -w /tmp/switch_eth1.pcap 'tcp and host 10.0.0.5'
3) Comprobar la política de PMTUD
Los firewalls no deben bloquear ICMP de forma general. Revise las reglas de filtrado ICMP y, si procede, active temporalmente los logs para ICMP „Fragmentation Needed“.
4) Política de hashing para servicios con estado
Para cargas de trabajo VPN, IPSec o proxy con estado, se recomienda un hash L3/L4 que tenga en cuenta puerto origen y destino. Evite el hashing puramente L2 cuando existan muchas sesiones desde el mismo rango de IP.
Runbook operativo: guía de actuación para fallos de LACP
Un runbook conciso aumenta la probabilidad de una recuperación rápida. Importante: responsabilidades claras, pasos comunicables y asegurar la telemetría.
Pasos de emergencia (versión corta)
- Confirmar la alarma y documentar las consecuencias (VLANs afectadas, servicios).
- Exportar snapshot de las configuraciones y de los logs relevantes (switch, firewall, host).
- Desactivar y observar de forma controlada un miembro tras otro (máx. 30 s entre cambios).
- Si hay indicios claros de fallo del miembro: deshabilitar el puerto y activar LAN/transceptor de reemplazo.
- Si MLAG está afectado: comprobar el Peer-Link y, si procede, aislar temporalmente el peer y establecer operación en chasis único.
Ejemplos de exportación de configuración/logs
# Switch: Konfiguration sichern (Beispiel SSH-Session)
show running-config | redirect flash:running-config-$(date +%F).txt
show logging | redirect flash:logs-$(date +%F).txt
# Firewall: Sessions und Cluster-Status
show session summary
show cluster status
Monitorización y comprobaciones preventivas
Automatice las siguientes comprobaciones para obtener alertas tempranas:
- Recuento de miembros por LAG y cambios inesperados
- Cambios de estado LACP (cambio de Partner-ID, suspendido)
- Tasa de errores PMTU y mensajes ICMP de fragmentación
- Tasa de flapping de MAC por VLAN
- Latencia del Peer-Link, pérdidas (drops) y errores de keepalive (en MLAG/vPC)
Las métricas pueden recopilarse mediante SNMP, Telemetry (gNMI/streaming) o vía syslog/collectd. Establezca líneas base y active alertas por desviaciones, no solo por umbrales.
Buenas prácticas resumidas
- Simetría de configuración: Trunk/VLAN/MTU/Speed/Auto-Neg idénticos en ambos lados.
- Sincronización de tiempos: ajuste la tasa LACP y los timeouts en ambos extremos.
- Enlaces mínimos: defina el número mínimo de enlaces y pruebe escenarios de degradación.
- MLAG: supervise Peer-Link & Keepalive como servicios independientes.
- Firewall: supervise activamente PMTUD y la salud de las sesiones; adapte el hashing para cargas de trabajo stateful.
- Documentación: defina Runbooks, copias de seguridad de configuración, escenarios de prueba y el proceso de RCA.
Conclusión
La agregación de enlaces estable se logra con consistencia: mismos parámetros de puerto, diseño uniforme de VLAN y MTU, política de hashing adecuada y, en entornos multi-chassis, un Peer-Link sano con una estrategia clara contra split‑brain. Los síntomas similares a deadlocks suelen ser consecuencia de la superposición de varios mecanismos de protección (LACP, STP, Loop‑Protection, MLAG/Keepalive). Con un orden de verificación claro, experimentos precisos (desactivar miembro, probar MTU, correlacionar eventos de flap/MAC) y una estrategia de recuperación pragmática, reduzca los tiempos de inactividad y establezca las bases para una operación fiable.
Link-Aggregation (LACP) en operación, automatización e integración de sistemas
Además de la mera configuración de red, la operación determina la fiabilidad: ¿Cómo se rastrean los cambios de LACP, cómo responde la monitorización y cómo se integra la capa de red en sus soluciones digitales empresariales y la CMDB? A menudo aquí se encuentran los mayores riesgos — no porque LACP falle, sino porque los procesos, la telemetría y las particularidades de los vendors no se comparan de forma automatizada.
Aspectos operativos clave y recomendaciones:
- Detectar config‑drift de forma automatizada: Exporte continuamente las configuraciones de LAG y puertos a un repositorio de versiones. Así se puede aplicar un rollback de forma rápida y los cambios quedan auditables.
- Documentar Vendor‑Quirks: Algoritmos de hashing basados en ASIC, CPU‑Offload, o distintos temporizadores por defecto de LACP (Cisco vs. Arista vs. Broadcom‑Silicon) conducen a comportamientos no homogéneos. Registre estas desviaciones en el inventario y verifique la compatibilidad de firmware antes de los despliegues.
- Protección del Control‑Plane: Muchos LACP‑Flaps generan alta carga de CPU en los controladores de los switches. Límites, rate‑limits para LACPDU y alertas específicas evitan la degeneración del plano de control.
- Interfaces de integración: Envíe los cambios de estado LACP a su registro/telemetría (gNMI, SNMP‑Traps, syslog). Vincule las alertas con el sistema de tickets y su inventario, de modo que los cambios de configuración y las piezas de repuesto físicas (transceptores) se asignen automáticamente.
Comprobación práctica de automatización: un bucle SSH sencillo recopila las IDs de socios LACP de varios dispositivos y muestra desviaciones. Ajuste los comandos del proveedor a su CLI.
#!/usr/bin/env bash
# hosts.txt enthält eine Zeile pro Switch
while read host; do
echo "== $host ==";
ssh admin@${host} "show lacp neighbor || show etherchannel summary" 2>/dev/null | sed -n '1,120p'
done < hosts.txt
Utilice este resultado como base para un diff automatizado frente al último snapshot de configuración persistido. Si se detecta una desviación, desencadene una prueba canaria: desactivación temporal de un miembro en una VLAN de laboratorio, comprobación automática de salud y, en caso de éxito, despliegue controlado.
Finalmente: vincule los eventos de monitorización con sus procesos operativos. Un cambio LACP no debería limitarse a generar una alerta, sino aportar automáticamente contexto (último commit de configuración, versión de firmware, clusters de firewall asignados). De ese modo reduce el MTTR y evita que los problemas de infraestructura provoquen incidencias en su software de negocio y en las soluciones de software orientadas a procesos.