INTRODUCCIÓN
Una práctica muy habitual en redes corporativas consiste en la aplicación de enlaces redundantes con el fin de mejorar el servicio y rendimiento de estas. Sin embargo, dicha redundancia puede generar problemas, traducidos normalmente en bucles de capa 2. Este hecho, también denominado tormenta de broadcast, se produce cuando la misma trama recorre los mismos enlaces de manera infinita, pero ¿cuáles son las consecuencias reales ante tal situación? Se podrían identificar las siguientes:
Las tramas que hayan entrado en bucle lo
recorrerán de manera infinita, sin ser descartadas nunca por los switchs. Ello
es debido a que no disponen del campo TTL, el cual es utilizado en capa 3 para
eliminar paquetes que superen un determinado número de saltos. Su ausencia en
capa 2 conlleva que no exista un control sobre la vida o recorrido de las
tramas, por lo tanto, serán siempre procesadas y reenviadas. A consecuencia de
ello, el ancho de banda de los enlaces se verá afectado considerablemente,
hasta tal punto que la red quedará inutilizable. La única manera de detenerlo
es desconectando físicamente alguno de los enlaces intervinientes o apagando y
encendiendo administrativamente la interfaz implicada con los comandos shutdown
y no shutdown.
La tabla de MACs de los switchs que forman parte del bucle estarán continuamente actualizándose, dando como resultado registros incorrectos y con ello reenvíos de tramas a través de interfaces erróneas.
Los switchs que intervienen en el bucle tienen que procesar todas las tramas que lo atraviesan de manera continua e infinita, lo que genera una bajada de rendimiento tanto a nivel de hardware como de software (IOS).
Las tramas que atraviesan el bucle también son recibidas por dispositivos finales. Estos las aceptan y procesan siempre, hecho que genera una disminución de su ancho de banda y rendimiento.
Un ejemplo de tormenta de broadcast podría ser el siguiente:
Paso 1: Un PC de la Red A envía una trama al SwitchA. Este, como se trata de un broadcast, la reenvía a través de todas sus interfaces excepto por la que fue recibida, lo que incluye los enlaces hacia el SwitchB y SwitchC.
Paso 2: La trama es recibida por los SwitchsB y C, la procesan, y al ser un broadcast actúan exactamente igual, reenviándola por todas las interfaces excepto por la cual fue recibida, lo que incluye el enlace entre ambos y sus respectivas redes.
Paso 3: Tanto B como C han vuelto a recibir un broadcast, procediendo ambos de la misma manera que anteriormente.
Llegados a este punto, los pasos 1, 2 y 3 se repetirán de manera infinita. Si no se soluciona el problema, el ancho de banda disponible en la red, la capacidad de procesamiento de los switchs y el rendimiento de los hosts disminuirán considerablemente.
Se ha generado un bucle de capa 2 en una topología tan sencilla como la recién mostrada, compuesta tan solo por 3 dispositivos que hacen uso de enlaces redundantes. Imagina un entorno corporativo, con decenas o cientos de Switchs conectados entre sí, el problema resultaría incontrolable. Un detalle a tener en cuenta es que las tormentas de broadcast suelen originarse con los siguientes tipos de tramas:
- Broadcast: Cuando un switch recibe una trama broadcast la reenvía a través de todas sus interfaces excepto por la cual fue recibida, lo que incluye los enlaces redundantes hacia otros switchs, pudiendo crear un bucle, tal y como se analizó en el ejemplo.
- Unicast con dirección de destino desconocida: Una trama unicast es aquella cuyo destinatario es un solo dispositivo. En este caso, los switchs leen su dirección de destino, la buscan en la tabla de MACs y la reenvían únicamente por la interfaz asociada. Sin embargo, si la MAC no se encuentra registrada, la trama será reenviada a través de todas las interfaces, al igual que sucede con los broadcasts, generando también bucles de capa 2.
El término tormenta de broadcast se aplica por igual a los bucles generados por ambos tipos de tramas.
Continuando con el ejemplo anterior, para solucionar el problema se puede proceder de dos maneras, bien desconectando físicamente algún enlace que intervenga en el bucle, o bien apagando y encendiendo la interfaz administrativamente con los comandos shutdown y no shutdown.
Por ejemplo, se podría aplicar cualquiera de las dos acciones sobre el enlace entre el SwitchA y B y el bucle se detendría. Aun así, esta solución sería temporal, ya que una vez conectado el cable o habilitada la interfaz se volverán a formar tormentas de broadcast ante cualquier trama de las ya mencionadas.
Entonces, ¿cada vez que se genere un bucle se debe proceder de esta manera? Evidentemente no, resultaría imposible administrar una red de estas características. Para poner fin a este problema nace el protocolo STP (Spanning Tree Protocol - IEEE 802.1D) cuya función consiste en evitar bucles de capa 2 de manera automática mediante el bloqueo de enlaces redundantes.
Entonces, ¿cada vez que se genere un bucle se debe proceder de esta manera? Evidentemente no, resultaría imposible administrar una red de estas características. Para poner fin a este problema nace el protocolo STP (Spanning Tree Protocol - IEEE 802.1D) cuya función consiste en evitar bucles de capa 2 de manera automática mediante el bloqueo de enlaces redundantes.
En este caso se ha aplicado STP y el protocolo ha bloqueado automáticamente el enlace entre el SwitchA y C para evitar tormentas de broadcast. Con ello, la comunicación se llevaría a cabo de la siguiente manera:
Paso 1: SwitchA recibe la trama broadcast y la reenvía a través de todas sus interfaces excepto por la cual fue recibida. Como el enlace entre A y C está bloqueado por STP, solo será reenviada hacia B.
Paso 2: SwitchB recibe la trama, la procesa y reenvía por todas las interfaces excepto por la recibida, lo que incluye la red B y el enlace con C.
Paso 3: Por último, el SwitchC recibe la trama, la procesa y tan solo la reenvía hacia la red C. Ello es debido a que el enlace entre C y A está bloqueado por STP y el de C y B recibió la trama, por lo tanto, no se reenvía a través del mismo.
Gracias a ello se evita la formación de bucles de capa 2 pero por contra se inutiliza un enlace. En el caso de que el link entre A y B caiga, el protocolo activa automáticamente el de A y C, por lo que la comunicación entre las diferentes redes no se verá afectada.
En resumen, STP es un protocolo de capa 2 utilizado para evitar tormentas de broadcast mediante el bloqueo de enlaces redundantes.
