De golpe la red de una oficina queda inutilizable: switches con CPU al 100% y alertas de MAC flapping. ¿Qué sospechás y cómo lo prevenís?

Sospecha: un bucle de capa 2 que genera una tormenta de broadcast. Ethernet no tiene TTL, así que las tramas broadcast circulan sin fin. Las tablas MAC aprenden la misma dirección por puertos distintos (MAC flapping) y la CPU de los switches se satura. Causas típicas: alguien conecta un cable entre dos bocas de pared, un mini-switch no gestionado mal cableado, o STP deshabilitado o mal configurado.

Diagnóstico en caliente:

• Revisar los logs de MAC flapping: indican entre qué puertos salta la MAC.
• Mirar los contadores de broadcast y multicast por interfaz y seguir el tráfico hasta el puerto de acceso de origen.
• Ejecutar show spanning-tree para ver cambios de topología y quién es el root bridge.
• Apagar el puerto sospechoso para cortar el bucle y después investigar físicamente.

Prevención (diseño):

• Usar RSTP o MST y elegir el root bridge a propósito bajando la prioridad en el core, en lugar de dejarlo al azar.
• En los puertos de acceso, PortFast junto con BPDU Guard: si llega una BPDU, el puerto pasa a err-disabled.
• Root Guard en los puertos hacia switches que nunca deberían ser root.
• Loop Guard y UDLD en los uplinks de fibra, para enlaces unidireccionales.
• Storm-control para limitar broadcast y multicast por puerto.

spanning-tree mode rapid-pvst
spanning-tree vlan 10 priority 4096
interface Gi1/0/5
 spanning-tree portfast
 spanning-tree bpduguard enable
 storm-control broadcast level 1.00

Además conviene monitorear los cambios de topología (TCN) con SNMP o syslog y documentar el cableado.

Culpar a un virus o al ISP sin considerar un bucle de capa 2. Proponer deshabilitar STP para que no bloquee puertos. No mencionar BPDU Guard ni la elección deliberada del root bridge.