Cómo protegerte frente a una tormenta broadcast

Una diferencia fundamental entre soluciones basadas en WiFi y los equipos de Albentia es cómo gestionamos el Broadcast. En este caso, tengo que decir que nuestros equipos son mucho más flexibles, pero esto también nos hace más sensibles a estos paquetes y a los problemas que pueden generarnos.

¿Qué son los paquetes de Broadcast?

Dicho de manera rápida: un paquete de broadcast es un paquete destinado a cualquier equipo en una red, o lo que es lo mismo, que se envía a todos los equipos que haya en la red.

En realidad cuando hablamos de tormentas de broadcast, podemos hablar de 3 tipos de paquetes diferentes:

Paquetes de «broadcast auténtico»: son paquetes que van dirigidos a la dirección ethernet FF:FF:FF:FF:FF:FF y (si llevan IP por encima) a la dirección IP destino 255.255.255.255. Por ejemplo, los paquetes ARP (request) son paquetes de broadcast. También paquetes de discovery de Ubnt van destinados a esta dirección.

Últimamente, me he encontrado con mucho tráfico de este tipo en redes de algunos clientes. No sé si es algún update de Ubnt, pero ahora se lían sus CPEs a intentar descubrir a sus amiguitos:

Paquetes «multicast»: en realidad no son paquetes de broadcast puro, si no que están destinados a solo un grupo de equipos en la red. La dirección MAC destino suele empezar por 01 (en realidad el bit menos significativo ha de estar a 1). El problema es que estos paquetes se tratan por los switches, normalmente, como broadcast y se envían a toda la red, así que inundan también a todos los equipos.

Paquetes «unicast» a una dirección desconocida: a veces un paquete normal, unicast, llega a un switch y va con destino a una dirección no conocida. En este caso al switch no le queda más remedio que enviar el paquete por todos sus puertos, inundando la red. Estos paquetes se comportan, por lo tanto, como paquetes de broadcast. Si tienes tus BSs actualizadas a la última versión de firmware (DragonflyM3 para BS150 y EarwigM2 para BS450), no te tienes que preocupar de estos paquetes, la propia BS se encarga de filtrarlos apropiadamente.

¿Cómo afecta el broadcast a mi BS?

Con todas las BS actualizadas y como acabamos de ver, el tráfico que nos tiene que preocupar es el de «broadcast auténtico» y el «multicast«. Cuando estos paquetes llegan a la BS, esta lo único que puede hacer con ellos es enviárselos a todos los terminales conectados.

Si el tráfico de broadcast en la red es pequeño (unos pocos kbps), no hay nada más que hacer, es normal y aquí paz y después gloria.

El problema aparece cuando el tráfico de broadcast empieza a crecer. Hemos visto redes con más de 600kbps de tráfico de broadcast sostenido en la boca ethernet de la BS. Si la BS tiene conectados 100 clientes, esto supone un despilfarro de 60Mbps. Este tráfico no será útil y solo nos degradará la capacidad de la BS para entregar tráfico interesante a los clientes.

Fíjate en la imagen anterior: tenemos un montón de tráfico (unos 200kbps) enviándose a todos los clientes. Este tráfico es broadcast, paquetes de discovery que envían CPEs Ubnt en la red como los de la captura que os puse al principio de este artículo.

¿Cómo me puedo proteger?

Limitando el tráfico de broadcast

Las BS450 actualizadas a Earwig M2 tienen una nueva función para limitar el tráfico de broadcast (y multicast) que le envía a los clientes. Para configurar el limitador hay que hacer lo siguiente:

1. En la página de «Local AA«, hacemos click en la plantilla a la que están asociados los clientes. Si tenemos más de una plantilla, tendremos que editarlas todas.

2. Esta es la página de editar una plantilla:

Y esta es la nueva opción que aparece que antes no estaba:

3. Activamos el limitador de tráfico, por ejemplo así:

Podríamos haber limitado solo el «broadcast auténtico» o solo el multicast, pero en este caso limitamos los dos tipos de tráficos a un valor máximo de 32kbps.

De esta manera lo que estamos haciendo es decirle a la BS que haga lo siguiente: que mida cuánto tráfico de broadcast está enviando a los CPEs y que todo lo que pase de 32kbps lo descarte y no lo envíe.

Este método tiene una ventaja: es súper sencillo de configurar. Pero también tiene una desventaja que hay que conocer: la descarta cualquier paquete de broadcast que supere el límite de 32kbps.

Filtrando el tráfico no deseado

Después de analizar el tráfico de broadcast que tenemos en la red, podemos tomar la decisión de filtrar aquellos paquetes que no queremos que se envíen a los clientes. Para analizar el tráfico podemos hacer uso de la herramienta tcpdump en la BS o cualquier analizador de tráfico que tengáis en la red. Si decidís usar tcpdump os recomiendo hacer lo siguiente:

1. Elegid un terminal que veáis que tiene tráfico destino que creáis que es de broadcast.

2. En la página de  «Traffic stats» fijaros cuál es su interfaz de red. Será una con el nombre wethX (como por ejemplo, weth8).

3. Por ssh como root en la BS ejecutáis este comando (Podéis usar las opciones -vv para que os dé detalles o -xx para que os muestre los bytes de los paquetes)

# tcpdump -i weth8 -vv

En la red de estos clientes que comentaba antes hicimos este análisis y descubrimos que había dos tipos de paquetes que no queríamos enviar a los clientes:

• Paquetes de discovery UDP de Ubnt: son paquetes destinados a la IP 255.255.255.255, con protocolo capa 4 tipo UDP y puerto > 2048.
• Paquetes de discovery CDPv1: son paquetes destinados a la dirección mac 01:00:0C:CC:CC:CC.

¿Cómo filtramos estos paquetes? haciendo uso del sistema de classifiers de la BS. Si tenéis un solo servicio de DL, vamos a editar ese servicio. Si hay más de un servicio de DL, editad el servicio de datos tipo «internet».

Vamos a crear 3 clasificadores:

• Clasificador 1: por defecto, simplemente damos a «Add classifier» y a «Save» y ya está.
• Clasificador 2: Order: 255; Action: discard; Layer 4 protocol: 17 (que es UDP); IP Destination adress: 255.255.255.255; mask: 255.255.255.255; Destination port range: low: 2048, high: 65535.
• Clasificador 3: Order: 255; Action: discard, Ethernet Dst Address: 01:00:0C:CC:CC:CC, mask: FF:FF:FF:FF:FF:FF.

Aquí os dejo unas capturas de estos clasificadores:

En resumen…

El tráfico de broadcast es necesario hasta que se vuelve excesivo (especialmente cuando tenemos una tormenta).

Cuando el tráfico de broadcast se vuelve excesivo, nos consume recursos de la BS que degradan el tráfico que podemos entregar a los clientes.

Para deshacernos del tráfico de broacast tenemos dos opciones: limitarlo o filtrarlo.