Otros protocolos de supervisión de redes

a. Funciones iniciales de los registros

Cuando se produce un evento inesperado, como una avería, en un equipo de red, el administrador comienza por analizar los archivos de registro: "los logs". Estos son generados por el equipo en cuestión y recogen todos los eventos que se han producido, y esto, en tiempo real.

Un evento se caracteriza, por ejemplo, por un cambio de estado de una interfaz, un incidente de seguridad de puerto en un conmutador, un umbral elevado de uso de recursos de hardware, una conexión a la interfaz de administración del equipo o cualquier otra actividad que tenga lugar en la "vida" del activo en cuestión. Todo proceso ejecutado en el equipo se ha desarrollado con el fin de dejar un registro o, al menos, mostrar su estado en la consola de administración.

En la práctica, los registros son mensajes de texto que se suelen almacenar en la memoria RAM o en la memoria permanente, lo que permite al administrador conocer la actividad del activo en tiempo real, pero también durante un periodo de tiempo determinado, ya que estos mensajes llevan marca de tiempo.

De ahí la importancia de configurar la hora y la fecha en un equipo pero, sobre todo, de asegurarse de que estén sincronizadas con una referencia única, utilizada por todos los demás activos de la red. Incluso se ha creado un protocolo para ello, el protocolo NTP (Network Time Protocol).

El mecanismo de registros encaja perfectamente en los objetivos de la supervisión; se puede establecer un paralelismo con el uso de SNMP en modo trapping. De hecho, es el propio equipo el que genera y proporciona los eventos, sin que ningún proceso externo sea el origen de los mismos. Para el administrador, los registros permiten identificar un problema y, potencialmente, comprender y explicar su origen al observar los eventos que lo precedieron.

La ventaja de este sistema de registros es que, en la mayoría de los casos, es nativo en los activos de red, pero también en servidores, sistemas operativos y aplicaciones. De hecho, la primera norma oficial que dio lugar al protocolo estandarizado Syslog se registró en la IETF con el nombre de "BSD Syslog", en referencia directa al mecanismo de registro implementado en los sistemas operativos basados en el núcleo Unix BSD....

a. Orígenes del protocolo

El protocolo NetFlow fue diseñado por Cisco Systems a partir de 1996 y se integró rápidamente en las diferentes gamas de routers comercializados. El principio de NetFlow consiste, de hecho, en analizar el tráfico de red que entra por una interfaz y sale por otra. A partir de este análisis, el tráfico se agrupa en lo que se denomina flujos. Esta recopilación de flujos permite al administrador elaborar estadísticas sobre los anchos de banda de las interfaces en función de varios criterios, como la dirección IP (origen y/o destino), los puertos utilizados y las clases de QoS activadas.

NetFlow y sus variantes son utilizados especialmente por los operadores de telecomunicaciones, por un lado, para supervisar su red y, por otro, para facturar a sus clientes -en el marco de una facturación por uso-, es decir, según el ancho de banda consumido. De hecho, algunos programas que interpretan los flujos recopilados son capaces de cuantificarlos financieramente.

En un principio, NetFlow se normalizó en el RFC 3954, que servía más como memorándum de uso público que como una verdadera norma. En 2009, Cisco publicó la versión 9 de NetFlow, que sigue siendo relativamente utilizada, ya que es compatible con los protocolos IPv6, MPLS y BGP. En el mismo periodo, el protocolo IPFIX (IP Flow Information Export) apareció en la IETF bajo el RFC 5101, retomando todos los conceptos de NetFlow y formalizándolos así de manera oficial.

En 2013, IPFIX (que incluso se considera la versión 10 de NetFlow) se mejora en el nuevo RFC 7012. Se presenta entonces como el estándar "oficial" que deben implementar los fabricantes para el formateo, la gestión y la recopilación de los flujos. Se trata de una mejora de NetFlow 9 que permite una mayor flexibilidad en la definición de flujos, es decir, la posibilidad de añadir variables adicionales para un flujo determinado, como por ejemplo un nombre de usuario, algo que Cisco no había previsto necesariamente. Sin embargo, IPFIX sigue siendo compatible con NetFlow v9.

Pero, en definitiva, esta capacidad de permitir a los fabricantes integrar campos adicionales de su elección crea una variedad...