Una tormenta de broadcast es una descripción del marco de comportamiento de las inundaciones que se produce bajo condiciones especiales en una red Ethernet. Durante una tormenta de broadcast las tramas Ethernet se encuentran atrapadas en un bucle sin fin y siguen siendo retransmitidos hasta que el conmutador de red se siente colapsado o el bucle se termina.
Cuando hablamos de tráfico de broadcast, nos referimos a un elemento esencial para el funcionamiento de los protocolos que operan en una red, y también un problema debido al consumo innecesario de los recursos y ancho de banda. Por esto es importante limitar las consecuencias de un tráfico de broadcast excesivo.
El broadcast es un riesgo permanente en nuestra red,¿porqué?
- Porque inunda la red utilizando ancho de banda innecesariamente.
- Porque insume recursos de los dispositivos que deben procesar este broadcast.
- Porque insume recursos de las terminales y servidores que reciben el broadcast y deben analizarlo.
Adicionalmente, problemas de configuración o fallos de los dispositivos o de las terminales pueden provocar la presencia de montos muy importantes de broadcast en la red que quitan recursos para el procesamiento del tráfico de datos o la operación regular de la red, bajando de modo notable su performance.
Una tormenta de difusión puede consumir suficientes recursos de red con el fin de hacer que la red no puede transportar el tráfico normal.
Por lo general la causa es un circuito de conmutación en la topología de cableado Ethernet. Como broadcast y multicast se transmiten por medio de interruptores fuera cada puerto, el conmutador o conmutadores retransmitirán repetidamente mensajes de difusión e inundar la red.
En algunos casos, una tormenta de difusión puede ser instigado a los efectos de una denegación de servicio a través de uno de los ataques de amplificación de paquetes, como el ataque pitufo o ataque Fraggle, donde pitufo envía una gran cantidad de tráfico ICMP Echo Pide a una dirección de difusión , con cada paquete de eco ICMP contiene la dirección de origen de la parodia de la máquina víctima. Cuando el paquete falso llega a la red de destino, todas las máquinas de la red responden a la dirección falsa. La solicitud de eco inicial se multiplica por el número de máquinas de la red. Esto genera una tormenta de respuestas al host víctima inmovilización de ancho de banda de red, utilizando recursos de la CPU o, posiblemente, rompiendo la víctima.
En las redes inalámbricas un paquete disociación falsificado con la fuente a la del punto de acceso inalámbrico y enviado a la dirección de difusión puede generar una disociación ataque DOS difusión.
Si se desea que funcione el BSC, debe ser posible reconocer tanto los paquetes de broadcast, como los multicas, dentro de una misma “tormenta” de paquetes, omitiendo por completo los paquetes que no están dentro de dicha tormenta.
El Broadcast Storm Control se configura para un switch de forma global, pero trabaja puerto por puerto. Éste control aparece inhabilitado por defecto. Se puede prevenir la “tormenta” de broadcast mediante un establecimiento de valores muy altos o muy bajos en el umbral del switch, descartando el tráfico excesivo de MAC. Al configurar los valores para elevar el umbral de un switch puede llegar a desactivar el puerto.
Supresión de broadcast con Cisco IOS
Los switches Cisco IOS brindan un feature que permite con facilidad limitar la porción de ancho de banda que puede ser ocupada por tráfico de broadcast en cada puerto del switch. Esta función está deshabilitada por defecto. Esta función permite adicionalmente definir el modo en que cada puerto debe manejar el tráfico de broadcast que recibe: se puede descartar el tráfico de broadcast excedente por un tiempo limitado o hasta que el tráfico de broadcast que llega disminuya.
Un ejemplo de cómo configurar esta función en un switch Catalyst 2950:
Switch(config)#interface fastethernet 0/10
Switch(config-if)#storm-control broadcast level 50
Switch(config-if)#storm-control action trap
El primer comando es el único requerido. En esa línea se define el tráfico que se desea limitar (también se puede utilizar para limitar tráfico de multicast o de unicast) y hasta qué nivel se tolera el mismo.
La segunda línea indica la acción que se desea tomar. Si la opción buscada es que el puerto sea inhabilitado completamente, el comando será: storm-control action shutdown. Si no se especifica nada, por defecto, el comando descarta el tráfico de broadcast. También se puede solicitar que envíe un aviso de SNMP a una estación de management.
REFERENCIAS
- Jesus Sanchez Patoni . (marzo 13, 2015). Broadcast Storm Control y Spanning-Tree Protocol. marzo 3, 2018, de Conocimiento Tecnologico Sitio web: http://ctecnologicou.blogspot.mx/2015/03/broadcast-storm-control-y-spanning-tree.html
- http://programoweb.com/como-evitar-las-tormentas-de-broadcast/
- http://daxnetworks.com/Technology/Techdost/TD-112305.pdf
No hay comentarios:
Publicar un comentario