Gestion de Red

Introducción
• Actualmente las redes de las organizaciones tienden a ser:

– Grandes en tamaño, muchos dispositivos
– Soportan muchas aplicaciones y muchos usuarios
• Administración compleja por un única persona

– Equipos de diferentes vendedores Æ Configuración diferente
– Necesidad de aprender distintos métodos para obtener información
– Dimensión de la red ↑↑ Æ Problema ↑↑
• Surge la necesidad de utilizar protocolos de administración que

posibiliten la gestión de redes independientemente de su tamaño
Protocolos y Servicios. Gestión de Red 1

Definición y Áreas de actuación
• Gestión de Red: Es el control y supervisión de una red compleja

para maximixar su eficiencia y productividad
• La ISO (International Organization for Standardization) define

cinco áreas para la administración de red:
• Gestión de fallos (detectar, aislar y corregir operaciones anormales)
• Gestión de seguridad (protección de la info. gestionada y control de
acceso a los recursos)
• Gestión de prestaciones (comportamiento de objetos adm. y
efectividad de comunicaciones)
• Gestión de configuración (controlar estado y mantenimiento de
componentes de la red)
• Gestión de cuentas (administrar y supervisar la actividad de
usuarios)

Historia
• En los años 70, se utilizaba como gestión de red la herramienta

ICMP, Internet Control Message Protocol
• Disponible en los dispositivos que soportaban IP
• Característica:
– echo de una petición ÆTest de la comunicación entre entidades
• Ejemplo: comando ping

Historia
• Si no hay respuesta Æ estación B caída
• Incovenientes:
– Información limitada
– Engorroso cuando la red es grande
– No hay garantías de que el mensaje sea devuelto aún cuando la
entidad B está operativa (congestión en los circuitos que se encargan de
transmitir el mensaje, debido a falta de espacio en el buffer,…)
• Necesario un protocolo de administración

Historia
• En los años 80, se desarrollan dos estándares de gestión de red:

– SNMP (Simple Network Management Protocol)
• Redes basadas en el estándar TCP/IP
– CMIS/CMIP (Common Management Information Service/Protocol)
• Redes basadas en el estándar OSI
• En 1988, el IAB (Internet Architecture Board) recomienda:
– SNMP como solución a corto plazo (había sido implementado y
comprobado)
– CMIS/CMIP como solución a largo plazo (estaba en fase de desarrollo
y mas complejo)
• Debido a que los estándares de gestión están siendo guiados por
las requisitos urgentes del mercado, actualmente el SNMP es el
estándar mas utilizado y desarrollado por todos los fabricantes

Evolución del SNMP
• En 1988, SNMPv1
• Inclusión de supervisión remota, RMON (Remote Monitoring)
– Obtener información de la red como un todo
• Deficiencias en funcionalidad y seguridad del v1
• En 1992,
– S-SNMP
– SMP Æ SNMPv2C
• No autentificación de usuarios ni encriptación
• En 1998, SNMPv3

Arquitectura de gestión de red
• Manager o Estación servidora

– Interfaz entre el usuario y el sistema de gestión
– Configurar y gestionar la red
– Estructura centralizada o distribuida
– Suelen estar replicadas
• Agente
– Ubicado en los dispositivos gestionados
– Responde a solicitudes realizadas por el manager
– Encargado de mantener la información local

• Base de datos de información de gestión, MIB (Management

Information Base)
– Recursos de red se representan como objetos
– Cada objeto representa un aspecto del dispositivo gestionado
(nombre host, dirección IP, nº de conexiones TCP,…)
– Colección de objetos se le denomina MIB
– Los objetos están estandarizados en cada sistema
– El manager realiza la supervisión leyendo y/o modificando los
valores de los objetos
– Cada agente dispone de su MIB local
– Puntos de acceso del manager sobre el agente

• Protocolo de gestión de red

– Para redes basadas en el estándar TCP/IP se utiliza el SNMP
– Medio de intercambio de información entre manager y agente
– SNMP incluye las siguientes operaciones:
• Get. Obtención del valor de los objetos situados en la MIB de
los agentes por parte del manager
• Set. El manager fija o modifica el valor de un objeto de la MIB
del agente
• Trap. El agente notifica al manager de forma asíncrona eventos
significativos (caída de un enlace,…)

Arquitectura del protocolo SNMP
• SNMP, protocolo a nivel de aplicación que forma parte de la

familia TCP/IP
• El protocolo de transporte utilizado es el UDP

– No orientado a conexión
– SNMP es no orientado a conexión
– No hay conexiones mantenidas entre manager y agente. Cada
intercambio de información es una transacción separada
• Managers y agentes utilizan SNMP, UDP, IP y protocolo de red

específico (Ethernet, X.25, FDDI,…)

• La estación manager posee un proceso para controlar el acceso a

la MIB central e interpretar los mensajes SNMP. Suministra una
interfaz de usuario con el gestor de la red
• El agente posee un proceso que controla el acceso a la MIB

local e interpreta los mensajes SNMP
• Todos los mensajes son enviados y recibidos por el puerto UDP

161, excepto los traps que son dirigidos al puerto UDP 162 del
manager


Proxy o representante
• SNMP requiere que tanto manager como agente soporten UDP e

IP
• Dispositivos como modems no soportan ninguna parte de la
familia de protocolos TCP/IP
• Sistemas pequeños que soportan TCP/IP, pero supone una carga
extra añadirle un agente y el mantenimiento de una MIB
• Solución: surge la figura del proxy
– Compatibilidad entre dispositivos que no implementan SNMP
– Desempeñado por un agente específico
– Puede controlar uno o varios dispositivos
– Actúa como intercambiador de información entre el manager y el
dispositivo no SNMP

Proxy o representante

Estructura de la Información de Gestión, SMI
• Cualquier sistema de gestión de red posee una base de datos que

contiene información acerca de los elementos gestionados, MIB
• Los datos contenidos en la MIB pueden ser leídos y modificados

(control y supervisión)
• Requisitos de la MIB:
– Los objetos utilizados para representar un recurso particular tienen
que ser los mismos en cada sistema
– Se requiere un esquema común para soportar interoperabilidad

SMI
• RFC 1155
– Describe el modo en el que se define y construye una MIB
– Tipos de datos utilizados
– Representación de los recursos en la MIB
– Lenguaje utilizado, ASN.1 (Abstract Syntax Notation One)
• SMI evita tipo de datos de complejos para simplificar tareas de

implementación
• MIB almacenan sólo tipos de datos simples:

– Escalares
– Arrays de dos dimensiones de escalares, tablas
ASN.1 (Abstract Syntax Notation One)
• Lenguaje formal aprobado y estandarizado por el ICCITT y la

ISO
• Ideal para describir y definir información estructurada
• Utilizado en la especificación de protocolos de comunicación
• ASN.1 es importante por:
– Utilizado para definir sintaxis abstractas en el manejo de datos
– Utilizado para definir la estructura para aplicaciones y
representaciones de PDUs (Protocol Data Units)
– Definición de MIBs
• SNMP utiliza un subconjunto de ASN.1 (SMI)

Reglas léxicas o sintaxis
• Los espacios múltiples y líneas en blanco se consideran como un

espacio en blanco
• Los comentarios son delimitados con un par de guiones (--) al
principio y al final
• Los identificadores , nombres de tipos y nombres de módulos
pueden contener letras mayúsculas, minúsculas, dígitos y
guiones
• Un identificador comienza con una letra minúscula
• Una referencia de tipo o nombre de módulo comienza con una
letra mayúscula

Tipos de objetos
• La estructura y los objetos de una MIB se definen utilizando un

subconjunto de los tipos de datos de ASN.1
• Dos tipos de datos

– Tipos universales. De uso general y sólo se usa un subconjunto de
los definidos en ASN.1
– Tipos aplicación. Tipos de datos relevantes a una aplicación
particular. Las MIB pueden utilizar los tipos de datos definidos en
algunas RFCs. Los tipos de datos definidos en la RFC1155 es
utilizada por casi todas las MIBs

Tipos universales
• Integer: Entero de 32 bits

• Octet String: Secuencia de octetos, c/u puede tomar un valor en el
rango de 0..255
• Null: Valor sin significado, para un campo de datos que no es
utilizado
• Object Identifier: Secuencia de enteros que identifica un objeto
dentro de la MIB
• Sequence, Sequence Of: Utilizado para construir tablas

Tipos aplicación
• NetworkAddress: Permite la selección de un formato de dirección

entre un cierto número de familias de protocolos
• IpAddress: Dirección de 32 bits en formato IP
• Counter: Entero no negativo de 32 bits
• Gauge: Entero no negativo de 32 bits que puede ser incrementado o
decrementado, quedándose fijo al alcanzar el valor máximo
• TimeTicks: Entero no negativo que cuenta el tiempo en centésimas de
segundo
• Opaque: String de octetos que almacenan datos arbitrarios

Definición de MIBs
RFC1213-MIB DEFINITIONS ::= BEGIN

nombre_mib DEFINITIONS ::= BEGIN
-- Comentarios de la MIB IMPORTS
IMPORTS mgmt, NetworkAddress, IpAddress,
Counter, Gauge, TimeTicks
objetos o definiciones FROM modulo
FROM RFC1155-SMI
OBJECT-TYPE
-- definiciones de objetos
FROM RFC-1212
END
-- definiciones de objetos
END

Definición de objetos
• Syntax: Tipo de dato de la variable (entero, string,...)

• Access: Tipo de acceso a la variable (lectura, escritura,...)
• Status: Define si la variable es obligatoria, opcional u obsoleta
• Description: información sobre el objeto
sysLocation OBJECT-TYPE
SYNTAX DisplayString(Size(0..255))
ACCESS read-write
STATUS mandatory
DESCRIPTION “Ubicación física del recurso”
::=system {6}
• Para definir las tablas se utilizan los tipos Sequence/Sequence of

SYNTAX ACCESS
– read-only
– INTEGER
– read-write
– OCTET STRING
– write-only
– OBJECT IDENTIFIER
– not-accesible
– IpAddress
– Integer
– Counter STATUS
– Counter – mandatory
– Gauge – optional
– TimeTicks – obsolete
– New Type
DESCRIPTION
– “”

Estructura de la MIB
• Definida con la notación ASN.1
• ISO y CCITT establecieron un árbol de nombres para asignar
identificadores únicos a todos los objetos relacionados con los
estándares de comunicación
• Ramificación de nodos de forma jerárquica hasta llegar a los
objetos
• Identificador de Objeto (OID): Secuencia de números enteros
que encontramos al ir desde la raíz del árbol hasta el objeto.
Cada secuencia tiene asociado un nombre, pero es sólo
informativo
– SysUpTime 1.3.6.1.2.1.1.3
• Para acceder a un objeto simple se utiliza la instancia ‘0’. Para
obtener el valor de sysUpTime, la ruta final es 1.3.6.1.2.1.1.3.0

RFC1155-MIB

Descripción de nodos
• iso: nodo raíz, administrado por la ISO

• org: subárbol exclusivos de organizaciones. Posee el nodo dod
(Departament of Defense)
• internet: nodo para la comunidad internet. Administrado por
IAB. Define cuatro sub-nodos:
– directory: reservado para uso futuro con el directorio OSI
– mgmt: objetos definidos en los documentos aprobados por la IAB
– experimental: objetos utilizados en los experimentos realizados en
internet
– private: de este nodo cuelga el nodo enterprises. Utilizado para
permitir a los fabricantes gestionar sus dispositivos. De aquí parten
las MIBs de los fabricantes. El identificador es asignado por el
IANA (Internet Assigned Numbers Authority).

Nodo MIB-2
• Bajo el nodo mgmt se encuentra el nodo mib-2

• Dedicado a la gestión de redes basadas en TCP/IP
– system: información general acerca del sistema
– interfaces: información genérica acerca de las interfaces de red, así
como la configuración y estadísticas de eventos ocurridos
– at (address translation): tabla de mapeo desde direcciones de red
(IP) hasta direcciones físicas (MAC) de la interface
– ip: información sobre implementación y operación del protocolo IP
– icmp: información sobre implementación y operación del
protocolo ICMP
– tcp: información sobre implementación y operación del protocolo
TCP

Nodo MIB-2
– udp: información sobre implementación y operación del protocolo

UDP
– egp: información sobre implementación y operación del protocolo
EGP
– transmission: información acerca de los esquemas de transmisión y
protocolos de acceso a cada interface
– snmp: información sobre implementación y operación del
protocolo SNMP
• La información contenida en cada nodo es referida solamente al

sistema donde esté la MIB

Nodo MIB-2
• MIB-2 soporta supervisión y gestión de red desde la capa de

transporte hacia abajo, manejando información acerca de cómo
se establecen las conexiones, como se encaminan los paquetes,
etc
• Para gestionar recursos tales como servidores de correo e

impresoras, la MIB ha de ser mejorada
• La estructura del árbol ISO/CCITT permite definir otras MIBs

para aplicaciones específicas y para productos de fabricantes
específicos

SNMPv1
• Los agentes tienen que ser capaces de controlar el uso de su

MIB por parte de los managers
• Aspectos relacionados con este control:

– Autentificación: Limitar el acceso a la MIB
– Políticas de acceso: Privilegios de acceso diferentes
– Servicio de proxy: Política de acceso y autentificación de
recursos no SNMP en el agente proxy
• RFC 1157, SNMPv1 sólo proporciona una capacidad limitada y

primitiva para la seguridad basada en el concepto de
COMUNIDAD
Comunidad
• Concepto local y definido en el dispositivo gestionado

• Relacionado con la seguridad:
– autentificación, control de acceso y características proxy
• Relación entre agente y conjunto de managers
• Múltiples comunidades en sólo agente
• Diferentes agentes pueden utilizar el mismo nombre de
comunidad
• Conocimiento del manager del nombre de las comunidades
• Utilización del nombre de la comunidad en las operaciones
realizadas

Servicio de autentificación
• Autentificación trivial
• Nombre de comunidad actúa como clave
• Mensaje auténtico cuando el manager conoce la clave
• Esquema vulnerable, no se utiliza encriptación
• Suplantar managers verdaderos

Política de acceso
• Acceso limitado a la MIB definiendo una comunidad
• Diferentes accesos utilizando mas de una comunidad

– Vista MIB SNMP: Subconjunto de objetos de la MIB
Diferentes vistas para una comunidad
– Modo de acceso: Lectura / Lectura-Escritura
Cada comunidad Æ modo de acceso
• Perfil de comunidad SNMP: Combinación de Vista MIB y modo de

acceso
• Política de acceso SNMP: Combinación de comunidad y perfil de
comunidad

Servicio de proxy
• Para cada dispositivo representado se mantiene una política de

acceso SNMP
– Comunidad y perfil de comunidad
• Proxy conoce la Vista MIB y el modo de acceso a la MIB

Especificación del protocolo
• Protocolo simple de gestión basado en el modelo de

manager/agente
• SNMPv1 utiliza un conjunto limitado de operaciones para la
gestión
• Manager:
– GetRequest
– GetNextRequest
– SetRequest
• Agente:
– GetResponse
– Trap

Formato de los mensajes
• Cada mensaje SNMP está compuesto por tres campos

fundamentales:
– Versión: Versión del protocolo SNMP
– Comunidad
– PDU Snmp: Operaciones específicas del protocolo
• Longitud variable
• Limitado por el tamaño máximo de mensajes UDP, ej: 65507

octetos


Variable bindings
• Operaciones SNMP involucran un acceso a un objeto

• Variable-bindings: Secuencia de instancias a objetos junto con
sus respectivos valores
• Varias operaciones del mismo tipo en un sólo mensaje
• Reducción de la comunicación, un mensaje para:
– Manager: Solicita/Modifica valores de un grupo objetos
– Agente: Responde con los valores solicitados
• PDU Gets
– Instancia de objeto
– Valor = null

PDU GetRequest
request- 0 0
PDU type variable-bindings
id
• PDU type: Tipo de PDU

• Request-id (identificador de petición):
– Cada petición hacia un mismo agente queda unívocamente
identificada
– Detección de paquetes duplicados
• Variable bindings: Lista de instancia a objetos cuyos valores
quieren ser obtenidos
• Obtención del valor de los objetos de la lista

PDU GetRequest
Manager Agente
MIB
GetRequest
GetResponse
• Repuesta del agente con GetResponse

• Es atómica: obtención de todos los valores o ninguno
• Posibles errores:
– Identificador de objeto inválido
– Mensaje GetResponse demasiado grande

PDU GetNextRequest
• Acceso secuencial a variables
• Retorna la instancia del objeto y su valor correspondiente al
siguiente elemento en la MIB
– getNext (1.3.6.1.2.1.1.3.0) // sysUpTime
– Response (1.3.6.1.2.1.1.4.0, “Gestor”) // sysContact
• Permite descubrir la estructura de una MIB dinámicamente
• Permite generar peticiones consecutivas
• Utilizado para acceder a tablas cuando las entradas son
desconocida
Manager Agente
• Formato y propiedades GetRequest
MIB
GetNextRequest
GetResponse

PDU SetRequest
• Modifica valor de objeto (permisos)

• Variable-bindings: instancia de objetos y valores
• Si una variable no es modificada, no se retorna el resto de
valores, y éstos no son actualizados en la MIB
• Posibles errores:
– Iguales GetRequest
– Valor inválido (inconsitencia entre variables y valores)
• Permite borrar filas de tablas
Manager Agente
• Formato y propiedades GetRequest
MIB
• Invocación de acciones SetRequest
GetResponse

PDU GetResponse
request- error- error-
id status index
• Respuesta a las PDU Get y Set

• Usa el mismo valor request-id utilizado en la operación de
solicitud
• Error-status: tipo de error
– noSuchName: identificador inválido
– tooBig: PDU excede del tamaño limitado
– badValue: inconsistencia objeto/valor
– genErr: Otras causas de error
• Error-index: número de la variable que ha producido el error
– Set (1.3.6.1.2.1.1.5.0, “DEBIAN3”, 1.3.6.1.2.1.1.15.0, “host”)
– Response (error-status = noSuchName; error-index = 2)

PDU Trap
agent- generic- specific- time- variable-
PDU type enterprise
addr trap trap stamp bindings
• Emitida por un agente

• Notificación asíncrona de un agente
• No espera respuesta del manager
• Formato de PDU diferente
• 7 eventos posibles predefinidos (generic-trap)
Manager Agente
Trap

PDU Trap
• Enterprise: identifica el recurso de red que genera el trap
• Agent-addr: dirección IP del recurso que generó el trap
• Generic-trap: tipos de eventos predefinidos
• Specific-trap: código que identifica específicamente el trap
• Time-stamp: tiempo transcurrido entre entre la última

inicialización del recurso y el trap
• Variable-bindings: información específica relacionada con el

trap

PDU Trap
• Valores del campo generic-trap:
– coldStart: sistema reinicializado tal que la configuración del agente

o del protocolo pueden ser alterados
– warmStart: sistema reinicializado tal que la configuración del
agente o del protocolo NO pueden ser alterados
– linkDown: fallo en un enlace de comunicación
– linkUp: enlace de comunicación reestablecido
– authenticationFailure: mensaje con autentificación errónea
– egpNeighborLoss: relación de protocolo EGP inexistente
– enterpriseSpecific: evento específico indicado en el campo
specific-trap

Limitaciones de SNMPv1
• No ideal para solicitar/recibir grandes cantidades de datos

• No certeza que el manager ha recibido un trap
• Autentificación trivial, no encriptación
• Modelo MIB limitada, no soporta sofisticadas consultas
• No soporta comunicación manager a manager
• Limitados códigos de error
• Limitados tipos de datos

RMON (Remote Network Monitoring)
• Obtener información de tráfico global de la red

• Principalmente define una MIB de supervisión remota (RFC
1757)
• Monitor en modo promiscuo
• Dispositivo dedicado o una función disponible en un sistema
• Características que soportan control desde el manager:
– Configuración: forma y tipos de datos a capturar
– Invocación de acciones: cuando cambia el estado de una variable
• Generan información como estadísticas

MIB RMON
• Dividida en nueve grupos funcionales

• Cada grupo posee:
– Tabla/s de control: Parámetros que describen los datos
– Tabla/s de datos: Almacenamiento de datos
• Configuración: activación de parámetros apropiados para
conseguir datos deseados (manager)
– Añadiendo un fila a la tabla de control
– Modificando fila existente
• Datos capturados almacenados en filas
• Relación fila de control/fila de datos
• Permite acceso concurrente de varios managers

Grupos MIB RMON
• Statistics: estadísticas sobre la subred supervisada, paquetes

perdidos, colisiones, errores, distribución tamaño de paquetes
• History: estadísticas periódicas (muestras) de la información del

grupo statistics
• Alarm: fija intervalo de muestra y umbrales sobre parámetro

referentes a la red. Ej: No superar 500 CRC errores en 5 min.
• Host: estadísticas sobre cada host de la subred
• hostTopN: Estadísticas sobre hosts que encabezan una lista ordenada

en base a un parámetro común
Grupos MIB RMON
• Matrix: información sobre tráfico entre pares de hosts
• Filter: permite al monitor observar cierto tipo de paquetes,

aquellos que superan el filtro
• Packet-capture: esquema de almacenamiento para capturar

paquetes utilizando el filter
• Event: almacena eventos generados por el agente RMON
• tokenRing: estadísticas e información de configuración de

subredes token ring

SNMPv2. Historia
• SNMPv1 no proporciona seguridad

– Comunidad en texto plano
– No autentificación del emisor
• Soluciones propuestas en jul’92:
– Secure SNMP:
• Seguridad basada en party: entidad única, autentificación,
privacidad, vista MIB única
• No mejora rendimiento y funcionalidad
– SMP (Simple Management Protocol)
• Gestión de recursos arbitrarios (sistema, manager to manager)
• Incorpora seguridad S-SNMP
• Tamaño pequeño y eficiente

SNMPv2. Historia
• SMP como base para el desarrollo de SNMPv2

• Mar’93 publicación de estándares propuestos:
– Seguridad basada en parties
– Mejoras en la funcionalidad
• 1995, el IETF ordenó una revisión:
– Modelo basado en parties era muy complejo (Seguridad eliminada)
– Modificaciones leves de las otras características
– Nuevo estándar propuesto (RFC 1901-1908)
• SNMPv2C o Community string-based SNMPv2
• Nuevos elementos de protocolo y estructura MIB
• Mantiene modelo administrativo SNMPv1

Caracteríticas SNMPv2
• Modificaciones en la estructura de información de gestión,

SMIv2
– Nuevos tipos de datos, creación y borrado de filas en tablas,...
• Permite comunicación manager – manager
• Implementa dos nueva operaciones de protocolo

– GetBulkRequest. Solicitar grandes volúmenes de datos
– InformRequest. Información de manager a manager

SMIv2
• Basada en la SMI para SNMPv1
• Especificación y documentación mas elaborada de los objetos

gestionados
• Dividida en 4 partes:
– Definiciones de objetos
– Tablas: Facilita creación, borrado y acceso a filas de tablas
– Definición de notificaciones: se utiliza la macro NOTIFICATION-
TYPE para definir la información enviada cuando ocurre un evento
– Módulos de información: especifica grupo de definiciones
relacionadas (Ej, revisión, última actualización, organización,...)

SYNTAX MAX-ACCESS
– INTEGER – not-accesible
– OCTET STRING – read-write
– OBJECT IDENTIFIER – read-only
– BITS – read-create (read, write, create)
– IpAddress
– Integer32
– Unsigned32 STATUS
– Counter32
– current
– Counter64
– obsolete
– Gauge32
– deprecated
– TimeTicks
DESCRIPTION
– “”

Operaciones de SNMPv2
• Proporciona tres tipos de acceso a la información de gestión:
– Manager – Agente: Peticiones del manager hacia el agente
– Trap: Notificación de evento especial por parte del agente hacia el

manager
– Manager-Manager: Peticiones de un manager a otro manager.

Nuevo tipo de acceso

• Cada mensaje SNMP está compuesto por tres campos

fundamentales:
– Versión: Versión del protocolo SNMP
– Comunidad
– PDU Snmp: Operaciones específicas del protocolo
• Tipos de PDU:
– GetRequest
– GetNextRequest
– SetRequest
– SNMPv2 Trap
– InformRequest
– GetBulkRequest
– Response

Version Comunidad PDU SNMP
Mensaje SNMP
request- 0 0
id
PDUs GetRequest, GetNextRequest, SetRequest SNMPv2 Trap, InformRequest
request- error- error-

id status index
PDU Response
request- non- max-

id repeaters repetitions
PDU GetBulkRequest
name 1 valor 1 name 2 valor 2 ... name n valor n
Variable-bindings

GetRequest
• Idéntica en formato y semántica a SNMPv1

• No es atómica
• Response puede retornar valores de no todos los objetos requeridos
• Maneja dos excepciones:
– NoSuchObject
– NoSuchInstance
• La excepción se devuelve en el valor del objeto
• Se mejora el procesado del response por parte del manager
Get (1.3.6.1.2.1.1.5.0, 1.3.6.1.2.1.1.325.0)
Response (error-status Æ noError, 1.3.6.1.2.1.1.5.0 Æ DEBIAN,
1.3.6.1.2.1.1.325.0 Æ noSuchObject)

GetNextRequest

• No es atómica
• Response puede retornar valores de no todos los objetos requeridos
• Maneja una excepción:
– endofMibView
• La excepción se devuelve en el valor del objeto
GetNext (1.4.0)
Response (error-status Æ noError, 1.4.0 Æ endofMibView)

GetBulkRequest
request- non- max-
id repeaters repetitions
• Minimiza el nº de intercambios requeridos al solicitar muchos datos

• Permite al manager pedir respuestas tan largas como sea posible
• Principio GetNext: siguiente instancia del objeto pasado
• GetBulk puede especificar múltiples sucesores
• Dos parámetros:
– Non-repeaters (n): los primeros n elementos de la lista se tratan como una
operación getNext
– Max-repetitions (m): a los restantes elementos de la lista se les realiza m
getNext sucesivos

GetBulkRequest
GetBulk (non-repeaters=1, max-repetitions=2,

1.3.6.1.2.1.1.2.0, 1.3.6.1.2.1.1.4.0 )
Response (1.3.6.1.2.1.1.3.0 Æ 0:10:25,
1.3.6.1.2.1.1.5.0 Æ DEBIAN,
1.3.6.1.2.1.1.6.0 Æ Laboratorio)
SetRequest
• Variables procesadas en dos fases:
– Se valida cada par de la lista (objeto/valor)
– Si todas son validadas, se realiza el set para todas
• Es atómica
• Códigos de error de validación

SNMPv2 Trap
• Generada y transmitida por un agente cuando ocurre un evento

• Formato diferente a SNMPv1
• Mismo formato que otras PDU, excepto GetBulk y Response
• Facilita tarea de procesado del receptor
• No provoca ninguna respuesta
• Contiene en la lista los siguientes pares objetos/valores:
– SysUpTime.0
– SnmpTrapOID.0: Identificador de la notificación enviada
– Si hay objetos definidos como NOTIFICATION-TYPE se pasan
en la lista
– Variables adicionales pueden ser incluidas

Inform Request
• Generada y recibida por un manager

• Notificar información
• Mismo formato que SNMPv2 Trap
– sysUpTime.0
– snmpTrapOID.0
• Response con los mismos datos recibidos
• Posible error: tooBig
Manager_1 Manager_2
MIB
Inform
Response

Protocolo de Transporte
• SNMPv1
– UDP
• SNMPv2
– UDP
– CLNS (OSI)
– IPX (Novell)
– DDP (Appletalk)

Coexistencia con SNMPv1
• Pautas para conseguir la coexistencia:

– Información de gestión
– Operaciones de protocolo
• Información de gestión
– SMIv2 es un superconjunto de SMIv1
– Módulos SMIv1 pueden ser utilizados por entidades SNMPv2
– Un agente SNMPv1 puede mantener una MIB y estar presente en
un entorno SNMPv2 - SNMPv1

Operaciones de protocolo
• SNMPv2 es similar a SNMPv1
• Mismo formatos PDUs y mismo modelo administrativo
• Cambios importantes:
– Ampliación de PDUs: GetBulkRequest, InformRequest
– Operaciones Get proporcionan resultados parciales (no atómica)
• La coexistencia se basa en 2 aspectos:

– Uso de agentes proxy
– Manager dual

Agente proxy
• Acceder a agentes SNMPv1 mediante un agente proxy
• Agente proxy:
– Entidad SNMPv2 implementada y configurada para actuar como
proxy de otros agentes SNMPv1
– Conversión de protocolos entre SNMPv2 y SNMPv1
• Dos tipos de conversiones
– SNMPv2 Æ SNMPv1
• GetRequest, GetNextRequest y SetRequest pasadas sin cambios
• GetBulkRequest se convierte a GetNextRequest
– SNMPv1 Æ SNMPv2
• GetResponse sin cambios (valores de error-status reconocidos por
SNMPv2)
• Trap es convertida a SNMPv2-Trap
– Añade sysUpTime.0 y snmpTrapOID.0

Agente proxy
Entorno SNMPv2 Entorno SNMPv1
GetRequest GetRequest
GetNextRequest GetNextRequest
SetRequest SetRequest
GetBulkRequest GetNextRequest
Agente Agente
Manager
y proxy SNMPv1
SNMPv2
SNMPv2
Response GetResponse
SNMPv2-Trap Trap

Manager dual
• Manager que implementa SNMPv2 y SNMPv1
• Base de datos: Agente / protocolo utilizado
• Capacidad dual visible sólo en el nivel SNMPv2/SNMPv1
• Comunicación con agente SNMPv1, operaciones como agente proxy
Manager
SNMPv2 Inf
orm
Re
que
Inf st,
orm Re
Re spo
que nse
st,
R esp GetRequest, GetNextRequest,
on SetRequest
se Manager Agente
Dual SNMPv1
se (v1, v2) GetResponse, Trap
spon
Re
ra p, est
,
2 -T qu
e est
M Pv e xtR equ
SN GetN , SetR
, t
q uest ques
e e
Agente
GetR BulkR
SNMPv2 t
Ge

MIB SNMPv2
• Añade nuevos objetos que describe el comportamiento de una

entidad SNMPv2
• Tres grupos:
– Grupo system: expansión del grupo system de MIB-II. Nuevos
objetos para descripción de recursos controlados por el agente
– Grupo snmp: Refinamiento del grupo snmp de MIB-II.

Información de tráfico relacionada con operaciones SNMPv2
– Grupo snmpMIBObjects: Control de los objetos MIB relacionados

con traps y operación set

CMIP (Common Management Information Protocol)
• Ventajas
– Sistema de administración mas eficiente
– Dispositivos de administración de seguridad
– Modelo basado en eventos (SNMP consultas)
– Confirmación de eventos
– Basado en objetos (SNMP escalares)
• Desventajas
– Consume muchos recursos
– Difícil de programar
– Agentes complicados
CMIP SNMP
Precio Alto Bajo
Aceptación mercado Bajo Alto

Gestion de Red

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Gestion de Red

Hochgeladen von

Copyright:

Verfügbare Formate

Introducción

• Actualmente las redes de las organizaciones tienden a ser:

• Administración compleja por un única persona

• Surge la necesidad de utilizar protocolos de administración que

Protocolos y Servicios. Gestión de Red 1

• Gestión de Red: Es el control y supervisión de una red compleja

• La ISO (International Organization for Standardization) define

Protocolos y Servicios. Gestión de Red 2

• En los años 70, se utilizaba como gestión de red la herramienta

Protocolos y Servicios. Gestión de Red 3

• Si no hay respuesta Æ estación B caída

• Necesario un protocolo de administración

Protocolos y Servicios. Gestión de Red 4

• En los años 80, se desarrollan dos estándares de gestión de red:

Protocolos y Servicios. Gestión de Red 5

Protocolos y Servicios. Gestión de Red 6

• Manager o Estación servidora

Protocolos y Servicios. Gestión de Red 7

• Base de datos de información de gestión, MIB (Management

Protocolos y Servicios. Gestión de Red 8

• Protocolo de gestión de red

Protocolos y Servicios. Gestión de Red 9

• SNMP, protocolo a nivel de aplicación que forma parte de la

• El protocolo de transporte utilizado es el UDP

• Managers y agentes utilizan SNMP, UDP, IP y protocolo de red

Protocolos y Servicios. Gestión de Red 10

• La estación manager posee un proceso para controlar el acceso a

• El agente posee un proceso que controla el acceso a la MIB

• Todos los mensajes son enviados y recibidos por el puerto UDP

Protocolos y Servicios. Gestión de Red 11

Protocolos y Servicios. Gestión de Red 12

• SNMP requiere que tanto manager como agente soporten UDP e

Protocolos y Servicios. Gestión de Red 13

Protocolos y Servicios. Gestión de Red 14

• Cualquier sistema de gestión de red posee una base de datos que

• Los datos contenidos en la MIB pueden ser leídos y modificados

Protocolos y Servicios. Gestión de Red 15

• SMI evita tipo de datos de complejos para simplificar tareas de

• MIB almacenan sólo tipos de datos simples:

• Lenguaje formal aprobado y estandarizado por el ICCITT y la

Protocolos y Servicios. Gestión de Red 17

• Los espacios múltiples y líneas en blanco se consideran como un

Protocolos y Servicios. Gestión de Red 18

• La estructura y los objetos de una MIB se definen utilizando un

• Dos tipos de datos

Protocolos y Servicios. Gestión de Red 19

• Integer: Entero de 32 bits

Protocolos y Servicios. Gestión de Red 20

• NetworkAddress: Permite la selección de un formato de dirección

Protocolos y Servicios. Gestión de Red 21

RFC1213-MIB DEFINITIONS ::= BEGIN

Protocolos y Servicios. Gestión de Red 22

• Syntax: Tipo de dato de la variable (entero, string,...)

• Para definir las tablas se utilizan los tipos Sequence/Sequence of

Protocolos y Servicios. Gestión de Red 23

Protocolos y Servicios. Gestión de Red 24

Protocolos y Servicios. Gestión de Red 25

Protocolos y Servicios. Gestión de Red 26

• iso: nodo raíz, administrado por la ISO

Protocolos y Servicios. Gestión de Red 27

• Bajo el nodo mgmt se encuentra el nodo mib-2

Protocolos y Servicios. Gestión de Red 28

– udp: información sobre implementación y operación del protocolo

• La información contenida en cada nodo es referida solamente al