Understand SNMP Implementation in Junos OS

Junos OS Support for SNMP Versions

The Junos OS supports the following versions of SNMP. For more information, see Table 1.

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.

Figure 1: SNMP Communication Flow

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.

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.