SNMP

13.- SNMP: PROTOCOLO DE GESTIN DE RED SIMPLE

En los ltimos aos, SNMP ha ido cobrando mayor importancia, convirtindose en el mecanismo dominante en la gestin distribuida de redes. El aspecto ms relevante de SNMP es la capacidad que tiene de monitorizar y gestionar redes manteniendo un esquema de simplicidad y efectividad. El trmino SNMP se emplea habitualmente para hacer referencia al conjunto de componentes necesarios para gestionar una red, cuando en realidad, SNMP slo es el protocolo utilizado para intercambiar informacin de gestin entre los dispositivos de la red, ya que su definicin no cubre todos los aspectos del sistema de gestin. En este captulo revisaremos todos estos componentes que se utilizan conjuntamente con SNMP. Curiosamente, y pese a ser definido para su utilizacin en entornos TCP/IP, SNMP se basa en las definiciones de gestin de red desarrolladas por OSI. 13.1.- NECESIDAD DE LOS SISTEMAS DE GESTIN Durante los aos ochenta, las redes evolucionaron y pasaron de ser el vehculo para el acceso de los terminales a los sistemas centrales a ser redes de comparicin de recursos basadas en PCs, microordenadores y mainframes interconectados entre s y con un sistema operativo de red. Esto constituye lo que conocemos como sistemas distribuidos, en los cuales los buses internos de los ordenadores han sido sustituidos por la red; este tipo de sistema de informacin se ha convertido en el elemento bsico de la tecnologa de la informacin, siendo la red el ncleo de todo ello. Dado que los fallos en la red tienen una repercusin directa sobre la organizacin, la capacidad de mantener los recursos funcionando correctamente se ha convertido en una misin crtica. Hasta la llegada de SNMP, la gestin de red haba sido propietaria y los productos desarrollados por cada fabricante, lo que complicaba enormemente los centros de control de las redes heterogneas, adems dada la dificultad de desarrollar este tipo de productos y el mercado restringido al que iban dirigido, los productos eran caros y complejos. Con el crecimiento de la popularidad de TCP/IP, apareci un mercado lo suficientemente atractivo para que la IETF propusiera un estndar de gestin y los desarrolladores de software se sintieran atrados a desarrollar sistemas de gestin sofisticados a un costo reducido que pudiera ser atractivo incluso para los gestores de red de organizaciones pequeas. La gestin de red es un problema clsico de tecnologa de informacin, se necesitan grandes cantidades de informacin para entender lo que est pasando dentro del sistema y poder tomar las decisiones acerca de cmo controlar, adaptar o hacer crecer el servicio. Esto precisa de grandes cantidades de espacio en disco para almacenar informacin sobre largos perodos de tiempo, gran cantidad de memoria y capacidad de procesamiento para ejecutar las herramientas de anlisis y capacidad grfica para mostrar los mapas de la red y diagramas en los cuales sealar las alarmas y faltas. Un aspecto potencial de estos sistemas es que pueden generar tanto trfico en la red y tanta informacin para gestionarse a s mismo que pueden llegar a convertirse en una carga significativa para la red.

REDES DE ORDENADORES

SNMP

13.2.- EL DESARROLLO DE LA GESTIN TCP/IP Para que una gestin estndar tenga xito debe basarse en software simple, pequeo y de bajo costo para poder instalarlo en la gran cantidad de pequeos dispositivos que constituyen la red, de otro modo quedarn reducidos a los sistemas centrales que recogen y analizan informacin de gestin. El origen de SNMP se encuentra en las iniciativas de OSI en el rea de la gestin de red (CMIS/CMIP) de mediados de los ochenta. Mientras se estaban iniciando ambos desarrollos pudo apreciarse que estos estndares no se ajustaran a las necesidades de simplicidad y bajo costo. La estructura de gestin de SNMP es una versin simplificada de los desarrollos de OSI; SNMP tiene un nivel de presentacin y los estndares estn definidos haciendo uso del lenguaje de OSI, ANS.1. Inicialmente existieron dos propuestas para la gestin TCP/IP, por un lado SNMP y por otro CMOT (Common Management Information Services and Protocol over TCP/IP). CMOT utiliza los estndares OSI CMIP ( Common Management Information Protocol ) y CMIS ( Common Management Information Services ) operando sobre protocolos TCP/IP en vez de OSI. SNMP opera sobre UDP como nivel de transporte y es un sistema no orientado a la conexin, por contra CMOT utiliza CMIP y CMIS y est basado en un sistema orientado a la conexin. En todo caso, CMOT es hoy poco menos que historia, pese a que el Internet Architecture Board definiera que sera el objetivo de su estrategia a largo plazo. SNMP fue publicado inicialmente en 1989 pero las primeras aplicaciones no aparecieron hasta 1990. SNMP v2 apareci en Mayo de 1993 aadiendo nuevos comandos para as reducir el trfico en la red, especialmente en redes grandes, ofrece adems nuevas capacidades de notificacin de errores, introduce la definicin de nuevos objetos, ms contadores y mejores herramientas de gestin, as como aadidos para garantizar la seguridad y la autenticacin. En abril de 1999 se ha publicado una nueva versin de SNMP, la versin 3, cuya aplicacin todavia resulta escasa. SNMP es un componente integral y esencial de todos los sistemas TCP/IP, por ello, todos los protocolos por debajo del nivel de aplicacin tienen sus componentes SNMP, por lo que para poder afirmar que se ajustan a los estndares, los fabricantes deben implementar los correspondientes estndares de gestin de red. SNMP se ha extendido para cubrir equipos no TCP/IP y algunos protocolos propietarios, constituyndose en el estndar ms ampliamente utilizado para la recogida de informacin de gestin de red. 13.3.- RECOGIDA DE LA INFORMACIN DE GESTIN En los sistemas anteriores a SNMP, las estadsticas sobre el rendimiento de la red se recogan de un solo analizador conectado en un punto de la red. Esta informacin localizada no representaba una visin my ajustada de la actividad de la red completa a menos que se hicieran estudios en profundidad, por lo dems tcnicamente complejos y que se efectuaban en contadas ocasiones. Uno de los beneficios de la llegada de las redes locales era que todos los nodos estaban conectados al mismo medio fsico y por lo tanto todos podan ser accedidos desde cualquier punto de la red. Recogiendo en cada nodo las estadsticas de rendimiento se consigue distribuir la medicin de la red y por tanto una visin del rendimiento de la red mucho ms ajustada a la realidad. El principal problema aqu es que hay tanta informacin generada que necesita una capacidad de proceso importante as como un software de anlisis sofisticado para analizar los datos y generar las excepciones adecuadas de modo que los gestores puedan identificarlas e interpretarlas correctamente. Con el uso de un protocolo nico para el envo de estadsticas, los fabricantes pueden concentrarse en diferenciar sus productos por la capacidad del anlisis y presentacin de los datos. La gestin de una red TCP/IP se desarrolla en estaciones de gestin de red (NMS) que se comunican con el resto de los elementos de red (NE). Estas estaciones son normalmente estaciones de trabajo que muestran grficamente aspectos relevantes acerca de los elementos que esta monitorizando: lneas en funcionamiento o cadas, volumen de trfico a travs de enlaces, etc y que poseen aplicaciones para el anlisis de los datos que recopilan. La aplicacin que se encarga de la comunicacin con la aplicacin instalada en los elementos de red, el agente de gestin (MA) es el gestor (NMA) que es la implementacin en la estacin del protocolo SNMP.

REDES DE ORDENADORES

SNMP

Los elementos de red pueden ser cualquier dispositivo que utilice alguna parte del conjunto de protocolos TCP/IP : nodos, router terminales X, servidores de terminales, impresoras, etc. El , software que se encuentra en el elemento de red que ejecuta el software de gestin es denominado agente y su funcin es por un lado recoger informacin de los eventos que se producen en el dispositivo y por otro comunicarse con el gestor. La comunicacin puede producirse por dos medios: El gestor puede preguntar al agente acerca del valor de alguna variable. El agente puede informar al gestor acerca de algn hecho importante. El gestor, adems de poder leer el contenido de las variables del agente, puede modificar su valor. La mayora de los sistemas de gestin actuales son muy efectivos en la presentacin de alarmas y la recogida de estadstica, pero no proporcionan suficiente asistencia en el anlisis e interpretacin del significado de estas estadsticas. 13.4.- ARQUITECTURA SNMP La gestin de TCP/IP consta de tres elementos fundamentales : La Base de Informacin de Gestin ( MIB ), que especifica qu objetos o variables deben mantener los elementos de red, en relacin con su configuracin y operatoria (la informacin que puede ser consultada y modificada por el gestor). Existe una segunda versin ( MIB-II ) definida en RFC 1213. Un conjunto de estructuras comunes y un esquema de identificacin utilizado como referencia para las definiciones de los objetos MIB , lo que se conoce como la Estructura de Gestin de Informacion ( SMI ), especificado en RFC 1155. El protocolo utilizado para la comunicacin entre el gestor y el elemento de red, denominado Protocolo de Gestin de Red Simple ( SNMP ) definido en RFC 1157. En 1993 se publicaron nuevos RFC especificando la versin 2 de SNMP. La arquitectura bsica de la gestin TCP/IP es la que se muestra en la figura. SNMP MIB MIB MIB MIB MIB MIB MIB Figura 13.1 Como puede verse, la arquitectura de gestin TCP/IP incluye ms que SNMP. Consta de una Base de Informacin de Gestin ( MIB ) para cada componente de la pila de protocolos adems de SNMP. Los estndares relacionados con la gestin de red son los siguientes: ARP Enlace de Datos Fsico ICMP IP . Aplicacin TCP/UDP

REDES DE ORDENADORES

SNMP

SNMP (Simple Network Management Protocol) es un protocolo estndar Internet, cuyo estatus es recomendado. Su especificacin actual es el RFC 1157 - Simple Network Management Protocol (SNMP). MIB-II protocolo estndar Internet, cuyo estatus es recomendado. Su especificacin actual puede encontrarse en RFC 1213 - Management Information Base for Network Management of TCP/IP-based Internets: MIB-II. CMIP (Common Management Information Protocol) y CMIS (Common Management Information Services) estn definidos en los estndares ISO/IEC 9595 y 9596. CMOT (CMIS/CMIP Over TCP/IP) es una propuesta de protocolo estndar Internet cuya especificacin actual puede encontrarse en RFC 1189 - Common Management Information Services and Protocols for the Internet (CMOT) and (CMIP). OIM-MIB-II es un protocolo estndar Internet cuyo estatus es electivo. Su especificacin actual es el RFC 1214 - OSI Internet Management: Management Information Base. Otros RFCs preparados por el IAB sobre este mismo tema en sucesivas versiones son: RFC 1052 - IAB Recommendations for the Development of Internet Network Management Standards. RFC 1085 - ISO Presentation Services on Top of TCP/IP-based Internets. RFC 1905 - Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2) RFC 1906, Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2) RFC 1907, Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2) RFC 1155 - Structure and Identification of Management Information for TCP/IP-based Internets. RFC 1156 - Management Information Base for Network Management of TCP/IP-based Internets. RFC 1215 - Convention for Defining Traps for Use with the SNMP. RFC 1227 - SNMP MUX Protocol and MIB. RFC 1228 - SNMP-DPI: Simple Network Management Protocol Distributed Programming Interface. RFC 1230 - IEEE 802.4 Token Bus MIB. RFC 1231 - IEEE 802.5 Token-Ring MIB. RFC 1239 - Reassignment of Experimental MIBs to Standard MIBs. RFC 1351 - SNMP Administrative Model. RFC 1352 - SNMP Security Protocols. RFC 2570 - Introduction to Version 3 of the Internet-standard Network Management Framework RFC 2571 - An Architecture for Describing SNMP Management Frameworks RFC 2572 - Message Processing and Dispatching for the Simple Network Management Protocol (SNMP) RFC 2573 - SNMP Applications RFC 2574 - User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3) RFC 2575 - View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP) RFC 2576 - Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework

REDES DE ORDENADORES

SNMP

13.5.- EL PROTOCOLO SNMP El RFC 1157 define la Estacin de Gestin de Red (NMS) como la que ejecuta las aplicaciones de gestin de red (NMA) que monitorizan y controlan los elementos de red (NE) tales como nodos, conmutadores, routers, servidores de terminales, etc. Estos elementos de red utilizan un agente de gestin (MA) para desarrollar las funciones de gestin de red que precisan las estaciones de gesti nde red. SNMP proporciona un mecanismo para acceder a los objetos de MIB mantenidos por el agente de modo que puedan ser consultados y modificados desde la aplicacin de gestin de red, adems de permitir que los elementos de red enven mensajes no solicitados a una estacin de gestin SNMP para indicar que se ha producido una cierta condicin.

Gestor SNMP UDP IP Ethernet

MIB

Agente SNMP UDP IP Figura 13.2 Ethernet

MIB

Agent SNMP UDP IP Ethernet usuario

Figura 13.2 Todas las funciones de los agentes de gestin son slo alteraciones (set) o inspecciones (get) de variables limitando el nmero de funciones de gestin esenciales a dos y evitando protocolos ms complejos. En el otro sentido, desde el NE al NMS, se utiliza un nmero limitado de mensajes no solicitados (traps) para informar de eventos asncronos. Del mismo modo, intentando preservar la simplicidad, el intercambio de informacin preciso slo de un servicio de datagramas no fiable y cada mensaje est completa e independientemente representado por un solo datagrama de transporte. Esto supone que los mecanismos de SNMP son generalmente adecuados para ser utilizados por una gran variedad de servicios de transporte. El RFC 1157 especifica el intercambio de mensajes mediante el protocolo UDP, pero pueden utilizarse una gran variedad de protocolos de transporte. SNMP define cinco tipos de mensajes de intercambio entre gestor y agente, que al igual que en OSI se denominan PDUs ( Unidad de Datos de Protocolo ): Get-request. Utilizado por la estacin de gestin para obtener el valor de una o ms variables MIB del agente SNMP de la estacin remota. Get-next-request. Es similar a la anterior, con la diferencia que se obtiene el valor de una variable sin definir sta explcitamente. De hecho se obtiene el valor de la variable que sigue a la especificada dentro de la ordenacin de la MIB. Response. Es la respuesta del agente a una peticin del gestor devolviendo el valor de una o ms variables. Set-request. Constituye el mecanismo para que el gestor modifique los valores de las variables MIB de la estacin remota . Trap. Cuando se produce un determinado evento o condicin en la estacin remota, el agente enva un trap para notificarlo al gestor. Dado que el mensaje se enva de forma asncrona y en cualquier momento, la estacin de gestin debe monitorizar la red en todo instante. Hay siete tipos de trap definidos en el RFC 1157: coldStart, warmStart, linkDown, linkUp, authenticationFailure, egpNeighborLoss y enterpriseSpecific

REDES DE ORDENADORES

SNMP

Gestor SNMP Get-request Puerto UDP 162 Set-request Puerto UDP 162 Response Trap Puerto UDP 162 Response

Agente SNMP

Puerto UDP 161

Puerto UDP 161 Puerto UDP 161

Figura 13.3 SNMP utiliza el protocolo UDP. El gestor implementa un esquema de temporizacin y retransmisin para contemplar el hecho de la prdida de los mensajes y solventar la falta de fiabilidad de UDP. SNMP hace uso de dos puertos UDP, el 161 y el 162 para la recepcin en el agente y el gestor respectivamente, de esta forma es posible que en una estacin operen simultneamente el software de gestor y agente. 13.5.1.- FORMATO DE LOS MENSAJES SNMP El formato de los mensajes SNMP es el siguiente: Versin (0-1) 20 octetos Comunidad 8 octetos Figura 13.4 El mensaje comienza con el campo Versin, que puede tomar los valores 0 1 para SNMPv1y SNMPv2 respectivamente. El campo Comunidad define un nivel de autenticacin del emisor del mensaje de forma que se puede determinar si tiene permiso de modificacin e incluso de lectura sobre las variables de la MIB. En cada sistema remoto se aplica una poltica de acceso de manera que existan varias perfiles con diferentes privilegios; para ello se crean distintas vistas de la MIB con diferentes modos de acceso sobre los objetos de sta: Slo lectura, Lectura y escritura. La asignacin de un modo de acceso a una determinada vista constituye lo que se conoce como perfil de comunidad, y la poltica de acceso consiste en asignar a cada comunidad definida en el agente un perfil. De este modo, el gestor identificar una comunidad en cada PDU enviada al agente y ste atender la peticin en funcin de que la comunidad disponga de privilegios para realizarla o no. Existen dos tipos de formatos en las PDU SNMP, el primero es general y comn a casi todas ellas, y el segundo corresponde a la PDU trap. PDU ( get-request, ... )

REDES DE ORDENADORES

SNMP

Versin (0-1) Comunidad Tipo PDU Identificacin de Peticin Estado de error Indice de error Nombre Valor Nombre Valor ... Get-request Get-next-request Set-request Response

Versin (0-1) Comunidad Tipo PDU Enterprise Direccin del agente Tipo de Trap Cdigo especfico Timestamp Nombre Valor ... Trap

Figura 13.5

13.5.2.- PDU GET-REQUEST, GET-NEXT-REQUEST, SET-REQUEST Todas ellas son generadas por una estacin de gestin de red y son dirigidas a un agente de red y comparten un formato comn. El significado de los campos que componen la PDU tal y como aparece en la figura 16.5 es el siguiente. Tipo PDU especifica el tipo de mensaje, de acuerdo con los siguientes valores: Tipo PDU 0 1 2 3 4 Nombre Get-request Get-next-request Set-request Response Trap Tabla 13.1

La Identificacin de la peticin se utiliza para relacionar peticiones y respuestas. La entidad emisora asigna nmeros de manera que cada consulta pendiente al mismo agente es identificada de manera inequvoca de modo que la aplicacin SNMP puede correlacionar las respuestas emitidas con las peticiones pendientes y hacer frente a PDU duplicadas por un servicio de transporte inseguro.

REDES DE ORDENADORES

SNMP

El estado de error se emplea para indicar que ha ocurrido una anomala mientras se procesaba una consulta. Los valores posibles son: Estado de error 0 1 2 3 4 5 Nombre NoError tooBig noSuchName badValue readOnly genErr Significado Sin error La PDU es demasiado grande No existe tal nombre, la variable no existe. Valor incorrecto, no se ajusta a la definicin de la variable. Slo lectura, la variable no puede ser modificada. Error general ( ninguno de los anteriores ). Tabla 13.2 Indice de error. Cuando el estado de error es distinto de 0, el ndice de error puede suponer informacin adicional, ya que es un desplazamiento entero que especifica qu variable contiene el error. El agente la utiliza slo para los errores noSuchname , badValue y Readonly . Nexos de variables. Es una lista de nombres de variables y sus valores correspondientes. El campo valor existe tanto en las preguntas como en las respuestas, si bien en las primeras su contenido es nulo. El agente SNMP que recibe una Get-Request devuelve una PDU Response, completando los nexos de variables con los valores que toman stas en la MIB de la estacin remota. La operacin GetRequest slo devuelve valores cuando todas las variables estn disponibles y no se produce error en ninguna de ellas. Si el agente puede asignar valores a todas las variables que aparecen en la lista nexos de variables de la PDU Get-Request, la PDU Get-Response incluye en la lista nexos de variables los valores resultantes para cada variable, pero si falta al menos uno de estos valores, la lista se devolver vaca. Los errores que pueden producirse son los siguientes: Un objeto que aparezca en la lista nexos de variables no corresponde a ningn identificador de objeto de la vista del MIB, y por lo tanto, no tiene un valor asociado. El estado de error de la PDU Response ser NoSuchName acompaador del ndice del objeto problema. Si el agente puede asignar un valor a cada variable en la lista, pero el tamao de la PDU resultante excede del tamao mximo por alguna limitacin local, el estado de error de la PDU Response ser TooBig. Si el agente no puede asignar valores al menos a uno de los objetos por cualquier otra razn devuelve la PDU Response con estado de error GenErr y el ndice del objeto problema. La PDU Get-Next-Request es casi idntica a la PDU Get-Request, con la nica diferencia que en la primera, el agente debe devolver para cada variable en la lista nexo de variables el valor del objeto siguiente en orden lexicogrfico en la MIB de la estacin remota. Esta diferencia tiene enormes implicaciones, ya que permite a un gestor descubrir dinmicamente la estructura de la vista de la MIB, adems de proporcionar un eficaz instrumento de bsqueda en tablas cuyas entradas sean desconocidas. Las situaciones de error son similares a las que se producen en la PDU Get-Request. La PDU Set-Request se genera de igual manera y siguiendo el mismo modelo de actuacin que en la generacin de Get-Request, con la diferencia de que Set-Request se utiliza para escribir un valor de objeto en lugar de leerlo. Por tanto, el gestor incluye en la lista nexo de variables el identificador de objeto y el valor a asignarle. La operacin SetRequest es atmica : o bien se actualizan todas las variables o ninguna. Las condiciones de error son las mismas que en el caso de Get-Request.

REDES DE ORDENADORES

SNMP

SNMP no presenta un mecanismo especfico de generacin de un comando a un agente para la realizacin de una accin. Las nicas capacidades de SNMP se reducen a leer y escribir valores de objetos dentro de una MIB. Sin embargo, es posible utilizar algunas de las propiedades de set para generar un mandato. Un objeto puede ser utilizado para representar un mandato, de manera que se realice una accin concreta si el objeto es asociado a un valor especfico. 13.5.3.- PDU Trap Los agentes utilizan esta PDU para notificar a los gestores de manera asncrona determinados hechos ms o menos relevantes en el funcionamiento de la red. Su formato es considerablemente distinto del que tienen el resto de PDUs de SNMP. Los campos que figuran en su PDU son los siguientes: Enterprise. Identifica al software agente que gener la PDU trap, generalmente a travs del nombre del mismo, fabricante y versin. Direccin del agente. Indica la direccin IP de la estacin remota cuyo agente envi la PDU trap. Tipo de Trap. Permite diferenciar entre traps, e identificar el evento que origin el envo del mensaje. El esquema de codificacin es el siguiente:

Tipo de Trap 0

Nombre Cold start

Significado El agente SNMP remitente se ha reinicializado automticamente debido a que la configuracin del agente ha sido alterada. Generalmente se debe a un rearranque debido a un crash . La entidad SNMP remitente se reinicializa automticamente aunque la configuracin del agente no haya sido alterada. Es la tpica rutina de reinicio. Seala el fallo de una de las conexiones del agente. El primer elemento de la lista nexos de variables es el nombre y valor de ifIndex del interfaz referido. Seala la aparicin de una nueva conexin en el agente. El primer elemento de la lista nexos de variables es el nombre y valor de ifIndex del interfaz referido. Implica que la entidad remitente ha recibido un mensaje que no ha pasado la autentificacin. Indica que un vecino EGP ha dejado de contestar y la relacin entre ambos se ha frustrado. El agente reconoce la existencia de un evento especfico del dispositivo. El campo cdigo especfico indica el evento concreto. Tabla 13.3

Warm start

Link down

Link up

4 5 6

Autentication failure EGP neighbourloss Enterprise specific

El campo Cdigo especfico permite diferenciar identificar eventos diferentes de los anteriores. Se utiliza en combinacin con el campo anterior, cuyo valor debe ser 6, y con el campo enterprise, del cual depende para su interpretacin. Es un medio para que los fabricantes enriquezcan sus productos de red permitiendo detectar otras situaciones diferentes de las especificadas en el estndar. Timestamp. Contiene el tiempo medido en segundos que ha pasado entre la ltima reinicializacin del sistema remoto y la generacin del trap.

REDES DE ORDENADORES

SNMP

Nexos de variables. Contiene Informacin adicional relativa al evento. En cada caso se incluyen diferentes variables MIB de la estacin remota con sus valores para ilustrar el estado de la misma en el momento en que se produjo el evento.

13.6.- SNMPv2
El marco general de la versin 2 del Simple Network Management Protocol (SNMPv2) fue publicado en Abril de 1993 y consta de 12 RFCs incluyendo el primero, RFC 1441, que es una introduccin. Ebn agosto de 1993 los 12 RFCs se convirtieron en un estndar propuesto con el estatus de electivo. El marco consta de las siguientes disciplinas: Structure of Management Information (SMI) Definicin del subconjunto de OSI ASN.1 para crear mdulos MIB, descrito en RFC 1442. Textual Conventions Definicin del conjunto inicial de convenciones textuales disponibles para todos los mdulos MIB. Est descrito en RFC 1443. Protocol Operationes Definicin de las operaciones del protocolo con respecto al envo y recepcin de PDUs. Descrito en RFC 1448. Transport mappings Definicin de los asignaciones de SNMPv2 sobre un conjunto inicial de dominios de transporte porque puede ser utilizados sobre una gran variedad de familias de protocolos. Las asignaciones sobre UDP son las preferidas, pero el RFC tambin las define sobre OSI, AppleTalk, IPX etc. Descrito en RFC 1449. Protocol intrumentation Definicin del MIB y Manager-to-Manager MIB para SNMPv2. Descrito en los RFCs 1450 y 1451. Administrative Framework Definicin del SNMPv2 Party, Protocolos de Seguridad y el MIB Party. Descrito en los RFCs 1445, 1446 y 1447. Conformance statements Definicin de la notacin de cumplimiento o capacidad de los agentes. Descrito en RFC 1444. A continuacin describimos las diferencias principales entre las versiones 1 y 2 de SNMPv.

13.6.1.- Entidad SNMPv2

Una entidad SNMPv2 es un proceso real que desarrolla operaciones de gestin de red generando y/o respondiendo a mensajes de protocolo SNMPv2 utilizando las operaciones del protocolo SNMPv2. Las posibles operaciones de una entidad pueden restringirse a un subconjunto de todas las operaciones posibles que pertenecen a un Party particular administrativamente definido. Una entidad SNMPv2 puede ser miembre de varios Parties SNMPv2. Una entidad SNMPv2 mantiene las siguientes Bases de Datos locales: Una Base de Datos para todos los Parties conocidos por la entidad SNMPv2 que podran ser: Operaciones realizadas localmente Operaciones realizadas por interacciones proxy con Parties o dispositivos remotos. Operaciones realizadas por otras entidades SNMPv2 Otra Base de Datos que representa todos los recursos gestionados que son conocidos por la entidad SNMPv2. Y al menos una Base de Datos que representa una poltica de control de acceso que define el los privilegios de acceso de acuerdo a los parties SNMPv2 conocidos. Una entidad SNMPv2 puede actuar como un agente o un gestor SNMPv2.

10

REDES DE ORDENADORES

SNMP

13.6.2.- Party SNMPv2

Un party SNMPv2 es un entorno de ejecucin virtual cuya operacin est restringida, por seguridad, u otros propsitos a un subconjunto administrativamente definido de todas las operaciones posibles de una entidad particular SNMPv2. Arquitectnicamente, cada SNMPv2 party consta de : Una identidad de party nica Una ubicacin de red lgica en la que se ejecuta el party, caracterizada por un dominio de protocolo de transporte e informacin de direccionamiento de transporte. Un protocolo de autenticacin simple y los parmetros asociados por los cuales todos los mensajes originados por el party son autenticados como un origen e integridad. Un protocolo de privacidad nico y sus parmetros asociados por los que todos los mensajes recibidos por el party estn protegidos.

13.6.3.- GetBulkRequest
El comando GetBulkRequest se define en el RFC 1448 y por lo tanto forma parte de las operaciones del protocolo. Se genera y transmite un GetBulkRequest como una peticin de la aplicacin SNMPv2. El propsito del GetBulkRequest es pedir la transferencia de una cantidad de datos potencialmente grande, indlcuyendo, pero no limitndose a ello la recuperacin eficiente y rpida de tablas de grandes dimensiones. El comando GetBulkRequest resulta ms eficiente que el GetNextRequest en el caso de recuperacin de la MIB de objetos tablas de gran dimensin. La sintaxis del comando GetBulkRequest es: GetBulkRequest [ non-repeaters = N, max-repetitions = M ] ( RequestedObjectName1, RequestedObjectName2, RequestedObjectName3 )

RequestedObjectName1, 2, 3 Identificador de objeto MIB tal como sysUpTime etc. Los objetos estn ordenados lexicogrficamente. Cada identificador de objeto tiene un enlace con al menos una variable. Por ejemplo, el identificador de objeto ipNetToMediaPhysAddress tiene una variable asociada para direccin IP en la tabla ARP y el contenido es la direccin MAC asociada. N Especifica valores no repetitivos, que significa que slo se pide los contenidos de la variable que sigue al objeto especificado en la peticin, de los primeros N objetos especificados entre los parntesis. Esta funcin es la misma proporcionada por el comando GetNextRequest. M Especifica el valor max-repetitions, que significa que se solicita de los objetos restantes (nmero de objetos solicitados N) los contenidos de las M variables que siguen al objeto especificado en la peticin. Es similar a un comando iterativo GetNextRequest pero transmitido en una sola peticin. Con el comando GetBulkRequest se puede recuperar de manera eficiente el contenido de la siguiente variable o de los siguientes M variables en una sola peticin. Supongamos la siguiente tabla ARP en un nodo que ejecuta un agente SNMPv2: Interface-Number 1 1 2 Network-Address 10.0.0.51 9.2.3.4 10.0.0.15 Physical-Address 00:00:10:01:23:45 00:00:10:54:32:10 00:00:10:98:76:54 Type static dynamic dynamic

REDES DE ORDENADORES

11

SNMP

Un gestor SNMPv2 enva la siguiente peticin para recuperar la variable sysUpTime y la tabla ARP completa : GetBulkRequest [ non-repeaters = 1, max-repetitions = 2 ] ( sysUpTime, ipNetToMediaPhysAddress, ipNetToMediaType ) La entidad SNMPv2 que actua en el papel de agente responde con una PDU Response: Response (( sysUpTime.0 = "123456" ), ( ipNetToMediaPhysAddress.1.9.2.3.4 = "000010543210" ), ( ipNetToMediaType.1.9.2.3.4 = "dynamic" ), ( ipNetToMediaPhysAddress.1.10.0.0.51 = "000010012345" ), ( ipNetToMediaType.1.10.0.0.51 = "static" )) La entidad SNMPv2 que acta en el papel de gestor continua con: GetBulkRequest [ non-repeaters = 1, max-repetitions = 2 ] ( sysUpTime, ipNetToMediaPhysAddress.1.10.0.0.51, ipNetToMediaType.1.10.0.0.51 ) La entidad SNMPv2 que actua en el papel de agente responde con: Response (( sysUpTime.0 = "123466" ), ( ipNetToMediaPhysAddress.2.10.0.0.15 = "000010987654" ), ( ipNetToMediaType.2.10.0.0.15 = "dynamic" ), ( ipNetToMediaNetAddress.1.9.2.3.4 = "9.2.3.4" ), ( ipRoutingDiscards.0 = "2" )) Esta respuesta seala el fin de la tabla a la entidad gestora SNMPv2. Con comando GetNextRequest habran sido necesarias cuatro peticiones para recuperar la misma informacin. Si se ha fijado el valor max-repetition del comando GetBulkRequest a 3, en este ejemplo, habra sido necesaria una sola peticin.

13.6.4.- InformRequest
Se genera un InformRequest como peticin de una aplicacin en una entidad gestora SNMPv2 que desea notificar a otra aplicacin que acta tambin como entidad gestora SNMPv2, informacin en la vista MIB de un party local a la aplicacin emisora. El paquete se utiliza como una indicacin al gestor del otro party de la informacin accesible en el party emisor ( comunicacin gestor-a-gestor a travs de lmites de party). Las primeras dos variables en la lista de asignacin de variables de un InformRequest son sysUpTime.0 y snmpEventID.i respectivamente, pudiendo seguir otras variables.

13.6.5.- Autenticacin y Protocolo de privacidad

El protocolo de autenticacin proporciona un mecanismo por el cual las comunicaciones de gestin SNMPv2, transmitidas por un party, pueden ser identificadas de manera fiable como originadas por dicho party. El protocolo de privacidad proporciona un mecanismo por el cual las comunicaciones de gestin SNMPv2, transmitidas a un party son protegidas frente a consultas no deseadas.

12

REDES DE ORDENADORES

SNMP

Las principales amenazas contempladas por el protocolo de seguridad SNMPv2 son: Modificacin de la informacin Enmascaramiento Modificacin de los mensajes Lecturas no deseadas

Los siguientes servicios de seguridad proporcionan proteccin frente a las amenazas anteriores: Integridad de datos Proporcionados por el algoritmo de cifrado MD5. Se cacula un cdigo de 128 bits a partir de la porcin designada de un mensaje SNMPv2 y se incluye como parte del mensaje enviado. Autenticacin del origen de los datos Proporcionado aadiendo un prefijo a cada mensaje con un valor secreto compartido por el origen del mensaje y el destinatario del mismo antes del cifrado. Retraso de los mensajes o repeticin de los mismos Proporcionado aadiendo un valor de timestamp en cada mensaje. Confidencialidad de los datos Proporcionado por un protocolo de privacidad simtrico que encripa una porcin del mensaje de acuerdo a una clave secreta conocida slo por el emisor y el receptor del mensaje. Este protocolo se utiliza junto con el algoritmo de encriptacin simtrica que es parte del Data Encryption Standard (DES). La porcin del mensaje SNMPv2 desingada es encriptada e incluida como parte del mensaje enviado.

13.6.6.- El nuevo modelo administrativo

El propsito del nuevo Modelo Administrativo de SNMPv2, es definir el modo de aplicar el marco administrativo para conseguir una gestin eficiente de la red en configuraciones y entornos variados. El modelo propone el uso de distintas identidades para parejas que intercambian mensajes SNMPv2, abandonando el concepto comunidad de SNMPv1. Al indentificar unvocamente el emisor y el destinatario de cada mensaje SNMPv2, esta nueva estrategia mejora el esquema de comunidad anterior soportando un modelo de control de acceso ms conveniente para un uso efectivo de protocolos de seguridad asimtricos ( clave pblica ) en el futuro.

13.6.7.- El nuevo formatode trama

Figure 13.6 Formato del mensaje SNMPv2

REDES DE ORDENADORES

13

SNMP

PDU

Incluye una de las siguientes PDUs:

GetRequest GetNextRequest Response SetRequest InformRequest SNMPv2-Trap

La GetBulkRequest tiene un formato de PDU diferente, ya mencionado anteriormente. El mensaje SNMP-Trap tiene ahora el mismo formato que el resto de las peticiones. SnmpMgmtCom (SNMP Management Communication) Aade el identificador del party emisor (srcParty), el identificador de party destinatario (dstParty) y el contexto a la PDU. Contexto especifica el contexto SNMPv2 que contiene la informacin de gestn referenciada por la comunicacin. SnmpAuthMsg Este campo se utiliza como informacin de autenticacin del protocolo utilizado por dicho party. El SnmpAuthMsg es codificado mediante ASN.1 BER y puede ser encriptado a continuacin. SnmpPrivMsg SNMP Private Message Un Mensaje Privado SNMPv2 es una comunicacin de gestin SNMPv2 autenticada que es protegida frente a accesos no deseados. Se aade un destino privado para idetntificar el party de destino (privDst). El mensaje despus se encapsula en un datagrama UDP/IP y se enva al destinatario. 13.7.- ESTRUCTURA DE LA INFORMACION DE GESTIN: SMI La SMI ( Structure of Management Information ), tal y como est indicado en el RFC 1155, define la estructura bajo la cual podr ser definido y construido una MIB. Seala aspectos tales como el tipo de datos que podr albergar la MIB, cmo pueden representarse y denominarse los recursos en la MIB,..., es decir las reglas por las cuales son descritos los objetos gestionados y cmo los protocolos pueden acceder a los mismos. SMI slo permite la utilizacin de tipos de datos simples en la construccin de MIB: escalares y arrays bidimensionales de escalares, y no permite la creacin o recuperacin de estructuras complejas de datos. SMI proporciona tcnicas para: Definir la estructura de una MIB particular. Definir los objetos individuales, la sintaxis y valor de cada objeto. Codificar el valor de los objetos. Los objetos MIB, as como toda la estructura del MIB, estn definidos utilizando ASN.1 (Abstract Syntax Notation 1, ISO standard 8824), un lenguaje de especificacin formal. La definicin del tipo de objeto se realiza en una plantilla que consta de cinco campos: Object: Un nombre textual, denominado object descriptor, para el tipo de objeto junto con su correspondiente object identifier definido a continuacin. Syntax: La sintaxis abstracta de ASN.1 del tipo objeto. Definition: Una descripcin textual de la semntica del tipo objeto. Las implementaciones de los distintos fabricantes deben garantizar que se cumple esta definicin.

14

REDES DE ORDENADORES

SNMP

Access: Restricciones de acceso al objeto ( lectura, lectura/escritura, escritura, sin acceso ). Status: Indica si el objeto es obligatorio para todo nodo, opcional o bien si est obsoleto y se mantiene a efectos de mantener la compatibilidad. Los tipos de datos universales definidos por SMI son un subconjunto de los tipos de ASN.1 : Integer. Algunas variables son declaradas como enteros sin restricciones, otras son definidas para tomar valores especficos y otras con valores mximos y mnimos. Octect string. Es una cadena de 0 o ms bytes. Cada byte puede tener un valor entre 0 y 255. Por delante de la cadena se incluye el nmero de bytes que la componen. Object identifier. Es un identificador de cada uno de los objetos definidos en la MIB. Null. Indica que la variable correspondiente no tiene ningn valor. Sequence. Es una estructura, similar a la del lenguaje C. Sequence of. Es la definicin de un vector donde todos los elementos tienen el mismo tipo de datos. Adems de estos existen otros tipos de datos, de aplicacin, susceptibles de ser utilizados, pero que son representables mediante los tipos universales. No son por lo tanto ms que restricciones sobre los tipos anteriores. Algunos de los ms comunes son los siguientes: Ipaddress. Es un octect string de longitud 4 con 1 byte para cada uno de los bytes de la direccin IP. Physaddress. Es un octect string que especifica la direccin fsica. Counter. Es un entero positivo cuyo valor aumenta monotonamente de 0 a 232 1, y vuelve a empezar de 0, una vez superado el mximo. Gauge. Es un entero positivo entre 0 y 232 -1, cuyo valor aumenta o disminuye pero permanece en su valor mximo una vez alcanzado ste, sin empezar de nuevo. Opaque. Es tipo de datos cuyo contenido no est definido, de modo que puede servir para enviar informacin sin ninguna restriccin en forma de OCTET-STRING. El receptor debe saber interpretar los datos. Timeticks. Contador de tiempo en centsimas de segundo a partir de un determinado instante. Cada variable puede especificar este contador a partir de una poca distinta de modo que la poca utilizada para cada variable de este tipo se especifica cuando se declara la variable en el MIB. A modo de ejemplo:

13.7.1.- IDENTIFICADORES DE OBJETO Un objeto gestionado no slo debe ser descrito sino tambin identificado unvocamente. Esto se lleva a cabo mediante el tipo ASN.1 Object Identifier. Las normas para la asignacin de identificadores de objeto son las siguientes: Cada identificador es nico, y su valor consiste en una secuencia de enteros. el grupo de objetos definidos formar una estructura en rbol. los objetos particulares estarn en las hojas de las ramas del rbol. Un identificador de objeto es una secuencia de enteros separados por puntos decimales. Estos enteros tienen una estructura arborescente, similar a la de DNS.

REDES DE ORDENADORES

15

SNMP

root Itu-t(0) iso(1) org(3) dod(6) Internet (1) Joint-iso-itu-t (2)

1.3.6.1

directory (1)

mgmt (2)

Experimental (3)

private(4) enterprise (1)

mib(1) system(1) interfaces(2) at(3) ip(4) icmp(5) tcp(6) udp(7)

Figura 13.7 Comenzando a partir de la raz del rbol de identificadores de objetos, cada valor del componente identificador de objeto identifica una rama del rbol. A partir de la raz hay tres nodos en el primer nivel: iso, itu-t, y joint-iso-itu-t. Bajo el nodo iso, se usa un subrbol para otras organizaciones, una de las cuales es el DOD. El RFC 1155 especifica que un subrbol bajo DOD se asignar para su administracin por el IAB como sigue: internet OBJECT IDENTIFIER :: = { iso org(3) dod(6) } As, el nodo Internet tiene el valor de identificador 1.3.6.1, que sirve como prefijo para los nodos por debajo de l. El nmero 1.3.6.1. se obtiene uniendo los nmeros de grupos con el siguiente significado: El primer grupo define el nodo administrador: (1) para ISO (2) para ITU-T (3) para la unin ISO-ITU-T. El segundo grupo del administrador ISO define (3) para su uso por otras organizaciones. El tecer grupo define (6) para su uso por el U.S. Department of Defense (DoD). El el cuarto grupo el DoD no ha indicado cmo gestionar su grupo de modo que la comunidad internet asume (1) para ella. El quinto grupo fue aprobado por la IAB para ser : (1) para uso del directorio OSI en Internet. (2) para identificar objetos con el fin de gestionarlos. (3) para identificar objetos con propositos experimentales. (4) para identificar objetos de uso privado. En el ejemplo, el identificador {system 1} que sigue al nombre del objeto significa que le identificador de objeto es 1.3.6.1.2.1.1.1. Es el primer objeto del primer grupo (system) en la Management Information Base (MIB).

16

REDES DE ORDENADORES

SNMP

13.7.2.- CODIFICACION DE LA INFORMACIN Cuando se pasa informacin entre diferentes arquitecturas, los sistemas debe acordar la representacin de la informacin. Los sistemas de gestin deben acordar el significado de la informacin de gestin antes de intercambiarla para evitar errores en la interpretacin de la misma. SNMP se basa en dos estndares OSI para la representacin de la informacin: ASN.1 ( Abstract Syntax Notation ) y BER ( Basic Encodign Rules ). ASN.1 es un lenguaje de especificacin formal que puede ser compilado en una secuencia de octetos haciendo uso de BER. SNMP slo utiliza un subconjunto de ASN.1, los tipos integer, octect string, object identifier, sequence y null; si se utilizan otros tipos deben poder ser resueltos en estos tipos primitivos. BER trata con el mismo problema que XDR, pero a diferencia de este es un sistema explcito y no ambiguo, es decir, cada valor est clara y explcitamente definido. Esto hace muy sencillo para cualquier analizador de red descifrar cualquier informacin de la red codificada en BER. Para hacer esto con XDR sera preciso conocer de antemano la estructura de la informacin utilizada por la aplicacin que gener el mensaje. En ambos casos es necesario entender el contexto de la informacin para entender su significado completamente, pero as como XDR asume que el dispositivo que recoge la informacin entiende lo que espera, BER incluye una etiqueta con la informacin indicando exactamente lo que es. Todos los datos son codificados son precedidos por un campo tipo y longitud. El campo tipo indica la construccin de los datos transportados y el campo longitud su tamao, lo que permite al receptor descifrar diferentes tipos de informacin. bits 8 c 8 0 0 1 1 7 0 1 0 1 7 c 6 f Tag class Universal Application wide Context specific Private use Figura 13.8 Para proporcionar mayor flexibilidad para otras estructuras que puedan necesitarse en el futuro, el campo tipo tiene tres subdivisiones, tal y como se ve en la figura; los bits 8 y 7 son denominados Tag class ( cc ), el bit 6 el Form ( f ) y los bits 5 al 1 el tag number. El campo longitud tiente generalmente un octeto, pero puede utilizar ms bits para describir estructuras ms largas; para ello se utiliza el bit 8 del campo de longitud, que cuando se pone a 1 denota que la longitud, medida en octetos viene representada en los restantes 7 bis de dicho campo. 13.8.- BASE DE INFORMACION DE GESTIN ( MIB ) La Base de Informacin de Gestin o MIB es una definicin de los objetos que deberan ser proporcionados en cada nodo gestionado por el agente SNMP, para ello identifica los elementos de red, objetos gestionados y define nombres no ambiguos asociados con cada objeto. Los objetos gestionados estn organizados en grupos, cada uno de los cuales se relaciona con uno de los protocolos o niveles TCP/IP o con el sistema en s. Muchos de los objetos son contadores de eventos y por lo tanto acumulan el nmero de veces que se ha producido dicho evento desde la ltima vez que se inicializ el contador. No todos los grupos de variables definidas son obligatorios para todos los componentes, lo que s es obligatorio es soportar todas las variables que un grupo tiene si se soporta algn elemento del grupo. 5 t 6 0 1 4 t 3 t Form Primitive Constructed 2 t 1 t 54321 Tag number

REDES DE ORDENADORES

17

SNMP

Estas definiciones comunes de las variables de cada tipo de nodo de la red hace que el acceso a la informacin de los nodos de la red sea simple e independiente del fabricante, si bien algunos de estos han efectuado extensiones a MIB ampliando sus definiciones. Se han definido MIB para todos los componentes de una red, repetidores, bridges , routers y nodos. La descripcin que vamos a efectuar corresponde a la versin 2, MIB-II descrita en RFC 1213, ya que la MIB-I descrita en el RFC 1156 est clasificada como histrica y no recomendada. La MIB est dividida en varios grupos de informacin, cada uno de los cuales tiene un nmero variable de objetos definidos que describen parmetros relevantes dentro de ellos. Grupo System Interfaces at ip icmp tcp udp egp transmiss. snmp Objetos Informacin bsica del sistema Uniones a redes Traduccin de direcciones Protocolo internet Estadsticas del protocolo ICMP Protocolo TCP Protocolo UDP Protocolo EGP Transmisin, especfico de cada medio Entidades aplicacin SNMP Tabla 13.4 Cada nodo gestionado soporta slo aquellos grupos que son apropiados. Por ejemplo, si no hay un router exterior, el grupo EGP no es preciso que sea soportado. Sin embargo cuando se contempla un grupo, todos los objetos del mismo deben ser soportados. La lista de objetos gestionaos se ha derivado de aquellos elementos considerados esenciales. Este enfoque de tomar slo los objetos esenciales no es restrictivo, dado que SMI proporciona mecanismos de extensibilidad como la definicin de una nuevo versin de la MIB y la definicin de objetos privados o no estndares. A continuacin se mencionan algunos ejemplos de objetos de cada grupo. La lista completa est definida en el 1213. System Group sysDescr - Full description of the system (version, HW, OS) sysObjectID - Vendor's object identification sysUpTime - Time since last re-initialization sysContact - Name of contact person sysServices - Services offered by device Interfaces Group ifIndex - Interface number ifDescr - Interface description ifType - Interface type ifMtu - Size of the largest IP datagram ifAdminisStatus - Status of the interface ifLastChange - Time the interface entered in the current status ifINErrors - Number of inbound packets that contained errors ifOutDiscards - Number of outbound packets discarded Address Translation Group atTable - Table of address translation atEntry - Each entry containing one network address to physical address equivalence atPhysAddress - The media-dependent physical address atNetAddress - The network address corresponding to the media-dependent physical address Num 7 23 3 38 26 19 7 18 0 30

18

REDES DE ORDENADORES

SNMP

IP Group ipForwarding - Indication of whether this entity is an IP gateway ipInHdrErrors - Number of input datagrams discarded due to errors in their IP headers ipInAddrErrors - Number of input datagrams discarded due to errors in their IP address ipInUnknownProtos - Number of input datagrams discarded due to unknown or unsupported protocol ipReasmOKs - Number of IP datagrams successfully re-assembled ipRouteMask - Subnet-mask for route ICMP Group icmpInMsgs - Number of ICMP messages received icmpInDestUnreachs - Number of ICMP destination-unreachable messages received icmpInTimeExcds - Number of ICMP time-exceeded messages received icmpInSrcQuenchs - Number of ICMP source-quench messages received icmpOutErrors - Number of ICMP messages not sent due to problems within ICMP TCP Group tcpRtoAlgorithm - Algorithm to determine the timeout for retransmitting unacknowledged octets tcpMaxConn - Limit on the number of TCP connections the entity can support tcpActiveOpens - Number of times TCP connections have made a direct transition to the SYN-SENT state from the CLOSED state tcpInSegs - Number of segments received, including those received in error tcpConnRemAddress - The remote IP address for this TCP connection tcpInErrs - Number of segments discarded due to format error tcpOutRsts - Number of resets generated UDP Group udpInDatagrams - Number of UDP datagrams delivered to UDP users udpNoPorts - Number of received UDP datagrams for which there was no application at the destination port udpInErrors - Number of received UDP datagrams that could not be delivered for reasons other than the lack of an application at the destination port udpOutDatagrams - Number of UDP datagrams sent from this entity EGP Group egpInMsgs - Number of EGP messages received without error egpInErrors - Number of EGP messages with errors egpOutMsgs - Number of locally generated EGP messages egpNeighAddr - The IP address of this entry's EGP neighbor egpNeighState - The EGP state of the local system with respect to this entry's EGP neighbor Esta no es la definicin completa de la MIB pero sirve para ilustrar significativamente un ejemplo de los objetos definidos en cada grupo. Para aclarar estos coceptos, en la figura siguiente se muetra cmo el grupo Interfaces contiene dos objetos de mximo nivel: el nmero de interfaces del nodo (ifNumber) y una tabla conteniendo informacin sobre los mismos (ifTable). Cada entrada (ifEntry) de la tabla contiene los objetos de un interfaz particular. Entre estos, el tipo interfaz (ifType) se identifica en el rbol MIB utilizando lanotacin ASN.1 1.3.6.1.2.1.2.2.1.3. y para el adaptador token-ring el valor de la correspondiente variable sera 9, que significa "iso88025-tokenRing"

REDES DE ORDENADORES

19

SNMP

Figura 13.9

13.8.1.- IDENTIFICACION DE UNA INSTANCIA Cuando se desea consultar o modificar el valor de un objeto MIB es necesario identificarlo. SNMP slo puede hacer referencia a los nodos finales, y no las ramas del rbol; adems, SNMP no manipula filas o columnas enteras de una tabla. Variables simples Se hace referencia a las variables simples aadiendo al identificador de objeto de la variable ( .o p.e. ifNumber.0, o ms exactamente 1.3.6.1.2.1.2.1.0 ) Tablas La identificacin de instancia de las entradas de una tabla es ms complicada, puesto que slo se puede hacer referencia a los nodos finales del rbol y no a estructuras ms complejas. Cada tabla MIB lleva asociado un ndice formado por una o ms columnas, y es a travs de este ndice como se identifica una instancia concreta. A modo de ejemplo consideremos los siguientes valores para la tabla udplistenertable: IfIndex 1 2 3 ifDescr Eth0 Ser0 Ser1 Tabla 13.5 ifType Ethernet Serial Serial IfMtu 1500 1500 256

20

REDES DE ORDENADORES

SNMP

El ndice de la tabla es la primera columna, aunque en otros casos pueda ser la combinacin de varias de ellas. Por lo tanto, el identificador del valor 256 sera: ifEntry.3 (1.3.6.1.2.1.2.2.1.3). Todos los objetos MIB estn ordenados lexicogrficamente de acuerdo con sus identificadores. Esto hace que las entradas de las tablas MIB estn ordenadas en primer lugar por columnas y en segundo lugar por filas. Hay una ordenacin implcita en MIB basada en el orden de los identificadores de objetos. De acuerdo con esto, todas las instancias de un objeto aparecen antes que las del siguiente objeto, y por ello las tablas aparecen ordenadas en primer lugar por columnas. La ordenacin de las filas depende de los valores de los ndices de las tablas. La ordenacin de los objetos MIB es especialmente importante cuando se hace uso de la PDU SNMP Get-next-request. Dado que esta peticin se refiere al valor de la variable que sigue a la especificada en la peticin, el valor que se obtendr estar directamente relacionado con la ordenacin de los objetos MIB. A modo de ejemplo una peticin Get-next-request udp sera equivalente a Get-request udpindatagrams. La PDU Get-next-request se utiliza especialmente para averiguar los valores contenidos en las tablas MIB, recuperndose los valores en este caso en primer lugar por columnas y dentro de stas por filas, es decir, se obtendran todas las instancias de la primera columna ordenadas segn los valores de los ndices, a continuacin las de la segunda columna y as sucesivamente. 13.8.2.- MIB para SNMPv2 Esta MIB define los objetos gestionados que describen el comportamiento de la entidad SNMPv2, si bien es importante tener en cuenta que no sustituye a la MIB-II. A continuacin se incluyen algunos ejemplos de definiciones de objetos para hacerse una idea de los contenidos: snmpORLastChange OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the time of the most recent change in state or value of any instance of snmpORID." warmStart NOTIFICATION-TYPE STATUS current DESCRIPTION "A warmStart trap signifies that the SNMPv2 entity, acting in an agent role, is reinitializing itself such that its configuration is unaltered." 13.8.3.- MIB para Party La MIB party define los objetos gestionados que corresponden a las propiedades asociadas con un party SNMPv2. Un ejemplo de algunos objetos MIB: partyIdentity OBJECT-TYPE SYNTAX Party MAX-ACCESS not-accessible STATUS current DESCRIPTION "A party identifier uniquely identifying a particular SNMPv2 party."

REDES DE ORDENADORES

21

SNMP

partyAuthProtocol OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-create STATUS current DESCRIPTION "The authentication protocol by which all messages generated by the party are authenticated as to origin and integrity. The value noAuth signifies that messages generated by the party are not authenticated. Once an instance of this object is created, its value can not be changed." 13.8.4.- MIB Gestor a Gestor El propsito de esta MIB es proporcionar los medios para coordinar entre mltiples estaciones de gestin. Es decir, los medios por el que pueden distribuirse las funciones de monitorizacin y contorl de la red entre varias estaciones de gestin en una red extensa. Especificamente, esta MIB proporciona el medio para que una estacin de gestin solicite servicios de gestin a otra estacin de gestin. Adems, una entidad SNMPv2 puede actuar con un papel doble; cuando se proporciona informacin de gestin a otro gestor la entdidad acta como agente, y cuando se solicita informacin, acta como gestor. La MIB gestor-a-gestor consta de las siguientes tres tablas: Alarmas Eventos Notificaciones Cada alarma es una condicin especfica detectada en la monitorizacin peridica, a intervalos configurados, del valor de determinadas variables de informacin de gestin. Un ejemplo de una condicin de alarma es, por ejemplo, que una variable monitorizada queda fuera de un rango configurado. Cada condicin de alarma dispara un eventa y cada envento puede originar una o ms notificaciones a otras estaciones de gestin utilizando la trama InformRequest.

13.9. GESTION DE REDES REMOTAS (RMON) La ms importante incorporacin a la aplicacin bsica de los estndares de gestin de red, SMI, MIB y el propio SNMP es el estndar de gestin o monitorizacin de redes remotas ( RMON ). RMON es un importante paso adelante en la gestin interredes. Define un MIB de monitorizacin remota que complementa a MIB-II y proporciona al gestor de la red informacin vital sobre su interrelacin con otras redes. Con MIB-II, el gestor de red puede obtener informacin puramente local sobre un dispositivo individual. Consideramos una LAN con varios dispositivos, cada uno con un agente SNMP. Un gestor SNMP puede conocer la cantidad de trfico que ha llegado o que ha salido de cada dispositivo, pero desde MIB-II, no es sencillo recabar informacin sobre el trfico de la LAN completa. Los aparatos que habitualmente se emplean para estudiar el trfico en conjunto de una red son llamados monitores de red o analizadores de red. Normalmente, los analizadores operan en modo promiscuo , visualizando todos los paquete dentro de la LAN. El monitor puede proporcionar y resumir informacin, incluyendo estadsticas de errores y de comportamiento, tambin puede almacenar paquetes enteros o parciales para anlisis posteriores; igualmente, se pueden utilizar filtros basados en algunas de las caractersticas de los paquetes para limitar el nmero de los capturados. A efectos de gestin de red en un entorno con varias redes, sera necesario habitualmente un monitor por cada red fsica. El monitor puede ser un sistema dedicado, cuyo nico objetivo sea capturar y analizar trficos o bien una estacin con otras tareas propias, una estacin de trabajo, un servidor o un router Para una gestin de red efectiva, estos monitores necesitan comunicar con una estacin . de gestin de red central, en general se les conoce como monitores remotos.

22

REDES DE ORDENADORES

SNMP

13.9.1.- OBJETIVOS RMON La especificacin de RMON es fundamentalmente una ampliacin de MIB. El efecto, sin embargo, es el de definicin de funciones e interfaces entre consolas de gestin basadas en SNMP y monitores remotos. En trminos generales, la capacidad de RMON proporciona una manera efectiva y eficiente de monitorizar comportamientos de subredes, reduciendo la carga en otros agentes y estaciones de gestin. El RFC1271 enumera los siguientes objetivos de diseo de RMON. Operacin Off-line: Podra ser deseable o necesario limitar o detener la rutina de sondeo de un monitor por parte de un gestor de red con el fin de ahorrar costos de comunicacin, especialmente cuando se utilizan lneas telefnicas para alcanzar el monitor. El sondeo puede cesar tambin si hay un fallo de comunicaciones o si falla el gestor. En general, el monitor debe recoger fallos, rendimiento e informacin de configuracin de forma continua, incluso si no est siendo sondeando por un gestor de red. El monitor simplemente continua acumulando estadsticas que pueden ser solicitadas por el gestor posteriormente. El monitor puede intentar tambin notificar la estacin de gestin si se produce un evento excepcional. Monitorizacin Apropiativa: Si el monitor tiene suficientes recursos, y si esta prctica no supone demasiada sobrecarga de trfico y proceso, el monitor puede hacer sondeos activos continuos sobre el resto de los dispostivos de su red para detectar errores y condiciones de excepcin, poder efectuar diagnsticos y registrar el rendimiento de la red. Alternativamente, el monitor puede reconocer de forma pasiva (sin sondeo) ciertas condiciones de error, y otras condiciones, tales como la congestin, sobre la base del trfico que observa. Deteccin y notificacin de problemas: En caso de que se produzca un fallo o se produzca alguna otra situacin predefinida en algn lugar dentro de Internet, el monitor registrar la condicin e intentar notificarla a la estacin de gestin. Datos de valor aadido: El monitor puede realizar anlisis especficos de los datos recogidos en las subredes, relevando a la estacin gestora de su responsabilidad. Por ejemplo, el monitor puede analizar el trfico de una subred para determinar que nodo genera la mayor parte del trfico o los errores de dicha subred. Este tipo de informacin que afecta a una subred no sera accesible de otro modo para una estacin gestora de red que no est directamente conectada a dicha subred. Gestores mltiples: Una configuracin de mltiples redes puede tener ms de una estacin gestora, con objeto de alcanzar un mayor grado de fiabilidad, realizar diferentes funciones y proporcionar capacidad de gestin a diferentes unidades dentro de una organizacin. El monitor puede estar configurado para trabajar con ms de una estacin gestora en paralelo. No todos los monitores remotos pueden cumplir todos estos objetivos, pero la especificacin RMON proporciona la base para la soportar todos ellos. 13.9.2.- CONTROL DE MONITORES REMOTOS Un monitor remoto puede implementarse bien como aparato dedicado o como una funcin disponible en un sistema en el que los recursos de memoria y proceso no estn dedicados a la funcin exclusiva de monitorizacin. El monitor remoto debe ser configurado para la captura de datos, especificando el tipo de datos y la forma en que van a ser recogidos. La forma en la que esto es contemplado dentro de MIB RMON es organizando la MIB en grupos funcionales; dentro de cada uno de los cuales puede haber una o ms tablas de control y una o ms tablas de datos. La tabla de control, que habitualmente es lectura y escritura, contiene parmetros que describen la configuracin del monitor RMON espcificando la informacin que captura y por lo tanto la informacin de la tabla de datos, que suele ser de slo lectura. La estacin de gestin establece los parmetros de control apropiados para configurar el monitor remoto de manera que recabe la informacin deseada. Los parmetros se establecen mediante la adicin de una fila a la tabla de control, o modificando una lnea ya existente.

REDES DE ORDENADORES

23

SNMP

A medida que se recoge la informacin de acuerdo al conjunto de parmetros de una fila de control, sta se almacena en las filas de la correspondiente tabla de datos. As, las funciones desarrolladas por un monitor estn definidas e implementadas en trmino de filas de la tabla de control. Por ejemplo, una tabla de control puede contener objetos que especifican las fuentes de datos que deben de ser recogidas, los intervalos para la recogida de datos, etc. Una fila individual de la tabla de control, mediante la asignacin de valores especficos a los parmetros de la tabla, define una funcin especfica de captura de datos. Asociada con la fila individual de control hay un o ms filas en una o ms tablas de datos. La fila de control y sus filas de datos asociadas estn enlazadas mediante punteros. La fila de control incluye un objeto ndice que puede utilizarse para acceder a una o ms filas de datos en una o ms tablas de datos; cada fila de datos incluye un ndice que se refiere a la correspondiente fila de la tabla de control. Para modificar cualquier parmetro de una tabla de control, es necesario en primer lugar borrar dicha fila y todas las filas asociadas en las tablas de datos. La estacin de gestin puede entonces crear una nueva fila de control con los parmetros modificados. El mismo mecanismo se utiliza para deshabilitar simplemente una funcin particular de captura de datos. En muchos casos, existe una relacin uno a uno entre los parmetros de control que definen una funcin de captura de datos y una fila individual de objetos utilizadas para mantener los datos recogidos. En estos casos, las tablas de datos y de control estn combinadas en unas tablas simples. 13.9.3.- INVOCACIN DE UNA ACCIN Como ya se indic anteriormente, SNMP no tiene un mecanismo especfico de envo de un comando para un agente para que ste ejecute una accin. Las nicas capacidades de SNMP estriban en la lectura de valores de objetos MIB y su modificacin. Sin embargo, es posible mediante operaciones SNMP enviar un mandato, empleando un objeto para representar un estado de modo que se realice una determinada accin cuando dicho objeto cambia de estado. La especificacin RMON sugiere que la etiqueta de propiedad contenga uno o ms de los siguientes datos: direccin IP; nombre de la estacin de gestin, nombre del gestor de red, localizacin o nmero de telfono. Aunque el concepto de propiedad es til, es importante tener en cuenta que la etiqueta de propiedad no acta como una clave o un mecanismo de control de acceso. El control de acceso slo se fuerza en SNMP mediante el uso de una vista asociada a MIB con un nombre de comunidad. Por tanto, si una tabla de control tiene permiso de acceso de lectura y escritura, est disponible para la lectura y escritura a todas las estaciones de gestin para las cuales la tabla es visible en su vista MIB. En general, una fila de una tabla de control slo debera ser modificada o borrada por su propietario y tratada como de slo lectura por las otras estaciones de gestin. 13.9.4.- GESTORES MLTIPLES Un agente RMON puede ser objeto de gestin de varias estaciones. En cualquier momento en el que se permitan varios accesos a un recurso, pueden existir conflictos y resultados no deseados. En el caso de un agente RMON compartido, pueden surgir las siguientes dificultades: Las demandas concurrentes de recursos pueden exceder la capacidad del monitor de proporcionarlos. Una estacin de gestin podra capturar y mantener recursos del monitor durante un periodo bastante extenso, impidiendo su uso por parte de otras estaciones gestoras para otras funciones. Los recursos pueden ser asignados a una estacin de gestin que se caiga sin liberarlos. Para resolver estos problemas, es suficiente una combinacin de aspectos de evitacin y resolucin. Asociado a cada tabla de control hay un objeto que identifica al propietario de una fila en particular de la tabla y de la funcin asociada. La etiqueta de propiedad puede ser utilizada de las siguientes formas:

24

REDES DE ORDENADORES

SNMP

Una estacin gestin puede reconocer recursos que le pertenecen y no necesita en adelante. Un operador de red puede identificar a la estacin gestora que posee un recurso o funcin en particular y negociar su liberacin. Un operador de red puede tener la autoridad para liberar unilateralmente los recursos que otro operador ha reservado. Si una estacin de gestin es reinicializada, puede reconocer recursos que haba reservado y liberarlos si ya no los va a necesitar. Dentro de SNMP, los procedimientos para aadir y borrar filas de tablas son poco claros. La falta de claridad ha sido el origen de numerosos problemas y cuestiones de discordia. La especificacin RMON incluye un conjunto de convenciones textuales y reglas de procedimiento que si bien no violan o modifican el marco SNMP proporcionan una tcnica clara y disciplinada para la insercin y borrado de filas 13.9.5.- LA MIB RMON La mayor parte de la especificacin RMON est orientada a la definicin de la Base de Informacin de Gestin de RMON. La MIB RMON se divide en nueve grupos: Estadsticas: Mantiene estadsticas de error y de bajo nivel de utilizacin para cada subred monitorizada por el agente. Historia: Guarda muestras estadsticas peridicas de la informacin disponible en el grupo estadstico. Alarma: Permite a la persona que trabaje en la consola gestora establecer un intervalo de muestreo y un umbral de alarma para cualquier dato grabado por el agente RMON. Host: Contiene datos sobre varios tipos de trfico de y hacia hosts conectados a la subred. HostTopN: Contiene estadsticas que se agrupan en una lista basadas en parmetros en la tabla "host". Matriz: Muestra informacin sobre errores y utilizaciones en forma de matriz, de modo que el operador recobre informacin para cualquier par de direcciones de la red. Filtro: Permite al monitor observar paquetes que casan con el filtro. El monitor puede capturar todos los paquetes que pasan el filtro o simplemente grabar estadsticas basadas en esos paquetes. Captura de paquetes: Administra la forma en la que los datos se envan a una consola de gestin. Evento: Una tabla con todos los eventos generados por el agente RMON. Cada grupo es usado para almacenar datos y estadsticas derivadas de la recoleccin de datos por parte del monitor. Un monitor puede tener ms de un interface fsico y as conectarse a ms de una subred. Los datos almacenados en cada grupo representan datos de una o ms subredes conectadas, dependiendo de cmo el monitor es configurado para cada grupo particular.

REDES DE ORDENADORES

25

SNMP

13.- SNMP: PROTOCOLO DE GESTIN DE RED SIMPLE ............................................................... 1 13.1.- NECESIDAD DE LOS SISTEMAS DE GESTIN ................................................................. 1 13.2.- EL DESARROLLO DE LA GESTIN TCP/IP ....................................................................... 2 13.3.- RECOGIDA DE LA INFORMACIN DE GESTIN .............................................................. 2 13.4.- ARQUITECTURA SNMP...................................................................................................... 3 13.5.- EL PROTOCOLO SNMP...................................................................................................... 5 13.5.1.- FORMATO DE LOS MENSAJES SNMP......................................................................... 6 13.5.2.- PDU GET-REQUEST, GET-NEXT-REQUEST, SET-REQUEST ..................................... 7 13.5.3.- PDU Trap ....................................................................................................................... 9 13.6.- SNMPv2 ............................................................................................................................. 10 13.6.1.- Entidad SNMPv2 .......................................................................................................... 10 13.6.2.- Party SNMPv2.............................................................................................................. 11 13.6.3.- GetBulkRequest ........................................................................................................... 11 13.6.4.- InformRequest .............................................................................................................. 12 13.6.5.- Autenticacin y Protocolo de privacidad........................................................................ 12 13.6.6.- El nuevo modelo administrativo .................................................................................... 13 13.6.7.- El nuevo formatode trama............................................................................................. 13 13.7.- ESTRUCTURA DE LA INFORMACION DE GESTIN: SMI ............................................... 14 13.7.1.- IDENTIFICADORES DE OBJETO ................................................................................ 15 13.7.2.- CODIFICACION DE LA INFORMACIN....................................................................... 17 13.8.- BASE DE INFORMACION DE GESTIN ( MIB ) ............................................................... 17 13.8.1.- IDENTIFICACION DE UNA INSTANCIA ....................................................................... 20 13.8.2.- MIB para SNMPv2........................................................................................................ 21 13.8.3.- MIB para Party ............................................................................................................. 21 13.8.4.- MIB Gestor a Gestor..................................................................................................... 22 13.9. GESTION DE REDES REMOTAS (RMON).......................................................................... 22 13.9.1.- OBJETIVOS RMON...................................................................................................... 23 13.9.2.- CONTROL DE MONITORES REMOTOS ..................................................................... 23 13.9.3.- INVOCACIN DE UNA ACCIN .................................................................................. 24 13.9.4.- GESTORES MLTIPLES ............................................................................................. 24 13.9.5.- LA MIB RMON.............................................................................................................. 25

26

REDES DE ORDENADORES