- play_arrow Descripción general
- play_arrow Características de operación, administración y administración
- play_arrow OAM de Ethernet y administración de fallos de conectividad para enrutadores
- Introducción a la administración de errores de conectividad (CFM) de OAM
- Configurar la administración de errores de conectividad (CFM)
- Perfil de acción de CFM
- Interfaz de administración local Ethernet
- Soporte CFM para paquetes encapsulados CCC
- Configurar ISSU unificada para 802.1ag CFM
- Monitoreo CFM entre dispositivos CE y PE
- Configurar mensajes de comprobación de continuidad
- Ejemplo: Configurar Ethernet CFM en interfaces físicas
- Ejemplo: Configurar Ethernet CFM en conexiones de puente
- Ejemplo: Configurar Ethernet CFM a través de VPLS
- play_arrow Administración de fallos de vínculo para enrutadores
- play_arrow Administración de fallos de vínculo OAM Ethernet para conmutadores
- play_arrow Administración de errores de conectividad OAM Ethernet para conmutadores
- play_arrow Retardo de trama Ethernet
- Mediciones de retardo de trama Ethernet en conmutadores
- Configurar interfaces MEP en conmutadores para que admitan mediciones de retardo de trama Ethernet (procedimiento de CLI)
- Configuración de mediciones de retardo de trama Ethernet unidireccional en conmutadores (procedimiento de CLI)
- Configurar un perfil de iterador en un conmutador (procedimiento de CLI)
- Activar una sesión de medición de retardo de trama Ethernet en un conmutador
- Configuración de mediciones de retardo de trama Ethernet bidireccional en conmutadores (procedimiento de CLI)
- play_arrow Oam del servicio Ethernet (ITU-ty.1731) para enrutadores
- Visión general de OAM del servicio Ethernet ITU-T Y.1731
- Configurar sesiones de medición de retardo de trama Ethernet
- Configuración de interfaces MEP para admitir mediciones de retardo de trama Ethernet
- Configurar la medición de pérdida de tramas Ethernet
- Configurar un perfil de iterador
- Configurar mediciones de pérdida sintética Ethernet
- Indicación de alarma Ethernet
- Modo de transmisión en línea
-
- play_arrow Monitoreo remoto de red (RMON) con alarmas y eventos SNMP
- play_arrow Opciones de contabilidad
- play_arrow Opciones de monitoreo
- play_arrow Alarmas de interfaz
- play_arrow Monitoreo de IP
- play_arrow Tecnología de monitoreo de sFlow
- play_arrow Muestreo adaptable para enrutadores y conmutadores
- play_arrow Software de diagnóstico del acelerador de flujo de paquetes
-
- play_arrow Supervisión de características de seguridad comunes
- play_arrow Gestión del rendimiento
- play_arrow Imitación de puerto
- play_arrow Duplicación de puertos y analizadores
- Duplicación de puertos y analizadores
- Configuración de analizadores y duplicación de puertos
- Configuración de instancias de creación de reflejo de puertos
- Configuración de la duplicación de puertos en interfaces físicas
- Configuración de la creación de reflejo de puertos en interfaces lógicas
- Configuración de la duplicación de puertos para varios destinos
- Configuración de la duplicación de puertos para destinos remotos
- Configuración del análisis local y remoto de creación de reflejo de puertos
- Duplicación de puerto 1:N a múltiples destinos en conmutadores
- Ejemplo: Configurar la creación de reflejo de puertos con familia cualquiera y un filtro de firewall
- Supervisión de la duplicación de puertos
- Configurar la duplicación de paquetes con encabezados de capa 2 para el tráfico reenviado de capa 3
- Solución de problemas de duplicación de puertos
-
- play_arrow Mensajes de registro del sistema
- Información general sobre el registro del sistema
- Registro del sistema en un sistema de chasis único
- Dirija los mensajes de registro del sistema a un destino remoto
- Comprobar los comandos que introducen los usuarios
- Mostrar archivos de registro del sistema
- Configurar el registro del sistema para dispositivos de seguridad
- Configurar Syslog a través de TLS
- Supervisar mensajes de registro
- play_arrow Administración de red y solución de problemas
- Comprimir los registros de solución de problemas de /var/logs para enviarlos al soporte técnico de Juniper Networks
- Monitoreo y solución de problemas
- Solución de problemas del rendimiento del sistema con la metodología de monitoreo de recursos
- Configuración de las opciones de depuración y rastreo de rutas de datos
- Uso de MPLS para diagnosticar LSP, VPN y circuitos de capa 2
- Uso de la captura de paquetes para analizar el tráfico de red
- Descripción general de On-Box Packet Sniffer
- Solución de problemas de dispositivos de seguridad
- play_arrow Instrucciones de configuración y comandos operativos
Descripción de la implementación de SNMP en Junos OS
SNMP en Junos OS
En Junos OS, SNMP utiliza MIB estándar (desarrollado por IETF y documentado en RFC) y específico de 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 reside en el dispositivo administrado y es administrado por el NMS o host.
El software del agente SNMP de Junos OS consta de un agente principal SNMP (conocido como proceso SNMP o snmpd). Reside en el dispositivo administrado y es administrado por el NMS o el host.
Varios subagentes que residen en distintos módulos de Junos OS, como el motor de enrutamiento. El agente SNMP principal delega todas las solicitudes SNMP a los subagentes. Cada subagente es responsable del soporte de un conjunto específico de MIB.
Junos OS procesa que comparten datos con los subagentes cuando se sondean los datos SNMP (por ejemplo, MIB relacionadas con la 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 de Junos OS con versiones SNMP
- Niveles de gravedad del registro del sistema para capturas SNMP
- Flujo de comunicación SNMP
- Cola de trampas
Compatibilidad de Junos OS con versiones SNMP
Junos OS admite las siguientes versiones de SNMP. Para obtener más información, consulte Tabla 1.
Versiones de SNMP | Description |
---|---|
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 gerente a gerente. En concreto, SNMPv2c implementa cadenas de comunidad, que actúan como contraseñas para determinar quién, qué y cómo los clientes SNMP pueden acceder a los datos en el agente SNMP. La cadena de comunidad se encuentra en SNMP |
SNMPv3 | 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 de 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 del registro del sistema para capturas SNMP
Para algunas capturas, cuando se produce una condición de interrupción, 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 del 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 primario en busca de datos, el agente primario comparte inmediatamente los datos con el NMS si los datos solicitados están disponibles del agente primario o de uno de los subagentes. Sin embargo, si los datos solicitados no pertenecen a las categorías que mantienen 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 requeridos, el subagente devuelve la respuesta al agente primario, que a su vez la pasa al NMS.
Figura 1 muestra el flujo de comunicación entre el NMS, el agente principal SNMP (snmpd), los subagentes SNMP, el kernel de Junos OS y el motor de reenvío de paquetes.

Cuando se produce un evento importante, 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: atrapa e informa. Las trampas son notificaciones no confirmadas, mientras que los informes son notificaciones confirmadas. Los informes solo se admiten en dispositivos compatibles con la configuración SNMP versión 3 (SNMPv3).
Cola de trampas
Junos OS admite la cola de capturas para garantizar que las capturas no se pierdan debido a la indisponibilidad temporal de las rutas. Se forman dos tipos de colas, colas de destino y una cola de acelerador, para garantizar la entrega de trampas y controlar el tráfico de capturas.
No puede configurar las colas de captura en Junos OS. No puede ver información sobre las colas de capturas, excepto 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 no se puede acceder al host, y agrega las capturas posteriores al mismo destino a la cola. Junos OS comprueba la disponibilidad de las rutas cada 30 segundos y envía las capturas desde la cola de destino de forma rotativa.
Si se produce un error en la entrega de capturas, la captura se vuelve a agregar a la cola y se restablecen el contador de intentos de entrega y el temporizador del siguiente intento de entrega de la cola. Los intentos posteriores ocurren 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 de 10. Después de 10 intentos fallidos, se eliminan la cola de destino y todas las capturas de la cola.
Junos OS también tiene un mecanismo de aceleración para controlar el número de capturas (umbral del acelerador; valor predeterminado de 500 capturas) enviadas durante un período de tiempo determinado (intervalo del acelerador; valor predeterminado de 5 segundos) y para garantizar la coherencia en el tráfico de capturas, especialmente cuando se genera un gran número de capturas debido a cambios de estado de la interfaz. El período de intervalo del acelerador comienza cuando la primera trampa llega al acelerador. Todas las interrupciones dentro del umbral de captura se procesan y las capturas que superan el límite de umbral se ponen en cola.
El tamaño máximo de las colas de captura, es decir, la cola del acelerador y la cola de destino juntas, 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 1.000. El tamaño máximo de cualquier cola es de 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 del acelerador, o si la cola del acelerador ha superado el tamaño máximo, la captura se vuelve a agregar encima 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 capturas.
Carga de archivos MIB en 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 el NMS mediante un compilador MIB. Un compilador MIB es una utilidad que analiza la información MIB, como el nombre del objeto MIB, los ID y el tipo de datos del NMS.
Puede descargar el paquete MIB de Junos desde el índice MIB empresariales de Junos OS en https://www.juniper.net/documentation/en_US/release-independent/junos/mibs/mibs.html . El paquete Junos MIB está disponible en .zip y .tar paquetes. Puede descargar el formato adecuado según sus requisitos.
El paquete MIB de Junos 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 supervisar dispositivos que ejecutan Junos OS:
Al cargar un archivo MIB, si el compilador devuelve un mensaje de error que indica que alguno 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 estén cargados 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, la MIB de PING específica de la empresa, mib-jnx-ping.txt, tiene dependencias en 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. Cargue mib-rfc2925a.txty, a continuación, intente cargar mib-jnx-ping.txt. A continuación, se carga sin problemas la MIB PING específica de la empresa. mib-jnx-ping.txt
Descripción de la interfaz de administración local integrada
La Interfaz de administración local integrada (ILMI) proporciona un mecanismo para que los dispositivos conectados al modo de transferencia asíncrono (ATM), como hosts, enrutadores y conmutadores ATM, transfieran información de administración. ILMI proporciona un intercambio bidireccional de información de administración entre dos interfaces ATM a través de una conexión física. La información de ILMI se intercambia a través de una encapsulación directa de SNMP versión 1 (RFC 1157, A Simple Network Management Protocol) a través de ATM Adaptation Layer 5 (AAL5) utilizando un valor de identificador de ruta virtual/identificador de canal virtual (VPI/VCI) (VPI=0, VCI=16).
Junos OS solo admite dos variables ILMI MIB:
atmfMYIPNmAddress
atmfPortMyIfname
Para las interfaces de cola inteligente (IQ) ATM1 y ATM2, puede configurar la ILMI para que se comunique directamente con un conmutador ATM conectado a fin de permitir la consulta de la dirección IP y el número de puerto del conmutador.
Para obtener más información acerca de la MIB de ILMI, consulte atmfMYIPNmAddress
o atmfPortMyIfname
en el Explorador de MIB de SNMP.