ContenidoRMON (Remote Network Monitor, Monitor de Red Remoto).....................................................1

DEFINICIONES:.....................................................................................................................1

DESCRIPCIÓN:......................................................................................................................2

Gestores múltiples................................................................................................................3

Configuración de la sonda RMON : Gestión de tablas.........................................................4

MIB RMON v1....................................................................................................................4

MIB RMON v2....................................................................................................................6

FUNCIONAMIENTO..............................................................................................................7

EJEMPLOS DE APLICACIÓN...............................................................................................8

RMON (Remote Network Monitor, Monitor de Red Remoto)

DEFINICIONES:RMON: Define una MIB que amplía las funcionalidades ofrecidas por MIB-II sin la necesidad de realizar cambios en el protocolo de gestión SNMP. Con la MIB RMON se puede obtener información sobre la red misma, y no sobre los dispositivos conectados a la red como es el caso de MIB-II.

El monitoreo remoto de redes es la especificación más importante que se puede agregar al conjunto SNMP, MIB-II. Esta especificación se encuentra descripta en varias RFCs, las de mayor importancia son las siguientes:

· RFC1757: Remote Network Monitoring Management Information Base.· RFC2021: Remote Network Monitoring Management Information Base II.

Sonda RMON: RMON es un protocolo para la monitorización remota de redes. Un agente RMON, denominado también monitor o sonda RMON, recogerá información de gestión, principalmente estadísticas del tráfico, sobre la red entera, y las pone a disposición de las estaciones de gestión. Las sondas RMON recopilan información y tiene la misma función que un agente SNMP, transmitiendo la información periódicamente. Además, pueden procesar la información a enviar a la estación de administrador.

El monitor RMON puede encontrarse en un dispositivo totalmente dedicado para este servicio, o ser un proceso que se ejecuta en un dispositivo de la red, como por ejemplo un Switch, consumiendo recursos de memoria y de procedimiento para la función de gestión.

Identificador de la MIB RMON: iso.org.dod.internet.mgmt.mib-2.rmon 1.3.6.1.2.1.16

VERSIONES:

RMON1: orientado a capas física y de enlace, su MIB define 10 grupos de objetos: estadísticas, alarmas, filtros, eventos,...

RMON2: orientado a capas de red y superiores, su MIB define otros 10 grupos de objetos.

En ambos casos no siempre el dispositivo implementa todos los objetos.

AplicaciónTransporteRedEnlace(MAC)

Físico

DESCRIPCIÓN:En la especificación RMON se define el explorador RMON (RMON probe) que es todo sistema que implemente el uso de la MIB RMON. El explorador RMON consta de un agente RMON, que no difiere de las características de un agente SNMP, y de una entidad de procesos RMON (RMON probe process entity) que es la que provee la capacidad de lectura y escritura en la MIB RMON local.

VENTAJAS

El uso de RMON para la gestión de redes ofrece muchas ventajas, algunas de estas son:

Operación off-line: aún si se ha producido un fallo en la conexión entre el monitor RMON y la estación de gestión de red, el monitor continuará recolectando información acerca de la red (performance, tráfico, etc.). De esta manera, cuando se restaure la conexión con el gestor, el monitor enviará la información requerida por éste. Además, como el monitor recolecta la información estadística sin necesidad de que el gestor envíe constantemente pedidos, se logra reducir el tráfico de polling, disminuyendo el ancho de banda necesario para gestión en la red.

Detección y reporte de fallos: El monitoreo preventivo ofrece la posibilidad de detectar un fallo antes de que éste ocurra. Esto se logra mediante el análisis de la performance y el tráfico de la red. El monitor RMON puede configurarse para que detecte estos casos automáticamente, y en caso de ocurrir esta condición, la registra y envía un mensaje de notificación al gestor de red.

Datos con valor agregado: El monitor de red puede realizar un análisis de la información recolectada de la subred que gestiona. Por ejemplo, puede reconocer las estaciones que generan mayor cantidad de tráfico, o las que generan mayor cantidad de errores en la red. Esta función no podría ser ejercida por el mismo gestor de red, salvo que se encontrara dentro de la misma subred.

Múltiples Gestores de red: En casos donde la red es muy amplia y consta de muchas subredes puede ser necesario el uso de más de un gestor de red. El

RMON V2

RMON V1

MODELO TCP/ IP Monitoreado

por:

Ilustración 1: Capas del modelo TCP/IP y las versiones de RMON

monitor de red puede ser configurado para que funcione correctamente con múltiples gestores de red.

Nota: no todos los monitores de red soportan estas características, pero la especificación provee el soporte para el uso de las mismas.

Gestores múltiplesCuando un explorador RMON es compartido puede ser accedido desde diferentes gestores de red y pueden ocasionarse las siguientes dificultades:

1. Si se realizan pedidos de varios gestores a la vez donde cada uno necesita cierta cantidad de recursos, y la suma de estos excede la capacidad del explorador RMON, éste no podrá entregar dichos recursos ocasionando que alguno de los pedidos no se lleven a cabo.

2. Si una estación de gestión retiene recursos del monitor por un período largo de tiempo, puede provocar que otra estación de trabajo no pueda acceder a los datos de gestión por falta de recursos.

3. Los recursos pueden estar asignados a un gestor que haya sufrido un fallo sin haber liberado estos recursos.

Para evitar este tipo de problemas la MIB RMON tiene para todas las tablas de control definidas una columna que identifica al propietario de la fila correspondiente. Este valor puede ser usado de las siguientes maneras:

1. Un gestor puede reconocer los recursos que posee y ya no necesita, y de esta forma puede liberarlos.

2. Un operador de red puede conocer qué gestor está utilizando determinados recursos o

3. Un operador puede tener la autorización para liberar recursos que otros operadores hayan reservado.

4. Si un gestor ha sido reinicializado puede detectar los recursos que poseía anteriormente y liberar los que ya no necesitará.

La etiqueta de propietario no confiere ningún tipo de seguridad sobre los objetos asociados. Estos pueden ser leídos, modificados y borrados por cualquier gestor de red (en caso de que los objetos tengan permisos de lectura y escritura).

Para mejorar la eficiencia del sistema en el uso de los recursos, en casos de gestores múltiples, pueden compartirse los valores obtenidos por el explorador RMON. Para que pueda llevarse a cabo esta mejora es necesario que cuando un gestor requiere información, debe observar antes de solicitar los recursos necesarios por si otro gestor está pidiendo los mismos datos. Si es así, puede leer los datos de las filas de la tabla creadas por el otro gestor, sin gastar más recursos del explorador RMON. La desventaja de compartir recursos se da cuando el propietario de las filas de la tabla ya no necesita más la información y elimina las mismas, sin saber que estaban siendo utilizadas por otro gestor.

Configuración de la sonda RMON: Gestión de tablas

Tabla de Control (r/w):

En ella se colocan los parámetros de configuración. El gestor añade una fila en esta tabla para configurar su petición de

monitorización. La sonda empieza a recolectar datos sobre esa petición.

Tabla de Datos (r):

Almacena los resultados de la monitorización. El gestor accede a los resultados almacenados.

Ilustración 2: Ejemplo de Tabla RMON

MIB RMON v1El monitoreo remoto de redes está especificado con la definición de una MIB que se encuentra detallada en la RFC 1757. Esta MIB se encuentra incorporada en el árbol de MIB-II con el identificador 16. La MIB RMON está compuesta por nueve grupos:

1. statistics2. history3. alarms4. host5. hostTopN6. matrix7. filter8. capture9. event

En la RFC 1513 se definen extensiones en la MIB RMON para la gestión de redes tipo Token Ring (802.5). Esta extensión consiste en el agregado de nuevas tablas en los grupos ya existentes, statistics y history, y el agregado de un nuevo grupo:

10. tokenRing

Los diez grupos son opcionales para la implementación de RMON. Sin embargo, existen algunas dependencias que se detallan a continuación:

1. El grupo alarm necesita la implementación del grupo event.2. El grupo hostTopN necesita la implementación del grupo host.3. El grupo packet capture necesita la implementación del grupo filter.

GRUPO DE RMONFUNCION

Estadística Contiene la estadística medida por la punta de prueba para cada interfaz vigilado en este dispositivo.

Historia Registra muestras estadísticas periódicas de una red y las salva para la extracción posterior.

Alarmar Toma muestras estadísticas de variables en la punta de prueba y las compara periódicamente con los umbrales previamente configurados.

Ordenador Principal Contiene la estadística asociada a cada ordenador principal descubierto en la red.

HostTopN Prepara los vectores que describen los ordenadores principal que rematan una lista pedida por una de su estadística.

Matriz Estadística de los almacenes para las conversaciones entre los conjuntos de dos direcciones

Filtros Permite a los paquetes ser correspondido con por una ecuación del filtro.

Captura del Paquete Permite a los paquetes ser capturado después de que atraviesen un canal.

Acontecimientos Controla la generación y la notificación de acontecimientos de este dispositivo.

Token-ring Ayuda del token ringTabla 1. Funciones de los Grupos RMON v1

MIB RMON v2 Se encuentra recogida en la RFC 2021. Hace énfasis en el tráfico IP y en el tráfico del nivel de aplicaciones. Su función es proporcionar información de gestión de los niveles de red y de aplicación permitiendo analizar el flujo entre subredes. La RMON MIB v2 añade 10 subgrupos a la RMON MIB v1 .

GRUPO DE RMON FUNCIONProtocol Directory Lista de protocolos que la sonda RMON2

puede monitorear con lo cual un gestor puede conocer cuales son los protocolos que implementa un agente RMON v2. Muy importante cuando los gestores y los agente son de diferentes proveedores.

Protocol Distribution Estadísticas de tráfico por cada protocolo de nivel de red.

Address mapping Traducción entre direcciones MAC y direcciones IP.

Network Layer host Estadísticas de tráfico de la capa de red en los host.

Network layer matrix Estadísticas de tráfico entre pares de nodos a nivel de la capa de red.

Application layer host Estadísticas de tráfico de la capa de aplicación, por protocolos, en cada host.

Application layer matrix Estadísticas de tráfico entre pares de host, por protocolo, de la capa de aplicación.

User history Muestreo periódico a variables especificadas por el usuario. Permite, por ejemplo, obtener la historia de un servidor particular o de una conexión router-to-router.

Probe configuration Suministra un estándar para configurar remotamente los parámetros de una sonda.

Tabla 1. Funciones de los Grupos RMON v2

FUNCIONAMIENTOUna configuración típica de RMON consiste en la dirección de la estación central de la red y un dispositivo que hace un monitoreo remoto, llamado un agente de RMON. La dirección de la estación de la red puede ser el servidor o una PC basada en Windows o basada en UNIX que ejecuta una aplicación, tal como análisis de efectividad. De esta estación, se puede publicar comandos del SNMP que solicita la información del agente de RMON. El agente de RMON envía la información solicitada a la estación, que procesa y visualiza esta información sobre su consola.

El agente de RMON es un software que reside dentro de la red. Mientras que los paquetes viajan a través de la red, el agente de RMON recoge y analiza datos de Ethernet en tiempo real en un segmento alejado del LAN y salva continuamente los datos localmente en Ethernet DCM según la especificación del MIB de RMON.

Para poder administrar una red de manera correcta también es necesario un buen y potente software. Suele ser una buena elección el software programado por grupos de seguridad conocidos.

Ilustración 3: Esquema de operación de RMON

EJEMPLOS DE APLICACIÓNEjemplo 1:

Problema:

El personal de la división de ingeniería de un fabricante de computadoras corre simulaciones sobre la Intranet lo que típicamente dura días y requiere la máxima velocidad de la red.

Las simulaciones comenzaron a estar muy lentas y la división de ingeniería le echo la culpa a la falta de ancho de banda de la red exigiendo que la tecnología de su LAN fuera reemplazada con otra de más velocidad.

Metodología de Solución:

• El administrador de red:o Analizó el historial de tráfico de las sondas RMON en las LAN criticas

de ingeniería. o Elaboró gráficos que mostraban la utilización y la máxima utilización de

las máquinas de la red.• Resultado:

o La utilización del ancho de banda de las LAN nunca alcanzo el 10 %.

o La máquina de más tráfico en la red de ingeniería era una x-terminal

corriendo un sofisticado protector de pantalla desde el servidor.• La división de ingeniería no se quejó desde entonces.

Ejemplo 2:

Problema:

• La Internet de una ciudad presenta baja respuesta.

• Los usuarios reportan problemas en el acceso a los servidores vía TCP/IP.

• Eventualmente, los problemas se resuelven reseteando los servidores pero es una solución temporal pues los problemas se vuelven a presentar.

Metodología de Solución:

• El administrador de red coloca:o Varias sondas RMON en la red y detecta que el tráfico de broadcast es el

40% del tráfico de la red.o Filtros en las sondas para capturar sólo el tráfico de broadcast, resultando

que varios de los servidores estaban enviando solicitudes ARP en proporción anormal.

o Filtros para capturar una conversación cliente/servidor observándose que

todas las solicitudes al servidor estaban siendo respondidas, no con una respuesta, sino con una solicitud ARP.

• Se evidencia que el servidor pierde información de las direcciones físicas de los clientes tan pronto como la obtiene, o sea, su caché ARP se limpia constantemente.

• Al revisar la configuración del servidor se encontró que valor de “time out” de la caché estaba fijada en milisegundos en vez de en minutos.

• El problema de la red se resolvió completamente cambiando el valor de “time out” de la caché.

Ejemplo 3:

Problema:

• Una gran empresa posee una Internet corporativa enrutada y muy redundante con topología malla en el backbone de la WAN al cual se conectan las LAN.

• Periódicamente, en un cierto momento del día, los usuarios remotos llaman reportando problemas severos de comunicación con el centro de datos.

• Los técnicos se esfuerzan para encontrar el problema pero este desaparece después de aproximadamente una hora.

Metodología de Solución:

• El administrador de la red:o Colocó agentes RMON en las LAN conectadas a los enlaces WAN

conociendo el comportamiento adecuado del tráfico en las mismas.o Fijó umbrales para que cualquier desviación del rango de tráfico activara

una alarma.• Durante una de las ocurrencias periódicas del problema un agente disparó la

alarma por poseer proporciones de tráfico de 10 a 12 veces por encima de lo normal.

• Se detecta que los causantes eran dos puertos del router de la LAN que llevaban a la WAN.

• Una captura de tráfico demostró que la mayor parte del tráfico de la LAN venia de la WAN y se destinaba a estaciones fuera de la red local.

• Se encontró que el router del problema calculaba mal sus tablas de asignación de rutas durante el chequeo periódico que un técnico hacía en cierto momento del día.

• En lugar de enrutar el tráfico dentro de la infraestructura de la malla de la WAN, estaba desviando el tráfico a la LAN desde donde era enrutado nuevamente a la WAN.

• Esto provocaba que la LAN en cuestión formaba parte del backbone corporativo durante una hora hasta que el router se arreglaba a si mismo.

• Se cambió el protocolo de ruteo y la lista de acceso al router se modificó para quitar el impacto de las actividades del técnico.