Tráfico Unicast Flooding: causa básica y monitorización
El Tráfico Unicast Flooding, o Inundación de Tráfico Unicast, en su versión más amable, está asociada con el proceso de aprendizaje de los switches de red.
De hecho, se trata del método a través del cual los switches identifican las direcciones a nivel de enlace de datos o MAC address de los dispositivos que son accesibles por cada uno de sus puertos, construyendo de esta forma una tabla que luego será utilizada para decidir el destino de cada frame que llega al switch.
Sin embargo, este tipo de tráfico también puede presentar un lado perverso, en el cual estaremos lidiando con una excesiva cantidad de frames Unicast que sin justificación aparente son transmitidos por todos los puertos del switch.
Hay consenso en aceptar que los períodos de inundación por Unicast pueden suponer desde un bajo rendimiento hasta la caída completa de la red.
Y aunque no encontramos datos estadísticos que permitan estimar la prevalencia de los problemas de Tráfico Unicast Flooding, sí es cierto que, de forma constante, observamos en los foros técnicos a muchos administradores de red buscando información sobre el tema.
También es notable que empresas fabricantes de dispositivos de red, como Cisco, hayan desarrollado procedimientos y comandos para tratar de contener el efecto negativo de este tipo de tráfico. Aunque los temas de diagnóstico y monitorización no hayan sido abordados de manera tan contundente.
Ahora bien, ¿qué síntomas pueden llevarnos a pensar que podríamos tener un problema asociado con Tráfico Unicast Flooding?
Síntomas
En principio, un problema de Tráfico Unicast Flooding en una fase aguda puede llevar a que se eleve por mucho la cantidad de tráfico sobre una VLAN, que se aumente el número de paquetes perdidos, que aumente la latencia de los servicios afectados y, como decíamos, puede degenerar en la caída completa de la red.
Por otro lado, no es despreciable el efecto negativo que pudiera tener esta condición cuando no llega a reflejar síntomas demasiado alarmantes y la red “se acostumbra” a ellos, es decir, existe el tráfico excedente, hay una degradación del rendimiento y los casos de soporte asociados son cerrados sin llegar a la causa raíz.
En nuestra experiencia, esos casos de soporte “recurrentes”, que no llegan a cerrarse de forma satisfactoria y que son abiertos por usuarios que reportan lentitud o imposibilidad en el acceso a recursos de la red, pueden en realidad ser un síntoma que nos lleve a sospechar la presencia de Tráfico Unicast Flooding en la plataforma.
Sospecho que tengo Tráfico Unicast Flooding. ¿Ahora qué?
Hay tres elementos que hacen difícil batallar con el Tráfico Unicast Flooding. El primero de ellos es que esta condición es difícil de precisar.
Los analistas de soporte pueden llegar a visualizar la condición de Unicast Flooding si tienen la oportunidad de evaluar con un analizador de tráfico los paquetes Broadcast del segmento y logran observar tráfico Unicast, allí donde solo debería ver paquetes Broadcast o Multicast.
Aquí se presenta el segundo elemento; esta condición, dependiendo de su causa raíz, puede ser temporal. Por lo tanto, podemos tener una inundación de tráfico Unicast por un periodo de tiempo variable y la misma puede desaparecer sin ninguna intervención.
Complicándose así la visualización, ya que se debe tener la oportunidad de analizar el tráfico correcto, del segmento correcto, en el momento correcto, lo que en una plataforma grande puede ser muy complicado y costoso en términos de recursos.
El tercer punto es que son muchas las condiciones que pueden generar la inundación, lo que complica su visualización, el análisis y la toma de decisiones.
Posibles causas vs la causa básica
Hay muchas condiciones documentadas como generadoras de Tráfico Unicast Flooding; desde cambios en la topología que pudieran hacer patentes fallas en el diseño de la red y en la configuración de los switches hasta ataques maliciosos que promueven la inundación, pasando por diferentes condiciones técnicas, como el temido Enrutamiento Asimétrico.
Sin embargo, todas estas condiciones tienen su base en la forma en cómo se resuelven nombres y direcciones en un esquema de red basado en switches.
El esquema de resolución de nombres apoya las comunicaciones desde que un dispositivo A desea establecer contacto y transferir información a otro dispositivo B, para lo cual se requiere a nivel de red la dirección IP y a nivel de enlace de datos la dirección MAC de dicho dispositivo.
Muchos son los protocolos y procedimientos involucrados en este esquema de resolución de nombres, pero en cuanto al Tráfico Unicast Flooding debemos detenernos en dos elementos que participan en el esquema y que son gestionados por los switches: la tabla ARP y la tabla de direcciones MAC.
El dispositivo A puede obtener la dirección IP del dispositivo B en la tabla ARP, donde los registros tienen un tiempo de permanencia, llamado de forma genérica arp aging time, cuyo valor puede ser de 4 horas, por ejemplo.
De no existir el registro, se emitirán de forma consecutiva una terna de mensajes Broadcasts en búsqueda de la dirección en cuestión. Si el lector está interesado en indagar un poco más sobre paquetes Broadcast y su efecto negativo le recomendamos la lectura de este artículo, publicado en este mismo blog.
Teniendo la dirección IP definida se requiere entonces, a nivel de enlace de datos, la dirección MAC, para lo que se utiliza la tabla de direcciones MAC, cuyos registros también tienen un tiempo de permanencia que podemos referir como mac address table aging time, cuyo valor por defecto puede ser 5 minutos. De no existir el registro apropiado, el switch entiende que debe intentar aprender dónde se encuentra esta dirección y genera el tráfico Unicast Flooding.
Las capacidades y situación actual de cada tabla, además de la desigualdad en los tiempos de permanencia de los registros y la forma en que los protocolos utilizan dichos registros, es la base para la mayoría de las condiciones que generan Tráfico Unicast Flooding:
- Los cambios de topología pueden generar inconsistencias en las tablas o el desbordamiento de las mismas.
- Los códigos maliciosos utilizan el desbordamiento de las tablas como herramienta.
- El enrutamiento asimétrico puede generarse por múltiples enlaces entre dos VLANs, y por la diferencia en los tiempos de permanencia entre las tablas arp y de direcciones MAC.
Esta es la razón, por lo que nuestra recomendación es que, antes de estudiar las condiciones específicas de cada situación, y por supuesto antes de tomar decisiones administrativas como bloquear el tráfico Unicast en uno o varios puertos o para toda una VLAN, es conveniente asegurarse de:
- Investigar y entender bien cómo funciona el esquema de resolución de nombres en la plataforma basada en los switches, considerando las marcas y modelos de switches con los que se cuenta.
- Revisar las tablas ARP y de direcciones MAC, así como los comandos de visualización y modificación asociados con las mismas.
Esto nos ofrecerá una capacidad de trabajo con la cual podremos intentar resolver las condiciones específicas de generación de Tráfico Unicast Flooding, cuando se presenten. Quedando entonces pendiente el tema de la monitorización
Un primer acercamiento a la monitorización
Un primer acercamiento a la tarea de monitorizar las condiciones que pueden generar Tráfico Unicast Flooding puede partir de evaluar el comportamiento de la tabla de direcciones MAC.
Para lo cual, podemos utilizar Pandora FMS para obtener la información de los switches, automatizar la revisión que inicialmente pudiéramos hacer de forma manual y luego utilizar la información y todas las facilidades de visualización para facilitar nuestro análisis.
Podríamos entonces seguir estos pasos:
Visualizar la topología de red:
La idea en este punto es lograr un mapa que permita:
- Identificar los switches que conforman la plataforma (con variables como nombre, marca, modelo y cantidad de puertos).
- Identificar los switches administrables y los no administrables, así como los que funcionan en capa de red y los que funcionan solo en capa de enlace de datos.
- Identificar los puertos que interconectan switches y el esquema de configuración de dichos puertos (enlaces simples o definidos como troncales u otros).
- Establecer la distribución de los dispositivos de cada VLAN en los switches.
Para ello utilizaremos las facilidades que en el tema de Mapas de Red ofrece Pandora FMS. Tengamos en cuenta que los mapas en Pandora FMS pueden ser de generación automática, pero también nos permiten establecer la información que deseamos esté presente en el mapa, de manera de lograr un mapa de topología tanto física como lógica, que sea especialmente útil para el caso que nos ocupa.
Una vez desarrollado el mapa quizás podamos hacerlo visible desde el dashboard de los responsables de la monitorización de la red, siendo innecesario para el grupo de personas más orientadas a la administración de aplicaciones, por ejemplo. Para ello, utilizaremos las facilidades de Pandora FMS que nos permiten definir dashboard personalizados para cada usuario.
Evaluar la tabla de direcciones MAC:
Digamos, por ejemplo, que deseamos evaluar la cantidad de registros utilizados y disponibles en las tablas de direcciones MAC de todos o de un grupo seleccionado de nuestros switches de red, de manera de identificar si existe una condición de desbordamiento en algún momento o fluctuaciones demasiado amplias que merezca la pena investigar.
Para automatizar la revisión de las tablas consideremos como ejemplo los siguientes comandos, extraídos de switches Cisco que permiten evaluar la situación actual de las tablas de direcciones MAC:
- show mac address-table
Muestra de forma general las direcciones MAC que son accesibles por cada puerto y a qué VLANs pertenecen dichas direcciones. - show mac address-table aging time
Muestra información sobre el tiempo de permanencia de los registros en la tabla. - show mac address-table count
Muestra la capacidad en términos de cantidad de registros que contiene la tabla. Además muestra la cantidad de registros disponibles.
Tengamos en cuenta que la aplicación de estos comandos implica la conexión a los switches vía SSH, la presentación de credenciales y la ejecución del comando como tal.
Podríamos entonces automatizar la aplicación del comando show mac address-table count en intervalos inferiores al mac address aging time, utilizando para ello las facilidades que suministra Pandora FMS para la automatización de este tipo de evaluaciones, o la monitorización basada en SNMP si en el MIB del switch en cuestión aparecieran las variables requeridas.
Luego, esta información de cada switch se registrará en un archivo o gráfica que después podremos evaluar, identificando si cambia con el tiempo y si alguna tabla llega a experimentar un desbordamiento. Aquí podríamos evaluar la necesidad de generar una alarma sobre esta condición.
Así mismo podríamos cruzar estos datos con los suministrados por el esquema de monitorización Pandora FMS sobre indicadores de rendimiento que ya midamos en nuestra plataforma, y tratar de relacionar un comportamiento identificado en la tabla de direcciones MAC con fluctuaciones inaceptables de indicadores, como latencia en un servicio o aplicación, por ejemplo.
A partir de aquí podríamos continuar trabajando en el análisis de este tipo de tráfico, dependiendo de la existencia del mismo en nuestra plataforma y sus efectos en el rendimiento global.
Finalmente, esperamos que este primer acercamiento a la monitorización de una condición tan evasiva como el Tráfico Unicast Flooding les motive a considerar la monitorización basada en Pandora FMS como la herramienta para monitorizar esta y otras condiciones de error.
Por supuesto, les invitamos a compartir sus experiencias con el tráfico Unicast Flooding y a solicitar información sobre las capacidades en monitorización de redes que aporta Pandora FMS, visitando este enlace.
