DEFINICIÓN
SNMP es uno de los protocolos ampliamente aceptados para administrar y monitorizar elementos de red. La mayoría de los elementos de red de nivel profesional vienen con un agente SNMP incluido. Estos agentes deben estar habilitados y configurados para comunicarse con el sistema de administración de red (NMS).
Su utilidad en la gestión de redes proviene del hecho de que permite recopilar la información sobre los dispositivos conectados a la red de una forma estandarizada en una gran variedad de tipos de hardware y software.
Casi ningún administrador de red renuncia a SNMP; más bien al contrario: la mayoría confía firmemente en este protocolo porque es admitido por muchos tipos de dispositivos de múltiples fabricantes diferentes, permitiéndoles conseguir una supervisión integral gracias a la tecnología SNMP.
OBJETIVOS:
•Hacer que la red Se use eficazmente, utilizando mejor sus recursos.
•Establecer mecanismo de control y monitorización para garantizar la resolución del problema a tiempo y suministrar recursos cuando sea necesario.
•Aumentar la seguridad de la red…
•Controlar cambios y actualizaciones evitando posibles perjuicios.
FUNCIONES
Cada agente SNMP mantiene una base de datos de información que describe los parámetros del dispositivo administrado. El administrador SNMP usa esta base de datos para solicitar al agente informática según sea necesario para el sistema de administración de res (NMS).
La información que puede ofrecernos este protocolo es totalmente adaptable a las necesidades de los diferentes fabricantes de equipos. Existen una serie datos que son estándares, y que todo equipo que quiera cumplir el protocolo debe gestionar y responder, pero también unas definiciones totalmente personalizables. Esta información está almacenada en bases de datos MIB que indican la estructura y el código de los datos que podemos solicitar. Esta información suele ser pública aunque algunos fabricantes pueden no publicitar la información específica de sus equipos salvo a sus clientes.
El protocolo se basa en dos situaciones y comportamientos diferentes:
- Si deseamos conocer el estado de un equipo, o una característica en concreto, el gestor de SNMP envía una petición indicando quién es él, qué valor del MIB desea consultar (no es lo mismo pedir si un ventilador en concreto está en marcha que el ancho de banda consumido por una interfaz de red) y una clave. Una vez el equipo recibe la petición comprueba que la calve proporcionada es correcta y contesta a su petición informándole del valor asociado al valor MIB solicitado.
- En el segundo caso el comportamiento es inverso. El equipo llega a una situación en la que está programado para avisar a su gestor (se ha alcanzado un umbral de espacio en disco, se ha roto un ventilador, etc.). Así el equipo envía una paquete SNMP trap a su gestor informándole de la situación para que éste lo gestione y avise al administrador de sistemas si fuera necesario. Se trata pues de un procedimiento que se puede utilizar como sistema de alarma.
TIPOS DE MENSAJES SNMP
Existen diferentes tipos de mensajes SNMP que se pueden usar para configurar la supervisión de la red a través de SNMP:
- GetRequest: se trata del mensaje que envía un administrador SNMP para solicitar datos, y es el que se usa con mayor frecuencia. El dispositivo objetivo devuelve el valor solicitado con un mensaje de respuesta.
- GetNextRequest: el administrador de SNMP puede enviar este tipo de mensaje para descubrir qué información está disponible desde el dispositivo. Al comenzar en OID 0, el administrador puede continuar enviando una solicitud de los siguientes datos disponibles hasta que no haya más. De esta manera, los usuarios pueden descubrir todos los datos disponibles en un determinado dispositivo, incluso aunque no hayan tenido ningún conocimiento previo del sistema o dispositivo de respuesta.
- GetBulkRequest: aparece por primera vez en SNMP 2, y se trata de una versión más nueva y optimizada de GetNextRequest. La respuesta solicitada contendrá tantos datos como permita la solicitud. Esencialmente, es una forma de efectuar varias GetNextRequest a la vez, permitiendo a los usuarios generar una lista de todos los datos y parámetros disponibles.
- SetRequest: es un comando iniciado por el administrador para establecer o modificar el valor de un parámetro a través de SNMP en el dispositivo o sistema del agente. Este tipo de mensaje se puede usar para administrar o actualizar la configuración u otros ajustes. ¡Pero hay que tener cuidado! Un SetRequest incorrecto podría afectar seriamente a los sistemas y las configuraciones de red.
- Response: la respuesta es el mensaje que un agente de dispositivo envía tras una solicitud del administrador. Cuando se envía en respuesta a un tipo GetRequest, el paquete contiene los datos o valores solicitados. En el caso de un SetRequest, el paquete responde indicando el nuevo valor establecido a modo de confirmación de que el SetRequest se ha completado con éxito.
- Trap(v2): el agente SNMP envía (“expulsa”) una trampa sin que el administrador lo haya solicitado. De hecho, las trampas se envían bajo determinadas condiciones, como en caso de un error o al sobrepasar un umbral preestablecido. Las trampas son una excelente idea en términos de supervisión proactiva, pero si los usuarios desean beneficiarse de su uso, es posible que primero tengan que configurarlas con la ayuda del administrador de SNMP.
- InformRequest: este tipo de mensaje se agregó en SNMP v2 para dar al administrador la posibilidad de confirmar que ha recibido un mensaje de captura de un agente. Algunos agentes están configurados de modo que sigan enviando una trampa hasta recibir la confirmación de un mensaje de informe.
- Report: los mensajes Report (“informe”) necesitan SNMP v3 y permiten que un administrador de SNMP determine qué tipo de problema detectó el agente SNMP remoto. Dependiendo del error detectado, el motor de SNMP puede intentar enviar un mensaje corregido. De no ser posible, puede enviar una indicación del error a la aplicación en cuyo nombre se emitió la solicitud SNMP fallida. [RFC3412]
TRANSFERENCIA DE MENSAJES SNMP
El protocolo simple de administración de red es parte de la familia de protocolos de internet (Internet Protocol Suite) como un protocolo de capa de aplicación (capa 7) del modelo OSI.
SNMP utiliza el protocolo de datagramas de usuario (UDP) para transferir los mensajes. Para que la supervisión tenga éxito, es imperativo que los paquetes UDP puedan pasar del agente al administrador. Generalmente, esto funciona así de forma predefinida en una red local, pero hay que configurar específicamente el router para permitir que dichos paquetes atraviesen redes más amplias.
Los agentes SNMP reciben solicitudes UDP en el puerto 161. Un administrador SNMP puede enviar sus solicitudes desde cualquier puerto; por lo general, es el 161. Los agentes envían trampas a través del puerto 162, y el administrador de SNMP también las recibe trampas en dicho número de puerto.
COMANDOS BÁSICOS DE SNMP
La simplicidad en el intercambio de información ha convertido al SNMP en un protocolo ampliamente aceptado. La razón principal es un conjunto conciso de comandos, que se enumeran a continuación:
- GET: La operación GET es una solicitud enviada por el administrador al dispositivo administrado. Se realiza para recuperar uno o más valores del dispositivo administrado.
- GET NEXT: Esta operación es parecida a la GET. La diferencia significativa es que la operación GET NEXT recupera el valor del siguiente OID en el árbol MIB.
- GET BULK: La operación GETBULK se utiliza para recuperar datos voluminosos de una tabla MIB grande.
- SET: Los administradores utilizan esta operación para modificar o asignar el valor del dispositivo administrado.
- TRAPS: A diferencia de los comandos anteriores que se inician desde el administrador SNMP, los agentes inician TRAPS. Es una señal al administrador SNMP por parte del agente sobre la repetición de un evento.
- INFORM: Este comando es similar al TRAP iniciado por el agente, además, INFORM incluye la confirmación del administrador SNMP al recibir el mensaje.
- RESPONSE: Es el comando utilizado para transportar los valores o la señal de las acciones dirigidas por el administrador de SNMP.
CARACTERÍSTICAS
Trabaja en la capa de aplicación del modelo TCP/IP. Es decir, está en el último eslabón para que se entreguen los datos a la aplicación que los maneje.
Las cabeceras que emplea son relativamente simples. Trabaja con el Protocolo UDP en la capa de transporte, lo que indica que no es con fiable ni orientado a conexión. Usa los puertos 161 y 162 (este último para los “traps”).
Estructura cliente-servidor. El servidor es el equipo gestionado que utiliza el agente de gestión para servir datos al cliente, el cliente es el NMS (NetWork Management System) o sistema administrador.
Utiliza un tamaño máximo de paquete de 64 kB.
Mensajes por petición-respuesta y por “trampas” del agente de gestión Realiza continuos sondeos al carecer de confiabilidad.
Hace una petición por cada dato que necesite (no puede usar solicitudes múltiples).
Utiliza MIB (Management Information Base) estáticas.
HERRAMIENTAS DEL SNMP
Es común tener un entorno de red heterogéneo. Por lo tanto, las herramientas disponibles en el conjunto de herramientas de OpUtils podrían no ser suficientes para monitorear una gama más amplia de dispositivos. En tal escenario, las herramientas SNMP de OpUtils se pueden usar para monitorear tales dispositivos. La base de datos de MIB tiene un gran número de MIB tanto de proveedor estándar como privado. Usando herramientas como la herramienta walker y la herramienta de navegador MIB, uno puede monitorear cualquier dispositivo.
ESTRUCTURA DE MIB E IDENTIFICADOR DE OBJETO (ID DE OBJETO U OID)
La Base de información de administración (MIB) es una recopilación de información para administrar el elemento de red. Las MIB se componen de objetos administrados identificados mediante el nombre Identificador de objeto (ID de objeto u OID).
Cada identificador es único y señala características específicas de un dispositivo administrado. Cuando se lo consulta, el valor de retorno de cada identificador puede ser diferente, por ejemplo, Texto, Número, Contador, etc.
OID
OID significa “Identificador de objetos” (Object Identifier). Los OID identifican los objetos gestionados que se definen en los archivos MIB de forma exclusiva.
Ejemplo:
En una impresora, los típicos objetos a supervisar son los diferentes estados de los cartuchos y, tal vez, la cantidad de páginas impresas. En un switch, los típicos objetos de interés son el tráfico entrante y saliente, así como la tasa de pérdida de paquetes o el número de paquetes dirigidos a una dirección de difusión (broadcast).
Generalmente, la jerarquía de objetos (OID) se representa como un árbol con diferentes niveles, desde la raíz hasta cada una de las hojas. Cada OID tiene una dirección que sigue los niveles del árbol OID.
Muestra:
Aquí se presenta una estructura de ejemplo de un OID:
Iso(1).org(3).dod(6).internet(1).private(4).transition(868).products(2).chassis(4)
.card(1).slotCps(2)-cpsSlotSummary(1).cpsModuleTable(1).cpsModuleEntry(1)
.cpsModuleModel(3).3562.3
o simplemente:
1.3.6.1.4.868.2.4.1.2.1.1.1.3.3562.3
Las ID de objeto MIB de nivel superior y general las asignan diferentes organizaciones estándar, como ISO. Los proveedores definen OID para sus propios productos en ramas privadas del árbol OID.
Hay dos tipos de objetos: escalares y tabulares. Los objetos escalares definen una única instancia de objeto, mientras que los tabulares definen múltiples instancias de objeto relacionadas que se agrupan en tablas MIB.
Hay dos tipos de objeto administrado o ID de objeto: Escalar y tabular. Podrían entenderse mejor con un ejemplo
Escalar: Nombre del proveedor del dispositivo, el resultado solo puede ser uno. (Como dice la definición: "Objeto escalar define una instancia de objeto única")
Tabular: El uso de la CPU de un procesador cuádruple, esto me daría un resultado para cada CPU por separado, lo que significa que habrá 4 resultados para esa ID de objeto en particular. (Como dice la definición: "El objeto tabular define varias instancias de objetos relacionados que se agrupan en tablas MIB")
Cada ID de objeto se organiza jerárquicamente en MIB. La jerarquía de MIB se puede representar en una estructura de árbol con un identificador de variable individual.
Un ID de objeto normal será una lista punteada de enteros. Por ejemplo, el OID en RFC1213 para "sysDescr" es .1.3.6.1.2.1.1.1
COMPARACIÓN DE LAS DIFERENTES VERSIONES DEL SNMP PROTOCOL
Inicialmente, SNMP no contaba con una posibilidad para que los gerentes se comunicaran entre sí, ni para que los agentes enviaran mensajes cuya llegada fuera confirmada. Además, el soporte de muchas aplicaciones inicialmente solo funcionaba de manera parcial, a pesar de su enfoque de estándar abierto. Por lo tanto, las revisiones de los años siguientes se centraron especialmente en integrar los mecanismos necesarios en el simple network management protoco. Otro esfuerzo importante del grupo de trabajo responsable del IETF, el cual se refleja en particular en la tercera versión del protocolo, fue hacer que el procedimiento de administración fuera más seguro desde el principio. Estos y otros pasos de optimización del SNMP protocol se explican con más detalle en los siguientes apartados, los cuales se centran en las versiones individuales SNMPv1, SNMPv2 y SNMPv3.
SNMPv1
SNMPv1 es la primera versión del protocolo de administración de red que propone el modelo gestor-agente y la base para la comunicación entre la estación del gestor y cada agente. El protocolo de gestión de red simple se describe como un protocolo sencillo que opera a nivel de aplicación y mediante UDP (User Datagram Protocol) y el protocolo de internet (IP), pero que también es compatible con protocolos de red similares como Apple Talk DDP (protocolo de datagramas de entrega) o Internet Packet Exchange (IPX). El único mecanismo de seguridad integrado es el intercambio de la denominada cadena de comunidad, la cual se envía con las respectivas solicitudes.
SNMPv2
Un problema importante con la primera versión del SNMP protocol es que la medida de seguridad de cadena de comunidad se transmite solo en texto sin formato. Por esta razón, los desarrolladores se pusieron a trabajar rápidamente en una nueva variante llamada Secure SNMP, en la que esta cadena se transmite en forma cifrada. Sin embargo, esta versión nunca se lanzó porque fue reemplazada directamente por SNMPv2. Otras mejoras respecto de la variante de protocolo original incluyen el manejo mejorado de errores, la capacidad de comunicación de administrador a administrador y comandos SET más potentes. Sin embargo, la mayor ventaja sobre el SNMPv1 radica en los mensajes de tipo GETBULK (para consultar datos múltiples en una sola solicitud) e INFORM (para confirmar que se han recibido las respuestas del agente).
SNMPv3
Después de las primeras y más modestas actualizaciones en la segunda versión del protocolo, el IETF se centró para el SNMPv3 completamente en la seguridad y reemplazó la cadena de la comunidad por el nombre de usuario y la contraseña. Además, a diferencia de sus predecesores, el tercer protocolo incluye funciones para cifrar la transmisión de los paquetes SNMP.
Para saber más del tema se muestra en el vídeo siguiente:
No hay comentarios:
Publicar un comentario