Asignatura: Redes II

Conferencia 14: Modelo de gestión

TCP/IP
MSc. Lídice Romero Amondaray
Profesor Auxiliar
Bibliografía
 Tema 2
 Bibliografía básica.
 SNMP, SNMPv2M snmpV3 AND rmon 1 AND 2. 3ª edition.
William Stallings. Addison Wesley. 1999.
 Bibliografía Complementaria.
 Network Management Standards. 2ª edition. Uyless Black.
McGrawHill.
 Network Management, a practical perspective. Allan Leinwand,
Karen Fang. Addison Wesley. 1993.
 Communication Network Management. Kornel Terplan. Prentice
Hall. 1992.
Conferencia 6: Evolución de los
sistemas de gestión
 Objetivos:
 Que el estudiante domine los modelos de datos y
comunicaciones para la gestión en redes IP.
Modelo de gestión Internet.
 Premisas de diseño
 Modelo simple
 Axioma fundamental: Si la gestión de red es esencial
entonces debe ser implantada en todos los recursos de red.
 Por eso es simple, para que quepa en un equipo grande
(Router) o en uno pequeño (Modem barato)
 Consecuencia:
 El impacto de añadir gestión en los nodos de red debe ser el
mínimo posible.
 La complejidad algorítmica y de comunicaciones debe recaer en
los procesos gestores.
Gestión Internet. Historia
 La primera herramienta para gestión de Internet fue
ICMP (Internet Control Message Protocol)
 Mensajes de control entre routers y hosts
 Gestión en ICMP: mensajes de petición/respuesta de eco
 Se puede comprobar la conectividad y estimar retardos y
fiabilidad de una ruta en la red
 Programas PING (Packet Internet Groper) y traceroute
 Al final de los 80 Internet crece explosivamente
 En 1987 se propone SGMP (Simple Gateway Monitoring
Protocol): para monitorizar routers
Gestión Internet. Historia
 1988: en un ámbito más general se proponen dos
aproximaciones:
 Simple Network Management Protocol (SNMP):
 Versión extendida de SGMP
 A corto plazo
 CMIP over TCP/IP (CMOT): intento de incorporar a TCP/IP
el protocolo CMIP* en desarrollo en ISO/OSI
 Solución “definitiva” para el largo plazo (cuando OSI se
impusiera)
 Para facilitar la convergencia: utilizarían una misma base de
datos para los objetos gestionados
 La evolución de SNMP es comparable a la de TCP/IP:
 SNMP se ha impuesto mientras CMOT languidece
Gestión Internet. Historia
 SNMP se estandariza en los años 90/91, y aunque era
una solución simple a corto plazo, el retraso en la
aparición de redes OSI y la gran cantidad de redes
TCP/IP, le augura una larga vida, mientras que los
trabajos en CMOT se ralentizan.
 Actualmente es un estándar utilizado universalmente
y se está ampliando a todo tipo de redes (no sólo
TCP/IP) incluido OSI.
 Durante su historia ha ido evolucionado desde el
estándar simple original. Las principales extensiones
aumentan su funcionalidad y cubren problemas de
seguridad detectados en el protocolo original.
Gestión Internet. Evolución
 Una vez se generaliza el uso de SNMP, se proponen
diversas ampliaciones
 La ampliación de SNMP más importante fue RMON
(Remote Monitor)
 RMON: permite monitorizar globalmente una subred, no
sólo sus dispositivos
 Se han propuesto muchísimas extensiones a la MIB inicial
de SNMP: algunas estándar y otras privadas.
 Algunas deficiencias de SNMP se intentan resolver con
SNMPv2 y SNMPv3.
Estándares de SNMP
 3 Full Standards:
 RFC 1155(STD 16): Estructura e identificación de la información
de gestión para Internets basadas en TCP/IP. Mayo de 1990.
 Define como se definen en la MIB los objetos gestionados.
 RFC 1157 (STD 15): A Simple Network Management Protocol
(SNMP). Mayo de 1990.
 Define el protocolo para gestionar los objetos.
 RFC 1213 (STD 17): Management Information Base para gestión
de red en Internets basadas en TCP/IP:Ñ MIB-II. Marzo de 1991
 describe los objetos almacenados en la MIB.
 1 Draft Standard
 20 Proposed Standards
 4 Experimental Standards: entre ellos SNMP sobre OSI
 2 Informational
Arquitectura
 Estructura clásica ya vista:
 Estación de gestión
 Agentes de gestión (incluidos agentes proxy)
 Base de información de gestión (MIB)
 Protocolo de gestión de red
 Elementos del modelo de gestión
 Estación gestora
 Sirve como interfaz entre el gestor humano y el sistema
de gestión de la red
 Contiene:
 Aplicaciones de gestión para análisis de datos,
recuperación de fallos, etc.
 Interfaz (gráfico) para monitorización y control de la red
 Traducción de las peticiones del gestor en órdenes
Normalizadas concretas para la monitorización y control de los
por SNMP dispositivos de remotos
 Base de datos de información extraída de las MIB de todas
los dispositivos gestionados.
Elementos del modelo de gestión
 Agente
 los dispositivos de la red (hosts, puentes, routers
y hubs) pueden tener agentes SNMP
 responden a órdenes de la estación gestora y de
forma asíncrona le envían información importante
no solicitada (traps)
Elementos del modelo de gestión
 Base de información de gestión (MIB: Management
Information Base)
 Los recursos de la red que se pueden gestionar (monitorizar y
controlar) se representan mediante objetos
 Aunque se denominan objetos son básicamente variables.
 Colección de objetos = MIB
 Se almacenan en los dispositivos gestionados
 Los MIB forman un conjunto de puntos de acceso a los
dispositivos desde la estación gestora
 Los objetos están estandarizados para una clase concreta (p.e.,
se usa un mismo tipo de objetos para gestionar varios puentes)
Elementos del modelo de gestión
 Protocolo de gestión de red
 La estación gestora y los agentes se comunican
utilizando un protocolo
 En las redes TCP/IP este protocolo es SNMP
 Incluye las siguientes capacidades:
 get : la estación gestora extrae (lee) el valor de un objeto
del agente
 set : la estación gestora fija (escribe) el valor de un objeto
del agente
 trap: permite a un agente notificar a la estación gestora
eventos significativos
Entorno de gestión. SNMP y
UDP
Funcionamiento SNMP
Trap-directed polling
 Si una estación gestora es responsable de un gran número de
agentes y cada agente mantiene un gran número de objetos no es
práctico que la estación gestora sondee todos sus agentes y todos
sus objetos
 Se utiliza trap-directed polling
 La estación gestora realiza un sondeo inicial y a intervalos poco
frecuentes (horas) para recoger información clave (características
del interfaz y estadísticas básicas)
 Cada agente notifica a la estación gestora los eventos no usuales
(p.e., el agente cae y se reactiva, un enlace falla, condición de
sobrecarga).
 La comunicación de estos eventos se realiza mediante traps
 Una vez alertada, la estación gestora puede iniciar una consulta
sobre el agente para diagnosticar el problema
Proxies
 En una situación ideal todos los componentes de la red incluyen un
agente SNMP
 A veces esto no es posible:
 Hay componente antiguos que no soportan SNMP
 Hay sistemas muy pequeños que se sobrecargarían excesivamente con
el agente SNMP (por ejemplo: módems)
 Para estos casos, uno de los agentes en la configuración hace de
proxy para uno o varios componentes
 Cuando un nodo hace de proxy, actúa de parte de otro u otros
 Si un gestor quiere información de (o controlar a) ese componente
tiene que comunicarse con su proxy
 El agente proxy traduce la petición del gestor a la forma adecuada
para el nodo en cuestión
Proxies
 Algunos puentes, módems, etc. no soportan los protocolos
TCP/IP y SNMP
 Algunos sistemas pequeños (PCs, controladores programables)
tienen TCP/IP para sus aplicaciones, pero no se quiere cargarlos
con SNMP, el agente, y el mantenimiento del MIB
Información para la gestión
 La gestión en TCP/IP se basa en el manejo de una “base de
datos” que contiene la información de los elementos a gestionar
 En TCP/IP (igual que en OSI) la base de datos se denomina
MIB (Management Information Base)
 Cada recurso gestionable es un objeto (variable)
 La MIB es una colección de objetos con estructura de árbol
 Cada sistema mantiene una MIB con información sobre sus
propios recursos
 La estación gestora monitoriza los recursos de la red leyendo
los valores de los objetos en la MIB y puede controlar los
recursos modificando esos valores
Estructura de la información de
gestión (SMI). Necesidad
 El objeto usado para representar un recurso particular debe
ser el mismo en todos los sistemas
 Ejemplo:
 El número de conexiones TCP abiertas en un periodo:
conexiones abiertas = conexiones pasivas + conexiones activas
 Basta con almacenar dos de los tres
 La definición de MIB especifica que se deben almacenar las conexiones
pasivas y activas
 Se definen los objetos tcpActiveOpens y tcpPassiveOpens
 Ocupan las posiciones en el árbol 1.3.6.1.2.1.6.5 y 1.3.6.1.2.1.6.6
 Son de tipo counter (entero 32 bits)
 Debe utilizarse un esquema de representación común
(estándar) para soportar la interoperabilidad
SMI: Tipos de datos
 Los tipos de datos que se usan en SNMP están basados en los de
ASN.1 (Abstract Syntax Notation One)
 ASN.1 es un lenguaje que se utiliza para definir estructuras de
datos
 Incluye unas reglas precisas de codificación (BER: Basic Encoding
Rules)
 Proviene de OSI: al igual que buena parte de OSI es grande,
complejo y no muy eficiente
 Podrían valer las definiciones de C, pero carecen de una
codificación en bits estandarizada:
 Por ejemplo: para que una estación de 32 bits, little endian de
complemento a 2 pueda comunicarse con otra de 16 bits, big endian y
complemento a uno
SMI: Tipos de datos
 Todos los tipos ASN.1 (excepto CHOICE y ANY),
tienen una etiqueta asociada
 La etiqueta consiste del nombre de la clase y un
número no negativo
 Hay cuatro clases de tipos de datos en ASN.1:
 UNIVERSAL: tipos básicos de ASN.1 (independientes de
la aplicación)
 APPLICATION: relevantes a una aplicación particular
(por ejemplo, SNMP)
 CONTEXT-SPECIFIC: igual que antes pero aplicables en
un contexto limitado
 PRIVATE: definidos por los usuarios. No estandarizados
SMI: Tipos de datos universales
 Los tipos de la clase UNIVERSAL de ASN.1 que se
usan en SNMP son
Nombre Etiqueta
INTEGER UNIVERSAL 2
OCTETSTRING UNIVERSAL 4
NULL UNIVERSAL 5
OBJECT IDENTIFIER UNIVERSAL 6
SEQUENCE,SEQUENCE-OF UNIVERSAL 16
 En ASN.1 hay más: BOOLEAN, ENUMERATED,
REAL, SET, ... pero no se usan en SNMP
SMI: Tipos de datos universales
 INTEGER
 32 bits en complemento a dos
 Una variable de este tipo puede adoptar cualquier
valor entero, pero se puede limitar
 Por ejemplo:
cuenta INTEGER ::= 100 -- valor inicial opcional
Estado ::= INTEGER {up(1), down(2), unknown(3)} -- subtipo
PacketSize ::= INTEGER {0..1023} --subtipo
SMI: Tipos de datos universales
 OCTETSTRING: Cadena de octetos. Puede definirse
la longitud de la cadena y un valor inicial
 Se utiliza también DisplayString que es equivalente
pero sólo puede contener caracteres NVT ASCII
(máximo 255 caracteres)
 Casi toda la información de gestión que representa
un texto es de este tipo
 También PhysAddress es equivalente. El objeto
SNMP ifPhysAddress es de este tipo
SMI: Tipos de datos universales
 OBJECT IDENTIFIER: Para identificar y describir objetos
SNMP
 El identificador del objeto es una secuencia de números que
determina una posición dentro de la estructura de árbol
 Por ejemplo, el identificador del objeto tcpConnTable es el
1.3.6.1.2.1.6.13

iso(1).org(3).dod(6).internet(1).mgmt(2).mib-(1).tcp(6).tcpConnTable(13)

 SEQUENCE es una lista ordenada de tipos (parecido a una

estructura en C o un registro en Pascal)
 SEQUENCE-OF es un vector de una sola dimensión de un solo
tipo
SMI: Tipos de datos de
aplicación
 Corresponden a la clase APPLICATION de
ASN.1, son tipos de datos relevantes para una
aplicación particular
 En SNMP se definen tipos de datos propios
dentro de la clase APPLICATION
 EL RFC 1155 define los siguientes tipos:
 networkaddress
 Definido mediante la construcción CHOICE
 Actualmente la única dirección definida es IpAddress
 Se ha eliminado en SNMPv2
SMI: Tipos de datos de
aplicación
 ipaddress
 Direcciones de 32 bits, formato IP. Es un OCTETSTRING
de 4 bytes
 counter
 Entero no negativo de 32 bits (valor máximo: 232 - 1)
 Puede ser incrementado pero no decrementado
 Cuando el contador alcanza su máximo, vuelve a cero
 Ejemplos de aplicación:
 contar el número de paquetes u octetos enviados o recibidos
 contar el número de errores de un cierto tipo
SMI: Tipos de datos de
aplicación
 gauge
 Entero no negativo de 32 bits (valor máximo: 232 - 1)
 Puede ser incrementado o decrementado
 Cuando el contador alcanza su máximo se queda
bloqueado en este valor
 Ejemplos de aplicación:
 el número de paquetes almacenados en una cola en un
instante
 almacenar la diferencia en el valor de algo desde el principio
al final de un intervalo de tiempo
SMI: Tipos de datos de
aplicación
 timeticks
 Entero no negativo de 32 bits
 Cuenta el tiempo en centésimas de segundo (valor
máximo 497 días)
 opaque
 este tipo tiene la capacidad de pasar datos arbitrarios
 prácticamente no se utiliza
SMI: Tipos de datos en SNMPv2
 Nuevos tipos en SNMPv2:
 integer32: igual que INTEGER
 counter32: igual que counter
 gauge32: igual que gauge
 unsigned32: igual que gauge
 counter64: de 0 hasta 18446744073709551615
SMI: definición de la estructura
 SMI: Structure of Management Information (RFC
1155)
 Basada en ASN.1
 Consiste en:
 una técnica estándar para definir la estructura de una MIB
 una técnica estándar para definir objetos individuales
(sintaxis y su valor)
 una técnica estándar para codificar los valores de los objetos
 Una MIB sólo puede almacenar datos de dos tipos:
 escalares
 matrices bidimensionales de escalares
SMI: definición de la estructura
 Estructura en forma de árbol
 Los objetos forman las hojas del árbol: representan un recurso,
una actividad o una información relacionada
 Dentro del árbol, los objetos se agrupan en grupos (ramas)
relacionados
 Grupos de objetos IP, grupos de objetos TCP, ...
 A cada objeto de una MIB se le asocia un identificador del tipo
ASN.1 OBJECT IDENTIFIER
 Como el valor asociado con el tipo OBJECT IDENTIFIER es
jerárquico: secuencia de enteros. Ej: 1.3.6.1.4.1.9.1.25
 El nombre sirve también para identificar la posición que ocupa
el objeto dentro del árbol
SMI: definición de la estructura
 Tres nodos en el primer nivel: iso, ccitt y
joint-iso-ccitt
 Dentro del nodo iso hay un subárbol para las
organizaciones org y dentro de éste un
subárbol para el Department of Defense de
USA
SMI: definición de la estructura

 internet es un nodo que cuelga de dod:

 Se puede identificar mediante {iso (1) org (3) dod
(6) internet (1)} o simplemente 1.3.6.1
 Este valor sirve como prefijo de los nodos en niveles
inferiores
 SMI
 SMI define cuatro nodos bajo el nodo
internet
 directory: “reservado para uso futuro en el
directorio OSI (X.500)”
 mgmt: se usa para objetos definidos en
documentos aprobados por IAB
 experimental: se usa para identificar objetos en
experimentos sobre Internet
 private: se usa para identificar objetos
definidos unilateralmente (empresas)
 Objeto mgmt:
{iso (1) org (3) dod (6) internet (1) mgmt(2) } o
1.3.6.1.2
SMI: Definición de objetos
 Cada objeto dentro de una MIB de SNMP tiene
una definición formal
 La definición especifica:
 el tipo de datos del objeto
 el rango de valores que puede tomar
 su relación con otros objetos de la MIB (su posición
dentro del árbol)
 Se usa la sintaxis ASN.1
 RFC 1155 (Structure of Management Information) y
RFC 1212 (Concise MIB Definitions)
Definición de objetos
 Un ejemplo:
tcpMaxConn OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION
“Límite de conexiones TCP que la entidad puede
soportar. Si el número máximo de conexiones es
dinámico este objeto debe contener el valor -1”
:: = { tcp 4 }
Definición de objetos
 SYNTAX: tipo de datos
 corresponde a un tipo universales (INTEGER, OCTETSTRING,
…) o un tipo de aplicación de SNMP (counter, gauge, …)
 ACCESS: modo de acceso a una instancia del objeto:
readonly, read-write, write-only, not-accessible
 STATUS: define si este objeto debe ser necesariamente
incluido en la implementación de la MIB
 mandatory, optional, obsolete, deprecated
 DescrPart: descripción del objeto (opcional). Dirigido al
usuario
 Finalmente, se indica la posición del objeto dentro del árbol
Definición de objetos
 Otro ejemplo:
sysDescr OBJECT-TYPE
SYNTAX DisplayString (SIZE (0..255))
ACCESS read-only
STATUS mandatory
DESCRIPTION
"A textual description of the entity. This value should include the
full name and version identification of the system's hardware
type, software operating-system, and networking software. It is
mandatory that this only contain printable ASCII characters."
::= { system 1 }
Definición de objetos
 Uno más:
lostPackets OBJECT-TYPE
SYNTAX counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Cantidad de paquetes perdidos desde la última
activación"
:: = {experimental 20 }
Macro: RFC 1212
Macro: RFC 1212
(Continuación)
Macro: RFC 1212
 ReferPart: referencia cruzada textual a un objeto
definido en otro módulo MIB (opcional)
 IndexPart: usado para definir tablas. Esta cláusula
estará presente si el tipo de objeto describe una fila
de una tabla
 DefValPart: define un valor por defecto que se usa
cuando se crea una instancia del objeto (opcional)
 VALUE NOTATION: indica el nombre que se usa
para acceder a este objeto vía SNMP
SMI: Definición de tablas
 SMI sólo soporta una forma de estructurar los datos:
una tabla de dos dimensiones de valores escalares
 Ejemplo: objeto tcpConnTable (1.3.6.1.2.1.6.13)
contiene información sobre las conexiones TCP de un
dispositivo
 Para cada conexión, la tabla mantiene esta información:
 State: uno de los 11 estados TCP + 1
 Local address: dirección IP local
 Local port: puerto TCP local
 Remote address: dirección IP remota
 Remote port: puerto TCP remoto
Ejemplo tablas: tcpConnTable
Ejemplo tablas: tcpConnTable
Ejemplo tablas: tcpConnTable
Ejemplo tablas: tcpConnTable
Ejemplo tablas: tcpConnTable
Ejemplo tablas: tcpConnTable
Ejemplo tablas: ifTable
Ejemplo tablas: ifTable
Ejemplo tablas: ifTable
Ejemplo tablas: ifTable
Ejemplo tablas: ifTable
MIBs privadas
 Los fabricantes pueden crear objetos específicos para gestionar
sus productos
 El uso de SMI y un esquema de identificadores de objetos
estándar permite que se pueda acceder fácilmente a esos objetos
 Se cargan dentro de subárbol private (1.3.6.4.1) y más
concretamente dentro de la rama enterprises (1.3.6.1.4.1)
 Una estación gestora solo puede acceder a la información cuya
existencia conoce y sobre la que puede preguntar
 Para que la estación gestora pueda gestionar objetos MIB
privados, su estructura debe ser cargada en la estación gestora
 Algunos fabricantes proporcionan una descripción formal de su
MIB en texto
MIB-II (RFC 1213 )
 El grupo mib-2 se subdivide en los siguientes grupos
 system: información general del sistema
 interfaces: interfaces de red del sistema
 at: (deprecated: reemplazado)
 ip: implementación y ejecución de IP en el sistema
 icmp: implementación y ejecución de ICMP en el sistema
 tcp: implementación y ejecución de TCP en el sistema
 udp: implementación y ejecución de UCP en el sistema
 egp: implementación y ejecución de EGP en el sistema (no
se utiliza)
 dot3: esquemas de transmisión y protocolos de acceso
 snmp: implementación y ejecución de SNMP en el sistema
Grupo system
 Grupo system
 sysDescr RO DisplayString(SIZE(0...255))
 sysObjectID RO OBJECT IDENTIFIER
 sysUpTime RO TimeTicks
 sysContact RW DisplayString(SIZE(0...255))
 sysName RW DisplayString(SIZE(0...255))
 sysLocation RW DisplayString(SIZE(0...255))
 sysServices RO INTEGER(0...127)
Grupo system
 sysDescr: descripción dispositivo
 sysObjectID: identifica el agente software
 formato: 1.3.6.1.4.1.ve.vs.vs
 ve: número de la empresa
 vs: código específico del producto
 Ejemplo: El router 2509 de Cisco (ve = 9) 1.3.6.1.4.1.9.1.25
 sysUpTime: tiempo de funcionamiento del agente
 sysContact: datos de la persona responsable de
gestionar este dispositivo
Grupo system
 sysName: nombre del dispositivo
 sysLocation: ubicación del dispositivo
 sysServices: binario 7 bits: cada bit corresponde a
un nivel en la arquitectura OSI:
1 físico (repetidores)
2 enlace de datos (puentes)
3 internet (router IP)
4 transporte (hosts TCP)
7 aplicaciones
 Grupo interfaces
 Grupo interfaces: información sobre las interfaces del sistema
ifNumber RO INTEGER -- núm. De interfaces
ifTable NA SEQUENCE OF ifEntry
ifEntry NA SEQUENCE
ifIndex RO INTEGER
ifDescr RO DisplayString(SIZE (0...255))
ifType RO INTEGER
IfPhysAddressRO PhysAddress
Ifspeed RO Gauge
IfInOctets RO Counter
IfOutOctets RO Counter
...
Grupo interfaces
 ifDescr: descripción de la interfaz
 ifType: tipo de interfaz
 p.e.: 6 = ethernetCsmacd
 ifMtu: la MTU en bytes
 ifSpeed: velocidad de transmisión en bits/s
 ifPhysAddress: dirección física (MAC)
 ifAdminstatus: up (1), down (2), testing (3)
 ifInOctets: número de octetos recibidos
 ifOutOctets: número de octetos transmitidos
 IfSpecific: ha sido eliminado en RFC1573
Grupo interfaces
 Expresiones útiles con objetos de la ifTable
 Para que el valor de un contador sea útil
necesitamos dos muestras:
 una para tener un punto de referencia
 otra para calcular el cambio producido
  es la diferencia entre los valores de un
contador en dos intervalos de tiempo
 Para calcular  (segundos) se debe consultar
sysUpTime
Grupo interfaces
 Utilización de entrada de un interfaz

 Utilización de salida de un interfaz

 Utilización de un segmento Ethernet

Grupo interfaces
 Detección de problemas de congestión

 Detección de problemas en el hw o en la
línea
Grupo ip
 ipForwarding: forwarding (1)
not-forwarding (2)
 ipDefaultTTL: TTL por defecto
 ipReasmTimeout: valor en seg.
del timeout para reensamblar
Grupo ip
 Monitorizando estos objetos podemos identificar:
 gran núm. de paquetes fragmentados (problemas con la
MTU)
 gran núm. de reensamblados (problemas con la MTU)
 gran núm. de paquetes sin ruta (problemas de
encaminamiento)
 alto porcentaje de fallos de reensamblado (fragmentos
corruptos o limitación de recursos)
 alto porcentaje de fallos de fragmentación (el dispositivo
está configurado para activar el flag “Don’t Fragment”)
Grupo ip
 Algunas expresiones útiles para detectar
problemas de encaminamiento
Grupo icmp
 Que se envíen o reciban un cierto número de
paquetes ICMP no es señal de problemas
 Pero, puede ser un indicador de problemas
cuando...
 un dispositivo recibe muchos paquetes ICMP de
error comparado con el número de paquetes que
transmite
 un dispositivo genera muchos paquetes ICMP de
error comparado con los paquetes que recibe
Grupo icmp
 Las siguientes relaciones pueden ayudar:
Grupo tcp
 tcpRtoAlgorithm: algoritmo para el cálculo del timeout de
retransmisión: other (1), constant (2), rsre (3), vanj (4)
 tcpRtoMin : timeout mínimo
 tcpRtoMax : timeout máximo
 tcpMaxConn: número máximo de conexiones TCP
 tcpActiveOpens: conexiones que pasan del estado CLOSED a
SYN-SENT
 tcpPassiveOpens: conexiones que pasan del estado LISTEN a
SYN-RCVD
 tcpAttemptFails: intentos de conexión fallidos
 tcpCurrentEstab: conexiones actuales
 tcpEstabResets: conexiones “reseteadas”
El protocolo SNMP
 El SNMP = Simple Network Management Protocol
está especificado en el RFC 1157 (Mayo, 1990)
 Protocolo de aplicación que pueden inspeccionar o
alterar las variables del MIB de un agente.
 Define una arquitectura basada en el modelo
cliente/servidor.
 El cliente (gestor) realiza conexiones virtuales a un
servidor (agente) ejecutado en un dispositivo remoto
de red.
El protocolo SNMP
 Operaciones de SNMP:
 Get: una estación gestora solicita el valor de un
objeto escalar de la estación gestionada
 Set: una estación gestora fija el valor de un objeto
escalar en la estación gestionada
 Trap: la estación gestionada envía el valor de un
objeto escalar no solicitado a la estación gestora
Comunidades
 Cada agente SNMP es responsable de su MIB local
y controla el uso que hacen de esa MIB las
estaciones gestoras
 Los agentes definen una o varias comunidades que
se caracterizan por una política de acceso
 Las estaciones gestoras deben proporcionar el
nombre de comunidad en todas sus interacciones
con la estación gestionada
 Este nombre hace el papel de palabra clave
Servicio de autenticación
 Este esquema de autenticación es muy elemental
 Muchos sistemas sólo permiten la monitorización:
operaciones Get y Trap
 Hay esquemas más sofisticados, pero fuera del estándar
RFC 1157
 Política de acceso: Para cada comunidad se definen
dos aspectos
 Vista de la MIB: subconjunto de la MIB
 Modo de acceso a la MIB: READ-ONLY o READ-WRITE
 En la definición de los objetos de una MIB también se incluye
el campo ACCESS. Hay que combinarlos
Identificación del objeto
 Se identifica una instancia del objeto (su
valor)
 Objetos escalares: por consistencia con los
objetos tabulares, SNMP exige que el
identificador de una instancia de un objeto
escalar sea el identificador del objeto
concatenado con 0
 Ejemplos:
Identificación del objeto
 Objetos columna
 Objetos que aparecen dentro de una tabla
 El identificador del objeto no es suficiente para
identificar la instancia
 Hay una instancia de ese objeto para cada fila de la
tabla
 Dos técnicas para identificar una instancia
específica de un objeto :
 técnica de acceso serie (en orden léxico-gráfico)
 técnica de acceso aleatorio
Identificación del objeto

 Hay diez instancias de tcpConnState, todas tienen el mismo

identificador de objeto: 1.3.6.1.2.1.6.13.1.1
 Se utilizan los valores de lo objetos INDEX (ver en la figura) para
distinguir entre una fila u otra
 Se concatena el identificador del objeto con INDEX.
Ejemplo:
1.3.6.1.2.1.6.13.1.1.158.42.53.1.1215.158.42.57.128.21
Formatos SNMP
Formatos SNMP

Versión del prtotocolo. La

RFC 1157 es la versión 1
Formatos SNMP

el “password”
Formatos SNMP

Tipo de mensaje SNMP:

GetRequest (0),
GetNextRequest (1),
GetResponse (2),
SetRequest (3),
Trap (4)
Formatos SNMP

Entero que indica el orden de

emisión de los datagramas.
Este parámetro sirve también
para identificar datagramas
duplicados en los servicios de
datagramas poco fiables.
Formatos SNMP

Entero que indica si ha

existido un error. Puede
tomar los siguientes valores:
noError(0), tooBig(1),
noSuchName(2),
badValue(3), readOnly(4),
genErr(5)
Formatos SNMP

entero que en caso de

error indica qué variable
de una lista ha generado
ese error
Formatos SNMP

Lista de nombres de
variables con su valor
asociado. Algunas PDU
quedan definidas sólo con
los nombres, pero aún así
deben llevar valores
asociados. En algunos
casos (GetRequest) los
valores son nulos
Formatos SNMP

Tipo de
dispositivo que
genera el trap
(basado en
sysObjectID)
Formatos SNMP

Dirección del
dispositivo que
genera el trap
Formatos SNMP

Entero que indica el tipo de trap.

Puede tomar los siguientes valores:
coldStart(0), warmStart(1),
linkDown(2), linkUp(3),
authenticationFailure(4),
egpNeighborLoss(5),
enterpriseSpecific(6)
Formatos SNMP

Entero con
código de trap
específica
Formatos SNMP

Tiempo desde la última

inicialización de la
entidad de red y la
generación del trap.
Valor de sysUpTime
Formatos SNMP

Lista tipo varBindList con

información de posible
interés
Secuencias SNMP
PDU GetRequest
 La genera una estación gestora
 Incluye la siguiente información:

 Se pueden solicitar los valores de varias variables

 Es una operación atómica: o se da respuesta a todos los
valores de las variables o no se da ninguno
PDU GetResponse
 La respuesta a un GetRequest es un GetResponse con
idéntico request-id

 Si hay error: GetResponse con error-status ≠ 0

 Códigos de error:
 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
PDU GetNextRequest
 Tiene el mismo formato que GetRequest
 También es una operación atómica
 Con la diferencia:
 Para cada objeto en la lista variablebindings se solicita que
se responda con el valor de la siguiente instancia de objeto
en orden léxico-gráfico (dentro de la vista)
 Diferencia pequeña pero importante:
 Permite a la estación gestora descubrir la estructura de una
MIB dinámicamente
 Ofrece un mecanismo para buscar en una tabla cuyas
entradas son desconocidas
Orden léxico-gráfico. Ejemplo
Orden léxico-gráfico. Ejemplo
Orden léxico-gráfico. Ejemplo
PDU GetNextRequest
 El gestor quiere obtener todos los valores de todos los
objetos simples del grupo udp:
GetRequest (udpInDatagrams.0, udpNoPorts.0, udpInErrors.0,
udpOutDatagrams.0)
GetResponse ((udpInDatagrams.0=100), (udpNoPorts.0=1),
(udpInErrors.0=2), (udpOutDatagrams.0=200))
 Si uno de estos objetos no está soportado en la MIB del
agente obtendremos un GetResponse con el código de error
noSuchName y no obtendremos ningún valor.
PDU GetNextRequest
 Supongamos que usamos la PDU GetNextRequest de
la siguiente manera:

GetNextRequest (udpInDatagrams.0, udpNoPorts.0,

udpInErrors.0, udpOutDatagrams.0)

 Si suponemos que el objeto udpNoPorts no está

soportado (o no es visible), para la misma petición
obtendríamos la respuesta

GetResponse ((udpInDatagrams.0=100), (udpInErrors.0=2),

(udpInErrors.0=2), (udpOutDatagrams.0=200))
 PDU GetNextRequest

 La estación gestora quiere leer la tabla completa y no

conoce su contenido (ni el número de filas)
GetNextRequest ( ipRouteDest, ipRouteMetric1, ipRouteNextHop )
GetResponse ( ipRouteDest.9.1.2.3 = 9.1.2.3,
ipRouteMetric1.9.1.2.3 = 3,
ipRouteNextHop.9.1.2.3= 99.0.0.3 )
GetNextRequest ( ipRouteDest.9.1.2.3, ipRouteMetric1.9.1.2.3,
ipRouteNextHop.9.1.2.3)
GetResponse ( ipRouteDest.10.0.0.51 = 10.0.0.51,
ipRouteMetric1.10.0.0.51 = 5,
ipRouteNextHop. 10.0.0.51 = 89.1.1.42 )
PDU GetNextRequest

GetNextRequest ( ipRouteDest.10.0.0.51 ,
ipRouteMetric1.10.0.0.51 ,
ipRouteNextHop.10.0.0.51 )
GetResponse ( ipRouteDest.10.0.0.99 = 10.0.0.99,
ipRouteMetric1.10.0.0.99 = 5,
ipRouteNextHop. 10.0.0.99 = 89.1.1.42 )
GetNextRequest ( ipRouteDest.10.0.0.99 ,
ipRouteMetric1.10.0.0.99 ,
ipRouteNextHop.10.0.0.99 )
GetResponse (ipRouteMetric1.9.1.2.3 = 3,
ipRouteNextHop.9.1.2.3 = 99.0.0.3,
ipNetToMediaIfIndex.1.158.42.1.8 =00.60.97.B4.EE.83 )
PDU SetRequest

 Igual que GetRequest pero escribe en vez de leer

 Se contesta con un GetResponse con el mismo
request-id
 Es una operación atómica: o se actualizan todos los
valores o no se actualiza ninguno
 La respuesta puede contener los mismos códigos de
error que en el caso de GetRequest (noSuchName,
tooBig, genErr) más uno adicional:
 badValue para indicar que el SetRequest es inconsistente
con el tipo, la longitud o valor de la variable
PDU SetRequest
 Actualizando tablas:
 Supongamos que en la tabla que estamos usando queremos
cambiar la métrica de la primera entrada:
SetRequest (ipRouteMetricl.9.1.2.3 = 9)
 La respuesta sería:

GetResponse (ipRouteMetricl.9.1.2.3 = 9)
 Ahora supongamos ahora que la estación desea agregar una
nueva fila, y para ello envía:
SetRequest ((ipRouteDest.11.3.3.12 = 11.3.3.12),
(ipRouteMetricl.11.3.3.12 = 9),
(ipRouteNextHop.11.3.3.12 = 91.0.0.5))
PDU SetRequest
 Actualizando tablas (cont):
 El objeto columna ipRouteDest en un índice de la tabla.
 Si se le quiere asignar el valor 11.3.3.12, el identificador
de la instancia debe ser ipRouteDest.11.3.3.12.
 Pero este identificador es actualmente desconocido por
el agente.
PDU SetRequest
 Actualizando tablas (cont):
 La manera de proceder por parte del agente debe ser:
1. Puede rechazar la operación y devolver un GetResponse con un error-status de
noSuchName.
2. Puede aceptar la operación pero encontrar que uno de los valores es
inapropiado debido a su sintaxis o su valor, y devolver un GetResponse con
un error-status de badValue.
3. Puede aceptar la operación y crear una nueva fila.

GetResponse ((ipRouteDest.11.3.3.12 = 11.3.3.12),

(ipRouteMetricl.11.3.3.12 = 9),
(ipRouteNextHop.11.3.3.12 = 91.0.0.5)
 SNMP no dictamina nada acerca de que debe hacer un agente
ante un pedido como el que estamos mencionando.
PDU SetRequest
 Borrado de una Fila
 El comando Set puede usarse para borrar una fila de una
tabla.
 Ejemplo para la tabla ipRouteTable , se proporciona el valor
de un objeto para este propósito. Si la estación de gestión
envía:
SetRequest (ipRouteType.7.3.5.3 = invalid)
 La respuesta apropiada será:

GetResponse (ipRouteDest.7.3.5.3 = invalid)

 El efecto de este intercambio es la eliminación lógica de la
fila en la tabla referenciada por un valor de ipRouteDest de
7.3.5.3.
PDU SetRequest
 Borrado de una Fila
 Dos de las tablas dentro de MIB-II tienen un objeto
columna específico para el borrado de una fila.
 Como vimos, una es la ipRouteTable que contiene el
objeto ipRouteType que puede adoptar el valor de
invalid.
 Lo mismo ocurre con la tabla ipNetToMediaTable y el
objeto ipNetToMediaType.
 Las otras tablas dentro de MIB-II no proporcionan un
método tan sencillo para borrar una fila
PDU Trap
 generic-trap:
 coldStart (0), reinicialización de la entidad SNMP (caída
sistema): la configuración del agente puede estar afectada
 warmStart (1), reinicialización de la entidad SNMP: la
configuración del agente no está afectada
 linkDown (2), fallo en uno de los enlaces de red del
agente. El primer elemento en variablebindings es el
nombre y valor del ifIndex de la interfaz referenciada
 linkUp (3), un enlace de red del agente activado
 authentication-Failure (4), el agente ha recibido un
mensaje del protocolo cuya autentificación no ha tenido
éxito
 egpNeighborLoss (5), pérdida de un vecino EGP
 enterprise-Specific (6), trap específica del fabricante
Soporte del nivel de transporte
 SNMP necesita de un nivel de transporte para
enviar los mensajes
 Utiliza UDP
 Los agentes escuchan en el puerto 161
 Las estaciones gestoras escuchan los Traps en
el puerto 162
El grupo SNMP
 Definido en la MIB-II contiene
información relevante para la
implementación y la operación de
SNMP
 Exceptuando el último objeto del
grupo, todos los demás son
contadores de sólo lectura
 snmpEnableAuthenTraps indica si
el agente está autorizado a generar
traps de fallo de autentificación
Limitaciones de SNMP
 SNMP no es adecuado para gestionar redes muy muy grandes (por
el sondeo)
 SNMP no es adecuado para recuperar grandes volúmenes de datos
 Posee traps no confirmados. Si se utiliza un servicio de transporte
no confiable como UDP, el agente no tiene seguridad sobre el
arribo de un mensaje crítico a la estación de gestión
 El estándar SNMP básico ofrece un mecanismo de autenticación
trivial (más adecuado para monitorizar que para controlar)
 SNMP no soporta directamente órdenes imperativas
 El modelo MIB es limitado
 SNMP no soporta la comunicación de gestor a gestor
Limitaciones de SNMP
 El mayor inconveniente de SNMP es su escasa
seguridad
 El nombre de comunidad en la cabecera de cada
mensaje SNMP no es suficiente
 Muchos fabricantes no implementan la orden Set, así
el sistema de gestión se convierte en un sistema de
monitorización
 ...
 Muchas de estas deficiencia se abordan en
SNMPv2 y v3
SNMPv2
 Además de la seguridad hay otras cuestiones mejorables:
eficiencia, comunicación gestor a gestor, etc.
 En 1992 se inicia el desarrollo de SNMPv2
 Se forman dos grupos de trabajo:
 Seguridad (propuesta Ene-93)
 Otros aspectos protocolo y SMI (propuesta Dic-92)
 RFCs 1441 al 1452
 En 1996, el IETF revisa la especificación y rechaza la
parte de seguridad (no la considera satisfactoria)
Los RFC de SNMPv2
1901 Introduction to Community-Based SNMPv2
1902 Structure of Management Information for NMPv2
1903 Textual Conventions for SNMPv2
1904 Conformance Statements for SNMPv2
1905 Protocol Operations for SNMPv2
1906 Transport Mappings for SNMPv2
1907 Management Information Base for SNMPv2
1908 Coexistence Between Version 1 and Version 2 of the
Internet-Standard Network Management Framework
SNMPv2: Novedades
 Novedades en SNMPv2:
 Se introduce la idea de que los gestores pueden
tener gestores de nivel superior: la gestión puede
ser jerárquica
 Cambios en la estructura de la información de
gestión (SMI)
 Capacidad de comunicación gestor a gestor
 Nuevas operaciones del protocolo
SMI en SNMPv2
 La SMI de SNMPv2 es un superconjunto de
la SMI de SNMPv1
 Hay nuevos tipos de datos
 Hay un nuevo mecanismo para añadir y
borrar filas de una tabla
 inspirado en RMON pero mucho más elaborado
Nuevos tipos de datos en SNMPv2
 Nuevos tipos en SNMPv2:
– integer32: igual que INTEGER
– counter32: igual que counter
– gauge32: igual que gauge
 unsigned32: igual que gauge
 counter64: de 0 hasta 8.446.744.073.709.551.615
La macro OBJECT-TYPE de
SNMPv2
Operaciones del protocolo
 En SNMPv2 hay tres interacciones básicas
para acceder a la información de gestión:
 Petición-respuesta gestor-agente: igual que en
SNMPv1
 Petición-respuesta gestor-gestor: nuevo en
SNMPv2
 Agente-gestor no confirmada: trap
Secuencias SNMPv2
Formatos SNMPv2
PDUs GetRequest y
GetNextRequest
 Iguales que en SNMPv1
 Salvo que ya NO son operaciones atómicas
 En la respuesta se devuelve el valor de las variables o
una indicación (noSuchObject, noSuchInstance,
endOfMibView) señalando por qué no se ha podido
obtener ese valor
 Para otro tipo de errores no hay respuesta a ninguna
variable
 La respuesta tiene el campo error-status = genErr, y en error-
index se indica el objeto del campo variablebindings que
causa el problema
PDU GetBulkRequest

 Se introduce para minimizar las operaciones necesarias

para leer una cantidad grande de datos. Por ejemplo: leer
una tabla con una sola operación
 GetBulkRequest incluye una lista de (N+R) nombres de
variables
 Para las primeras N funciona como GetNextRequest
 Para las últimas R devuelve M sucesores léxico-gráficos
 En total devuelve N + (M ×R) valores (máximo)
 Si la respuesta es demasiado grande, responde lo que
puede
Ejemplo
 Tabla ipNetToMediaTable
 Ejemplo

getBulkRequest [non-repeaters = 1, max-repetitions = 2]

(sysUpTime, ipNetToMediaPhysAddress,ipNetToMediaType)
Response( (sysUpTime.0 = “123456”),
(ipNetToMediaPhysAddress.1.9.2.3.4 = “000010543210”)
(ipNetToMediaType.1.9.2.3.4 = “dynamic”),
(ipNetToMediaPhysAddress.1.10.0.0.51 = “000010012345”)
(ipNetToMediaType.1.10.0.0.51 = “static”) )
 Ejemplo

getBulkRequest [non-repeaters = 1, max-repetitions = 2]

(sysUpTime, ipNetToMediaPhysAddress.1.10.0.0.51,
ipNetToMediaType.1.10.0.0.51 )
Response( (sysUpTime.0 = “123466”),
(ipNetToMediaPhysAddress.2.10.0.0.15 = “000010987654”)
(ipNetToMediaType.2.10.0.0.15 = “dynamic”),
(ipNetToMediaNetAddress.1.9.2.3.4 = “9.2.3.4”)
(ipRoutingDiscards.0 = “2”) )
PDU SetRequest
 Igual que SNMPv1
 Como en SNMPv1, es una operación atómica
 Sólo cambian los códigos de error en las
respuestas
 En SNMPv2, estos códigos dan más
información sobre el tipo de error
PDU Response
 Códigos de error
PDU SNMPv2-Trap
 El formato es diferente a SNMPv1

 El campo variable-bindings contiene la

información siguiente:
 sysUpTime.0
 snmpTrapOID.0 (forma parte del grupo snmpTrap de la
MIB de SNMPv2): indica el tipo de trap
 Una lista de variables
PDU InformRequest

 Paso de información de gestor a gestor

 El campo variable-bindings se inicializa
igual que en las traps variable-bindings
PDU type request-id 0 0
La MIB de SNMPv2
El grupo system
El grupo snmp
 Como el de la MIB-II pero con objetos
nuevos y algunos objetos eliminados
El grupo snmpMIBObjects
SNMPv3: Introducción
 SNMPv3 es una extensión de SNMP que aborda
especialmente dos aspectos:
 administración y seguridad
 Un objetivo principal de SNMPv3 es definir una
arquitectura modular que pueda ser fácilmente extendida
 Lo que llamábamos agentes y gestores SNMP ahora se
llaman entidades SNMP
 Entidad SNMP:
 motor SNMP
 aplicaciones SNMP
SNMPv3: arquitectura
SNMPv3: arquitectura
 Dispatcher:
 – Responsable de enviar y recibir mensajes
 – Cuando se recibe un mensaje:
 Determina la versión y lo pasa al Modelo de Procesamiento de
Mensajes adecuado
 Subsistema de procesamiento de mensajes
 Se compone de uno o varios Modelos de
Procesamiento de Mensajes
SNMPv3: arquitectura
 Se encarga de
 Preparar los mensajes que deben ser enviados
 Extraer los datos de los mensajes recibidos
 Ejemplo: el Dispatcher recibe un mensaje SNMPv3
válido y determina la versión: 3
 Lo envía al Modelo de Procesamiento de Mensajes
SNMPv3 donde se extrae el mensaje
 Éste llama al Subsistema de Seguridad para descifrarlo
(si es necesario) y autentificarlo
 Envía el mensaje a la aplicación adecuada
SNMPv3: arquitectura
 Subsistema de seguridad:
 Autentifica los mensajes
 Cifra/descifra los mensajes

 El Modelo de seguridad define:

 Qué amenazas a la seguridad protege
 Qué protocolos de seguridad se usan para ofrecer los
servicios
SNMPv3: arquitectura
 El modelo de seguridad SNMPv3 protege los mensajes
SNMPv3 frente las siguientes amenazas a la seguridad:
 Modificación de mensajes generados por un usuario autorizado
(por otro no autorizado)
 Suplantación de un usuario autorizado por otro no autorizado
 Modificación del flujo de mensajes.
 SNMP se basa en UDP. Los mensajes podrían ser capturados, reordenados,
retrasados y, posiblemente, reenviados en un instante posterior. Por ejemplo,
una operación Set podría ser capturada y reenviada más tarde
 Escuchas en la red.
 Si los mensajes están cifrados no tienen sentido para alguien que realiza
escuchas
SNMPv3: arquitectura
 El modelo de seguridad de SNMPv3 se basa
actualmente en:
 Protocolos de autenticación HMAC-MD5-96 y
HMAC-SHA-96:
 Verificar que el contenido del mensaje no ha sido
alterado
 Verificar la fuente del mensaje
 Protocolo de privacidad (cifrado) CBC-DES
(Cipher Block Chaining-Data Encrytion Standard)
SNMPv3: arquitectura
 Subsistema de control de acceso:
 determinar si se debe permitir o no el acceso a un objeto
de la MIB
 Actualmente sólo hay definido un modelo de control de
acceso: View-Based Access Control Model (VACM)
 Cuando se procesa una operación Get, Get-Next, Get-
Bulk o Set hay que comprobar que se tiene acceso a los
objetos referenciados
 Cuando se genera una Notificación (una Trap o Inform)
también hay que comprobar el acceso a las variables
SNMPv3: arquitectura
 Aplicaciones:
 Aplicaciones internas a la entidad SNMP: generar
mensajes SNMP, responder a mensajes SNMP
recibidos, generar notificaciones, recibir
notificaciones, etc.
Monitor remoto. RMON
 El monitoreo remoto de redes es la especificación más
importante que se puede agregar al conjunto SNMP, MIB-
II.
 La información que se obtiene con la MIB-II es local a
cada dispositivo gestionado
 No se tiene información sobre el tráfico global en una red
 Para esto se utiliza un monitor de red (analizador de red o
sonda) para recolectar y analizar los paquetes que pasan por
ellos.
 Estos monitores se comunican con una estación central de
gestión de la red: de ahí el nombre de monitores remotos.
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.
 Brinda información sobre la red misma, y no
sobre los dispositivos conectados a la red
como es el caso de MIB-II.
Ventajas de RMON para la Gestión
de Redes
 Operación off-line: permite recolectar
información en modo desconectado.
 Detección y reporte de fallos: detecta fallos
antes de que ocurran.
 Datos con valor agregado: realiza un análisis
de la información recolectada.
 Múltiples Gestores de red: interactúa con
múltiples gestores de red.
Operación off-line
 Si se produce un fallo en la conexión entre el
monitor RMON y la estación de gestión de red,
el monitor continua recolectando información a
cerca de la red (desempeño, tráfico, etc.).
 Cuando se restaura la conexión con el gestor, el
monitor envía la información requerida por éste.
 Recolecta información estadística sin necesidad
de que el gestor envíe constantemente pedidos
 Se reduce el tráfico de polling y el ancho de
banda.
Detección y reporte de fallos
 El monitoreo preventivo ofrece la posibilidad de
detectar una fallo antes de que éste ocurra. Esto se
logra mediante el análisis del desempeño y el
tráfico de la red.
 El monitor RMON se puede configurar 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.
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 monitor de red puede ser configurado para
que funcione correctamente con múltiples
gestores de red.
RMON
 Se define la sonda RMON (RMON probe) que
es todo sistema que implemente el uso de la
MIB RMON.
 La sonda RMON consta de:
 Un agente RMON, que no difiere de las
características de un agente SNMP,
 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.
Control de monitores remotos
 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 (Switch) consumiendo recursos de memoria y
de procedimiento para la función de gestión.
 Las tareas que debe realizar son más complejas que
un agente SNMP con MIB-II.
 La MIB de RMON soporta nuevas funciones:
 configuración
 invocación de acciones
Configuración
 Determina el tipo, el formato y la cantidad de
los datos que deben ser recolectados
 La MIB RMON está organizada en varios grupos
 Dentro de cada grupo hay una o más tablas de
control y una o más tablas de datos
 La tabla de control es (habitualmente) de lectura-
escritura, contiene parámetros que describen los
datos en la tabla de datos
 La tabla de datos es (generalmente) de sólo lectura
(la sonda es se encarga de escribir los datos).
Configuración
 En la fase de configuración, la estación gestora da
instrucciones al monitor remoto para que recolecte los
datos deseados
 Para esto añade una nueva fila a la tabla de control o
modificando una fila ya existente.
 La información se recolecta y almacena en varias filas
de las tablas de datos según la configuración descrita en
una fila de la tabla de control
 Cada fila de la tabla de control tiene asociadas varias filas en
una o varias tablas de datos
Configuración
 Para modificar un parámetro de la tabla de
control debe invalidarse la fila
correspondiente y crearse una nueva fila con
los valores requeridos.
 Al invalidarse la fila de la tabla de control se
eliminan automáticamente la fila de la tabla
de control y las filas asociadas en la tabla de
datos.
Invocación de acciones
 SNMP no tiene mecanismos para ordenar a un
agente que ejecute una determinada acción
 Sólo se pueden leer y escribir valores de objetos
definidos dentro de una MIB.
 Se puede hacer que mediante la orden Set se
envíe una orden: invocación de acción
 Se definen objetos que representan un comando
en lugar de información: al cambiar el valor del
objeto se ejecuta una acción específica.
Gestores múltiples
 Una sonda RMON puede ser gestionada desde varios
gestores
 Dificultades al compartir recursos:
1. Si las peticiones concurrentes de varios gestores a la vez
pueden exceder la capacidad del monitor de proporcionar los
datos solicitados.
2. Si una estación gestora captura y mantiene recursos del
monitor durante un tiempo excesivo puede provocar que otra
estación de trabajo no pueda acceder a los datos de gestión
por falta de recursos.
3. Se pueden asignar recursos del monitor a una estación
gestora que haya sufrido un fallo sin haber liberado estos
recursos.
Gestores múltiples
 Solución: cada tabla de control contiene una objeto
columna que identifica al propietario de cada fila en
particular.
1. Un gestor reconoce 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 funciones y puede
negociar por éstos para que sean liberados.
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á.
Gestores múltiples
 El estándar RMON sugiere que la etiqueta de
propietario contenga:
 dirección IP
 nombre de la estación gestora
 nombre del gestor de la red
 lugar donde se haya la estación
 nombre del administrador de red y el
 número telefónico.
Gestores múltiples
 La etiqueta de propietario no confiere ningún
tipo de seguridad sobre los objetos asociados
(no actúa como password)
 Los objetos pueden ser leídos, modificados y
borrados por cualquier gestor de red (con
permisos de lectura y escritura).
Gestores múltiples
 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.
 El propietario de la filas puede ser el propio
monitor, en cuyo caso las etiqueta de
propietario = monitor.
Gestión de las tablas
 En SNMPv1 no se especifica claramente los procedimientos para
agregar y borrar filas de una tabla.
 En RMON se han definido nuevas convenciones textuales
(textual conventions), que no contradicen la especificación
SNMPv1.
 Ayudan a definir en forma clara y ordenada la manera en que
deben agregarse y borrarse las filas de las tablas.
 OwnerString: es el tipo de dato que se asocia al objeto que indica el
propietario en la fila de una tabla. Este dato es un mnemónico de
DisplayString que representa una cadena de octetos (entre 0 y 255
octetos).
 EntryStatus: es el tipo de dato que se asocia al objeto que representa
el estado de la fila en una tabla. Este tipo de objeto puede tomar los
valores: valid, createRequest, underCreation, invalid.
Gestión de las tablas
OwnerString ::= DisplayString

EntryStatus ::= INTEGER { valid (1),

Se utiliza en el
proceso de creación
createRequest (2),
de una fila underCreation(3),
Invalid (4) }
Gestión de las tablas
OwnerString ::= DisplayString

EntryStatus ::= INTEGER { valid (1),

createRequest (2),
Una vez creada la fila
permanece en este estado underCreation(3),
hasta que la estación de
gestión termine de crear todas
Invalid (4) }
las filas que necesite para la
configuración.
Gestión de las tablas
OwnerString ::= DisplayString

EntryStatus ::= INTEGER { valid (1),

createRequest (2),
Una vez terminada la
configuración, la estación de underCreation(3),
gestión cambia el valor de
status a valid.
Invalid (4) }
Gestión de las tablas
OwnerString ::= DisplayString

EntryStatus ::= INTEGER { valid (1),

createRequest (2),
underCreation(3),
Para borrar y Invalid (4) }
modificar una fila de
una tabla
Gestión de las tablas
 Una tabla de control de RMON de ejemplo:
ejeControlTable
 Típicamente incluye los siguientes objetos
columna:
 ejeControlIndex: índice de la fila
 ejeControlParameter: un parámetro de configuración
que se aplica a todas las filas de datos controladas por
esta fila de control
 ejeControlOwner: el propietario de la fila
 ejeControlStatus: el estado de la fila
Gestión de las tablas
 La tabla de datos asociada: ejeDataTable
 Típicamente incluye los siguientes objetos columna:
 ejeDataControlIndex: índice de la fila. Contiene el mismo
valor que el ejeControlIndex de la fila que contiene los
parámetros de control de esta entrada de datos
 ejeDataIndex: índice de la fila. Define una entrada
concreta de entre todos los datos recolectados bajo una
misma control de la fila
 ejeDataValue: el valor almacenado en esta
Gestión de las tablas: ejemplo
Gestión de las tablas
 Si una estación de gestión intenta crear una
nueva fila, y el valor de cada uno de los
índices aún no existe, la fila es creada con el
valor del objeto status en createRequest.
Gestión de las tablas
 Inmediatamente después de terminada la
operación de creación de la fila, el agente
cambia el valor del objeto status a
underCreation.
Gestión de las tablas
 La fila debe permanecer en el estado
underCreation hasta que la estación de gestión
termine de crear todas las filas que necesite
para la configuración.
Gestión de las tablas
 Una vez terminada la configuración, la
estación de gestión cambia el valor de status
a valid.
Gestión de las tablas
 Si se intenta crear una nueva fila, con el
estado createRequest, y la fila ya existe, el
agente devolverá un error.
Gestión de las tablas
 Para borrar una fila de una tabla debe cambiarse
el valor de status a invalid mediante la PDU
SetRequest correspondiente.
Gestión de las tablas
 Para modificar una fila de una tabla debe
cambiarse el estado a invalid y luego cambiar
los valores deseados de la fila.
La MIB de RMON
 Se encuentra detallada en la RFC 1757.
 La MIB de RMON se incorpora como un subárbol dentro
de la MIB II con el identificador 16.
 Se divide en 9 grupos:
 statitics: estadísticas sobre utilización y errores
 history: muestra estadísticas periódicas del grupo anterior
 host: contadores de tráfico desde y hacia los hosts
 hostTopN: estadísticas ordenadas de los hosts top de una lista
 matrix: información de utilización y errores en forma de matriz
 alarm: permite fijar alarmas para cualquier contador RMON
 filter: observar paquetes que pasen el filtro
 packet capture: como se envían los datos a la consola gestora
 event: eventos generados por la sonda RMON
La MIB de RMON
 En la RFC 1513 se definen extensiones en la
MIB RMON para la gestión de redes tipo
Token Ring (802.5).
 Consiste en el agregado de nuevas tablas en
los grupos ya existentes, statistics y history, y
el agregado de un nuevo grupo:
10. tokenRing
La MIB de RMON
La MIB de RMON
 Los diez grupos son opcionales para la
implementación de RMON.
 Pero existen algunas dependencias como son:
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 statistics
 Contiene estadísticas básicas sobre cada subred monitorizada
 Contiene una única tabla para Ethernet (RFC 1757):
etherStatsTable
 Una fila por cada interfaz de red.
 Recolecta información sobre cada subred: cantidad de bytes,
de paquetes, paquetes de determinada longitud, paquetes
erróneos, cantidad estimada de colisiones, cantidad de
paquetes broadcast y multicast.
 Esta información se almacena en objetos cuyo tipo es
contador, que se inicializan en cero cuando es creada una
nueva fila.
Grupo statistics
 El índice de la tabla: etherStatsIndex
 etherStatsDataSource: identifica la interfaz origen de
los datos de esta fila.
 Es del tipo OBJECT IDENTIFIER y corresponde al
ifIndex del grupo interfaces
Grupo statistics
 Contadores
Grupo statistics
 Contadores (cont)
Grupo history
 Almacena muestras de algunas de las
variables de la tabla del grupo statistics.
 Este grupo está conformado por 4 tablas:
 historyControlTable Redes Ethernet
 etherHistoryTable
 tokenRingMLHistoryTable Redes Token Ring
 tokenRingPHistoryTable
Grupo history
 Cuando el gestor necesita obtener
información acerca de la evolución de
algunos parámetros de la red a través del
tiempo, debe crear una nueva fila en la tabla
de control incluyendo los datos necesarios:
 Interfase de la que se quieren obtener los datos.
 Cantidad de muestras a almacenar.
 Intervalo entre muestras.
Grupo history
 historyControlTable: especifica la interfaz y los detalles
de la función de muestreo
 historyControlIndex: índice
 historyControlDataSource: identifica la fuente de los datos
(intefaz de red) debe coincidir con ifindex (del grupo interface)
 historyControlBucketsRequested: número de muestras
solicitadas (por defecto 50)
 historyControlBucketsGranted: número de muestras
concedidas
 historyControlInterval: intervalo en seg. ⊂ [1, 3600]. Defecto
1800 s

 historyControlOwner
 historyControlStatus Igual en todas las tablas de control
 Grupo history
 etherHistoryTable: registra los datos
 etherHistoryIndex (igual a
historyControlIndex)
 etherHistorySampleIndex (índice de la tabla
de datos)
 etherHistoryIntervalStart: valor del
sysUpTime al inicio del intervalo de medida
 Contadores correspondientes a
etherStatsTable:
etherHistoryDropEvents,
etherHistoryOctets,
etherHistoryPkts,...
 etherHistoryUtilization: % de utilización en el
intervalo de medida
Grupo history: historyControlTable
Grupo host
 Estadísticas sobre cada uno de los hosts
detectados por la sonda.
 El monitor descubre nuevos hosts en la red
observando las direcciones físicas fuente y
destino
 Contiene tres tablas: una de control y dos de
datos
Grupo host
 La tabla hostControlTable contiene
 hostControlIndex: índice
 hostControlDataSource: identifica la fuente de los
datos (intefaz de red) debe coincidir con ifindex (del
grupo interface)
 hostControlTableSize: número de filas en hostTable y
hostTimeTable asociadas a esta fila
 hostControlLastDeleteTime: valor de sysUpTime
correspondiente a la última vez que se borró una
entrada de la parte de la hostTable asociada a esta fila
Grupo host
 La tabla hostTable contiene
 hostAddress: dirección MAC (física)
 hostCreationOrder: número asignado en orden de inserción de
hosts en la tabla
 hostIndex: una subred (un valor de hostControlIndex)
 Diversos contadores
 Indexada por:

1º: hostIndex
2º: hostAddress

* se ordenan dependiendo de la dirección MAC del host.

Grupo host
 La tabla hostTimeTable contiene exactamente la misma
información que hostTable pero indexada por orden de creación :
1º: hostTimeIndex
2º: hostTimeCreationOrder

* se ordenan por el orden en que el monitor detecta los hosts de la

subred
Grupo hostTopN
 Estadísticas sobre el conjunto de hosts de una subred
que encabezan una clasificación (según un
determinado parámetro)
 Por ejemplo: los 10 hosts que más tramas transmiten
 Las estadísticas se extraen del grupo host
 Las estadísticas para un parámetro y una subred,
recogidas en un intervalo de medida se conocen
como informe (report)
 El informe: lista ordenada según el incremento en el
parámetro considerado dentro del tiempo de
elaboración del informe
Grupo hostTopN
 Consiste en un tabla de control y una tabla de
datos
 La tabla hostTopNControlTable contiene:
 hostTopNControlIndex: define una fila
 hostTopNHostIndex: coincide con un valor de
hostControlIndex y hostIndex (una interfaz única
del monitor = una subred). La clasificación de los
“top-N” se preparará para los hosts de esta subred
Grupo hostTopN
 hostTopNRateBase: cambios en la variable seleccionada,
establece la base para uno de los contadores de la hostTable
(hostTopNRate )
 hostTopNTimeRemaining: segundos que faltan para el
siguiente muestreo (definir el intervalo de medición)
 hostTopNDuration: intervalo de muestreo (seg)
 hostTopNRequestedSize: número máximo de hosts en la
clasificación solicitados
 hostTopNGrantedSize: idem concedidos
 hostTopNStartTime: valor de sysUpTime cuando se inició
este informe
Grupo hostTopN
 La tabla hostTopNTable contiene:
 hostTopNReport: define un informe particular.
Corresponde a una fila de la
hostTopNControlTable
 hostTopNIndex: define una fila entre las filas
generadas en este informe (un host)
 hostTopNAddress: la dirección MAC del host
 hostTopNRate: incremento de la variable
seleccionada durante el intervalo de muestreo
Grupo hostTopN
 Preparación de un informe:
 La estación gestora crea una fila en la tabla de control,
especificando:
 La subred a monitorizar (hostTopNHostIndex)

 La variable para clasificar (hostTopNRateBase)

 Tamaño de la lista (hostTopNRequestedSize)

 El periodo de muestreo (hostTopNTimeRemaining)

 Cuando hostTopNTimeRemaining=0 se calcula el informe

 Si la estación gestora quiere otro informe pone otra vez
hostTopNTimeRemaining := hostTopNDuration
 Se borran los datos y se genera un nuevo informe
Grupo matrix
 El grupo Matrix recolecta información sobre
el tráfico entre dos hosts dentro de una
subred.
 La información se guarda con el formato de
una matriz:
Grupo matrix
 Este grupo esta conformado por una
tabla de control (matrixControlTable) y
dos tablas de datos (matrixSDTable y
matrixDSTable):
 matrixSDTable: tráfico desde un host a todos sus
destinos
 matrixDSTable: tráfico desde cualquier host hacia
un destino
Grupo matrix
 La tabla matrixControlTable contiene los siguientes
objetos:
 matrixControlIndex: un entero que diferente para cada fila de
la tabla (índice)
 matrixControlDataSource: identifica la fuente de los datos
(intefaz de red) debe coincidir con ifindex (del grupo
interface)
 matrixControlTableSize: número de filas en las tablas
matrixSDTable y matrixDSTable
 matrixControlLastDeleteTime: valor de sysUpTime
correspondiente a la última vez que se borró una entrada de
matrixSDTable y matrixDSTable
Grupo matrix
 La tabla matrixSDTable almacena estadísticas del trafico
desde una maquina determinada a un conjunto de
destinos
 Contiene los siguientes objetos:
 matrixSDIndex: índice (igual a matrixControlIndex)
 matrixSDSourceAddress: dirección MAC fuente
 matrixSDDestAddress: dirección MAC destino
 matrixSDPkts: paquetes fuente destino
 matrixSDOctets: octetos fuente destino
 matrixSDErrors: paquetes defectuosos fuente destino
Grupo matrix
 La tabla matrixDSTable contiene la misma informacion
que la anterior pero indexada :
 matrixDSIndex: indice (igual a matrixControlIndex)
 matrixDSDestAddress: dirección MAC destino
 matrixDSSourceAddress: dirección MAC fuente
 matrixDSPkts
 matrixDSOctets
 matrixDSErrors
 Cada vez que el monitor detecta una nueva conversacion,
incluye dos filas en cada una de las dos tablas (DS y SD)
Grupo alarm
 Se usa para definir un conjunto de umbrales para las
prestaciones de la red
 Si se cruza un umbral en una dirección determinada
se genera una alarma y se envía a la consola central
 Cuando se activa una alarma se genera un evento
(definido en el grupo event)
 Por ejemplo, se puede generar una alarma si se
contabilizan más de 500 errores CRC (el umbral) en
un intervalo de 5 minutos
 El grupo alarm está formado por una sola tabla:
alarmTable
Grupo alarm
 La tabla alarmTable contiene los siguientes
objetos:
 alarmIndex: índice
 alarmInterval: período muestreo
 alarmVariable: la variable a muestrear (tipos
INTEGER, counter, gauge o TimeTicks)
 alarmSampleType: Método de muestreo,
absoluteValue(1), se mide el valor de la variable, o
deltaValue(2) respecto a la medición anterior
(delta).
 alarmValue: valor muestreado en el último periodo.
Grupo alarm
 alarmStartupAlarm: risingAlarm(1),
fallingAlarm(2) o risingOrFallingAlarm(3),
mecanismo diseñado para prevenir que se
generen alarmas repetidamente.
 alarmRisingThreshold y alarmFallingThreshold:
Umbrales de bajada y subida
 alarmRisingEventIndex y
alarmFallingEventIndex: índice de eventEntry
que utiliza cuando se cruza el umbral ascendente
o descendente
Grupo alarm
 Aunque se mencionen “las muestras”, sólo se
almacena la muestra más reciente y no un conjunto
de muestras tal como lo hace el grupo history.
 La estación gestora define una nueva alarma
añadiendo una fila en la alarmTable
 La combinación de variable, intervalo de muestreo y
umbrales debe ser única
Método para evitar la activación de
muchas alarmas menores
Grupo filter
 Permite definir filtros para que el monitor observe un
determinado tipo de paquetes
 Los filtros se forman a partir de dos componentes básicos:
 filtros de datos: para averiguar si un patrón de bits
aparece (o no) dentro de los paquetes
 filtros de estado: se buscan paquetes de un tipo
determinado (válidos, errores de CRC, etc.)
 Estas componentes se pueden combinar mediante
operaciones AND y OR para crear filtros más complejos.
 El flujo de paquetes que pasan el conjunto de filtros se
denomina canal (channel)
Grupo filter
 Los paquetes de un canal se contabilizan
 Cuando un paquete pasa por un canal se puede generar
un evento (definido en el grupo event)
 Los paquetes que pasan por un canal pueden ser
capturados mediante el mecanismo definido en el grupo
capture
 El grupo filter tiene dos tablas de control:
 Cada fila de la channelTable define un canal único
 Asociado a ese canal hay una o más filas en la filterTable
donde se definen los filtros asociados
Grupo filter
 La tabla channelTable incluye los objetos siguientes:
 channelIndex: entero que identifica al canal
 channelIfIndex: Identificador de la subred
 channelAcceptType: controla la aplicación de los filtros
asociados a este canal:
 acceptMatched (1): se acepta un paquete si pasa al menos
un filtro
 acceptFailed (2): se acepta un paquete si no pasa ningún
filtro
 channelDataControl: on (canal abierto) o off (canal
cerrado)
Grupo filter
 channelTurnOnEventIndex: cuando sea generado el
evento que especifica este objeto se cambiará el
estado de channelDataControl a on.
 channelTurnOffEventIndex: cuando sea generado
el evento que especifica este objeto se cambiará el
estado de channelDataControl a off.
 channelEventIndex: Especifica el evento con el
cual está asociado el canal. Este se define mediante
el índice que posea el evento en la tabla del grupo
event.
Grupo filter
 channelEventStatus:
eventReady (1) se genera un evento y luego pasa al
estado eventFired(2).
eventFired (2) en este estado no se generan eventos.
eventAlwaysReady (3) todos los paquetes generan un
evento.
 channelMatches: contador del número de paquetes que
pasan los filtros (incluso aunque ChannelDataControl =
off, es decir, aunque el canal está cerrado)
 channelDescription: descripción textual del canal
Grupo filter
 La tabla filterTable incluye los objetos
siguientes:
 filterIndex: índice de la filterTable
 filterChannelIndex: número de canal al que está
asociado el filtro.
 filterPktDataOffset: desplazamiento en bits desde el
comienzo del paquete hasta donde debe comenzar el
proceso de comparación de bits.
 filterPktData: Bits que deben compararse con cada
paquete.
 filterPktDataMask: Máscara que se debe aplicar al
proceso de comparación para el filtro de datos.
Grupo filter
 filterPktDataNotMask : Máscara de inversión (inversion
mask) que debe aplicarse en el proceso de comparación
para el filtro de datos.
 filterPktStatus: Estado que deben tener los paquetes
para pasar el filtro de estado.
 filterPktStatusMask: Máscara que se debe aplicar al
proceso de comparación para el filtro de estado.
 filterPktStatusNotMask: Máscara de inversión
(inversion mask) que debe aplicarse en el proceso de
comparación para el filtro de estado.
 Cada fila de la tabla filterTable define un nuevo
filtro
Grupo capture
 Se usa para configurar la captura de paquetes de
uno de los canales definidos en el grupo filter
 Está formado por una tabla de control
bufferControlTable y una tabla de datos
captureBufferTable.
 Cada fila de la tabla de control define un buffer
que será utilizado para almacenar los paquetes
capturados.
Grupo capture
 La tabla bufferControlTable contiene:
 bufferControlIndex: índice
 bufferControlChannelIndex: identifica el canal fuente de esta
captura
 bufferControlFullStatus: spaceAvailable (1), full (2)
 bufferControlFullAction: lockWhenFull (1), wrapWhenfull
(2)
 Una vez que esté lleno se eliminará el paquete más antiguo

para almacenar el capturado recientemente.

 O una vez que esté completo no se capturan más paquetes.
Grupo capture
 bufferControlCaptureSliceSize: número máximo de octetos de
cada paquete, comenzando desde el inicio del paquete, que se
almacenan en el buffer de captura. (si 0, tanto como sea posible.
Por defecto 100)
 bufferControlDownloadSliceSize : número máximo de octetos de
cada paquete que se entregan en respuesta a una petición SNMP
 bufferControlDownloadOffset: un offset para el valor anterior
 bufferControlMaxOctetsRequested: tamaño del buffer en octetos.
Solicitado.
 bufferControlMaxOctetsGranted: tamaño del buffer en octetos.
Concedido.
 bufferControlCapturedPackets: número de paquetes actualmente el
buffer
 bufferControlTurnOnTime: valor de sysUpTime cuando se activa
el buffer
Grupo capture
 La tabla captureBufferTable contiene:
 captureBufferControlIndex: número de buffer del paquete
 captureBufferIndex: número del paquete dentro del buffer
 captureBufferPacketID: índice que describe el orden de los
paquetes capturados recibidos en un interfaz
 captureBufferPacketData: el paquete
 captureBufferPacketLength: tamaño real del paquete
 captureBufferPacketTime: milisegundos desde que se
activo este buffer hasta la captura del paquete
 captureBufferPacketStatus: estado de error del paquete
Grupo event
 Se definen los eventos
 La activación se produce en otros lugares de la MIB
(ejemplo, en el grupo alarm)
 Los eventos que pueden generarse son:
 Ninguno.
 Enviar un Trap.
 Archivar el evento en la tabla de datos.
 Enviar un Trap y archivar el evento.
 El grupo event contiene dos tablas: eventTable y
logTable
Grupo event
 La tabla eventTable contiene los objetos
siguientes:
 eventIndex: índice
 eventDescription: descripción textual
 eventType: none (1), log (2), snmp-trap (3), log-and-
trap (4)
 eventCommunity: comunidad para la trap
 eventLastTimeSent: valor de SysUpTime cuando se
generó el último evento
Grupo event
 La tabla logTable contiene los objetos
siguientes:
 logEventIndex: evento que generó esta anotación
 logIndex: número de esta anotación (de entre todas
las anotaciones del mismo evento)
 logTime: valor de SysUpTime cuando se realizó la
anotación
 logDescription: descripción de la anotación
(dependiente de la implementación)
RMON2
 RMON2 es una extensión a la MIB RMON que
incluye la decodificación de paquetes pertenecientes
a las capas 3 a 7 del modelo OSI.
 RMON2 puede:
 decodificar los paquetes de esos protocolos. Al
decodificar IP el monitor observa tráfico de fuera de la
red que llega por los routers
 Puede decodificar tráfico de aplicaciones (email,
www, ...), por tanto puede contabilizar los paquetes
generados por cada host para cada aplicación
RMON2
 Se añaden los siguientes grupos a la MIB de RMON2:
 protocolDir (11): directorio de protocolos
 protocolDist (12) : distribución de protocolos
 addressMap (13): mapa de direcciones
 nlHost (14): hosts de nivel de red
 nlMatrix (15): matriz de nivel de red
 alHost (16): hosts de nivel de aplicación
 alMatrix (17): matriz de nivel de aplicación
 usrHistory (18): histórico del usuarios
 probeConfig (19): configuración de la sonda
RMON2
 Grupo protocolDir
 En un red puede haber varios protocolos por encima del MAC:
estandarizados o no
 Aquí se guarda información sobre qué protocolos puede
interpretar una sonda RMON2
 Grupo protocolDist
 Resumen estadísticos sobre el número de octetos y paquetes que
se han transferido para cada uno de los protocolos soportados
 Grupo addressMap
 Relaciona cada dirección de red con la dirección MAC
 Útil para descubrir la topología de una red
RMON2
 Grupo nlHost
 Permite decodificar paquetes basándose en su dirección IP
 Recopila estadísticas similares al grupo host de RMON1
 Grupo alHost
 Una tabla de este grupo recopila información para cada uno de los
protocolos de aplicación* y cada una de las direcciones IP
 Grupo nlMatrix
 Contiene tablas para recoger estadísticas del tráfico entre parejas de
hosts (identificadas por su dirección IP)
 Otras tablas almacenan estadísticas sobre los topN (clasificaciones de
hosts según diferentes métricas)

(*) En RMON2 “nivel de aplicación” es cualquier protocolo por

encima del nivel de red
RMON2
 Grupo alMatrix
 Igual que el anterior pero para el nivel de aplicación.
 Contiene tablas para recoger estadísticas del tráfico entre los
protocolos de aplicación
 Grupo usrHistory
 Periódicamente sondea estadísticas y variables, y registra
los datos según parámetros definidos por los usuarios
 El gestor de la red puede mantener un registro histórico de
cualquier contador del sistema
 Grupo probeConfig
 Para configurar una sonda RMON2