Use SNMP to determine where and when a network failure is occurring, and to gather statistics about network performance in order to evaluate the overall health of the network and identify bottlenecks.
Because SNMP is a client/server protocol, SNMP nodes can be classified as either clients (SNMP managers) or servers (SNMP agents). SNMP managers, also called network management systems (NMSs), occupy central points in the network and actively query and collect messages from SNMP agents in the network. SNMP agents are individual processes running on network nodes that gather information for a particular node and transfer the information to SNMP managers as queries are processed. The agent also controls access to the agent’s Management Information Base (MIB), the collection of objects that can be viewed or changed by the SNMP manager. Because SNMP agents are individual SNMP processes running on a host, multiple agents can be active on a single network node at any given time.
Communication between the agent and the manager occurs in one of the following forms:
Agents store information in a hierarchical database called the Structure of Management Information (SMI). The SMI resembles a file system. Information is stored in individual files that are hierarchically arranged in the database. The individual files that store the information are known as Management Information Bases (MIBs). Each MIB contains nodes of information that are stored in a tree structure. Information branches down from a root node to individual leaves in the tree, and the individual leaves comprise the information that is queried by managers for a given MIB. The nodes of information are identified by an object ID (OID). The OID is a dotted integer identifier (1.3.6.1.2.1.2, for instance) or a subtree name (such as interfaces) that corresponds to an indivisible piece of information in the MIB.
MIBs are either standard or enterprise-specific. Standard MIBs are created by the Internet Engineering Task Force (IETF) and documented in various RFCs. Depending on the vendor, many standard MIBs are delivered with the NMS software. You can also download the standard MIBs from the IETF Web site, http://www.ietf.org, and compile them into your NMS, if necessary.
For a list of standard and enterprise-specific supported MIBS, see the JUNOS Network Management Configuration Guide.
Enterprise-specific MIBs are developed and supported by a specific equipment manufacturer. If your network contains devices that have enterprise-specific MIBs, you must obtain them from the manufacturer and compile them into your network management software.
To download enterprise MIBs for a device, go to https://www.juniper.net/techpubs/software/index_mibs.html.
You can grant access to only specific SNMP managers for particular SNMP agents by creating SNMP communities. The community is assigned a name that is unique on the host. All SNMP requests that are sent to the agent must be configured with the same community name. When multiple agents are configured on a particular host, the community name process ensures that SNMP requests are sorted to only those agents configured to handle the requests.
Additionally, communities allow you to specify one or more addresses or address prefixes to which you want to either allow or deny access. By specifying a list of clients, you can control exactly which SNMP managers have access to a particular agent.
The get and set commands that SNMP uses are useful for querying hosts within a network. However, the commands do not provide a means by which events can trigger a notification. For instance, if a link fails, the health of the link is unknown until an SNMP manager next queries that agent.
SNMP traps are unsolicited notifications that are triggered by events on the host. When you configure a trap, you specify the types of events that can trigger trap messages, and you configure a set of targets to receive the generated messages.
SNMP traps enable an agent to notify a network management system (NMS) of significant events. You can configure an event policy action that uses system log messages to initiate traps for events. The traps enable an SNMP trap-based application to be notified when an important event occurs. You can convert any system log message that has no corresponding traps into a trap. This feature helps you to use NMS traps rather than system log messages to monitor the network.
You can use the request snmp spoof-trap operational mode command to mimic SNMP trap behavior. The contents of the traps (the values and instances of the objects carried in the trap) can be specified on the command line or they can be spoofed automatically. This feature is useful if you want to trigger SNMP traps and ensure they are processed correctly within your existing network management infrastructure, but find it difficult to simulate the error conditions that trigger many of the traps on the device. For more information, see the JUNOS System Basics and Services Command Reference.
The SNMP health monitor feature uses existing SNMP remote monitoring (RMON) alarms and traps to monitor a select set of Services Router characteristics (object instances) like the CPU usage, memory usage, and file system usage. The health monitor feature also monitors the CPU usage of the device's forwarding process (also called a daemon)—for example, the chassis process and forwarding process microkernel. You can configure the SNMP health monitor options rising threshold, falling threshold, and interval using the SNMP Quick Configuration page.
A threshold is a test of some SNMP variable against some value, with a report when the threshold value is exceeded. The rising threshold is the upper threshold for a monitored variable. When the current sampled value is greater than or equal to this threshold, and the value at the last sampling interval is less than this threshold, the SNMP health monitor generates an alarm. After the rising alarm, the health monitor cannot generate another alarm until the sampled value falls below the rising threshold and reaches the falling threshold.
The falling threshold is the lower threshold for the monitored variable. When the current sampled value is less than or equal to this threshold, and the value at the last sampling interval is greater than this threshold, the SNMP health monitor generates an alarm. After the falling alarm, the health monitor cannot generate another alarm until the sampled value rises above the falling threshold and reaches the rising threshold.
The interval represents the period of time, in seconds, over which the object instance is sampled and compared with the rising and falling thresholds.
At present, you do not have to configure a separate trap for the SNMP health monitor, because it uses the already existing RMON traps. For more information about RMON events and alarms, see the JUNOS Network Management Configuration Guide.
To display the information collected by the SNMP health monitor, use the following CLI show snmp health-monitor commands:
For more information, see the JUNOS System Basics and Services Command Reference.