Rate and give feedback:  Feedback Received. Thank You!

Rate and give feedback: 

X

This document helped resolve my issue

Yes No

Additional Comments

800 characters remaining

May we contact you if necessary?

Name:  

E-mail: 

Enter a valid Email ID

Need product assistance? Contact Juniper Support

Submit

This site is protected by hCaptcha and its Privacy Policy and Terms of Service apply.

English  

English

Understanding SNMP Implementation in Junos OS

• Managed device
• SNMP agent
• Network management system (NMS)

A managed device is any device on a network, also known as a network element, that is managed by the network management system. Routers and switches are common examples of managed devices. The SNMP agent is the SNMP process that resides on the managed device and communicates with the network management system. The NMS is a combination of hardware and software that is used to monitor and administer a network.

The SNMP data is stored in a highly-structured, hierarchical format known as a management information base (MIB). The MIB structure is based on a tree structure, which defines a grouping of objects into related sets. Each object in the MIB is associated with an object identifier (OID), which names the object. The “leaf” in the tree structure is the actual managed object instance, which represents a resource, event, or activity that occurs in your network device.

The SNMP agent exchanges network management information with SNMP manager software running on an NMS, or host. The agent responds to requests for information and actions from the manager. The agent also controls access to the agent’s MIB, the collection of objects that can be viewed or changed by the SNMP manager.

The SNMP manager collects information about network connectivity, activity, and events by polling managed devices.

• Get, GetBulk, and GetNext requests—The manager requests information from the agent. The agent returns the information in a Get response message.
• Set requests—The manager changes the value of a MIB object controlled by the agent. The agent indicates status in a Set response message.
• Traps notification—The agent sends traps to notify the manager of significant events that occur on the network device.

• A master SNMP agent (known as the SNMP process or snmpd) that 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, and are managed by the master SNMP agent (snmpd).

Note: By default, SNMP is not enabled on devices running Junos OS. For information about enabling SNMP on a device running the Junos OS, see Configuring SNMP on Devices Running Junos OS.

The SNMP implementation in Junos OS uses both standard (developed by the IETF and documented in RFCs) and enterprise-specific (developed and supported by specific vendors) MIBs.

In Junos OS, the management data is maintained by the snmpd at one level (for example, snmpVacmMIB and snmpUsmMIB), and the subagents at the next level (for example, routing MIBs and RMON MIBs). However, there is another level of data that is maintained neither by the master agent nor by the subagents. In such cases, the data is maintained by the Junos OS processes that share the data with the subagents when polled for SNMP data. Interface-related MIBs and Firewall MIBs are good examples of data maintained by Junos OS processes.

When a network mangement system polls the master agent for data, the master agent immediately shares the data with the network mangement system if the requested data is available with the master agent or one of the subagents. However, if the requested data does not belong to those categories that are maintained by the master 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 master agent, which in turn passes it to the NMS.

The following illustration shows the communication flow among the NMS, SNMP process (snmpd), SNMP subagents, and the Junos OS processes.

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.

Junos OS supports trap queuing to ensure that traps are not lost because of temporary unavailability of routes. Two types of queues, destination queues and a throttle queue, are formed to ensure delivery of traps and to 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 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 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.