PDF de programación - GESTIÓN INTERNET

GESTIÓN INTERNET

2.3 SMI
Cada objeto a gestionar debe ser representado por un
objeto. El MIB es una colección estruturada de objetos.
Cada nodo en el sistema será mantenido en el MIB, que
reflejará el estado del recurso gestionado en ese nodo.
Para que esto sea posible, se necesita un esquema
común
la
interoperatibilidad entre los nodos.

representación

de

que

soporte

2.3.1 Estructura de la información de gestión

Determina la forma en la que debe definirse y construirse
una MIB.

Proporciona técnicas de estandarización para:

• Definir la estructura de un determinado MIB.
• Definir los objetos individuales, incluyendo la
sintaxis y valor.
• Codificación de los valores de estos objetos.

Estructura de la MIB
Cada tipo de objeto de un MIB tiene asociado un OBJECT
IDENTIFIER que lo nombra y cuya organización es
jerárquica (en forma de árbol). Este valor consiste en
una secuencia de enteros no negativos.

GESTIÓN DE REDES

GESTIÓN INTERNET

El subárbol 1.3.6.1 se refiere a la subrama de internet
que define cuatro tipos de nodos internet (grupos):

• directory: Reservado para OSI directory (X.500).
• mgmt: Destinado a objetos definidos por la IAB (MIB
I y MIB II).
• experimental: Objetos usados en
experimentales.
• private: Objetos definidos de manera unilateral
(empresas).

temas

Las estructura de estas MIBs son definidas utilizando la
sintaxis ASN.1

GESTIÓN DE REDES

GESTIÓN INTERNET

ARBOL DE REGISTRO ISO

iso (1)

org (3)

dod (6)

internet (1)

directory (1)

mgmt (2)

mib-2 (1)

system (1)

interfaces (2)

at (3)

ip (4)

icmp (5)

tcp (6)

udp (7)

egp (8)
transmission (10)
snmp (11)

experimental (3)

private (4)

enterprises (1)

GESTIÓN DE REDES

GESTIÓN INTERNET

Contructores de la Macro del RFC 1212:

SYNTAX: Sintaxis abstracta del tipo de objetos. Los tipos de datos
aceptables son un subconjunto muy reducido de los valores permisibles
en ASN.1

Tipos Básicos:

INTEGER (UNIVERSAL 2), OCTET STRING (UNIVERSAL 4), NULL
(UNIVERSAL 5), OBJECT IDENTIFIER (UNIVERSAL 6), SEQUENCE,
SEQUENCE OF (UNIVERSAL 16).

Tipos Compuestos:

•Network Address: CHOICE de direcciones de red. Actualmente,
sólo...
•IpAddress: Dirección IP en 32 bits.
•Counter: Entero no negativo que sólo puede incrementarse (hasta
2E32-1). Si se alcanza el máximo, vuelve a 0.
•Gauge: Entero no negativo que puede crecer o decrecer limitado a
2E32-1. Si se alcanza, permanece ahi hasta un reset.
•TimeTicks: Entero no negativo que representa el tiempo transcurrido
en centésimas de segundo desde un determinado
instante
identificado en la definición del objeto que lo utiliza.
•Opaque: Para enviar datos de tipos arbitrarios como secuencias de
octetos.

ACCESS: Define la forma en que una instancia de un objeto puede ser
accedida. permite restricciones específicas para una implementación.
STATUS: Especifica si se requiere que sea soportado por las
implementaciones.
DescrPart: Descripción textual de la semántica del objeto.
ReferPart: Referencia textual a otro objeto definido en otros modulos.

GESTIÓN DE REDES

GESTIÓN INTERNET

IndexPart: Requerido cuando se definen tablas.
DefValPart: Se utiliza para definir valores por defecto para los tipos de
datos. Se utilizan cuando se crean las instancias en el agente.
VALUE NOTATION: Nombre del objeto necesario para acceder a él
cuando se utiliza SNMP (Su posición dentro del árbol de registro).

Definición de tablas:
El soporte lo van a dar:

•El tipo SEQUENCE y SEQUENCE OF de ASN.1.
•El constructor INDEX de la Macro Object Type.

No se permiten anidaciones de tabla.

Para definir una tabla en SNMP:

1.- Definición de un objeto xxxTable:
•Sintaxis: SEQUENCE OF Tipo
•Not accessible.

2.- Definición de un objeto xxxEntry debajo de xxxTable:

•Sintaxis: Tipo ::= SEQUENCE. Un campo por columna de la tabla.
•Not accessible.
•Constructor INDEX indicando el(los) campo(s) que identifican
unívocamente cada entrada de la tabla.

3.- Definición de N objetos columna debajo de xxxEntry:

•Sintaxis: coincidente con el campo correspondiente del SEQUENCE
anterior.

GESTIÓN DE REDES

GESTIÓN INTERNET

•Regla de acceso dependiente de la semántica de la columna.

Ejemplo: La tabla de conexiones de TCP.

Codificación de los valores:

Siguiendo las Basic Encoding Rules de ASN.1

2.3.2 Management Information Base I (RFC 1155)
Constituyó la primera MIB normalizada y estandarizaba
la definicion de los objetos de la torre de protocolos TCP/
IP:

GRUPO

NUMERO

DESTINO

system
interfaces
at
ip
icmp
tcp
udp
egp

3
22
3
33
26
17
4
6

El propio sistema
Interfaces de red
Correspondencia de direcciones IP.
Internet Protocol.
Internet Control Message Protocol.
Transmision Control Protocol
User Datagram Protocol
Exterior Gateway Protocol

GESTIÓN DE REDES

GESTIÓN INTERNET

2.3.3 Management Information Base II (RFC 1213)

GRUPO

NUMERO

DESTINO

system
interfaces
at
ip
icmp
tcp
udp
egp

3
22
3
33
26
17
4
6

El propio sistema
Interfaces de red
Correspondencia de direcciones IP.
Internet Protocol.
Internet Control Message Protocol.
Transmision Control Protocol
User Datagram Protocol
Exterior Gateway Protocol

Define un superconjunto de la MIB I pero con objetos y
grupos adicionales. Se desestimó la tabla at (address
translation).

GRUPO

NUMERO

COMENTARIOS

system
interfaces
at
ip
icmp
tcp
udp
egp

7
223
3
38
26
19
7
18

Eran 3
Eran 22
Mantenidos por compatibilidad
Eran 33
Sin cambio
Eran 17
Nueva tabla
Expansión de tabla

GESTIÓN DE REDES

GESTIÓN INTERNET

GRUPO

NUMERO

COMENTARIOS

trnasmission
snmp

0
30

Nuevo grupo
Nuevo grupo

Criterios de diseño de la MIB-II:

•Se incluyen objetos esenciales para gestión de
configuración y fallos. Y de los que sea evidente su
necesidad actual.
•Sólo se permiten objetos de control débiles (o sea,
que no puedan causar muchos destrozos si son mal
utilizados)
•Límite en el número de objetos para adecuarse a la
tecnología.
•Se evita al máximo la redundancia de información.
•Sólo
incluyen aspectos genéricos, no
dependientes de la implementación => No hay
objetos opcionales.

se

Los objetos gestionados están divididos en grupos por
cercanía semántica. La idea es que un agente debe
implementar un grupo completo si es aplicable al equipo
que controle.

2.3.4 MIBs experimentales
Son MIBs en desarrollo por los grupos de trabajo de
Internet. Actualmente existen multitud de MIBs

GESTIÓN DE REDES

GESTIÓN INTERNET

experimentales:

TITULO

RFC

FECHA

IEEE 802.5 Token Ring
IEEE 802.4 Token Bus
IEEE 802.3 Repeater Devices
Ethernet
FDDI
RMON
ATM
Modem

1231
1230
1516
1398
1512
1271
1695
1696

Mayo 1991
Mayo 1991
Septiembre 1993
Enero 1993
Septiembre 1993
Noviembre 1991
Agosto 1994
Agosto 1994

2.3.5 MIBs privadas
MIBs de productos específicos, que añaden
funcionalidad a las MIB estándar.

Los fabricantes las hacen públicas por Internet (depósito
común en isi.edu).
MIBs para productos de Cabletron, Synoptis, ATT,
Cisco, IBM, etc....

GESTIÓN DE REDES

GESTIÓN INTERNET

2.3.6 EL PROTOCOLO SNMP
RFC 1157
Sólo se permiten GET, SET y TRAP.
No se permiten cambios en la estructura de la MIB
(añadir, eliminar objetos), invocar acciones...

implementación,

la

limitaciones en

Sencillez de
funcionalidad.
Communities:
Relación 1-n entre agente y gestores, con el agente
manteniendo la información de la MIB (necesidad de
mecanismos de seguridad).
Community: Relación entre un agente y varios gestores
con unas características determinadas de control de
acceso y autentificación.

La definición de las communities es local al agente y
llevan asociado un nombre.
Autentificación:
¡Se usa simplemente el community name sin cifrar!
Política de control de acceso:

GESTIÓN DE REDES

GESTIÓN INTERNET

Definiendo diferentes communities podemos permitir
distintas vistas de la MIB, con diferentes objetos y
diferentes permisos de acceso (READ-ONLY, READ-
WRITE) -> Es el community profile.
Hay que combinar la declaración de acceso realizada
con SMI al definir la MIB con la del community profile del
gestor que accede:

Según la MIB

Según la Community

Según la Community

READ-ONLY

READ-WRITE

READ-ONLY

GETs y TRAPs.

GETs y TRAPs.

READ-WRITE

GETs y TRAPs.

GETs, SETs y TRAPs.

WRITE-ONLY

GETs y TRAPs
El valor depende de la implementación.

GETs SETs y TRAPs
El valor depende de la implementación
en los GETs y TRAPs.

NOT-ACCESSIBLE

No disponible.

No disponible.

Identificación de instancias:
En base al OBJECT IDENTIFIER, pero....
...¿cómo lo hacemos en las tablas?

Cada tabla contiene cero o más filas con conjuntos de
objetos columna. Cada objeto columna lleva asociado su
OID (OID de la tabla + Identificador).

Falta conocer a qué fila nos referimos: Para ello se utiliza
la clave que permite identificar cada fila, indicada por el
constructor INDEX de SMI (puede ser múltiple).

GESTIÓN DE REDES

GESTIÓN INTERNET

y.(i1).(i2). . . . .(in) , donde y es el OID del objeto
columna y ij, son subidentificadores con los valores de
sus campos índice para ese objeto.

Representación de los valores de los objetos como
subidentificadores:

•Enteros: Un subidentificador con el valor.
•Cadenas de longitud fija: n subidentificadores, uno
por caracter.
•Cadenas de longitud variable: un subidentificador
con la longitud (n) más n para la cadena.
•Oids: un subidentificador con la longitud (n) más n
para la cadena de números.
•Direcciones IP: Cuatro identificadores con el formato
habitual.

Para algunas tablas antiguas esto no se cumplia: una
solución era marcar las líneas con la misma clave con
otro identificador, pero la tendencia ha sido irlas
eliminando de la MIB.

No hay identificadores para tablas ni filas (no son
accesibles).

Los objetos escalares llevan el subidentificador 0 para
diferenciar tipo e instancia.

Mediante este sistema, podemos establecer un