Este artículo explicará qué es tráfico de broadcast y por qué es importante gestionarlo en su red administrada por UniFi.

El tráfico de broadcast es un tema de importancia crítica para los administradores de red, especialmente en redes más grandes. Sin gestionar el tráfico de broadcast y multicast, tarde o temprano la mayoría de las redes probablemente sufrirán las consecuencias que pueden ser perjudiciales para la salud de la red.

Con UniFi, los administradores tienen una serie de métodos para controlar el tráfico de broadcast/multicast y tomar medidas para evitar los problemas de red. En este artículo, explicaremos por qué el tráfico de broadcast/multicast es una consideración importante para los administradores de red y sugerimos algunos métodos para administrar este tráfico.

A continuación se definirán las tres formas diferentes y fundamentales de comunicación en una red: unicast, broadcast y multicast.

Unicast: es el método más común utilizado para transmisiones de red. Unicast implica un dispositivo que envía información a otra dirección de red única. Este es el método más utilizado en las redes cuando los usuarios navegan por Internet o descargan archivos de un servidor de archivos.

Broadcast: implica enviar un paquete único en una red a cada destinatario posible en la red. Este método tiene sus propias ventajas/desventajas sobre unicast y es muy eficiente. Sin embargo, solo puede extenderse hasta el dominio de broadcast (difusión), que generalmente está definido por subred. Los usos comunes de las transmisiones de difusión incluyen descubrimiento de dispositivos UniFi, solicitudes ARP (Address Resolution Protocol), DHCP, etc.

Multicast: en una especie de mezcla entre broadcast/unicast. Con multicast, un dispositivo envía datos solo a los sistemas que están configurados para recibir estos datos, pero a diferencia de unicast, puede enviarlos a múltiples dispositivos. Esto significa que es más eficiente que unicast y consume menos recursos que broadcast. Esto ocurre más comúnmente en redes locales. Un ejemplo de una función común que usa transmisiones multicast es la transmisión de medios como una transmisión en vivo de un evento deportivo.

Como la comunicación unicast es la más común y esencial en la mayoría de las redes y la menos intensiva de las tres, generalmente se deben tomar precauciones especiales para garantizar que las solicitudes de broadcast/multicast no consuman tantos recursos de red que tengan un impacto adverso en el rendimiento de la red.

Es probable que la mayoría de nosotros haya estado en una red cuando alguien conectó un router o un teléfono IP de manera incorrecta y, básicamente, eliminó la red. La causa de estas interrupciones de red suele ser el tráfico de broadcast/multicast. Cuando un router se conecta incorrectamente a la red local y comienza a emitir solicitudes ARP en un bucle, esto consume una gran cantidad de ancho de banda que no permite el funcionamiento normal de la red. Esto es lo que llamamos una tormenta de broadcast.

Si bien muchas redes experimentarán esto de vez en cuando, las consecuencias menos obvias del tráfico no gestionado de broadcast/multicast a menudo pasan desapercibidas a la vez que impactan severamente en la red. En tales casos, los paquetes descartados, los problemas de conectividad intermitente con AP y la velocidad de red más lenta pueden distraer a los administradores.

Esto es como se ven 400 paquetes/segundo de tráfico de broadcast en una red WLAN con 5 AP:

Mientras que 393 Kbps no es una cantidad particularmente grande de datos, cuando se envía a través de la transmisión puede consumir el 80% del tiempo de uso.Esto lleva aproximadamente la misma cantidad de tiempo de aire que intentar enviar 639 Mbps (500 paquetes/segundo * 123 bytes * 8bytes/bit * 1300 frames unicast/multicast) a través del AP a la velocidad PHY completa.

En el ejemplo anterior, es probable que tanto AP1 como AP4 experimenten problemas de conectividad intermitente y paquetes descartados, lo que afectará adversamente aún más el rendimiento de otros AP. Estas condiciones resultarían en AP con conectividad intermitente con un máximo de 17 Mbps de rendimiento real del usuario (datos unicast). Esto limitaría drásticamente el número de usuarios que podrían conectarse a cada AP y hacer que la red inalámbrica se vuelva particularmente lenta.

A medida que aumentan las transmisiones de broadcast, esto continuará reduciendo la función de red con fallas en cascada.

Por estas razones, es fundamental administrar el tráfico de broadcast/multicast. En la siguiente gráfica se puede ver lo beneficioso que puede ser a través de otro ejemplo:

Como se puede ver, con un control adecuado del tráfico de broadcast/multicast, los mismos AP pueden manejar más del cuádruple del rendimiento del usuario sin experimentar ninguna conectividad intermitente. Esto significa que la misma cantidad de usuarios tendrá cuatro veces la cantidad de rendimiento o, para el mismo rendimiento, el sistema podrá administrar cuatro veces más usuarios.

En la siguiente sección, explicaremos cómo se puede administrar este tráfico.

Dependiendo de las herramientas que tenga disponibles en su red, existen varias maneras de administrar el tráfico de broadcast/multicast. Con los switches/hardware UniFi, el método actualmente recomendado es usar Port Isolation (aislamiento de puertos). Este método asegura que los datos de broadcast/multicast se mantengan al mínimo, al tiempo que permite servicios críticos que dependen de las transmisiones de broadcast/multicast. A continuación se muestra un resumen de cómo se vería esto:

Aquí se explica cómo configurar esto como se muestra en el ejemplo anterior en el UniFi Controller:

Es importante tener en cuenta que la característica Broadcast Blocking LAN-WLAN no bloquea las estaciones para que no envíen frames de broadcast al AP para que los reenvíe a la red cableada. Sin embargo, si bloquea los frames de broadcast destinados a la interfaz athX y evita que se transmitan.

Los frames se descartan a un nivel de controlador inalámbrico. Por lo tanto, si ejecuta un tcpdump en la interfaz athX del AP en sí, aparecerá el tráfico que terminará bloqueado más tarde. El puente a Ethernet/VLAN reenvía todo a la interfaz athX, que es lo que tcpdump retoma, ignorando por completo los frames que el controlador inalámbrico descartará después.

Esta es la razón por la cual la verificación del bloqueo tcpdump no funcionará. Sin embargo, podrá observar, al escuchar en su interfaz inalámbrica, que una vez que esta característica esté habilitada, ningún equipo conectado a ese AP recibirá tráfico de broadcast, aunque todavía podría ver ese tráfico cuando se ejecuta tcpdump -i athXen el AP.