GESTIÓN DE REDES: PROTOCOLOS DE MANTENIMIENTO

Dr. Víctor J. Sosa 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

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 afecte a la MIB o a los recursos gestionados  Trap en respuesta a un evento que 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 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 limitar el 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

Versión Comunidad Mensaje SNMP 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 readOnly(4), genErr(5) (0), tooBig(1), noSuchName(2), badValue(3), Í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 correspondientes valores  de variables y sus 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 alterado la configuración del agente o la implementación del protocolo (0): el emisor se ha reinicializado, y puede haberse 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 restablecido  (3): un enlace de comunicación del agente se ha 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 => común de nombrado (SMI) esquema

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 desarrollado por ISO esquema jerárquico de nombres El espacio de nombres forma un conectada a un conjunto de nodos etiquetados  árbol , con una raíz 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 relacionada representa un recurso, actividad o información

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 remota de la red (RMON) : por ejemplo, con una versión posterior (mib-3) o añadiendo subárboles a mib-2, como la base de monitorización  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 objeto : dentro de private existe el nodo enterprises, donde se asigna una rama a cada fabricante que registra un identificador de

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 INTEGER ACCESS read-only Tipo de datos Modo de acceso a una instancia del objeto {read-only, read-write, write-only, not-accessible} Define si el objeto ha de ser necesariamente incluido en la implementación de la MIB {mandatory, optional, obsolete, deprecated} STATUS mandatory

DESCRIPTION

 "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.“ Descripción del objeto (opcional, dirigida al usuario) ::= { tcp 4 } Posición del objeto dentro del árbol (referida al nodo “padre”)

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 universales

   INTEGER 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 universales

OBJECT 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=2 32 - 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ón

Gauge

 Entero no negativo de 32 bits (máx=2 Gauge ::= [APPLICATION 2] IMPLICIT INTEGER (0..4294967295) 32 - 1):  !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=2 32 - 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

1o Mbps 100 Mbps 155 Mbps 1 Gbps

Tiempo de desbordamiento

57.26min.

5.73min.

3.69min.

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" Status DescrPart ReferPart IndexPart DefValPart VALUE NOTATION ::= value (VALUE ObjectName) 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 DefValPart ::= "DEFVAL" "{" value (defvalue ObjectSyntax) "}“ | empty

END

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) 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-TYPE

OJO: T mayúscula

SYNTAX SEQUENCE OF

TcpConnEntry

ACCESS not-accessible STATUS mandatory DESCRIPTION "A table containing TCP connection specific information." ::= { tcp 13 }

SMI: Definición de tablas

Definición del objeto fila :

tcpConnEntry OBJECT-TYPE

SYNTAX TcpConnEntry ACCESS not-accessible INDEX { tcpConnLocalAddress, tcpConnLocalPort, tcpConnRemAddress, tcpConnRemPort } ::= { tcpConnTable 1 } 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”

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-write STATUS mandatory DESCRIPTION "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 prestaciones :  para gestión de contabilidad y 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 sobre contadores 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 especificación de SNMPv2:



dentro de la

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 implementación real alcanzado niveles mínimos aceptables de implementación, junto con el nivel de 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 recomendaciones para permitir y facilitar la coexistencia con SNMPv1 de SNMPv2 se hacen  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)”