13 dic 2025·8 min
Spanning Tree de Radia Perlman: la columna silenciosa de Ethernet
Conoce a Radia Perlman y aprende cómo Spanning Tree Protocol evita bucles de Ethernet, permite redundancia y hizo que las redes grandes fueran estables y confiables.
Conoce a Radia Perlman y aprende cómo Spanning Tree Protocol evita bucles de Ethernet, permite redundancia y hizo que las redes grandes fueran estables y confiables.
Ethernet comenzó como una forma sencilla de conectar ordenadores en el mismo edificio. A medida que se expandió por oficinas, campus y centros de datos, las expectativas cambiaron: las redes locales dejaron de ser “algo agradable” y se convirtieron en la tubería para correo, intercambio de archivos, impresoras, teléfonos y, finalmente, flujos enteros de trabajo empresarial. Cuando esa tubería falla, todo lo que depende de ella falla también.
Los responsables de redes aprendieron además una dura lección sobre fiabilidad: si diseñas una red con una sola ruta entre dispositivos, un único cable o switch averiado puede dejar fuera de servicio una zona entera. La solución obvia es la redundancia: enlaces y switches adicionales.
En la Capa 2 de Ethernet, sin embargo, la redundancia tiene un efecto secundario peligroso: los bucles.
Radia Perlman diseñó el Protocolo Spanning Tree (STP), el mecanismo que permite a las redes Ethernet tener redundancia sin colapsar por bucles. Su contribución no fue “tuberías más grandes”: fue una forma práctica y distribuida para que los switches se coordinen, acepten una estructura de reenvío segura y se adapten automáticamente cuando cambia la topología.
STP es el tipo de sistema que solo notas cuando falta o está mal configurado. Cuando funciona, nada parece especial: el tráfico fluye, los enlaces se mantienen y la red tolera fallos. Bloquea discretamente las rutas necesarias para evitar bucles, manteniendo alternativas listas por si una ruta activa cae.
Haremos el problema tangible mostrando cómo luce un bucle Ethernet y por qué provoca tormentas y cortes. Luego explicaremos la idea central de STP: cómo mantiene la redundancia pero elimina los bucles, y en términos sencillos cómo los switches deciden qué enlaces reenvían y cuáles quedan en reserva. Al final tendrás un modelo intuitivo de por qué STP se volvió fundamental para la conmutación en Capa 2 y por qué el diseño de Perlman sigue importando, incluso con Ethernet mucho más grande que sus orígenes en oficinas.
Las primeras redes Ethernet eran a menudo pequeñas y sencillas: unas pocas máquinas en un segmento compartido o, más tarde, algunos switches (y “bridges”, el término antiguo) conectando segmentos. Si un cable se desenchufaba, la gente lo notaba, y la falla era fácil de entender.
A medida que las organizaciones añadieron más salas, pisos y edificios, la red rara vez creció según un plano limpio. Creció como un organismo vivo: un switch nuevo aquí, un cable “de emergencia” allá, una solución temporal que quedó como permanente.
Cuando la red se expande así, se añaden enlaces por razones prácticas:
Cada cambio puede parecer inofensivo por separado. Colectivamente, pueden crear múltiples rutas entre los mismos switches.
La redundancia es deseable porque mejora la disponibilidad. Si un enlace falla, el tráfico puede tomar otra ruta y los usuarios siguen trabajando.
Pero en la Capa 2 (conmutación), Ethernet no fue diseñada para “elegir” automáticamente una ruta y ignorar las otras. Los switches reenvían tramas según direcciones aprendidas y, sin un control coordinado, pueden formarse bucles.
Esa es la tensión central: más cables pueden romper accidentalmente la red. Las mismas conexiones añadidas para mayor seguridad pueden crear condiciones donde el tráfico circula sin fin, saturando enlaces y dispositivos. Spanning Tree fue creado para conservar los beneficios de la redundancia evitando estos apagones autorinfligidos a escala de red.
Un bucle de conmutación Ethernet ocurre cuando existen dos (o más) rutas activas de Capa 2 entre los mismos switches, a menudo porque alguien añadió un cable de “respaldo”, conectó ambos uplinks a la misma red o formó un anillo sin un mecanismo de control. Las tramas no tienen límite de saltos en Capa 2, por lo que pueden circular indefinidamente.
Parte del tráfico está destinado a inundar la red: broadcasts (como peticiones ARP) y tramas de “destino desconocido” (cuando un switch aún no sabe en qué puerto está una MAC). En un bucle, esa trama inundada se copia y envía alrededor del bucle, luego se copia otra vez, y así sucesivamente.
Un ejemplo simple: un PC pregunta “¿Quién tiene 10.0.0.5?” por ARP (broadcast). Con un bucle, cada switch repite el broadcast por varios puertos y las copias repetidas siguen llegando a otros switches. Muy rápido, los enlaces y las CPUs de los switches pasan la mayor parte del tiempo procesando duplicados, dejando poco espacio para tráfico real.
Los switches aprenden dónde están los dispositivos observando por qué puerto llega una dirección MAC origen. En un bucle, las tramas del mismo dispositivo pueden llegar por diferentes puertos a pocos milisegundos de diferencia. El switch sigue “cambiando de opinión” sobre dónde está esa MAC, reescribiendo su tabla constantemente. El resultado es tráfico encaminado al puerto equivocado, luego inundado, luego re-aprendido erróneamente.
Estos efectos se combinan en síntomas reconocibles: ralentizaciones repentinas a nivel de red, desconexiones intermitentes, teléfonos que cortan llamadas, Wi‑Fi que “funciona pero es inutilizable” y, a veces, una caída completa cuando los switches se saturan y dejan de responder. Un simple cable de parche accidental puede tirar más que los dos dispositivos que conecta.
Ethernet obtiene su resiliencia por tener más de una posible ruta entre switches. Si se corta un cable, el tráfico puede tomar otra ruta. El problema es que las rutas extra pueden formar accidentalmente un círculo, y las tramas Ethernet no tienen un campo “time to live” en Capa 2 para detenerlas.
El Protocolo Spanning Tree (STP) soluciona esto con un trato sencillo: mantén físicamente los enlaces redundantes, pero desactiva lógicamente algunos de ellos para que la red activa forme un árbol sin bucles.
Piensa en una ciudad que construye carreteras extra para que las ambulancias puedan llegar a todos los barrios cuando hay un cierre. Si la ciudad abre todas las carreteras sin reglas, se pueden crear rutas circulares donde los conductores dan vueltas sin fin.
STP actúa como control de tráfico:
Una parte clave del diseño de Radia Perlman es que no depende de un controlador que diga a cada switch qué hacer. Cada switch participa, intercambiando pequeños mensajes y llegando de forma independiente a la misma conclusión sobre qué enlaces deben reenviar y cuáles deben esperar en reserva.
Eso hace a STP práctico en redes reales: puedes añadir switches, quitar enlaces o sufrir fallos, y la red converge hacia un patrón de reenvío seguro.
Bien implementado, STP ofrece dos resultados que normalmente confligen:
El objetivo de Spanning Tree Protocol (STP) es mantener la redundancia de Ethernet sin permitir que el tráfico gire eternamente en un bucle. Lo hace haciendo que todos los switches acuerden un único conjunto “óptimo” de enlaces a usar en cada momento—llamado árbol de expansión (spanning tree)—y colocando los enlaces extra en estado de reserva.
STP primero elige un bridge raíz, el switch que sirve como punto de referencia para toda la red. Piénsalo como “el centro del mapa”. La raíz se determina por un valor de prioridad (configurado o por defecto) y un identificador único del switch; gana el menor.
Cada switch entonces se pregunta: “¿Cuál es mi mejor camino hacia la raíz?” STP asigna un coste de ruta a cada enlace (los enlaces más rápidos suelen tener menor coste). Cada switch suma los costes a lo largo de las rutas posibles y elige la menor como su ruta preferida hacia la raíz.
El puerto que un switch no raíz usa para alcanzar la raíz por esa mejor ruta se convierte en su puerto raíz.
En cada conexión compartida entre switches (un “segmento”), STP necesita exactamente un switch que reenvíe tráfico hacia la raíz. Ese puerto reenviador es el puerto designado para el segmento. El switch que anuncia la ruta de menor coste hacia la raíz en ese segmento obtiene el rol designado.
Los puertos que no son ni puerto raíz ni puerto designado se colocan en bloqueo (STP) o en un estado no reenviador similar (en variantes más nuevas). Bloquear no elimina el cable ni la redundancia: simplemente impide que ese puerto reenvíe tramas de usuario normales, para que no se forme un bucle. Si un enlace activo falla, STP puede desbloquear una ruta de respaldo y mantener la red conectada.
Hagamos STP concreto con una pequeña red de cuatro switches:
STP empieza eligiendo un único punto de referencia: el bridge raíz. Cada switch anuncia un identificador (bridge ID) y gana el ID más bajo.
Supongamos que S1 tiene el bridge ID más bajo. Ahora todos acuerdan: S1 es la raíz.
Cada switch no raíz elige exactamente un puerto como su puerto raíz: el puerto que proporciona la mejor ruta de vuelta a S1.
Para cada segmento, STP elige un lado como puerto designado (el que debe reenviar para ese segmento). Cualquier puerto que no sea puerto raíz ni designado pasa a bloqueo.
En este ejemplo, el enlace S3–S4 es donde se corta el bucle. Si S3 ya llega a la raíz vía S2, STP puede poner el puerto de S3 hacia S4 (o el puerto de S4 hacia S3, según criterios de desempate) en bloqueo.
Resultado: todos los cables siguen enchufados, pero solo hay una ruta activa entre dos puntos—sin bucle.
Si la ruta activa se rompe (por ejemplo S2–S3 cae), STP reevalúa. El enlace antes bloqueado S3–S4 puede pasar a reenvío, restaurando la conectividad vía S3 → S4 → S1.
Ese cambio no es instantáneo; STP necesita tiempo para converger y actualizar los estados de reenvío sin reintroducir bucles.
STP solo funciona si todos los switches de la red acuerdan las mismas reglas. Por eso los estándares importan: las redes reales suelen ser multivendor, construidas con equipos comprados durante muchos años. Sin un protocolo compartido, la función de “prevención de bucles” de una marca podría no entender la de otra, y la redundancia se transformaría en un fallo.
El Spanning Tree tradicional está definido en IEEE 802.1D. No necesitas leer la norma para beneficiarte de ella: el punto clave es que 802.1D da a los distintos vendedores un lenguaje común para elegir la raíz, calcular el coste de ruta y decidir qué puertos deben reenviar o bloquear.
Aunque posteriormente pases a variantes más nuevas (como RSTP o MSTP), las actualizaciones son posibles por la misma razón: el comportamiento está estandarizado lo suficiente como para que los dispositivos se coordinen en lugar de adivinar.
Los switches se coordinan usando tramas de control pequeñas llamadas BPDUs (Bridge Protocol Data Units). Piensa en las BPDUs como los “mensajes hello” de STP: contienen la información necesaria para que los switches construyan una vista compartida de la topología—quién creen que es la raíz, qué coste tienen hasta ella y datos de temporización.
Como las BPDUs se intercambian continuamente, STP puede reaccionar cuando algo cambia. Si un enlace falla, la conversación de BPDUs cambia también y los switches pueden reconverger y abrir un enlace previamente bloqueado.
Una complicación práctica: los vendedores suelen usar nombres diferentes para los mismos ajustes. Un parámetro como “port cost”, “edge/PortFast” o “bpdu guard” puede aparecer con etiquetas distintas o en menús diferentes. Los conceptos básicos de STP son consistentes, pero el vocabulario de la interfaz no lo es—por eso conviene traducir las funciones del proveedor a lo que 802.1D pretende lograr.
El STP clásico (IEEE 802.1D) resolvió los bucles, pero podía ser dolorosamente lento en recuperarse tras la caída de un enlace o switch. La razón es sencilla: STP era cauteloso. Los puertos no empezaban a reenviar de inmediato—pasaban por estados temporizados (blocking → listening → learning → forwarding). Con temporizadores por defecto, la reconvergencia podía tomar decenas de segundos (a menudo ~30–50 s), tiempo suficiente para que llamadas de voz se corten, aplicaciones fallen por timeout o los usuarios supongan que “la red está caída”.
Rapid Spanning Tree Protocol (RSTP, IEEE 802.1w) mantiene el objetivo—reenvío sin bucles con redundancia—pero cambia cómo los switches alcanzan el acuerdo.
En lugar de esperar largos temporizadores fijos, RSTP usa un apretón de manos más rápido entre switches para confirmar qué puertos pueden reenviar con seguridad.
En términos sencillos: RSTP sigue bloqueando las rutas correctas para prevenir bucles; simplemente deja de tratar cada cambio como el peor de los casos.
A medida que las redes crecieron, usar un único árbol para todo se volvió limitante—especialmente con muchas VLAN y topologías complejas. Multiple Spanning Tree Protocol (MSTP, IEEE 802.1s) permite crear múltiples instancias de spanning tree y mapear grupos de VLAN a cada instancia.
Eso permite:
El avance principal de STP → RSTP → MSTP es consistente: mantener redundancia, prevenir bucles y restaurar el reenvío de forma más rápida y predecible.
El beneficio menos apreciado de Spanning Tree es cómo convierte “cables y switches extra” en fiabilidad predecible. En entornos empresariales—muchos armarios, muchos switches de acceso, movimientos constantes—la redundancia en Capa 2 puede ser una bendición o una trampa. STP hace que sea más probable lo primero.
Las grandes redes rara vez fallan porque se corte un enlace; fallan porque la recuperación es desordenada. STP ayuda proporcionando una forma controlada de reaccionar cuando algo cambia:
Muchas organizaciones mantienen STP habilitado incluso si creen que su topología no tiene bucles. La razón es pragmática: la gente comete errores, la documentación queda desactualizada y aparecen caminos inesperados en Capa 2. Con STP activado, un cable de parche accidental suele provocar un puerto bloqueado en lugar de un corte en todo un edificio.
Los centros de datos modernos a menudo prefieren diseños leaf–spine en Capa 3 o tecnologías de multipath específicas para tener ancho de banda activo/activo sin depender de la convergencia clásica de STP. Aun así, STP (o variantes como RSTP/MSTP) sigue usándose ampliamente en redes de campus, segmentos de borde y como capa de compatibilidad donde no es práctico migrar todo a Capa 3.
A gran escala, el logro real de STP es tanto operativo como técnico: hace que la redundancia sea manejable por equipos corrientes, no solo por especialistas.
STP es simple en concepto—evitar bucles en Capa 2 manteniendo caminos de respaldo—pero algunos mitos persistentes llevan a que la gente lo desactive, lo configure mal o lo “optimice” hasta causar un desastre.
Es cierto que las redes modernas a menudo usan enrutamiento en Capa 3, MLAG y overlays que reducen la necesidad del STP clásico IEEE 802.1D. Pero STP (y sus formas más nuevas como RSTP/MSTP) sigue siendo una red de seguridad en cualquier lugar donde Ethernet pueda formar un bucle por accidente: switches de acceso, redes temporales en eventos, laboratorios, sucursales pequeñas y entornos donde alguien puede conectar dos puertos “solo para probar”.
Desactivar STP puede convertir un error de cableado en una tormenta de broadcast que tumbe una VLAN entera.
Un puerto bloqueado no está “muerto”. Es una ruta validada en espera. STP intercambia parte de la capacidad activa por estabilidad: si el enlace de reenvío falla, el enlace bloqueado puede convertirse en la nueva ruta sin que nadie tenga que volver a cablear. Equipos a veces desactivan STP para forzar que todos los enlaces estén activos, pero eso puede parecer eficiente hasta que el primer bucle derrite la red.
La redundancia ayuda solo cuando está diseñada. Añadir enlaces cruzados entre switches sin planificación aumenta las posibles combinaciones de bucles y hace el comportamiento de STP más difícil de predecir. El resultado puede ser rutas inesperadas, uplinks bloqueados o una reconvergencia más larga tras una falla.
Incluso con STP activado, ajustes incorrectos pueden causar daños reales:
La conclusión: STP no es solo una casilla que marcar; es un plano de control. Trátalo como tal, documenta la intención y valida cambios antes de aplicarlos ampliamente.
Los problemas de Spanning Tree suelen manifestarse como “la red está lenta” antes de que alguien identifique un problema de Capa 2. Unas comprobaciones focalizadas pueden ahorrar horas de investigar.
Cuando aparece un bucle o inestabilidad de STP, normalmente verás:
Empieza por lo fundamental:
La higiene de STP es, en su mayoría, procesal:
Si quieres una lista de comprobación más amplia para aislar problemas de red más allá de STP, consulta /blog/network-troubleshooting-basics.
STP es un gran ejemplo de “infraestructura silenciosa” y suele fallar por motivos muy humanos: intención poco clara, cableado sin documentar, configuraciones inconsistentes y resolución ad‑hoc. Una forma práctica de reducir ese riesgo es construir herramientas internas ligeras y runbooks alrededor de tus operaciones STP.
Con Koder.ai, los equipos pueden crear pequeñas aplicaciones o dashboards desde un chat: por ejemplo, una herramienta que ingesta salidas de switches, resalta el bridge raíz actual, marca puertos bloqueados inesperados o rastrea eventos de cambio de topología a lo largo del tiempo. Como Koder.ai soporta exportar código fuente y desplegar/apps con rollback y snapshots, es una forma de convertir el “conocimiento tribal” en un servicio interno mantenible en lugar de un script en el portátil de alguien.
El trabajo de Radia Perlman sobre spanning tree recuerda que parte de la infraestructura más importante no es llamativa: simplemente evita el caos. Al dar a Ethernet una forma práctica de usar enlaces redundantes sin crear bucles, STP hizo que “añadir una ruta de respaldo” fuera una opción segura por defecto en vez de un experimento arriesgado. Ese cambio permitió redes de Capa 2 más grandes y resilientes en empresas, campus y centros de datos.
STP asume que algo saldrá mal: un cable se conecta al puerto equivocado, un switch se reinicia, un enlace hace flap. En lugar de esperar que los operadores nunca fallen, construye un sistema que absorba errores y converja hacia un estado seguro. La lección va más allá de redes: trata las fallas como requisitos de primera clase.
Spanning Tree bloquea intencionadamente algunos enlaces para mantener la red estable. Esa “capacidad desperdiciada” es un intercambio a favor de un comportamiento predecible. Los buenos sistemas reservan margen—tiempo extra, comprobaciones adicionales, guardarraíles—porque evitar fallos catastróficos vale más que aprovechar el último punto porcentual de utilización.
STP funciona porque cada switch sigue las mismas reglas distribuidas e intercambia mensajes pequeños para acordar una topología sin bucles. No necesitas un operador decidiendo manualmente qué puertos desactivar en cada cambio. Moraleja: cuando muchos componentes deben cooperar, invierte en protocolos y valores por defecto que hagan que el comportamiento seguro sea el más fácil.
Si recuerdas solo unos puntos: construye redundancia, asume error humano y automatiza la “elección segura”. Esa mentalidad—más que cualquier característica individual—explica por qué Spanning Tree se convirtió en un esencial silencioso.
Si quieres más fundamentos de redes en lenguaje accesible, visita /blog.
Un bucle de Capa 2 ocurre cuando los switches tienen dos o más rutas activas entre los mismos segmentos, creando un ciclo. Como las tramas Ethernet no tienen límite de saltos en Capa 2, el tráfico inundado (broadcasts y unicasts de destino desconocido) puede circular indefinidamente y multiplicarse, saturando enlaces y la CPU de los switches.
La redundancia añade rutas alternativas, pero sin coordinación los switches pueden reenviar por todas ellas. Eso crea un bucle donde las tramas inundadas se replican una y otra vez, provocando tormentas de broadcast e inestabilidad en el aprendizaje de direcciones MAC; a menudo, una sola cable extra puede causar la caída de la red.
STP mantiene los enlaces redundantes físicamente conectados pero desactiva lógicamente algunos puertos para que la topología activa sea un árbol sin ciclos. Si una ruta activa falla, STP puede promover un puerto previamente bloqueado a estado de reenvío para restaurar la conectividad.
STP elige un puente raíz como punto de referencia para todo el dominio de Capa 2. El switch con el menor bridge ID (prioridad + identificador único) se convierte en la raíz; que la raíz sea el switch de core/distribución previsto ayuda a mantener las rutas de tráfico previsibles.
Cada switch no raíz selecciona un puerto raíz: el puerto con el menor coste de ruta total hacia la raíz. El coste se basa en la velocidad del enlace (los enlaces más rápidos suelen tener menor coste). Si hay empates, se usan identificadores para decidir de forma determinista.
En cada segmento entre switches, STP selecciona un puerto designado que reenvía tráfico hacia la raíz (es el lado que anuncia la mejor ruta a la raíz). Cualquier puerto que no sea puerto raíz ni puerto designado queda bloqueado/descartante, y así STP corta los bucles.
Significa que el puerto no reenvía tramas de usuario normales, por lo que no puede participar en un bucle. El cable sigue conectado y el puerto puede intercambiar tramas de control STP; si cambia la topología (por ejemplo, falla un enlace), ese puerto bloqueado puede promocionarse a estado de reenvío.
Las BPDUs (Bridge Protocol Data Units) son tramas de control de STP que los switches intercambian para compartir información de topología: quién creen que es la raíz, el coste de camino hacia ella y datos de temporización. Al intercambiar BPDUs continuamente, los switches detectan fallos o cambios y reconvergen hacia una topología segura sin bucles.
STP clásico (IEEE 802.1D) puede tardar decenas de segundos en reconverger porque usa temporizadores conservadores y estados de puerto secuenciales. RSTP (802.1w) acelera esto con un apretón de manos más rápido entre switches y transiciones inmediatas para ciertos puertos (por ejemplo, puertos de borde/PortFast), reduciendo el tiempo de inactividad tras fallos.
Lista práctica:
Para diagnósticos más amplios, consulta /blog/network-troubleshooting-basics.