SNMP

Report
GESTIÓN DE REDES:
PROTOCOLOS DE MANTENIMIENTO
Dr. Víctor J. Sosa Sosa
[email protected]
Introducción
 Elementos del modelo de gestión
 Simple Network Management Protocol
(SNMP)
 Estructura de la información de gestión
(SMI)
 Management Information Base (MIB-II)
 SNMPv2 y SNMPv3
Gestión de Redes TCP/IP
 Al inicio de TCP/IP no se pensó en incluir soporte para la
gestión de redes
 Eran los expertos en protocolos quienes solucionaban los
problemas de gestión
 La única “herramienta” disponible era ICMP, sobre todo con los
mensajes de ECHO para tests de alcanzabilidad, y los de
timestamp, para obtener información acerca de los retardos en la
red
 Programas PING (Packet Internet Groper) y traceroute
 Finales años 8Os: Internet crece explosivamente
 Se empezó a pensar en una capacidad de gestión de red más
potente
 Protocolo estándar, con mucha más funcionalidad que PING, fácil
de aprender y utilizar por muchas personas responsables de la
gestión de red
Gestión de Redes TCP/IP
 El IAB (Internet Architecture Board) propuso dos estrategias
(1988):

A corto plazo, definir el protocolo SNMP (inicialmente era SGMP:Simple
Gateway Management Protocol)
 A largo plazo, una migración hacia la gestión OSI (protocolo CMOT: CMIP
–Common Management Information Protocol– sobre TCP/IP)
 Premisa:

el impacto de añadir gestión de red a los nodos debía ser mínimo
 Se pensaba que las instalaciones acabarían evolucionando a
protocolos basados en OSI

Para facilitar la migración, se pensó que ambos empleasen la misma
base de datos de objetos gestionados
 Pero eso se vio que era imposible, pues la gestión OSI emplea BD
orientadas a objetos y se pretendía mantener el SNMP tan sencillo como
fuese posible
 SNMP y CMOT* evolucionaron en paralelo
*Common Management Information Protocol
Gestión de Redes TCP/IP
 Situación actual:
 SNMP es el estándar de facto para la gestión de redes, al
igual que TCP/IP lo es para la interconexión de redes
 No es probable que OSI y su sistema de gestión de red
reemplacen al modelo TCP/IP+SNMP
 Una vez se extiende el uso de SNMP se proponen
diversas ampliaciones
 RMON: Remote MONitor
 Monitorización global de una subred, no sólo de sus
dispositivos
 Extensiones a la MIB de SNMP, tanto estándar como
privadas
 Versiones 2 y 3 de SNMP para resolver deficiencias
Principales RFCs relacionados con
SNMPv1
Principales RFCs relacionados con
SNMPv2
Principales RFCs relacionados con
SNMPv3
Elementos del modelo de gestión
SNMP
 Estación de gestión:
 Interfaz entre el gestor humano y el SGR
 Debe incluir:
 Interfaz (gráfico) para monitorizar y controlar la red
 Aplicaciones de gestión para análisis de datos,
recuperación de fallos, etc
 Capacidad de traducir los requerimientos del gestor
en órdenes concretas de monitorización y control de
los elementos remotos de la red
 Base de datos de información extraída de las MIBs
de todas las entidades gestionadas en la red
Elementos del modelo de gestión
 Agente:
 Software que proporciona acceso a los datos de
gestión de un dispositivo en particular
 Hosts, puentes, routers, switches, hubs, …
 SNMP soporta dos tipos de transacciones:
 Petición (POLL) por parte del gestor, y respuesta
por parte de agente
 Notificaciones no solicitadas (TRAPS) desde el
agente al gestor
Elementos del modelo de gestión
 Base de información de gestión (MIB):
 Conjunto de objetos (variables) que representan los
recursos de la red que se pueden gestionar
(monitorizar y controlar)
 Monitorización: lectura del valor de los objetos de la MIB
 Control: modificación del valor de ciertas variables
 Los objetos se almacenan en los dispositivos
gestionados
 Los objetos están estandarizados para cada clase
concreta
 Ejemplo: Hay los mismos tipos de objetos para gestionar
varios puentes
Elementos del modelo de gestión
 Protocolo de gestión de red:
 La estación de gestión y los agentes se comunican
empleando el protocolo de gestión de red
 En redes TCP/IP ese protocolo es SNMP
 SNMP incluye las siguientes capacidades:
 GET: permite a la estación de gestión obtener (leer)
el valor de los objetos del agente
 SET: permite a la estación de gestión modificar
(escribir) el valor de los objetos del agente
 TRAP: permite al agente notificar a la estación de
gestión la ocurrencia de eventos significativos
Elementos del modelo de gestión
 SNMP es un protocolo del nivel de aplicación
 Funciona sobre UDP => no es orientado a la conexión
 Cada intercambio es una transacción separada entre el gestor y
los agentes
 Tanto el gestor como los agentes deben implementar IP,
UDP y SNMP, sobre los protocolos específicos de acceso a
la red
 Proceso gestor:
 Actúa como “cliente” SNMP, cuando envía peticiones SNMP
 Escucha los traps en el puerto 162
 Proceso agente: debe interpretar los mensajes SNMP y
controlar la MIB del agente
 Actúa como “servidor” SNMP, escuchando las peticiones del
gestor en el puerto 161
 Envía los traps al gestor
Elementos del modelo de gestión
SNMP: Tipos de mensajes
SNMP: Tipos de mensajes
 GetRequest: el gestor pide al agente el valor de un dato

GetNextRequest es similar, permitiendo extraer datos de una tabla
 SetRequest: el gestor pide al agente que modifique los valores de
las variables que especifique

El agente los modificará todos o ninguno
 El agente responde a estas peticiones mediante GetResponse,
conteniendo :


Los datos pedidos o un código de error, para las operaciones Get
Respuesta idéntica a la petición (tras cambiar los valores) o un código de
error para la operación Set
 El agente emite un mensaje Trap en respuesta a un evento que
afecte a la MIB o a los recursos gestionados

Puede incluir en el mensaje los nombres y valores de ciertos objetos
como información adicional sobre el evento
 El gestor NO confirma la recepción de un Trap al agente
SNMP: Sondeo dirigido por traps (trapdirected polling)
 El protocolo SNMP se basa en el sondeo o polling:
 El gestor sondea periódicamente a los agentes para ver si
hay algo que necesite atención
 Si una estación de gestión controla un gran número de
agentes, y cada uno tiene un gran número de objetos, este
mecanismo se vuelve poco eficiente
 Por ello, se emplea la técnica del sondeo dirigido por trap:
 Cuando llega un trap desde un agente, el gestor centra su
atención en ese dispositivo
 Problema: Los traps no se confirman y el transporte es ‘no
fiable’ (UDP)
 Por tanto, el gestor no se puede basar exclusivamente en la
recepción de traps para obtener información de los
dispositivos
SNMP: Sondeo dirigido por traps (trapdirected polling)
 Solución:
 Sondeo al inicializar el sistema y a intervalos poco regulares
(horas)
 Se pide alguna información clave, y algunas características básicas
de funcionamiento a todos los agentes que conozca el gestor
 El resto del tiempo, el gestor no sondea, y es el agente quien le
avisa mediante un trap en caso de que ocurra algún evento
anormal
 Ejemplos: Caída y reinicialización del agente, caída de un enlace ...
 Tras recibir el trap el gestor puede obtener más información del
agente que envió el trap, o de otros agentes próximos a él para
obtener más información y diagnosticar el problema
 Ahorro de capacidad de la red y de tiempo de proceso de los
agentes y gestores
SNMP: Proxies SNMP
SNMP: Detalles del protocolo
 SNMP se especifica en el RFC 1157 (Mayo 1990)
 SNMP permite leer y escribir objetos escalares
en la MIB de un agente
 Mediante traps, un agente puede enviar el valor de un
objeto escalar al gestor
 Cada agente es responsable de su MIB local
 Controla el uso que hacen de ella las estaciones
gestoras
 Control de acceso a la MIB de un agente:
 concepto de comunidad
SNMP: Comunidades
 Comunidad: relación entre un agente SNMP y un
conjunto de estaciones de gestión SNMP, que define
unas características de autentificación y control de
acceso
 El agente establece una comunidad para cada combinación




deseada de autentificación y control de acceso, y a cada
comunidad se le da un nombre único dentro del agente
(community name)
Las estaciones de gestión pertenecientes a una comunidad deben
emplear ese nombre en todas las operaciones get y set
El agente puede establecer cualquier número de comunidades
Una estación de gestión puede pertenecer a varias comunidades
Una estación debe almacenar los nombres de comunidad
asociados a cada agente
SNMP Comunidades
 Mediante el uso de comunidades, un agente puede limitar el
acceso a su MIB en dos formas:


Vista de la MIB: subconjunto de los objetos de la MIB
Modo de acceso: READ-ONLY o READ-WRITE
 La combinación de una vista de la MIB y un modo de acceso se




denomina perfil de comunidad SNMP (SNMP community profile)
A cada comunidad se le asigna un perfil, denominándose a esta
asociación política de acceso SNMP (SNMP access policy)
Cada paquete SNMP contiene el nombre de la comunidad, sin
codificar
El agente sólo atiende la petición si el nombre de la comunidad
es correcto para el tipo de acceso solicitado
Se trata de un esquema de seguridad muy limitado

Por ello, en muchos agentes no se implementan las peticiones de
escritura en la MIB (mensajes SetRequest)
SNMP Comunidades
SNMP Comunidades
SNMP: Formato de los paquetes
 Todos los paquetes contienen dos campos:
 El número de versión de SNMP
 Un nombre de comunidad
 El resto del paquete depende del tipo del mismo, y
se denomina PDU (Protocol Data Unit) de SNMP
Versión
Comunidad
Mensaje SNMP
PDU de SNMP
SNMP:
Formato de los paquetes
SNMP:
Formato de los paquetes

Request ID: identificador único por cada petición

Código de error: indica que ha ocurrido una excepción al procesar una
petición

Posibles valores: noError
readOnly(4), genErr(5)
(0),
tooBig(1),
noSuchName(2),
badValue(3),

Índice de error: indica qué variable de la lista causó la excepción, cuando el
código de error no es 0

Asignación de variables: lista de nombres de variables y sus
correspondientes valores


Los nombres se especifican como identificadores de objetos (OIDs)
En GetRequest, los valores son null

Empresa (enterprise): objeto que genera el trap (valor de sysObjectID)

Dirección de agente: dirección IP del agente que genera el trap

Trap genérica: tipo de trap genérico

Trap específico: código de trap específico

Time stamp: tiempo transcurrido entre la última reinicialización de la
entidad y la generación del trap (valor de sysUpTime)
SNMP: Traps genéricas SNMP
 coldStart (0): el emisor se ha reinicializado, y puede haberse
alterado la configuración del agente o la implementación del
protocolo
 warmStart (1): reinicialización del emisor, sin cambios en
configuraciones ni en implementaciones
 linkDown (2): fallo en algún enlace de comunicación del agente
 linkUp (3): un enlace de comunicación del agente se ha
restablecido

En el campo de asignación de variables, se especifica cuál es el enlace
que ha caído/restablecido
 authenticationFailure (4): la entidad emisora ha recibido un
mensaje en el que falla la autentificación
 egpNeighborLoss(5): desconexión de un vecino EGP
 enterprise-Specific(6): definidas por empresas
SNMP: Ventajas e inconvenientes de
SNMP
 Es un protocolo maduro, estándar de facto aceptado por la industria
 Está disponible en gran cantidad de productos
 Es fácil de implementar y requiere pocos recursos del sistema
 Falta de seguridad:



Cualquier estación puede resetear variables con SetRequest, por lo que muchos
fabricantes no implementan este comando
No hay control de acceso: al recibir un PDU un agente no comprueba si ha sido
enviado por una estación autorizada
La identificación de comunidad viaja tal cual
 Mala utilización del ancho de banda:

No existe la posibilidad de transferir información por bloques
 Limitaciones en el mecanismo de traps:


Sólo se puede informar de algunos eventos previstos
No son reconocidas
 No es apropiado para gestionar redes muy grandes (por el sondeo)
Estructura de la información de gestión
(SMI)
 La gestión en TCP/IP se basa en el manejo de una base de datos
(la MIB) que contiene información sobre los objetos a gestionar

Cada recurso se representa mediante un objeto
 Objetos escalares y tablas bidimensionales

La MIB es un conjunto estructurado de tales objetos
 Estructura de árbol



Las operaciones de monitorización consultan el valor de los objetos
Las operaciones de control modifican el valor de los objetos
Cada objeto de un dispositivo gestionable por SNMP debe tener
un nombre único con el que se le denominará en las operaciones
de gestión

El esquema de nombres debe asegurar que dos fabricantes no emplean
el mismo nombre para objetos distintos
 Se define mediante el SMI (Structure of Management Information)
Estructura de la información de
gestión (SMI)
 La MIB define el objeto u objetos utilizados para
representar un recurso en concreto deben ser los
mismos en cada nodo
 Ejemplo: número total de conexiones activas TCP en un
nodo
 Conexiones abiertas = conexiones activas + conexiones pasivas
 El nodo puede almacenar cualquier par de los tres valores
{totales,activas, pasivas}
 En la definición de la MIB se indica:
 Que se deben almacenar las conexiones activas y pasivas
 Se definen los objetos tcpActiveOpens y tcpPassiveOpens,
de tipo “counter” (entero 32 bits)
 Sus nombres son 1.3.6.1.2.1.6.5 y 1.3.6.1.2.1.6.6 => esquema
común de nombrado (SMI)
SMI:
Estructura
 La estructura del SMI y de la MIB se definen empleando el




estándar ASN.1 (Abstract Syntax Notation One) de
CCITT/ISO
Los tipos de datos empleados en SNMP también se basan
en los de ASN.1
ASN.1 es un lenguaje que se emplea para definir
estructuras de datos y protocolos
Incluye unas reglas precisas de codificación (BER: Basic
Encoding Rules)
Proviene de OSI:
 Grande, complejo y no muy eficiente
 Ventaja: proporciona una codificación estándar en bits de
cada objeto
SMI: Estructura
 SNMP
utiliza el esquema jerárquico de nombres
desarrollado por ISO
 El espacio de nombres forma un árbol, con una raíz
conectada a un conjunto de nodos etiquetados
 Etiqueta = {breve descripción textual + entero} (ejemplo: iso(1))
 Los nodos se agrupan por ramas de objetos relacionados
 Identificador de objeto: nombre de un nodo
 Es la secuencia de enteros de las etiquetas de cada nodo, desde la
raíz hasta el nodo en cuestión
 El identificador es único para cada objeto
 La parte textual sólo se emplea por las personas, nunca se
transmite
 Cada nodo representa un recurso, actividad o información
relacionada
SMI: Estructura
SMI: Estructura
 La raíz no se etiqueta, y de ella cuelgan tres nodos:
 iso(1), ccitt(2) y joint-iso-ccitt(3)
 Del nodo iso cuelgan nodos para distintas organizaciones
 Entre ellas está el Departamento de Defensa de EE.UU. (dod(6))
 Ahí hay un nodo administrado por el IAB:
 internet OBJECT IDENTIFIER::={iso(1) org(3) dod(6) 1}
 Así, el nodo internet tiene el identificador de objeto 1.3.6.1
 Todos los objetos de interés para SNMP cuelgan del nodo
internet, y por tanto tienen el prefijo 1.3.6.1 en sus
identificadores de objeto
SMI: Estructura
 Dentro del nodo internet,
el SMI define cuatro nodos:
 directory(1): directorio X.500
 mgmt(2): objetos definidos
en documentos aprobados
por el IAB
 Como la mib-2 (1)
 experimental(3):
identificadores de objetos
experimentales en Internet
 private(4): identificadores de
objetos definidos por
empresas
SMI: Estructura
Definido por SMI
(RFC 1155)
Definido en MIB-II
(RFC 1213)
SMI: Estructura
 Adición de nuevos objetos en las MIB:
 Expansión o reemplazamiento del subárbol mib-2: por
ejemplo, con una versión posterior (mib-3) o añadiendo
subárboles a mib-2, como la base de monitorización
remota de la red (RMON)
 Construcción de una MIB experimental, para una
aplicación particular
 Primero se incluyen los objetos en el subárbol
experimental, y cuando el IAB los aprueba, pasan al
mgmt
 Extensiones privadas en el subárbol private: dentro de
private existe el nodo enterprises, donde se asigna una
rama a cada fabricante que registra un identificador de
objeto
SMI: Estructura
 Cada objeto dentro de la MIB de SNMP tiene una
definición formal que especifica:
 El tipo de datos del objeto
 El rango de valores que puede tomar
 Su relación con otros objetos de la MIB, esto es, su
posición dentro del árbol
 Se emplea la sintaxis ASN.1
 RFC 1155: Structure of Management Information
 RFC 1212: Concise MIB Definitions
 Especifican el formato que hay que seguir para definir
los objetos en una MIB
SMI: Estructura
 Ejemplo:
tcpMaxConn OBJECT-TYPE
Tipo de datos
Modo de acceso a una instancia del objeto
{read-only, read-write, write-only, not-accessible}
SYNTAX INTEGER
Define si el objeto ha de ser necesariamente
ACCESS read-only
incluido en la implementación de la MIB
{mandatory, optional, obsolete, deprecated}
STATUS mandatory
DESCRIPTION
 "The limit on the total number of TCP
connections the entity can support. In
Descripción del objeto
(opcional, dirigida al usuario)
entities where the maximum number
of connections is dynamic, this object
should contain the value -1.“
::= { tcp 4 }
Posición del objeto dentro del árbol
(referida al nodo “padre”)
SMI: Estructura
SMI: Tipos de Datos
 Los tipos de datos tienen una etiqueta asociada
 Etiqueta = nombre de la clase + número no negativo
 Clases de tipos de datos
 UNIVERSAL: tipos básicos, independientes de la
aplicación
 APPLICATION: relevantes a una aplicación particular
 Por ejemplo, SNMP
 CONTEXT-SPECIFIC: ídem que el anterior, pero
aplicables en un contexto limitado
 PRIVATE: definidos por los usuarios; no standarizados
SMI: Tipos de datos relevantes en
SNMTP
 Tipos de datos universales:





INTEGER (UNIVERSAL 2)
OCTETSTRING (UNIVERSAL 4)
NULL (UNIVERSAL 5)
OBJECT IDENTIFIER (UNIVERSAL 6)
SEQUENCE, SEQUENCE OF (UNIVERSAL 16)
 Tipos de datos de la aplicación (RFC 1155)






networkAddress (eliminado actualmente)
ipAddress (OCTETSTRING de 4 bytes)
counter (INTEGER)
gauge (INTEGER)
timeticks (INTEGER)
opaque (datos arbitrarios, apenas se usa)
SMI: Tipos de datos universales
INTEGER

32 bits en complemento a 2
 Se puede limitar el rango de valores
 Ejemplos:
 cuenta INTEGER ::= 100 -- valor inicial (opcional)
 estado ::= INTEGER{ up(1), down(2), unknown(3)} – subtipo
 PacketSize ::= INTEGER {0..1023} – subtipo
OCTETSTRING

Cadena de bytes
 Puede definirse la longitud de la cadena y un valor inicial
 Ejemplos:
 DisplayString
 Sólo puede contener caracteres NVT ASCII
 Representación de textos
 physAddress
 Representación de direcciones físicas
SMI: Tipos de datos universales
OBJECT IDENTIFIER
 Identificador de objetos
 Secuencia de números que determina la posición de un objeto
dentro de la estructura en árbol
 Ejemplo: el identificador del objeto tcpConnTable es
1.3.6.1.2.1.6.13
SEQUENCE
 Lista ordenada de tipos
 Similar a un registro de Pascal o a una estructura de C
SEQUENCE OF
 Vector unidimensional de un solo tipo
SMI: Tipos de datos de la
aplicación
ipAddress
 Direcciones IP (32 bits)
 Definido como OCTETSTRING de 4 bytes:
IpAddress ::= [APPLICATION 0] -- in network-byte order
IMPLICIT OCTET STRING (SIZE (4))
counter
 !Entero no negativo de 32 bits (máx=232 - 1)
Counter ::= [APPLICATION 1]
IMPLICIT INTEGER (0..4294967295)

Se puede incrementar, pero no decrementar
 Cuando el contador llega al máximo, vuelve a cero



¿Cuánto vale realmente la cuenta?
Aplicaciones:
Número de paquetes/bytes enviados/recibidos, número de errores, …
SMI: Tipos de datos de la
aplicación
Gauge
 Entero no negativo de 32 bits (máx=232 - 1):
Gauge ::= [APPLICATION 2]
IMPLICIT INTEGER (0..4294967295)



!Se puede incrementar y decrementar
Cuando el contador llega al máximo, se queda bloqueado en ese valor
Aplicaciones:

Número de paquetes almacenados en una cola en un instante

Almacenar la diferencia en el valor de algo entre el principio y el final de un intervalo de tiemp
timeticks
 Entero no negativo de 32 bits (máx=232 - 1)
 Cuenta el tiempo en centésimas de segundo
Valor máximo: 497 días
TimeTicks ::= [APPLICATION 3]
IMPLICIT INTEGER (0..4294967295)
SMI: Tipos de datos de la
aplicación
 Problema: ¿Cuánto tiempo hace falta para “dar la vuelta”
a un contador de 32 bits?
 Ejemplo: cantidad de bytes transmitidos
Velocidad de la interfaz
Tiempo de desbordamiento
1o Mbps
57.26min.
100 Mbps
5.73min.
155 Mbps
3.69min.
1 Gbps
0.57min
SMI: Tipos de datos de la
aplicación
 Nuevos tipos en SNMPv2
 Integer32: igual que INTEGER
 Counter32: igual que counter
 Gauge32: igual que gauge
 Unsigned32: igual que gauge
 Counter64: desde 0 hasta 18446744073709551615
SMI: Macro para la definición de
objetos (RFC 1212)
IMPORTS ObjectName FROM RFC1155-SMI
DisplayStringFROM RFC1158-MIB;
Access ::= "read-only“ | "read-write“
| "write-only“ | "not-accessible"
OBJECT-TYPE MACRO ::=
BEGIN
TYPE NOTATION ::=
Status ::= "mandatory"| "optional"| "obsolete“
| "deprecated"
"SYNTAX" type(ObjectSyntax)
"ACCESS" Access
"STATUS" Status
DescrPart ::= "DESCRIPTION" value
(description DisplayString) | empty
DescrPart
ReferPart
IndexPart
DefValPart
VALUE NOTATION ::= value (VALUE
ObjectName)
ReferPart ::= "REFERENCE" value (reference
DisplayString) | empty
SMI: Macro para la definición de
objetos (RFC 1212)
IndexPart ::= "INDEX" "{" IndexTypes "}“ | empty
IndexTypes ::= IndexType | IndexTypes ","
DefValPart ::= "DEFVAL" "{" value (defvalue
ObjectSyntax) "}“ | empty
END
IndexType
IndexType ::=
-- if indexobject, use the SYNTAX
-- value of the correspondent
-- OBJECT-TYPE invocation
value (indexobject ObjectName)
-- otherwise use named SMI type
-- must conform to IndexSyntax below
| type (indextype)
IndexSyntax ::= CHOICE {
number INTEGER (0..MAX),
string OCTET STRING,
object OBJECT IDENTIFIER,
address NetworkAddress,
ipAddress IpAddress }
SMI: Macro para la definición de
objetos (RFC 1212)
 ReferPart (opcional): referencia cruzada textual a
un objeto definido en otro módulo MIB
 IndexPart: para definir tablas; esta cláusula
aparece cuando el objeto describe una fila de
una tabla
 DefValPart (opcional): valor por defecto que se
usa cuando se crea una instancia de un objeto
 VALUE NOTATION: indica el nombre que se usa
para acceder a este objeto mediante SNMP
SMI: Definición de tablas
 SMI sólo permite estructurar los datos como
tablas bidimensionales con valores escalares
 Ejemplo: tabla con las conexiones TCP de un
dispositivo
 Objeto tcpConnTable (1.3.6.1.2.1.6.13)
 Para cada conexión, se almacena en la tabla:
 State: estado de la conexión TCP
 Local Address: dirección IP local
 Local Port: puerto local
 Remote Address: dirección IP remota
 Remote Port: puerto remoto
SMI: Definición de tablas
 Definición del objeto tabla:
OJO: T mayúscula
tcpConnTable OBJECT-TYPE
SYNTAX SEQUENCE OF TcpConnEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"A table containing TCP connectionspecific information."
::= { tcp 13 }
SMI: Definición de tablas
Definición del objeto fila:
tcpConnEntry OBJECT-TYPE
SYNTAX TcpConnEntry
ACCESS not-accessible
STATUS mandatory
INDEX { tcpConnLocalAddress,
tcpConnLocalPort,
tcpConnRemAddress,
tcpConnRemPort }
::= { tcpConnTable 1 }
TcpConnEntry ::= SEQUENCE {
tcpConnState INTEGER,
DESCRIPTION
tcpConnLocalAddress IpAddress,
"Information about a particular
tcpConnLocalPort INTEGER (0..65535),
tcpConnRemAddress IpAddress,
current TCP connection. An object
tcpConnRemPort INTEGER (0..65535)
of this type is transient, in that it
}
ceases to exist when (or soon
after) the connection makes the
transition to the CLOSED state”
SMI: Definición de tablas
Definición de los campos:
tcpConnState OBJECT-TYPE
SYNTAX INTEGER {
closed(1), listen(2), synSent(3),
synReceived(4), established(5),
finWait1(6), finWait2(7), closeWait(8),
lastAck(9), closing(10), timeWait(11),
deleteTCB(12) }
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The state of this TCP connection.....”
::= { tcpConnEntry 1 }
tcpConnLocalAddress OBJECT-TYPE
SYNTAX IpAddress
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The local IP address for this TCP
connection. ...."
::= { tcpConnEntry 2 }
tcpConnLocalPort OBJECT-TYPE
SYNTAX INTEGER (0..65535)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The local port number for this TCP
connection."
::= { tcpConnEntry 3 }
SMI: Definición de tablas
Definición de los campos:
tcpConnRemAddress OBJECT-TYPE
SYNTAX IpAddress
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The remote IP address for this
TCP connection."
::= { tcpConnEntry 4 }
tcpConnRemPort OBJECT-TYPE
SYNTAX INTEGER (0..65535)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The remote port number for this TCP
connection."
::= { tcpConnEntry 5 }
SMI: Definición de tablas
SMI: Definición de tablas
Management Information Base
(MIB-II)
 La MIB-II se define en el RFC 1213, y sustituye a la versión anterior
MIB-I (RFC 1156)
 La MIB-II se divide en varios grupos

Los nodos deben implementar todos los objetos del mismo grupo, o
ninguno
MIB-II: Grupo system
 Proporciona información general sobre el sistema gestionado

Muchos de estos objetos son útiles para la gestión de fallos y de la
configuración
 Objetos para la gestión de fallos

sysObjectID: información sobre el fabricante del dispositivo
(identificador de objeto para la empresa en el subárbol enterprises)
 sysServices: código de 7 bits que indica los niveles del protocolo de red
que soporta el dispositivo
 sysUptime: tiempo total que ha transcurrido desde la última
reinicialización del sistema
 Objetos para la gestión de la configuración

sysDescr: descripción textual de la entidad (versión S.O., hardware...)
 sysLocation: ubicación física del sistema
 sysContact: persona responsable del sistema
 sysName: nombre del sistema
MIB-II: Grupo system
MIB-II: Grupo interfaces
 Contiene datos genéricos relativos a cada interfaz
específico de un dispositivo de red
 Son útiles en gestión de fallos, de la configuración, de
prestaciones y de contabilidad
 Objetos ifNumber e ifTable
 ifNumber define el número de interfaces del sistema
(número de entradas en la tabla)
 ifTable contiene la información de cada interfaz:
 Información
prestaciones:
para
gestión
de
contabilidad
y
 Información estadística: número de paquetes enviados,
recibidos, descartados, multicast, erróneos, tamaño de
colas ...
MIB-II: Grupo interfaces
 Información para la gestión de configuración
 ifIndex: índice del interfaz
 ifDescr: descripción textual
 ifType: tipo de hardware que hay bajo la capa de
red
 ifMTU: tamaño de MTU para el interfaz
 ifPhysAddress: dirección física del interfaz
 ifSpeed: ancho de banda del interfaz (bits/seg)
MIB-II: Grupo interfaces
 Información para la gestión de fallos
 ifAdminStatus, ifOperStatus: estado deseado y
actual del interfaz (activo, inactivo o en modo de
pruebas)
MIB-II: Grupo interfaces
MIB-II: Grupo ip
 Información relativa al funcionamiento del protocolo IP
 Configuración: ipForwarding, ipDefaultTTL
 Estadísticas: número de datagramas recibidos y enviados, errores,
datagramas reensamblados y fragmentados....
 Tabla de direcciones: ipAddr Table

Información de las direcciones IP asignadas a esta entidad
 Útil para monitorizar la configuración de la red
 Tabla de encaminamiento: ipRouting Table
 Información de encaminamiento

Útil para monitorizar la configuración de la red, y para controlar el
proceso de encaminamiento (gestión de fallos, de seguridad o de
prestaciones)
 Tabla de traducción de direcciones: ipNetToMedia Table
 Correspondencia entre direcciones IP y direcciones físicas (tabla ARP)

Esta información está también en el grupo at, por compatibilidad con
MIB-I
MIB-II: Grupo ip
MIB-II: Grupo icmp
 Estadísticas relativas
al funcionamiento del
protocolo ICMP
 Diversos
contadores
sobre
tipos
de
mensajes
ICMP
enviados y recibidos
MIB-II: Grupo tcp
 Configuración del protocolo:
 tcpRtoAltorithm: algoritmo
de cálculo del timeout para
retransmisiones
 tcpRtoMin, tcpRtoMax:
valores mínimo y máximo
para el timeout
 Estadísticas de conexiones:
activas, pasivas, intentos
fallidos de conexión...
 Estadísticas sobre envío y
recepción de segmentos
 Tabla de conexiones TCP:
tcpConnTable
MIB-II: Grupo udp
 Estadísticas sobre envío
y recepción de
datagramas UDP
 Tabla de puertos para los
que hay una aplicación
aceptando datagramas
en la entidad: udpTable
 Cada entrada es un par
{udpLocalAdress,
udpLocalPort}
MIB-II: Grupo egp
 Estadísticas sobre envío
y recepción de mensajes
EGP (External Gateway
Protocol)
 Tabla egpNeighTable
 Información sobre los
encaminadores vecinos
conocidos
MIB-II: Grupo transmission
 Objetos que proporcionan información sobre el medio de
transmisión subyacente para cada interfaz del sistema
 Existen varias MIBs definidas para cada tipo de interfaz
 Algunas se hayan en fase experimental (rama experimental);
cuando se estandaricen, se moverán al grupo transmission
 Algunos ejemplos:
 MIB para IEEE 802.4 Token Bus (RFC 1230)
 MIB para IEEE 802.5 Token Ring (RFC 1231)
 MIB para FDDI (RFC 1285)
 MIB para Ethernet (RFC 1643)
 ...
MIB-II: Grupo snmp
 Estadísticas sobre paquetes SNMP enviados y
recibidos, errores en la sintaxis ASN.1, número
de GETs, SETs y TRAPs...
 Algunas implementaciones se optimizan para ser
agentes o gestores
 Devuelven 0 en aquellos objetos que no tienen
sentido para ellas
 Objeto snmpEnableAuthenTraps
 Indica a un agente si debe enviar un trap de error de
autentificación, al recibir un mensaje con nombre de
comunidad erróneo
MIB-II: Grupo snmp
SNMPv2: Introducción
 SNMP presenta algunas deficiencias:
 Seguridad
 Prestaciones y funcionalidad
 Julio 1992: se proponen dos protocolos para mejorar SNMP
 Secure-SNMP: trata de mejorar los aspectos de seguridad
 SMP (Simple Management Protocol): se centra en mejorar los
demás aspectos:
 Alcance: facilita la gestión no solo de recursos de red, sino de cualquier
recurso (aplicaciones, comunicación entre gestores, ...)
 Tamaño, velocidad y eficiencia: desarrollo de una capacidad de
transferencia de bloques de información
 Seguridad y privacidad: incluyendo las mejoras de secure-SNMP
 Utilización y compatibilidad: SMP está diseñado para ejecutarse sobre
TCP/IP, OSI y otras arquitecturas de comunicación; también puede
interoperar con plataformas SNMP
SNMPv2: Introducción
 Tras la publicación de S-SNMP y SMP, se decidió
combinar ambos y proporcionar una única
evolución de SNMP
 Marzo/1993:
 Surge SNMPv2, en forma de propuesta de estándar
 1996
 Se especifica finalmente SNMPv2, tras varios años de
pruebas
 Finalmente, en SNMPv2 quedan las mejoras de
eficiencia y compatibilidad, pero se eliminan las
mejoras de seguridad, por falta de un consenso en
cuanto al método a adoptar
SNMPv2: Estructura del SMI
 La SMI de SNMPv2 expande la de la versión 1 en
varias maneras:
 Ampliación de la macro de definición de los tipos de datos
 Se permiten enumeraciones
 Los enteros son de 32 bits
 Se incluye el tipo de direcciones OSI NSAP, además de las IP
 Existen contadores de 64 bits
 Mejor definición del tipo Gauge
 Mejora de la documentación de cada objeto
 Cláusula UNITS
 Nuevas convenciones para la creación y eliminación de filas
en una tabla
SNMPv2: Estructura de la MIB
 Se
definen dos MIBs
especificación de SNMPv2:
dentro
de
la
 La MIB SNMPv2: información relacionada con la
operación y configuración del protocolo, y de
agentes y gestores
 La MIB M2M (Manager to Manager): soporte para
la arquitectura de gestión distribuida
SNMPv2: Estructura de la MIB
 La MIB SNMPv2 incluye cinco grupos:
 Estadísticas SNMPv2
 Estadísticas SNMPv1
 Recursos de Objeto: objetos que permiten a una
entidad SNMPv2 actuar como un agente, y que son
objeto de configuración dinámica por parte del gestor
 Grupo de Traps: objetos que permiten que una entidad
agente SNMPv2 genere PDUs de tipo TRAP SNMPv2
 Grupo Set: permite la cooperación de entidades
gestoras SNMPv2, para coordinar el uso de la
operación Set
SNMPv2: Estructura de la MIB
 La MIB M2M (Manager to Manager) incluye
dos grupos:
 snmpAlarm: colección de objetos que permiten
describir y configurar umbrales de alarma en una
entidad SNMPv2 actuando como agente y como
gestor
 snmpEvent: colección de objetos que permiten la
descripción y configuración de eventos de una
entidad SNMPv2, realizando un papel doble
SNMPv2: Operación del protocolo
 SNMPv2 define dos nuevas PDU’s:
 Intercambio de información entre gestores:
InformRequest
 Siempre contiene las variables sysUpTime.0 (MIB-II) y
SNMPTrapOID.i (MIB M2M)
 SNMPv2TrapOID.i contiene el identificador de objeto
del tipo de evento
 Transferencia eficiente de grandes bloques de
datos: GetBulkRequest
 Similar a GetNextRequest en la forma de especificar el
inicio de la información a recuperar, pero pudiendo
seleccionar múltiples sucesores lexicográficos
SNMPv2: Operación del protocolo
SNMPv2: Operación del protocolo
 Otras diferencias:
 La PDU de Trap tiene el mismo formato que las
demás, excepto GetBulkRequest, para facilitar su
procesamiento en el receptor
 Siempre se incluye el valor de las variables
sysUpTime.0, y snmpTrapOID.0 (SNMPv2 MIB)
 Se pueden incluir más variables
 GetRequest y GetNextRequest no son atómicas
SNMPv2: Otras caraterísticas
 Declaraciones de conformidad
 La especificación de SNMPv2 incluye la definición de
un notación para especificar niveles mínimos
aceptables de implementación, junto con el nivel de
implementación real alcanzado
 Protocolos de transporte soportados





UDP (preferido)
OSI Connectionless-Mode Network Service (CLNS)
OSI Connection-Oriented Network Service (CONS)
Novel IPX
Appletalk
SNMPv2: Coexistencia con SNMP
 En
la especificación de SNMPv2 se hacen
recomendaciones para permitir y facilitar la
coexistencia con SNMPv1
 La información de gestión de SNMPv2 es un superconjunto
de la de SNMPv1
 Para compatibilizar las operaciones del protocolo,
hay dos posibilidades:
 Emplear un agente proxy: este agente interactuará con los
agentes SNMP, y con los gestores SNMPv2
 Emplear un gestor bilingüe: el gestor contactará con cada
agente empleando el protocolo adecuado
 Esto debe ser transparente a la aplicación de gestión
SNMPv2: Coexistencia con SNMP
SNMPv2: Coexistencia con SNMP
SNMPv3
 En la versión final de SNMPv2 finalmente se descartaron las
mejoras a la seguridad, por falta de consenso
 Se intenta añadir seguridad a SNMPv2, proponiendo SNMPv2u y
SNMPv2*
 A partir de ellos, en 1998 surge SNMPv3
 Define una serie de capacidades de seguridad y un marco que
hace posible su uso junto con las PDUs de SNMPv1 o SNMPv2
 SNMPv3 define un conjunto de mecanismos de seguridad
 Protección
contra las amenazas de modificación de la
información, enmascaramiento, modificación del flujo de
mensajes y revelación de contenidos
 No contempla la protección frente a la denegación de servicio o el
análisis del tráfico
SNMPv3
 Se definen dos capacidades relacionadas con la seguridad:
 Modelo de seguridad basado en el usuario (USM, User-based
Security Model)
 Proporciona funciones de autentificación y privacidad (encriptado)
 Opera a nivel de mensaje
 Modelo de control de acceso basado en vistas (VACM, View-
based Access Control Model)
 Determina si a una entidad dada se le permite el acceso a ciertos
objetos de un MIB, para ejecutar acciones concretas: implementa
un control de acceso a los objetos
 Funciona a nivel de PDU (subsistema de control de acceso)
 La MIB también se amplía para contemplar las nuevas
informaciones necesarias para la gestión
 RFC 3418 “Management Information Base (MIB) for the Simple
Network Management Protocol (SNMP)”

similar documents