Modelo de Comunicaciones SNMP

Arquitectura• UDP: servicio no fiable.• Se sigue el modelo de comunicación de “sondeo” (salvo para la

operación “Trap”)• Aunque nos centraremos en redes IP, se puede implantar SNMP sobre

otras torres de protocolos (IPX, OSI, CLNS, …)

Operaciones

• GetRequest: el gestor realiza una petición de valores específicos de la MIB del agente.• GetNextRequest: el gestor realiza una petición del objeto siguiente a uno dado en la

MIB del agente, siguiendo un orden lexicográfico.• GetResponse: el agente devuelve los valores solicitados por las operaciones anteriores

al gestor. Es la respuesta a un GetRequest, GetNextRequest o SetRequest.• SetRequest: el gestor permite asignar un valor a una variable en el sistema del agente.• Traps: el agente informa de un suceso inusual predefinido mediante “informe de

eventos”.

Formato del mensaje SNMP

Significado de los campos del mensaje• Version: Versión del protocolo SNMP.• Comunity: comunidad que permite la autenticación del gestor ante el agente y

el control de acceso (autorización)• Request-id: Identificador único para cada petición. Es el mismo en la respuesta

correspondiente.• Error-status: indica si ha ocurrido un error cuando procesa una petición. Los

código son: noError (0), tooBig (1), noSuchName (2), badValue (3), readOnly(4), genErr (5). Vale 0 en caso de getRequest, getNextRequest y setRequest.

• Error-index: cuando se ha producido un error, puede aportar información, indicando que instancia de la lista de variablebindings ha producido el error. Vale 0 en caso de getRequest, getNextRequest y setRequest.

• Variablebindings: lista de nombres de variables (OIDs) y sus correspondientes valores. Los valores son nulos (NULL) en casos como GetRequest, GetNextRequest o GetResponse con error. Permite múltiples operaciones en el mismo mensaje.

Significado de los campos del mensaje (cont)

• Enterprise: tipo de sistema que genera el trap, basado en sysObjectID.• Agent-addr: dirección IP del agente que genera el trap.• Generic-trap: código de trap genérico.• Specific-trap: código de trap específico.• Time-stamp: tiempo desde la última (re)inicialización del agente y la

generación del trap (valor de sysUpTime).

Operación de petición de información

• GetRequest (gestor-agente) - GetResponse (agente-gestor).• Request-id permite correlar petición con respuesta y detectar duplicados (udp

no fiable).• Variablebindings permite multiplexar varias peticiones en un mismo mensaje.• La respuesta debe ser atómica, es decir, si una petición falla:

– No se devuelve el resultado de ninguna.– Error-index apunta al name (varible-bindings) que ha producido el fallo. Ej.: si falla

el segundo name, erro-index = 2.• Errores en la respuesta (error-status):

– noSuchName: OID no referencia a una instancia o no se encuentra en la vista.– tooBig: el tamaño del mensaje de respuesta no cabe en el tamaño máximo de datos

UDP impuesto por el sistema.– genErr: cualquier otro motivo.

Operación de navegación por la MIB• GetNextRequest (gestor-agente) - GetResponse (agente-gestor)• Se procesa igual que GetRequest.• Operación atómica.• Devuelve el valor de la siguiente instancia en orden lexicográfico:

– OID, no instancia: ejemplo (1.3.6.1.2.1.4.3)• Si existe en la vista devuelve la instancia OID.0• Si no existe, valor de la siguiente instancia NextOID.0

– Instancia OID: ejemplo (1.3.6.1.2.1.4.3.0)• Valor de la siguiente instancia: NextOID.0

– OID de tabla o Entry de tabla: ejemplo (ifTable o ifTable.1)• Valor de la primera instancia de la tabla.

– OID columnar: ejemplo (ifTable.1.1)• Valor de la primera instancia de la columna de la tabla.

– Instancia OID columnar: ejemplo (ifTable.1.1.1)• Valor de la siguiente instancia en la vista (puede ser de la misma columna, otra columna o

fuera de la tabla).

• Si no existe la siguiente instancia devuelve NoSuchName.

Operación de modificación de información

• SetRequest (gestor-agente) - getResponse (agente-gestor)• VariableBindings:

– En Set contiene name y value de todas las instancias cuyo valor se quiere modificar.– En response:

• Contiene name y value tras la modificación.

• Si se produce error en alguna de las peticiones del mensaje, no se modifica ninguna y no se devuelve ningún valor.

• Códigos de error:– noSuchName, TooBig, genErr: mismos casos que GetRequest.– badValue: si tiene algún (name,value) inconsistente (tipo o longitud del valor no

válidos, fuera de rango...).– En el caso de noSuchName el error puede indicar que el objeto no puede (control de

acceso) ser modificado (aunque exista).– Si el objeto es de sólo lectura devuelve noSuchName. No se utiliza readOnly. En

SNMPv2 se utiliza un nuevo código denominado notWritable.

Operación de notificación de eventos

• Trap (agente-gestor).• No requiere confirmación: problema si se pierde el mensaje.• Motivos de trap:

– coldStart (0): reinicio inesperado debido a algún tipo de fallo.– warmStart (1): reinicio en caliente, normalmente programado.– linkDown (2): fallo en uno de los enlaces del sistema. El primer elemento en

variablebindings, contiene el valor ifindex del interface.– linkUp (3): uno de los enlaces se ha iniciado. El primer elemento en

variablebindings, contiene el valor ifindex del interface.– authenticationFailure (4): se ha recibido un mensaje SNMP con error de

autenticación.– egpNeighborLoss (5): se ha perdido la relación con un vecino EGP.– enterpriseSpecific (6): se ha producido algún evento específico de empresa

especificado en specific-trap.

SNMPv2

Bibliografía (RFCs)

• 1901 - Introducción• 1902 - SMI• 1903 – Nomenclatura• 1905 - Protocolo• 1907 - MIB• 1908 - Coexistencia v1/v2

Principales novedades

• Soporte de comunicación gestor-gestor(PDU informrequest)

• Lectura de tablas completas en una sola operación (PDU getbulkrequest)

• Seguridad: fracaso total, sigue basada en “comunidades” hasta la v3

• ¿Simple?

SMI

• Basicamente una ampliación de la versión v1• Amplía el árbol de OIDs:

– directory (1)– mgmt (2)– expmt (3)– private (4)– security (5)– snmpv2 (6)

SMI (cont)

• Se definen nuevos tipos de datos:– enumerados– Counter32– Counter64– Gauge32– BITS

• Se redefinen los tipos de acceso que se asocian a los atributos:– Desaparece write-only– Aparecen:

• accessble-for-notify• read-create• read-write-create

SMI (cont)

• En cuanto a las tablas se dividen en dos categorías:– Controladas por el agente: el gestor no

puede crear/eliminar filas– Controladas por el gestor: el gestor puede

crear/eliminar filas,• y se soporta la modificación de la

estructura de la tabla desde el gestor.

Protocolo

• Básicamente dos cambios respecto a la versión v1:– Se añaden nuevas primitivas– Se unifica el formato de las PDUs (en la

versión v1 el de trap era diferente al resto

Protocolo - PDUs

• get-request• get-next-request• get-bulk-request• response• set-request• inform-request• snmpV2-trap• report (apareciá en los documentos de seguridad y

después se eliminó junto con ellos)

Protocolo – Formato de PDUs

data1 data2

Protocolo – Formato de PDUs

• El significado de data1 y data2 y variablebindingsdepende del tipo de PDU, por ejemplo:– response devuelve error-status y error-index en

data1/data2– getbulkrequest devuelve non-repeaters y max-

repetitions en data1/data2– variablebindings puede incluir:

• OIDs y NULL en peticiones de información• noSuchObject, noSuchInstance, endOfMibView, …

Protocolo – get-request y get-next-request• Similar a v1, pero• en v1 las peticiones múltiples son atómicas (se reciben todas o ninguna)• en v2 pueden ser incompletas

– Es posible devolver noSuchObject, noSuchInstance, endOfMibView para elementos individuales

Protocolo – set-request• La única diferencia con v1 está en las respuestas• Sigue siendo átómica (se modifican todas las variables o ninguna)• Básicamente existen más códigos de error posibles

Protocolo – get-bulk-request

• Permite leer tablas accediendo fila a fila y optimizando la transacción global (de una tabla completa)

• Es similar a get-next-request en el sentido de que utiliza un orden lexicográfico

• Devuelve una lista de variables con contenidos de la tabla en variablebindings y dos contadores en data1/data2 (non-repeaters y max-repetitions) que controlan el acceso a esas variables

Protocolo – snmpv2-trap

• Utiliza un formato diferente de v1, pero• Se unifica en cuanto a formato con las demás

primitivas de la v2.• variablebindings incluye:

– sysUpTime.0– snmpTrapOID.0 (qué trap)– Información de interés sobre la trap concreta (varía de

trap a trap)

Protocolo – inform-request

• Permite la comunicación de datos entre un gestor y otro.

• Funcionalidad básica: X le puede “decir” algo sobre Y a Z (X y Z son gestores)

• No muy utilizado

Interoperabilidad con v1

• Los agentes pueden hablar v1 y/o v2.• Los gestores deben hablar v2

– Y también v1 para hablar con agentes v1• El gestor intentará primero hablar v2 con un

agente– Si el agente habla v2 le contestará– Si el agente habla v1 responderá con un mensaje de

error y el gestor lo intentará con v1• Para ello puede tener que hacer conversiones (por ejemplo,

convertir getbulk en getnext

SNMPv3

Bibliografía (RFCs)

• 2271 – Arquitectura• 2272 – Procesado de mensajes• 2273 – Aplicaciones v3 (partes funcionales)• 2274 – Modelo de seguridad basado en usuario• 2275 – Modelo de control de acceso basado en

vistas

SNMP v3

• SNMPv2 +– Seguridad a nivel de protocolo:

• Autentificación, confidencialidad y gestión de claves– Es decir, el Modelo de seguridad basado en usuario.– (La confidencialidad se denomina privacidad)

– Un modelo de control de acceso mejorado• Basado en vistas de la MIB• Basado en grupos• Es decir, el Modelo de control de acceso basado en vistas.

Formato básico

• Encapsulado de las PDUs v1/v2.

• La parte de PDU se puede autentificar o autentificar/cifrar.

Cabecera

global

Cabecera del modelo de seguridad

Cabecera

de PDU

PDU SNMP

v1/v2

Parte cifrada

Parte SNMPv3

RMON

Introducción

• RMON: ampliación de SNMP, SMI, MIB para monitorización remota.

• Documentos:– RFC2819: RMON-1 de monitorización remota.– RFC2021: RMON-2 de monitorización remota.– Otros: SMON, TPM, APM, RAQMON, DSMON

• MIB que define funciones de monitorización e interfaz.• Utiliza el protocolo SNMP.• Permite definir monitorizaciones desde una gestor e

implementarlas en una sonda RMON.

Control de monitorización remota• Monitor remoto puede ser:

– Un dispositivo dedicado.– Una función disponible en un sistema con recursos (memoria y procesador)

dedicados.• Puede realizar tareas más complejas que un agente.• Control del gestor sobre el monitor remoto. Dos categorías:

– Configuración:• Especifica el tipo de información monitorizada y la forma de hacerlo.• MIB se organiza en grupos.• Cada grupo tiene tablas de control (RW) y tablas de datos (RO) asociadas.• Los parámetros de cada monitorización se especifican en una fila de la tabla de control.• Los datos recopilados se guardan en filas de la tablas de datos.• Modificar parámetro en tabla de control: borrar y crear uno nuevo.• En casos sencillos datos y control pueden estar en la misma tabla.

– Invocación de acción: hay objetos de RMON que representan estados y se invoca un determinado proceso cuando se cambia de estado (setRequest())

MIB RMON

• statistics: contadores de paquetes con algún tipo de error, octetos y paquetes de distintos tipos.

• history: toma muestras para ver la evolución de contadores de statictics con el tiempo.• alarm: monitorización y definición de umbral de alarma de algún OID de las MIBs

RMON (requiere event).• host: contadores de tipos de tráfico por cada host de la subred.• hostTopN: los N hosts que tienen un contador con mayor valor (requiere host).• matrix: información de tráfico entre parejas de hosts.• filter: define filtros para capturar o hacer estadísticas de paquetes.• capture: captura paquetes definidos por un filtro (requiere filter).• event: tabla de eventos generados ante condiciones de alarma o contador de filtros que

supera un umbral.• tokenRing: estadísticas y configuración de subred TokenRing.

Grupo Statistics• Estadísticas sobre una subred Ethernet en forma de contadores de eventos.• Tabla etherStatsTable con una fila por cada interfaz.• Algunos eventos de la tabla:

– Bytes recibidos y paquetes recibidos.– Paquetes recibidos dentro de cada uno de los siguientes grupos de tamaño:

• 64, 65..127, 128..255, 256..511, 512..1023, 1024..1518.– Paquetes broadcast y multicast recibidos.– Distintos tipos de errores:

• Pérdidas de paquetes por falta de recursos en la sonda.• Error CRC o de alineamiento (nº incorrecto de bytes). Tamaño correcto.• Tamaño menor de 64 bytes.• Tamaño mayor de 1518 bytes.• Tamaño menor de 64 bytes y error de CRC o alineamiento.• Tamaño mayor de 1518 y error de CRC o alineamiento.• Estimación del nº total de colisiones.

• Objetos no contadores: Índice de la tabla, identificador del interfaz (OID del interfaz en interfaces.ifIndex.valor), propietario y estado de la fila.

Grupo History• Define funciones de muestreo de estadísticas sobre los interfaces.• Dos tablas. Control y datos:

– historyControlTable: especifica el interfaz y detalles de la función de muestreo:• historyControlIndex: índice de la fila.• historyControlSourceData: identificador de la fuente de datos (interfaz).• historyControlBucketRequested: número de muestras que se solicita tener guardadas.• historyControlBucketGranted: número de muestras guardadas (buffer circular). El monitor

intenta que se acerque a BucketRequested lo máximo posible.• historyControlInterval: intervalo de muestreo (1..3600) segundos. Por defecto una muestra

cada 1800 seg.• historyControlOwner y historyControlStatus.

– etherHistoryTable: guarda los datos de las muestras (en cada fila una muestra):• etherHistoryIndex: índice correspondiente en la tabla de control.• etherHistorySampleIndex: identifica cada muestra de forma única.• etherHistoryIntervalStart: (sysUpTime) comienzo del intervalo de muestreo.• Contadores con la muestra pertenecientes a eventos de etherStatsTable:• dropEvents, octets, pkts, broadcastPkts, multicastPkts... Diferencia del valor

correspondiente entre el principio y el final del intervalo.• Entero que indica la utilización calculada a partir de etherStatsOctets y etherStatsPkts

medidos en un intervalo de tiempo.

Grupo Host

• Descubre los hosts en la LAN por direcciones MAC de origen y destino que ve en las tramas (sin error).

• Tres tablas: control (hostsControlTable) y datos (hostTable y hostTimeTable).

• Estructura de hostsControlTable:– hostsControlIndex: índice de la tabla. Cada fila identifica un interfaz del

monitor. El valor se usa en las otras tablas.– hostsControlDataSource: identifica el interfaz por el que se reciben datos

de la LAN.– hostsControlTableSize: nº de filas en hostTable que referencian esta fila.– hostsControlLastDeleteTime: valor de sysUpTime correspondiente a la

última vez que una fila de hostTable que referencia a esta fila fue borrada. (0 si no fue borrada ninguna fila).

– hostsControlOwner y hostsControlStatus.

Grupo Host

• Por cada entrada (fila) en la tabla de control hay entradas en la tabla de datos hostTable, una por cada MAC encontrada en el interfaz (LAN).

• Estructura de hostTable: indexada por hostIndex y hostAddress– hostAddress: dirección MAC del host– hostCreationOrder: orden (temporal) de creación del host capturado– hostIndex: valor de hostControlIndex– Contadores:

• hostIn(Out)Pkts: paquetes transmitidos a/desde el host• hostIn(Out)Octets: octetos transmitidos a/desde el host• hostOutErrors: paquetes no válidos transmitidos por el host• hostOutBroadcastPkts: paquetes difusión transmitidos por el host.• hostOutMulticastPkts: paquetes multicast transmitidos por el host.

• Estructura de hostTimeTable: misma información que la anterior pero indexada por hostIndex y hostCreationOrder.

Grupo hostTopN• Mantiene una lista (informe) de los N hosts de una LAN que alcanzan mayor

incremento de una variable determinada durante un tiempo de observación.• Dos tablas: control (hostTopNControlTable) y datos (hostTopNTable).• Estructura de la tabla de control hostTopNControlTable:

– hostTopNControlIndex: identifica un informe sobre un interfaz. Se define en una fila de la tabla.

– hostTopNHostIndex: valor de hostIndex en la tabla de datos del grupo host. Identifica por lo tanto una LAN.

– hostTopNRateBase: especifica uno de los siete contadores en la tabla de datos del grupo host.

– hostTopNTimeRemaining: tiempo que queda para finalizar el informe (seg).– hostTopNDuration: duración del intervalo de muestreo del informe (seg).– hostTopNRequestedSize: máximo número de hosts solicitado en el informe.– hostTopNGrantedSize: máximo número de hosts en el informe.– hostTopNStartTime: hora (sysUpTime) en que se inicializó el informe la última vez.– hostTopNControlOwner y hostTopNControlStatus.

Grupo hostTopN• Estructura de la tabla de datos hostTopNTable:

– HostTopNReport: identificador del informe. Mismo valor que HostTopNControlIndex.

– HostTopNIndex: índice que identifica una fila de un informe.– HostTopNAddress: Dirección MAC del host.– HostTopNRate: diferencia del valor seleccionado en HostTopNRateBase desde que

se inició el informe.• Proceso de inicio de un informe:

– Crear una fila en la tabla de control en la que selecciona un contador.– hostTopNTimeRemaining inicia cuenta descendente hasta que alcanza el valor 0 (fin

de intervalo).– Mide la diferencia entre el valor del contador al principio y final del intervalo. Para

cada host de la LAN seleccionada.– Lista los hostTopNGrantedSize hosts que tienen mayor el valor medido en orden

decreciente.– Para reiniciar el proceso, el gestor debe actualizar hostTopNTimeRemaining con el

valor de hostTopNDuration.

Grupo Matrix

• Almacena información sobre tráfico entre cada par de hostsen una LAN.

• Tres tablas: control (matrixControlTable) y datos(matrixSDTable y matrixDSTable).

• Estructura de la tabla de control matrixControlTable:– matrixControlIndex: identifica una fila de la tabla que define la

comunicación observada en un interfaz.– matrixControlDataSource: interfaz o LAN que observa el monitor.– matrixControlTableSize: número de entradas en las tablas de datos

que se refieren a esta entrada en la tabla de control.– matrixControlLastDeleteTime: valor de sysUpTime de la última

vez que se borro una entrada en las tablas de datos (0 si no se ha borrado).

– matrixControlOwner y matrixControlStatus.

Grupo Matrix

• Estructura de la tablas de datos matrixSDTable:– matrixSDSourceAddress: dirección MAC fuente.– matrixSDDestAddress: dirección MAC destino.– matrixSDIndex: identificador. Mismo valor que matrixControlIndex.– matrixSDPkts: paquetes transmitidos de fuente a destino.– matrixSDOctets: octetos transmitidos de fuente a destino.– matrixSDErrors: paquetes transmitidos de fuente a destino, con error.– Indexada con matrixSDIndex, matrixSDSourceAddress y

matrixSDDestAddress.– Se ve ordenada la información que va desde una fuentes a varios destinos.

• Estructura de la tabla matrixDSTable:– Tiene la misma información.– Indexada con matrixDSIndex, matrixDSDestAddress y

matrixDSSourceAddress.– Se ve ordenada la información que va desde varias fuentes a un mismo

destino.

Grupo Alarms• Permite definir umbrales que disparan una alarma si se rebasan.• Una tabla única (alarmTable).• Cada entrada programa una alarma con los siguientes parámetros:

– alarmIndex: índice de la tabla.– alarmInterval: intervalo de muestreo en segundos (toma muestra y compara).– alarmVariable: OID de la variable de la MIB RMON que se monitoriza, puede ser (INTEGER,

counter, gauge o TimeTicks).– alarmSampleType: el método de cálculo del valor que se compara con el umbral, puede ser

absoluto (absoluteValue) o diferencial (deltaValue).– alarmValue: valor de la variable en el último periodo de muestreo.– alarmStartupAlarm: si se dispara por subida (risingAlarm), bajada (fallingAlarm) o ambos

(risingOrFallingAlarm).– alarmRisingThreshold: umbral para disparo de alarma por subida.– alarmFallingThreshold: umbral para disparo de alarma por bajada.– alarmRisingEventIndex/alarmFallingEventIndex: índice del evento llamado (tabla de eventos)

cuando se cruza el umbral.– alarmOwner y alarmStatus.

• Se puede programar alarmas con ciclos de histéresis para evitar disparos ante pequeñas fluctuaciones alrededor del umbral.

Grupo Filters

• Observa paquetes seleccionados de un interfaz de red.• Dos tipos de filtros:

– Filtro de datos: paquetes que tienen un determinado patrón de bits que no tienen un determinado patrón.

– Filtro de estado: paquetes con un determinado estado (error CRC, longitud menor de 64 bytes o mayor de 1518 bytes...).

• Podemos construir un test con la combinación de varios filtros mediante operaciones lógicas AND y OR.

• Un canal es el flujo de paquetes que pasan un test, hay un contador del número de paquetes del canal.

• Se puede poner un evento si el contador pasa de un determinado valor (grupo event).

• Se pueden capturar los paquetes de un canal (grupo capture).• Hay dos tablas de control: filterTable y channelTable.

Grupo Capture• Captura paquetes de un determinado canal del grupo filtros.• Tablas de control (bufferControlTable) y de datos (captureBufferTable).• Estructura de la tabla de control:

– bufferControlIndex: identifica una entrada que define la captura de un canal.– bufferControlChannelIndex: índice del canal fuente de los datos channelIndex.– bufferControFullStatus: dice si el buffer está lleno o le queda espacio.– bufferControlFullAction: comportamiento con buffer lleno (bloqueado/circular).– bufferControlCaptureSliceSize:número de octetos capturados por paquete.– bufferControlDownLoadSliceSize/bufferControlDownLoadOffset: número de

octetos/offset devueltos ante una petición snmp.– bufferControlMaxOctectsRequested: máximo tamaño del buffer solicitado.– bufferControlMaxOctectsGranted: máximo tamaño del buffer garantizado.– bufferControlCapturedPackets: nº de paquetes en el buffer actualmente.– bufferControlTurnOnTime: valor de sysUpTime cuando el buffer se inició por

primera vez.

Grupo Capture

• Estructura del buffer de datos:– captureBufferControlIndex: mismo valor que bufferControlIndex.– captureBufferIndex: índice de la tabla, identifica un paquete

capturado.– captureBufferPacketID: índice que describe el orden en el que el

paquete fue recibido en un interfaz particular.– captureBufferPacketData: datos del paquete.– captureBufferPacketLength: longitud del paquete capturado o

porción de éste.– captureBufferPacketTime: tiempo de captura referido al inicio del

buffer.– captureBufferPacketStatus: estado de error del paquete.

Grupo Event

• Soporta la definición de eventos que pueden ser disparado por una condición definida en la MIB (alarma, captura de un filtro).

• Un evento puede a su vez disparar una acción definida en la MIB:– Guardar información en un log.– Envío de un trap.

• Una tabla de control (eventTable) y una de datos (logTable).• Estructura de la tabla de control:

– eventIndex:indice.– eventDescription: descripción textual.– eventType: puede tomar los valores none, log, snmp-trap o log-and-trap.– eventcommunity: comunidad para enviar el trap si es de tipo trap.– eventLastTimeSent: valor sysUpTime del último evento de esta entrada

generado.– eventOwner y eventStatus.

Grupo Event

• Estructura de la tabla de datos (asociada con eventos de tipo log):– logEventIndex: índice del evento asociado (eventIndex).– logIndex: índice de la tabla.– logTime: valor de sysUptime cuando se creo la entrada en la tabla.– logDescription: descripción dependiente de la implementación.

RMON2

• Decodifica paquetes de las capas 3 a 7 del modelo OSI.• Visibilidad a nivel de red. Observa cabeceras nivel de red

(normalmente IP) para detectar cosas como:– Sobrecarga de LAN por tráfico externo entrante y su origen.– Sobrecarga de router por trafico interno saliente y su origen.– Sobrecarga por tráfico que atraviesa la red y su origen.

• Visibilidad a nivel de aplicación. Observa cabeceras de niveles altos (tcp, http, ftp, e-mail…).

MIB de RMON2• RMON2 es una extensión de RMON que añade nuevos grupos:

– Directorio de protocolos (protocolDir): directorio de los protocolos que la sonda puede interpretar.

– Distribución de protocolos (protocolDist): estadísticas de tráfico generado por protocolo en la LAN.

– Mapa de direcciones (addressMap): asocia cada dirección de red con MAC y puerto de dispositivo.

– Host de nivel de red (nlHost): estadísticas de tráfico en hosts identificados por la dirección de red.

– Matriz de nivel de red (nlMatrix): estadísticas de tráfico entre pares de hostsidentificados por dirección de red.

– Host de aplicación (alHost): estadísticas de tráfico en hosts identificados por dirección de aplicación (protocolos de capas entre 4 y 7).

– Matriz de Aplicación (alMatrix): estadísticas de tráfico en pares de hostsidentificados por la dirección de aplicación.

– Historial de usuario (usrHistory): periódicamente muestrea parámetros de variables y logs definidos de usuario.

– Configuración (probeConfig): define parámetros de configuración estándar para la sonda.

Nuevas características funcionales

• Indexación de tablas con objetos externos.– En RMON1 las tablas de datos se indexan con:

• Un índice local que coincide con el de la tabla de control correspondiente.• Y después el índice particular de esta tabla.

– En RMON2 las tablas de datos se indexan:• El índice de la tabla de control correspondiente (externo).• Y después el índice particular de esta tabla.

• Indexación de tablas por filtro de tiempo.– El gestor hace un sondeo periódicamente a las sondas para obtener valores

de las tablas (monitorización).– Con un filtro de tiempo se devuelve únicamente los valores que han

cambiado desde un instante determinado en la misma petición GetRequest.– Para implementar esto se crea un índice en la tabla de datos formado por:

• Timestamp: marca de tiempo (sysUptime) de la última vez que se actualizó un determinado parámetros (entrada en la tabla).

• Index: índice que identifica de forma única el parámetros que se monitoriza.