RMON, syslog y NetFlow

Un agente normal responde por su máquina: cuánta memoria le queda, cuánto tráfico ha pasado por sus puertos. Pero hay preguntas que ningún equipo puede contestar por sí solo, como qué conversaciones dominan un segmento o cómo evolucionó el tráfico durante la madrugada. Para eso existe RMON, la monitorización remota, que es una base de datos de gestión de un tipo particular.

Su diferencia esencial es el punto de vista: informa de la red, no de un equipo concreto. Y guarda estadísticas históricas de una zona determinada, en lugar de limitarse a decir cómo están las cosas en el instante de la pregunta. Eso permite investigar hacia atrás, que es lo que hace falta cuando alguien avisa de que «ayer por la tarde iba lentísimo».

Al software que hace ese trabajo se le llama sonda, y no agente, precisamente por esa diferencia de alcance. Se instala en un punto por el que pase el tráfico que interesa: un encaminador troncal, un conmutador, o un equipo dedicado en exclusiva a ello cuando el volumen lo justifica.

El agente contesta por su máquina y en el momento; la sonda contesta por el segmento y con histórico. Esa es la pregunta de examen sobre RMON.

La herramienta de gestión de red es el producto que se instala en el gestor. Como SNMP es un estándar, funciona contra agentes de cualquier fabricante: se puede vigilar con el mismo panel un conmutador de una marca, un servidor de otra y una cabina de una tercera.

Lo que se le pide a una de estas herramientas es siempre lo mismo, y conviene tenerlo claro porque explica para qué sirve todo lo anterior.

• Descubrir los equipos de la red y mantener el inventario al día
• Sondear periódicamente a cada agente y guardar el histórico de cada valor
• Recibir los avisos espontáneos y presentarlos junto al resto de la información
• Comparar cada valor con un umbral y generar la alarma cuando se supera
• Avisar a quien corresponda por correo o por mensaje, con turnos y escalado
• Pintar gráficas y sacar informes para ver tendencias y planificar ampliaciones

Los productos que se citan en el temario son, entre los de código abierto o con versión libre, Nagios, Icinga, Cacti, Zabbix, Zenoss, OpenNMS y Pandora FMS; y entre los comerciales, SolarWinds, OpenView y Patrol. Nombres aparte, todos hacen lo de la lista anterior, y la diferencia práctica está en cuánto trae hecho el producto y cuánto hay que configurar.

El error de bulto al montar uno de estos sistemas no es técnico: es poner alarmas a todo. Un panel con doscientos avisos permanentes no lo mira nadie, y la avería de verdad pasa desapercibida entre el ruido. Se empieza por lo que de verdad interrumpe el servicio y se van añadiendo umbrales con criterio.

Que SNMP sea un estándar es lo que permite que una sola herramienta valga para equipos de fabricantes distintos. Sin eso haría falta una consola por marca.

SNMP responde muy bien a «cómo está esto», pero mal a otras dos preguntas que se hace el administrador a diario: qué ha pasado exactamente en ese equipo y quién se está comiendo el ancho de banda. Se complementa con dos mecanismos que suelen ir en el mismo cuadro de mandos.

El primero es el registro centralizado. Los equipos de red y los servidores pueden enviar sus mensajes de registro a un servidor común en lugar de guardarlos solo en local, lo que da dos ventajas: se pueden correlacionar sucesos de varias máquinas y el registro sobrevive aunque la máquina se apague o alguien lo borre. Cada mensaje va etiquetado con su origen y su gravedad, y por eso se puede filtrar lo importante de lo rutinario.

El segundo es la contabilidad por flujos. El encaminador o el conmutador resume las conversaciones que pasan por él (origen, destino, puertos y volumen) y envía ese resumen a un recolector, bien de todas las conversaciones, bien de una muestra estadística cuando el volumen es enorme. Es lo que contesta a quién habla con quién y cuánto ocupa, sin necesidad de capturar el contenido del tráfico.

Los flujos resumen conversaciones, el capturador guarda paquetes enteros. Para saber quién consume la línea sobra con lo primero, que además es mucho más barato de almacenar.

SNMP se impuso, pero no fue la única propuesta. En un examen aparecen tres nombres más y basta con saber ubicarlos.

Las diferencias frente a SNMP son tres y explican por qué el segundo es más potente y aun así perdió. Permite crear y borrar objetos de gestión, cosa que SNMP no hace porque su estructura viene fijada por la norma y por el fabricante. Es orientado a conexión, mientras que SNMP no lo es. Y está dirigido por sucesos, con un mecanismo de notificación equivalente al aviso espontáneo.

La comparación se resume así: la propuesta OSI podía crear y borrar objetos y trabajaba con conexión; SNMP no puede lo primero ni hace lo segundo, y precisamente por ser más simple se extendió.