Spanning Tree de Radia Perlman: la columna silenciosa de Ethernet

Por qué Spanning Tree se volvió un esencial silencioso

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.

La idea clave de Radia Perlman

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.

Infraestructura “silenciosa” que es mejor cuando es invisible

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.

Qué aprenderás en esta guía

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.

El problema al que se enfrentaron las redes Ethernet al crecer

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.

El crecimiento orgánico crea caminos inesperados

Cuando la red se expande así, se añaden enlaces por razones prácticas:

• Alguien quiere mejor rendimiento y añade otra conexión entre switches.
• Un equipo quiere una ruta de respaldo “por si acaso” y duplica un enlace.
• Mudanzas y reformas dejan conexiones heredadas que nadie documenta.

Cada cambio puede parecer inofensivo por separado. Colectivamente, pueden crear múltiples rutas entre los mismos switches.

Por qué la redundancia ayuda y a la vez es riesgosa

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.

Cómo se ve un bucle Ethernet (y por qué es malo)

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.

Tormentas de broadcast (la falla ruidosa)

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.

Inestabilidad de la tabla MAC (la falla confusa)

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.

Lo que realmente se percibe: cortes, lentitud y flapping raro

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.

La idea central: redundancia sin bucles

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.

Una analogía de control de tráfico

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:

• Permite que existan múltiples vías.
• Cierra algunas “entradas” (puertos) para evitar rutas circulares.
• Si una vía principal se bloquea, reabre una entrada previamente cerrada para restaurar el acceso.

Automático y distribuido: sin cerebro central

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.

La promesa

Bien implementado, STP ofrece dos resultados que normalmente confligen:

• No hay bucles de Capa 2 durante la operación normal.
• Capacidad de conmutación por fallo cuando un enlace o switch muere, activando una ruta en espera.

Cómo STP decide qué reenviar y qué bloquear

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.

Paso 1: Elegir un líder (el bridge raíz)

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.

Paso 2: Medir distancia con coste de ruta

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.

Paso 3: Elegir un reenviador por cada segmento (puertos designados)

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.

Qué significa realmente “bloquear”

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.

Un recorrido sencillo de STP con una red pequeña

Hagamos STP concreto con una pequeña red de cuatro switches:

• S1, S2, S3, S4
• Los enlaces forman un cuadrado: S1–S2–S3–S4–S1
• Hay un bucle evidente: las tramas pueden circular alrededor del cuadrado para siempre.

Paso 1: Elegir el switch raíz

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.

Paso 2: Elegir la mejor ruta hacia 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.

• S2 elige su enlace hacia S1 como puerto raíz.
• S4 elige su enlace hacia S1 como puerto raíz.
• S3 tiene dos opciones iguales: alcanzar S1 vía S2 o vía S4. STP rompe empates de forma predecible (basándose en coste de ruta y IDs anunciados). Digamos que S3 elige S3 → S2 → S1.

Paso 3: Decidir qué puertos reenvían y cuál se bloquea

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.

¿Qué ocurre cuando un enlace falla?

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.

Estándares y los mensajes que intercambian los switches

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.

La referencia clásica: IEEE 802.1D

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.

BPDUs: los “mensajes hello” de STP

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.

Mismas ideas, etiquetas distintas

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.

De STP a RSTP y MSTP: qué mejoró

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”.

RSTP: misma idea, recuperación más rápida

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.

• Puertos de borde (generalmente puertos hacia dispositivos finales) pueden pasar a reenvío rápidamente porque no se espera que creen bucles.
• Transiciones rápidas ocurren cuando los switches pueden verificar una ruta segura sin el enfoque antiguo de “esperar y ver”.

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.

MSTP: escalar spanning tree para redes más grandes

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:

• distribuir el tráfico de forma más inteligente entre enlaces redundantes (sin crear bucles)
• reducir la sobrecarga administrativa frente a ejecutar un árbol por VLAN

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.

Cómo Spanning Tree soporta la resiliencia a gran escala

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.

La fiabilidad que notas día a día

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:

• Fallas de enlace: cuando se desenchufa una fibra o un switch muere, STP puede desbloquear una ruta alternativa para que los usuarios sigan trabajando.
• Ventanas de mantenimiento: los equipos pueden apagar uplinks o reemplazar equipo con menos riesgo de crear bucles accidentalmente durante trabajos temporales.
• Cambio constante: aparecen nuevos switches, cables parcheados y valores por defecto de distintos fabricantes. STP proporciona un comportamiento base que suele ser más seguro que “reenviar todo por todas partes”.

Una “red de seguridad por defecto” en muchas empresas

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.

Por qué algunos centros de datos usan diseños distintos

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.

Malentendidos comunes que causan cortes reales

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.

“STP ya está obsoleto”

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.

“Los enlaces bloqueados son ancho de banda desperdiciado”

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.

“Más redundancia siempre es mejor”

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.

Configuraciones erróneas también provocan cortes

Incluso con STP activado, ajustes incorrectos pueden causar daños reales:

• Prioridad de bridge mal configurada puede mover la raíz a un armario de acceso, forzando el tráfico por un punto débil.
• Mezclar modos de STP (o mapeos MSTP inconsistentes) en el mismo dominio de Capa 2 puede crear inestabilidad.
• Usar edge/PortFast en enlaces switch‑a‑switch puede permitir que un bucle se forme antes de que STP reaccione.

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.

Consejos prácticos: resolución de problemas y operaciones seguras

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.

Síntomas prácticos para reconocer

Cuando aparece un bucle o inestabilidad de STP, normalmente verás:

• MACs fluctuantes: la misma MAC “se mueve” entre puertos repetidamente en la tabla.
• Picos de broadcast: ARP, DHCP y otros broadcasts suben dramáticamente, a veces saturando enlaces.
• Conectividad intermitente: usuarios reportan cortes breves, llamadas VoIP fallidas o impresoras que desaparecen y reaparecen.
• CPU alta en switches: el plano de control se ve abrumado por cambios constantes de topología.

Comprobaciones básicas que suelen localizar la causa

Empieza por lo fundamental:

1. Confirma la elección del bridge raíz: verifica que el switch previsto es la raíz (no uno de acceso que haya reiniciado).
2. Revisa roles y estados de puertos: busca bloqueos/descartes inesperados en uplinks críticos o transiciones frecuentes (forwarding ↔ blocking).
3. Mira los contadores de cambios de topología: cambios repetidos suelen correlacionar con un cable suelto, un uplink mal parcheado o un switch no gestionado que crea un bucle.

Buenos hábitos operativos

La higiene de STP es, en su mayoría, procesal:

• Documenta cada cambio (qué se movió, dónde y cuándo). Los bucles suelen surgir de parches “temporales” que se quedan.
• Prueba la conmutación por fallo deliberadamente durante ventanas de mantenimiento para saber qué puertos bloquean o abren cuando cae un enlace.
• Evita bucles accidentales: ten cuidado con switches no gestionados, tomas de pared que pueden puentease y cambios de cableado de última hora.

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.

Dónde puede ayudar Koder.ai (sin reemplazar tu stack de red)

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.

Qué podemos aprender del diseño de Radia Perlman

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.

1) Diseña para el fallo, no para la perfección

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.

2) Automatiza la seguridad, incluso si cuesta algo de eficiencia

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.

3) Prefiere reglas simples y compartidas sobre coordinación manual

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.

Conclusiones prácticas

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.