Optimización de redes corrigiendo errores que generan Broadcast innecesario
La optimizacion de redes utiliza la monitorización del tráfico de la plataforma como una manera fácil de identificar problemas de rendimiento y, en el mejor de los casos, prevenirlos. Cuando monitorizamos un segmento de red, podemos observar el tráfico Unicast, como el tráfico Broadcast y Multicast, siendo, por regla general, mucho mayor la cantidad de paquetes Unicast, convirtiéndose en un elemento vital de análisis.
Sin embargo, somos conscientes de que la presencia de tráfico Broadcast y Multicast implica un riesgo en el rendimiento global de la red. La generación de una cantidad excesiva de este tipo de paquetes puede llevar incluso al colapso total de la plataforma, por lo que hay que prestar especial interés. En este artículo vamos a estar muy atentos al tráfico Broadcast y al Multicast que, sin llegar a ser excesivo, puede llegar a deteriorar el rendimiento global de una plataforma IPv4.
Nos referimos al tráfico Broadcast y Multicast “innecesario”, es decir, a aquel que está presente en una plataforma por fallos en la configuración y en la administración de los dispositivos que la conforman.
El efecto de este tráfico no debería ser evaluado por la cantidad total de paquetes, sino por el efecto que estos paquetes tienen y pudieran tener en un futuro sobre el rendimiento global de la plataforma.
Recordemos que cada paquete Broadcast en particular, implica que todos los switches del segmento de red harán una copia de dicho paquete y lo colocarán en cada uno de sus puertos. Además, cada dispositivo deberá ejecutar una interrupción de entrada/salida para analizarlo.
Si partimos de que el paquete es innecesario, todo el proceso anterior se hará para que los dispositivos finalmente descarten el paquete. De esta forma llegamos a nuestra propuesta, que es establecer una estrategia de optimizacion de redes en función de:
- Monitorizar cada segmento de red.
- Analizar el tráfico Broadcast y Multicast con la premisa de que todo este tráfico debe estar justificado.
- Identificar la falla de configuración que es el origen del tráfico Broadcast y Multicast innecesario.
- Aplicar las actividades de soporte técnico necesarias con la idea de eliminar o minimizar su efecto
¿Qué debemos buscar? En principio debemos concentrarnos en aquel tráfico Broadcast y Multicast que sea recurrente, sin importar el volumen global de estos paquetes o aquel que, siendo aleatorio, represente, por su volumen, un riesgo a la integridad de la plataforma.
¿Quieres saber más acerca de la monitorización de redes?
Redes remotas, monitorización unificada, umbrales inteligentes… descubre la monitorización de red en la versión Enterprise de Pandora FMS
A continuación mostramos una lista con algunos de los problemas que podemos identificar y corregir al analizar el tráfico Broadcast y Multicast innecesario.
Problemas en el esquema de resolución de nombres
Cuando un dispositivo debe resolver el nombre de un recurso se apoya en sus servidores DNS (Domain Name Server) pero, si el nombre no es resuelto, el dispositivo puede generar una ráfaga recurrente de tráfico Broadcast innecesario con la esperanza de que el nombre sea reconocido por otro dispositivo en la red.
Siendo este el caso, cuando hacemos análisis de tráfico Broadcast y Multicast de un segmento de red, podremos identificar los dispositivos que buscan de forma recurrente algún recurso y no reciben respuesta, y aplicar las acciones de soporte técnico para eliminar la referencia al recurso. El ejemplo típico de este caso son las estaciones de trabajo tratando de resolver el nombre de un servidor que ya no existe en la red.
Errores en la configuración de dispositivos plug and play
Los dispositivos plug and play por lo general traen instalados un gran número de protocolos. El problema sobreviene cuando estos protocolos están en estado “activo” por defecto. Esta condición, puede llevar a que se emita una ráfaga recurrente de tráfico Broadcast o Multicast sobre el segmento de red.
El ejemplo típico es la instalación de impresoras en segmentos IP, ya que las impresoras traen configurado y activado el protocolo IPX/SPX. De modo que lo visualizado al monitorizar es una ráfaga constante de tráfico Broadcast IPX del todo innecesario.
Errores en la configuración de estaciones
En general, los administradores de red manejan estándares que regulan la forma como las estaciones de trabajo deben ser instaladas: qué sistema operativo deben utilizar, qué protocolos y qué servicios deben ser configurados. Pero si por un descuido o por la ejecución de una prueba algún protocolo innecesario queda configurado, con seguridad veremos al monitorizar una secuencia de tráfico Broadcast o Multicast innecesario asociado con dicho protocolo.
Herramientas no utilizadas de administración de redes
Muchos de los fabricantes de equipamiento de red, tales como switches, enrutadores y servidores, incluyen entre su arsenal de herramientas algún producto que permite la administración de dichos dispositivos.
Estas herramientas pueden funcionar partiendo de que cada dispositivo genere un paquete Broadcast o Multicast, de manera que la herramienta de administración se haga cargo de su presencia. El punto es que si no tenemos ninguna herramienta que administre este tipo de dispositivos no tenemos necesidad del tráfico innecesario.
Problemas con tablas mac-address
Si al analizar tráfico Broadcast y Multicast nos tropezamos con tráfico Unicast, podemos estar en presencia de una secuencia de tráfico Broadcast llamada Unicast Flooding
El tráfico Unicast Flooding refiere al tráfico direccionado entre dos dispositivos que es convertido en tráfico Broadcast por los switches. Situación que puede presentarse por varias razones, pero que con regularidad es producto de la insuficiencia en tamaño de las tablas mac-address para manejar el volumen de tráfico que pasa por el switch.
El tráfico Unicast Flooding es un comportamiento normal, en especial cuando los switches se encuentran en fase de aprendizaje, pero una excesiva cantidad de este tipo de tráfico puede perjudicar en mucho el rendimiento general de la plataforma, en especial por su característica de aleatoriedad.
Fabricantes como Cisco han desarrollado procedimientos y comandos para contener el tráfico Unicast Flooding. Sin embargo, puede ser interesante evaluar además la correlación entre las capacidades de las tablas y el tamaño de los segmentos de red en términos de cantidad de tráfico.
En conclusión, la optimización de la plataforma puede y debe estar enriquecida con la monitorización de los segmentos de red, el análisis del tráfico Broadcast y Multicast innecesario y la ejecución de las actividades técnicas para eliminarlo o minimizar su efecto.
