El tráfico de broadcast es un elemento necesario en el funcionamiento de los protocolos que operan en nuestra red, a la vez que un problema por el consumo innecesario de ancho de banda y recursos. Limitar las consecuencias de un excesivo tráfico de broadcast en nuestra red es una de las tareas permanentes del Administrador de la red. ¿Qué es el broadcast?
El broadcast es un componente natural de las redes TCP/IP y particularmente las redes Ethernet. Distinguimos 3 tipos básicos de comunicaciones:
- Unicast - Comunicación de una terminal origen a una terminal destino.
- Multicast - Comunicación de una terminal origen a un grupo de terminales destino.
- Broadcast - Comunicación de una terminal origen a TODAS las terminales de un dominio de broadcast (red, subred o VLAN).
Un paquete broadcast a nivel de capa de red, es un paquete cuya dirección de destino es 255.255.255.255. Si se trata de una red o subred específica el paquete puede tener como dirección destino la dirección reservada de subred correpondiente, por ejemplo: 172.16.1.255/24.
Los paquetes de broadcast se encapsulan a nivel de capa de enlace de datos con una dirección MAC reservada que es FFFF.FFFF.FFFF. Los switches LAN cuando reciben una trama con una dirección broadcast de destino inundan esa trama a todas sus bocas salvo la boca a través de la cual han recibido la trama.
Hay múltiples protocolos que automatizan operaciones de la red que utilizan en algunos de sus procesos direcciones de broadcast. Es el caso, por ejemplo, de los protocolos ARP y DHCP.
Limitando el broadcast de la red
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.
El primer recurso para limitar el impacto negativo del tráfico de broadcast es limitar el tamaño de los dominios de broadcast (el conjunto de nodos que reciben un paquete de broadcast). Para esto, las herramientas tradicionales son:
- Dividir la red en subredes.
- Implementar dispositivos de capa 3 para la comunicación entre subredes.
- Dividir la red en VLANs.
Cuando implementamos switching de capa 2, el único recurso disponible para limitar la difusión de broadcast es la implementación de VLANs, ya que por definición los switches LAN no filtran el broadcast y lo inundan a toda la red. Sin embargo, cuando implementamos switches Cisco se puede limitar el monto de ancho de banda que se utilizará para tráfico de broadcast implementando supresión de broadcast.
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.
El estado de los puertos respectos de esta función de descarte de tráfico broadcast puede ser verificado con el correspondiente comando show:
Swtich#show storm-control broadcast
Interface Filter State Trap State. Upper....Lower....Current
--------- ------------ ----------. ------...-----....-------
Fa0/1.... inactive....inactive.....100.00%..100.00%....N/A
Fa0/2.... inactive....inactive.....100.00%..100.00%....N/A
Fa0/3.... inactive....inactive.....100.00%..100.00%....N/A
Fa0/4.... inactive....inactive.....100.00%..100.00%....N/A
Fa0/5.... inactive....inactive.....100.00%..100.00%....N/A
Fa0/6.... inactive....inactive.....100.00%..100.00%....N/A
Fa0/7.... inactive....inactive.....100.00%..100.00%....N/A
Fa0/8.... inactive....inactive.....100.00%..100.00%....N/A
Fa0/9.... inactive....inactive.....100.00%..100.00%....N/A
Fa0/10....Forwarding..Below rising..50.00%...50.00%..0.00%
Fa0/11....inactive....inactive.....100.00%..100.00%....N/A
Fa0/12....inactive....inactive.....100.00%..100.00%....N/A
¿Tenés alguna información o referencia adicional para aportar en este tema....?
Perfecto!!!! agregá un comentario con el detalle.
Muchas gracias.
Oscar Gerometta.
