Gestión de Redes: Protocolos de Mantenimiento

1. Dr. Víctor J. Sosa Sosa vjsosa@gmail.com Gestión de Redes: Protocolos de Mantenimiento

2. 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

3. Gestión de Redes TCP/IP • Al inicio de TCP/IP no se pensó en incluir soporte para la gestiónde redes • Eran los expertos en protocolos quienes solucionaban los problemasde 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 • ProgramasPING (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 • Protocoloestándar, con mucha más funcionalidad que PING, fácil de aprender y utilizar por muchas personas responsables de la gestiónde red

4. Gestión de Redes TCP/IP • El IAB (Internet ArchitectureBoard) 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 InformationProtocol– 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 InformationProtocol

5. 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: RemoteMONitor • 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

6. Principales RFCs relacionados con SNMPv1

7. Principales RFCs relacionados con SNMPv2

8. Principales RFCs relacionados con SNMPv3

9. 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 SNMP

10. 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

11. 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

12. 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

13. 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 • Procesogestor: • 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

14. Elementos del modelo de gestión

15. SNMP: Tiposde mensajes

16. SNMP: Tipos de mensajes • GetRequest: el gestor pide al agente el valor de un dato • GetNextRequestes 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

17. SNMP: Sondeo dirigido por traps (trap-directedpolling) • 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 trapspara obtener información de los dispositivos

18. SNMP: Sondeo dirigido por traps (trap-directedpolling) • 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

19. SNMP: Proxies SNMP

20. SNMP: Detallesdel protocolo • SNMP se especifica en el RFC 1157 (Mayo 1990) • SNMP permite leer y escribir objetos escalaresen 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

21. 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 (communityname) • 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

22. 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 communityprofile) • A cada comunidad se le asigna un perfil, denominándose a esta asociación política de acceso SNMP (SNMP accesspolicy) • 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)

23. SNMP Comunidades

24. SNMP Comunidades

25. 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 denominaPDU (Protocol Data Unit) de SNMP MensajeSNMP

26. SNMP: Formato de los paquetes

27. 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)

28. 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

29. SNMP: Ventajase 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)

30. 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)

31. 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)

32. SMI: Estructura • La estructura del SMI y de la MIB se definen empleando el estándar ASN.1 (AbstractSyntaxNotationOne) 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

33. 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

34. SMI: Estructura

35. 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 isocuelgan 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

36. SMI: Estructura • Dentrodel nodo internet, el SMI define cuatronodos: • directory(1): directorio X.500 • mgmt(2): objetosdefinidos en documentosaprobadosporel IAB • Como la mib-2 (1) • experimental(3): identificadoresde objetosexperimentalesen Internet • private(4): identificadoresde objetosdefinidosporempresas

37. SMI: Estructura Definido en MIB-II (RFC 1213) Definido por SMI (RFC 1155)

38. 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

39. 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

40. SMI: Estructura • Ejemplo: tcpMaxConnOBJECT-TYPE SYNTAX INTEGER ACCESS read-only 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.“ 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} Descripción del objeto (opcional, dirigida al usuario) Posición del objeto dentro del árbol (referida al nodo “padre”) ::= { tcp 4 }

41. SMI: Estructura

42. 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 • Porejemplo, SNMP • CONTEXT-SPECIFIC: ídem que el anterior, pero aplicables en un contexto limitado • PRIVATE: definidos por los usuarios; no standarizados

43. SMI: Tipos de datos relevantes en SNMTP • Tiposde datosuniversales: • 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(eliminadoactualmente) • ipAddress(OCTETSTRING de 4 bytes) • counter (INTEGER) • gauge (INTEGER) • timeticks(INTEGER) • opaque (datos arbitrarios, apenas se usa)

44. 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

45. 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

46. SMI: Tipos de datos de la aplicación ipAddress • DireccionesIP (32 bits) • Definidocomo OCTETSTRING de 4 bytes: IpAddress::= [APPLICATION 0] -- in network-byte order IMPLICIT OCTET STRING (SIZE (4)) counter • !Enterono 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úmerode paquetes/bytes enviados/recibidos, número de errores, …

47. SMI: Tipos de datos de la aplicación Gauge • 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)

48. 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

49. SMI: Tipos de datos de la aplicación • Nuevostipos en SNMPv2 • Integer32: igualque INTEGER • Counter32: igualque counter • Gauge32: igualque gauge • Unsigned32: igualque gauge • Counter64: desde 0 hasta 18446744073709551615

50. SMI: Macro para la definición de objetos (RFC 1212) IMPORTS ObjectName FROM RFC1155-SMI DisplayStringFROMRFC1158-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