| SNMP | |
|---|---|
| Nombre | Protocolo Simple de Manejo de Red |
| Nivel (según el modelo OSI ) | Aplicado |
| Familia | UDP |
| Puerto/ID | 161/ UDP ,162/ UDP |
| Propósito del protocolo | Gestión de dispositivos de red |
| Especificación | RFC 1155 , RFC 1212 , RFC 1213 , RFC 1157 , RFC 3411 |
| Implementaciones principales (clientes) | Integrado en todos los sistemas operativos de red |
| Archivos multimedia en Wikimedia Commons | |
SNMP ( Protocolo simple de administración de red en inglés - a simple network management protocol) es un protocolo de Internet estándar para administrar dispositivos en redes IP basadas en arquitecturas TCP / UDP . Los dispositivos habilitados para SNMP incluyen enrutadores, conmutadores, servidores, estaciones de trabajo, impresoras, bastidores de módem y otros. El protocolo se usa comúnmente en los sistemas de administración de redes para monitorear los dispositivos conectados a la red en busca de condiciones que requieran la atención del administrador. SNMP está definido por el Grupo de Trabajo de Ingeniería de Internet (IETF) como un componente de TCP/IP . Consiste en un conjunto de estándares para la gestión de redes, incluido un protocolo de capa de aplicación, un esquema de base de datos y un conjunto de objetos de datos.
Cuando se usa SNMP, una o más computadoras administrativas (llamadas administradores ) monitorean o administran un grupo de hosts o dispositivos en una red de computadoras. Cada sistema administrado tiene un programa en ejecución permanente llamado agente que comunica información al administrador a través de SNMP .
Las redes administradas por SNMP constan de tres componentes clave:
Un dispositivo administrado es un elemento de red (hardware o software) que implementa una interfaz de administración (no necesariamente SNMP) que permite el acceso unidireccional (solo lectura) o bidireccional a información específica sobre el elemento. Los dispositivos administrados comparten esta información con el administrador. Los dispositivos administrados pueden referirse a cualquier tipo de dispositivo: enrutadores, servidores de acceso, conmutadores, puentes, concentradores, teléfonos IP, cámaras IP, computadoras host, impresoras, etc.
Un agente es un módulo de software de administración de red ubicado en un dispositivo administrado o en un dispositivo conectado a la interfaz de administración de un dispositivo administrado. El agente tiene conocimiento local de la información de gestión y traduce esta información hacia o desde un formulario específico de SNMP (mediación de datos).
El Sistema de administración de red ( NMS ) es una aplicación que monitorea y controla los dispositivos administrados. NMS proporciona la mayor parte del procesamiento de datos necesario para la gestión de la red. Cualquier red administrada puede tener uno o más NMS.
Dado que las direcciones de los objetos del dispositivo se definen en formato digital, son difíciles de recordar. Para simplificar, se utilizan bases de información de gestión (MIB). Los MIB describen la estructura de los datos administrados en un subsistema de dispositivo; utilizan un espacio de nombres jerárquico que contiene identificadores de objetos (OID). Cada OID consta de dos partes: un nombre de texto y una dirección SNMP numérica. Los MIB son opcionales y desempeñan una función de apoyo en la traducción del nombre del objeto del formato humano (palabra) al formato SNMP (numérico). Muy similar a los servidores DNS . Dado que la estructura de los objetos en dispositivos de diferentes fabricantes no coincide, es casi imposible determinar las direcciones SNMP digitales de los objetos requeridos sin la base MIB. Las MIB utilizan la notación especificada en ASN.1 .
SNMP opera en la capa de aplicación TCP/IP (capa 7 del modelo OSI). El agente SNMP recibe solicitudes en el puerto UDP 161. El administrador puede enviar solicitudes desde cualquier puerto de origen disponible al puerto del agente. La respuesta del agente se enviará de vuelta al puerto de origen en el administrador. El administrador recibe notificaciones (Traps e InformRequests) en el puerto 162. El agente puede generar notificaciones desde cualquier puerto disponible. Cuando se usa TLS o DTLS , las solicitudes se reciben en el puerto 10161 y las trampas se envían en el puerto 10162.
SNMPv1 especifica cinco unidades de datos de protocolo básico (PDU). Dos PDU más, GetBulkRequest e InformRequest, se introdujeron en SNMPv2 y se trasladaron a SNMPv3.
Todas las PDU SNMP se construyen de la siguiente manera:
| Encabezado IP (encabezado IP) | Encabezado UDP (encabezado UDP) | versión (versión) | comunidad (contraseña) | Tipo PDU (tipo PDU) | ID de solicitud (ID de solicitud) | estado de error (estado de error) | índice de error (índice de error) | enlaces de variables (variables enlazadas) |
Las siete unidades de intercambio de protocolo SNMP se enumeran a continuación:
Una solicitud de un administrador a un objeto para obtener el valor de una variable o una lista de variables. Las variables requeridas se especifican en el campo de enlaces de variables (la sección del campo de valores no se utiliza). La recuperación de los valores de la variable especificada debe ser realizada por el agente como una operación atómica . Al administrador se le devolverá una Respuesta con los valores actuales.
Una solicitud de un administrador a un objeto para cambiar una variable o lista de variables. Las variables vinculadas se especifican en el cuerpo de la solicitud. El agente debe realizar los cambios en todas las variables especificadas como una operación atómica. Se devolverá una Respuesta al administrador con los nuevos valores (actuales) de las variables.
Una solicitud de un administrador a un objeto para descubrir las variables disponibles y sus valores. Se devolverá al administrador una Respuesta con variables asociadas para la siguiente variable en el MIB en orden lexicográfico . Se puede omitir todo el MIB del agente mediante el uso iterativo de GetNextRequest a partir del OID 0. Las filas de la tabla se pueden leer especificando los OID de las columnas en las variables asociadas en la solicitud.
Una versión mejorada de GetNextRequest. Solicitud del administrador al objeto para múltiples iteraciones de GetNextRequest. Se devolverá una Respuesta al administrador con varias variables asociadas atravesadas, comenzando con la(s) variable(s) asociada(s) en la solicitud. Los campos no repetidores y repeticiones máximas específicos de PDU se utilizan para controlar el comportamiento de la respuesta. GetBulkRequest se introdujo en SNMPv2.
Devuelve variables y valores asociados del agente al administrador para GetRequest, SetRequest, GetNextRequest, GetBulkRequest e InformRequest. Las notificaciones de error se proporcionan mediante campos de estado de error e índice de error.
Esta unidad se utiliza como respuesta a las solicitudes Get y Set y se denomina GetResponse en SNMPv1.
Notificación asíncrona del agente al gestor. Incluye el valor actual de sysUpTime, un OID que identifica el tipo de trampa y variables asociadas opcionales. El direccionamiento de destino para las trampas se determina utilizando variables de configuración de trampas en la MIB. El formato del mensaje de captura se cambió a SNMPv2 y la PDU se renombró a SNMPv2-Trap.
Notificación asíncrona de gerente a gerente o de agente a gerente. Las notificaciones de administrador a administrador ya eran posibles en SNMPv1 (usando Trap), pero SNMP generalmente se ejecuta en UDP, donde la entrega de mensajes no está garantizada y no se informan paquetes perdidos. InformRequest soluciona esto devolviendo un acuse de recibo. El receptor responde con una Respuesta que repite toda la información de la InformRequest. Esta PDU se introdujo en SNMPv2.
SNMP versión 1 (SNMPv1) es la implementación original del protocolo SNMP. SNMPv1 funciona con protocolos como UDP, IP, CLNS, DDP e IPX. SNMPv1 se usa ampliamente y es el protocolo de administración de red de facto en la comunidad de Internet.
Los primeros RFC para SNMP, ahora conocidos como SNMPv1, aparecieron en 1988:
Estos protocolos se han revisado en los siguientes RFC:
Después de un tiempo, el RFC 1156 (MIB-1) fue reemplazado por el más utilizado:
La versión 1 ha sido criticada por su falta de seguridad. La autenticación de los clientes se llevó a cabo solo con la ayuda de los llamados. "cadena común" (cadena comunitaria), de hecho, la contraseña, que se transmitió en claro. El desarrollo de SNMPv1 en la década de 1980 fue llevado a cabo por un grupo de personas que consideraban que el trabajo HEMS/CMIS/CMIP financiado oficialmente por las organizaciones OSI/IETF/NSF era irrealizable en las plataformas informáticas de la época y potencialmente inviable. SNMP fue aprobado por la creencia de que era un protocolo intermedio necesario para dar pasos hacia el despliegue a gran escala de Internet y su comercialización. En ese momento, un estándar de seguridad/autenticación era un sueño y fue frustrado por los grupos de desarrollo de protocolos.
SNMPv2 ( RFC 1441 - RFC 1452 ) revisa la Versión 1 e incluye mejoras en el rendimiento, la seguridad, la privacidad y la comunicación entre administradores. El protocolo introdujo GetBulkRequest, una alternativa al uso iterativo de GetNextRequest para obtener una gran cantidad de datos de control en una sola solicitud. Al mismo tiempo, la nueva seguridad basada en el lado SNMPv2 nunca obtuvo una adopción generalizada, ya que muchos la consideraban demasiado compleja.
SNMPv2 basado en la comunidad (SNMPv2c) se define en RFC 1901 - RFC 1908 . En sus inicios, esta versión se conocía informalmente como SNMPv1.5. SNMPv2c incluye SNMPv2 sin su controvertido modelo de seguridad; en su lugar, se utiliza un esquema de seguridad simple basado en la comunidad de SNMPv1. SNMPv2c a menudo se ha visto como el estándar SNMPv2 de facto, a pesar de que oficialmente era solo un "borrador de estándar".
SNMPv2 basado en el usuario (SNMPv2u) se define en RFC 1909 - RFC 1910 . Esencialmente, este es un compromiso que intenta ofrecer mayor seguridad que SNMPv1, pero sin la complejidad adicional de SNMPv2. Se comercializó una variante de esta versión, SNMP v2*, y el propio mecanismo finalmente se adoptó como uno de los dos marcos de seguridad en SNMP v3.
Ahora se ha determinado que SNMPv2c es incompatible con SNMPv1 en dos áreas clave: formatos de mensajes y operaciones de protocolo. Los mensajes SNMPv2c utilizan formatos de unidad de datos de protocolo (PDU) y encabezado diferentes a los de SNMPv1. Además, SNMPv2c utiliza dos operaciones de protocolo que no están definidas en SNMPv1. Además, RFC 2576 define dos posibles estrategias de coexistencia SNMPv1/v2c: agentes proxy y sistemas de gestión de red bilingües.
Agentes proxyUn agente SNMPv2 puede actuar como agente proxy en nombre de los dispositivos administrados SNMPv1, de la siguiente manera:
El agente proxy asigna trampas SNMPv1 a trampas SNMPv2 y luego las reenvía al NMS.
Sistemas de gestión de redes bilingüesLos sistemas de administración de red SNMPv2 bilingües admiten SNMPv1 y SNMPv2. Para admitir dicho entorno, la aplicación de control en el NMS bilingüe debe comunicarse con el agente. Luego, el NMS analiza la información almacenada en la base de datos local para determinar si el agente es compatible con SNMPv1 o SNMPv2. Según esta información, el NMS se comunica con el agente mediante la versión adecuada de SNMP.
Si bien SNMPv3 no trae ningún cambio al protocolo además de agregar seguridad criptográfica, es una mejora a través de nuevas convenciones textuales, conceptos y terminología.
La seguridad ha sido un gran problema con SNMP desde sus inicios. La autenticación en las versiones 1 y 2 de SNMP no era más que una contraseña (cadena comunitaria) que se enviaba en texto claro entre el administrador y el agente.
A diferencia de SNMPv1 y v2, en SNMPv3 cada mensaje contiene parámetros de seguridad que se codifican como una cadena de octetos. El significado de estos parámetros depende del modelo de seguridad que esté utilizando.
SNMPv3 proporciona funciones de seguridad importantes:
Desde 2004, el IETF ha reconocido SNMPv3 como se define en RFC 3411 , RFC 3418 (también conocido como STD0062) como la versión estándar actual de SNMP. El IETF ha marcado SNMPv3 como un estándar de Internet completo, que es el nivel más alto de preparación para RFC. Al mismo tiempo, las versiones anteriores se consideran obsoletas (indicadas como "históricas" - Históricas).
En la práctica, las implementaciones de SNMP suelen admitir varias versiones: v1, v2c y v3.
Las implementaciones de SNMP varían entre los proveedores de plataformas. En algunos casos, SNMP no se considera lo suficientemente serio para un elemento de desarrollo central y, por lo tanto, es solo una característica opcional. Algunos proveedores de hardware importantes tienden a extender demasiado sus propias interfaces de línea de comandos (CLI) y sistemas de control.
La estructura de árbol aparentemente simple y la indexación lineal en SNMP no siempre se comprenden bien dentro de las estructuras de datos internas que son elementos del diseño de la plataforma subyacente. Por lo tanto, el procesamiento de solicitudes SNMP en ciertos conjuntos de datos puede generar más sobrecarga de CPU de lo necesario. Un ejemplo de este problema son las grandes tablas de enrutamiento como BGP e IGP.
Los dispositivos modulares pueden aumentar o disminuir dinámicamente sus índices SNMP (también llamados casos) a medida que se agrega o elimina hardware. Esto se usa más comúnmente con hardware, aunque las interfaces virtuales tienen el mismo efecto. Los valores de índice generalmente se asignan en el momento del arranque y permanecen sin cambios hasta el próximo reinicio. Los índices de hardware o las entidades virtuales agregadas durante un dispositivo en vivo pueden asignarse al final del rango existente y posiblemente reasignarse en el próximo reinicio.
SNMP en sí mismo es solo un protocolo para recopilar y organizar información. La mayoría de los kits de herramientas de implementación de SNMP ofrecen algún tipo de mecanismo de descubrimiento (una recopilación estandarizada de datos comunes a la mayoría de las plataformas y dispositivos) para obtener un nuevo usuario o artista al inicio. Una de estas funciones suele ser una forma de configuración automática, en la que los nuevos dispositivos descubiertos en la red se sondean automáticamente. En el caso de SNMPv1 y SNMPv2c, esto es un riesgo de seguridad porque las comunidades de lectura de SNMP se transmitirán en texto no cifrado en el dispositivo de destino. Si bien los requisitos de seguridad varían de una organización a otra, se debe tener cuidado al usar esta función, especialmente en entornos como centros de datos de inquilinos mixtos, instalaciones de alojamiento de servidores y entornos similares.
snmpset y reinicie Cisco as53xx
| esquemas URI | |
|---|---|
| Oficial | |
| no oficial | |
| Protocolos TCP /IP básicos por capas del modelo OSI | |
|---|---|
| Físico | |
| canalizado | |
| la red | |
| Transporte | |
| sesión | |
| Representación | |
| Aplicado | |
| Otro aplicado | |
| Lista de puertos TCP y UDP | |