Monitoreo de red mediante SNMP
SUMMARY En esta sección se describe la implementación de SNMP en Junos OS.
Descripción de la implementación de SNMP en Junos OS
Arquitectura SNMP
Una implementación típica de SNMP incluye tres componentes:
Sistema de administración de red (NMS): una combinación de hardware (dispositivos) y software (el administrador SNMP) que se utiliza para supervisar y administrar una red. El administrador sondea los dispositivos de la red con la frecuencia con la que especifica para obtener información sobre la conectividad, la actividad y los eventos de la red.
Dispositivo administrado: un dispositivo administrado (también llamado elemento de red) es cualquier dispositivo de una red administrada por el NMS. Los enrutadores y conmutadores son ejemplos comunes de dispositivos administrados.
Agente SNMP: el agente SNMP es el proceso SNMP que reside en el dispositivo administrado y se comunica con el NMS. El agente SNMP intercambia información de administración de red con el software snmp manager que se ejecuta en un NMS o host. El agente responde a las solicitudes de información y acciones del administrador. El agente también controla el acceso al MIB del agente, la colección de objetos que el administrador SNMP puede ver o cambiar.
Este tema contiene las siguientes secciones:
MIB SNMP
Los datos SNMP se almacenan en un formato altamente estructurado y jerárquico conocido como base de información de administración (MIB). Un MIB define los objetos administrados en un dispositivo de red.
La estructura MIB se basa en una estructura de árbol y define una agrupación de objetos en conjuntos relacionados. Cada objeto de la MIB está asociado con un identificador de objeto (OID), que da nombre al objeto. La "leaf" de la estructura de árbol es la instancia de objeto administrado real, que representa un recurso, evento o actividad que se produce en el dispositivo de red.
Los MIB son estándar o específicos de la empresa. Los MIB estándar son creados por el Grupo de trabajo de ingeniería de Internet (IETF) y documentados en varias RFC. Según el proveedor, muchos MIB estándar se entregan con el software NMS. También puede descargar los MIB estándar desde el sitio web de IETF, www.ietf.org, y compilarlos en su NMS, si es necesario.
Para obtener una lista de MIB estándar compatibles, consulte MIB SNMP estándar compatibles con Junos OS.
Los BMI específicos de la empresa son desarrollados y compatibles con un fabricante de equipos específico. Si su red contiene dispositivos que tienen MIB específicos de la empresa, debe obtenerlos del fabricante y compilarlos en su software de administración de red.
Para obtener una lista de los MIB compatibles con empresas específicas de Juniper Networks, consulte MIB SNMP específicas para la empresa compatibles con Junos OS.
Autenticación y comunicación de agente y administrador SNMP
SNMP utiliza una forma muy básica de autenticación llamada cadenas de comunidad para controlar el acceso entre un administrador y agentes remotos. Las cadenas de comunidad son nombres administrativos que se usan para agrupar colecciones de dispositivos (y los agentes que se ejecutan en ellas) en dominios de administración comunes. Si un gerente y un agente comparten la misma comunidad, pueden hablar entre sí. Muchas personas asocian cadenas de comunidad SNMP con contraseñas y claves porque los trabajos que hacen son similares. Como resultado, las comunidades SNMP se denominan tradicionalmente cadenas.
La comunicación entre el agente y el administrador se produce de uno de los siguientes formularios:
Get,GetBulkyGetNextsolicitudes: el administrador solicita información del agente; el agente devuelve la información en unGetmensaje de respuesta.Setsolicitudes: el administrador cambia el valor de un objeto MIB controlado por el agente; el agente indica el estado en unSetmensaje de respuesta.Trapsnotificación: el agente envía capturas para notificar al administrador de eventos significativos que se producen en el dispositivo de red.
Capturas e informes SNMP
Los enrutadores pueden enviar notificaciones a los administradores SNMP cuando ocurren eventos significativos en un dispositivo de red, la mayoría de las veces errores o fallas. Las notificaciones SNMP se pueden enviar como trampas o solicitudes de información. Las capturas SNMP son notificaciones no confirmadas. Los informes SNMP son notificaciones confirmadas.
Las capturas SNMP se definen en MIB estándar o específico de la empresa. El IETF crea trampas estándar y se documentan en varias RFC. Las trampas estándar se compilan en el software de administración de red. También puede descargar las trampas estándar desde el sitio web de IETF, www.ietf.org.
Para obtener más información acerca de las capturas estándar compatibles con Junos OS, consulte Capturas SNMP estándar compatibles con dispositivos que ejecutan Junos OS.
Un fabricante específico de equipos desarrolla y admite trampas específicas para la empresa. Si la red contiene dispositivos que tienen trampas específicas de la empresa, debe obtenerlas del fabricante y compilarlas en su software de administración de red.
Para obtener más información acerca de las capturas específicas de la empresa compatibles con Junos OS, consulte Capturas SNMP específicas para la empresa compatibles con Junos OS. Para obtener más información acerca de los niveles de gravedad de registro del sistema para capturas SNMP, consulte Niveles de gravedad de registro del sistema para capturas SNMP.
Con las trampas, el receptor no envía ningún reconocimiento cuando recibe una trampa, y el remitente no puede determinar si se recibió la trampa. Para aumentar la confiabilidad, los informes SNMP se admiten en SNMPv3. Un administrador SNMP que recibe un informe reconoce el mensaje con una respuesta. Para obtener más información acerca de los informes SNMP, consulte Configuración de las informaciones SNMP.
SNMP en Junos OS
En Junos OS, SNMP usa tanto el estándar (desarrollado por IETF y documentado en RFC) como los MIC específicos para la empresa de Juniper Networks.
De forma predeterminada, SNMP no está habilitado en dispositivos que ejecutan Junos OS.
En Junos OS, los procesos que mantienen los datos de administración SNMP incluyen los siguientes:
Un agente SNMP maestro que reside en el dispositivo administrado y lo administra el NMS o el host.
El software del agente SNMP de Junos OS consta de un agente SNMP principal (conocido como el proceso SNMP o snmpd). Reside en el dispositivo administrado y lo administra el NMS o el host.
Varios subagentes que residen en diferentes módulos de Junos OS, como el motor de enrutamiento. El agente SNMP maestro delega todas las solicitudes SNMP a los subagentes. Cada subagente es responsable del soporte de un conjunto específico de MIB.
Procesos de Junos OS que comparten datos con los subagentes cuando se sondean para los datos SNMP (por ejemplo, MIB relacionados con interfaz).
La cadena de comunidad es el primer nivel de autenticación de administración implementado por el agente SNMP en Junos OS.
Consulte las siguientes secciones para obtener más información.
- Compatibilidad con Junos OS de las versiones SNMP
- Niveles de gravedad de registro del sistema para capturas SNMP
- Flujo de comunicación SNMP
- Cola trampa
Compatibilidad con Junos OS de las versiones SNMP
Junos OS admite las siguientes versiones de SNMP:
SNMPv1: la implementación inicial de SNMP que define la arquitectura y el marco para SNMP.
SNMPv2c: el protocolo revisado, con mejoras en el rendimiento y las comunicaciones de administrador a administrador. Específicamente, SNMPv2c implementa cadenas de comunidad, que actúan como contraseñas al determinar quién, qué y cómo los clientes SNMP pueden acceder a los datos en el agente SNMP. La cadena de comunidad está contenida en SNMP
Get,GetBulk,GetNext, ySetsolicitudes. Es posible que el agente requiera una cadena de comunidad paraGet,GetBulkyGetNextsolicitudes (read-onlyacceso) diferente a la que requiere paraSetlas solicitudes (read-writeacceso).SNMPv3: el protocolo más actualizado se centra en la seguridad. SNMPv3 define un modelo de seguridad, un modelo de seguridad basado en el usuario (USM) y un modelo de control de acceso basado en vistas (VACM). SNMPv3 USM proporciona integridad de datos, autenticación de origen de datos, protección contra reproducción de mensajes y protección contra la divulgación de la carga del mensaje. SNMPv3 VACM proporciona control de acceso para determinar si se permite un tipo específico de acceso (lectura o escritura) a la información de administración.
Además, el software del agente SNMP de Junos OS acepta direcciones IPv4 e IPv6 para el transporte a través de IPv4 e IPv6. Para IPv6, Junos OS admite las siguientes funciones:
Datos SNMP a través de redes IPv6
Datos MIB específicos de IPv6
Agentes SNMP para IPv6
Niveles de gravedad de registro del sistema para capturas SNMP
Para algunas capturas, cuando se produce una condición de captura, independientemente de si el agente SNMP envía una captura a un NMS, la captura se registra si el registro del sistema está configurado para registrar un evento con ese nivel de gravedad de registro del sistema.
Para obtener más información acerca de los niveles de gravedad de registro del sistema para capturas estándar, consulte Capturas SNMP estándar compatibles con Junos OS. Para obtener más información acerca de los niveles de gravedad del registro del sistema para capturas específicas de la empresa, consulte Capturas SNMP específicas de la empresa compatibles con Junos OS.
Flujo de comunicación SNMP
Cuando un NMS sondea al agente principal para los datos, el agente principal comparte inmediatamente los datos con el NMS si los datos solicitados están disponibles del agente principal o de uno de los subagentes. Sin embargo, si los datos solicitados no pertenecen a las categorías que mantiene el agente principal o los subagentes, el subagente sondea el kernel de Junos OS o el proceso que mantiene esos datos. Al recibir los datos necesarios, el subagente vuelve a pasar la respuesta al agente principal, que a su vez la pasa al NMS.
Figura 1 muestra el flujo de comunicación entre el NMS, el agente principal (snmpd), los subagentes SNMP, el kernel de Junos OS y el motor de reenvío de paquetes.
Cuando se produce un evento significativo, la mayoría de las veces un error o un error, en un dispositivo de red, el agente SNMP envía notificaciones al administrador SNMP. La implementación de SNMP en Junos OS admite dos tipos de notificaciones: trampas e informes. Las trampas son notificaciones no confirmadas, mientras que las informa son notificaciones confirmadas . Los informes solo se admiten en dispositivos que admitan la configuración snmp versión 3 (SNMPv3).
Cola trampa
Junos OS admite la cola de trampas para garantizar que no se pierdan las trampas debido a la indisponibilidad temporal de rutas. Se forman dos tipos de colas, las colas de destino y una cola de aceleración, para garantizar la entrega de trampas y controlar el tráfico de trampas.
No puede configurar colas de captura en Junos OS. No puede ver información acerca de las colas de captura, excepto por lo que se proporciona en los registros del sistema.
Junos OS forma una cola de destino cuando se devuelve una captura a un destino determinado porque el host no es accesible y agrega las capturas posteriores al mismo destino de la cola. Junos OS comprueba la disponibilidad de rutas cada 30 segundos y envía las trampas desde la cola de destino de manera de ida y vuelta.
Si se produce un error en la entrega de la captura, la captura se vuelve a agregar a la cola y se restablece el contador de intentos de entrega y el temporizador de intentos de entrega siguiente para la cola. Los intentos posteriores se producen a intervalos progresivos de 1 minuto, 2 minutos, 4 minutos y 8 minutos. La demora máxima entre los intentos es de 8 minutos y la cantidad máxima de intentos es de 10. Después de 10 intentos fallidos, se eliminan la cola de destino y todas las trampas de la cola.
Junos OS también tiene un mecanismo de aceleración para controlar la cantidad de trampas (umbral de aceleración; valor predeterminado de 500 trampas) enviadas durante un período de tiempo determinado (intervalo de aceleración; valor predeterminado de 5 segundos) y para garantizar la consistencia del tráfico de trampa, especialmente cuando se genera un gran número de trampas debido a cambios de estado de interfaz. El período de intervalo de aceleración comienza cuando la primera trampa llega al acelerador. Todas las capturas dentro del umbral de captura se procesan y las capturas que superan el límite de umbral se colan.
El tamaño máximo de las colas de trampa (es decir, la cola de aceleración y la cola de destino juntas) es de 40 000. Sin embargo, en conmutadores Ethernet de la serie EX, el tamaño máximo de la cola de captura es de 1000. El tamaño máximo de cualquier cola es de 20 000 para dispositivos que no son conmutadores de la serie EX. En los conmutadores de la serie EX, el tamaño máximo de una cola es 500. Cuando se agrega una trampa a la cola de acelerador o si la cola de aceleración ha superado el tamaño máximo, la trampa se agrega de nuevo en la parte superior de la cola de destino y todos los intentos posteriores de la cola de destino se detienen durante un período de 30 segundos, después del cual la cola de destino se reinicia enviando las trampas.
Los usuarios no pueden configurar Junos OS para hacer colas trampas. Los usuarios no pueden ver ninguna información sobre las colas de captura, excepto lo que está disponible en la información registrada.
Descripción general de SNMPv3
El conmutador QFX3500 admite SNMP versión 3 (SNMPv3). SNMPv3 mejora la funcionalidad de SNMPv1 y SNMPv2c al admitir la autenticación de usuario y el cifrado de datos. SNMPv3 usa el modelo de seguridad basado en el usuario (USM) para proporcionar seguridad para los mensajes SNMP y el modelo de control de acceso basado en vistas (VACM) para el control de acceso de usuarios.
Las funciones de SNMPv3 incluyen:
-
Con USM, los mensajes SNMP entre el administrador SNMP y el agente pueden autenticar el origen del mensaje y comprobar la integridad de los datos. USM reduce los retrasos y las repeticiones de mensajes mediante la aplicación de límites de tiempo de espera y la búsqueda de identificaciones de solicitud de mensajes duplicados.
-
VACM complementa la USM proporcionando control de acceso de usuario para consultas SNMP al agente. Se definen privilegios de acceso que desea extender a un grupo de uno o más usuarios. Los privilegios de acceso están determinados por los parámetros del modelo de seguridad (
usm,v1ov2) y los parámetros de nivel de seguridad (authentication,privacyonone). Para cada nivel de seguridad, debe asociar una vista MIB para el grupo. Asociar una vista MIB con un grupo otorga el permiso de lectura, escritura o notificación a un conjunto de objetos MIB para el grupo. -
Configure los parámetros de seguridad para cada usuario, incluidos el nombre de usuario, el tipo de autenticación y la contraseña de autenticación, y el tipo de privacidad y contraseña de privacidad. El nombre de usuario dado a cada usuario tiene un formato que depende del modelo de seguridad configurado para ese usuario.
-
Para garantizar la seguridad de la mensajería, otro tipo de nombre de usuario, llamado nombre de seguridad, se incluye en los datos de mensajería que se envían entre el servidor SNMP local y el servidor SNMP de destino. Cada nombre de usuario está asignado a un nombre de seguridad, pero el nombre de seguridad tiene un formato independiente del modelo de seguridad.
-
Las entradas de captura en SNMPv3 se crean configurando los parámetros notify, filtro de notificación, dirección de destino y destino. La
notifyinstrucción especifica el tipo de notificación (captura) y contiene una sola etiqueta que define un conjunto de direcciones de destino para recibir una captura. El filtro de notificación define el acceso a una colección de identificadores de objeto de captura (OID). La dirección de destino define la dirección de una aplicación de administración SNMP y otros atributos utilizados para enviar notificaciones. Los parámetros de destino definen el procesamiento de mensajes y los parámetros de seguridad utilizados para enviar notificaciones a un destino determinado.
Para configurar SNMPv3, realice las siguientes tareas:
Carga de archivos MIB a un sistema de administración de red
Para que el sistema de administración de red (NMS) identifique y comprenda los objetos MIB utilizados por Junos OS, primero debe cargar los archivos MIB en su NMS mediante un compilador MIB. Un compilador MIB es una utilidad que analiza la información DE MIB, como el nombre del objeto MIB, los identificaciones y el tipo de datos del NMS.
Puede descargar el paquete Junos MIB desde el índice DE MIB empresariales junos OS en https://www.juniper.net/documentation/en_US/release-independent/junos/mibs/mibs.html . El paquete Junos MIB está disponible en y .tar paquetes.zip. Puede descargar el formato adecuado según sus requisitos.
El paquete JUnos MIB contiene dos carpetas: StandardMibs y JuniperMibs. La StandardMibs carpeta contiene las MIB y RFC estándar compatibles con dispositivos que ejecutan Junos OS, mientras que la JuniperMibs carpeta contiene las MIB específicas de la empresa de Juniper Networks.
Para cargar archivos MIB necesarios para administrar y monitorear dispositivos que ejecutan Junos OS:
Mientras carga un archivo MIB, si el compilador devuelve un mensaje de error que indica que cualquiera de los objetos no está definido, abra el archivo MIB con un editor de texto y asegúrese de que todos los archivos MIB enumerados en la IMPORT sección se cargan en el compilador. Si alguno de los archivos MIB enumerados en la IMPORT sección no se carga en el compilador, cargue ese archivo MIB y, a continuación, intente cargar el archivo MIB que no se pudo cargar.
Por ejemplo, el PING MIB específico de la empresa, mib-jnx-ping.txt, tiene dependencias de RFC 2925, DiSMAN-PING-MIB, mib-rfc2925a.txt. Si intenta cargar mib-jnx-ping.txt antes de cargar mib-rfc2925a.txt, el compilador devuelve un mensaje de error que indica que ciertos objetos en mib-jnx-ping.txt no están definidos. Cargar mib-rfc2925a.txty, a continuación, intentar cargar mib-jnx-ping.txt. El PING MIB específico de la empresa, y luego se mib-jnx-ping.txtcarga sin ningún problema.
Consulte también
Gestión de trampas e informes
En las siguientes secciones, se proporcionan detalles sobre cómo administrar las notificaciones SNMP:
- Generación de trampas basadas en eventos SysLog
- Trampas de filtrado basadas en la categoría de trampa
- Capturas de filtrado basadas en el identificador de objeto
Generación de trampas basadas en eventos SysLog
Las políticas de eventos pueden incluir una acción que genera trampas para eventos basados en mensajes de registro del sistema. Esta característica permite la notificación de una aplicación basada en capturas SNMP cuando se produce un mensaje de registro importante del sistema. Puede convertir cualquier mensaje de registro del sistema, para el cual no hay ninguna captura correspondiente, en una trampa. Si utiliza capturas del sistema de administración de red en lugar de mensajes de registro del sistema para supervisar su red, puede usar esta función para asegurarse de que se le notifican todos los eventos principales.
Para configurar una política que genera una trampa al recibir un evento, incluya las siguientes instrucciones en el [edit event-options policy policy-name] nivel de jerarquía:
En el ejemplo siguiente se muestra la configuración de ejemplo para generar una captura para el evento ui_mgd_terminate:
[edit event-options policy p1]
events ui_mgd_terminate;
then {
raise-trap;
}
Trampas de filtrado basadas en la categoría de trampa
Las trampas SNMP se clasifican en muchas categorías. Junos OS proporciona una opción de configuración, categories en el [edit snmp trap-group trap-group] nivel de jerarquía, que le permite especificar categorías de capturas que desea recibir en un host determinado. Puede usar esta opción cuando desee supervisar solo módulos específicos de Junos OS.
En el siguiente ejemplo, se muestra una configuración de ejemplo para solo linkrecepción, vrrp-events, services, y otn-alarms capturas:
[edit snmp]
trap-group jnpr {
categories {
link;
vrrp-events;
services;
otn-alarms;
}
targets {
192.168.69.179;
}
}
Capturas de filtrado basadas en el identificador de objeto
Junos OS también ofrece una opción de filtro más avanzada que le permite filtrar capturas específicas según sus identificadores de objeto. Puede usar la notify-filter opción para filtrar una trampa específica o un grupo de trampas.
En el siguiente ejemplo, se muestra la configuración de ejemplo para excluir las capturas de administración de configuración específicas para la empresa de Juniper Networks (tenga en cuenta que la configuración SNMPv3 también admite el filtrado de las capturas SNMPv1 y SNMPv2, como se muestra en el siguiente ejemplo):
[edit snmp]
v3 {
vacm {
security-to-group {
security-model v2c {
security-name sn_v2c_trap {
group gr_v2c_trap;
}
}
}
access {
group gr_v2c_trap {
default-context-prefix {
security-model v2c {
security-level none {
read-view all;
notify-view all;
}
}
}
}
}
}
target-address TA_v2c_trap {
address 10.209.196.166;
port 9001;
tag-list tg1;
target-parameters TP_v2c_trap;
}
target-parameters TP_v2c_trap {
parameters {
message-processing-model v2c;
security-model v2c;
security-level none;
security-name sn_v2c_trap;
}
notify-filter nf1;
}
notify v2c_notify {
type trap;
tag tg1;
}
notify-filter nf1 {
oid .1.3.6.1.4.1.2636.4.5 exclude;
oid .1 include;
}
snmp-community index1 {
community-name "$9$tDLl01h7Nbw2axN"; ## SECRET-DATA
security-name sn_v2c_trap;
tag tg1;
}
view all {
oid .1 include;
}
}