universidad autónoma metropolitana unidad …148.206.53.84/tesiuami/uam4381.pdf · información....
TRANSCRIPT
Casa Abierta al Tiempo
UNIVERSIDAD AUTóNOMA METROPOLITANA
UNIDAD IZTAPALAPA
. División de Ciencias Básicas e Ingenieria
Departamento de Ingenieria Eléctrica
lnternet
Reporte de Proyecto de Investigación I y I1
Tesis que presenta el alumno(a)
Abel Chávez Estrada 933 7 8382
Para obtener el grado de :
Licenciatura en Computación
Octubre 2002.
TABLA DE CONTENIDO. Pag
4.5.2.3 Cláusula OBJECTS ...................................................................... 36 4.5.2.4 Cláusula STATUS .......................................................................... 36 4.5.2.5 Cláusula DESCRIPTION ............................................................... 36 4.5.2.6 Cláusula REFERENCE- ................................................................ 36 4.5.2.7 Valor de la NOTIFICACIÓN-TYPE ............................................... 36 4.5.2.8 Ejemplo de Uso .............................................................................. 37
37 4.6.1 Modificando Definiciones de Objetos .............................................. 37
4.6.1.1 Modificando la Definición de la Notificaciones .................... 38 4.6.2 Módulos MIB .................................................................................... 39
4.6.2.1 Las Diferentes Clases de los Módulos MIB ....................... 39 4.6.2.2 MIB Internet-Standar ............................................................ 39 4.6.2.1 Las Diferentes Clases de los Módulos MIB ....................... 39 4.6.2.1 Las Diferentes Clases de los Módulos MIB ........................ 39
39 4.6.3.1 Grupo System ....................................................................... 40
4.6.3.2 Grupo SnmpSet ..................................................................... 44 4.6.3.3 Innovaciones de Tipo Estándar ........................................... 46
4.7 Sentencias de Conformidad ........................................................................ 47
4.7.1.1 Importando Definiciones de Macros ................................... 48 4.7.1.2 Resumen ................................................................................. 49
4.8 Modelo Administrativo ................................................................................. 50 4.8.1 Conceptos ........................................................................................ 50 4.8.2 Autentificaclon 50 4.8.3 Privacidad 51 4.8.4 Autorizaclon 51
4.8.5 Comunidades 51 4.8.6 Procedimientos 53 4.8.7 Originado un Mensaje ...................................................................... 53 4.8.8 Recibiendo un Mensaje 53 4.8.9 Esperando por Mensajes ................................................................. 54
5 . MODELO OPERACIONAL- ............................................................................... 54 5.1 lnteracciones del Protocolo ........................................................................ 55
5.1 . 1 I nteracciones ..................................................................................... 58 5.1.2 lnteracclon de Excepciones 59 5.1.3 lnteracclon de Error 60 5.1.4 lnteracclon de Timeout ..................................................................... 60 5.1.5 Interacción al Procesamiento .......................................................... 61
5.2 Peticiones de Recuperaclon ........................................................................ 61 5.2.1 El Operador Get ................................................................................ 61 5.2.2 El Operador Get-Next ...................................................................... 61 5.2.3 El Operador Get-Bulk ....................................................................... 62
5.3 Peticiones de Modificacm 5.3.1 El Operador Set ................................................................................ 66
5.4 Manejo de Filas de Conceptos .................................................................. 66 5.4.1 Creación de una Fila de Conceptos ............................................... 67
5.4.1 . 1 Aproximaclon Directa." ......................................................... 68 5.4.1.2 Aproximación Negociada ...................................................... 69
5.4.2 Modificación de una Fila de Conceptos ......................................... 70 5.4.3 Eliminación de una Fila de Conceptos ........................................... 70
71
4.6 Revision de un Módulo MIB ..
.........................................................................
4.6.3 MIB SNMPv2 ...................................................................................
4.7.1 MODULE-COMPLIANCE ................................................................ 48
.. .................................................................................
......................................................................................... .. ...................................................................................... ....................................................................................
.................................................................................
...................................................................
.. ............................................................. . .
.......................................................................... ..
* I
. . 64 .........................................................................
. .
5.5 I nteracciones de I nvocaclon 5.5.1 El Grupo SnmpTrap ......................................................................... 71
5.6 lnteracciones entre Administradores ......................................................... 71 5.6.1 Entidades de Doble Rol ................................................................... 72
.. .......................................................................
5.7 M a w de Transporte .____....______..._____..______.._______.______. ~ ______._______..______ ~ _______.... 72 5.7.1 Direcciones y Dominios de Transporte _.__________.____.__ ~ __________________.___ 72
5.7.1.1 Dominio snmpUDPDomain __._______..______.______.______..__.___.______..___ 73 5.7.1.2 Dominios snmpCLNSDomain y snmpCONSDomain ....73
5.7.1.3 Dominios snmpDDPDomain ________________________________.._ ~ ____._ ~ ______. 74 5.7.1.4 Dominios snmplPXDomain _._____.__.____.._____.___.__________.___.______._._ 75
5.8 Resumen ............................................................. ~ ................................... - .... 76 6. MANUAL DE USUARIO ___________________.______.___.__________.__.____._______._____________.__.___._____ 77
6.1 lntroducclon .................................................................................................. 77 6.2 Fundamentos de la Simulaclon _..._____.___________.________._________._____________________.___ 77 6.3 Variables a Incluir _____________._____.___ ~ _______.__ ~ ._____ ~ ______________________.____.__.___.____________ 79
6.3.1 Significado de las Variables .__.___.___.______.__._.____.____.__.______._____._____.._.._ 80 6.4 Generando el Módulo MIB 81 6.5 Opciones de Simulaclon ___._____...___.__.___._____________._____.______.____._______ ~ _____._________ 82 6.6 Resultados de la Simulación ________.__._.___.___._____________.__._.___.._____._.__._____.____.___ 83
7. CONCLUSIONES ........................................................................ ~ __._.................. 85
8. BIBLIOGRAFíA ~ _ _ _ _ _ _ ~ ................................................................................. 86
. I
.,
.,
I .- INTRODUCCI~N
En una lnternet se conectan varias redes entre sí con el uso de routers y un protocolo
de interconexión de redes, de modo que los routers usan el protocolo para encubrir las
características de las redes y proporcionar un servicio uniforme entre ellas, es decir,
aunque cada red use una tecnología distinta y unas reglas específicas de transmisión,
los hosts de cada red ven a la red de igual manera. Este es el poder de la abstracción
de la interconexión entre redes.
La principal tecnología de interconexión de redes es el conjunto de protocolos de
lnternet llamados TCP/IP, que se crearon en la Agencia de Proyectos de Investigación
Avanzada de Defensa (DARPA) y que son los que se usan en la Red Internet, (con
mayúscula, la red de redes global) pero también en la interconexión de redes menores
Internet, (con minúscula, redes locales).
SNMP se sitúa en el tope de la capa de transporte de la pila OSI, o por encima de la
capa UDP de la pila de protocolos TCPIIP. Siempre en la capa de transporte.
Gráficamente se podría ver así:
I ADlicación I SNMP
Transporte(TCP,UDP ,...) Interred(1P)
lnterfase de red Física
1 .I .- Desarrollo de Aplicaciones de Interconexión entre Redes
TCPllP es un conjunto de protocolos que permite interconectar una numerosa cantidad
de sistemas en Internet. TCP/IP proporciona una interface de programación para una
gran cantidad de hardware, y con ello es posible que varias redes con
implementaciones de hardware distintas puedan convivir en un ambiente de
comunicación armonioso. TCP/IP es el conjunto de protocolos que da lugar a la
existencia de Internet, y por ello, se consideró importantísirno incorporar la facilidad de
desarrollar aplicaciones distribuidas con Java.
1
Es importante señalar que existen dos modelos bien establecidos que fueron
propuestos para solucionar la interconexión entre redes de comunicación, y ellos son
el modelo OS1 de ISO, y
el modelo TCPIIP. Se puede hacer una comparación entre ambos modelos viendo al
modelo TCP/IP compuesto de cuatro capas:
Aplicación
Transporte
Red
Enlace
Cada capa tiene funciones especificas, y a continuación se sintetiza la utilidad de cada
una de ellas.
Capa de Aplicación.
En el nivel más alto, los usuarios llaman a una aplicación que accesa servicios
disponibles a través de la red de redes TCPIIP. Una aplicación interactúa con uno de
los protocolos de nivel de transporte para enviar o recibir datos. Cada programa de
aplicación selecciona el tipo de transporte necesario, el cual puede ser una secuencia
de mensajes individuales o un flujo continuo de octetos. El programa de aplicación
pasa los datos en la forma requerida hacia el nivel de transporte para su entrega.
Las aplicaciones de red dependen de la definición de un diálogo transparente. En un
sistema cliente/servidor, la aplicación de cliente sabe cómo solicitar servicios, y el
servidor conoce como responder de manera adecuada. Ejemplos de protocolos que
funcionan en esta capa son HTTP, FTP, y Telnet.
Capa de Transporte.
La principal tarea de la capa de transporte es proporcionar la comunicación entre un
programa de aplicación y otro. Este tipo de comunicación se conoce frecuentemente
2
como comunicación punto a punto. La capa de transporte regula el flujo de
información. Puede también proporcionar un transporte confiable, asegurando que los
datos lleguen sin errores y en secuencia. Para hacer esto, el software de protocolo de
transporte tiene el lado de recepción enviando acuses de recibo de retorno y la parte
de envío retransmitiendo los paquetes perdidos. El software de transporte divide el
flujo de datos que se está enviando en pequeños fragmentos (por lo general conocidos
como paquetes) y pasa cada paquete, con una dirección de destino, hacia la siguiente
capa de transmisión. La capa de transporte debe aceptar datos desde varios
programas de usuario y enviarlos a la capa del siguiente nivel. Para hacer esto, se
añade información adicional a cada paquete, incluyendo códigos que identifican qué
programa de aplicación envía y qué programa de aplicación debe recibir, así como una
suma de verificación. La máquina de recepción utiliza la suma de verificación para
verificar que el paquete ha llegado intacto y utiliza el código de destino para identificar
el programa de aplicación en el que se debe entregar.
Esta capa permite a las aplicaciones de red obtener mensajes sobre canales
claramente definidos y con características especificas. Los dos protocolos de la familia
TCPllP que se implementan generalmente en estas capas son TCP (Transmission
Control Protocol) y UDP (User Datagram Protocol).
Capa de Red.
La capa de red maneja la comunicación de una máquina a otra. Ésta acepta una
solicitud para enviar un paquete desde la capa de transporte, junto con una
identificación de la máquina, hacia la que se debe enviar el paquete. Encapsula el
paquete en un datagrama IP, llena el encabezado del datagrama, utiliza un algoritmo
de ruteo para determinar si se puede entregar el datagrama directamente o si debe
enviarlo a un ruteador y pasar el datagrama hacia la interfaz de red apropiada para su
transmisión. La capa de red también maneja la entrada de datagramas, verifica su
validez y utiliza un algoritmo de ruteo para decidir si el datagrama debe procesarse de
manera local, el software de la capa de red de redes borra el encabezado del
datagrama y selecciona, de entre varios protocolos de transporte, un protocolo con el
que manejará el paquete. Por último, la capa de Internet envía los mensajes ICMP de
error y control necesarios y maneja todos los mensajes ICMP entrantes.
3
Esta capa permite que se transmita la información a cualquier máquina sobre una red
TCP/IP, independiente de las distintas características físicas que intervengan. El
protocolo IP (Internet Protocol) es el mecanismo para transmitir datos dentro de esta
capa.
Capa de Enlace.
El software TCP/IP de nivel inferior consta de una capa de enlace o interfaz de red
responsable de aceptar los datagramas IP y transmitirlos hacia una red específica.
Una interfaz de red puede consistir en un dispositivo controlador (por ejemplo, cuando
la red es una red de área local a la que las máquinas están conectadas directamente)
o un complejo subsistema que
utiliza un protocolo de enlace de datos propio (por ejemplo, cuando la red consiste de
conmutadores de paquetes que se comunican con anfitriones utilizando HDLC).
Esta capa consiste de los protocolos de bajo nivel usados para transmitir datos a las
máquinas sobre la misma red física. En esta capa se implementan los protocolos que
no son parte de la familia TCP/IP, tales como Ethernet, Token Ring, FDDI, o ATM.
Dentro de esas capas, se encapsulan los datos con un mecanismo en común:
protocolos con un encabezado, que identifican información tal como la fuente, el
destino, y otros atributos, además de una porción de datos que contiene la
información. Los protocolos de las capas superiores se encapsulan dentro de la
porción de datos de las capas inferiores. Cuando vienen de regreso, se reconstruye la
información tal y como fue liberada a cada capa.
Protocolos de TCP/IP
En el esquema de TCP/IP, tres son los protocolos más utilizados, y ellos son: IP, TCP,
y UDP. El entender su funcionamiento es esencial para poder desarrollar aplicaciones
de interconexión entre redes.
IP (Internet Protocol)
Todos los datos en Internet viajan a través de paquetes IP, que son la unidad básica
de transmisiones IP. A IP se le conoce como un protocolo no orientado a conexión, y
4
no confiable. Como protocolo no orientado a conexión, IP no intercambia información
de control antes de transmitir datos a un sistema remoto; es decir, que los paquetes se
envian al destino esperando que lleguen a éste de manera edecuada. Se dice que IP
es no confiable por que no retransmite paquetes perdidos ni detecta datos con error.
Se le dejan esas tareas a protocolos que funcionen en niveles más altos, como TCP.
IP define un esquema universal de direccionamiento que se conoce como dirección IP.
Una dirección IP es un número de 32 bits, y cada dirección estándar es única en
Internet. Dado un paquete IP, se puede rutear la información al destino basándose en
la dirección IP que se encuentra definida en el encabezado IP. Estas direcciones se
escriben generalmente en un formato de cuatro números, entre O y 255, separados por
un periodo. Por ejemplo, la dirección IP del servidor de correo de la Universidad
Autónoma Metropolitana es 148.206.32.5.
TCP (Transmission Control Protocol)
La mayor parte de las aplicaciones de Internet utilizan a TCP para implementar a la
capa de transporte. TCP proporciona un protocolo confiable, orientado a conexión, y
de flujo continuo. El ser confiable significa que cuando se pierden o se contaminan con
errores segmentos TCP, son la unidad más pequeña de transmisión para TCP, el
protocolo detectará esto y retransmitirá los segmentos asociados. El ser orientado a
conexión significa que el protocolo establece una conexión con el sistema remoto
antes de comenzar la comunicación, transmitiendo información de control. En el otro
extremo de la conexión, se finaliza transmisión de manera similar. Y , el que sea de
flujo continuo significa que TCP proporciona un medio de comunicación que permite
que se envíe un número arbitrario de bytes y se reciban de manera adecuada; una vez
que se ha estabilizado una conexión, los segmentos TCP proporcionan a la capa de
aplicación la apariencia de un flujo continuo de datos.
Un concepto importante que se maneja con TCP es el de puerto. Un puerto separa
varios flujos de comunicación TCP que se ejecutan concurrentemente sobre el mismo
sistema. Para aplicaciones de servidor, que esperan a que los clientes TCP inicien el
contacto, se puede estabilizar un puerto específico a partir del cual se van a originar
las comunicaciones. Para implementar esto como una abstracción en un sistema de
software, se utiliza el término de sockets.
UDP (User Datagram Protocol)
En el grupo de protocolos TCPIIP, el Protocolo de datagrama de usuario o UDP
proporciona el mecanismo primario que utilizan los programas de aplicación para
enviar datagramas a otros programas de aplicación. El UDP proporciona puertos de
protocolo utilizados para distinguir entre muchos programas que se ejecutan en la
misma máquina. Esto es, además de los datos, cada mensaje UDP contiene tanto el
número de puerto de destino como el número de puerto de origen, haciendo posible
que el software UDP en el destino entregue el mensaje al receptor correcto y que éste
envie respuesta.
El UDP utiliza el Protocolo Internet subyacente para transportar un mensaje de una
máquina a otra y proporciona la misma semántica de entrega de datagramas, sin
conexión y no confiable que el IP. No emplea acuses de recibo para asegurarse de
que llegan mensajes, no ordena los mensajes entrantes, ni proporciona
retroalimentación para controlar la velocidad a la que fluye la información entre
máquinas.
Por lo tanto, los mensajes UDP se pueden perder, duplicar o llegar sin orden. Además,
los paquetes pueden llegar más rápido de lo que el receptor los puede procesar.
Este protocolo es una alternativa a usar TCP, y tiene un overhead mucho menor. A
diferencia de TCP, UDP es no confiable, no orientado a conexión, y orientado a
mensajes. Esta última característica indica que UDP permite que las aplicaciones
envíen mensajes contenidos en datagramas UDP, que son la unidad de transmisión de
este protocolo. La aplicación debe encapsular toda la información en datagramas.
Un programa de aplicación que utiliza el UDP acepta la responsabilidad por el manejo
de problemas de confiabilidad, incluyendo la pérdida y retraso de los mensajes, la
entrega fuera de orden y la pérdida de conectividad. Por lo tanto, muchos programas
de aplicación que confían en el UDP trabajan bien en un ambiente local, pero fallan
dramáticamente cuando se utiliza en una red de redes TCP/IP más grande.
Introducción al Protocolo SNMP
Los marcos de gestión estándar tradicionales (tales como SNMP (Simple Network
Management Protocol, Protocolo Simple de Gestión de Redes) [SNMP], aplicado en
6
Internet, o CMlP (Common Management Information Protocol, Protocolo Común de
Información de Gestión) [X701], aplicado en TMN (Telecommunication Management
Network, Red de Gestión de Telecomunicación)[TMN] ) fueron concebidos a principios
de los años 90 para la gestión de Redes de Comunicación. Fueron ellos quienes
adoptaron el modelo gestor-agente, que gobierna las interacciones entre las distintas
aplicaciones de gestión. Dichos modelos son orientados a objetos, pero únicamente en
términos de especificación de la información que modela los recursos a gestionar y
que intercambian gestor y agentes entre sí, dejando deliberadamente sin especificar
aspectos que son relevantes a la estructura interna de las aplicaciones de gestión.
Por otro lado, OMG (Object Management Group, Grupo de Gestión de Objetos)
CORBA (Common Object Request Broker Architecture, Arquitectura Común de
Intermediación de Peticion de Objetos) tOMG.981 y tecnologías similares emergen del
mundo de los sistemas distribuidos y pueden considerarse como aplicaciones
prácticas del Procesamiento Abierto de Objetos Distribuidos (ODP, Open Distributed
Processing [ODP]). Están enfocados hacia un paradigma orientado a objetos y
abarcan principalmente aspectos de interfaz, dado que usan un protocolo de propósito
general de Llamada a Procedimiento Remoto (RPC, Remote Procedure Call) [Pav1.97]
Teniendo en cuenta dichas tecnologías, las Plataformas de Procesamiento Distribuido
Orientadas a Objetos están siendo cada vez más importantes en el mundo de los
servicios de telecomunicación: Modularidad, independencia de la plataforma,
reusabilidad, transparencia en las comunicaciones, etc. son ventajas a tener en
cuenta para dichos servicios de telecomunicación, tal y como propugna TINA-C
(Telecommunication Information Networking Architecture, Arquitectura de Red de
Información de Telecomunicación) tTINA.981.
Función de un sistema de gestión de red.
La función de un sistema de gestión de red es monitorizar y configurar todos los
elementos de una red, tanto de hardware como de software. En un sistema de gestión
de red, cada elemento utiliza un programa, llamado agente, para comunicar su estado
y su información de configuración al software centralizado de gestión, llamado gestor
(más conocido como manager, aunque sea un anglicismo). Los elementos de una red
y los atributos de los dispositivos gestionados se adaptan bien a un modelo jerárquico
7
de organización, por lo que esta información se acostumbra a organizar en una
estructura en árbol.
Estándares de Gestión de redes.
Los operadores de las redes de datos fueron los primeros en plantearse la necesidad
de desarrollar unos protocolos de gestión estándares que permitieran acceder
uniformemente a cualquier elemento de red independientemente del fabricante. Pero
no sólo interesaba que el acceso fuera uniforme, sino que esta uniformidad también
era necesaria en la semántica de la información de gestión. Se pretendía evitar la
situación inicial, en la cual dos dispositivos con la misma funcionalidad pero
procedentes de diferentes fabricantes, proporcionaban métodos muy diferentes para la
obtención de datos.
Con la elaboración de estándares se podría implementar consultas a dispositivos de
red, así como configurar parámetros de los mismos, dando una apariencia uniforme a
los datos enviados por el gestor y a los devueltos por el dispositivo.
2.- MODELO DE GESTIóN SNMP.
El protocolo SNMP (Simple Network Management Protocol) se define en el RFC 11 57,
y aunque su nombre indique lo contrario sólo es sencillo si se compara con el modelo
de gestión propuesto para OS1 (CMIP).
En su origen, SNMP era una especificación interina, y como tal fue diseñado e
implementado; tenía que servir para comunicar con dispositivos de red mientras que el
estándar OS1 se acababa de materializar hacia el final de la década de los ochenta. Se
suponía que SNMP desaparecería en cuanto OS1 fuera una realidad, pero no ocurrió
así. En 1993, cuando OS1 acabó de madurar, SNMP ya tenía tres años de vida y
estaba implementado en cientos de productos. Lejos de ser una solución provisional,
SNMP se ha convertido actualmente en el estándar de facto de la gestión de red. Su
popularidad se debe a que, como proclaman sus siglas, el protocolo SNMP es sencillo
de implementar en hardware. Tras sacudirse la etiqueta de "protocolo de transición",
SNMP está evolucionando en su propia línea. Esto es evidente en las nuevas
funcionalidades de la versión 2 de SNMP (SNMPv2).
8
En SNMP la información se guarda en forma de árbol en una estructura denominada
MIB. Además de las MIBs, el otro componente significativo de SNMP es el protocolo
de comunicaciones (la unidad de protocolo de datos o PDU, Protocol Data Unit) que
emplea el software de gestión para comunicarse con los agentes.
Existen varios tipos de PDU's dependiendo de la información deseada:
GetRequest: Primitiva para la obtención del valor de la variable de la MI6 de un
dispositivo de red.
GetNextRequest: Primitiva para la obtención del valor siguiente (en orden
lexicográfico) al solicitado en la anterior primitiva GetRequest.
GetRespond: Primitiva empleada por el agente SNMP para devolver al gestor los
datos solicitados.
SetRequest: Primitiva para la modificación de variables en la MIB del agente SNMP
Trap: Esta es una primitiva especial que los agentes pueden enviar asíncronamente a
un gestor para notificar determinadas condiciones o estados, previamente definidos.
SNMP V2.
Es una propuesta que soluciona algunas deficiencias del modelo SNMP. Las
principales son mejora de la seguridad y primitivas para obtener grandes volúmenes
de información sin necesidad de enviar un request por cada dato.
2.1 .- Que podemos gestionar?
Prácticamente de todo. Desde Servidores lnformáticos hasta Sistemas de Aire
Acondicionado, Calefacción, Centralitas, Redes Locales, Routers, etc. Si no existiera
este standard, deberíamos controlar cada uno de los sistemas anteriores con
soluciones propietarias.
Las aplicaciones practicas de este método de gestión son múltiples. Hay proyectos ya
implementados en Subestaciones Eléctricas, Centralitas Telefónicas, Procesos
9
Industriales, Gestión Centralizada de Servidores Informáticos, Redes Locales,
Ferrocarriles, Metropolitanos, Autopistas, Control de Trafico, etc. SNNP se ha creado,
para implantar una gestión "universal", de una forma fiable, segura, sencilla y sobre
todo económica.
Hasta la aparición de SNMP, era casi obligado disponer de consolas y operadores
dedicados y especializados en distintos subsistemas. Las Plataformas SNMP disponen
de Interfaces gráficas y bases de datos orientadas a objetos. Su funcionamiento es
mucho más sencillo que los sistemas propietarios, lo que permite controlar todos los
sistemas existentes en una Empresa, con personal "no especializado".
2.2.- Necesidad de Administrar Redes
Los problemas que se presentan en la interconexión de redes son principalmente
dos:
1. Dispositivos diferentes: La interconexión de redes permite diferentes tipos
de dispositivos y estos son de distintos vendedores, todos ellos soportando
el protocolo TCPAP. Debido a esto, la administración de redes se presenta
como un problema. Sin embargo, usar una tecnología de interconexión
abierta permitió que existieran las redes formadas por dispositivos de
distintos fabricantes, por lo que para administrar estas redes, habrá que
usar una tecnología de administración de redes abierta.
2. Administraciones diferentes: Como se permite la interconexión entre redes de
distinto propósito y distinto tamaño, hay que tener en cuenta que también están
administradas, gestionadas y financiadas de distinta forma.
10
3.- EVOLUCIóN HlSTORlCA DEL PROTOCOLO SIMPLE DE GESTIóN DE RED (SNMP)
El protocolo Snmpvl fue diseñado a mediados de los 80 por Case, McCloghrie, Rose,
and Waldbusser, como una solución a los problemas de comunicación entre diferentes
tipos de redes.
En un principio, su principal meta era el lograr una solución temporal hasta la llegada
de protocolos de gestión de red con mejores diseños y mas completos. Pero esos
administradores de red no llegaron y SNMPvl se convirtió en la única opción para la
gestión de red.
El manejo de este protocolo era simple, se basaba en el intercambio de información de
red a través de mensajes (PDU’s). Además de ser un protocolo fácilmente extensible a
toda la red, debido a esto su uso se estandarizo entre usuarios y empresas que no
querían demasiadas complicaciones en la gestión de sus sistemas informáticos dentro
de una red.
No obstante este protocolo no era perfecto, además no estaba pensado para poder
gestionar la inmensa cantidad de redes que cada día iban apareciendo. Para subsanar
sus carencias surgió la versión 2 (SNMP v2). Las mayores innovaciones respecto a la
primera versión son:
Introducción de mecanismos de seguridad, totalmente ausentes en la versión 1. Estos
mecanismos protegen la privacidad de los datos, confieren autentificación a los usuarios y controlan el acceso.
Mayor detalle en la definición de las variables.
Se añaden estructuras de la tabla de datos para facilitar el manejo de los datos. El
hecho de poder usar tablas hace aumentar el número de objetos capaces de
gestionar, con lo que el aumento de redes dejo de ser un problema.
Realmente esta versión 2 no supuso mas que un parche, es más hubo innovaciones
como los mecanismos de seguridad que se quedaron en pura teoría, no se llegaron a
implementar. Por estas razones, este año se ha producido la estandarización de la
versión 3. Con dos ventajas principales sobre sus predecesores:
Añade algunas características de seguridad como privacidad, autentificación y
autorización a la versión 2 del protocolo.
Uso de Lenguajes Orientados a Objetos(Java, C++) para la construcción de los
elementos propios del protocolo(objetos). Estas técnicas confieren consistencia y
llevan implícita la seguridad, por Io que ayudan a los mecanismos de seguridad.
3.1 .- Conceptos
El entorno usado para administración en los protocolos de Internet se llama Internet-
standard Networking Management framework (Entorno para la administración de
redes basadas en Internet), y esto se debe a motivos históricos: Los esquemas previos
eran ocasionales y propietarios. Actualmente existen dos versiones de este entorno: El
entorno original (Internet-standard Networking Management framework), compuesto
por tres documentos, cada uno de los cuales es un estándar de Internet con la
condición de Recomendado; y el entorno que le sucedió (SNMPv2 framework),
formado por doce documentos. Dos años después, éste segundo entorno se reviso en
ocho documentos, quedando algunos como borradores de estándares y otros como
proposiciones de estándares. Con el tiempo, estos documentos se convirtieron en un
completo estándar de Internet. Fue entonces cuando se declaró histórico el estándar
original y la comunidad se quedó con un solo entorno. Entre ambos entornos hubo dos
pasos intermedios: SNMP Security y SMP, que fueron incluidos dentro del entorno
SNMPv2, dejando sus documentos originales sólo para interés histórico.
3.2.- Un Modelo
Un sistema de administración de red contiene cinco elementos:
0 Uno o más nodos administrables, conteniendo cada uno un agente.
12
0 AI menos una estación de administración de red (NMS) con soporte para una o
más aplicaciones de administración de la red.
0 Posiblemente una o más entidades de doble función, que pueden actuar tanto
como agente o como administrador.
0 Un protocolo de administración de red, que es usado por la estación y los agentes
para intercambiar información.
0 Información que administrar.
3.3.- Nodos Administrables
Un nodo administrable es un dispositivo tal que puede clasificarse un una de las tres
siguientes categorías:
0 Un Host, como una estación de trabajo, mainframe, o impresora;
0 un sistema de enrutamiento; o
0 un dispositivo de acceso al medio, como un repetidor, un puente o un hub.
Estas tres categorías coinciden en que clasifican a algún tipo de dispositivo con alguna
capacidad de trabajo en red. Las dos primeras categorías se caracterizan por ser
normalmente independientes del medio, mientras que la principal característica de los
dispositivos de la tercera clase es la dependencia del medio.
3.4.- El Axioma Fundamental
Un buen sistema de administración de red debe conocer la diversidad de dispositivos
existentes y proporcionar un entorno apropiado. Así, el axioma fundamental dice que:
El impacto de añadir una administración de red a un nodo administrable debe
ser mínima, reflejando un común denominador más bajo.
El axioma fundamental se debe a las grandes diferencias entre los distintos nodos
administrables que existen.
13
3.4.1 .- Características de los Nodos Administrables
Podemos considerar que cada nodo administrable está formado por tres componentes:
1 .- Funciones de usuario.
2.- Un protocolo de administración, que permite monitorizar y
controlar el nodo administrable.
3.- Instrucciones de administración, que interactúan con la
Implementación del nodo administrable para permitir la
monitorización y el control.
La interacción entre estos tres componentes es sencilla: Las instrucciones actúan
como un pegamento entre las funciones de usuario y el protocolo de administración:
Esto se debe a un mecanismo de comunicación interno en el que las estructuras de
datos de las funciones de usuario deben ser accesibles y modificables a petición del
protocolo de administración.
3.4.2.- Modelo Administrativo
Actualmente los intercambios de información son insuficientes para proporcionar la
administración de los nodos. El protocolo de administración trabaja en el entorno del
modelo administrativo, que mantiene políticas de autorización y autentificación. Esto
permite determinar al nodo como se está administrando, de modo que sólo los procesos de aplicaciones autorizadas realicen la administración.
3.5.- Estación de Administración de Red
Una estación de administración de red es una máquina que ejecuta el protocolo de
administración de red y una o más aplicaciones de administración de red. Si el
protocolo es el encargado de proporcionar los mecanismos de administración,
entonces las aplicaciones determinan la política que se usa para la administración.
El Axioma Fundamental indica que añadir administración de red debería tener un
impacto mínimo en los nodos; en consecuencia la carga se desplaza a las estaciones.
Sin embargo podríamos pensar que el sistema que soporta la estación de
14
administración es más potente que un nodo, asi que ‘cuánta potencia es necesaria
entonces?. La experiencia muestra que la mayoria de las estaciones de trabajo
pueden proporcionar los recursos necesarios para soportar una buena estación de
administración.
Hay que tener en cuenta que a medida que hay más nodos administrables en una
internet, se favorece desplazar la carga hacia la estación de administración.
3.5.1 .- Entidades de Doble Función
Se ha dicho que las estaciones de administración sólo interactúan con los nodos.
¿Qué pasaría si el mismo nodo también fuera una estación de administración? Es
necesario apreciar que el modelo agente-administrador puede soportar directamente
esto si consideramos que el software de cada estación de administración puede
realizar tanto la función de administrador como la de agente, es decir, que el modelo
agente-administrador es también un modelo peer-to-peer.
Teniendo esto en cuenta, se pueden construir relaciones jerárquicas entre las
estaciones de administración. Por ejemplo, se puede construir un sistema de
administración donde cada segmento de una LAN tiene una aplicacion de
administración que controla el estado de los dispositivos de ese segmento; estas
aplicaciones deberían informar a aplicaciones de estaciones de administración
regionales, las cuales deberían informar a estaciones de administración entre
empresas. En este ejemplo, el software de cada estación realiza un papel de
administrador al monitorizar y controlar dispositivos que dependen de éI
jerárquicamente, y un papel de agente al informar y actuar según los comandos
proporcionados por un superior jerárquico.
Hay que hacer significar que el concepto clave con las entidades de doble función es
que la relación jerárquica depende de la configuración, mientras que la relación peer-
to-peer depende de la arquitectura.
15
3.5.1 .I .- Protocolo de Administración de Red
Dependiendo del paradigma que se utilice para la administración de la red, existen
varias formas que puede tomar un protocolo de administración.
3.5.2.- Operaciones
En el entorno de administración, cada nodo tiene una serie de variables, de modo que
leyendo estas variables se monitoriza el nodo, y cambiándoles el valor se controla. Se
trata de un paradigma de depuración remota, cuya ventaja es que es sencillo construir
un protocolo de administración que realice estas funciones.
Además de las operaciones de lectura y escritura, existen otras dos:
1 .- Una operación cruzada, que permite determinar a la estación de administración qué
variables soporta un nodo.
2.- Una operación de interrupción, que permite a los nodos informar a la estación de
administración de un evento extraordinario
Veamos un poco más de ambas operaciones.
3.5.2.1 .- Operación de Examen
Como los nodos realizan distintas funciones, también contienen diferentes variables de
administración. En el entorno de administración, todas las variables relacionadas con
una determinada funcionalidad se agrupan juntas. Las estaciones deben determinar
qué variables se soportan. Sin embargo, el protocolo debe proporcionar un significado
para examinar la lista de variables soportadas por un nodo.
También hay que tener en cuenta que pueden existir variables que aparezcan más de
una vez. Por ejemplo, la tabla de enrutamiento IP no es escalar, sino que está formada
por una o más filas, cada una de las cuales presenta varias columnas. Por tanto, el
protocolo de administración debe proporcionar dos nuevas funciones:
16
1 .- Un mecanismo para recuperar celdas de una tabla.
2.- Un mecanismo para recuperar números grandes de una celda de una tabla.
3.5.2.2.- Operación de Interrupción
Desde el comienzo de los sistemas operativos, siempre se ha debatido acerca de
utilizar un método de interrupción o un método de sondeo. Esta discusión también se
realiza en la administración de redes. Los argumentos para cada uno de estos
métodos son los siguientes:
I .- Con el método basado en interrupciones, tenemos las siguientes ventajas: Cuando
ocurre un evento extraordinario, el nodo envía una interrupción a la estación de
administración
adecuada (suponiendo que el dispositivo no ha caído y se puede alcanzar la estación).
Por tanto tenemos la ventaja de una notificación inmediata.
2.- Con el método basado en interrupciones, tenemos las siguientes desventajas:
Requiere recursos para generar la interrupción ya que si la interrupción debe contener
mucha información, el nodo perderá tiempo en prepararla y no se dedicará a cosas
útiles. Por supuesto, cuando se genera una interrupción, el agente asume que la
aplicación de administración está preparada para recibir la información. Por tanto hay
que usar un diseño cuidadoso para que las interrupciones sean recibidas sólo por
aquellas estaciones interesadas. Más aún, si ocurre un evento extraordinario, las
interrupciones pueden ocupar un gran ancho de banda, lo cual es poco deseable si se
está informando de un problema de congestión de la red. Por eso se refina el método
de las interrupciones de modo que un nodo sólo informa cuando la ocurrencia de un
evento sobrepasa un determinado umbral, pero esto implica que el agente debe gastar
tiempo para determinar cuándo debe generar una interrupción. Es decir, el método
basado en interrupciones tiene un fuerte impacto en el agente, en la red o en ambos.
En conclusión, como los nodos tienen una pequeña visión de toda la red, es
conveniente que las aplicaciones de administración detecten el problema de alguna
otra forma.
17
3.- Con el método basado en sondeo, una aplicación de administración pregunta
periódicamente al nodo cómo van las cosas, así el control lo tiene la aplicación, la cual
sí tiene una visión global de la red.
4.- La desventaja del método de sondeo es que la aplicación de administración no
sabe qué elementos sondear ni con qué frecuencia: Si el intervalo de frecuencia es
breve, se ocupa mucho ancho de banda, y si es muy largo, la respuesta a eventos
catastróficos es demasiado lenta. Otra desventaja es el trafico que se introduce en la
red, por lo que la aplicación de administración debe tener recursos de almacenamiento
adicionales para ello.
En el entorno de administración se usa el modelo interrupción-sondeo directo (trap-
directed polling). Cuando ocurre un evento extraordinario, el nodo manda una
interrupción simple a la aplicación. La aplicación es entonces la responsable de iniciar
conversaciones con el nodo para determinar la naturaleza y la extensión del problema.
Esto es muy efectivo ya que el impacto creado en los nodos es pequeño, en el ancho
de banda es mínimo y los problemas se resuelven en el momento oportuno. Por tanto,
las interrupciones actúan como una alarma previa, y se usa un sondeo de baja
frecuencia.
3.5.3.- Forma de Transporte
La elección de un servicio de transporte por parte del protocolo de administración es
importante ya que de los mecanismos internos del servicio de transporte depende la
efectividad del protocolo, y de acuerdo con el Axioma Fundamental, hay que elegir la
forma de comunicación menos impactante en el proceso.
La aplicación de administración es la que debe decidir el nivel de fiabilidad deseado e
implementar el algoritmo apropiado, sin dejar esta decisión en manos del servicio de
transporte. De esta manera, el nodo tendría menos carga debido a esta elección.
Todo esto conduce a elegir un servicio de transporte no orientado a conexión. Esta
elección implica un comportamiento "sin preocupaciones" por parte del agente y
permite a la aplicación controlar el nivel de fiabilidad.
Hay otro motivo para elegir servicios de transporte no orientados a conexión. Cuando
la red está congestionada y es difícil establecer una conexión, un protocolo orientado
18
a conexión realiza ésta en tres pasos. Si la red está perdiendo paquetes, es más difícil
establecer este modo de conexión que otro modo de un solo paso. Por tanto es
conveniente usar la segunda forma, ya que en esos casos es cuando realmente la red
necesita ser controlada y administrada.
3.5.4.- Información de Administración
Finalmente, hemos de explicar la información a intercambiar entre la estación de
administración y el nodo utilizando el protocolo de administración. Una unidad de
información de administración se denomina objeto administrado (managed object), y
un conjunto de dichos objetos se denomina Módulo de Base de Información de
Administración (Módulo MIB).
La característica más importante de los métodos usados para describir la información
de administración es la extensibilidad, de modo que se pueda comenzar con un
pequeño conjunto de definiciones, para aumentarlo según crezcan las necesidades.
Un efecto lateral de la extensibilidad, es que los vendedores de dispositivos pueden
añadir sus propios objetos para mejorar sus productos, lo que puede influir en la
estandarización de la tecnología de administración.
3.5.4.1 .- Objetos Administrados (Managed Objects)
La instrumentación de administración actúa entre los protocolos del dispositivo y el
protocolo de administración, tomando la información del dispositivo y presentándola
como un conjunto de objetos administrados. Esta colección se denomina Recursos
Objeto del Agente.
3.5.4.2.- Relaciones de Tipo Proxy
A veces, un agente accede a información de administración no local. Cuando otro
agente recibe la petición de esa información, realiza una serie de operaciones para
satisfacer la solicitud.
19
Esto se denomina Interacción de delegación (interacción Proxy) y el agente que la
realiza se denomina Agente delegado (Agente Proxy).
Hay varias razones por las que utilizar las relaciones Proxy:
1.- Cortafuegos Administrativo(Firewa//): Puede ser útil que el agente proxy
autentifique y autorice las peticiones para no cargar a un dispositivo ocupado con
estas tareas. Así, el agente proxy implementa una política administrativa extensiva, y
el dispositivo sólo responde a las peticiones realizadas por el agente.
2.- Caching Firewall: Puede ser útil que el agente proxy tenga la información a modo
de cache, también para minimizar la carga del dispositivo.
3.- Puentes de transporte: En una red multiprotocolo, un dispositivo soportaría el
servicio punto a punto de solo un conjunto de protocolos. Idealmente, una estación de
administración soportaría los servicios punto a punto de todos los conjuntos de
protocolos. De todas maneras, un agente proxy que soporte servicios punto a punto
del conjunto apropiado de protocolos puede utilizarse para establecer un camino para
las comunicaciones de administración entre el dispositivo y la estación.
4.- Traducciones de protocolo: En el caso en que los dispositivos no soporten
protocolos de administración, las peticiones usadas en el protocolo son traducidas a
una forma entendida por el dispositivo. De igual forma, las respuestas son traducidas a
la forma entendida por el protocolo.
Una propiedad importante de las relaciones tipo proxy es el principio de transparencia.
La idea es aparentar que la aplicación se está comunicando directamente con el
agente real, es decir, una aplicación simplemente especifica los recursos deseados y
el agente proxy es el encargado de hacer que las cosas salgan bien, como si la
información de administración la tuviera el agente proxy localmente.
20
3.5.4.3.- En perspectiva
El Axioma Fundamental del entorno de administración se basa en la noción de
distribución universal:
Si se ve la administración de redes como un aspecto esencial, entonces debería
distribuirse en la mayor cantidad de dispositivos de la red.
Como hay muchos más agentes que estaciones de administración, entonces
minimizando el impacto de la administración en los agentes, podremos solucionar el
problema.
Otro principio importante es que la administración de red es distinta a cualquier otra
aplicación:
Cuando todo falla, la administración de red debe seguir funcionando.
Este principio indica que muchas de las funciones que se encuentra en la capa de
transporte, serán directamente direccionadas por aplicaciones en la estación de
administración, teniendo en cuenta que serán las propias aplicaciones las que definan
el grado de fiabilidad requerido de cada operación. Sin embargo, el servicio de
transporte no debe "ayudar", sólo debería ser la forma más simple de permitir atravesar
la red.
4.- MODELO DE INFORMACI~N
Para examinar el papel de la información de gestión en el entorno de administración,
consideraremos las siguientes cinco partes:
1 .- Reglas para definir la información de administración.
2.- Ejemplos de colecciones de definiciones existentes.
3.- Reglas para definir los convenios textuales (definición de tipos de uso frecuente).
4.- Cómo se accede a éstas al definir información de administración.
21
5.- Coexistencia entre el entorno original y el entorno SNMPv2.
Antes de comenzar, hay que aclarar la relación entre variables, objetos y tipos de
objetos. Un objeto administrable tiene asociado una sintaxis y una semsntica de tipo
abstracto, mientras que una variable es una instancia de un objeto particular; en este
caso también se denomina instancia de un objeto.
4.1 .- Estructura de la Información de Administración
La Estructura de la Información de Administración (SMI) define las reglas para
definir la información de administración independientemente de los detalles de
implementación. La SMI se define usando ASN.1 (Abstract Syntax Notation).
Si se piensa que una colección de objetos administrados están almacenados, por
ejemplo, en una base de datos, la define el esquema de esa base de datos. En
realidad, esa base de datos se denomina Base de Información de Administración
(MlB) .
índice para este punto:
1.- Módulos de información
2.- Definiciones de ob.ietos
3.- Convenciones textuales
4.- Refinamiento de la sintaxis
5.- Grupos de ob.ietos
6.- Identificando una instancia de un ob ieto
7.- Definiciones de notificaciones
8.- E.iemplos de uso
9.- Revisión de un módulo MIB
22
4.1 . I .- Módulos de Información
Existen tres clases de módulos ASN.1, también llamados Módulos de Información,
definidos por el SMI:
1 .- Módulos MIS, que define una colección de objetos de administración afines.
2.- Sentencias de Conformidad, que definen un conjunto de requisitos de los
nodos con respecto a uno o más
3.- Sentencias de Capacidad, que describe la capacidad de un nodo para implementar
los objetos definidos en uno o más módulos MIB.
Por supuesto, estas funciones deberían estar combinadas en un sólo módulo.
4.1.2.- Identificando un Módulo de Información
Cada módulo de información debe comenzar con la indicación de su identidad y la
historia de sus revisiones. Para ello, la m define una macro especial (MODULE-
IDENTITYj:
MODULE-IDENTITY MACRO ::= BEGIN
TYPE NOTATION : :=
"LAST-UPDATED'' value (Update UTCTime )
vtORGANIZATION'l Text
"CONTACTO-INFO" Text
"DESCRIPTION" Text
RevisionPart
VALUE NOTATION : : = value (VALUE OBJECT IDENTIFIER)
RevisionPart : : = Revisions I empty
Revisions : : = Revision 1 Revisions Revision
Revision : : =
"REVISION" value (Update UTCTime)
23
"DESCRIPTION" Text
- - se usa el j u e g o d e c a r a c t e r e s ASCII NVT
La macro MODULE-IDENTITY se usa para mantener los históricos de las revisiones
de cada módulo de información. Debe existir una y sólo una en cada módulo de
información.
4.1.2.1 .- Cláusula LAST-UPDATED
La cláusula LAST-UPDATED, que debe existir, contiene la fecha y hora de la última
revisión realizada sobre este módulo de información.
4.1.2.2.- Cláusula ORGANIZATION
La cláusula ORGANIZATION, que debe existir, contiene una descripción textual de la
organización bajo cuyo auspicios se desarrollo este módulo de información.
4.1.2.3.- Cláusula CONTACT-INFO
La cláusula CONTACT-INFO, que debe estar presente, contiene el nombre, dirección
postal, número del teléfono, y la dirección de correo electrónico de la persona a quien
deben ser enviadas las preguntas de carácter técnico relacionadas con este módulo
de información.
4.1.2.4.- Cláusula DESCRIPTION
La cláusula DESCRIPTION, indispensable, contiene una descripción textual de alto
nivel de los contenidos de este módulo de información.
24
4.1.2.5.- Cláusula REVISION
La cláusula REVISION, que no es necesaria, es usada normalmente para describir las
revisiones hechas al módulo de información, en orden inverso a su sucesión
cronológica. Cada instancia de esta cláusula contiene la fecha y hora de la revisión.
4.1.2.6.- Cláusula DESCRIPTION
La cláusula DESCRIPTION, que debe estar presente por cada cláusula REVISION,
contiene una descripción textual de alto nivel de la revisión identificada en esa cláusula
REVISION.
4.1.2.7.- Valor de MODULE-IDENTITY El valor devuelto de una llamada a la macro MODULE-IDENTITY es un identificador
de objetos (OBJECT IDENTIFIER). Como tal, este valor puede usarse al referirse al
módulo de información que contiene la llamada.
4.1.2.8.- Ejemplo de Uso
Ejemplo de cómo podría construirse el esqueleto de un módulo
MIB:
FIZBIN-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, experimental
FROM SNMPV2-SMI;
f i z b i n MODULE-IDENTITY
LAST-UPDATED “ 9 2 1 0 0 7 0 4 3 3 2 “
ORGANIZATION “IETF SNMPV~ Grupo de trabajo”
CONTACT-INFO
‘I Marshall T. Rose
25
Postal : Dover Beach Consulting, Inc.
420 Whisman Court
Mountain View, CA 94043-2186,
us
Tel: +1 415 968 1052
Fax: +1 415 968 2510
DESCRIPTION
"Módulo MIB para entidades SNMPvZ . "
REVISION "92100704332"
DESCRIPTION
"Versión inicial de este módulo MIB. "
: : I { snmpModules 1 }
END
4.2.- Uso de OBJECT IDENTIFIERS
Un identificador de objeto es un nombre asignado arbitrariamente. Los identificadores
de objetos definidos en el para el protocolo de gestión son:
- - camino al root internet OBJECT IDENTIFIER : : = { is0 3 6 11
directory OBJECT IDENTIFIER : : = {internet I }
mgmt OBJECT IDENTIFIER : := {internet 21
experimental OBJECT IDENTIFIER : : =
{internet 3)
26
private OBJECT IDENTIFIER {internet 4 )
enterprises OBJECT IDENTIFIER : : = {private I }
security OBJECT IDENTIFIER : : = {internet 5 }
snmpV2 OBJECT IDENTIFIER : : = {internet
. . _ . .-
6 1
- - dominios de transporte
snmpDomains OBJECT IDENTIFIER : : = { s n m p ~ 1)
- - proxies de transporte
snmpProxys OBJECT IDENTIFIER : : = { snmp~2 2 }
- - entidades módulo snmpModules OBJECT IDENTIFIER : : = { snmpv2 3}
La raíz del subárbol administrada por la Autoridad de Números Asignados para Internet (IANA)
es:
Internet OBJECT IDENTIFIER : : = { is0 3 6 1 1
Es decir, el subárbol de Internet de identificadores de objetos comienza con el prefijo:
1.3.6.1.
Varias ramas debajo de este subárbol se usan para la gestión de la red:
mgmt OBJECT IDENTIFIER : : = { internet 2 )
experimental OBJECT IDENTIFIER : : = { internet 3 }
private OBJECT IDENTIFIER : : = { internet 4 }
enterprises OBJECT IDENTIFIER : : = { private 1 }
Sin embargo, el no prohibe la definición de objetos en otras porciones del árbol de
objetos.
El subárbol mgmt(2) es usado para identificar objetos "estándar".
El subárbol experimental(3) es usado para identificar objetos diseñados por grupos de
trabajo del IETF. Si un módulo de información producido por un grupo de trabajo se
convierte en un módulo de información "estándar", entonces en el momento de su
entrada en los cauces estándar de Internet, los objetos se mueven al subárbol
mgmt(2).
27
El subárbol private(4) se usa para identificar objetos definidos de forma unilateral. El
subárbol enterprises(1) bajo el private se usa, entre otras cosas, para permitir a los proveedores de subsistemas de red registrar modelos de sus productos.
El subarbol snmpV2 se usa con propósitos de mantenimiento.
4.3.- Identificando un Punto de Registro
Los identificadores de objeto se usan frecuentemente en el funcionamiento del
protocolo, y existe una macro para asociar información textual con asignaciones de
identificadores, que es la macro OBJECT-IDENTITY:
OBJECT-IDENTITY MACRO::= BEGIN
TYPE NOTATION : : =
“STATUS“ Status
“DESCRIPTION“ Text
ReferPart
VALUE NOTATION : : = value (VALUE OBJECT IDENTIFIER)
Status : := “current” 1 “deprecated” 1 “obsolete”
La macro OBJECT-IDENTITY se usa para definir información sobre la asignación de
un identificador de objeto. La expansión de la macro OBJECT-IDENTITY
conceptualmente sucede durante la implementación y no en tiempo de ejecución.
4.3.1 .- Cláusula STATUS
La cláusula STATUS, que debe estar presente, indica si esta definición es actual o
histórica.
28
4.3.2.- Cláusula DESCRIPTION
La cláusula DESCRIPTION, obligatoria, contiene una descripción textual de la
asignación del objeto.
4.3.3.- Cláusula REFERENCE
La cláusula REFERENCE, que no es necesaria, contiene una referencia cruzada
textual a una asignación del objeto definida en algún otro módulo de información.
4.3.4.- Valor de OBJECT-IDENTITY
El valor devuelto en una llamada a la macro OBJECT-IDENTITY es un identificador de
objeto (OBJECT IDENTIFIER).
4.3.5.- Ejemplo de uso
Ejemplo de cómo podría hacerse una asignación de un identificador de objeto:
fizbin69 OBJECT-IDENTITY
STATUS current
DESCRIPTION
I' La identidad autoritaria de 1 chipset Fizbin 69 . If
::= { fizbinChipSets 1 )
4.4.- Convenciones Textuales
Aunque los tipos de datos específicos de la aplicación contenidos en el son
usados, la experiencia en la creación de módulos MIB muestra que, a veces, es
convieniente definir tipos de datos con sintaxis similar a la estándar, pero con una
semántica mucho más precisa. Estos tipos, se denominan convenciones textuales. Su
29
codificación es idéntica a la de los otros tipos, pero dentro del MIB, poseen una
semántica especial, la cual es capturada por la macro TEXTUAL-CONVENTION:
TEXTUAL-CONVENTION MACRO ::=
BEGIN
TYPE NOTATION : : =
Displaypart
"STATUS" Status
"DESCRIPTION" Text
ReferPart
"SYNTAX" type (Syntax)
VALUE NOTATION : : = value(VALUE Syntax)
Displaypart : : = "DISPLAY-HINT" Text I empty
Status : := "current" I "deprecated" I "obsolete"
ReferPart : : = "REFERENCE" Text I empty
--Usa el conjunto de caracteres ASCII NVT
<descriptor> <macro> <cláusulas> : := <valor>
sino que es de la forma:
<descriptor> ::= TEXTUAL-CONVENTION <CláUSUlaS> <tipo syntax>
Ejemplo:
Displaystring : : = TEXTUAL-CONVENTION
DISPLAY-HINT q9255ag1
STATUS current
DESCRIPTION
"Representa información textual, y ningún objeto puede superar l o s 255 caracteres de longitud"
SYNTAX OCTET STRING (SIZE ( O . .255) )
30
4.4.1 .- Cláusula DISPLAY-HINT
Indicación de cómo un valor entero o cadena correspondiente a esta convención
textual, puede ser interpretado para su representación por pantalla.
4.4.2.- Cláusula STATUS
Indicación del estado de la convención textual.
4.4.3.- Cláusula DESCRIPTION
Explicación textual de la convención.
4.4.4.- Cláusula REFERENCE
Si la convención textual es una derivación de otra, entonces esta cláusula está
presente e incluye una referencia textual a la otra convención.
4.4.5.- Cláusula SYNTAX
Sintaxis asociada con el tipo de dato.
4.5.- Convenciones Textuales Predefinidas
Existen convenciones textuales predefinidas, ya que son comunes a la
mayor parte de las aplicaciones, como pueden ser:
31
DisplayString: cadena de hasta 255 caracteres NVT ASCII
OCTET STRING (SIZE (0..255))
Su valor de DISPLAY-HINT sería 255a (se interpreta como una cadena de 255 bytes)
PhysAddres:
OCTET STRING
Su DISPLAY-HINT asociado sería Ix: , que es interpretado como: imprimir cada octeto como un número hexadecimal seguido del caracter u , .I,
Truthvalue: un valor booleano
INTEGER { true( I ) , false(2) }
DateAndTime: una especificación temporal:
OCTET STRING (SIZE (8 I 11))
Su DISPLAY-HINT asociado es: 2d-Id-Id- , Id: ld: ld: ld. ld, lald:Id, que determina un formato de fecha y hora de la forma:
1992-2-29,17:45:20.3,+4:0
4.5.1 .- Refinamiento de la Sintaxis
Algunas macros permiten refinar la sintaxis de un objeto (ej., la cláusula SYNTAX de la
macro MODULE-COMPLIANCE). Sin embargo, no todos los refinamientos de sintaxis
son apropiados. En particular, las primitivas del objeto o el tipo de aplicación no se
debe cambiar.
Además, se aplican las siguientes restricciones:
32
Restricciones a Refinamiento en
Counter32 - -
TimeTicks
NsapAddress
Counter64
- - - -
- - -
- - -
donde:
El rango de valores permitidos puede ser refinado aumentando los límites inferiores,
reduciendo los límites superiores, y/o reduciendo las opciones de valor/rango
alternativas;
La enumeración de valores con nombre puede refinarse quitando uno o más valores
con nombre;
El tamaño en caracteres del valor puede ser refinado aumentando los límites
inferiores, reduciendo los límites superiores, ylo reduciendo las opciones de tamaño
alternativas:
El repertorio de caracteres en el valor puede ser reducido mediante el uso de subtipos.
No existen otros métodos de refinamiento.
AI refinar un objeto con un valor de cláusula SYNTAX de Integer32 o Ulnteger32, el
valor refinado de SYNTAX se expresa como un INTEGER y se consideran las
restricciones de la tabla superior.
33
4.5.2.- Grupos de Objetos
Se definen objetos afines dentro de grupos de objetos (object group). Desde el punto
de vista de la implementación, un grupo de objetos se ve como una unidad de
implementación, y un desarrollador puede codificar cero o más objetos de los
contenidos en el grupo.
La asignación de identificadores de objeto a los tipos en un módulo MIB, sigue la
siguiente pauta:
1.
2.
3.
Los tipos de objeto se ponen dentro de grupos de objetos
Un identificador de objeto es asignado a cada grupo. Por
convenio, se suele anteponer al nombre, como prefijo, el
nombre del módulo MIB.
Los objetos poseen un identificador secuencia1
subordinado al del grupo.
4.5.2.1.- Identificando una Instancia de un Objeto
Es necesario conocer el nombre de un objeto, para poder gestionarlo, pero los objetos
en sí no son más que plantillas, y son las instancias de los mismos, las que maneja el
protocolo, con lo que se debe especificar el identificador de instancia.
El protocolo de gestión utiliza, para identificar instancias, un identificador de objeto,
formado por la concatenación del nombre del tipo de objeto y un sufijo. Si el objeto no
es parte de una tabla, entonces, representa una instancia de un tipo de objeto en un
dispositivo particular. Para identificarlo sólo hay que añadir al nombre del objeto, ".O". Ejemplo:
"nombre de objeto".O En caso de ser un objeto parte de una tabla, su identificación posee tres posibles
alternativas dependiendo de:
0 El objeto es una tabla
0 El objeto es una fila de una tabla
0 El objeto es una columna de una fila de la tabla
34
El protocolo no permite manejar objetos agregados, con lo que sólo se pueden
gestionar objetos columna que forman las celdas de una tabla.
4.5.2.2.- Definiciones de Notificaciones
La macro NOTIFICATION-TYPE se usa para definir la información contenida dentro de
una transmisión no solicitada de información de gestión (es decir, dentro de una
SNMPv2-Trap-PDU o InformRequest-PDU).
La definición de la macro es la siguiente: NOTIFICATION-TYPE MACRO ::=
BEGIN
TYPE NOTATION : : =
ObjectsPart
"STATUS" Status
"DESCRIPTIONr1 Text
ReferPart
VALUE NOTATION : : = value(VALUE OBJECT IDENTIFIER)
ObjectsPart : := "OBJETOSIt I t { ' ' Object " } " I empty
Objetos : : = Objeto I Objects ' I , It Object
Objeto : : = value(Name ObjectName)
Status : : = "actual" I "desaprobado" I ltobsoletotl
ReferPart : := "REFERENCEt1 Text I empty
--usa el juego de caracteres NVT ASCII
Text : : = I1 I t I ? I! string I t I t I , VI
END
4.5.2.3.- Cláusula OBJECTS
La cláusula OBJECTS, no obligatoria, define la sequencia ordenada de objetos del
MIB que están contenidos dentro de cada instancia de la notificación.
35
4.5.2.4.- Cláusula STATUS
La cláusula STATUS, que debe existir, indica si esta definición es actual o antigua
("current" u "obselete" respectivamente).
El valor "deprecated" (desaprobada) indica que la notificación está obsoleta, pero que
un implementador puede desear dotar al objeto de interoperabilidad con aplicaciones
más viejas.
4.5.2.5.- Cláusula DESCRIPTION
La cláusula DESCRIPTION, que debe estar presente, contiene una definición textual
de la notificación que mantiene todas las definiciones semánticas necesarias para la
implementación, y debe incluir cualquier información que pueda ser comunicada en
cualquier notificación asociada con el objeto. En particular, la cláusula DESCRIPTION
debe documentar qué instancias de los objetos mencionados en la cláusula OBJECTS
deben ser contenidas dentro de las notificaciones de este tipo.
4.5.2.6.- Cláusula REFERENCE
La cláusula REFERENCE, no obligatoria, contiene una referencia cruzada de tipo
textual a una notificación definida en algún otro módulo de información. Se usa si se
tiene un módulo MIB no OSI, producido por alguna otra organización.
4.5.2.7.- Valor de NOTIFICATION-TYPE
El valor devuelto en una llamada a la macro NOTIFICATION-TYPE es el nombre de la
notificación, que es un identificador de objeto (OBJECT IDENTIFIER), un nombre
asignado administrativamente.
36
4.5.2.8.- Ejemplo de uso
Véase cómo podría describirse un trap linkup:
Linkup NOTIFICATION-TYPE
OBJECTS { ifIndex )
STATUS current
DESCRIPTION
“Un trap linkup significa que la entidad SNMPv2 que actúa bajo el papel de agente, reconoce que uno de los enlaces de comunicación representados en su configuración ha surgido“.
::= { snmpTraps 4 }
Según esta llamada, la interrupción (trap) identificada como
{ snmpTraps 4 }
es usada para informar del establecimiento de un enlace.
Una entidad SNMPv2 que actúa como un agente puede configurarse para enviar a
esta interrupción a cero o más entidades SNMPv2 gestoras, dependiendo del
contenido de las tablas aclTable y viewTable. Por ejemplo, por uso juicioso de
viewTable, una entidad agente SNMPv2 podria configurarse para enviar todas las
interrupciones del linkup a una entidad particular, y las interrupciones de tipo linkup
para sólo ciertas interfaces a otras entidades.
4.6.- Revisión de un Módulo MI6
4.6.1 .- Modificando Definiciones de Objetos
Cuando se modifica la definición de tipo de un objeto existente, hay cambios que son
factibles sin necesidad de cambiar las asignaciones de identificadores de objetos:
37
Si la cláusula SYNTAX utiliza un tipo enumerado. Ej:
(SYNTAX INTEGER { up(l), down(2) }
entonces se añaden enumeraciones:
(SYNTAX INTEGER { up(l), down(2), testing(3) }
y deben cambiarse las etiquetas asociadas.
Debe añadirse una cláusula UNITS
La cláusula STATUS debe modificarse:
De "current" a "deprecated" u "obsolete"
De "deprecated" a "obsolete"
Una cláusula REFERENCE debe ser añadida, o en caso de estar presente,
modificada.
Una cláusula DEFVAL debe ser añadida o cambiada, según corresponda.
Por otra parte, si previamente la semántica de cualquier objeto predefinido se cambia
(es decir, si se hace un cambio específicamente a alguna cláusula distinta de las
especificadas anteriormente como posibles), entonces el objeto asociado con dicho
identificador también debe cambiarse.
Ese cambio del descriptor asociado con un objeto existente es considerado un cambio
sernántico, estas cadenas pueden ser usadas en una declaración IMPORTS.
Finalmente, si un objeto tiene el valor de su cláusula STATUS cambiado, entonces el
valor de su cláusula DESCRIPTION, debe ser actualizado de forma acorde.
4.6.1 .I .- Modificando la Definición de las Notificaciones
Las reglas para modificar una notificación son simples: debe añadirse o cambiarse una
cláusula REFERENCE, pero si se realiza un cambio profundo, debe definirse un nuevo
tipo notificación.
38
4.6.2.- Módulos MIB
4.6.2.1.- Las Diferentes Clases de Módulos MIB
Existen tres tipos de módulos MIB:
Estándar: Diseñados por un grupo de trabajo del IETF(/nternet Engineering task force)
y estandarizado por el IESG(/nternet Engineering Steering Group). Los prefijos de los identificadores de objetos se encuentran bajo el subárbol mgmt.
Experimental: Mientras un grupo de trabajo desarrolla un MIB, los identificadores de
objetos temporales se colocan bajo el subárbol experimental. Si el MIB adquiere la
condición de estándar, se colocan los identificadores bajo el subárbol mgmt.
Específico: La mayor parte de las empresas desarrollan módulos MIB propios que
soporten ciertas características particulares, las cuales no son generalmente
contempladas en los módulos MIB estándar.
4.6.2.2.- MIB Internet-Standard
En el protocolo original, el MIB estándar Internet definía el conjunto fundamental de
objetos administrados por un dispositivo basado en TCPllP (MIB-I). El documento fue
posteriormente revisado hasta llegar al MIB-II.
4.6.3.- MI6 SNMPV~
Parte de la instrumentación para una entidad SNMPv2. Existen cinco grupos:
system: Grupo system (traído del MIB-It). Se trata de una colección de objetos
comunes a todos los sistemas de gestión
snmp: Grupo estadístico del SNMPv2
snmpCommunity: Grupo estadístico del SNMPvl
snmpset: Grupo set del SNMPv2
snmpBasicNotification: Grupo de notificaciones básico
39
4.6.3.1 .- Grupo System
Se trata de un conjunto fundamental de objetos administrados por un dispositivo
basado en TCP/IP. Son comunes para todos los sistemas.
System OBJECT IDENTIFIER ::= { mib-2 1 } SysDescr OBJECT-TYPE
SYNTAX Displaystring (SIZE ( 0 . . 2 5 5 ) )
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Una descripción textual de la entidad. Este valor debería contener el nombre y
versión completos del tipo del hardware del sistema, sistema operativo, y software de red. I'
: := { system 1 } sysObjectID OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"La identificación del vendedor del subsistema de red contenido en l a entidad..
Este valor está almacenado dentro del subarbol de empresa SMI ( 1 . 3 . 6 . 1 . 4 . 1 ) y
provee de un método sencillo para determinar qué se está gestionando. Por
ejemplo, si el vendedor es 'Flintstones, Inc.' Asignado al subarbol
1.3 .6 .1 .4 .1 .4242 , éste podría asignar el identificador 1.3.6.1.4.1.4242.1.1 al
'Router Fred' . I'
: := { system 2 } sysUpTime OBJECT-TYPE
SYNTAX TimeTicks
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Tiempo (en centésimas de segundo) desde que la tuvo lugar la última
reinicialización de alguna parte del sistema."
::= { system 3 }
40
sysContact OBJECT-TYPE
SYNTAX Displaystring (SIZE (0..255))
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"Identificación textual de la persona de contacto para este nodo gestionado,
junto con información de cómo contactar con esa persona. Si no se conoce
información de contacto, el valor será una cadena de longitud cero.''
::= { system 4 } sysName OBJECT-TYPE
SYNTAX Displaystring (SIZE ( O . .255))
MAX-ACCESS read-write
STATUS current
DESCRIPTION
I'Un nombre asignado administrativamente para este nodo. Por convenio, este el
nombre de dominio. Si el nombre es desconocido, se pone una cadena de longitud
cero. I'
: := { system 5 } sysLocation OBJECT-TYPE
SYNTAX Displaystring (SIZE (0..255))
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"Localización física de éste nodo (ej. : , '3rd floor'). Si es desconocida, le
valor de este campo es una cadena de longitud cero.''
: := { system 6 } sysservices OBJECT-TYPE
SYNTAX INTEGER ( O . .127)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Un valor que indique el conjunto de servicios que la entidad puede ofrecer
potencialmente. El valor será una suma. La suma toma inicialmente el valor
cero, entonces, para cada capa, L, en el rango 1 a 7, para la que éste nodo ejecuta transacciones, 2 elevado a (L - 1 ) es añadido a la suma. Por ejemplo,
un nodo que ejecuta sólo funciones de enrutamiento podría tener un valor de 4
(z3-l). Por el contrario, un nodo que es un host y ofrece servicios de
aplicación podría tener el valor de 72 (2"l + 27-1). En el contexto del conjunto
de protocolos internet, los valores deben ser calculados de acuerdo a:
41
layer functionality
1 physical (e.g., repeaters)
2 datalink/subnetwork (e.g., bridges)
3 internet (e.g., supports the IP)
4 end-to-end (e.g., supports the TCP)
7 applications (e.g., supports the SMTP)
Para sistemas que incluyen protocolos OSI, las capas 5 y 6 pueden además ser
contadas. I'
: := { system 7 }
Ahora se introduce información de recursos de objetos: Una colección de
objetos que describen el soporte de las entidades SNMPv2, estática y dinámicamente configurables, de varios módulos MIB
sysORLastChange OBJECT-TYPE
SYNTAX Timestamp
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"El valor de sysUpTime en el momento del último cambio de estado o valor de
cualquier instancia de sysOR1D."
::= { system 8 } sysORTable OBJECT-TYPE
SYNTAX SEQUENCE OF SysOREntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"La tabla (conceptual) con la lista de capacidades de la entidad local SNMPv2
actuando como agente con respecto a varios módulos MIB. Las entidades SNMPv2
con soporte dinámicamente configurable de módulos MIB tendrán un número
dinámicamente variable de filas conceptuales."
::= { system 9 } sysOREntry OBJECT-TYPE
SYNTAX SysOREntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
42
"Una entrada (fila conceptual) en sysORTable."
INDEX { sysORIndex )
: := { sysORTable 1 } SysOREntry : := SEQUENCE {
SysORIndex INTEGER,
SysORID OBJECT IDENTIFIER,
SysORDescr DisplayString,
SysORUpTime Timestamp
1 sysORIndex OBJECT-TYPE
SYNTAX INTEGER ( 1 . . 2 1 4 7 4 8 3 6 4 7 )
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Variable auxiliar usada para identificar instancias de objetos columna in
sysORTable . "
::I { sysOREntry 1 } SySORID OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Identificación autoritaria de la situación de las capacidades con respecto a
varios módulos MIB soportados por la entidad local SNMPv2 actuando como
agente. I'
: := { sysOREntry 2 } sysORDescr OBJECT-TYPE
SYNTAX DisplayString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Descripción textual de las capacidades identificadas por la instancia
correspondiente de sysORID."
: := { sysOREntry 3 } sysORUpTime OBJECT-TYPE
SYNTAX Timestamp
MAX-ACCESS read-only
43
STATUS current
DESCRIPTION
"Valor de sysUpTime en el momento en el que esta fila conceptual fue
instanciada por última vez.''
: : E { sysOREntry 4 }
4.6.3.2.- Grupo snmpSet
Este grupo define una colección de objetos que permiten a varias entidades SNMPv2
cooperantes coordinar el uso de la operación SET.
snmp OBJECT IDENTIFIER ::= { mib-2 11 } snmpInPkts OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Número total de mensajes enviados a la entidad SNMP desde la capa de
transporte. I'
::= { snmp 1 } snmpInBadVersions OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Número total de mensajes SNMP que fueron enviados a la entidad SNMP y eran
para una versión no soportada de SNMP."
::= { snmp 3 } snmpInBadCommunityNames OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Número total de mensajes SNMP enviados al la entidad SNMP que usaban un nombre
de comunidad SNMP desconocido para dicha entidad."
44
::= { snmp 4 }
snmpInBadCommunityUses OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Número total de mensajes SNMP enviados a la entidad que representaban una
operacion SNMP no permitida por la comunidad SNMP indicada en el mensaje.''
::= { snmp 5 }
snmpInASNParseErrs OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Número total de errores de ASN.l o BER(Basic Encoding Ru1es)encontrados por la
entidad cuando decodificaba los mensajes SNMP recibidos."
::= { snmp 6 }
SnmpEnableAuthenTraps OBJECT-TYPE
SYNTAX INTEGER { enabled ( 1 ) , disabled(2) }
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"Indica si la entidad está autorizada para generar traps authenticationFailure.
El valor de este objeto está por encima de cualquier información de
configuración; así como, provee un entorno por el cual todos l o s traps
authenticationFailure pueden ser deshabilitados.
Es muy recomendable que este objeto esté almacenado en memoria no volátil, ya
que se debe mantener constante ante cualquier reinicialización del sistema de
gestión de red. 'I
: := { S ~ P 30 } snmpSilentDrops OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
45
"Número total de GetRequest-PDUs, GetNextRequest-PDUs, GetBulkRequest-PDUs,
SetRequest-PDUs, e Informequest-PDUs enviados a la entidad SNMP que fueron
silenciosamente eliminados porque el tamaño de una respuesta conteniendo una
Response-PDU alternativa con un campo vacío de unión de variables era mayor que
otra restricción local o el tamaño máximo de mensaje asociado con el origen de
la respuesta.
: := { SIIIIIP 31 }
snmpProxyDrops OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Número total de GetRequest-PDUs, GetNextRequest-PDUs, GetBulkRequest-PDUs,
SetRequest-PDUs, e InformRequest-PDUs enviados a la entidad SNMP que fueron
eliminados porque la transmisión del (posiblemente traducido) mensaje a un
objetivo proxy falló de forma (distinto de un time-out) que no es posible
retornar un Response-PDU."
: := { snmp 32 }
4.6.3.3.- lnvocaciones de Tipo Estándar
El módulo SNMPv2 también define tres "traps" estándar:
snmpTraps OBJECT IDENTIFIER : := { snmpMIBObjects 5 }
coldstart NOTIFICATION-TYPE
STATUS current
DESCRIPTION
"Un trap coldstart significa que la entidad SNMPv2, actuando como agente, está
autoreinicializándose y su configuración puede haber sido alterada."
::= { snmpTraps 1 }
warmstart NOTIFICATION-TYPE
STATUS current
DESCRIPTION
"Un trap warmstart implica que la entidad SNMPv2, actuando como agente, está
autoreinicializándose de tal forma que su configuración no cambia."
46
: : = { snmpTraps 2 1
authenticationFailure NOTIFICATION-TYPE
STATUS current
DESCRIPTION
"Un trap authenticationFailure significa que la entidad SNMPv2, en el papel de
agente, ha recibido un mensaje que no está apropiadamente autentificado.
Mientras todas las implementaciones de SNMPv2 deben ser capaces de generar este
trap, el objeto snmpEnableAuthenTraps indica cuando este trap será generado."
::= { snmpTraps 5 )
4.7.- Sentencias de Conformidad
En la declaración original del protocolo, cada grupo de objetos llevaba un comentario
en ASN.1 indicando el nivel de conformidad asociado con el grupo.
Por ejemplo:
snmpComunityGroup OBJECT-GROUP
OBJECTS { snrnpInBadCommunityNames,snmpInBadCommunityUses }
STATUS current
DESCRIPTION
"Colección de objetos que proporcionan instrumentación básica de las entidades SNMPv2 que soporten autenticación basada en la comunidad."
: := { snmpMIBGroups 9 }
define un grupo de conformidad con 2 objetos. Un objeto puede estar en varios grupos
de conformidad. Un grupo de conformidad, es identificado por un identificador de
objeto, y es usado de dos formas: en definiciones de requerimientos de conformidad y
en definiciones de las extensiones implementadas en un módulo MIB.
41
4.7.1 .- MODULE-COMPLIANCE
Cuando la macro MODULE-COMPLIANCE es invocada, cero o más módulos son
identificados. Para cada módulo, la cláusula MANDATORY-GROUPS identifica
aquellos grupos que deben ser implementados. De forma similar, la cláusula GROUPS
identifica los grupos que debes ser implementados si se encuentra alguna condición.
smpBasicCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
“Declaración de conformidad para entidades SNMPv2 con SNMPv2 MIB. I ‘
MODULE - - este módulo
MANDATORY-GROUPS (snmpGroup, snmpSetGroup,systemGroup,snmpBasicNotificationsGroup 1 GROUP snmpCommunityGroup
DESCRIPTION
“Este grupo es preceptivo para entidades SNMPv2 soporten autentificación b a s E en la comunidad. I t
::= { snmpMIBCompliances 1 ]
4.7.1 .I .- Importando Definiciones de Macros
Todos los módulos de información empiezan con una invocación de la macro
MODULE-IDENTITY, que proporciona la lista de contactos y revisiones. Esta llamada
debe aparecer siempre después de cualquier declaración IMPORT o EXPORT.
48
4.7.1.2.- Resumen
En este apartado se ha hablado de una parte fundamental de cualquier sistema, nos
referimos a las reglas que rigen la formación de los distintos módulos que forman el
sistema de gestión.
El SMI (Estructura de la información de administración) nos ofrece las reglas para
definir la información de administración independientemente de los detalles de
implementación, la sintaxis usará ASN.l.
Existe tres tipos de módulos de información definidos con las reglas ofrecidas por el
SMI:
Modulo de Información Base (MIB): Conjunto fundamental de objetos de
administración.
Sentencias de conformidad: Conjunto de requisitos de los nodos respecto a uno o mas
módulos MIB.
Sentencias de capacidad: Capacidad de un nodo para implementar objetos definidos
en uno o más módulos MIB.
Cada módulo de información debe comenzar con la indicación de su identidad y la
historia de sus revisiones (macro MODULE-IDENTITY)
Dentro de cada modulo existirán objetos, los cuales se definen con la macro OBJECT-
TYPE, la expansión de estos se produce durante la implementación. También se
usaran convenciones textuales (macro TEXTUAL-CONV€NT/ON), que son
redefiniciones mas precisas de algún tipo de datos, dentro de un MIB.
Existen tres tipos de MIB:
Estándar: son módulos que se han convertido en un estándar.
Experimental: Esperan su oportunidad de convertirse en estándar.
Especifico: son propios de alguna empresa.
El modulo MIB de la V2 contiene 5 grupos de objetos: system, snmp,
snmpcomunity, SnmpSet y SnmpBasicNotification.
49
4.8.- Modelo Administrativo
Consideraremos como se definen políticas administrativas para aplicaciones de
gestión y agentes. Esta parte de la red de gestión ha sufrido la mayor revisión desde la
introducción de SNMP. Desafortunadamente todavía no existe un consenso en la
solución más apropiada al problema.
4.8.1 .- Conceptos
En el entorno de gestión, una entidad SNMP es una "entidad lógica" en nombre de la
cual un agente o una aplicación de gestión están procesando un mensaje.
El entorno de gestión es responsable de proporcionar:
Autentificación: se refiere a como las entidades SNMP identifican sus mensajes.
Privacidad: se refiere a como las entidades SNMP protegen sus mensajes.
Autorización: se refiere a como una entidad agente SNMP determina los objetos que
son accesibles a una entidad de aplicación de gestión dada, y las operaciones que se
pueden realizar en estos objetos.
4.8.2.- Autentificación
Cuando una entidad comienza una comunicación, es configurada para suministrar
credenciales de autentificación como una parte de la comunicación. Dependiendo de
los mecanismos de autentificación, serán válidas tres clases de servicios:
Identificación origen, por la cual un mensaje puede ser asociado con una entidad
origen.
Integridad del mensaje, por la cual un mensaje alterado puede ser detectado con
seguridad.
Protección limitada de retransmisión, por la cual un mensaje que ha sido duplicado
o retrasado por la red o una tercera parte puede ser detectado fuera del tiempo de vida
esperado del mensaje.
50
Tras esto podemos observar que prevenir las ocasiones de fuera de servicio, en las
cuales una tercera parte interrumpe una comunicación, no es un objetivo del entorno
de gestión.
No obstante para alcanzar seguridad con las anteriores funciones deberemos usar:
Encriptación con firma,
Algoritmos (message digest)
Relojes incrementados monótonamente.
4.8.3.- Privacidad
Como las propiedades de autentificación están asociadas con la entidad enviadora, las
propiedades de privacidad se pueden asociar con las entidades receptoras.
Para lograr privacidad con seguridad, deberíamos usar un algoritmo de encriptación y
la clave asociada.
4.8.4.- Autorización
Cuando un agente ejecuta una operación, primero deberá identificar la colección de
recursos de objetos de gestión a monitorizar. Si los recursos son accesibles mediante
algún mecanismo local, se dice que la operación se desarrolla desde el punto de vista
del MIB, el cual es normalmente un conjunto adecuado de todos los objetos
gestionados controlados por una entidad. En cambio, si los recursos son accesibles
mediante el envío de mensajes SNMP a una entidad remota, entonces se dice que los
objetos son validos a través de una relación proxy.
Una vez que los recursos son identificados, solo resta determinar las operaciones
SNMP empleadas en ellos. A esto se denomina Política de Acceso, y es usada para el
control del flujo de información entre la entidad agente SNMP y una entidad de
aplicación de gestión dada.
51
4.8.5.- Comunidades
SNMP v2 esta diseñado para soportar múltiples entornos de administración. El entorno
que veremos se denomina entorno de gestión basado en comunidades, debido a que
usa el concepto de comunidad empleado en el SNMP original.
SNMP define una comunidad como una relación entre entidades SNMP. Una
comunidad SNMP se escribe como una cadena de octetos sin interpretación. Esta
cadena se llama nombre de comunidad. Cada octeto toma un valor entre O y 255.
Cuando se intercambian mensajes SNMP, contienen dos partes:
Una cadena de comunidad, mandada en texto sencillo: y ,
Datos, conteniendo una operación SNMP y los operandos asociados.
La cadena de comunidad es un simple manejador para las relaciones de gestión.
Ahora realizamos una valoración de las propiedades de gestión de SNMP:
Identificación origen: como las cadenas de comunidad son enviadas sin protección,
cualquier tercera parte capaz de interceptar un mensaje SNMP puede usar el mismo
nombre de comunidad y de esa forma demandar ser un miembro de la comunidad de
mensajes:
Integridad del mensaje: cualquier tercera parte puede modificar un mensaje SNMP que
intercepte.
Protección limitada de reenvíos: cualquier tercera parte puede retrasar un mensaje
SNMP que haya interceptado;
Privacidad: cualquier tercera parte puede leer el mensaje SNMP que haya
interceptado;
Autorización: los agentes son responsables de mantener información local así como los
MI6 que contiene, o las relaciones de proxy válidas; será sencillo para una tercera
parte obtener los accesos correctos de una entidad autorizada para monitorizar o
controlar esos objetos.
Para contemporizar, todo lo que puede ser dicho es que aunque SNMP v2 ofrece
enfoques técnicos para estos asuntos, sus mecanismos no llevan a solución. Además
el grupo de trabajo ha sido incapaz de lograr un consenso en como llegar a la solución.
Naturalmente, el mercado se ha adaptado a estas carencias:
52
Primero, varios diseñadores de módulos MIB son reacios a definir objetos, que
maliciosamente modificados puedan causar considerables dificultades en la red; y,
Muchos implementadores de agentes no han implementado funciones de control
SNMP a propósito.
4.8.6.- Procedimientos
Veremos como se procesan los mensajes SNMP. Para empezar, veremos el formato
del mensaje. Existen tres partes:
Versión: el número de versión del mensaje.
Comunidad: la cadena de comunidad; y,
Datos: una operación SNMP, definido como una estructura PDUs
4.8.7.- Originando un Mensaje
Usando conocimiento local, la entidad origen comienza seleccionando la comunidad
apropiada la cual tiene la autorización adecuada para usar las operaciones y el acceso
a los objetos MI6 deseados. Luego:
Una estructura de mensaje es construida desde esta información;
Es convertida en una cadena de octetos; y,
Es enviada a la dirección de transporte de la entidad receptora.
4.8.8.- Recibiendo un Mensaje
Cuando un paquete es recibido del servicio de transporte, el contador (snmplnPkts)
es incrementado. Luego el paquete es examinado para ver si es una representación
de una estructura de mensaje.
Si no es una representación de una estructura de mensaje, el contador
(snmplnASNParseErrs) es incrementado y el paquete es descartado. En caso
53
afirmativo, la versión del mensaje es revisada para ver si se refiere a una versión
implementada por la entidad receptora.
Si no es una versión implementada por la entidad receptora, el contador
(snmplnBadVersions) es incrementado y el paquete es descartado. En caso
afirmativo, se chequea la comunidad del mensaje para ver si se refiere a una conocida
a la entidad receptora.
Si la comunidad no es conocida, el contador (snmplnBadCommunityNames) es
incrementado y el paquete descartado. En caso afirmativo, se chequea la comunidad
para ver si esta tiene autorización para utilizar la operación contenida en los datos del
mensaje.
Si no tuviera autorización, el contador (snmplnBadCommunityUses) es
incrementado y el paquete descartado. De otra forma, La entidad receptora chequea
para mirar que clase de recursos de objetos están asociados con la comunidad
Si la comunidad se refiere a recursos de objetos locales, entonces la operación se
desarrolla de acuerdo con los MlBs apropiados asociados con la comunidad.
En cambio si la comunidad se refiere a recursos de objetos remotos, entonces:
Si la operación es una respuesta, entonces es correlativa con la anterior petición, y
una respuesta es enviada a la entidad originaria de la petición.
Si la operación es una Trap o un informe, entonces el agente proxy, usando
conocimiento local, determina la entidad SNMP que debería enviar el mensaje.
De otra forma, La petición se propaga por la relación proxy definida por la comunidad.
4.8.9.- Esperando por Mensajes
Normalmente las entidades SNMP esperan los mensajes en la dirección de transporte
por defecto asociada con cada dominio de transporte válido para el.
5.- MODELO OPERACIONAL
Examinaremos el papel de las operaciones del protocolo en el entorno de
administración. SNMP es un protocolo asíncrono de petición-respuesta basado en el
modelo de interrupción-sondeo directo; esto significa que una entidad no necesita
54
esperar una respuesta después de enviar un mensaje, por lo que puede enviar otros
mensajes o realizar otras actividades.
SNMP tiene pocos requisitos de transporte ya que usa un servicio de transporte no
orientado a conexión, y que normalmente es UDP. Aunque ésto ratifica el Axioma
Fundamental, hay una razón más importante: Las funciones de administración de red
se realizan cuando hay problemas, de modo que la aplicación de administración es la
que decide qué restricciones realiza para el trafico de administración. La elección de
un servicio de transporte no orientado a
conexión permite a la estación determinar el nivel de retransmisión necesario para
complacer a las redes congestionadas.
5.1 .- lnteracciones del Protocolo
Una interacción SNMP consiste en una petición de algún tipo, seguida por una
respuesta. Hay cuatro resultados posibles de una operación:
Una respuesta sin excepción o error.
Una respuesta con una o más excepciones.
Una respuesta con error.
Sobrepasar el tiempo de espera (timeout).
PDUS : : =
CHOICE {
get-request
[O] IMPLICIT PDU,
get-next-request
[l] IMPLICIT PDU,
response
[21 IMPLICIT PDU,
set-request
[ 3 ] IMPLICIT PDU,
- - [ 4 ] está obsoleta
get-bulk-request
[ 5 ] IMPLICIT PDU,
55
inform-request
[61 IMPLICIT PDU,
trap
[7] IMPLICIT PDU,
report
[ 8 1 IMPLICIT PDU
max-bindings
INTEGER : : = 2147483647
PDU : :I
SEQUENCE {
request-id Integer32,
error-status - - Algunas veces se ignora
INTEGER {
noError ( O
tooBig ( 1 ) ,
noSuchName
badvalue (
readonly (
genErr ( 5 )
( 2 ) , - - Compatibilidad con proxy
3 ) , - - Compatibilidad con proxy
4 ) , - - Compatibilidad con proxy
noAccess (6) ,
wrongType (7 ) ,
wrongLength ( 8 1 ,
wrongEncoding ( 9 ) ,
wrongvalue (10) ,
nocreat ion ( 11) ,
inconsistentValue(l2),
resourceunvailable(l3).
commitFailed(l4),
undoFailed(lS),
authorizationError(l6),
notwritable (17) ,
inconsistentName(l8)
I r
56
error - index - - Algunas veces se ignora
INTEGER (O..max-bindings),
variable-bindings - - A veces se ignoran los valores
VarBindList
1 - - colecciones de variables
VarBind : :=
SEQUENCE {
Name
ObjectName,
CHOICE {
value Objectsintax,
unspecified - - En peticiones de recuperacibn
NULL, - - Excepciones en respuestas
noSuchObject [ O 1
IMPLICIT NULL,
noSuchInstance [ll
IMPLICIT NULL,
EndOfMivView [ 2 ]
IMPLICIT NULL
1 1
- - lista de instanciaciones de variables
VarBindList ::=
SEQUENCE (SIZE (O. .max-bindings) ) OF VarBind
En esta definición se puede apreciar la influencia del Axioma Fundamental. Por
ejemplo, ni el campo error-status ni error-index se usan con el tipo de dato
GetRequest-PDU, pero al incluirlos, se puede usar un solo tipo de dato ASN.l para el intercambio de mensajes en todas las operaciones SNMPv2. Esto significa que sólo hay que escribir dos rutinas para codificar y decodificar los mensajes de la transmisión.
A continuación se describen los campos del tipo de dato PDU.
57
request-id, valor entero usado por la aplicación para distinguir entre peticiones
pendientes, lo que permite a la aplicación mandar rápidamente varios mensajes
SNMP, reconocer mensajes duplicados en la red y medir el tiempo del tráfico que
genera. Los agentes no pueden modificar este campo.
error-status, si no es cero, representa un error al procesar la petición y que debería
ignorarse el campo variable-bindings.
error-index, si no es cero indica qué variable de la petición es errónea.
variable-bindings, Lista de variables, con su nombre y valor.
Las operaciones de SNMPv2 se pueden clasificar así:
Recuperación: get, get-next y get-bulk.
Modificación: set.
Invocación: snmpv2-trap.
Administradores: inform.
5.1 A .- lnteracciones
Veamos primero una interacción normal entre dos entidades SNMPv2, para más
adelante estudiar sus variaciones:
1. La entidad que inicia el protocolo hace una petición con:
Un Único request-id.
error-statuslerror-index a cero.
Cero o más instancias de variables.
2. Si la operación no fue snmpv2-trap, la entidad que responde da una respuesta con:
El mismo request-id.
error-status a cero.
Las mismas instancias de variables.
Si se solicita una operación de recuperación, en la petición, los valores asociados con
las variables tienen el valor unspecified; si no, las instancias de variables esperan
58
valores. Si no se solicita una operación de recuperación, las instancias de las variables
de la respuesta son iguales a las de la petición.
5.1.2.- Interacción de Excepciones
Mientras se procesa una petición de recuperación, el agente podría encontrar una
excepción, indicando que una determinada variable no puede ser procesada. Hay tres
tipos de valores de excepción:
noSuchObject, indica que el tipo de objeto correspondiente a la variable no se
implementa por el agente.
noSuchlnstance, indica que la instancia de un objeto particular identificado por la
variable no existe en la vista del MIB para la operación.
endOfMibView, indica que no hay más información en la vista del MIB para la
operación.
Por tanto, el funcionamiento de interacciones SNMPv2 con excepciones es de la
siguiente forma:
1. La entidad que inicia el protocolo hace una petición de recuperación con:
Un Único request-id. error-statuslerror-index a cero.
Cero o mAs instancias de variables.
2.- La entidad que responde da una respuesta con:
El mismo request-id. error-status a cero.
Las mismas instancias de variables, pero con diferentes valores y uno o más
valores de excepción.
59
5.1.3.- Interacción de Error
Mientras se procesa alguna petición, el agente puede encontrar un error e indica que
la operación no puede procesarse. Hay varias clases de error. El funcionamiento de
interacciones SNMPv2 con excepciones es de la siguiente forma:
l. La entidad que inicia el protocolo hace una petición de recuperación con:
Un Único request - id. error- statuslerror- index a cero. Cero o más instancias de variables.
2. La entidad que responde da una respuesta con:
El mismo request -id. error-status a Cero. Las mismas instancias de variables que la peticidn.
Teniendo en cuenta que los errores nunca se devuelven en una respuesta a una
operación de invocación, hay dos clases de errores que pueden devolverse en la
respuesta a cualquier otra petición:
tooBig, indica que la respuesta podría ser demasiado larga para enviarla.
genErr, no debería devolverse excepto que no haya otra posibilidad.
Si se procesa una petición de modificación, hay otra case de errores que deberían
devolverse, pero que se verán más adelante.
5.1.4.- Interacción de Timeout
Esta interacción ocurre cuando se envía una petición pero no se recibe respuesta. Hay
varias posibilidades:
La red omite la petición.
El agente no está ejecutándose.
El agente omite la petición.
La red omite la respuesta.
El tiempo de espera fue muy corto.
60
5.1 5 . - lnteracción al Procesamiento
Para procesar las peticiones, primero debe aceptarse una estructura Message para
que la evalúe la entidad. Cuando la petición se procesa, se examina la lista de
variables instanciadas; en el caso que el campo variable-bindings esté vacío, termina
el procesamiento devolviendo una respuesta noError.
5.2.- Peticiones de Recuperación
Para examinar eficientemente la información de administración, el entorno de
administración usa un método inteligente para identificar las instancias: Es usado un
OBJECT IDENTIFIER, formado por la concatenación del nombre del tipo objeto con
un sufijo.
5.2.1.- El Operador Get
Si la aplicación de administración conoce las instancias que necesita, realiza una get-
request. Sólo se pueden devolver los errores tooBig y genErr.
Por otro lado, para cada variable de la petición, la instancia se recupera de la vista del
MIB con esta operación:
Si el agente no implementa el tipo objeto asociado con la variable, se devuelve la
excepción noSuchObject.
Si la instancia no existe o no la soporta el MIB, se devuelve la excepción
noSuchlnstance.
Se devuelve el valor asociado a la instancia.
5.2.2.- El Operador Get-Next
Si la aplicación no conoce exactamente la instancia de la información que necesita,
realiza una get-next-request. Sólo se pueden devolver los errores tooBig y genErr.
61
Por otro lado, para cada variable de la petición, se devuelve la primera instancia que
siga a la variable que esté en la vista del MIB con esta operación:
Si no hay una próxima instancia para la variable en el MIB, se devuelve una excepción
endOfMibView.
Si se reconoce la siguiente instancia de la variable en el MIB, se devuelve el valor
asociado.
El operador get-next puede usarse para comprobar si un objeto es soportado por un
agente.
Debido al almacenamiento que se hace en el MIB, las tablas se examinan en un orden
columna-fila; así, se examina cada instancia de la primera columna, cada instancia de
la segunda y así seguidamente hasta el final de la tabla. Entonces, se devuelve la
instancia del siguiente objeto , y sólo se devuelve una excepción si el operando de
get-next es mayor, lexicográficamente hablando, que la mayor instancia del MIB.
Como el operador get-next soporta múltiples operandos, se puede examinar
eficientemente la tabla entera. La aplicación de administración conoce que llega al final
de la tabla cuando se devuelve un nombre cuyo prefijo no coincide con el del objeto
deseado.
Puede ocurrir que al usar el operador get-next con múltiples operandos para examinar
una tabla vacía, se devuelva un error de tipo tooBig en vez de devolver las múltiples
instancias de la variable. Esto ocurre debido a que el operador no pudo encontrar
instancias en la tabla.
5.2.3.- El Operador Get-Bulk
Su función es minimizar las interacciones en la red, permitiendo al agente devolver
paquetes grandes. Este esquema tiene que funcionar con un servicio de transporte no
orientado a conexión de modo que la aplicación sea la responsable de controlar las
interacciones. Las aplicaciones de administración también deben controlar los tiempos
de las interacciones
El formato que sigue la SNMPv2 BulkPDU es el siguiente:
BulkPDU : : =
SEQUENCE {
request-id Integer32,
62
non-repeaters INTEGER(O..max-bindings),
max-repetitions INTEGER(O..max-bindings),
variable-bindings VarBindingList
1 Este formato es estructuralmente idéntico la del resto de operaciones SNMP, y los
campos se describen a continuación:
request-id, el usual.
non-repeaters, número de variables que deberían recuperarse de una vez.
max-repetitions, número máximo de veces que otras variables deberían recuperarse.
variable-bindings, el usual ignorando los valores.
Cuando un agente recibe una get-bulk, calcula el mínimo de:
El tamaño máximo del mensaje del emisor.
El tamaño de la generación de mensajes del propio agente.
De aquí resta la suma de dos cantidades:
El tamaño de las capas de privacidad/autentificación de la generación de la respuesta.
El tamaño de una respuesta sin variables instanciadas.
Dicha diferencia indica la cantidad máxima de espacio posible para las instancias de
las variables en la respuesta. Si la diferencia es menor de cero, la respuesta se pierde:
si no, se genera la respuesta, que tendrá cero o más variables instanciadas.
El agente examina las variables de la petición usando el operador get-next y
añadiendo cada nueva instancia con su valor a la respuesta y decrementando la
cantidad de espacio libre. Si no hay suficiente espacio, se envía la respuesta antes de
colapsar el espacio libre.
Finalmente, el espacio libre se ocupa, o se realiza el máximo número de repeticiones.
Es importante tener en cuenta que el agente puede terminar una repetición en
cualquier momento.
Existe otra forma con la que la operación get-bulk termina prematuramente: Esto
ocurre cuando al examinar las variables de la tabla, se devuelve una excepción
endOfMibView. En este caso, todas las futuras repeticiones devolverán lo mismo y se
omitirán de la respuesta.
63
Por último, es importante saber que cuando un agente decide procesar una petición
get-bulk, sólo se puede devolver el error genErr, ya que devolver tooBig no tiene
sentido.
Más Características del Operador Get-Bulk
La respuesta a un operador get-bulk no es más que la concatenación de un número
de respuestas max-repitition de interacciones get-next.
La parte más interesante del operador get-bulk es que puede implementarse en el
agente a alto nivel mejor que en las rutinas específicas de los objetos.
5.3.- Peticiones de Modificación
Sólo hay una petición de modificación: El operador set. Cuando una aplicación de
administración conoce exactamente las instancias que necesita, genera una set-
request.
La semántica de la operación set es tal que la operación tiene éxito si y sólo si todas
las variables se actualizan. Para explicarlo usaremos el concepto del compromiso de
/as dos fases, pero antes de empezar, se asegura que la respuesta no sea tan grande
como para no poder ser enviada, ya que si no, se generaría un error tooBig.
Dicho concepto consta de dos pasadas. En la primera, cada instancia se examina y se
hace una comprobación para verificar que:
La variable es soportada por la vista del MIB para esa operación.
Si la variable existe, el agente puede modificar las instancias del tipo objeto
correspondiente.
El valor proporcionado es correcto sintácticamente.
Si la variable no existe, el agente es capaz de crear instancias del tipo de objeto
correspondiente.
El nombre y valor proporcionado son correctos sintácticamente y son consistentes con
los valores de las otras variables de la petición.
Todos los recursos necesarios para el cambio están reservados.
64
Si alguna de estas condiciones no se verifica para alguna de las instancias, se
devuelve el error apropiado y se liberan los recursos.
SNMPv2 soporta nuevos códiqos de error, además de los habituales, que son los siguientes, así como las causas que los producen:
noAccess, la variable no es soportada por la vista del MIB para esa operación.
notwritable, La variable existe pero el agente no puede modificar instancias del tipo
objeto correspondiente.
wrongType, el nuevo valor proporcionado es de un tipo de datos ASN. 1 erróneo.
wrongLength, el nuevo valor proporcionado es de longitud errónea.
wrongEncoding, el nuevo valor proporcionado está codificado erróneamente.
wrongvalue, el nuevo valor está fuera del rango de valores admitidos para el tipo de
objeto correspondiente.
nocreation, la variable no existe y el agente no puede crear instancias del tipo objeto
correspondiente.
inconsistentName, la variable no existe y no puede ser creada porque el nombre de
la instancia es inconsistente con los valores de otro objeto en el agente.
inconsistentvalue, el valor proporcionado es inconsistente con los valores de otro
objeto en el agente.
resourcellnvailable, un recurso requerido no puede ser reservado.
Los códigos nocreation y notwritable son de tipo permanente, mientras que los tres
últimos son de tipo transitorio. El resto son casos que no deberían ocurrir si la
aplicación y el agente tuvieran un mismo concepto de los objetos en cuestión.
Sólo si cada instancias ha superado la primera pasada, se hace la segunda, en la cual
se acomete el cambio de cada instancia. Por experiencia, pueden existir fallos en esta
segunda pasada. Si ocurre, el agente trata de deshacer los cambios y devuelve uno de
los dos siguientes tipos de error:
commitfailed, indica que hubo un fallo en la segunda pasada pero que se deshicieron
los cambios.
undofailed, indica que falló la segunda pasada y que algunos cambios no pudieron
deshacerse.
Si se devuelve alguno de estos errores, se pone a cero el campo error-index,
indicando que hay un problema grave en el agente.
65
5.3.1 .- Operador Set
Cuando una aplicación de administración usa la operación set, hay que tener en
cuenta varias cosas:
Hay que tener cuidado al agrupar objetos en una sola petición set, ya que si algún
objeto puede resetear al agente, el resto de objetos no tendrán ningún efecto.
El servicio de transporte puede duplicar peticiones o repartir peticiones que estén fuera
de servicio. Por tanto, si una operación set depende de otra operación set anterior, la
segunda debe esperar hasta que los paquetes de la primera petición no existan en la
red. Esto se puede solucionar con la convencih textual TestAndlncr., o incluir
snmpSetSerialNo en el set para asegurar el procesamiento ordenado de las
peticiones.
Para algunos objetos no debería retransmitirse la operación set sólo porque no se
haya obtenido respuesta y sin usar una operación get para asegurarse que la
operación set tuvo efecto.
5.4.- Manejo de Filas de Conceptos
Desde la perspectiva del protocolo, no existe el con tcepto de fila en SNMP. En
particular no existe relación entre las variables presentadas en una lista de variables.
Cualquier relación existe como una característica del diseño de MIB, no por
operaciones de protocolo.
Podemos considerar un reto el crear instancias en una fila de conceptos, dado el
modelo operacional que usa el entorno de administración. Hay que tener en cuenta:
El agente puede no ser capaz de implementar algunas columnas en una fila de
conceptos.
El agente puede necesitar que algunas columnas se creen antes de usarlas.
Los valores de todas las columnas pueden no entrar en una sola PDU.
La aplicación de administración puede querer examinar los valores de algunas
columnas.
Las aplicaciones que cooperan no quieren comisionar al crear nuevas filas.
66
En SNMPv2, la convención textual Rowstatus se usa para expresar la forma de
manipular una fila: cuando una tabla se define en un módulo MIB, debe definirse una
columna status con la sintaxis de Rowstatus. El significado de una variable de la
columna status es que su valor indica la relación entre el dispositivo y la fila de
conceptos.
Un resumen de la convención textual Rowstatus es la siguiente:
Rowstatus : := TEXTUAL-CONVENTION
SYNTAX INTEGER {
- -dos valores de estado/acción que pueden ser leidos o escritos. active(1) , notInService ( 2 ) , - -un valor de estado, que solo puede ser leido. NotReady ( 3 ) , - -tres valores de acción que sólo pueden ser escritos crea t eAndGo ( 4 ) , createAndWait(5), destroy(6) 1
5.4.1 .- Creación de una Fila de Conceptos
El primer paso es la creación de un identificador de la instancia, que es específico para
cada tabla MIB. El identificador de instancia debe tener sentido semánticamente o ser
usado singularmente. En el último caso, el módulo MIB puede proporcionar un objeto
para ayudar a elegir un identificador sin usar, aunque si dos aplicaciones eligen el
mismo identificador, la convención Rowstatus genera un mecanismo para evitar la colisión.
El siguiente paso es crear la fila, y se puede hacer de dos formas:
Aproximación Directa, la fila se crea y se activa para ser usada por un dispositivo con
una sola operación set.
Aproximación Negociada, se crea la fila y por medio de un conjunto de interacciones,
se inicializa y se activa para ser utilizada por el dispositivo.
La aplicación de administración debe determinar para cada columna:
Qué columnas necesita el agente para activar la fila.
67
Qué columnas no puede crear el agente, por alguna razón.
Una vez creada la fila, la aplicación realiza una operación get para cada columna que
conoce, usando el identificador seleccionado en el primer paso. Para cada columna
requerida:
Si se devuelve un valor, el agente está indicando que implementa esa columna.
Si se devuelve una excepción noSuchlnstance, el agente indica que implementa la
columna, pero que la instancia en sí no existe.
Si se devuelve una excepción noSuchObject, el agente indica que no implementa el
tipo de objeto correspondiente a esa columna.
5.4.1 .I .- Aproximación Directa
Primero se selecciona el identificador deseado. Entonces la aplicación decide lanzar
un get para determinar los requisitos del agente para la columna. Todos los valores
devueltos deberían ser excepcionales, ya que si no se indicaría que la fila ya existe.
Entonces la aplicación enviará al agente un set, que contiene valores para las
columnas con un MAX-ACCESS de read-create y el estado de la columna puesto a
createAndGo.
Cuando el agente procesa la columna de estados en las instancias, si la variable ya
existe, devuelve un error inconsistentvalue; si no, el agente comprueba que tiene
suficiente información (procedente del set y de información local) para crear y activar
la fila. Si hay suficiente información, entonces:
Se crea la fila.
Se devuelve una respuesta con noError
El agente asigna valores por defecto a las columnas de las filas cuyos valores no se
especificaron en el set.
La columna de estado se pone a active.
Si no hay suficiente información, se devuelve un error inconsistentvalue.
68
Se debería tener en cuenta que puede que no todas las filas entren en una sola PDU.
También, la respuesta de get indica que aquellas columnas que implemente el agente
deben ser superconjuntos de las columnas que son obligatorias. Así, en el set, la
aplicación sólo tiene que preocuparse de las columnas con un MAX-ACCESS de
read-create.
Para que esta aproximación funcione, la versión del módulo MIB que conoce la
aplicación y el agente debe coincidir.
5.4.1.2.- Aproximación Negociada
Lo primero es seleccionar el identificador deseado. Entonces, la aplicación genera un
set con la columna de estado puesta a createAndWait y lo envía al agente. Cuando el
agente procesa la
columna de estado en las instancias, si no soporta la creación negociada, devuelve un
error wrongvalue, o si la variable ya existe, devuelve un error inconsistentvalue. En
otro caso:
Se crea la fila.
Se devuelve una respuesta noError.
El agente asigna valores por defecto a las columnas de las filas cuyos valores no se
especificaron en el set.
El agente debe asignar valores por defecto a aquellas filas que implementa de solo
lectura.
La columna de estado se activa a notlnService o a notReady, según la información
disponible del agente.
La estación de administración puede usar entonces un get para determinar los
requisitos de las columnas del agente. Para cada columna read-create solicitada:
Si se devuelve un valor, el agente indica que implementa esa columna y que si a la
aplicación no le gusta el valor, debe generar un set para cambiarlo.
69
Si se devuelve una excepción noSuchlnstance, el agente indica que antes de activar
la fila, la aplicación debe generar un set para proporcionar valores para la columna.
Si se devuelve una excepción noSuchObject, el agente indica que la aplicación no
debe intentar dar un valor.
Cuando el valor de una columna de estado cambia a notlnService, el agente indica
que la fila está siendo usada en el dispositivo y que la aplicación debería poner la
columna de estado a activa. Hay que tener en cuenta que es la aplicación la que
determina el número de operaciones set que quiere realizar.
Si una fila se encuentra en el estado notlnService o notReady, pueden aparecer
problemas: Si el dispositivo crea o modifica la misma fila que está siendo negociada
entre la aplicación y el agente, entonces existirán dos copias, una en el dispositivo y
otra en el agente, aunque cuando la columna de estado se active en el agente, ésta
eliminará la del dispositivo.
También puede ocurrir que el proceso de negociación se vea interrumpido. Por eso, el
agente debe almacenar de vez en cuando filas que no estén en estado activo.
5.4.2.- Modificación de una Fila de Conceptos
Algunos m6dulos MIB precisan que se desactive una fila para poder modificarla. Para
ello, la aplicación pone la columna de estado a notlnService. Si el agente no lo
soporta, devuelve un
error wrongvalue; si no, la fila no es accesible para el dispositivo y se devuelve una
respuesta de noError.
Desactivar una fila es útil cuando las modificaciones no caben en una sola PDU. Por
supuesto, hasta que no se hacen todas las modificaciones, la fila no será consistente,
por lo que el agente pone la columna de estado a notReady.
5.4.3.- Eliminación de una Fila de Conceptos
La aplicación pone la columna de estado a destroy. El agente hace la fila inaccesible
al dispositivo y a éI mismo y devuelve una respuesta noError.
70
5.5.- lnteracciones de Invocación
Cuando un agente detecta un evento extraordinario, se genera una invocación
snmpV2-trap,
que se envía a una o más aplicaciones de administración. La invocación snmpV2-trap
tiene un formato idéntico a las PDU usadas en otras peticiones.
Las dos primeras instancias son especiales:
sysUpTime.0, momento en que se generó la invocación.
snmpTrapOlD.0, el identificador de objeto de la invocación.
5.5.1.- El Grupo snmpTrap
Hay dos objetos escalares relacionados con las invocaciones SNMP.
snmpTrap OBJECT IDENTIFIER ::={snmpMIBObjects 4) snmpTrapOlD OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
MAX-ACCESS accesible-for-notify
...
::= {snmpTrap 1)
5.6.- lnteracciones entre Administradores
Cuando una aplicación quiere informar a otra aplicación, genera una inform-request.
El formato de la InformRequest-PDU es idéntico al de las otras PDU del resto de
peticiones. AI igual que snmpV2-trap, las dos primeras instancias indican el momento
del evento y su identidad.
Como es de esperar, sólo algunos dispositivos pueden tener el papel de administrador.
Hay que tener cuidado para minimizar el número de informes que se generan.
Actualmente, el control de la generación y retransmisión de informes es una tarea
específica de implementación.
71
5.6.1 .- Entidades de Doble Rol
Se trata de dispositivos que contienen agentes y aplicaciones de administración. Estos
dispositivos recogen y procesan información de los agentes y la proporcionan a los
administración. As;, según el entorno SNMPv2, una aplicación de administración es
algo que inicia una interacción entre peticiones y respuestas.
Administrador Response, snmpV2-trap, Get, get-next, get-bulk, set, inform, response inform
5.7.- Mapeo de Transporte
Las operaciones SNMP son independientes del protocolo de transporte, utilizando sólo
un servicio de transporte no orientado a conexión.
Para definir el mapeo de transporte, se especifican dos pasos:
Reglas para tomar la estructura de un mensaje y transformarlo en una cadena de
octetos para formar un paquete.
Reglas para enviar el paquete por el servicio de transporte.
Hay varios mapeos de transportes definidos y usan el mismo conjunto de reglas para
el primer paso. Como todos los objetos y estructuras SNMP se definen con el ASN.l
de OSI, el entorno de administración usa BER (Basic Encoding Rules) de OS1 para
codificar las estructuras en octetos. Cuando éstos se reciben, se transforman en una
estructura de datos con una semántica idéntica.
Hay varios mapeos de transportes definidos y usan el mismo conjunto de reglas para
el primer paso. Como todos los objetos y estructuras SNMP se definen con el ASN.l
de OSI, el entorno de administración usa BER (Basic Encoding Rules) de OS1 para
codificar las estructuras en octetos. Cuando éstos se reciben, se transforman en una
estructura de datos con una semántica idéntica.
72
5.7.1 .- Direcciones y Dominios de Transporte
La relación del protocolo de administración y el servicio de transporte se denomina
Dominio de Transporte.
5.7.1 .I .- Dominio snmpUDPDomain
Identifica el uso de SNMPv2 sobre UDP. Este es el mapeo preferido.
Si un objeto TDomain tiene un valor de snmpUDPDomain, entonces el correspondiente objeto TAddress se codifica en seis octetos:
SnmpUDPAddress ::= TEXTUAL-CONVENTION
DISPLAY-HINT "Id. Id. ld.ld/Zd"
STATUS current
DESCRIPTION
SYNTAX OCTET STRING (SIZE ( 6 ) )
La entidad que envía transforma y envía el mensaje como un Único datagrama UDP a
la dirección de transporte de la entidad receptora. Por convención, los agentes SNMP
escuchan en el puerto UDP 161 y envían las notificaciones al puerto UDP 162, aunque
una entidad debería configurarse para usar cualquier selector de transporte aceptable.
Todas las entidades receptoras deben admitir mensajes de al menos 1472 octetos de
longitud.
5.7.1.2.- Dominios snmpCLNSDomain y snmpCONSDomain
Identifican el uso de SNMPv2 en los servicios de transporte no orientados a conexión
de OS1 (CLTS): snmpCLNSDomain se usa cuando CLTS se ejecuta en servicios de
red no orientados a conexión de OS1 (CLNS), mientras que snmpCONSDomain se
usa cuando CLTS se ejecuta en servicios de red orientados a conexión de OS1
(CONS).
73
Si un objeto TDomain tiene alguno de estos dos valores, el correspondiente objeto
TAddress se codifica así:
SnmpOSIAddress : := TEXTUAL-CONVENTION
DISPLAY-HINT "*lX:/lX:"
STATUS current
DESCRIPTION
Y
(O ó de 3 a 20) 2..(n+l)
Cadena de hasta 64 octetos TSEL (n+2)..m Representación binaria concreta NSAP
SYNTAX OCTET STRING (SIZE (1 1 4. . 8 5 ) )
La entidad que envía transforma el mensaje y lo envía como una única unidad de
datos del servicio de transporte (TSDU) a la dirección de transporte de la entidad
receptora. Los selectores de transporte por defecto son:
CLTS sobre CLNS I Notificaciones I Snmpt-l CLTS sobre CONS I Agente I Snmp-o CLTS sobre CONS I Notificaciones 1 Snmpt-o
Una entidad debería poder configurarse para usar cualquier selector de transporte
aceptable. Todas las entidades receptoras deben admitir mensajes de al menos 1472
octetos de longitud.
5.7.1.3.- Dominio snmpDDPDomain
Identifica el uso de SNMPv2 sobre Appletalk's DDP.
Si un objeto TDomain tiene un valor de snmpDDPDomain, entonces el
correspondiente objeto TAddress se codifica así:
SnmpNBPAddress ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
SYNTAX OCTET STRING (SIZE (3. . 9 9 ) )
La entidad que envía transforma el mensaje y lo envía como un Único datagrama DDP
a la dirección de transporte de la entidad receptora. Todos los agentes SNMP
escuchan en el tipo NBP SNMP Agent y las notificaciones se envían al tipo NBP SNMP
Trap Handler. Todas las entidades receptoras deben admitir mensajes de al menos
484 octetos de longitud.
5.7.1.4.- Dominio snmplPXDomain
Identifica el uso de SNMPv2 sobre Netware’s IPX
Si un objeto TDomain tiene un valor de snmplPXDomain, entonces el correspondiente
objeto TAddress se codifica así:
SnmplPXAddress ::= TEXTUAL-CONVENTION DISPLAY-HINT “4~.l~:lX:lx:lX:lx:lX.Zd’’
STATUS current
DESCRIPTION
1 ..4
Network-byte order Número de socket 11 ..I2 Network-byte order Dirección física 5..10 Network-byte order Número de red
SYNTAX OCTET STRING (SIZE ( 1 2 ) )
La entidad que envía transforma y envía el mensaje como un Único datagrama IPX a la
dirección de transporte de la entidad receptora. Por convención, los agentes SNMP
75
escuchan en el socket IPX 36879 y envían las notificaciones al socket IPX 36880,
aunque una entidad debería configurarse para usar cualquier selector de transporte
aceptable.
Todas las entidades receptoras deben admitir mensajes de al menos 546 octetos de
longitud.
5.8.- Resumen
SNMP es un protocolo Asincrono de Petición-Respuesta basado en el modelo de
interrupción-Sondeo Directo.
Necesita pocos requisitos de la capa de transporte(N0 orientada a conexión UDP)
En la interación SNMP se producen peticiones seguidas de respuestas; se pueden
producir 4 clases distintas de resultados:
Resultado correcto
Timeout
1 o varias Excepciones
Error
Existen 4 posibles tipos de operaciones:
Recuperación:GET(conoce exactamente la instancia que necesita), GET-NEXT(no la
conoce) y GET-BULK (reduce la interación en la red al usar paquetes mas grandes).
Modificaci6n:SET.
Invocación: SNMPVZ-TRAP.
Administración: INFORM.
Las operaciones SNMP son independientes del protocolo de transporte usado, pero
utilizaremos solo un servicio de transporte no orientado a conexión.
Usaremos reglas para: formar el paquete y el envio del paquete.
Llamamos Dominio de Transporte a la relación del protocolo de administración con el
servicio de transporte:
76
SnmpUDPDomain. Snmp sobre UDP
SnmpCLNS/CONSDomain. No orientado a conexión I Orientado a conexión
SnmpDDPDomain. Snmp sobre Appletalk's DDP
SnmplPXDomain. Snmp sobre Netware IPX.
6.- MANUAL DE USUARIO
6.1 .- Introducción
El motivo fundamental de este documento es el esclarecimiento de las operaciones
realizables con la parte ejecutable del proyecto, la cual se basa, a groso modo, en la
realización de un modelo de simulación que nos permita conocer más a fondo las
posibilidades de un sistema que disponga de uno o más agentes SNMP y varios
clientes.
En esta parte no nos centraremos en el por qué de los datos que se pueden visualizar,
ni tampoco en los fundamentos teóricos que motivan un comportamiento u otro por
parte del programa, ya que de esto se explica convenientemente en otro documento.
Se ha de recordar antes de comenzar la explicación que la página html que posee la
parte que incluye la simulación es la titulada "Módulo MIB"
6.2.- Fundamentos de la simulación
La simulación se basa en recrear unos datos reales, en este caso del tráfico de una
subred real.
Se han tomado los datos del número de paquetes UDP y TCP de un sistema real,
junto con el tamaño de dichos paquetes y su dirección origen y destino, durante todo
un día. Dichos valores han sido luego procesados para separar los paquetes
generados por sistemas servidores, siendo estos los que poseen un disco duro y
aplicaciones compartidas para el resto de usuarios del sistema; y los generados por
sistemas clientes, es decir, que hacen uso de las aplicaciones que se encuentran los
servidores.
Una vez separados estos datos, se obtuvieron estadísticos para el número de
paquetes UDP y TCP, es decir, la media y varianza de paquetes que genera cada
sistema (por un lado los clientes y por otro los servidores). También se extrajeron
77
dichos estadísticos para obtener el tamaño medio de dichos paquetes, la fracción de
los mismos que ocupan más de 1514 bytes (fragmentados), y en qué proporción, su
destinatario es un sistema no perteneciente a la subred.
Hay que hacer notar que se obtuvieron tres juegos de los estadísticos anteriormente
mencionados: uno para el tráfico generado durante la mañana, otro para el de por la
tarde, y un último para el tráfico nocturno.
La aplicación (applet) que realiza la simulación contiene los valores de los estadísticos
obtenidos con el procedimiento anterior, y, haciendo uso de una función que genera
valores para una distribución normal (0,l) - media O y desviación típica 1 - recrea uno
a uno los sistemas que componen la simulación, es decir, si ha de generar 3
servidores, para obtener su número de paquetes TCP haría:
N" de paquetes TCP de servidoro= MTCPServ & DtcpServ * Normal(0,l)
N" de paquetes TCP de servidorl= MTCPServ f DtcpServ * Normal(0,l)
N" de paquetes TCP de servidor2= MTCPServ k DtcpServ * Normal(0,l)
Siendo:
MTCPServ, el número medio de segmentos TCP que genera un sistema
servidor
DtcpServ, la desviación típica de paquetes generados por un servidor.
Además dicho valor es recalculado para la siguiente franja horaria, es decir, al existir 6
fracciones del tiempo total seleccionado, se calcula el valor de todos los estadísticos
de todos los equipos de la subred 6 veces en una simulación completa.
El resto de valores se calculan de la misma forma, escalando las gráficas de forma
pertinente procurando que los valores no superen el límite superior de la misma.
78
6.3.- Variables a incluir
Es imprescindible incluir una serie de estructuras o tipos, de los cuales se crearán
instancias de variables, y que almacenarán los valores de los estadísticos que se
desee tener en cuenta. En este caso, se han incluido ocho estadísticos, que pueden
ser pulsados con el ratón para ser seleccionados:
La pulsación de cualquiera de ellos se tendrá en cuenta a la hora de generar el módulo
MIB adecuado.
79
6.3.1 .- Significado de las variables:
Datagramas UDP transmitidos y Seamentos TCP transmitidos: Ambas indican que
se ha de tener en cuenta, en el módulo MIB, y en la supuesta aplicación SNMP, el
número de datagramas y segmentos que se transmiten por la red y cuyo protocolo de
transporte es el UDP y TCP respectivamente. AI ser un número de paquetes, parece
lógico que la estructura de datos que le contendrá sea de tipo Counter, es decir un
contador que incrementará el cliente SNMP cuando envíe un paquete por la red.
Datagramas UDP fragmentados Y Segmentos TCP fragmentados: Estas variables
tendrán en cuenta el número de paquetes que se envían bajo el protocolo de
transporte UDP y TCP respectivamente, los cuales, por ser de longitud mayor de la
permitida por el protocolo (1514 bytes), han sido fragmentados en varios paquetes de
transporte.
Bvtes transmitidos sobre TCP y sobre UDP: Se usarán para tener en cuenta el total
de bytes transmitidos por la red, que iban en paquetes de transporte TCP y UDP
respectivamente.
Tráfico interno y externo: Número de bytes que han circulado por la red y cuyo
destino era un sistema (Estacion de trabajo, servidor de red, PC, etc ...), perteneciente
o no, según si hablamos del interno o el externo, a la subred. Esto se puede observar
comparando la dirección IP origen y destino con la máscara de la subred, que en este
caso es la "150.214.69".
80
6.4.- Generando el Módulo MIB
Una vez que conocemos el significado de los posibles estadísticos a incluir, no queda
más que pulsar el botón que indica "Pulse para generar el módulo MIB". Una vez
hecho esto, aparece, por debajo del botón, un título y una ventana de texto, que
muestra el módulo MIB genérico que podría contener cualquiera de los clientes SNMP
que formaran parte de la red con las estructuras de datos necesarias y en notación
ASN.1, la cual está convenientemente explicada en otra sección de la documentación.
Todas las estructuras que contiene el módulo MI6 son altamente autoexplicativas, ya
que todas ellas contienen una cláusula "DESCRIPTION", la cual contiene una cadena
de caracteres que explica la funcionalidad de la estructura que la contiene.
También se puede observar la presencia, en la parte inferior de la figura 2, de otro
botón que nos da paso a la simulación.
81
6.5.- Opciones de simulación
Una vez que se ha incidido con el "click" del ratón sobre el botón de "Simulación",
aparecen una serie de posibles selecciones sobre el sistema a simular:
En esta parte de la configuración, se determinará el número de sistemas servidores y
clientes que componen la subred. Aunque un sistema real se compondrá de bastantes
más servidores y clientes, se ha limitado, para la simulación, a 25 equipos de cada
tipo, siendo los servidores, aquellos equipos que poseen un HD y programas que son
usados por el resto de servidores y clientes.
Otra de las opciones configurables del modelo de simulación es la franja horaria a
simular y el número de horas de la simulación:
Mañana : Se supone entre las 6:OO y las 14:OO horas.
Tarde: Entre las 14:OO y las 22:OO horas.
Noche: Entre las 22:OO y las 6:OO horas.
Existe una última opción que es la de "Acumular datos anteriores" que una vez
pulsada, nos permitirá ver la evolución de los datos a lo largo de varias simulaciones.
Ejemplo: Si queremos ver el tráfico de todo un día no tenemos más que realizar tres
82
simulaciones, de ocho horas, con esta opción pulsada. Hay que señalar que los datos
muestran los valores acumulados de una marca horaria con su homóloga de la
siguiente simulación, lo cual no ofrece un dato especialmente significativo, pero si
muestra el volumen total de tráfico a lo largo de las simulaciones acumuladas.
6.6.- Resultados de la simulación
Los resultados de la simulación emulan o intentan emular a lo que sería una aplicación
SNMP ejecutándose sobre un agente SNMP, es decir, una aplicación que, cada cierto
tiempo, lee los valores de las variables de los clientes SNMP, y realiza una
representación por pantalla de los mismos. La representación podría ser a base de
datos numéricos o en formato gráfico, siendo éste último, el optado para la muestra
por pantalla de los valores obtenidos de la simulación, ya que permite una percepción
global mucho más rápida y precisa, y al no ser un sistema real, la visualización de
valores concretos sería poco menos que desmerecer el trabajo realizado.
En la figura anterior podemos observar el resultado obtenido tras pulsar el botón de
"Realizar simulación" con ciertas opciones de simulación -qué más da- y habiendo
seleccionado todas las variables opcionales en el MIB.
83
El resultado siempre serán 5 gráficos que representarán el número de paquetes por
tiempo, el porcentaje de tráfico por tiempo y los Mb por tiempo, en el caso de los tres
superiores llamados generales; y el número de paquetes TCP y UDP por tiempo para
uno de los servidores y uno de los clientes, en el caso de los inferiores.
La aparición del número de componentes de cada gráfica dependerá de las variables
del MIB seleccionadas en el momento de su generación.
La componente X de las escalas, es bastante explícita por el contenido de la gráfica y
su título. Hay que notar que las escalas de paquetes y Mbytes son variables, y que no
siempre, la misma altura, representa el mismo valor.
La componente Y de las escalas, se puede ver que es la misma en las 5 gráficas y una
sexta parte del tiempo total de simulación, es decir, si se toman 6 horas, cada
intervalo, que representa cada cuanto tiempo se recogen los valores de los clientes y
se realiza la representación, será de 1 hora.
84
7.- CONCLUSIONES
Este sistema ofrece una visión global de lo que podría ser un sistema SNMP, pero
nunca hay que olvidar que está basado en el tráfico total de una subred durante un día
completo, es decir, no se pueden establecer conclusiones generales sobre los
resultados o interpolarlas a otro sistema que disponga de otras aplicaciones y otros
horarios de trabajo.
La aplicación ofrece alta interactividad del usuario, y es por esto que permite realizar
muchos tipos de simulaciones que pueden ofrecer ideas claras sobre un sistema, pero
al mismo tiempo, un uso inconsciente de la misma, puede ofrecer datos que en
absoluto tengan relación con un sistema real.
85
8.- BIBLIOGRAFíA
Brogden, Tittel - Manual fundamental de Java - Ed. Anaya Multimedia - 1997
Groenendaal, Kleijnen van - Simulation, a statistical perspective - Ed. Wiley - 1992
RFC 1034 - Domain Names - lmplemetation and Specification
RFC 951 - Bootstrap Protocol
RFC 1907 - Management Information Base for version 2 of SNMP
RFC 1442 - Structure of Management Information for version 2 of the Simple Network
Management Protocol (SNMPv2)
RFC 1157 - A Simple Nenwork Management Protocol
Rose, Marshall T. -The Simple Book: An lntroduccion to Networking Management - Ed.
Prentice-Hall-1995
Rose, Marshall T. -The internet message: Closing the book with electronic mail.
Siyan, Karanjit S. - Todo Visual J++ - Ed. Inforbook's - 1997
Stallings, William - Data and computer communications - Ed. Prentice-Hall - 1997
Tanenbaum, Andrew S. - Redes de ordenadores - Ed. Prentice-Hall - 1991
Thomas, Patel, Hudson, Ball - Programación en JAVA para Internet - Ed. Paraninfo - 1997
Tittel, Gaither, Hassinger, Erwin - Fundamentos de programación con HTML & CGI - Ed.
Anaya Multimedia - 1996
Watson, Blackstone - Computer simulation - Ed. Wiley - 1989
86