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
Principales RFCs relacionados con SNMPv2
Principales RFCs relacionados con SNMPv3
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
Elementos del modelo de gestión
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
Elementos del modelo de gestión
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
Elementos del modelo de gestión
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
Elementos del modelo de gestión
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
Elementos del modelo de gestión
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
SMI: Macro para la definición de objetos (RFC 1212)
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 }
SMI: Macro para la definición de objetos (RFC 1212)
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
SMI: Definición de tablas
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) }
SMI: Definición de tablas
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 }
SMI: Definición de tablas
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 }
SMI: Definición de tablas
SMI: Definición de tablas
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 ...
MIB-II: Grupo interfaces
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)
MIB-II: Grupo interfaces
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 interfaces
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)”
Top Related