Top Banner
Modelo de Gestión de Red 26 de julio de 2010 Índice Índice .............................................................1 Introducción........................................................2 1 Modelo de gestión de red OSI…………………………………………………………………………………………………………3 1.1. Objetivos y claves de sus diseños…………………………………………………………………………………………….3 1.2. Esquema general ……………………………………………………………………………………………………………………3 1.3. Principales modelos………………………………………………………………………………………………………………..3 1.3.1. Modelo de comunicación: CMIP (Protocolo Común de Información de Gestión)………….3 1.3.2. Modelo de Información: GDMO…………………………………………………………………………………….4 1.3.3. Modelo Funcional………………………………………………………………………………………………………….7 1.3.4. Modelo de Organización………………………………………………………………………………………………..8 2. Modelo de Gestión de Red……………………………………………………………………………………………………………..9 2.1. Premisas de Diseño………………………………………………………………………………………………………………….9 2.2. Principales Soluciones………………………………………………………………………………………………………………9 2.2.1. Protocolo Simple de Monitorización de Pasarelas (SGMP) ……………………………………………..10 2.2.2. Sistema de Gestión de Entidades de Alto Nivel (HEMS) …………………………………………………17 2.2.3. CMOT…………………………………………………………………………………………………………………………….17 Conclusiones........................................................18 Bibliografía .......................................................19 1
26
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: Modelo de gestion de red

Modelo de Gestión de Red 26 de julio de 2010

Índice

Índice ......................................................................................................................................................1

Introducción............................................................................................................................................2

1 Modelo de gestión de red OSI…………………………………………………………………………………………………………3

1.1. Objetivos y claves de sus diseños…………………………………………………………………………………………….31.2. Esquema general ……………………………………………………………………………………………………………………31.3. Principales modelos………………………………………………………………………………………………………………..3

1.3.1. Modelo de comunicación: CMIP (Protocolo Común de Información de Gestión)………….31.3.2. Modelo de Información: GDMO…………………………………………………………………………………….41.3.3. Modelo Funcional………………………………………………………………………………………………………….71.3.4. Modelo de Organización………………………………………………………………………………………………..8

2. Modelo de Gestión de Red……………………………………………………………………………………………………………..9

2.1. Premisas de Diseño………………………………………………………………………………………………………………….92.2. Principales Soluciones………………………………………………………………………………………………………………9

2.2.1. Protocolo Simple de Monitorización de Pasarelas (SGMP)……………………………………………..102.2.2. Sistema de Gestión de Entidades de Alto Nivel (HEMS)…………………………………………………172.2.3. CMOT…………………………………………………………………………………………………………………………….17

Conclusiones............................................................................................................................................18

Bibliografía ..............................................................................................................................................19

1

Page 2: Modelo de gestion de red

Modelo de Gestión de Red 26 de julio de 2010

INTRODUCCIÓN

La evolución de las técnicas de gestión va pareja a la evolución en las tecnologías que permiten la propia evolución de las redes.

La gestión y red de servicios ha sido un campo en el que tradicionalmente se han impuesto soluciones y mecanismos propietarios de distintos fabricantes, que exigían que la gestión de sus equipos y servicios solo se pudieran realizar con el gestor del propio fabricante. Ante este escenario a principios d los 90 surgieron los denominados modelos de gestión de red integrada, que definían un protocolo y unos modelos de información de gestión estándares.

Debido a diversas razones, fueron dos los modelos propuestos: el modelo de gestión de red de internet (SNMP), y el modelo de gestión de red OSI (conocido con el nombre del protocolo: CMIP

2

Page 3: Modelo de gestion de red

Modelo de Gestión de Red 26 de julio de 2010

MODELO DE GESTIÓN DE RED

1. Modelo de gestión de red OSI

La Gestión de Sistemas OSI se basa en el uso de protocolos del nivel de aplicación para el intercambio de información de gestión según el paradigma Gestor-Agente

1.1. Objetivos y claves de sus diseños

Definido por ISO, con el objetivo de lograr la gestión de los recursos del modelo de referencia OSI.

Diseñado para realizar la gestión de la torre de protocolos OSI.

Sirve para el intercambio de información de gestión entre las aplicaciones y los agentes, que acceden al servicio mediante el interface estándar CMIS (Common Management Information Service), que, en el caso de utilizar el protocolo TCP/IP recibe el nombre de CMOT.

1.2. Esquema general

3

Page 4: Modelo de gestion de red

Modelo de Gestión de Red 26 de julio de 2010

1.3. Principales modelos1.3.1.Modelo de comunicación:

La Gestión de Sistemas OSI propugna el intercambio de información de gestión mediante un protocolo de nivel de aplicación.

Este protocolo se denomina CMIP (Common Management Information Protocol), Protocolo Común de Información de Gestión, que proporciona el servicio CMIS (Common Management Information Service), Servicio Común de Información de Gestión.

CMIP, es un protocolo de administración de red que define la comunicación entre las aplicaciones de administración de red y la gerencia de los agentes, define la información de la gerencia en términos de objetos administrados y permite tanto la modificación como las acciones sobre objetos gestionados

1.3.2.Modelo de Información:

El modelo de información OSI se basa en el concepto de Objeto Gestionado, que es la abstracción de recursos de comunicación o de procesado de información con el propósito de su gestión.

Del mismo modo, se define Clase de Objetos Gestionados como el conjunto de objetos que tienen las mismas propiedades de cara al sistema de gestión.

Para llevar a cabo la especificación de las clases de objetos gestionados, se utiliza la sintaxis GDMO (Guidelines for the Definition of Managed Objects), Directrices para la Definición de Objetos Gestionados. GDMO se basa en la utilización de unas plantillas.

GDMO es un metalenguaje de plantillas (templates) simple (ISO 10165-4), basado en ASN.1 (ISO 8824). Es utilizado para describir las Clases de Objetos Administrables (MOCs) en el modelo de información de la arquitectura de administración OSI. GDMO especifica el formato y los lineamientos para las definiciones de las MOC. En las definiciones de plantilla se puede hacer referencia a otras (definiciones de) plantillas. Cada referencia a otra plantilla puede ser reemplazada en línea (macro expansion) por la correspondiente definición de plantilla. OSI-SMI utiliza las siguientes estructuras genéricas para las plantillas:

A. Managed object class: Es el nivel más alto; otras plantillas pueden ser utilizadas para definir esta de manera más exacta utilizando una descomposición descendente (por ejemplo, la clase está compuesta por paquetes, el paquete está compuesto por atributos, notificaciones, comportamientos y parámetros).

4

Page 5: Modelo de gestion de red

Modelo de Gestión de Red 26 de julio de 2010

B.

Conditional Package: Que permitan incorporar variantes de ciertas propiedades y funciones. Cuando se "instancia" un MO, una decisión sobre sus características es tomada basada en condiciones if, colocadas en la definición de la MOC, para saber si dicho paquete formará parte integral del MO (es decir, el condicional colocado en la plantilla de definición de la clase especifica cuándo el paquete estará o no estará presente en una instancia de dicha clase). Esto puede hacer más fácil mapear un MO a un recurso real. Los paquetes condicionales ofrecen un alto nivel de flexibilidad en la especificación al permitir una "asociación tardía" al recurso real.

C. Attribute: son visibles en la managed object boundary y caracterizan las propiedades y el estado del objeto administrable. Los tipos de atributos utilizados dependen del objeto que está siendo modelado. Los atributos pueden ser asociados con tipos ASN.1 o puede derivarse de un atributo genérico como counters, gauges, thresholds, names, timers al igual que de tipos más complejos definidos en ISO 101165-2 ó en X.721. Los valores y operaciones permitidos están especificados para cada atributo, permitiendo restringir rangos de valores y aplicar protección de escritura. Plantillas de atributos se utilizan para describir atributos. Una plantilla de grupo (ATTRIBUTE GROUP) hace posible que los atributos sean combinados en grupos que pueden ser accedidos (leídos ó establecidos por defecto) a través del uso de un solo comando. Los atributos pueden ser de dos categorías: singled valued y set valued (El atributo single valued es administrado como un sólo dato con respecto a las modificaciones. Aunque no es obvio, un atributo es considerado de este tipo si un sólo valor ó un conjunto de valores ordenados se asocia con él. Un atributo set valued es una colección de valores que no está

5

Page 6: Modelo de gestion de red

Modelo de Gestión de Red 26 de julio de 2010

ordenado y se define utilizando la construcción "set of"). Las operaciones orientadas a atributo exitentes son:

a. get: lee el valor de un atributo b. replace: escribe el valor de un atributo c. replace-with-default d. add: agrega un valor a atributos set-valued e. remove: remueve un valor de atributo de cierto set-valued f. set-by-create: asigna un valor solo cuando el MO está siendo

creado g. not-modify: evita que el atributo sea refinado al crear subclases

D. Behavior: Respectivo que es especificado en la plantilla de

comportamiento. Esta plantilla (template) registra la semántica de los atributos, las operaciones y las notificaciones e indica las relaciones con otros MOs, efectos laterales, etcétera. El comportamiento generalmente se describe de manera informal utilizando lenguaje (inglés) normal. También existen enfoques que incorporan formal descriptions techniques (FDTs) para describir el comportamiento; incluyen un lenguaje de descripción y uno de especificación (SDL, ITU-T Z.100) que han sido agregados a la serie de estándares ISO 10165. Sin embargo, requieren una extensión al lenguaje GDMO (GDMO+).

E. Action: Operaciones complejas que afectan todo el MO (objeto administrable). Pueden definirse para que sean específicas a ese MO (por ejemplo "reset MO"). Una plantilla (template) de acción es utilizada para especificar acciones. Además de las acciones (ACTIONS), que definen libremente operaciones específicas a un MO, hay dos operaciones predefinidas que siempre afectan al MO en su totalidad: create MO (instanciación dinámica) y delete MO (las acciones, create MO y delete MO se consideran operaciones orientadas a objetos y son diferentes de las listadas antes -get, replace, add, remove, etc.- que están orientadas a atributos).

F. Notification: Un MO también puede ser un recurso autónomo en el cual pueden ocurrir eventos asincrónicos. Las notificaciones son mecanismos utilizados para informar sobre eventos que pueden ser iniciados por un MO sin necesidad de que el sistema de administración lo solicite. La plantilla (tamplate) de notificación es utilizada para describir las notificaciones que pueden (aunque no necesariamente) ser específicas a un MO.

6

Page 7: Modelo de gestion de red

Modelo de Gestión de Red 26 de julio de 2010

1.3.3.Modelo Funcional:

Se definen las funciones de gestión que proporcionan una interfaz a la aplicación de gestión, el cual describe las cinco áreas en las que tradicionalmente se ha dividido la gestión de red:

A. Gestión de falloso Gestión de fallos X700: la detección, el aislamiento y la

corrección de fallos, la corrección de la operación anormal del entorno OSI.

Los fallos se manifiestan como sucesos particulares (por ejemplo, errores) en la operación de un sistema abierto.

La detección de errores proporciona una capacidad para reconocer fallos

Funciones: mantener y examinar cuadernos de error (error logs); aceptar notificaciones de detección de error y reaccionar a las mismas; rastrear e identificar fallos; efectuar secuencias de pruebas de diagnóstico; y eliminar fallos.

B. Gestión de configuracióno La gestión de configuración identifica, ejerce control sobre, toma

datos de, y proporciona datos para, sistemas abiertos, con el fin de preparar, inicializar, poner en marcha, y tener en cuenta la operación continua y la terminación de, servicios de interconexión.

Funciones: Establecer los parámetros que controlan la operación rutinaria del sistema abierto; asociar nombres con objetos gestionados y conjuntos de objetos gestionados; inicializar y cerrar objetos gestionados; reunir, a petición, información sobre la condición actual del sistema abierto; obtener anuncios de cambios significativos en la condición del sistema abierto; y cambiar la configuración del sistema abierto.

C. Gestión de prestacioneso La gestión de prestaciones o del rendimiento tiene como

objetivo principal el mantenimiento del nivel de servicio que la red ofrece a sus usuarios, asegurándose de que está operando de manera eficiente en todo momento.

Funciones: Recogida de datos o variables indicadoras de rendimiento, tales como el troughput de la red, los tiempos de respuesta o latencia, la utilización de la línea, etc.; Análisis de los datos para determinar los niveles normales de rendimiento ; Establecimiento de umbrales,

7

Page 8: Modelo de gestion de red

Modelo de Gestión de Red 26 de julio de 2010

como indicadores que fijan los niveles mínimos de rendimiento que pueden ser tolerados; Determinación de un sistema de procesado periódico de los datos de prestación de los distintos equipos, para su estudio continuado.

D. Gestión de contabilidado Gestión de contabilidad X700: Permite establecer cargos (o

tasas) por el uso de recursos en el OSIE, e identificar costos correspondientes a la utilización de esos recursos.

Funciones: informar a los usuarios de costos ocasionados o recursos consumidos; permitir el establecimiento de límites de contabilidad y asociar calendarios de tarifas a la utilización de recursos; y permitir la combinación de costos cuando se invoquen múltiples recursos para alcanzar un objetivo de comunicación dado.

E. Gestión de seguridad.o La gestión de seguridad tiene por finalidad soportar la aplicación

de políticas de seguridad Funciones: estas funciones incluyen la creación,

supresión y control de servicios y mecanismos de seguridad; la distribución de información relativa a la seguridad; y señalización de sucesos relacionados con la seguridad.

1.3.4.Modelo de Organización:

El modelo de organización parte de una estructura de red dividida en dominios de gestión.La división del entorno se realiza a partir de dos aspectos principales:

o Políticas funcionales (p. e. dominios con una misma política de seguridad, contabilidad, etc.)

o Otras políticas, como dominios geográficos, tecnológicos, etc. o La red se estructura en dominios administrativos, con la necesidad de

establecer y mantener las responsabilidades de cada dominio. o El sistema permite que dentro de un dominio, se pueda reasignar

dinámicamente el papel de gestores y agentes.

8

Page 9: Modelo de gestion de red

Modelo de Gestión de Red 26 de julio de 2010

2. Modelo de Gestión de red (Internet)

2.1. Premisas de Diseño

El modelo de gestión SNMP parte de una estación de gestión (gestor), que sirve de interfaz para los operadores humanos y que incluye un conjunto de aplicaciones de gestión, y se comunica con uno o varios agentes (que son aplicaciones software instaladas en los recursos físicos de la red, tales como routers, hubs, etc) encargados de responder a las peticiones de información o de ejecución de acciones sobre los recursos gestionados provenientes de la estación de gestión

SNMP únicamente proporciona un marco para realizar el desarrollo de aplicaciones de gestión de red. Este marco consta del protocolo mediante el que los actores implicados (gestores y agentes) intercambian información de gestión, la estructura de dicha información y los tipos de datos que la soportan, así como la base de datos mantenida por los agentes en la que se almacena la información de gestión.

Quedan fuera de los estándares SNMP aspectos como la definición de las propias aplicaciones de gestión, el mecanismo concreto utilizado en el diálogo del agente con los recursos a los que representa, los detalles de implantación, etc.

Aunque inicialmente SNMP sólo se utilizaba en equipos relacionados con el mundo IP, y a pesar de sus limitaciones, la sencillez y la facilidad para su implementación, unidos al crecimiento de Internet y las tecnologías asociadas, ha hecho que su uso se haya extendido rápidamente en el campo de la gestión.

2.2. Principales Soluciones

Soluciones actuales:Las aplicaciones de gestión software se deben desarrollar teniendo un amplio conocimiento de las necesidades de los clientes y estar basadas en un conjunto común de reglas de diseño. Así, se han desarrollado aplicaciones que, basadas en plataformas abiertas, permiten la gestión, control y administración de los recursos de red. Es algo mucho más amplio que un simple sistema de recogida de alarmas de red y actuación remota sobre diferentes elementos de ella, ya que comprende otras funciones tales como gestión de direcciones, gestión de facilidades de las líneas y de las prestaciones de los elementos de red. Las aplicaciones de gestión pueden incluirse en un único PC o distribuirse a lo largo de un número de ellos, empleando un módulo que proporcione funciones de servidor de datos para las demás aplicaciones, y que en definitiva se configura mediante su co-instalación con una base de datos, por ejemplo la "SQL Server" de Microsoft. Es posible construir una gran red de gestores mediante el uso de varios servidores de datos, en la que cada uno de estos atienda un subconjunto concreto de nodos. Al iniciar una aplicación que actúe como cliente, elegirá uno de los

9

Page 10: Modelo de gestion de red

Modelo de Gestión de Red 26 de julio de 2010

gestores al que conectarse y entonces, dependiendo del nivel de autoridad, administrar los nodos asociados. Esta arquitectura distribuida permite optimizar el tráfico y los tiempos de respuesta, lo que es especialmente importante en las grandes redes internacionales.

Para realizar una exploración automática y crear sub-mapas particulares para cada nodo, existen aplicaciones que presentan, mediante iconos, los diferentes elementos. Los sub-mapas pueden reunirse para tener una jerarquía de mapas que permiten ir desde el nivel global hasta cada nodo particular. Tan pronto como ocurren, todas las alarmas se transmiten hacia los niveles superiores de la topología y estudiando el registro de alarmas a nivel de nodos, se pueden determinar las causas de los diferentes sucesos notificados.

2.2.1.Protocolo Simple de Monitorización de Pasarelas (SGMP)Sencillo Protocolo orientado fundamentalmente a la gestión de pasarelas IP.

SGMP, permite que los comandos que se publicará a las entidades de protocolo de aplicación para establecer o recuperar los valores (octeto entero o tipos de cadena) para su uso en la vigilancia de las puertas de enlace en el que las entidades de protocolo de aplicación residen. Los mensajes son intercambiados mediante UDP y utilizar métodos de transporte poco fiable. Autenticación se lleva a cabo en el puerto UDP 153. Algunos ejemplos de cosas que pueden ser controlados se enumeran a continuación.

Tipo de red para las interfaces: IEEE 802.3 MAC, IEEE 802.4 MAC, IEEE 802.5 MAC, Ethernet , PRONET-80, PRONET-10, FDDI , X.25 , punto a punto de serie, RPA 1822 HDH, ARPA 1822, AppleTalk , StarLan

Estado de la interfaz (abajo, arriba, intentando, etc) Tipo de ruta (local, remoto, sub-red, etc) Protocolo de enrutamiento ( RIP , EGP , GGP, IGRP)

Posteriormente pasaría a llamarse SNMP (Simple Network Management Protocol), Protocolo Simple de Gestión de Red.

SNMP permite a los administradores supervisar el funcionamiento de la red, buscar y resolver sus problemas, y planear su crecimiento.

Versiones:SNMP versión 1 (SNMPv1): diseñado para facilitar el intercambio de gstion de información entre los dispositivos de red.SNMP versión 2 (SNMPv2): reduce la carga de tráfico adicional para la monitorización (GetBulk e Informs) y solucionar los problemas de monitorización remota o distribuida con (RMON)

10

Page 11: Modelo de gestion de red

Modelo de Gestión de Red 26 de julio de 2010

SNMP versión 2 (SNMPv3): Mayor seguridad en las transmisiones (Cifrado y Autentificación)

Comandos básicos:

Los dispositivos administrados son supervisados y controlados usando cuatro comandos SNMP básicos: lectura, escritura, notificación y operaciones transversales.

El comando de lectura es usado por un NMS (proporcionan el volumen de recursos de procesamiento y memoria requeridos para la administración de la red) para supervisar elementos de red. El NMS examina diferentes variables que son mantenidas por los dispositivos administrados.El comando de escritura es usado por un NMS para controlar elementos de red. El NMS cambia los valores de las variables almacenadas dentro de los dispositivos administrados.El comando de notificación es usado por los dispositivos administrados para reportar eventos en forma asíncrona a un NMS. Cuando cierto tipo de evento ocurre, un dispositivo administrado envía una notificación al NMS.Las operaciones transversales son usadas por el NMS para determinar qué variables soporta un dispositivo administrado y para recoger secuencialmente información en tablas de variables, como por ejemplo, una tabla de rutas.

A. Base de información de administración SNMP (MIB)Una Base de Información de Administración (MIB) es una colección de información que está organizada jerárquicamente. Un objeto administrado (algunas veces llamado objeto MIB, objeto, o MIB) es uno de cualquier número de características específicas de un dispositivo administrado. Los objetos administrados están compuestos de una o más instancias de objeto, que son esencialmente variables.

Existen dos tipos de objetos administrados: Escalares y tabulares. Los objetos escalares definen una simple instancia de objeto. Los objetos tabulares definen múltiples instancias de objeto relacionadas que están agrupadas conjuntamente en tablas MIB.

Un identificador de objeto (object ID) únicamente identifica un objeto administrado en la jerarquía MIB. La jerarquía MIB puede ser representada como un árbol con una raíz anónima y los niveles, que son asignados por diferentes organizaciones.

11

Page 12: Modelo de gestion de red

Modelo de Gestión de Red 26 de julio de 2010

B. Mensajes SNMP

Para realizar las operaciones básicas de administración anteriormente nombradas, el protocolo SNMP utiliza un servicio no orientado a la conexión (UDP) para enviar un pequeño grupo de mensajes (PDUs) entre los administradores y agentes. La utilización de un mecanismo de este tipo asegura que las tareas de administración de red no afectarán al rendimiento global de la misma, ya que se evita la utilización de mecanismos de control y recuperación como los de un servicio orientado a la conexión, por ejemplo TCP.

Los puertos comúnmente utilizados para SNMP son los siguientes:

Número Descripción 161 SNMP 162 SNMP-trap

Los paquetes utilizados para enviar consultas y respuestas SNMP poseen el siguiente formato:

Versión Comunidad SNMP PDU

Versión: Número de versión de protocolo que se está utilizando (por ejemplo 1 para SNMPv1); Comunidad: Nombre o palabra clave que se usa para la autenticación. Generalmente existe una comunidad de lectura llamada "public" y una comunidad de escritura llamada "private"; SNMP PDU: Contenido de la unidad de datos del protocolo, el que depende de la operación que se ejecute.

12

Page 13: Modelo de gestion de red

Modelo de Gestión de Red 26 de julio de 2010

Los mensajes GetRequest, GetNextRequest, SetRequest y GetResponse utilizan la siguiente estructura en el campo SNMP PDU:

Tipo Identificador Estado de error Índice de error Enlazado de variables Identificador: Es un número utilizado por el NMS y el agente para enviar solicitudes y respuesta diferentes en forma simultánea;

Estado e índice de error: Sólo se usan en los mensajes GetResponse´(en las consultas siempre se utiliza cero). El campo "índice de error" sólo se usa cuando "estado de error" es distinto de 0 y posee el objetivo de proporcionar información adicional sobre la causa del problema. El campo "estado de error" puede tener los siguientes valores:

0: No hay error; 1: Demasiado grande; 2: No existe esa variable; 3: Valor incorrecto; 4: El valor es de solo lectura; 5: Error genérico.

Enlazado de variables: Es una serie de nombres de variables con sus valores correspondientes (codificados en ASN.1).

GetRequestA través de este mensaje el NMS solicita al agente retornar el valor de un objeto de interés mediante su nombre. En respuesta el agente envía una respuesta indicando el éxito o fracaso de la petición. Si la petición fue correcta, el mensaje resultante también contendrá el valor del objeto solicitado. Este mensaje puede ser usado para recoger un valor de un objeto, o varios valores de varios objetos, a través del uso de listas.

GetNextRequestEste mensaje es usado para recorrer una tabla de objetos. Una vez que se ha usado un mensaje GetRequest para recoger el valor de un objeto, puede ser utilizado el mensaje GetNextRequest para repetir la operación con el siguiente objeto de la tabla. Siempre el resultado de la operación anterior será utilizado para la nueva consulta. De esta forma un NMS puede recorrer una tabla de longitud variable hasta que haya extraído toda la información para cada fila existente.

SetRequestEste tipo de mensaje es utilizado por el NMS para solicitar a un agente modificar valores de objetos. Para realizar esta operación el NMS envía al

13

Page 14: Modelo de gestion de red

Modelo de Gestión de Red 26 de julio de 2010

agente una lista de nombres de objetos con sus correspondientes valores.

GetResponseEste mensaje es usado por el agente para responder un mensaje GetRequest, GetNextRequest, o SetRequest. En el campo "Identificador de Request" lleva el mismo identificador que el "request" al que está respondiendo.

TrapUna trap es generada por el agente para reportar ciertas condiciones y cambios de estado a un proceso de administración. El formato de la PDU es diferente:

Tipo Enterprise Dirección del agente Tipo genérico de trap Tipo específico de trap Timestamp Enlazado de variables

Enterprise: Identificación del subsistema de gestión que ha emitido el trap;

Dirección del agente: Dirección IP del agente que ha emitido el trap;

Tipo genérico de trap: Cold start (0): Indica que el agente ha sido inicializado o

reinicializado Warm start (1): Indica que la configuración del agente ha

cambiado

Link down (2): Indica que una interfaz de comunicación se encuentra fuera de servicio (inactiva)

Link up (3): Indica que una interfaz de comunicación se encuentra en servicio (activa)

Authentication failure (4): Indica que el agente ha recibido un requerimiento de un NMS no autorizado (normalmente controlado por una comunidad)

EGP neighbor loss (5): Indica que en sistemas en que los routers están utilizando el protocolo EGP, un equipo colindante se encuentra fuera de servicio

Enterprise (6): En esta categoría se encuentran todos los nuevos traps incluidos por los vendedores.

14

Page 15: Modelo de gestion de red

Modelo de Gestión de Red 26 de julio de 2010

Tipo específico de trap: Es usado para traps privados (de fabricantes), así como para precisar la información de un determinado trap genérico; Timestamp: Indica el tiempo que ha transcurrido entre la reinicialización del agente y la generación del trap; Enlazado de variables: Se utiliza para proporcionar información adicional sobre la causa del mensaje.

GetBulkRequestEste mensaje es usado por un NMS que utiliza la versión 2 ó 3 del protocolo SNMP típicamente cuando es requerida una larga transmisión de datos, tal como la recuperación de largas tablas. En este sentido es similar al mensaje GetNextRequest usado en la versión 1 del protocolo, sin embargo, GetBulkRequest es un mensaje que implica un método mucho más rápido y eficiente, ya que a través de un solo mensaje es posible solicitar la totalidad de la tabla.

InformRequestUn NMS que utiliza la versión 2 ó 3 del protocolo SNMP transmite un mensaje de este tipo a otro NMS con las mismas características, para notificar información sobre objetos administrados.

Nota: el SNMP proporciona amplia información:

Sistema: Incluye la identidad del vendedor y el tiempo desde la última re inicialización del sistema de gestión.

Interfaces: Un único o múltiples interfaces, local o remoto, etc.

ATT (Address Translation Table): Contiene la dirección de la red y las equivalencias con las direcciones físicas.

IP (Internet Protocol): Proporciona las tablas de rutas, y mantiene estadísticas sobre los datagramas IP recibidos.

ICMP (Internet Communication Management Protocol): Cuenta el número de mensajes ICMP recibidos y los errores.

TCP (Transmission Control Protocol): Facilita información acerca de las conexiones TCP, retransmisiones, etc.

UDP (User Datagram Protocol): Cuenta el número de datagramas UDP, enviados, recibidos y entregados.

15

Page 16: Modelo de gestion de red

Modelo de Gestión de Red 26 de julio de 2010

EGP (Exterior Gateway Protocol): Recoge información sobre el número de mensajes EGP recibidos, generados, etc.

RMON (Remote MONitor)

Define las funciones de supervisión de la red y los interfaces de comunicaciones entre la plataforma de gestión SNMP, los monitores remotos y los Agentes de supervisión que incorporan los dispositivos inteligentes.

Alarmas: Informa de cambios en las características de la red, basado en valores umbrales para cualquier variable MIB de interés. Permite que los usuarios configuren una alarma para cualquier Objeto gestionado.

Estadísticas: Mantiene utilización de bajo nivel y estadísticas de error.

Historias: Analiza la tendencia, según instrucciones de los usuarios, basándose en la información que mantiene el grupo de estadísticas.

Filtros: Incluye una memoria para paquetes entrantes y un número cualquiera de filtros definidos por el usuario, para la captura selectiva de información; incluye las operaciones lógicas AND, OR y NOT.

Ordenadores: Una tabla estadística basada en las direcciones MAC, que incluye información sobre los datos transmitidos y recibidos en cada ordenador.

Los N principales: Contiene solamente estadísticas ordenadas de los "N" ordenadores definidos por el usuario, con lo que se evita recibir información que no es de utilidad.

Matriz de tráfico: Proporciona información de errores y utilización de la red, en forma de una matriz basada en pares de direcciones, para correlacionar las conversaciones en los nodos más activos.

Captura de paquetes: Permite definir buffers para la captura de paquetes que cumplen las condiciones de filtrado.

Sucesos: Registra tres tipos de sucesos basados en los umbrales definidos por el usuario: ascendente, descendente y

16

Page 17: Modelo de gestion de red

Modelo de Gestión de Red 26 de julio de 2010

acoplamiento de paquetes, pudiendo generar interrupciones para cada uno de ellos

2.2.2.Sistema de Gestión de Entidades de Alto Nivel (HEMS)Sistema de Gestión de Entidades de Alto Nivel. Nunca llegó a tener aplicación práctica.

2.2.3.CMOT (CMIP)Adopción de los estándares ISO como marco de gestión para Internet sobre una torre de protocolos TCP/IP.

CMIP es un protocolo de administración de red que define la comunicación entre las aplicaciones de administración de red y la gerencia de los agentes, define la información de la gerencia en términos de objetos administrados y permite tanto la modificación como las acciones sobre objetos gestionados. Se describen usando GDMO y los objetos son identificados por un nombre distinguido (DN), similar en concepto al directorio X.500.

Los NMS pueden realizar las operaciones siguientes:

CREATE - crear una instancia de un objeto gestionado. DELETE - suprimir una instancia de un objeto gestionado. GET - solicitar el valor de un atributo de una instancia de un objeto

gestionado. CANCEL_GET - cancelar una petición de GET en curso. SET - fijar el valor de un atributo de una instancia de un objeto

gestionado. ACTION - solicitar una acción para ocurrir según lo definido por el objeto

gestionado. El agente administrador puede realizar esta operación:

EVENT_REPORT - enviar notificaciones o alarmar a los NMS.

CMIP también proporciona buena seguridad (autorización de la ayuda, control de acceso y registros de la seguridad) y un reporte flexible de las condiciones inusuales de la red.

17

Page 18: Modelo de gestion de red

Modelo de Gestión de Red 26 de julio de 2010

CONCLUSIONES

Modelo de Gestión OSI

Estándar en el mercado, este además es útil para el acceso a datos de gestión de red.

Tiene una independencia del entorno de comunicaciones, capacidades generales de monitorización y control, teniendo de esta forma una obtención selectiva de la información

Modelo de Gestión de Red (Internet)

En los setenta el número de nodos de Internet era muy reducido se gestionaba Internet con las facilidades que ofrecía el protocolo ICMP, como el PING. Cuando Internet avanzó en complejidad, multiplicando el número de nodos se empezó a trabajar en tres soluciones diferentes, que se definieron en 1987: SGMP, HEMS, CMOT

Hoy en día el modelo de Gestión SNMP es el más usado para la gestión de redes IP, por su sencillez en el manejo.

18

Page 19: Modelo de gestion de red

Modelo de Gestión de Red 26 de julio de 2010

BIBLIOGRAFÍA

http://www.rhernando.net/modules/tutorials/doc/redes/Gredes.htmlhttp://www.ramonmillan.com/tutoriales/gestionred.phphttp://personal.us.es/toni/_private/ManagementNetwork.pdfhttp://tvdi.det.uvigo.es/~mramos/gprsi/gprsi3.pdfhttp://www.fic.udc.es/files/asignaturas/56XR/files/09-GestionOSI-2009.pdfhttp://es.wikipedia.org/wiki/Simple_Network_Management_Protocolhttp://www.coit.es/publicac/publbit/bit102/quees.htmhttp://es.wikitel.info/wiki/Gesti%C3%B3n_y_operaci%C3%B3n_de_red

19