STP (PVST+) — Troubleshooting
Método general (de lo mínimo a lo complejo)
- ¿Quién es el root bridge de cada VLAN?
show spanning-tree vlan <n>. Un root inesperado explica muchos problemas. - ¿Qué puertos están en Blocking y por qué?
show spanning-tree blocked ports. - ¿Coinciden los costos y prioridades con tu diseño?
- ¿Hay inestabilidad (topología cambiando)? revisa cambios de topología y BPDUs.
- Si el enlace es un troncal, confirma que las VLANs pasan (Trunk & DTP - Troubleshooting).
Comando base:
Switch# show spanning-tree vlan número-de-vlan
Switch# show spanning-tree blocked ports
Caso 1 — El root bridge es un switch equivocado
Síntoma: el tráfico toma caminos subóptimos; un switch de acceso quedó como root.
Causa: ningún switch tiene prioridad ajustada, así que gana el de menor MAC (a igual prioridad). O alguien conectó un switch viejo con prioridad baja.
Diagnóstico:
Switch# show spanning-tree vlan 10 ! ¿quién es el Root ID?
Switch# show spanning-tree root
Solución: fijar como root al switch correcto.
Switch(config)# spanning-tree vlan 10 root primary
Caso 2 — Un enlace redundante no reenvía (está bloqueado, y es correcto)
Síntoma: uno de dos enlaces paralelos no pasa tráfico.
Causa: es el comportamiento normal de STP: bloquea el enlace redundante para evitar el bucle.
Diagnóstico:
Switch# show spanning-tree blocked ports
Switch# show spanning-tree vlan 10
Nota: si quieres usar ambos enlaces a la vez, no es un problema de STP: agrúpalos en un EtherChannel (EtherChannel L2 - Configuración).
Caso 3 — Quiero que un enlace concreto sea el activo y STP eligió el otro
Diagnóstico:
Switch# show spanning-tree interface fastEthernet 0/1 detail ! costo y prioridad
Causa: la elección del root port se basa en costo, luego BID vecino, luego port-priority.
Solución: bajar el costo del enlace deseado o su port-priority en el switch correspondiente.
Switch(config)# interface fastEthernet 0/1
Switch(config-if)# spanning-tree vlan 10 cost 100
Switch(config-if)# spanning-tree vlan 10 port-priority 64
Caso 4 — Bucle de capa 2 / tormenta de broadcast
Síntoma: CPU al 100%, MAC flapping, red saturada, todo lento o caído.
Causas posibles:
- STP deshabilitado o filtrado en un enlace (por ejemplo BPDU Filter mal puesto: ver Portfast, BDPU Guard & Filter, Root Guard, Loop Guard - Troubleshooting).
- Un enlace unidireccional que hace que un puerto bloqueado pase a forwarding (se mitiga con Loop Guard/UDLD).
- Un switch no gestionado o un cable en bucle.
Diagnóstico:
Switch# show spanning-tree ! ¿algún puerto que debería estar BLK está en FWD?
Switch# show mac address-table ! MAC flapping (misma MAC saltando de puerto)
Switch# show interfaces | include rate|drops
Switch# show log
Solución: identificar y aislar el enlace en bucle; reactivar STP donde falte; aplicar protecciones (BPDU Guard en accesos, Loop Guard en troncales).
Caso 5 — La topología cambia constantemente (TCN)
Síntoma: la tabla MAC se vacía seguido, hay microcortes.
Causa: un puerto de acceso sin PortFast que sube y baja (una PC que enciende/apaga) genera Topology Change Notifications.
Diagnóstico:
Switch# show spanning-tree detail | include changes|from
Solución: aplicar PortFast en los puertos de acceso para que no generen TCN (ver Portfast, BDPU Guard & Filter, Root Guard, Loop Guard - Configuración).
Caso 6 — Los costos no son los que esperas (métrica)
Síntoma: con enlaces de 10G o más, todos parecen tener costos raros o iguales.
Causa: el switch usa el método de costo corto (802.1D 1998), que no distingue bien velocidades altas.
Solución:
Switch(config)# spanning-tree pathcost method long
Recuerda el orden: quién es el root, qué está bloqueado y por qué, costos/prioridades, señales de bucle (MAC flapping, CPU), y estabilidad de la topología (TCN).