Spanning Tree Protocol (STP) es el mecanismo clásico utilizado en redes Ethernet conmutadas para mantener redundancia física sin permitir loops de Capa 2. Cuando existen varios caminos entre switches, STP determina una topología lógica libre de bucles y deja los enlaces redundantes disponibles para una eventual reconvergencia.
Para entender STP no basta con memorizar estados o comandos. Es necesario comprender cuatro decisiones fundamentales:
- qué switch será el Root Bridge;
- cuál es el mejor camino de cada switch hacia ese root;
- qué puerto debe reenviar tráfico en cada segmento;
- qué puertos redundantes deben permanecer sin reenviar tráfico de usuario.
En este artículo estudiaremos el funcionamiento de STP clásico (IEEE 802.1D) y utilizaremos ejemplos Cisco para configuración, verificación y troubleshooting. Al final veremos cómo se relaciona con RSTP, que mejora significativamente la convergencia.
Si necesitas revisar primero la segmentación y los enlaces entre switches, consulta qué es una VLAN y cómo funciona un trunk 802.1Q.
¿Por qué necesitamos Spanning Tree?
La redundancia es indispensable en una red empresarial. Si dos switches están conectados por un único enlace y ese enlace falla, la comunicación entre ambos lados puede perderse.
Una solución aparentemente sencilla es instalar un segundo enlace:
El problema es que Ethernet de Capa 2 no fue diseñado para permitir indiscriminadamente caminos activos en forma de loop.
A diferencia de un paquete IP, una trama Ethernet no posee un campo TTL (Time To Live) que vaya disminuyendo en cada salto. Una trama que entra en un loop puede continuar circulando mientras el loop exista.
STP permite mantener los enlaces físicos redundantes, pero selecciona una topología lógica que evita esos bucles.
¿Qué puede provocar un loop de Capa 2?
Un loop puede producir varios síntomas simultáneamente.
Broadcast storm
Los switches reenvían broadcasts por los puertos correspondientes del dominio de broadcast. En presencia de un loop, una trama broadcast puede ser replicada una y otra vez.
El resultado puede ser una broadcast storm, consumiendo ancho de banda y recursos de los switches hasta degradar severamente la red.
Duplicación de tramas
Una misma trama puede llegar al destino por diferentes caminos y ser recibida múltiples veces.
Inestabilidad de la tabla MAC
El switch aprende una dirección MAC observando por qué puerto recibe las tramas de esa dirección.
Con un loop, la misma MAC puede aparecer alternativamente por distintos puertos. La tabla CAM/MAC puede cambiar continuamente, fenómeno que puede observarse como MAC flapping.
Por eso una topología Ethernet redundante necesita un mecanismo de prevención de loops.
¿Cómo evita STP los loops?
STP intercambia información entre switches mediante Bridge Protocol Data Units (BPDUs).
A partir de esa información, los switches construyen una topología lógica en forma de árbol:
- eligen un Root Bridge;
- cada switch no-root selecciona su mejor camino hacia el Root Bridge;
- en cada segmento se determina qué puerto debe reenviar hacia ese árbol;
- los caminos redundantes que podrían formar loops quedan fuera del forwarding normal.
El enlace físico redundante no desaparece. Puede volver a utilizarse si cambia la topología y STP realiza un nuevo cálculo.
BPDUs: la información utilizada por STP
Las BPDUs son tramas de control utilizadas por los bridges y switches para intercambiar información de Spanning Tree.
Entre los datos relevantes para el cálculo se encuentran:
- identidad del Root Bridge;
- costo acumulado hacia el root;
- identidad del switch que envía la BPDU;
- identificación del puerto;
- información relacionada con timers y cambios de topología.
En STP clásico existen Configuration BPDUs y mecanismos de Topology Change Notification (TCN) para informar cambios relevantes en la topología.
Para estudiar la elección del árbol, lo más importante es entender que STP compara la información recibida y conserva la información superior según sus criterios de selección.
Bridge ID: cómo identifica STP a cada switch
Cada bridge participa en STP utilizando un Bridge ID (BID).
Conceptualmente, la elección considera la prioridad del bridge y su identidad MAC. En implementaciones modernas que utilizan el Extended System ID, parte del campo de prioridad incorpora el identificador de VLAN o instancia correspondiente.
Por eso en switches Cisco es habitual observar prioridades como:
32768
28672
24576
8192
4096
Los valores configurables avanzan en incrementos de 4096.
Una regla fundamental es:
el Bridge ID más bajo es mejor.
Elección del Root Bridge
Al comenzar el proceso de STP, los switches intercambian BPDUs y comparan la identidad anunciada como root.
El switch con el Bridge ID más bajo termina siendo elegido como Root Bridge.
En términos prácticos:
- primero se compara la prioridad;
- si existe empate, la identidad MAC permite desempatar.
Esto significa que una prioridad menor tiene preferencia.
Por ejemplo:
| Switch | Prioridad | Resultado |
|---|---|---|
| SW1 | 4096 | Mejor candidato |
| SW2 | 8192 | Segundo |
| SW3 | 32768 | Menor preferencia |
Si todos permanecen con la misma prioridad, otro componente del BID terminará decidiendo la elección. Por eso no es una buena práctica dejar al azar cuál switch será el root de una red importante.
El Root Bridge debe ser una decisión de diseño
En una red administrada, el Root Bridge debería estar ubicado deliberadamente en un switch adecuado para el diseño de Capa 2.
En Cisco IOS/IOS XE podemos influir directamente en la elección configurando la prioridad.
Ejemplo para VLAN 10:
SW1(config)# spanning-tree vlan 10 priority 4096
También existen macros Cisco como:
SW1(config)# spanning-tree vlan 10 root primary
y para preparar otro equipo como alternativa:
SW2(config)# spanning-tree vlan 10 root secondary
Estas formas ayudan a controlar dónde quedará el root, pero siempre debemos verificar el resultado efectivo después de la configuración.
Root Port: el mejor camino hacia el Root Bridge
Después de conocer el Root Bridge, cada switch que no es root debe seleccionar un Root Port (RP).
El Root Port representa el mejor camino de ese switch hacia el Root Bridge.
Un Root Bridge no posee Root Port para su propia instancia de spanning tree.
La primera comparación importante es el Root Path Cost: el camino con menor costo acumulado hacia el root es preferido.
Ejemplo conceptual:
Cada switch analiza las BPDUs recibidas y determina cuál de sus puertos ofrece la información superior para alcanzar el root.
¿Qué ocurre si dos caminos tienen el mismo costo?
STP necesita desempates determinísticos. No basta con decir que “gana la MAC menor”.
De forma simplificada para el estudio, cuando las rutas compiten se comparan criterios sucesivos presentes en la información STP, incluyendo:
- menor Root Path Cost;
- menor Bridge ID del switch emisor;
- menor Port ID del puerto emisor;
- cuando todavía es necesario, información local del puerto permite completar el desempate.
La idea clave es que STP siempre debe llegar a una única decisión reproducible.
Designated Port: el puerto que reenvía en cada segmento
Cada segmento de Capa 2 necesita un Designated Port (DP).
El puerto designado es el que ofrece la mejor información STP hacia el Root Bridge para ese segmento.
Una consecuencia importante:
todos los puertos activos del Root Bridge hacia sus segmentos son Designated Ports.
En un enlace entre dos switches no-root, ambos comparan la información que podrían anunciar. El lado que presenta la mejor información para el segmento se convierte en Designated Port.
¿Qué ocurre con el camino redundante?
Una vez seleccionados Root Ports y Designated Ports, un puerto redundante que pudiera crear un loop no participa en el reenvío normal de tramas de usuario.
En terminología de STP clásico hablamos normalmente de un puerto en estado Blocking.
No debemos confundir esto con la terminología de RSTP. Rapid STP introduce roles como Alternate y utiliza un conjunto diferente de estados. Veremos esa diferencia más adelante.
Path Cost: cómo STP compara caminos
STP asocia un costo a los enlaces y utiliza el costo acumulado para determinar el mejor camino hacia el Root Bridge.
En general, enlaces de mayor velocidad reciben menor costo.
Una tabla clásica frecuentemente utilizada al estudiar 802.1D es:
| Velocidad | Costo STP clásico |
|---|---|
| 10 Mbps | 100 |
| 100 Mbps | 19 |
| 1 Gbps | 4 |
| 10 Gbps | 2 |
Sin embargo, existen diferentes métodos y escalas de path cost para soportar velocidades modernas. Por eso, al analizar una red real, no conviene asumir un costo únicamente a partir de una tabla memorizada.
En Cisco podemos comprobar el costo que realmente está utilizando el switch con:
SW1# show spanning-tree
y, cuando necesitamos modificar deliberadamente un camino, existen comandos para ajustar el costo de una interfaz. Esa modificación debe responder a un diseño, no utilizarse como sustituto de entender la topología.
Ejemplo conceptual completo
Consideremos tres switches:
Supongamos que todos los enlaces tienen el mismo costo.
- SW1 es el Root Bridge.
- Los puertos de SW1 hacia SW2 y SW3 son Designated Ports.
- SW2 selecciona su enlace directo hacia SW1 como Root Port.
- SW3 selecciona su enlace directo hacia SW1 como Root Port.
- En el enlace SW2–SW3 todavía debe existir un Designated Port.
- El otro extremo no puede reenviar normalmente, porque hacerlo cerraría el loop.
Así conservamos físicamente los tres enlaces, pero la topología lógica activa permanece libre de loops.
Estados de puerto en STP clásico 802.1D
Una de las confusiones más frecuentes al estudiar Spanning Tree es mezclar los estados de STP clásico con los de RSTP.
En 802.1D STP clásico, encontramos:
Blocking
El puerto no reenvía tramas de usuario ni aprende direcciones MAC para forwarding. Puede recibir y procesar información STP relevante.
Listening
El puerto participa en el proceso de STP, pero todavía no reenvía tráfico de usuario ni aprende direcciones MAC para forwarding.
Learning
El puerto continúa sin reenviar tráfico normal, pero comienza a aprender direcciones MAC.
Forwarding
El puerto puede aprender direcciones MAC y reenviar tráfico de usuario normalmente.
Disabled
El puerto no participa normalmente porque se encuentra administrativamente deshabilitado o no operativo.
El paso por estados intermedios ayuda a evitar que un puerto comience a reenviar inmediatamente y cree un loop antes de que la topología sea estable.
Timers y convergencia del STP clásico
STP clásico utiliza timers para controlar parte de su funcionamiento.
Los valores tradicionalmente asociados al Root Bridge incluyen:
- Hello Time: 2 segundos;
- Forward Delay: 15 segundos;
- Max Age: 20 segundos.
Estos valores ayudan a entender por qué la convergencia de 802.1D clásico puede resultar lenta frente a protocolos posteriores.
No es correcto resumir la convergencia diciendo que “STP siempre tarda exactamente 30 o 50 segundos”. El comportamiento depende del evento, de la topología y del mecanismo implicado.
Lo importante es entender que las transiciones temporizadas de STP clásico fueron una de las razones para el desarrollo de Rapid Spanning Tree Protocol (RSTP).
Cambios de topología
Una red no permanece estática. Un enlace puede caer, un switch puede reiniciarse o una interfaz previamente redundante puede convertirse en el único camino disponible.
STP debe reaccionar a esos cambios y recalcular la topología cuando corresponda.
En 802.1D clásico existen mecanismos de Topology Change Notification. Un switch puede informar un cambio hacia el root y la información de cambio de topología afecta el comportamiento de los bridges, incluyendo el tratamiento de información aprendida.
Para troubleshooting, un número elevado de cambios de topología puede ser una señal importante: debemos investigar qué puertos cambian de estado y por qué.
STP por VLAN en switches Cisco
En muchos entornos Cisco encontraremos implementaciones donde existe una instancia de spanning tree asociada a cada VLAN o a grupos de VLAN, dependiendo del modo utilizado.
Por eso no basta con preguntar:
“¿Cuál es el Root Bridge de este switch?”
La pregunta operacional correcta suele ser:
“¿Cuál es el Root Bridge para esta VLAN o instancia?”
Dos VLAN pueden incluso tener roots diferentes como parte de un diseño deliberado.
Para revisar una VLAN específica:
SW1# show spanning-tree vlan 10
Cómo interpretar show spanning-tree
Este es uno de los comandos más importantes para diagnosticar STP:
SW1# show spanning-tree vlan 10
Una salida típica contiene información equivalente a:
VLAN0010
Spanning tree enabled protocol ieee
Root ID Priority 4106
Address 0011.2233.4455
Cost 4
Port 25 (GigabitEthernet1/0/25)
Bridge ID Priority 32778
Address 00aa.bbcc.ddee
Los valores son ilustrativos, pero el método de lectura es el importante.
Root ID
Indica quién es el Root Bridge que este switch reconoce para la instancia.
Bridge ID
Identifica al propio switch.
Si Root ID y Bridge ID corresponden al mismo bridge, estamos observando el Root Bridge.
Cost
En un switch no-root, indica el costo del mejor camino hacia el root.
Port
Identifica el Root Port utilizado por ese switch para alcanzar el root.
Más abajo, la tabla de interfaces permite observar roles y estados de los puertos.
Verificación rápida del Root Bridge
En Cisco también podemos filtrar la salida:
SW1# show spanning-tree root
Para una inspección más completa:
SW1# show spanning-tree
Y para una interfaz específica, dependiendo de plataforma y versión:
SW1# show spanning-tree interface GigabitEthernet1/0/24 detail
La sintaxis exacta y la información disponible pueden variar entre plataformas y releases, por lo que siempre debemos validar contra el equipo que estamos administrando.
Configuración básica: definir root y root secundario
Supongamos:
- VLAN 10 = USERS
- VLAN 20 = VOICE
- SW1 debe ser el root principal;
- SW2 debe ser la alternativa.
Una forma sencilla en Cisco sería:
SW1(config)# spanning-tree vlan 10,20 root primary
En SW2:
SW2(config)# spanning-tree vlan 10,20 root secondary
Después verificamos:
SW1# show spanning-tree root
SW2# show spanning-tree root
No debemos considerar una configuración terminada únicamente porque el CLI aceptó el comando. La validación posterior forma parte del cambio.
Configuración explícita de prioridad
Cuando necesitamos control preciso, podemos establecer la prioridad directamente:
SW1(config)# spanning-tree vlan 10 priority 4096
SW1(config)# spanning-tree vlan 20 priority 4096
Y en el switch de respaldo:
SW2(config)# spanning-tree vlan 10 priority 8192
SW2(config)# spanning-tree vlan 20 priority 8192
Antes de realizar cambios de prioridad en producción debemos conocer la topología existente. Cambiar el Root Bridge puede modificar los caminos activos de Capa 2 y provocar una reconvergencia.
STP y los trunks 802.1Q
STP y los enlaces trunk 802.1Q están directamente relacionados.
Un trunk puede transportar múltiples VLAN. Dependiendo del modo de spanning tree utilizado, las decisiones pueden variar por VLAN o instancia.
Esto hace especialmente importante revisar:
- VLANs permitidas en cada trunk;
- VLAN nativa;
- estado de STP de cada VLAN relevante;
- Root Bridge esperado;
- enlaces redundantes;
- EtherChannels.
Una inconsistencia de VLAN nativa también merece atención porque la topología de Capa 2 debe ser coherente entre ambos extremos del enlace.
STP y EtherChannel
Cuando varios enlaces físicos paralelos entre dos switches deben trabajar simultáneamente, normalmente no queremos que STP trate cada enlace independiente como un camino redundante que forma un loop.
EtherChannel permite agrupar enlaces compatibles en una interfaz lógica. STP puede entonces tratar el port-channel como el enlace lógico correspondiente.
Esto no significa que EtherChannel sustituya a STP. Ambos resuelven problemas diferentes y trabajan conjuntamente.
Puedes continuar después con EtherChannel y Link Aggregation.
Troubleshooting de STP
Cuando sospechamos un problema de Spanning Tree, conviene evitar cambios impulsivos. Primero debemos reconstruir la topología lógica que STP está viendo.
1. Identificar el root real
SW1# show spanning-tree root
Pregunta:
¿El Root Bridge actual es el switch que el diseño esperaba?
Si no lo es, debemos investigar prioridades y Bridge IDs antes de modificar nada.
2. Revisar la VLAN afectada
SW1# show spanning-tree vlan 10
Comprueba:
- Root ID;
- Bridge ID;
- Root Port;
- costos;
- roles;
- estados.
3. Revisar trunks
SW1# show interfaces trunk
Una VLAN que no atraviesa el trunk esperado puede producir una topología distinta de la que imaginamos.
4. Revisar una interfaz
SW1# show spanning-tree interface GigabitEthernet1/0/24 detail
Busca información sobre el rol, estado y cambios observados en ese puerto.
5. Revisar cambios frecuentes de topología
Una cantidad anormal de topology changes puede apuntar a:
- enlaces inestables;
- puertos de usuario que suben y bajan;
- dispositivos intermedios inesperados;
- problemas físicos;
- configuración de STP que no corresponde al tipo de puerto.
El objetivo no es “desbloquear el puerto” inmediatamente. Primero debemos determinar por qué STP decidió no utilizar ese camino.
Errores frecuentes al trabajar con STP
“Un puerto bloqueado significa que está fallando”
No necesariamente. Un puerto sin forwarding puede ser exactamente la decisión correcta para eliminar un loop manteniendo redundancia.
“Todos los switches deben tener la prioridad por defecto”
Funcionará desde el punto de vista del protocolo, pero deja una decisión crítica de diseño dependiendo de los BIDs disponibles.
“La MAC más baja siempre decide todo”
No. Existen diferentes comparaciones durante la elección del root, del Root Port y del Designated Port. La MAC o el Bridge ID pueden actuar como desempate en determinados puntos, pero no sustituyen el análisis de path cost y Port ID.
“STP y RSTP tienen los mismos estados y roles”
No. Los conceptos están relacionados, pero RSTP reorganiza estados, define roles adicionales y acelera la convergencia.
“Si tengo EtherChannel ya no necesito STP”
Incorrecto. EtherChannel agrupa enlaces; STP continúa siendo necesario para proteger la topología de Capa 2 frente a loops entre caminos lógicos.
“Puedo desactivar STP para resolver un problema”
Desactivar el mecanismo de prevención de loops puede convertir un problema localizado en una interrupción grave de Capa 2. Primero debe identificarse la causa.
STP vs. RSTP
RSTP (Rapid Spanning Tree Protocol) conserva la finalidad esencial de construir una topología libre de loops, pero introduce mecanismos que permiten una convergencia mucho más rápida.
Una comparación conceptual:
| Característica | STP clásico | RSTP |
|---|---|---|
| Referencia histórica | IEEE 802.1D | IEEE 802.1w, posteriormente integrado en 802.1D |
| Convergencia | Basada fuertemente en timers | Más rápida mediante mecanismos adicionales |
| Estados operativos | Blocking, Listening, Learning, Forwarding, Disabled | Discarding, Learning, Forwarding |
| Roles principales | Root / Designated y puertos sin forwarding | Root, Designated, Alternate, Backup |
| Uso actual | Fundamental para comprender STP | Base más apropiada para muchas redes modernas |
Por eso es importante aprender primero la lógica de elección de STP y después estudiar qué cambia con Rapid STP.
El siguiente artículo profundiza precisamente en Rapid Spanning Tree Protocol (RSTP).
Buenas prácticas de diseño
En redes administradas:
- define deliberadamente el Root Bridge;
- configura un root secundario cuando el diseño lo requiera;
- documenta qué switch debe ser root por VLAN o instancia;
- evita depender accidentalmente de prioridades por defecto;
- verifica STP después de cambios en trunks, VLANs y EtherChannels;
- investiga topology changes frecuentes;
- protege los puertos de acceso con las funciones de STP apropiadas para tu plataforma y diseño;
- no modifiques costos o prioridades sin entender cómo cambiará el árbol.
Funciones como PortFast, BPDU Guard, Root Guard y Loop Guard son muy importantes, pero merecen tratamiento cuidadoso porque cada una protege contra un escenario diferente. Las abordaremos de forma específica en contenidos posteriores.
Preguntas frecuentes
¿Qué es STP?
Spanning Tree Protocol es un protocolo de Capa 2 que permite mantener redundancia física entre bridges o switches mientras construye una topología lógica libre de loops.
¿Qué switch se convierte en Root Bridge?
El switch con el Bridge ID más bajo para la instancia correspondiente.
¿Qué es un Root Port?
Es el puerto seleccionado por un switch no-root como su mejor camino hacia el Root Bridge.
¿Qué es un Designated Port?
Es el puerto seleccionado para ofrecer la mejor información STP y reenviar hacia el árbol en un segmento determinado.
¿Por qué STP bloquea un enlace?
Porque permitir forwarding simultáneo por todos los caminos redundantes podría crear un loop de Capa 2.
¿STP elimina físicamente el enlace redundante?
No. El enlace continúa existiendo y puede participar después de una reconvergencia si cambia la topología.
¿STP funciona con VLANs?
Sí. La forma exacta en que las VLANs se asocian a instancias de spanning tree depende del modo y de la implementación utilizada.
¿Cuál es la diferencia principal entre STP y RSTP?
RSTP conserva el objetivo de evitar loops pero utiliza roles, estados y mecanismos de transición que permiten una convergencia considerablemente más rápida.
Continúa estudiando Switching
STP tiene mucho más sentido cuando lo relacionamos con el resto de la topología de Capa 2:
- VLAN: segmentación lógica de una red
- Trunk 802.1Q: cómo transportar múltiples VLAN
- VLAN nativa: tráfico sin etiqueta y native VLAN mismatch
- Router-on-a-Stick: enrutamiento entre VLANs
- Rapid Spanning Tree Protocol (RSTP)
- EtherChannel y Link Aggregation
Comprender estas tecnologías como partes de un mismo diseño es más útil que estudiarlas como comandos aislados.