A network is a complex organization of nodes and processes that must operate reliably and efficiently. Having a single node or link failure in a network can undermine the network's performance and result in a loss of service. Therefore, determining where and when a network failure is occurring is a necessity.
Additionally, gathering statistics about how a network is performing can help you diagnose the overall health of the network and pinpoint bottlenecks so that you can address network growth appropriately.
By querying individual network nodes and receiving triggered updates, SNMP clients are able to provide valuable feedback about the state of a network.
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 they 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. 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.
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.
A set of MIBs has been defined by the IETF and documented in various RFCs. These MIBs are common across many platforms. Additionally, individual enterprises can create their own set of enterprise-specific MIBs, provided they share the same structure as the standard MIBs. This structure is enforced through the Abstract Syntax Notation (ASN), which is a definition language used to store information.
To download the standard and enterprise MIBs for a Services Router, go to https://www.juniper.net/techpubs/software/index_mibs.html.
Information is stored in MIBs, and MIBs are queried by SNMP managers. Managers send SNMP requests to process the information. SNMP requests come in two primary forms: get requests and set requests. These requests are processed by one or more agents on a particular node, and information is retrieved or modified on the MIB. When the agent has processed the request, it generates an SNMP response that either returns retrieved information from the MIB or acknowledges that information has been modified on the MIB.
To help ensure that only specific SNMP managers can access a particular SNMP agent, SNMP access is granted through communities. To control access, you first create an SNMP community. 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 has unsolicited notifications known as traps 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 enabling an SNMP trap-based application to be notified when an important event occurs. You can convert any system log message for which there are no corresponding traps into a trap. This feature helps you to use NMS traps rather than system log messages to monitor the network.
For more information about configuring an event policy action that raises traps, see Configuring Event Policies
For information about MIBs, see the JUNOS Network Management Configuration Guide.
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 J-series Services Router 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.