Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Monitoreo de red mediante SNMP

SUMMARY En esta sección se describe la implementación 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 la frecuencia con la que se especifica para obtener información acerca de la conectividad, actividad y eventos de la red.

  • Dispositivo administrado: un dispositivo administrado (también llamado elemento de red) es cualquier dispositivo en una red administrada por el NMS. Los conmutadores y enrutadores 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 la información de administración de la red con el software SNMP Manager que se ejecuta en una NMS o un host. El agente responde a solicitudes de información y acciones del administrador. El agente también controla el acceso a las BIA del agente, la recopilación de objetos que puede ver o modificar el administrador SNMP.

Este tema contiene las siguientes secciones:

MIB de SNMP

Los datos de SNMP se almacenan en un formato jerárquico altamente estructurado conocido como base de información de administración (BIA). Un BIA define objetos administrados en un dispositivo de red.

La estructura BIA se basa en una estructura en árbol y define una agrupación de objetos en conjuntos relacionados. Cada objeto del BIA está asociado a un identificador de objeto (OID), que da nombre al objeto. La "leaf" en la estructura de árbol es la instancia real de objeto administrado, la cual representa un recurso, un evento o una actividad que se produce en su dispositivo de red.

Las MIB son específicas de cada empresa o son estándar. Las MIB estándar se crean mediante el Grupo de trabajo de ingeniería de Internet (IETF) y se documentan en varias RFC. Dependiendo del proveedor, se entregan muchas MIB estándar con el software NMS. También puede descargar las MIB estándar del sitio web de IETF, www.ietf.org, y compilarlas en el NMS, si es necesario.

Para obtener una lista de las MIB estándar compatibles, consulte SNMP estándar, compatible con Junos os.

Las MIB específicas de la empresa se desarrollan y respaldan por un fabricante de equipos específico. Si su red contiene dispositivos que tienen MIB específicas de la empresa, debe obtenerlos del fabricante y compilarlos en el software de administración de red.

Para obtener una lista de Juniper Networks MIB compatibles específicas de la empresa, consulte MIB de SNMP específicas de la empresa admitida por Junos os.

Autenticación y comunicación del agente SNMP Manager

SNMP utiliza una forma de autenticación muy básica llamada cadenas de comunidad para controlar el acceso entre un administrador y los agentes remotos. Las cadenas de comunidad son nombres administrativos que se utilizan para agrupar colecciones de dispositivos (y los agentes que se ejecutan en ellas) en dominios de administración comunes. Si un administrador y un agente comparten la misma comunidad, pueden comunicarse entre sí. Muchas personas asocian las cadenas de comunidad SNMP a las contraseñas y claves porque los trabajos son similares. Como resultado, tradicionalmente se hace referencia a las comunidades SNMP como cadenas.

La comunicación entre el agente y el administrador se produce en uno de los siguientes formatos:

  • Get, y solicitudes: el administrador solicita información al agente; el GetBulk agente devuelve la información en un mensaje de GetNextGet respuesta.

  • Set solicitudes: el administrador cambia el valor de un objeto BIA controlado por el agente; el agente indica el estado en un Set mensaje de respuesta.

  • Traps notificación: el agente envía capturas para notificar al administrador de eventos significativos que se producen en el dispositivo de red.

Interrupciones e informes SNMP

Los enrutadores pueden enviar notificaciones a los administradores SNMP cuando se producen eventos significativos en un dispositivo de red, normalmente errores o errores. Las notificaciones SNMP se pueden enviar como trampas o informar solicitudes. Las interrupciones SNMP son notificaciones no confirmadas. Los informes SNMP se confirman como notificaciones.

Las capturas SNMP se definen en las MIB estándar o específicas de la empresa. Las interrupciones estándar las crea IETF y se documentan en varias RFC. Las capturas estándar se compilan en el software de administración de red. También puede descargar las capturas estándar del sitio web de IETF, www.ietf.org.

Para obtener más información acerca de las interrupciones estándar compatibles con el Junos OS, consulte capturas de SNMP estándar compatibles con dispositivos que se ejecutan Junos os.

Los reventados específicos de la empresa se desarrollan y respaldan por un fabricante de equipos específico. Si su red contiene dispositivos con interrupciones específicas de la empresa, debe obtenerlas del fabricante y recopilarlas en su software de administración de red.

Para obtener más información acerca de las capturas específicas de empresa compatibles con el Junos OS, consulte capturas de SNMP específicas de la empresa compatibles con Junos os. Para obtener más información acerca de los niveles de gravedad del registro del Niveles de gravedad del registro del sistema para capturas SNMPsistema para capturas SNMP, consulte.

Con las capturas, el receptor no envía ninguna confirmación cuando recibe una captura, y el remitente no puede determinar si la captura se ha recibido. Para aumentar la confiabilidad, se admiten los informes SNMP en SNMPv3. Un administrador de SNMP que recibe un informe reconoce el mensaje con una respuesta. Para obtener más información acerca de los informes de SNMP, consulte configuración de informes SNMP.

SNMP en Junos OS

En Junos OS, SNMP utiliza estándar (desarrollado por IETF y documentado en RFC) y Juniper Networks las MIB específicas de la empresa.

Nota:

De forma predeterminada, SNMP no está habilitado en los dispositivos que ejecutan Junos OS.

En Junos OS, los procesos que mantienen los datos de administración de SNMP son los siguientes:

  • Un agente SNMP maestro que reside en el dispositivo gestionado y que está gestionado por la NMS o el host.

    El Junos OS de agente SNMP se compone de un agente principal SNMP (conocido como proceso SNMP o snmpd). Reside en el dispositivo administrado y lo administra el NMS o el host.

  • Varios subagentes que residen en distintos 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 de la compatibilidad de un conjunto específico de MIB.

  • Los procesos de Junos OS que comparten datos con los subagentes cuando sondean los datos de SNMP (por ejemplo, las MIB relacionadas con la interfaz).

La cadena de comunidad es el primer nivel de autenticación de administración implementada por el agente SNMP en Junos OS.

Consulte las secciones siguientes para obtener más información.

Compatibilidad de las versiones de SNMP Junos OS

El Junos OS admite las siguientes versiones de SNMP:

  • S NMPV1: la implementación inicial de SNMP que define la arquitectura y el marco para SNMP.

  • S NMPV2c: el protocolo modificado, con mejoras en el rendimiento y las comunicaciones de gerente a gerente. De forma específica, SNMPv2c implementa cadenas de comunidad, que actúan como contraseñas a la hora de determinar quién, qué y cómo los clientes SNMP pueden tener acceso a los datos en el agente SNMP. La cadena de comunidad se incluye en Getlas GetBulksolicitudes GetNextSNMP, Set , y. Es posible que el agente requiera una cadena Getde GetBulkcomunidad diferente GetNext para,read-only y solicitudes (Access) de Set las queread-write realiza para solicitudes (acceso).

  • S NMPV3: 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 de reproducción de mensajes y protección contra la revelació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 Junos OS acepta direcciones IPv4 e IPv6 para el transporte a través de IPv4 e IPv6. En el caso de IPv6, el Junos OS admite las siguientes características:

  • Datos SNMP a través de redes IPv6

  • Datos de BIA específicos de IPv6

  • Agentes SNMP para IPv6

Niveles de gravedad del registro del sistema para capturas SNMP

En el caso de algunas capturas, cuando se produce una condición de interrupción, la captura se registra si el registro del sistema se configura para registrar un evento con el nivel de gravedad de registro del sistema, independientemente de si el agente SNMP envía una captura a una NMS.

Para obtener más información acerca de los niveles de gravedad del registro del sistema para interrupciones estándar, consulte capturas de 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 empresa, consulte interrupciones SNMP específicas de la empresa admitidas por Junos os.

Flujo de comunicación SNMP

Cuando un NMS sondea al agente principal para obtener datos, el agente principal comparte de inmediato los datos con el NMS si los datos solicitados están disponibles desde el agente principal o uno de los sub reactivos. Sin embargo, si los datos solicitados no pertenecen Junos OS las categorías que mantiene el agente principal o los sub reactivos, el sub reactivo sondea el núcleo de Junos OS o el proceso que los mantiene. Al recibir los datos necesarios, el sub reactivo vuelve a devolver la respuesta al agente principal, el cual, a su vez, lo pasa al NMS.

Figura 1 muestra el flujo de comunicación entre el NMS, el agente principal SNMP (snmpd), los sub reactivos SNMP, Junos OS núcleo y el motor de reenvío de paquetes.

Figura 1: Flujo de comunicación SNMPFlujo de comunicación SNMP

Cuando se produce un suceso significativo, que suele ser un error o un fallo, en un dispositivo de red, el agente SNMP envía notificaciones al administrador SNMP. La implementación SNMP en Junos OS admite dos tipos de notificaciones: interrupciones e informes. Las capturas son notificaciones no confirmadas, mientras que los informes de notificaciones se confirman. Los informes sólo se admiten en dispositivos que admiten la configuración de la versión 3 de SNMP (SNMPv3).

Cola de interrupciones

Junos OS admite la puesta en cola de capturas para garantizar que las capturas no se pierden debido a la falta de disponibilidad temporal de las rutas. Dos tipos de colas, colas de destino y una cola de límite, se forman para garantizar la entrega de capturas y para controlar el tráfico de la captura.

Nota:

No puede configurar la cola de captura en Junos OS. No puede ver información acerca de las colas de captura, excepto la que se proporciona en los registros del sistema.

Junos OS forma una cola de destino cuando se devuelve una captura a un destino determinado debido a que no se puede alcanzar el host, y agrega las reventaciones posteriores al mismo destino en la cola. Junos OS comprueba la disponibilidad de las rutas cada 30 segundos y envía las capturas de la cola de destino en un modo de operación por turnos.

Si la entrega de capturas no se realiza correctamente, la captura se vuelve a agregar a la cola, y se restablecen el contador de entregas y el siguiente temporizador de intentos de entrega para la cola. Los intentos subsiguientes se producen a intervalos progresivos de 1 minuto, 2 minutos, 4 minutos y 8 minutos. El retraso máximo entre los intentos es de 8 minutos y el número máximo de intentos es 10. Después de 10 intentos fallidos, se eliminan la cola de destino y todas las capturas de la cola.

Junos OS también dispone de un mecanismo acelerador para controlar el número de capturas (umbral de limitación; valor predeterminado de 500 capturas) enviados durante un período de tiempo determinado (intervalo de limitación; predeterminado de 5 segundos) y para garantizar la coherencia en el tráfico de capturas, especialmente cuando el número de capturas se genera debido a cambios en el estado de la interfaz. El período del intervalo de limitación comienza cuando llega el primer reventado al acelerador. Todas las capturas que se encuentran dentro del umbral de captura se procesan y las capturas que superan el límite del umbral quedan en la cola.

El tamaño máximo de las colas de captura (es decir, la cola de aceleración y la cola de destino juntadas) es de 40 000. Sin embargo, en los conmutadores Ethernet de la serie EX, el tamaño máximo de la cola de captura es el 1.000. El tamaño máximo de cualquier cola es el 20.000 para dispositivos que no sean 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 captura a la cola de limitación, o si la cola supera el tamaño máximo, la captura se vuelve a agregar 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, tras lo cual el la cola de destino se reinicia enviando las capturas.

Nota:

Los usuarios no pueden configurar el Junos OS para la cola de capturas. Los usuarios no pueden ver ninguna información acerca de las colas de captura, excepto lo que esté disponible en la información registrada.

Descripción general de SNMPv3

A diferencia de las versiones de SNMP 1 (SNMPv1) y SNMP versión 2 (SNMPv2), la versión 3 de SNMP (SNMPv3) admite la autenticación y el cifrado. SNMPv3 utiliza el modelo de seguridad basado en el usuario (USM) para la seguridad de los mensajes y el modelo de control de acceso basado en vistas (VACM) para el control de acceso. USM especifica la autenticación y el cifrado. VACM especifica reglas de control de acceso.

USM utiliza el concepto de usuario para el que se configuran parámetros de seguridad (niveles de seguridad, autenticación, protocolos de privacidad y claves) tanto para el agente como para el administrador. Los mensajes que se envían mediante USM están mejor protegidos que los mensajes que se envían con cadenas de comunidad, donde las contraseñas se envían sin cifrar. Con USM, los mensajes intercambiados entre el directivo y el agente pueden tener autenticación de datos de comprobación y origen de datos. USM protege contra retrasos de mensajes y repeticiones de mensajes mediante indicadores de hora y identificadores de solicitud. El cifrado también está disponible.

Para complementar a la USM, SNMPv3 usa el VACM, un modelo de control de acceso muy granular para aplicaciones SNMPv3. Basándose en el concepto de aplicar políticas de seguridad al nombre de los grupos que consultan el agente, el agente decide si el grupo puede ver o cambiar determinados objetos BIA. VACM define las colecciones de datos (llamados vistas), los grupos de usuarios de datos y las instrucciones de acceso que determinan qué vistas puede utilizar un determinado grupo de usuarios para la lectura, escritura o recepción de capturas.

Los movimientos de reventado en SNMPv3 se crean mediante la configuración de los parámetros notificar, filtro de notificación, dirección de destino y destino. La notify instrucción especifica el tipo de notificación (TRAP) y contiene una sola etiqueta. La etiqueta define un conjunto de direcciones de destino en las que se va a recibir un reventado. El filtro de notificación define el acceso a una colección de identificadores de objetos de interrupción (OID). La dirección de destino define la dirección de una aplicación de administración y otros atributos que se usarán para enviar notificaciones. Los parámetros de destino definen el procesamiento de mensajes y los parámetros de seguridad que se utilizarán para enviar notificaciones a un determinado destino de administración.

Para configurar SNMPv3, realice las siguientes tareas:

Información general sobre SNMPv3 (QFX en modo independiente)

El conmutador QFX3500 es compatible con la versión 3 de SNMP (SNMPv3). SNMPv3 mejora la funcionalidad de SNMPv1 y SNMPv2c, ya que admite la autenticación de usuarios y el cifrado de datos. SNMPv3 utiliza el modelo de seguridad basado en el usuario (USM) para proporcionar seguridad a los mensajes SNMP, y el modelo de control de acceso basado en vistas (VACM) para el control de acceso de los usuarios.

Entre las características de SNMPv3, se incluyen:

  • Con USM, los mensajes SNMP entre el administrador de SNMP y el agente pueden tener autenticado el origen del mensaje y comprobar la integridad de los datos. USM reduce los retrasos de mensajería y las repeticiones de mensajes mediante la aplicación de límites de tiempo de espera y la comprobación de ID duplicados de solicitudes de mensajes.

  • VACM complementa USM al proporcionar control de acceso de usuario para las consultas SNMP al agente. Defina los privilegios de acceso que desee extender a un grupo de uno o más usuarios. Los privilegios de acceso se determinan según losusmparámetros v1del modelo v2de seguridad (, o)authenticationy privacylos parámetros nonede nivel de seguridad (, o). Para cada nivel de seguridad, debe asociar una vista BIA para el grupo. Asociar una vista BIA con un grupo concede el permiso leer, escribir o notificar a un conjunto de objetos BIA para el grupo.

  • Los parámetros de seguridad para cada usuario se configuran, como el nombre de usuario, el tipo de autenticación y la contraseña de autenticación, y la contraseña de privacidad y tipo de privacidad. El nombre asignado a cada usuario está en un formato que depende del modelo de seguridad configurado para dicho usuario.

  • Para garantizar la seguridad de la mensajería, se incluye otro tipo de nombre de usuario, denominado nombre de seguridad, 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 se asigna a un nombre de seguridad, pero el nombre de seguridad está en un formato independiente del modelo de seguridad.

  • Los movimientos de reventado en SNMPv3 se crean mediante la configuración de los parámetros notificar, filtro de notificación, dirección de destino y destino. La notify instrucción especifica el tipo de notificación (TRAP) y contiene una sola etiqueta que define un conjunto de direcciones de destino para que reciban un reventado. El filtro de notificación define el acceso a una colección de identificadores de objetos de interrupción (OID). La dirección de destino define la dirección de una aplicación de administración SNMP y otros atributos utilizados en el envío de notificaciones. Los parámetros de destino definen el procesamiento del mensaje y los parámetros de seguridad que se utilizan para enviar notificaciones a un objetivo determinado.

Carga de archivos de BIA a un sistema de administración de red

Para que el sistema de gestión de red (NMS) identifique y comprenda el BIA objetos que utiliza el Junos OS, primero debe cargar los archivos BIA en el NMS con un compilador BIA. Un compilador BIA es una utilidad que analiza la información de BIA, como el BIA el nombre del objeto, los identificadores y el tipo de datos de la NMS.

Puede descargar el paquete de BIA de Junos desde el Junos OS índice MIB de empresa en https://www.Juniper.net/Documentation/en_US/Release-Independent/Junos/mibs/MIBs.html . El paquete Junos BIA está disponible en .zip y .tar en paquetes. Puede descargar el formato adecuado según sus necesidades.

El paquete Junos BIA contiene dos carpetas: StandardMibsy JuniperMibs. La StandardMibs carpeta contiene las MIB y RFC estándar que se admiten en los dispositivos que ejecutan Junos os JuniperMibs , mientras que la carpeta contiene las Juniper Networks MIB específicas de la empresa.

Para cargar BIA archivos necesarios para administrar y supervisar los dispositivos que ejecutan el Junos OS:

  1. Vaya a la página de descarga de SNMP BIA Explorer para obtener Juniper Networks paquetes BIA SNMP (snmp BIA Explorer).
  2. Haga clic TAR en ZIP el vínculo o en el título de la versión correspondiente para descargar el Junos BIA paquete para esa versión.
  3. Descomprima el archivo (.tar o .zip) utilizando una utilidad adecuada.
  4. Cargue los archivos de BIA estándar (desde StandardMibs la carpeta) en el orden siguiente:
    Nota:

    Algunos de los compiladores de BIA que se utilizan con frecuencia tienen cargadas previamente las MIB estándar. Si las MIB estándar ya están cargadas en el compilador BIA que está utilizando, omita este paso y continúe en el paso 7.

    1. mib-SNMPv2-SMI.txt

    2. mib-SNMPv2-TC.txt

    3. mib-IANAifType-MIB.txt

    4. mib-IANA-RTPROTO-MIB.txt

    5. mib-rfc1907.txt

    6. mib-rfc4293.txt

    7. mib-rfc2012a.txt

    8. mib-rfc2013a.txt

    9. mib-rfc2863a.txt

  5. Cargue los restantes archivos BIA estándar.
    Nota:

    Debe seguir el orden especificado en este procedimiento y asegurarse de que todas las MIB estándar se carguen antes de cargar las MIB específicas de la empresa. Es posible que existan dependencias que requieran la presencia de un BIA concreto en el compilador antes de cargar otros BIA. Puede encontrar estas dependencias en la IMPORT sección del archivo de BIA.

  6. Cargue el Juniper Networks BIA SMI específico de la empresa mib-jnx-smi.txt, y las siguientes MIB opcionales de SMI en función de sus requerimientos:
    • mib-jnx-js-smi.txt— (Opcional) Para objetos Juniper seguridad BIA árbol

    • mib-jnx-ex-smi.txt— (Opcional) Para las series EX Conmutadores Ethernet

    • mib-jnx-exp.txt—(Recomendado) Para Juniper Networks de BIA experimentación

  7. Cargue en la JuniperMibs carpeta el resto de MIB específicas de empresa.
Consejo:

Mientras se carga un archivo de BIA, si el compilador devuelve un mensaje de error que indica que alguno de los objetos está sin definir, abra el archivo de BIA con un editor de texto y asegúrese IMPORT de que todos los archivos BIA que aparecen en la sección se cargan en el compilador. Si alguno de los BIA archivos enumerados en IMPORT la sección no está cargado en el compilador, cárguelo en ese BIA y, a continuación, intente cargar el archivo de BIA que no se pudo cargar.

Por ejemplo, el BIA de PING específico de la mib-jnx-ping.txtempresa,, tiene dependencias en RFC 2925, DISMAN-PING- mib-rfc2925a.txtBIA,. Si intenta cargar mib-jnx-ping.txt antes de cargar mib-rfc2925a.txt, el compilador devuelve un mensaje de error que indica que mib-jnx-ping.txt determinados objetos de no están definidos. Cargue mib-rfc2925a.txty, a continuación, intente mib-jnx-ping.txtcargar. La BIA PING específica de la empresa mib-jnx-ping.txt, se carga sin ningún problema.

Show SNMP

Hay varios comandos a los que puede tener acceso en Junos OS modo operativo para supervisar la información de SNMP. Algunos de los comandos son:

  • show snmp health-monitor, que muestra el registro de Health Monitor y la información de alarma.

  • show snmp mib, que muestra información de las MIB, como información del dispositivo y del sistema.

  • show snmp statistics, que muestra estadísticas SNMP como el número de paquetes, caídas silenciosas y valores de salida no válidos.

  • show snmp rmon, que muestra la información de alarma, suceso, historial y registro RMON

El ejemplo siguiente proporciona resultados de ejemplo del show snmp health-monitor comando:

El ejemplo siguiente proporciona resultados de ejemplo del show snmp mib comando:

El ejemplo siguiente proporciona resultados de ejemplo del show snmp statistics comando:

Descripción de p + f de Junos OS SNMP

En este documento, se presentan las preguntas más frecuentes acerca de las funciones y tecnologías utilizadas para implementar servicios SNMP en Juniper Networks dispositivos utilizando el Sistema operativo de Junos.

SNMP permite a los usuarios supervisar los dispositivos de red desde una ubicación central. Muchos sistemas de administración de redes (NMS) se basan en SNMP y la compatibilidad con este protocolo es una característica clave de la mayoría de los dispositivos de red.

Juniper Networks proporciona muchas plataformas diferentes que admiten SNMP en el Junos OS. El Junos OS incluye un agente SNMP incorporado que proporciona a las aplicaciones de administración remota acceso a información detallada acerca de los dispositivos de la red.

Una implementación típica de SNMP contiene tres componentes:

  • Dispositivos administrados, como enrutadores y conmutadores.

  • Agente SNMP: proceso que reside en un dispositivo administrado y se comunica con el NMS.

  • NMS: acomete el hardware y el software utilizados para supervisar y administrar la red; dispositivo de red que ejecuta software de administrador SNMP. También se conoce como administrador SNMP.

El agente SNMP intercambia la información de administración de la red con el administrador de SNMP (NMS). El agente responde a solicitudes de información y acciones del administrador. El administrador SNMP recopila información acerca de la conectividad, actividad y eventos de la red mediante el sondeo de los dispositivos administrados.

La implementación de SNMP en el Junos OS utiliza un agente SNMP maestro (conocido como proceso SNMP o SNMP) que reside en el dispositivo administrado. Varios subagentes residen también en diferentes módulos del Junos OS (como el motor de enrutamiento), y estos subagentes son administrados por el snmpd.

Preguntas frecuentes de Junos OS SNMP

Estas preguntas frecuentes explican estas áreas relacionadas con SNMP:

Preguntas frecuentes de Junos OS SNMP support

En esta sección se presentan preguntas frecuentes y sus respuestas relacionadas con la compatibilidad con SNMP en Junos OS.

Which SNMP versions does Junos OS support?

Junos OS admite SNMP versión 1 (SNMPv1), versión 2 (SNMPv2c) y versión 3 (SNMPv3). De forma predeterminada, SNMP está desactivado en un dispositivo Juniper Networks.

Which ports (sockets) does SNMP use?

El puerto predeterminado para las consultas SNMP es el puerto 161. El puerto predeterminado para las capturas y los informes de SNMP es el puerto 162. El puerto que se utiliza para las interrupciones e informes de SNMP se puede configurar, y el sistema se configura para que utilice puertos distintos del puerto predeterminado 162. Sin embargo, el puerto de escucha SNMP seguirá siendo el mismo; Esto se establece en la solicitud de cambio.

Is SNMP support different among the Junos OS platforms?

No, la compatibilidad con SNMP no es diferente en las plataformas de Junos OS. La configuración, interacción y comportamiento de SNMP son los mismos en cualquier dispositivo Junos OS. La única diferencia que puede ocurrir entre las plataformas es BIA soporte técnico.

Consulte también SNMP BIA Explorer para obtener una lista de las MIB que se admiten en las plataformas Junos os.

Does Junos OS support the user-based security model (USM)?

Sí, Junos OS admite USM como parte de su soporte para SNMPv3. SNMPv3 contiene más medidas de seguridad que las versiones anteriores de SNMP, incluida la inclusión de un USM definido. SNMPv3 USM proporciona seguridad de mensajes mediante la integridad de datos, autenticación del origen de datos, protección de reproducción de mensajes y protección contra la revelación de la carga del mensaje.

Does Junos OS support the view-based access control model (VACM)?

Sí, Junos OS admite VACM como parte de su soporte para SNMPv3. SNMPv3 contiene más medidas de seguridad que las versiones anteriores de SNMP, incluida la inclusión de un VACM definido. SNMPv3 VACM determina si se permite un tipo específico de acceso (lectura o escritura) a la información de administración.

Does Junos OS support SNMP informs?

Sí, Junos OS admite informes SNMP como parte de su soporte para SNMPv3. Los informes SNMP se confirman como notificaciones enviadas desde los agentes SNMP a los administradores de SNMP cuando se producen sucesos significativos en un dispositivo de red. Cuando un administrador SNMP recibe un informe, envía una respuesta al remitente para comprobar la recepción del informe.

Can I provision or configure a device using SNMP on Junos OS?

No, no se permite el aprovisionamiento ni la configuración de un dispositivo con SNMP en Junos OS.

Preguntas frecuentes de Junos OS MIBs

En esta sección se presentan preguntas frecuentes y sus respuestas relacionadas con Junos OS MIB.

What is a MIB?

Una base de información de administración (BIA) es una tabla de definiciones de objetos administrados en un dispositivo de red. SNMP utiliza las MIB para mantener las definiciones estándar de todos los componentes y sus condiciones de funcionamiento en un dispositivo de red. Cada objeto de la BIA tiene un código de identificación denominado identificador de objetos (OID).

Las MIB son específicas de cada empresa o son estándar. Las MIB estándar se crean mediante el Grupo de trabajo de ingeniería de Internet (IETF) y se documentan en varias RFC. Las MIB específicas de la empresa se desarrollan y respaldan por un fabricante de equipos específico.

Para obtener una lista de MIB estándar compatibles, consulte MIB estándar de SNMP compatible con Junos os.

Para obtener una lista de Juniper Networks MIB específicas de la empresa, consulte MIB de SNMP específicas de la empresa admitida por Junos os.

Do MIB files reside on the Junos OS devices?

No, BIA archivos no residen en los dispositivos Junos OS. Debe descargar los archivos BIA desde la página Juniper Networks publicaciones técnicas para la versión Junos OS necesaria: https://www.juniper.net/documentation/en_US/release-independent/junos/mibs/mibs.html .

How do I compile and load the Junos OS MIBs onto an SNMP manager or NMS?

Para que los sistemas de gestión de red (NMSs) identifiquen y conozcan los BIA objetos utilizados por Junos OS, primero debe cargar los archivos BIA en el NMS con un compilador BIA. Un compilador BIA es una utilidad que analiza la información BIA, como los nombres de BIA objetos, los identificadores y los tipos de datos de la NMS.

Puede descargar el paquete de BIA Junos OS desde la sección MIB e interrupciones específicas de la empresa en https://www.Juniper.net/Documentation/en_US/Release-Independent/Junos/mibs/MIBs.html o https://www.Juniper.net/Documentation/software/Junos/index.html .

El paquete Junos OS BIA tiene dos carpetas: StandardMibs, que incluye MIB estándar compatibles con Juniper Networks dispositivos, JuniperMibsy que contiene Juniper Networks MIB específicas de la empresa. Debe tener el estándar MIB descargado y descomprimido antes de descargar cualquier MIB específico de la empresa. Es posible que existan dependencias que requieran la presencia de una BIA estándar determinada en el compilador antes de cargar una BIA específica de una empresa concreta.

El paquete Junos OS BIA está disponible en .zip formato .tar y. Descargue el formato adecuado para sus necesidades.

Siga estos pasos para cargar BIA archivos para los dispositivos que se ejecutan Junos OS:

  1. Desplácese hasta la Juniper Networks página de descarga del software correspondiente Enterprise MIBs y localice el Enterprise-Specific MIBs and Traps vínculo en la sección.

    Nota:

    Aunque se titula Enterprise MIBsel vínculo, las MIB estándar y las MIB específicas de la empresa se pueden descargar desde esta ubicación.

  2. Haga clic TAR en ZIP el vínculo o para descargar el paquete Junos os BIA.

  3. Descomprima el archivo (.tar o .zip) utilizando una utilidad adecuada.

    Nota:

    Algunos compiladores de BIA utilizados con frecuencia se cargan previamente con las MIB estándar. Puede saltar paso 4 a paso 5 y continuar con el paso 6 si ya tiene cargadas las MIB estándar en el sistema.

  4. Cargue los archivos de BIA estándar de StandardMibs la carpeta.

    Cargue los archivos en el orden siguiente:

    1. mib-SNMPv2-SMI.txt

    2. mib-SNMPv2-TC.txt

    3. mib-IANAifType-MIB.txt

    4. mib-IANA-RTPROTO-MIB.txt

    5. mib-rfc1907.txt

    6. mib-rfc2011a.txt

    7. mib-rfc2012a.txt

    8. mib-rfc2013a.txt

    9. mib-rfc2863a.txt

  5. Cargue cualquier archivo de BIA estándar restante.

    Nota:

    Debe seguir el orden especificado en este procedimiento y asegurarse de que todas las MIB estándar se carguen antes de cargar las MIB específicas de la empresa. Es posible que existan dependencias que requieran la presencia de una BIA estándar determinada en el compilador antes de cargar una BIA específica de una empresa concreta. Las dependencias se enumeran IMPORT en la sección del archivo de BIA.

  6. Después de cargar las MIB estándar, cargue los Juniper Networks BIA SMI específico de la mib-jnx-smi.txtempresa, y las siguientes MIB opcionales que se basan en sus requerimientos:

    • mib-jnx-exp.txt: (Recomendado) para Juniper Networks de BIA fases

    • mib-jnx-js-smi.txt: (Opcional) para aplicaciones Juniper seguridad BIA árbol

    • mib-jnx-ex-smi.txt:(Opcional) para la serie EX Conmutadores Ethernet

  7. Cargue cualquier otro MIB específico de la empresa que desee JuniperMibs de la carpeta.

    Consejo:

    Mientras se carga un archivo de BIA, si el compilador devuelve un mensaje de error que indica que cualquiera de los objetos está sin definir, abra el archivo de BIA con un editor de texto y asegúrese IMPORT de que todos los archivos BIA que aparecen en la sección se cargan en el compilador. Si alguno de los BIA archivos enumerados en IMPORT la sección no se cargan en el compilador, cargue primero el archivo o los archivos que faltan y, a continuación, intente cargar el archivo de BIA que produjo el error.

    Es posible que el sistema devuelva un error si los archivos no se cargan en un orden determinado.

What is SMI?

La estructura de la versión de la información de administración (SMI) es un subconjunto de notación de sintaxis abstracta uno (ASN. 1), que describe la estructura de los objetos. La SMI es la sintaxis de la notación, o "sintomática", es decir, el estándar para escribir MIB.

Which versions of SMI does Junos OS support?

El Junos OS admite SMIv1 para las MIB de SNMPv1, y SMIv2 para las MIB de SNMPv2c y empresariales.

Does Junos OS support MIB II?

Sí, Junos OS admite BIA II, la segunda versión del BIA estándar.

Entre las características de BIA II se incluyen:

  • Adiciones que reflejan los nuevos requisitos operativos.

  • Compatibilidad con las versiones MIB y SNMP originales.

  • Compatibilidad mejorada con entidades multiprotocolo.

  • Mejorar la legibilidad.

Consulte la documentación de la versión pertinente para obtener una lista de las MIB que se admiten. Vaya a https://www.Juniper.net/Documentation/software/Junos/index.html .

Are the same MIBs supported across all Juniper Networks devices?

Existen algunas MIB comunes que admiten todos los dispositivos Junos OS, como el BIA de la interfaz (ifTable), el BIA del sistema y el chasis BIA. Algunas MIB son compatibles únicamente con las funciones de determinadas plataformas. Por ejemplo, la BIA de puente se admite en los conmutadores Ethernet de la serie EX y en las puertas de enlace de servicios serie SRX para la sucursal.

What is the system object identifier (SYSOID) of a device? How do I determine the SYSOID of my device?

JNX-how-define (las definiciones del chasis para el modelo de enrutador) BIA tiene una jnxProductName bifurcación para cada dispositivo Junos os. El ID de objeto del sistema de un dispositivo es idéntico al ID del objeto jnxProductName de la plataforma. Por ejemplo, en el caso de un enrutador de borde M7i multiservicio, jnxProductNameM7i es. 1.3.6.1.4.1.2636.1.1.1.2.10 en la bifurcación jnxProductName, que es idéntica a la SYSOID del M7i (. 1.3.6.1.4.1.2636.1.1.1.2.10).

How can I determine if a MIB is supported on a platform? How can I determine which MIBs are supported by a device?

La compatibilidad con la plataforma y el dispositivo MIB se incluye en la Junos OS documentación técnica. Consulte las MIB de SNMP específicas de la empresa admitidas por Junos os y las MIB estándar de snmp compatibles con Junos os documentos para ver la lista de MIB y dispositivos compatibles con Junos os.

What can I do if the MIB OID query is not responding?

Puede haber varios motivos por los que la consulta BIA OID deje de responder. Una razón podría ser que la propia BIA no responde. Para comprobar que el BIA responde, utilice el show snmp mib walk | get MIB name | MIB OID comando siguiente:

  • Si el BIA responde, el problema de comunicación existe entre el agente SNMP principal y SNMP. Los motivos posibles de este problema son los problemas de red, una configuración de comunidad incorrecta, una configuración de SNMP incorrecta, etc.

  • Si el BIA no responde, habilite SNMP traceoptions para registrar PDU y errores. Se registran todas las PDU SNMP entrantes y salientes. Compruebe la traceoptions salida para ver si hay errores.

Si sigue teniendo problemas con la consulta BIA OID, está disponible la asistencia técnica de productos en el centro de asistencia técnica de Juniper Networks (JTAC).

What is the enterprise branch number for Junos OS?

El número de sucursal empresarial para el Junos OS es 2636. Los números de sucursales empresariales se utilizan en configuraciones de BIA SNMP, y también se conocen como códigos empresariales privados de administración de red SMI.

Which MIB displays the hardware and chassis details on a Juniper Networks device?

El BIA del chasis (jnxchassis. MIB) muestra los detalles del hardware y del chasis para cada dispositivo Juniper Networks. Proporciona información acerca del enrutador y sus componentes. El chasis BIA objetos representan cada componente y su estado.

Which MIB objects can I query to determine the CPU and memory utilization of the Routing Engine, Flexible PIC Concentrator (FPC), and PIC components on a device?

Consulte los objetos jnxOperatingMemorydel chasis BIA jnxOperatingtBuffer, y jnxOperatingCPU para averiguar el uso de la CPU y la memoria de los componentes de hardware de un dispositivo.

Is the interface index (ifIndex) persistent?

El valor de alcambio es continuo cuando se producen reinicios si la versión de Junos OS sigue siendo la misma, lo que significa que los valores asignados a las interfaces en el valor de "o"

Cuando hay una actualización de software, el dispositivo intenta mantener el modo de carga persistente en función de los mejores esfuerzos. Por Junos OS versión 10,0 y anteriores, el "to" no se conserva cuando hay una actualización de software para Junos OS versión 10,1 y posteriores.

Is it possible to set the ifAdminStatus?

SNMP no puede establecer ifAdminStatus.

Which MIB objects support SNMP set operations?

Las Junos OS operaciones Set de SNMP son compatibles con las siguientes tablas y variables BIA:

  • snmpCommunityTable

  • eventTable

  • alarmTable

  • snmpTargetAddrExtTable

  • jnxPingCtlTable

  • pingCtlTable

  • traceRouteCtlTable

  • jnxTraceRouteCtlTable

  • sysContact. 0

  • sysName. 0

  • sysLocation. 0

  • pingMaxConcurrentRequests. 0

  • traceRouteMaxConcurrentRequests. 0

  • usmUserSpinLock

  • usmUserOwnAuthKeyChange

  • usmUserPublic

  • vacmSecurityToGroupTable (vacmGroupName, vacmSecurityToGroupStorageType y vacmSecurityToGroupStatus)

  • vacmAccessTable (vacmAccessContextMatch, vacmAccessReadViewName, vacmAccessWriteViewName, vacmAccessNotifyViewName, vacmAccessStorageType y vacmAccessStatus)

  • vacmViewSpinLock

  • vacmViewTreeFamilyTable (vacmViewTreeFamilyMask, vacmViewTreeFamilyType, vacmViewTreeFamilyStorageType y vacmViewTreeFamilyStatus)

Does Junos OS support remote monitoring (RMON)?

Sí, Junos OS admite RMON tal como se define en RFC 2819, Remote Network Monitoring base de información de administración. Sin embargo, no se admite la supervisión remota de la versión 2 (RMON 2).

Can I use SNMP to determine the health of the processes running on the Routing Engine?

Sí, puede usar el SNMP para determinar el estado de los motor de enrutamiento procesos configurando la característica de supervisión de estado. En los dispositivos Juniper Networks, las alarmas y los sucesos RMON proporcionan gran parte de la infraestructura necesaria para reducir la sobrecarga de sondeo del NMS. Sin embargo, debe configurar el usuario NMS para que configure objetos de BIA específicos en alarmas RMON. Esto a menudo requiere la experiencia específica del dispositivo y la personalización de la aplicación de supervisión. Además, algunas BIA instancias del objeto que necesitan supervisión solo se establecen al inicializarse, o bien se modifican en tiempo de ejecución y no se pueden configurar de antemano.

Para abordar estos problemas, el monitor de Estado extiende la infraestructura de alarmas RMON para proporcionar una supervisión predefinida de un conjunto seleccionado de instancias de objeto, como el uso del sistema de archivos, el uso de la CPU y el uso de memoria, e incluye compatibilidad con objetos desconocidos o dinámicos instancias, como los procesos de software de Junos OS.

Para mostrar la configuración de la supervisión de estado show snmp health-monitor , utilice el comando siguiente:

Cuando configure el monitor de estado, estará disponible la supervisión de la información de determinadas instancias de Tabla 1objetos, como se muestra en la.

Tabla 1: Instancias de objetos supervisados

Objetos

Descriptiva

jnxHrStoragePercentUsed. 1

Monitorea el siguiente sistema de archivos en el enrutador o conmutador: /dev/ad0s1a:

Este es el sistema de archivos root montado /en.

jnxHrStoragePercentUsed. 2

Monitorea el siguiente sistema de archivos en el enrutador o conmutador: /dev/ad0s1e:

Este es el sistema de archivos de configuración /configmontado en.

jnxOperatingCPU (RE0)

Supervise el uso de la CPU para los motores de enrutamiento RE0 y RE1. Los valores de índice asignados a los motores de enrutamiento dependen de si el BIA del chasis utiliza un esquema de indización basado en cero o basado en unos. Dado que el esquema de indización puede configurarse, se determina el índice correcto cada vez que se inicializa el enrutador y cuando hay un cambio en la configuración. Si el enrutador o conmutador cuenta solamente con una motor de enrutamiento, la RE1 de monitoreo de entrada de alarma se elimina después de cinco intentos fallidos de obtener el valor de la CPU.

jnxOperatingCPU (RE1)

jnxOperatingBuffer (RE0)

Supervise la cantidad de memoria disponible en los motores de enrutamiento RE0 y RE1. Dado que la indización de este objeto es idéntica a la utilizada para jnxOperatingCPU, los valores de índice se ajustan según el esquema de indexación utilizado en el BIA del chasis. Al igual que con jnxOperatingCPU, la RE1 de monitorado de entrada de alarma se retira si el enrutador o conmutador sólo tiene una motor de enrutamiento.

jnxOperatingBuffer (RE1)

sysApplElmtRunCPU

Supervisa el uso de la CPU para cada Junos OS proceso de software. Se supervisan e indizan por separado varias instancias del mismo proceso.

sysApplElmtRunMemory

Supervisa el uso de memoria para cada Junos OS proceso de software. Se supervisan e indizan por separado varias instancias del mismo proceso.

Las entradas del registro del sistema que se generan para los eventos del monitor de estado, como los umbrales cruzados y errores, tienen una etiqueta correspondiente HEALTHMONITOR en lugar de una etiqueta genérica SNMPD_RMON_EVENTLOG . Sin embargo, el monitor de estado envía risingThreshold las fallingThreshold capturas y RMON genéricos.

Are the Ping MIBs returned in decimal notation and ASCII?

Sí, se admiten tanto la notación decimal como el ASCII, que es la implementación estándar en SNMP. Todas las cadenas están codificadas en ASCII.

El siguiente ejemplo muestra el BIA ping en notación hexadecimal:

Esto se traduce en ASCII:

A partir de Junos OS versión 9,6 y posteriores, la CLI de Junos OS devuelve valores ASCII mediante show snmp mib get | get-next | walk asciiel comando.

El siguiente ejemplo muestra el resultado con la opción ASCII:

El ejemplo siguiente muestra el resultado sin la opción ASCII:

Puede convertir los valores decimales y ASCII utilizando un gráfico ASCII decimal como el que se encuentra en http://www.asciichart.com .

Is IPv6 supported by the Ping MIB for remote operations?

No, IPv6 no se admite.

Is there an SNMP MIB to show Address Resolution Protocol (ARP) table information? Are both IP and MAC addresses displayed in the same table?

Sí, el Junos OS admite el BIA estándar, que se describe en ipNetToMediaTable RFC 2011, SNMPv2 base de información de administraciónpara el protocolo de Internet mediante SMIv2 . Esta tabla se utiliza para asignar direcciones IP a sus direcciones MAC correspondientes.

Preguntas frecuentes sobre la configuración de SNMP Junos OS

Esta sección presenta preguntas frecuentes y sus respuestas relacionadas con Junos OS configuración de SNMP.

Can the Junos OS be configured for SNMPv1 and SNMPv3 simultaneously?

Sí, SNMP tiene compatibilidad con versiones anteriores, lo que significa que las tres versiones se pueden activar simultáneamente.

Can I filter specific SNMP queries on a device?

Sí, puede filtrar consultas SNMP específicas en un dispositivo que exclude Utilice include instrucciones e.

En el ejemplo siguiente se muestra una configuración que bloquea la operación de lectura y escritura en todos los OID en test. 1.3.6.1.2.1.1 para la comunidad:

Can I change the SNMP agent engine ID?

Sí, el ID del motor del agente SNMP puede cambiarse a dirección MAC del dispositivo, a la dirección IP del dispositivo o a cualquier otro valor deseado. Aquí se incluyen varios ejemplos.

El siguiente ejemplo muestra cómo utilizar el dirección MAC de un dispositivo como ID del motor de SNMP:

El siguiente ejemplo muestra cómo utilizar la dirección IP de un dispositivo como ID del motor SNMP:

El siguiente ejemplo muestra el uso de un valor seleccionado, AA en este caso, como el ID del motor SNMP de un dispositivo:

How can I configure a device with dual Routing Engines or a chassis cluster (SRX Series Services Gateways) for continued communication during a switchover?

Al configurar para una comunicación continua, la configuración SNMP debe ser idéntica entre los motores de enrutamiento. Sin embargo, es mejor tener identificadores de motor de enrutamiento independientes configurados para cada motor de enrutamiento, especialmente cuando se usa SNMPv3.

El ejemplo siguiente muestra la configuración de los motores de enrutamiento en un dispositivo de dos motor de enrutamiento. Observe que los identificadores de motor de enrutamiento se establecen en las direcciones MAC de cada motor de enrutamiento:

A continuación se encuentra un ejemplo de una configuración de SNMPv3 en un dispositivo de dos motor de enrutamiento:

How can I track SNMP activities?

Las operaciones de seguimiento SNMP realizan un seguimiento de la actividad de los agentes SNMP y registran la información en los archivos de registro.

Una configuración traceoptions de ejemplo podría tener el siguiente aspecto:

Cuando la traceoptions flag all instrucción se incluye en el [edit snmp] nivel de la jerarquía, se crean los siguientes archivos de registro:

  • snmpd

  • mib2d

  • rmopd

Preguntas frecuentes sobre SNMPv3

En esta sección se presentan preguntas frecuentes y sus respuestas relacionadas con SNMPv3.

Why is SNMPv3 important?

SNMP v3 ofrece seguridad mejorada en comparación con las otras versiones de SNMP. Proporciona autenticación y cifrado de datos. La seguridad mejorada es importante para la administración de dispositivos en sitios remotos de las estaciones de administración.

In my system, the MIB object snmpEngineBoots is not in sync between two Routing Engines in a dual Routing Engine device. Is this normal behavior?

Sí, éste es el comportamiento esperado. Cada motor de enrutamiento ejecuta su propio proceso SNMP (SNMP), lo que permite a cada motor de enrutamiento mantener sus propios arranques de motor. Sin embargo, si ambos motores de enrutamiento tienen el mismo ID de motor y el motor de enrutamiento con un valor menor se selecciona como el motor de enrutamiento principal durante el proceso de conmutación, el valor del motor de enrutamiento principal se sincroniza con el valor del otro motor de snmpEngineBootssnmpEngineBootssnmpEngineBoots enrutamiento.

Do I need the SNMP manager engine object identifier (OID) for informs?

Sí, la autenticación requiere el OID del motor del administrador SNMP, e informes no funcionan sin él.

I see the configuration of informs under the [edit snmp v3] hierarchy. Does this mean I cannot use informs with SNMPv2c?

Los informes se pueden usar con SNMPv2c. En el siguiente ejemplo se muestra la configuración básica de informativos de SNMPv3 en un dispositivo (Observe que la autenticación y la privacidad se establecen en None):

Puede convertir la informativa de SNMPv3 en informes en capturas estableciendo el valor de type la instrucción en [edit snmp v3 notify N1_all_tl1_informs] el nivel de trap jerarquía según se muestra en el siguiente ejemplo:

P + f sobre la interacción de SNMP con dispositivos Juniper Networks

En esta sección se presentan preguntas frecuentes y sus respuestas relacionadas con la forma en que SNMP interactúa con Juniper Networks dispositivos.

How frequently should a device be polled? What is a good polling rate?

Es difícil proporcionar un número absoluto para la velocidad de sondeos SNMP por segundo, ya que el índice depende de los dos factores siguientes:

  • El número de enlaces variables en una unidad de datos de protocolo (PDU)

  • Tiempo de respuesta para una interfaz desde el motor de reenvío de paquetes

En un escenario normal en el que la motor de reenvío de paquetes no introduce ningún retraso y hay una variable por PDU (una solicitud GET), el tiempo de respuesta es de 130 respuestas por segundo. Sin embargo, con varias variables en una PDU de solicitud SNMP (30 a 40 para solicitudes GetBulk), el número de respuestas por segundo es mucho menor. Dado que el motor de reenvío de paquetes la carga puede variar para cada sistema, se produce una variación mayor en la frecuencia con la que se debe sondear un dispositivo.

El sondeo frecuente de un gran número de contadores, especialmente de las estadísticas, puede afectar al dispositivo. Recomendamos la siguiente optimización en los administradores de SNMP:

  • Utilice el método de sondeo fila a fila, no el método columna por columna.

  • Reduzca el número de enlaces de variables por PDU.

  • Aumente los valores de tiempo de espera en intervalos de exploración e detección.

  • Reducir la velocidad de paquetes entrante en el proceso SNMP (snmpd).

Para obtener mejor respuesta SNMP en el dispositivo, el Junos OS realiza lo siguiente:

  • Filtra las peticiones SNMP duplicadas.

  • Excluye las interfaces que son lentas en respuesta a las consultas SNMP.

Una forma de determinar el límite de velocidad es anotar un aumento del Currently Active recuento del show snmp statistics extensive comando.

A continuación se muestra un ejemplo del resultado show snmp statistics extensive del comando:

Does SNMP open dynamic UDP ports? Why?

El proceso SNMP abre dos puertos adicionales (sockets): uno para IPv4 y otro para IPv6. Esto permite que el proceso SNMP envíe capturas.

I am unable to perform a MIB walk on the ifIndex. Why is this?

No es posible consultar directamente los enlaces o valores de variables not-accessible con un nivel de acceso, ya que forman parte de otros enlaces de variables de la tabla BIA de SNMP. El "o" o tiene un not-accessiblenivel de acceso de. Por consiguiente, no se puede obtener acceso a él directamente porque forma parte de los enlaces de variables. Sin embargo, es posible acceder indirectamente al cambio a través de los enlaces variables.

I see SNMP_IPC_READ_ERROR messages when the SNMP process restarts on my system and also during Routing Engine switchover. Is this acceptable?

Sí, es aceptable ver SNMP_IPC_READ_ERROR los mensajes cuando se reinicia el proceso SNMP, cuando el sistema se reinicia o durante un cambio de motor de enrutamiento. Si todos los procesos se activan correctamente y las operaciones SNMP funcionan correctamente, estos mensajes pueden pasarse por alto.

What is the source IP address used in the response PDUs for SNMP requests? Can this be configured?

La dirección IP de origen utilizada en las PDU de respuesta para las peticiones SNMP es la dirección IP de la interfaz de salida para llegar al destino. No se puede configurar la dirección IP de origen para respuestas. Solo se puede configurar para capturas.

Preguntas frecuentes sobre capturas y formularios SNMP

Esta sección presenta preguntas frecuentes y sus respuestas relacionadas con las interrupciones y los informes de SNMP.

Does the Junos OS impose any rate limiting on SNMP trap generation?

El Junos OS implementa un mecanismo de cola de interrupción para limitar el número de capturas que se generan y envían.

Si se produce un error en la entrega de captura, la captura se vuelve a agregar a la cola, y se restablecen el contador de entregas y el siguiente temporizador de intentos de entrega para la cola. Los intentos subsiguientes se producen a intervalos progresivos de 1, 2, 4 y 8 minutos. El retraso máximo entre los intentos es de 8 minutos y el número máximo de intentos es 10. Después de 10 intentos fallidos, la cola de destino y todas las capturas de la cola se eliminan.

Junos OS también dispone de un mecanismo de umbral de acelerador para controlar el número de capturas enviadas (predeterminado 500 capturas) durante un intervalo de limitación específico (predeterminado, 5 segundos). Esto ayuda a garantizar la coherencia en el tráfico de capturas, especialmente cuando se generan muchas capturas debido a cambios de estado en las interfaces.

El intervalo de limitación comienza cuando la primera captura llega al acelerador. Todas las capturas que se encuentran dentro del valor de umbral del acelerador se procesan y las capturas que superan el valor de umbral se ponen en cola. El tamaño máximo de todas las colas de captura (la cola de límite y la cola de destino) es 40.000 capturas. El tamaño máximo de una cola es de 20.000 capturas. Cuando se agrega una captura a la cola de limitación o si la cola supera el tamaño máximo, la captura se mueve a la parte superior de la cola de destino. Es más que intentar enviar la captura de la cola de destino se detiene durante un periodo de 30 segundos, después del cual la cola de destino se reinicia enviando las capturas.

Nota:

Para el conmutador Ethernet Juniper Networks EX Series, el tamaño máximo de todas las colas de captura (la cola de límite y la cola de destino) es 1.000 capturas. El tamaño máximo para cualquier cola de la serie EX es 500 capturas.

I did not see a trap when I had a syslog entry with a critical severity. Is this normal? Can it be changed?

No todas las entradas de syslog con gravedad crítica son interrupciones. Sin embargo, puede convertir cualquier entrada de syslog en una captura a event-options través de la instrucción.

En el siguiente ejemplo se muestra cómo configurar jnxSyslogTrap un elemento rpd_ldp_nbrdown cuando se produce un error en un mensaje de entrada syslog.

Are SNMP traps compliant with the Alarm Reporting Function (X.733) on the Junos OS?

No, las interrupciones SNMP en el Junos OS no son compatibles con la X. 733.

Can I set up filters for traps or informs?

Las capturas e informes se pueden filtrar según la categoría de captura y el identificador de objeto. Puede especificar las categorías de capturas que recibirá cada host mediante la categories instrucción en el [edit snmp trap-group trap-group] nivel de jerarquía. Utilice esta opción cuando desee supervisar solo módulos específicos de la Junos OS.

El ejemplo siguiente muestra una configuración de ejemplo para la linkrecepción vrrp-eventsde servicesúnicamente, otn-alarms , y Trap:

El Junos OS también tiene una opción de filtro más avanzadanotify-filter() para filtrar capturas específicas o un grupo de capturas según sus identificadores de objeto.

La configuración de SNMPv3 también admite el filtrado de capturas de SNMPv1 y SNMPv2, y la exclusión de Juniper Networks capturas de administración de configuraciones específicas de empresa, como se muestra en el siguiente ejemplo de configuración:

Can I simulate traps on a device?

Sí, puede usar el comando para simular una captura en el NMS que normalmente recibe las capturas request snmp spoof-trap trap name de su dispositivo. También puede Agregar los valores requeridos con el variable-bindings parámetro.

El siguiente ejemplo muestra cómo simular un reventado en el NMS local mediante enlaces variables:

How do I generate a warm start SNMPv1 trap?

Cuando el proceso SNMP se reinicia en condiciones normales, se genera una captura de inicio cálido si el tiempo de funcionamiento del sistema es superior a 5 minutos. Si el tiempo de funcionamiento del sistema es inferior a 5 minutos, se generará una captura de inicio frío.

The NMS sees only the MIB OIDs and numbers, but not the names of the SNMP traps. Why?

Antes de que la NMS pueda reconocer los detalles de la captura SNMP, como los nombres de las capturas, primero debe compilar y comprender las MIB y, a continuación, analizar el BIA OID.

In the Junos OS, how can I determine to which category a trap belongs?

Para obtener una lista de interrupciones comunes y sus categorías, consulte capturas de SNMP específicas de la empresa compatibles con Junos os.

Can I configure a trap to include the source IP address?

Sí, puede configurar el, source-addressel routing-instanceo logical-instance el nombre de dirección IP de origen utilizando el trap-options comando:

Can I create a custom trap?

Sí, puede utilizar la jnxEventTrap secuencia de eventos para crear capturas personalizadas, según sea necesario.

En el ejemplo siguiente, se activa un script de operaciones de Junos OS (OP) cuando UI_COMMIT_NOT_CONFIRMED se recibe un suceso. La secuencia de comandos Junos OS OP coincide con el mensaje completo del suceso y genera una captura SNMP.

Ejemplo Script OP Junos OS

Después de crear la captura personalizada, debe configurar una directiva en el dispositivo para indicar al dispositivo qué acciones debe realizar después de recibir la captura.

A continuación, se muestra un ejemplo de una directiva [edit event-options] configurada en la jerarquía:

Can I disable link up and link down traps on interfaces?

Sí, las capturas de enlace y vínculo hacia abajo pueden desactivarse en la configuración de interfaz. Para deshabilitar las capturas, utilice no-traps la instrucción en [edit interfaces interface-name unit logical-unit-number] el [edit logical-systems logical-system-name interfaces interface-name unit logical-unit-number] y las jerarquías de las interfaces físicas y lógicas.

I see the link up traps on logical interfaces, but I do not see the link down traps. Is this normal behavior?

En el caso de los tipos de interfaces Ethernet y ATM, Junos OS no envía trampas de conexión hacia abajo para una interfaz lógica si la interfaz física está inactiva para evitar alarmas de inundación para la misma causa raíz. Sin embargo, cuando la interfaz física y las interfaces lógicas vuelven a aparecer, se envían capturas que indican el vínculo hacia arriba. Esto se debe a que la interfaz física que se va a crear no significa necesariamente que también están llegando a las interfaces lógicas.

Para los tipos SONET de interfaces con encapsulación PPP, Junos OS envía capturas de enlace de vínculo inactivo para una interfaz lógica si la interfaz física está desactivada. Cuando la interfaz física y las interfaces lógicas aparecen, se envían capturas para las interfaces físicas y lógicas para indicar que se trata de una conexión.

Para los tipos SONET de interfaces con encapsulación HDLC, Junos OS no envía capturas de vínculos inactivos para una interfaz lógica si la interfaz física está desactivada. Cuando la interfaz física y las interfaces lógicas aparecen, se envían capturas para las interfaces físicas y lógicas para indicar que se trata de una conexión.

Para las interfaces de agrupación con encapsulación PPP, Junos OS envía capturas de vínculos desplegables de una interfaz lógica si la interfaz física está desactivada. Cuando la interfaz física y las interfaces lógicas aparecen, se envían capturas para las interfaces físicas y lógicas para indicar que se trata de una conexión.

Para las interfaces de canalización con encapsulación HDLC, Junos OS no envía capturas de vínculos inactivos para una interfaz lógica si la interfaz física está inactiva. Cuando la interfaz física y las interfaces lógicas aparecen, se envían capturas para las interfaces físicas y lógicas para indicar que se trata de una conexión.

Preguntas frecuentes sobre la configuración de Junos OS dos motor de enrutamiento

En esta sección se presentan preguntas frecuentes y sus respuestas relacionadas con la configuración de los motores de doble enrutamiento.

La configuración de SNMP debe ser idéntica entre los motores de enrutamiento al configurar una comunicación continua. Sin embargo, es recomendable tener configurados identificadores de motor de enrutamiento independientes para cada motor de enrutamiento, al usar SNMPv3.

In my system, the MIB object snmpEngineBoots is not in sync between two Routing Engines in a dual Routing Engine device. Is this normal behavior?

Así. Éste es el comportamiento normal. Cada motor de enrutamiento ejecuta su propio agente de proceso SNMP (snmpd), lo que permite a cada motor de enrutamiento mantener sus propios arranques de motor.

Is there a way to identify that an address belongs to RE0, RE1, or the master Routing Engine management interface (fxp0) by looking at an SNMP walk?

No. Cuando realice un recorrido SNMP en el dispositivo, solo muestra la dirección de interfaz motor de enrutamiento principal.

What is the best way to tell if the current IP address belongs to fxp0 or a Routing Engine, from a CLI session?

Los motores de enrutamiento se asignan con la fxp0 interfaz. Esto significa que cuando se consulta RE0, el ifTable informa de fxp0 la dirección de interfaz de RE0 solo. De manera similar, si consulta RE1, el ifTable informa fxp0 de la dirección de interfaz de Re1 solo.

When there is a failover, the master hostname is changed since the hostname belongs to the Routing Engine. Is this correct?

Así. Puede configurar el mismo nombre de host o distintos nombres de host. Puede funcionar.

Si solo está configurada la dirección IP principal (por ejemplo, 192.168.2.5), y el objeto tiene la misma cadena configurada en ambos motores de enrutamiento, incluso después de un cambio, el objeto devuelve el mismo sysDescr.0sysDescr.0 valor. El siguiente ejemplo muestra los resultados que se obtienen utilizando el snmpget comando:

Soporte de SNMP para instancias de enrutamiento preguntas más frecuentes

En esta sección se presentan preguntas frecuentes y sus respuestas relacionadas con el modo en que SNMP admite las instancias de enrutamiento.

Can the SNMP manager access data for routing instances?

Sí, la Junos OS permite a los administradores de SNMP para que todas las instancias de enrutamiento soliciten y administren los datos de SNMP relacionados con las instancias de enrutamiento y las redes de sistema lógicas correspondientes.

En función de la procedencia de los clientes, pueden producirse dos comportamientos de instancias de enrutamiento diferentes:

  • Los clientes de instancias de enrutamiento distintas a la predeterminada pueden tener acceso a BIA objetos y realizar operaciones SNMP únicamente en las redes de sistema lógicas a las que pertenecen.

  • Los clientes de la instancia de enrutamiento predeterminada pueden tener acceso a la información relacionada con todas las instancias de enrutamiento y redes de sistema lógicas.

Las instancias de enrutamiento se identifican mediante el campo de contexto en solicitudes de SNMPv3 o se codifican en la cadena de comunidad en las solicitudes de SNMPv1 o SNMPv2c.

Cuando se codifica en una cadena de comunidad, el nombre de la instancia de enrutamiento aparece primero y está separado de la cadena comunitaria real por el carácter @.

Para evitar conflictos con cadenas de comunidad válidas que contengan el carácter @, la comunidad se analiza únicamente si falla el procesamiento típico de cadenas de comunidad. Por ejemplo, si una instancia de enrutamiento RI denominada está configurada, una RI@public solicitud SNMP con se procesa en el RI contexto de la instancia de enrutamiento. El control de acceso (incluidas las vistas, las restricciones de dirección de origen y los privilegios de acceso) se aplica de acuerdo con la cadena de comunidad real (el conjunto de datos después del carácter @, en este public caso). Sin embargo, si la cadena RI@public de comunidad está configurada, la PDU se procesa de acuerdo con esa comunidad y se omite el nombre de instancia de enrutamiento incrustado.

Los sistemas lógicos realizan un subconjunto de las acciones de un enrutador físico y tienen sus propias tablas, interfaces, políticas y instancias de enrutamiento propias. Cuando se define una instancia de enrutamiento dentro de un sistema lógico, el nombre del sistema lógico se debe codificar junto con la instancia de enrutamiento mediante una barra diagonal (/) para separar ambas. Por ejemplo, si la instancia RI de enrutamiento se configura dentro del sistema LSlógico, dicha instancia debe codificarse dentro de una cadena de comunidad como LS/RI@public. Cuando una instancia de enrutamiento se configura fuera de un sistema lógico (dentro del sistema lógico predeterminado), no es necesario ningún / nombre de sistema lógico ni carácter.

Además, cuando se crea un sistema lógico, siempre se crea una instancia default de enrutamiento predeterminada con el nombre del sistema lógico. Este nombre debe utilizarse, por ejemplo LS/default@public, al consultar los datos de esa instancia de enrutamiento. Para las solicitudes SNMPv3, el logical system/routing instance nombre debe identificarse directamente en el campo de contexto.

Can I access a list of all routing instances on a device?

Sí, puede tener acceso a una lista de todas las instancias de enrutamiento de un dispositivo utilizando el objeto vacmContextName en el BIA-ACM-BASED-VIEW de SNMP. En SNMP, cada instancia de distribución se convierte en un contexto VACM; Esta es la razón por la que las instancias de ruta aparecen en el objeto vacmContextName.

Can I access a default routing instance from a client in another logical router or routing instance?

No, el agente SNMP solo puede tener acceso a los datos del enrutador lógico al que está conectado.

Preguntas frecuentes de los contadores SNMP

En esta sección se presentan preguntas frecuentes y sus respuestas relacionadas con los contadores SNMP.

Which MIB should I use for interface counters?

La administración de interfaces a través de SNMP se basa en dos tablas: el ifTable y su extensión ifXTable. Ambos se describen en RFC 1213, base de información de administración para la administración de red de Internet basada en TCP/IP: BIA-II y RFC 2233, El grupo de interfaces BIA utiliza SMIv2.

Las interfaces pueden tener varias capas, dependiendo del medio, y cada subcapa se representa mediante una fila independiente en la tabla. La relación entre la capa superior y las capas inferiores se describe en ifStackTableel.

El ifTable define los contadores de 32 bits para los octetos entrantes y salientes (IfInOctets/ifOutOctets), los paquetes (IfInUcastPkts/IfOutUcastPkts, ifInNUcastPkts/ifOutNUcastPkts), los errores y los descartes.

El ifXTable proporciona contadores similares de 64 bits, también denominados contadores de gran capacidad (HC), para los octetos entrantes y salientes (IfHCInOctets/ifHCOutOctets) y los paquetes entrantes (ifHCInUcastPkts).

When should 64-bit counters be used?

Siempre resulta conveniente utilizar contadores de 64 bits, ya que contienen estadísticas tanto de componentes de baja como de alta capacidad.

Are the SNMP counters ifInOctets and ifOutOctets the same as the command reference show interfaces statistics in and out counters?

Sí, son iguales, pero solo si SNMP está habilitado cuando se inicia el enrutador. Si enciende un dispositivo Juniper Networks y, a continuación, activa SNMP, los contadores SNMP empiezan por 0. Los contadores SNMP no reciben de forma automática sus estadísticas show de la salida del comando. De forma similar, clear statistics el uso del comando no borra las estadísticas recopiladas por los contadores SNMP, lo que puede ocasionar discrepancias en los datos que se observan en ambos procesos.

Do the SNMP counters ifInOctets and ifOutOctets include the framing overhead for Point-to-Point Protocol (PPP) and High-Level Data Link Control (HDLC)?

Así.

Gestión de interrupciones e informes

Las secciones siguientes contienen algunas sugerencias para administrar las notificaciones SNMP:

Generación de reventados basados en eventos SysLog

Las políticas de eventos pueden incluir una acción que genere capturas de eventos basados en mensajes de registro del sistema. Esta función permite la notificación de una aplicación basada en capturas de SNMP cuando se produce un mensaje importante de registro del sistema. Puede convertir cualquier mensaje de registro del sistema, para el que no haya un reventado correspondiente, en un reventado. Si utiliza capturas del sistema de administración de red en lugar de mensajes de registro del sistema para supervisar la red, puede utilizar esta función para asegurarse de que se le notifican todos los eventos principales.

Para configurar una directiva que provoque un reventado al recibir un evento, incluya las siguientes instrucciones en [edit event-options policy policy-name] el nivel de jerarquía:

El ejemplo siguiente muestra la configuración de ejemplo para provocar un reventado ui_mgd_terminatepara el evento:

Generación de reventados basados en eventos SysLog

Filtrar las capturas basadas en la categoría de captura

Las capturas SNMP se clasifican en varias categorías. El Junos OS proporciona una opción de configuración categories , en [edit snmp trap-group trap-group] el nivel de la jerarquía, que le permite especificar las categorías de capturas que desea recibir en un host determinado. Puede utilizar esta opción si desea supervisar solo módulos específicos de la Junos OS.

El ejemplo siguiente muestra una configuración de ejemplo para la linkrecepción vrrp-eventsde servicesúnicamente, otn-alarms , y Trap:

Filtrar las capturas según el identificador de objeto

El Junos OS también proporciona una opción de filtro más avanzada que le permite filtrar capturas específicas en función de sus identificadores de objeto. Puede utilizar la notify-filter opción para filtrar un reventado específico o un grupo de capturas.

El ejemplo siguiente muestra la configuración de ejemplo para excluir Juniper Networks capturas de administración de configuraciones específicas de la empresa (tenga en cuenta que la configuración de SNMPv3 también admite el filtrado de capturas de SNMPv1 y SNMPv2 como se muestra en el ejemplo siguiente) :