Gestión de Redes: Protocolos de Mantenimiento

GESTIÓN DE REDES: PROTOCOLOS DE MANTENIMIENTO

Dr. Víctor J. Sosa [email protected]

Introducción Elementos del modelo de gestión Simple Network Management

Protocol (SNMP) Estructura de la información de

gestión (SMI) Management Information Base

(MIB-II) SNMPv2 y SNMPv3

Gestión de Redes TCP/IP Al inicio de TCP/IP no se pensó en incluir soporte para la

gestión de redes Eran los expertos en protocolos quienes solucionaban los

problemas de gestión La única “herramienta” disponible era ICMP, sobre todo con

los mensajes de ECHO para tests de alcanzabilidad, y los de timestamp, para obtener información acerca de los retardos en la red

Programas PING (Packet Internet Groper) y traceroute Finales años 8Os: Internet crece explosivamente

Se empezó a pensar en una capacidad de gestión de red más potente

Protocolo estándar, con mucha más funcionalidad que PING, fácil de aprender y utilizar por muchas personas responsables de la gestión de red

Gestión de Redes TCP/IP

El IAB (Internet Architecture Board) propuso dos estrategias (1988): A corto plazo, definir el protocolo SNMP (inicialmente era

SGMP:Simple Gateway Management Protocol) A largo plazo, una migración hacia la gestión OSI (protocolo CMOT:

CMIP –Common Management Information Protocol– sobre TCP/IP) Premisa:

el impacto de añadir gestión de red a los nodos debía ser mínimo Se pensaba que las instalaciones acabarían evolucionando a

protocolos basados en OSI Para facilitar la migración, se pensó que ambos empleasen la misma

base de datos de objetos gestionados Pero eso se vio que era imposible, pues la gestión OSI emplea BD

orientadas a objetos y se pretendía mantener el SNMP tan sencillo como fuese posible

SNMP y CMOT* evolucionaron en paralelo*Common Management Information Protocol

Gestión de Redes TCP/IP

Situación actual: SNMP es el estándar de facto para la gestión de redes,

al igual que TCP/IP lo es para la interconexión de redes No es probable que OSI y su sistema de gestión de red

reemplacen al modelo TCP/IP+SNMP Una vez se extiende el uso de SNMP se proponen

diversas ampliaciones RMON: Remote MONitor Monitorización global de una subred, no sólo de sus

dispositivos Extensiones a la MIB de SNMP, tanto estándar como

privadas Versiones 2 y 3 de SNMP para resolver deficiencias

Principales RFCs relacionados con SNMPv1



Elementos del modelo de gestión

Estación de gestión: Interfaz entre el gestor humano y el SGR Debe incluir:

Interfaz (gráfico) para monitorizar y controlar la red

Aplicaciones de gestión para análisis de datos, recuperación de fallos, etc

Capacidad de traducir los requerimientos del gestor en órdenes concretas de monitorización y control de los elementos remotos de la red

Base de datos de información extraída de las MIBs de todas las entidades gestionadas en la red

SNM

P


Agente: Software que proporciona acceso a los datos

de gestión de un dispositivo en particular Hosts, puentes, routers, switches, hubs, …

SNMP soporta dos tipos de transacciones: Petición (POLL) por parte del gestor, y

respuesta por parte de agente Notificaciones no solicitadas (TRAPS) desde

el agente al gestor


Base de información de gestión (MIB): Conjunto de objetos (variables) que representan

los recursos de la red que se pueden gestionar (monitorizar y controlar) Monitorización: lectura del valor de los objetos de la

MIB Control: modificación del valor de ciertas variables

Los objetos se almacenan en los dispositivos gestionados

Los objetos están estandarizados para cada clase concreta Ejemplo: Hay los mismos tipos de objetos para

gestionar varios puentes


Protocolo de gestión de red: La estación de gestión y los agentes se

comunican empleando el protocolo de gestión de red En redes TCP/IP ese protocolo es SNMP

SNMP incluye las siguientes capacidades: GET: permite a la estación de gestión obtener

(leer) el valor de los objetos del agente SET: permite a la estación de gestión modificar

(escribir) el valor de los objetos del agente TRAP: permite al agente notificar a la estación de

gestión la ocurrencia de eventos significativos


SNMP es un protocolo del nivel de aplicación Funciona sobre UDP => no es orientado a la conexión

Cada intercambio es una transacción separada entre el gestor y los agentes

Tanto el gestor como los agentes deben implementar IP, UDP y SNMP, sobre los protocolos específicos de acceso a la red

Proceso gestor: Actúa como “cliente” SNMP, cuando envía peticiones SNMP Escucha los traps en el puerto 162

Proceso agente: debe interpretar los mensajes SNMP y controlar la MIB del agente Actúa como “servidor” SNMP, escuchando las peticiones del

gestor en el puerto 161 Envía los traps al gestor


SNMP: Tipos de mensajes

SNMP: Tipos de mensajes

GetRequest: el gestor pide al agente el valor de un dato GetNextRequest es similar, permitiendo extraer datos de una tabla

SetRequest: el gestor pide al agente que modifique los valores de las variables que especifique El agente los modificará todos o ninguno

El agente responde a estas peticiones mediante GetResponse, conteniendo : Los datos pedidos o un código de error, para las operaciones Get Respuesta idéntica a la petición (tras cambiar los valores) o un

código de error para la operación Set El agente emite un mensaje Trap en respuesta a un evento

que afecte a la MIB o a los recursos gestionados Puede incluir en el mensaje los nombres y valores de ciertos

objetos como información adicional sobre el evento El gestor NO confirma la recepción de un Trap al agente

SNMP: Sondeo dirigido por traps (trap-directed polling)

El protocolo SNMP se basa en el sondeo o polling: El gestor sondea periódicamente a los agentes para ver si

hay algo que necesite atención Si una estación de gestión controla un gran número de

agentes, y cada uno tiene un gran número de objetos, este mecanismo se vuelve poco eficiente

Por ello, se emplea la técnica del sondeo dirigido por trap: Cuando llega un trap desde un agente, el gestor centra su

atención en ese dispositivo Problema: Los traps no se confirman y el transporte es

‘no fiable’ (UDP) Por tanto, el gestor no se puede basar exclusivamente en la

recepción de traps para obtener información de los dispositivos

SNMP: Sondeo dirigido por traps (trap-directed polling)

Solución: Sondeo al inicializar el sistema y a intervalos poco regulares

(horas) Se pide alguna información clave, y algunas características

básicas de funcionamiento a todos los agentes que conozca el gestor

El resto del tiempo, el gestor no sondea, y es el agente quien le avisa mediante un trap en caso de que ocurra algún evento anormal Ejemplos: Caída y reinicialización del agente, caída de un

enlace ... Tras recibir el trap el gestor puede obtener más información

del agente que envió el trap, o de otros agentes próximos a él para obtener más información y diagnosticar el problema

Ahorro de capacidad de la red y de tiempo de proceso de los agentes y gestores

SNMP: Proxies SNMP

SNMP: Detalles del protocolo

SNMP se especifica en el RFC 1157 (Mayo 1990)

SNMP permite leer y escribir objetos escalares en la MIB de un agente Mediante traps, un agente puede enviar el valor

de un objeto escalar al gestor Cada agente es responsable de su MIB local

Controla el uso que hacen de ella las estaciones gestoras

Control de acceso a la MIB de un agente: concepto de comunidad

SNMP: Comunidades

Comunidad: relación entre un agente SNMP y un conjunto de estaciones de gestión SNMP, que define unas características de autentificación y control de acceso El agente establece una comunidad para cada

combinación deseada de autentificación y control de acceso, y a cada comunidad se le da un nombre único dentro del agente (community name)

Las estaciones de gestión pertenecientes a una comunidad deben emplear ese nombre en todas las operaciones get y set

El agente puede establecer cualquier número de comunidades

Una estación de gestión puede pertenecer a varias comunidades

Una estación debe almacenar los nombres de comunidad asociados a cada agente

SNMP Comunidades

Mediante el uso de comunidades, un agente puede limitar el acceso a su MIB en dos formas:

Vista de la MIB: subconjunto de los objetos de la MIB Modo de acceso: READ-ONLY o READ-WRITE

La combinación de una vista de la MIB y un modo de acceso se denomina perfil de comunidad SNMP (SNMP community profile)

A cada comunidad se le asigna un perfil, denominándose a esta asociación política de acceso SNMP (SNMP access policy)

Cada paquete SNMP contiene el nombre de la comunidad, sin codificar

El agente sólo atiende la petición si el nombre de la comunidad es correcto para el tipo de acceso solicitado

Se trata de un esquema de seguridad muy limitado Por ello, en muchos agentes no se implementan las peticiones de

escritura en la MIB (mensajes SetRequest)

SNMP Comunidades

SNMP Comunidades

SNMP: Formato de los paquetes

Todos los paquetes contienen dos campos: El número de versión de SNMP Un nombre de comunidad El resto del paquete depende del tipo del

mismo, y se denomina PDU (Protocol Data Unit) de SNMP

Mensaje SNMP

Versión Comunidad PDU de SNMP

SNMP: Formato de los paquetes

SNMP: Formato de los paquetes Request ID: identificador único por cada petición Código de error: indica que ha ocurrido una excepción al

procesar una petición Posibles valores: noError (0), tooBig(1), noSuchName(2),

badValue(3), readOnly(4), genErr(5) Índice de error: indica qué variable de la lista causó la

excepción, cuando el código de error no es 0 Asignación de variables: lista de nombres de variables y sus

correspondientes valores Los nombres se especifican como identificadores de objetos (OIDs) En GetRequest, los valores son null

Empresa (enterprise): objeto que genera el trap (valor de sysObjectID)

Dirección de agente: dirección IP del agente que genera el trap

Trap genérica: tipo de trap genérico Trap específico: código de trap específico Time stamp: tiempo transcurrido entre la última

reinicialización de la entidad y la generación del trap (valor de sysUpTime)

SNMP: Traps genéricas SNMP

coldStart (0): el emisor se ha reinicializado, y puede haberse alterado la configuración del agente o la implementación del protocolo

warmStart (1): reinicialización del emisor, sin cambios en configuraciones ni en implementaciones

linkDown (2): fallo en algún enlace de comunicación del agente

linkUp (3): un enlace de comunicación del agente se ha restablecido

En el campo de asignación de variables, se especifica cuál es el enlace que ha caído/restablecido

authenticationFailure (4): la entidad emisora ha recibido un mensaje en el que falla la autentificación

egpNeighborLoss(5): desconexión de un vecino EGP enterprise-Specific(6): definidas por empresas

SNMP: Ventajas e inconvenientes de SNMP

Es un protocolo maduro, estándar de facto aceptado por la industria Está disponible en gran cantidad de productos Es fácil de implementar y requiere pocos recursos del sistema

Falta de seguridad: Cualquier estación puede resetear variables con SetRequest, por lo que

muchos fabricantes no implementan este comando No hay control de acceso: al recibir un PDU un agente no comprueba si ha

sido enviado por una estación autorizada La identificación de comunidad viaja tal cual

Mala utilización del ancho de banda: No existe la posibilidad de transferir información por bloques

Limitaciones en el mecanismo de traps: Sólo se puede informar de algunos eventos previstos No son reconocidas

No es apropiado para gestionar redes muy grandes (por el sondeo)

Estructura de la información de gestión (SMI)

La gestión en TCP/IP se basa en el manejo de una base de datos (la MIB) que contiene información sobre los objetos a gestionar

Cada recurso se representa mediante un objeto Objetos escalares y tablas bidimensionales

La MIB es un conjunto estructurado de tales objetos Estructura de árbol

Las operaciones de monitorización consultan el valor de los objetos Las operaciones de control modifican el valor de los objetos

Cada objeto de un dispositivo gestionable por SNMP debe tener un nombre único con el que se le denominará en las operaciones de gestión

El esquema de nombres debe asegurar que dos fabricantes no emplean el mismo nombre para objetos distintos

Se define mediante el SMI (Structure of Management Information)

Estructura de la información de gestión (SMI) La MIB define el objeto u objetos utilizados para

representar un recurso en concreto deben ser los mismos en cada nodo

Ejemplo: número total de conexiones activas TCP en un nodo

Conexiones abiertas = conexiones activas + conexiones pasivas

El nodo puede almacenar cualquier par de los tres valores {totales,activas, pasivas}

En la definición de la MIB se indica: Que se deben almacenar las conexiones activas y pasivas Se definen los objetos tcpActiveOpens y tcpPassiveOpens,

de tipo “counter” (entero 32 bits) Sus nombres son 1.3.6.1.2.1.6.5 y 1.3.6.1.2.1.6.6 =>

esquema común de nombrado (SMI)

SMI: Estructura

La estructura del SMI y de la MIB se definen empleando el estándar ASN.1 (Abstract Syntax Notation One) de CCITT/ISO

Los tipos de datos empleados en SNMP también se basan en los de ASN.1

ASN.1 es un lenguaje que se emplea para definir estructuras de datos y protocolos

Incluye unas reglas precisas de codificación (BER: Basic Encoding Rules)

Proviene de OSI: Grande, complejo y no muy eficiente

Ventaja: proporciona una codificación estándar en bits de cada objeto

SMI: Estructura SNMP utiliza el esquema jerárquico de nombres

desarrollado por ISO El espacio de nombres forma un árbol, con una raíz

conectada a un conjunto de nodos etiquetados Etiqueta = {breve descripción textual + entero} (ejemplo: iso(1)) Los nodos se agrupan por ramas de objetos relacionados

Identificador de objeto: nombre de un nodo Es la secuencia de enteros de las etiquetas de cada nodo, desde

la raíz hasta el nodo en cuestión El identificador es único para cada objeto La parte textual sólo se emplea por las personas, nunca se

transmite Cada nodo representa un recurso, actividad o información

relacionada

SMI: Estructura

SMI: Estructura La raíz no se etiqueta, y de ella cuelgan tres nodos:

iso(1), ccitt(2) y joint-iso-ccitt(3) Del nodo iso cuelgan nodos para distintas organizaciones

Entre ellas está el Departamento de Defensa de EE.UU. (dod(6))

Ahí hay un nodo administrado por el IAB: internet OBJECT IDENTIFIER::={iso(1) org(3) dod(6) 1}

Así, el nodo internet tiene el identificador de objeto 1.3.6.1

Todos los objetos de interés para SNMP cuelgan del nodo internet, y por tanto tienen el prefijo 1.3.6.1 en sus identificadores de objeto

SMI: Estructura

Dentro del nodo internet, el SMI define cuatro nodos: directory(1): directorio

X.500 mgmt(2): objetos

definidos en documentos aprobados por el IAB Como la mib-2 (1)

experimental(3): identificadores de objetos experimentales en Internet

private(4): identificadores de objetos definidos por empresas

SMI: Estructura

Definido por SMI(RFC 1155)

Definido en MIB-II(RFC 1213)

SMI: Estructura

Adición de nuevos objetos en las MIB: Expansión o reemplazamiento del subárbol mib-2: por

ejemplo, con una versión posterior (mib-3) o añadiendo subárboles a mib-2, como la base de monitorización remota de la red (RMON)

Construcción de una MIB experimental, para una aplicación particular

Primero se incluyen los objetos en el subárbol experimental, y cuando el IAB los aprueba, pasan al mgmt

Extensiones privadas en el subárbol private: dentro de private existe el nodo enterprises, donde se asigna una rama a cada fabricante que registra un identificador de objeto

SMI: Estructura

Cada objeto dentro de la MIB de SNMP tiene una definición formal que especifica:

El tipo de datos del objeto El rango de valores que puede tomar Su relación con otros objetos de la MIB, esto es, su

posición dentro del árbol Se emplea la sintaxis ASN.1 RFC 1155: Structure of Management

Information RFC 1212: Concise MIB Definitions

Especifican el formato que hay que seguir para definir los objetos en una MIB

SMI: Estructura

Ejemplo:tcpMaxConn OBJECT-TYPE

SYNTAX INTEGERACCESS read-onlySTATUS mandatoryDESCRIPTION

"The limit on the total number of TCP connections the entity can support. In entities where the maximum number of connections is dynamic, this object should contain the value -1.“

Tipo de datosModo de acceso a una instancia del objeto{read-only, read-write, write-only, not-accessible}

Define si el objeto ha de ser necesariamenteincluido en la implementación de la MIB{mandatory, optional, obsolete, deprecated}

Descripción del objeto(opcional, dirigida al usuario)

Posición del objeto dentro del árbol(referida al nodo “padre”)

::= { tcp 4 }

SMI: Estructura

SMI: Tipos de Datos Los tipos de datos tienen una etiqueta asociada

Etiqueta = nombre de la clase + número no negativo

Clases de tipos de datos UNIVERSAL: tipos básicos, independientes de la

aplicación APPLICATION: relevantes a una aplicación particular

Por ejemplo, SNMP CONTEXT-SPECIFIC: ídem que el anterior, pero

aplicables en un contexto limitado PRIVATE: definidos por los usuarios; no

standarizados

SMI: Tipos de datos relevantes en SNMTP

Tipos de datos universales: INTEGER (UNIVERSAL 2) OCTETSTRING (UNIVERSAL 4) NULL (UNIVERSAL 5) OBJECT IDENTIFIER (UNIVERSAL 6) SEQUENCE, SEQUENCE OF (UNIVERSAL 16)

Tipos de datos de la aplicación (RFC 1155) networkAddress (eliminado actualmente) ipAddress (OCTETSTRING de 4 bytes) counter (INTEGER) gauge (INTEGER) timeticks (INTEGER) opaque (datos arbitrarios, apenas se usa)

SMI: Tipos de datos universalesINTEGER

32 bits en complemento a 2 Se puede limitar el rango de valores Ejemplos:

cuenta INTEGER ::= 100 -- valor inicial (opcional) estado ::= INTEGER{ up(1), down(2), unknown(3)} – subtipo PacketSize ::= INTEGER {0..1023} – subtipo

OCTETSTRING Cadena de bytes Puede definirse la longitud de la cadena y un valor inicial Ejemplos:

DisplayString Sólo puede contener caracteres NVT ASCII Representación de textos

physAddress Representación de direcciones físicas

SMI: Tipos de datos universalesOBJECT IDENTIFIER Identificador de objetos

Secuencia de números que determina la posición de un objeto dentro de la estructura en árbol

Ejemplo: el identificador del objeto tcpConnTable es 1.3.6.1.2.1.6.13

SEQUENCE Lista ordenada de tipos

Similar a un registro de Pascal o a una estructura de C

SEQUENCE OF Vector unidimensional de un solo tipo

SMI: Tipos de datos de la aplicación

ipAddress Direcciones IP (32 bits) Definido como OCTETSTRING de 4 bytes:

IpAddress ::= [APPLICATION 0] -- in network-byte order IMPLICIT OCTET STRING (SIZE (4))

counter !Entero no negativo de 32 bits (máx=232 - 1)

Counter ::= [APPLICATION 1] IMPLICIT INTEGER (0..4294967295)

Se puede incrementar, pero no decrementar Cuando el contador llega al máximo, vuelve a cero

¿Cuánto vale realmente la cuenta? Aplicaciones: Número de paquetes/bytes enviados/recibidos, número de errores, …

SMI: Tipos de datos de la aplicaciónGauge Entero no negativo de 32 bits (máx=232 - 1):

Gauge ::= [APPLICATION 2] IMPLICIT INTEGER (0..4294967295)

!Se puede incrementar y decrementar Cuando el contador llega al máximo, se queda bloqueado en ese valor Aplicaciones:

Número de paquetes almacenados en una cola en un instante Almacenar la diferencia en el valor de algo entre el principio y el final de un intervalo

de tiemp

timeticks Entero no negativo de 32 bits (máx=232 - 1) Cuenta el tiempo en centésimas de segundo

Valor máximo: 497 días TimeTicks ::= [APPLICATION 3] IMPLICIT INTEGER (0..4294967295)

SMI: Tipos de datos de la aplicación Problema: ¿Cuánto tiempo hace falta para

“dar la vuelta” a un contador de 32 bits? Ejemplo: cantidad de bytes transmitidos

Velocidad de la interfaz

Tiempo de desbordamiento

1o Mbps 57.26min.100 Mbps 5.73min.155 Mbps 3.69min.

1 Gbps 0.57min

SMI: Tipos de datos de la aplicación Nuevos tipos en SNMPv2

Integer32: igual que INTEGER Counter32: igual que counter Gauge32: igual que gauge Unsigned32: igual que gauge Counter64: desde 0 hasta

18446744073709551615

SMI: Macro para la definición de objetos (RFC 1212)

IMPORTS ObjectName FROM RFC1155-SMI DisplayStringFROM RFC1158-MIB;

OBJECT-TYPE MACRO ::=BEGIN

TYPE NOTATION ::="SYNTAX"

type(ObjectSyntax)"ACCESS" Access"STATUS" StatusDescrPartReferPartIndexPartDefValPart

VALUE NOTATION ::= value (VALUEObjectName)

Access ::= "read-only“ | "read-write“ | "write-only“ | "not-accessible"

Status ::= "mandatory"| "optional"| "obsolete“ | "deprecated"

DescrPart ::= "DESCRIPTION" value (description DisplayString) | empty

ReferPart ::= "REFERENCE" value (reference DisplayString) | empty


IndexPart ::= "INDEX" "{" IndexTypes "}“ | empty

IndexTypes ::= IndexType | IndexTypes ","

IndexType

IndexType ::= -- if indexobject, use the SYNTAX -- value of the correspondent -- OBJECT-TYPE invocation value (indexobject

ObjectName) -- otherwise use named SMI type -- must conform to IndexSyntax below | type (indextype)

DefValPart ::= "DEFVAL" "{" value (defvalue ObjectSyntax) "}“ | emptyEND

IndexSyntax ::= CHOICE { number INTEGER (0..MAX), string OCTET STRING, object OBJECT IDENTIFIER, address NetworkAddress, ipAddress IpAddress }


ReferPart (opcional): referencia cruzada textual a un objeto definido en otro módulo MIB

IndexPart: para definir tablas; esta cláusula aparece cuando el objeto describe una fila de una tabla

DefValPart (opcional): valor por defecto que se usa cuando se crea una instancia de un objeto

VALUE NOTATION: indica el nombre que se usa para acceder a este objeto mediante SNMP

SMI: Definición de tablas SMI sólo permite estructurar los datos como

tablas bidimensionales con valores escalares

Ejemplo: tabla con las conexiones TCP de un dispositivo Objeto tcpConnTable (1.3.6.1.2.1.6.13) Para cada conexión, se almacena en la tabla:

State: estado de la conexión TCP Local Address: dirección IP local Local Port: puerto local Remote Address: dirección IP remota Remote Port: puerto remoto

SMI: Definición de tablas

Definición del objeto tabla:tcpConnTable OBJECT-TYPESYNTAX SEQUENCE OF TcpConnEntryACCESS not-accessibleSTATUS mandatoryDESCRIPTION"A table containing TCP connection-specific information."::= { tcp 13 }

OJO: T mayúscula

OJO:

t m

inús

cula


Definición del objeto fila: tcpConnEntry OBJECT-TYPE

SYNTAX TcpConnEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Information about a

particular current TCP connection. An object of this type is transient, in that it ceases to exist when (or soon after) the connection makes the transition to the CLOSED state”

INDEX { tcpConnLocalAddress, tcpConnLocalPort, tcpConnRemAddress, tcpConnRemPort } ::= { tcpConnTable 1 }

TcpConnEntry ::= SEQUENCE { tcpConnState INTEGER, tcpConnLocalAddress IpAddress, tcpConnLocalPort INTEGER (0..65535), tcpConnRemAddress IpAddress, tcpConnRemPort INTEGER (0..65535) }


Definición de los campos:

tcpConnState OBJECT-TYPE SYNTAX INTEGER { closed(1), listen(2), synSent(3), synReceived(4), established(5), finWait1(6), finWait2(7), closeWait(8), lastAck(9), closing(10), timeWait(11), deleteTCB(12) }ACCESS read-writeSTATUS mandatoryDESCRIPTION "The state of this TCP

connection.....”::= { tcpConnEntry 1 }

tcpConnLocalAddress OBJECT-TYPE SYNTAX IpAddress ACCESS read-only STATUS mandatory DESCRIPTION "The local IP address for this TCP connection. ...." ::= { tcpConnEntry 2 }

tcpConnLocalPort OBJECT-TYPE SYNTAX INTEGER (0..65535) ACCESS read-only STATUS mandatory DESCRIPTION "The local port number for this TCP connection." ::= { tcpConnEntry 3 }


Definición de los campos:

tcpConnRemAddress OBJECT-TYPE

SYNTAX IpAddress ACCESS read-only STATUS mandatory DESCRIPTION "The remote IP address for

this TCP connection." ::= { tcpConnEntry 4 }

tcpConnRemPort OBJECT-TYPE SYNTAX INTEGER (0..65535) ACCESS read-only STATUS mandatory DESCRIPTION "The remote port number for this TCP connection." ::= { tcpConnEntry 5 }



Management Information Base (MIB-II) La MIB-II se define en el RFC 1213, y sustituye a la

versión anterior MIB-I (RFC 1156) La MIB-II se divide en varios grupos

Los nodos deben implementar todos los objetos del mismo grupo, o ninguno

MIB-II: Grupo system Proporciona información general sobre el sistema

gestionado Muchos de estos objetos son útiles para la gestión de fallos

y de la configuración Objetos para la gestión de fallos

sysObjectID: información sobre el fabricante del dispositivo (identificador de objeto para la empresa en el subárbol enterprises)

sysServices: código de 7 bits que indica los niveles del protocolo de red que soporta el dispositivo

sysUptime: tiempo total que ha transcurrido desde la última reinicialización del sistema

Objetos para la gestión de la configuración sysDescr: descripción textual de la entidad (versión S.O.,

hardware...) sysLocation: ubicación física del sistema sysContact: persona responsable del sistema sysName: nombre del sistema

MIB-II: Grupo system

MIB-II: Grupo interfaces

Contiene datos genéricos relativos a cada interfaz específico de un dispositivo de red

Son útiles en gestión de fallos, de la configuración, de prestaciones y de contabilidad

Objetos ifNumber e ifTable ifNumber define el número de interfaces del sistema

(número de entradas en la tabla) ifTable contiene la información de cada interfaz:

Información para gestión de contabilidad y prestaciones:

Información estadística: número de paquetes enviados, recibidos, descartados, multicast, erróneos, tamaño de colas ...


Información para la gestión de configuración ifIndex: índice del interfaz ifDescr: descripción textual ifType: tipo de hardware que hay bajo la

capa de red ifMTU: tamaño de MTU para el interfaz ifPhysAddress: dirección física del interfaz ifSpeed: ancho de banda del interfaz

(bits/seg)


Información para la gestión de fallos ifAdminStatus, ifOperStatus: estado

deseado y actual del interfaz (activo, inactivo o en modo de pruebas)


MIB-II: Grupo ip Información relativa al funcionamiento del protocolo IP Configuración: ipForwarding, ipDefaultTTL Estadísticas: número de datagramas recibidos y

enviados, errores, datagramas reensamblados y fragmentados....

Tabla de direcciones: ipAddr Table Información de las direcciones IP asignadas a esta entidad Útil para monitorizar la configuración de la red

Tabla de encaminamiento: ipRouting Table Información de encaminamiento Útil para monitorizar la configuración de la red, y para

controlar el proceso de encaminamiento (gestión de fallos, de seguridad o de prestaciones)

Tabla de traducción de direcciones: ipNetToMedia Table Correspondencia entre direcciones IP y direcciones físicas

(tabla ARP) Esta información está también en el grupo at, por

compatibilidad con MIB-I

MIB-II: Grupo ip

MIB-II: Grupo icmp

Estadísticas relativas al funcionamiento del protocolo ICMP Diversos

contadores sobre tipos de mensajes ICMP enviados y recibidos

MIB-II: Grupo tcp

Configuración del protocolo: tcpRtoAltorithm: algoritmo de

cálculo del timeout para retransmisiones

tcpRtoMin, tcpRtoMax: valores mínimo y máximo para el timeout

Estadísticas de conexiones: activas, pasivas, intentos fallidos de conexión...

Estadísticas sobre envío y recepción de segmentos

Tabla de conexiones TCP: tcpConnTable

MIB-II: Grupo udp

Estadísticas sobre envío y recepción de datagramas UDP

Tabla de puertos para los que hay una aplicación aceptando datagramas en la entidad: udpTable Cada entrada es un

par {udpLocalAdress, udpLocalPort}

MIB-II: Grupo egp

Estadísticas sobre envío y recepción de mensajes EGP (External Gateway Protocol)

Tabla egpNeighTable Información sobre los

encaminadores vecinos conocidos

MIB-II: Grupo transmission Objetos que proporcionan información sobre el

medio de transmisión subyacente para cada interfaz del sistema

Existen varias MIBs definidas para cada tipo de interfaz Algunas se hayan en fase experimental (rama

experimental); cuando se estandaricen, se moverán al grupo transmission

Algunos ejemplos: MIB para IEEE 802.4 Token Bus (RFC 1230) MIB para IEEE 802.5 Token Ring (RFC 1231) MIB para FDDI (RFC 1285) MIB para Ethernet (RFC 1643) ...

MIB-II: Grupo snmp

Estadísticas sobre paquetes SNMP enviados y recibidos, errores en la sintaxis ASN.1, número de GETs, SETs y TRAPs...

Algunas implementaciones se optimizan para ser agentes o gestores Devuelven 0 en aquellos objetos que no tienen

sentido para ellas Objeto snmpEnableAuthenTraps

Indica a un agente si debe enviar un trap de error de autentificación, al recibir un mensaje con nombre de comunidad erróneo

MIB-II: Grupo snmp

SNMPv2: Introducción SNMP presenta algunas deficiencias:

Seguridad Prestaciones y funcionalidad

Julio 1992: se proponen dos protocolos para mejorar SNMP Secure-SNMP: trata de mejorar los aspectos de

seguridad SMP (Simple Management Protocol): se centra en

mejorar los demás aspectos: Alcance: facilita la gestión no solo de recursos de red, sino

de cualquier recurso (aplicaciones, comunicación entre gestores, ...)

Tamaño, velocidad y eficiencia: desarrollo de una capacidad de transferencia de bloques de información

Seguridad y privacidad: incluyendo las mejoras de secure-SNMP

Utilización y compatibilidad: SMP está diseñado para ejecutarse sobre TCP/IP, OSI y otras arquitecturas de comunicación; también puede interoperar con plataformas SNMP

SNMPv2: Introducción

Tras la publicación de S-SNMP y SMP, se decidió combinar ambos y proporcionar una única evolución de SNMP

Marzo/1993: Surge SNMPv2, en forma de propuesta de estándar

1996 Se especifica finalmente SNMPv2, tras varios años

de pruebas Finalmente, en SNMPv2 quedan las mejoras de

eficiencia y compatibilidad, pero se eliminan las mejoras de seguridad, por falta de un consenso en cuanto al método a adoptar

SNMPv2: Estructura del SMI La SMI de SNMPv2 expande la de la versión 1 en

varias maneras: Ampliación de la macro de definición de los tipos de

datos Se permiten enumeraciones Los enteros son de 32 bits Se incluye el tipo de direcciones OSI NSAP, además de las

IP Existen contadores de 64 bits Mejor definición del tipo Gauge

Mejora de la documentación de cada objeto Cláusula UNITS

Nuevas convenciones para la creación y eliminación de filas en una tabla

SNMPv2: Estructura de la MIB Se definen dos MIBs dentro de la

especificación de SNMPv2: La MIB SNMPv2: información relacionada

con la operación y configuración del protocolo, y de agentes y gestores

La MIB M2M (Manager to Manager): soporte para la arquitectura de gestión distribuida

SNMPv2: Estructura de la MIB La MIB SNMPv2 incluye cinco grupos:

Estadísticas SNMPv2 Estadísticas SNMPv1 Recursos de Objeto: objetos que permiten a una

entidad SNMPv2 actuar como un agente, y que son objeto de configuración dinámica por parte del gestor

Grupo de Traps: objetos que permiten que una entidad agente SNMPv2 genere PDUs de tipo TRAP SNMPv2

Grupo Set: permite la cooperación de entidades gestoras SNMPv2, para coordinar el uso de la operación Set

SNMPv2: Estructura de la MIB La MIB M2M (Manager to Manager)

incluye dos grupos: snmpAlarm: colección de objetos que

permiten describir y configurar umbrales de alarma en una entidad SNMPv2 actuando como agente y como gestor

snmpEvent: colección de objetos que permiten la descripción y configuración de eventos de una entidad SNMPv2, realizando un papel doble

SNMPv2: Operación del protocolo SNMPv2 define dos nuevas PDU’s: Intercambio de información entre gestores:

InformRequest Siempre contiene las variables sysUpTime.0 (MIB-II) y

SNMPTrapOID.i (MIB M2M) SNMPv2TrapOID.i contiene el identificador de objeto

del tipo de evento Transferencia eficiente de grandes bloques de

datos: GetBulkRequest Similar a GetNextRequest en la forma de especificar

el inicio de la información a recuperar, pero pudiendo seleccionar múltiples sucesores lexicográficos

SNMPv2: Operación del protocolo

SNMPv2: Operación del protocolo Otras diferencias:

La PDU de Trap tiene el mismo formato que las demás, excepto GetBulkRequest, para facilitar su procesamiento en el receptor Siempre se incluye el valor de las variables

sysUpTime.0, y snmpTrapOID.0 (SNMPv2 MIB)

Se pueden incluir más variables GetRequest y GetNextRequest no son

atómicas

SNMPv2: Otras caraterísticas

Declaraciones de conformidad La especificación de SNMPv2 incluye la definición

de un notación para especificar niveles mínimos aceptables de implementación, junto con el nivel de implementación real alcanzado

Protocolos de transporte soportados UDP (preferido) OSI Connectionless-Mode Network Service (CLNS) OSI Connection-Oriented Network Service (CONS) Novel IPX Appletalk

SNMPv2: Coexistencia con SNMP En la especificación de SNMPv2 se hacen

recomendaciones para permitir y facilitar la coexistencia con SNMPv1

La información de gestión de SNMPv2 es un superconjunto de la de SNMPv1

Para compatibilizar las operaciones del protocolo, hay dos posibilidades:

Emplear un agente proxy: este agente interactuará con los agentes SNMP, y con los gestores SNMPv2

Emplear un gestor bilingüe: el gestor contactará con cada agente empleando el protocolo adecuado

Esto debe ser transparente a la aplicación de gestión

SNMPv2: Coexistencia con SNMP

SNMPv2: Coexistencia con SNMP

SNMPv3 En la versión final de SNMPv2 finalmente se descartaron

las mejoras a la seguridad, por falta de consenso Se intenta añadir seguridad a SNMPv2, proponiendo SNMPv2u

y SNMPv2* A partir de ellos, en 1998 surge SNMPv3

Define una serie de capacidades de seguridad y un marco que hace posible su uso junto con las PDUs de SNMPv1 o SNMPv2

SNMPv3 define un conjunto de mecanismos de seguridad

Protección contra las amenazas de modificación de la información, enmascaramiento, modificación del flujo de mensajes y revelación de contenidos

No contempla la protección frente a la denegación de servicio o el análisis del tráfico

SNMPv3 Se definen dos capacidades relacionadas con la seguridad:

Modelo de seguridad basado en el usuario (USM, User-based Security Model)

Proporciona funciones de autentificación y privacidad (encriptado) Opera a nivel de mensaje

Modelo de control de acceso basado en vistas (VACM, View-based Access Control Model)

Determina si a una entidad dada se le permite el acceso a ciertos objetos de un MIB, para ejecutar acciones concretas: implementa un control de acceso a los objetos

Funciona a nivel de PDU (subsistema de control de acceso) La MIB también se amplía para contemplar las nuevas

informaciones necesarias para la gestión RFC 3418 “Management Information Base (MIB) for the Simple

Network Management Protocol (SNMP)”

Documents

Gestión de Redes: Protocolos de Mantenimiento