- play_arrow Overview
- play_arrow Operation, Administration, and Management Features
- play_arrow Ethernet OAM and Connectivity Fault Management for Routers
- Introduction to OAM Connectivity Fault Management (CFM)
- Configure Connectivity Fault Management (CFM)
- CFM Action Profile
- Ethernet Local Management Interface
- CFM Support for CCC Encapsulated Packets
- Configure Unified ISSU for 802.1ag CFM
- CFM Monitoring between CE and PE Devices
- Configure Continuity Check Messages
- Example: Configure Ethernet CFM on Physical Interfaces
- Example: Configure Ethernet CFM on Bridge Connections
- Example: Configure Ethernet CFM over VPLS
- play_arrow Link Fault Management for Routers
- play_arrow Ethernet OAM Link Fault Management for Switches
- play_arrow Ethernet OAM Connectivity Fault Management for Switches
- play_arrow Ethernet Frame Delay
- Ethernet Frame Delay Measurements on Switches
- Configure MEP Interfaces on Switches to Support Ethernet Frame Delay Measurements (CLI Procedure)
- Configure One-Way Ethernet Frame Delay Measurements on Switches (CLI Procedure)
- Configure an Iterator Profile on a Switch (CLI Procedure)
- Trigger an Ethernet Frame Delay Measurement Session on a Switch
- Configure Two-Way Ethernet Frame Delay Measurements on Switches (CLI Procedure)
- play_arrow Ethernet Service OAM (ITU-TY.1731) for Routers
- ITU-T Y.1731 Ethernet Service OAM Overview
- Configure Ethernet Frame Delay Measurement Sessions
- Configuring MEP Interfaces to Support Ethernet Frame Delay Measurements
- Configure Ethernet Frame Loss Measurement
- Configure an Iterator Profile
- Configure Ethernet Synthetic Loss Measurements
- Ethernet Alarm Indication
- Inline Transmission Mode
-
- play_arrow Remote Network Monitoring (RMON) with SNMP Alarms and Events
- play_arrow Accounting Options
- play_arrow Monitoring Options
- play_arrow Interface Alarms
- play_arrow IP Monitoring
- play_arrow sFlow Monitoring Technology
- play_arrow Adaptive Sampling for Routers and Switches
- play_arrow Packet Flow Accelerator Diagnostics Software
-
- play_arrow Monitoring Common Security Features
- play_arrow Performance Management
- play_arrow Port Mirroring
- play_arrow Port Mirroring and Analyzers
- Port Mirroring and Analyzers
- Configuring Port Mirroring and Analyzers
- Configuring Port Mirroring Instances
- Configuring Port Mirroring on Physical Interfaces
- Configuring Port Mirroring on Logical Interfaces
- Configuring Port Mirroring for Multiple Destinations
- Configuring Port Mirroring for Remote Destinations
- Configuring Port Mirroring Local and Remote Analysis
- 1:N Port Mirroring to Multiple Destinations on Switches
- Example: Configure Port Mirroring with Family any and a Firewall Filter
- Monitoring Port Mirroring
- Configure Packet Mirroring with Layer 2 Headers for Layer 3 Forwarded Traffic
- Troubleshooting Port Mirroring
-
- play_arrow System Log Messages
- play_arrow Network Management and Troubleshooting
- Compressing Troubleshooting Logs from /var/logs to Send to Juniper Networks Technical Support
- Monitoring and Troubleshooting
- Troubleshooting System Performance with Resource Monitoring Methodology
- Configuring Data Path Debugging and Trace Options
- Using MPLS to Diagnose LSPs, VPNs, and Layer 2 Circuits
- Using Packet Capture to Analyze Network Traffic
- On-Box Packet Sniffer Overview
- Troubleshooting Security Devices
- play_arrow Configuration Statements and Operational Commands
Understand SNMP Implementation in Junos OS
SNMP on Junos OS
On Junos OS, SNMP uses both standard (developed by the IETF and documented in RFCs) and Juniper Networks enterprise-specific MIBs.
By default, SNMP is not enabled on devices running Junos OS.
In Junos OS, the processes that maintain the SNMP management data include the following:
A master SNMP agent resides on the managed device and is managed by the NMS, or host.
The Junos OS SNMP agent software consists of an SNMP primary agent (known as the SNMP process, or snmpd). It resides on the managed device and is managed by the NMS or host.
Various subagents that reside on different modules of Junos OS, such as the Routing Engine. The master SNMP agent delegates all SNMP requests to the subagents. Each subagent is responsible for the support of a specific set of MIBs.
Junos OS processes that share data with the subagents when polled for SNMP data (for example, interface-related MIBs).
The community string is the first level of management authentication implemented by the SNMP agent in Junos OS.
See the following sections for more information.
- Junos OS Support for SNMP Versions
- System Logging Severity Levels for SNMP Traps
- SNMP Communication Flow
- Trap Queuing
Junos OS Support for SNMP Versions
The Junos OS supports the following versions of SNMP. For more information, see Table 1.
SNMP Versions | Description |
---|---|
SNMPv1 | The initial implementation of SNMP that defines the architecture and framework for SNMP. |
SNMPv2c | The revised protocol, with improvements to performance and
manager-to-manager communications. Specifically, SNMPv2c
implements community strings, which act as passwords when
determining who, what, and how the SNMP clients can access the
data in the SNMP agent. The community string is contained in
SNMP |
SNMPv3 | SNMPv3—The most up-to-date protocol focuses on security. SNMPv3 defines a security model, a user-based security model (USM), and a view-based access control model (VACM). SNMPv3 USM provides data integrity, data origin authentication, message replay protection, and protection against disclosure of the message payload. SNMPv3 VACM provides access control to determine whether a specific type of access (read or write) to the management information is allowed. |
In addition, the Junos OS SNMP agent software accepts IPv4 and IPv6 addresses for transport over IPv4 and IPv6. For IPv6, the Junos OS supports the following features:
SNMP data over IPv6 networks
IPv6-specific MIB data
SNMP agents for IPv6
System Logging Severity Levels for SNMP Traps
For some traps, when a trap condition occurs, regardless of whether the SNMP agent sends a trap to an NMS, the trap is logged if the system logging is configured to log an event with that system logging severity level.
For more information about system logging severity levels for standard traps, see Standard SNMP Traps Supported by Junos OS . For more information about system logging severity levels for enterprise-specific traps, see Enterprise-Specific SNMP Traps Supported by Junos OS.
SNMP Communication Flow
When an NMS polls the primary agent for data, the primary agent immediately shares the data with the NMS if the requested data is available from the primary agent or one of the subagents. However, if the requested data does not belong to those categories that are maintained by the primary agent or the subagents, the subagent polls the Junos OS kernel or the process that maintains that data. On receiving the required data, the subagent passes the response back to the primary agent, which in turn passes it to the NMS.
Figure 1 shows the communication flow among the NMS, SNMP primary agent (snmpd), SNMP subagents, Junos OS kernel, and the Packet Forwarding Engine.

When a significant event, most often an error or a failure, occurs on a network device, the SNMP agent sends notifications to the SNMP manager. The SNMP implementation in Junos OS supports two types of notifications: traps and informs. Traps are unconfirmed notifications, whereas informs are confirmed notifications. Informs are supported only on devices that support SNMP version 3 (SNMPv3) configuration.
Trap Queuing
Junos OS supports trap queuing to ensure that traps are not lost because of the temporary unavailability of routes. Two types of queues, destination queues and a throttle queue, are formed to ensure the delivery of traps and control the trap traffic.
You cannot configure trap queueing in Junos OS. You cannot view information about trap queues except for what is provided in the system logs.
Junos OS forms a destination queue when a trap to a particular destination is returned because the host is not reachable, and adds the subsequent traps to the same destination to the queue. Junos OS checks for the availability of routes every 30 seconds and sends the traps from the destination queue in a round-robin fashion.
If the trap delivery fails, the trap is added back to the queue, and the delivery attempt counter and the next delivery attempt timer for the queue are reset. Subsequent attempts occur at progressive intervals of 1 minute, 2 minutes, 4 minutes, and 8 minutes. The maximum delay between the attempts is 8 minutes, and the maximum number of attempts is 10. After 10 unsuccessful attempts, the destination queue and all the traps in the queue are deleted.
Junos OS also has a throttle mechanism to control the number of traps (throttle threshold; default value of 500 traps) sent during a particular time period (throttle interval; default of 5 seconds) and to ensure consistency in trap traffic, especially when a large number of traps are generated because of interface status changes. The throttle interval period begins when the first trap arrives at the throttle. All traps within the trap threshold are processed, and the traps beyond the threshold limit are queued.
The maximum size of trap queues—that is, throttle queue and destination queue put together—is 40,000. However, on EX Series Ethernet Switches, the maximum size of the trap queue is 1,000. The maximum size of any one queue is 20,000 for devices other than EX Series Switches. On EX Series Switches, the maximum size of one queue is 500. When a trap is added to the throttle queue, or if the throttle queue has exceeded the maximum size, the trap is added back on top of the destination queue, and all subsequent attempts from the destination queue are stopped for a 30-second period, after which the destination queue restarts sending the traps.
Loading MIB Files to a Network Management System
For your network management system (NMS) to identify and understand the MIB objects used by the Junos OS, you must first load the MIB files to your NMS using a MIB compiler. A MIB compiler is a utility that parses the MIB information such as the MIB object name, IDs, and data type for the NMS.
You can download the Junos MIB package from the Junos OS Enterprise MIBs index at https://www.juniper.net/documentation/en_US/release-independent/junos/mibs/mibs.html . The Junos MIB package is available in .zip and .tar packages. You can download the appropriate format based on your requirements.
The Junos MIB package contains two folders: StandardMibs and JuniperMibs. The StandardMibs folder contains the standard MIBs and RFCs that are supported on devices running the Junos OS, whereas the JuniperMibs folder contains the Juniper Networks enterprise-specific MIBs.
To load MIB files that are required for managing and monitoring devices running the Junos OS:
While loading a MIB file, if the compiler returns an error message saying that any of the objects are undefined, open the MIB file using a text editor and ensure that all the MIB files listed in the IMPORT section are loaded on the compiler. If any of the MIB files listed in the IMPORT section are not loaded on the compiler, load that MIB file, and then try to load the MIB file that failed to load.
For example, the enterprise-specific PING MIB, mib-jnx-ping.txt, has dependencies on RFC 2925, DiSMAN-PING-MIB, mib-rfc2925a.txt. If you try to load mib-jnx-ping.txt before loading mib-rfc2925a.txt, the compiler returns an error message saying that certain objects in mib-jnx-ping.txt are undefined. Load mib-rfc2925a.txt, and then try to load mib-jnx-ping.txt. The enterprise-specific PING MIB, mib-jnx-ping.txt, then loads without any issue.
Understand the Integrated Local Management Interface
The Integrated Local Management Interface (ILMI) provides a mechanism for Asynchronous Transfer Mode (ATM)-attached devices, such as hosts, routers, and ATM switches, to transfer management information. ILMI provides a bidirectional exchange of management information between two ATM interfaces across a physical connection. ILMI information is exchanged over a direct encapsulation of SNMP version 1 (RFC 1157, A Simple Network Management Protocol) over ATM Adaptation Layer 5 (AAL5) using a virtual path identifier/virtual channel identifier (VPI/VCI) value (VPI=0, VCI=16).
Junos OS supports only two ILMI MIB variables:
atmfMYIPNmAddress
atmfPortMyIfname
For ATM1 and ATM2 intelligent queuing (IQ) interfaces, you can configure ILMI to communicate directly with an attached ATM switch to enable querying of the switch’s IP address and port number.
For more information about the
ILMI MIB, see atmfMYIPNmAddress
or atmfPortMyIfname
in the SNMP MIB
Explorer.