Bucles en la capa 2 o como arrancarte el pelo administrando una red

Bucles de capa 2, Switching Loops o Broadcast Storm lleva por nombre este típico problema que se suele dar en algunas redes, el cual puede surgir en cualquier momento y acabar con la paz que se respira en tu dominio, pues los equipos se saturan por que deben procesar demasiados paquetes, se consume el tiempo de procesamiento para otras tareas, los Routers mueren, la red WiFi cae, los switches caen, y los usuarios pierden conexión con internet, con algún servidor remoto, etc… Una conjunción de problemas, que añadiendo el extra de que va a ser difícil encontrar el punto donde se está produciendo el bucle, crea un ambiente de muerte y desasosiego en tu empresa. Podrá ser un cable que sale del puerto 1 de un switch y entre en el puerto 2 del mismo switch, o dos cables uniendo dos Switchs, pero será difícil de ver si no tienes orden en el RAC.

Lo mejor que podrás​ hacer será bendecir tu red para que de ninguna manera un pequeño paquete esbirro del demonio pueda subir desde el inframundo de las redes y joderte todo el día, o bueno quizá solo tengas que implementar STP…

Fuera de bromas, sabemos que los switching loops suceden en la capa de enlace de datos o capa 2 del modelo OSI, ¿pero cómo y por qué ocurren?

¿CÓMO?

Ocurren cuando un host en la red envía una trama a la red con una dirección broadcast como destino, por ejemplo, una trama hacía la dirección de destino FF-FF-FF-FF-FF-FF. Lo peor es que en esta capa hay constantemente paquetes que viajan con esa dirección como destino, ya que hay diversos protocolos que hacen uso de ella, por ejemplo un cliente DHCP cuando busca un servidor DHCP.

Lógicamente existen ciertas condiciones que se deben cumplir para que ocurran, por ejemplo que los switches no tenga el protocolo STP activado, o no sean compatibles con el mismo y que además exista un enlace redundante entre dos o más switches:

Captura de pantalla 2015-10-25 a las 16.22.40

Por ejemplo, arriba podéis ver que Debian Asterisk tiene dos caminos para llegar a Debian Servers, bien desde SW3 a SW1 o desde SW3 pasando por SW2 hasta SW1, esto se llama enlaces redundantes.

Supongamos que:

  1. Debian Asterisk, envía una trama a una dirección de destino Broadcast, el paquete entra en el SW3 a través de la interfaz 1, y se reenvía por saturación a todos los puertos, excepto por el que entró, por tanto se envía por el puerto 2 y 3.
  2. Cuando llega al SW2 este reenvía el paquete por saturación a todos los puertos excepto por el que entró, por tanto lo envía por el puerto 2.
  3. Cuando llega al SW1 este reenvía el paquete por saturación a todos los puerto excepto por el que entró, por tanto lo envía por el puerto 2.
  4. Los dos switches envían el paquete de nuevo, siguiendo el mismo procedimiento anterior, y hacen que dos paquetes broadcast lleguen al SW3 y este deba reenviarlos nuevamente. En este momento empieza el calvario del administrador de la red, ya que los switches empiezan saturarse y deja de quedar tiempo de procesamiento para los nuevos paquetes, por lo que se produce una denegación de servicio en toda la red, y en todos los dispositivos.

¿POR QUÉ?

Básicamente ya lo expliqué antes: por que los switches no tiene el protocolo STP activado o no son compatibles con dicho protocolo y hay enlaces redundantes.

Además los paquetes en la capa de enlace de datos, no tienen un campo como el que existe en la capa 3: TTL (Time To Live),  el cual es un campo con un numero que se reduce cada vez que pasa a través de un router, así la duración de los paquetes es finita. En la capa 3, este numero normalmente suele ser 64, aunque depende del protocolo IP utilizado.

Cuando he estado administrando alguna red pequeña-mediana, me he podido encontrar con este tipo de problemas y la verdad, os puedo asegurar que son un quebradero de cabeza, es extremadamente difícil encontrar el punto donde se esta produciendo el bucle para poder cancelar dicho enlace.

De hecho, esto me ocurrió hace unos pocos días trabajando, cuando en un establecimiento hostelero, a un trabajador se le ocurrió conectar ‘ese cable tan raro que el suponía que no debería estar suelto‘ en uno de los switches, creando un enlace redundante. La qué lío aquel medio día, en pleno servicio del restaurante, quedará de recuerdo durante muchos días, o quizá años, pues acto seguido de realizar esa acción, toda la red empezó a caer, el software del punto de venta dejó de funcionar, ningún dispositivo conectaba con la BD, así en cuestión de segundos se formo el caos.

¿CÓMO DARSE CUENTA?

Hay que fijarse en los LEDs de los puertos de los switches y se podrá detallar como parpadean de manera exagerada, casi pareciendo estar fijos.

Si tenemos un equipo con Wireshark, podemos hacer una captura de paquetes, y veremos como en poco más de un segundo se pueden capturar 70.000(ejemplo de mis pruebas realizadas) paquetes; lógicamente Wireshark en ese momento dejará de funcionar, hasta que desconectemos el equipo de la red o pausemos la captura de paquetes, si podemos, claro. Aquí os dejo un vídeo donde podéis detallar lo comentado:

Buena noche e id con STP!

2 comentarios sobre “Bucles en la capa 2 o como arrancarte el pelo administrando una red

Responder a Hollman Rammstein Quintero Cancelar la respuesta

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Salir /  Cambiar )

Google photo

Estás comentando usando tu cuenta de Google. Salir /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Salir /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Salir /  Cambiar )

Conectando a %s