Network Monitoring by using SNMP
SUMMARY This section describes the SNMP Implementation in Junos OS.
Understanding SNMP Implementation in Junos OS
SNMP Architecture
A typical SNMP implementation includes three components:
Network management system (NMS)—A combination of hardware (devices) and software (the SNMP manager) that is used to monitor and administer a network. The manager polls the devices on your network how ever often you specify for information about network connectivity, activity, and events.
Managed device—A managed device (also called a network element) is any device on a network that is managed by the NMS. Routers and switches are common examples of managed devices.
SNMP agent—The SNMP agent is the SNMP process that resides on the managed device and communicates with the NMS. The SNMP agent exchanges network management information with the 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.
This topic contains the following sections:
SNMP MIBs
SNMP data is stored in a highly structured, hierarchical format known as a management information base (MIB). A MIB defines managed objects in a network device.
The MIB structure is based on a tree structure and 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.
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 website, www.ietf.org, and compile them into your NMS, if necessary.
For a list of standard supported MIBs, see Standard SNMP MIBs Supported by Junos OS.
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.
For a list of Juniper Networks enterprise-specific supported MIBs, see Enterprise-Specific SNMP MIBs Supported by Junos OS.
SNMP Manager and Agent Authentication and Communication
SNMP uses a very basic form of authentication called community strings to control access between a manager and remote agents. Community strings are administrative names used to group collections of devices (and the agents running on them) into common management domains. If a manager and an agent share the same community, they can talk to one another. Many people associate SNMP community strings with passwords and keys because the jobs they do are similar. As a result, SNMP communities are traditionally referred to as strings.
Communication between the agent and the manager occurs in one of the following forms:
Get,GetBulk, andGetNextrequests—The manager requests information from the agent; the agent returns the information in aGetresponse message.Setrequests—The manager changes the value of a MIB object controlled by the agent; the agent indicates status in aSetresponse message.Trapsnotification—The agent sends traps to notify the manager of significant events that occur on the network device.
SNMP Traps and Informs
Routers can send notifications to SNMP managers when significant events occur on a network device, most often errors or failures. SNMP notifications can be sent as traps or inform requests. SNMP traps are unconfirmed notifications. SNMP informs are confirmed notifications.
SNMP traps are defined in either standard or enterprise-specific MIBs. Standard traps are created by the IETF and documented in various RFCs. The standard traps are compiled into the network management software. You can also download the standard traps from the IETF website, www.ietf.org.
For more information about standard traps supported by the Junos OS, see Standard SNMP Traps Supported on Devices Running Junos OS.
Enterprise-specific traps are developed and supported by a specific equipment manufacturer. If your network contains devices that have enterprise-specific traps, you must obtain them from the manufacturer and compile them into your network management software.
For more information about enterprise-specific traps supported by the Junos OS, see Enterprise-Specific SNMP Traps Supported by Junos OS. For information about system logging severity levels for SNMP traps, see System Logging Severity Levels for SNMP Traps.
With traps, the receiver does not send any acknowledgment when it receives a trap, and the sender cannot determine if the trap was received. To increase reliability, SNMP informs are supported in SNMPv3. An SNMP manager that receives an inform acknowledges the message with a response. For information about SNMP informs, see Configuring SNMP Informs.
SNMP on Junos OS
On Junos OS, SNMP uses both standard (developed by 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 which 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 of SNMP Versions
- System Logging Severity Levels for SNMP Traps
- SNMP Communication Flow
- Trap Queuing
Junos OS Support of SNMP Versions
The Junos OS supports the following versions of SNMP:
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
Get,GetBulk,GetNext, andSetrequests. The agent might require a different community string forGet,GetBulk, andGetNextrequests (read-onlyaccess) than it does forSetrequests (read-writeaccess).SNMPv3—The most up-to-date protocol focuses on security. SNMPv3 defines a security model, 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 a 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 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.
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 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.
Users cannot configure the Junos OS for trap queuing. Users cannot view any information about trap queues except what is available in the logged information.
SNMPv3 Overview
The QFX3500 switch supports SNMP version 3 (SNMPv3). SNMPv3 enhances the functionality of SNMPv1 and SNMPv2c by supporting user authentication and data encryption. SNMPv3 uses the user-based security model (USM) to provide security for SNMP messages, and the view-based access control model (VACM) for user access control.
SNMPv3 features include:
-
With USM, the SNMP messages between the SNMP manager and the agent can have the message source authenticated and the data integrity checked. USM reduces messaging delays and message replays by enforcing timeout limits and by checking for duplicate message request IDs.
-
VACM complements USM by providing user access control for SNMP queries to the agent. You define access privileges that you wish to extend to a group of one or more users. Access privileges are determined by the security model parameters (
usm,v1, orv2) and security level parameters (authentication,privacy, ornone). For each security level, you must associate one MIB view for the group. Associating a MIB view with a group grants the read, write, or notify permission to a set of MIB objects for the group. -
You configure security parameters for each user, including the username, authentication type and authentication password, and privacy type and privacy password. The username given to each user is in a format that is dependent on the security model configured for that user.
-
To ensure messaging security, another type of username, called the security name, is included in the messaging data that is sent between the local SNMP server and the destination SNMP server. Each user name is mapped to a security name, but the security name is in a format that is independent of the security model.
-
Trap entries in SNMPv3 are created by configuring the notify, notify filter, target address, and target parameters. The
notifystatement specifies the type of notification (trap) and contains a single tag that defines a set of target addresses to receive a trap. The notify filter defines access to a collection of trap object identifiers (OIDs). The target address defines the address of an SNMP management application and other attributes used in sending notifications. Target parameters define the message processing and security parameters used in sending notifications to a particular target.
To configure SNMPv3, perform the following tasks:
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 is 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 is 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.
See Also
Managing Traps and Informs
The following sections provide details on managing SNMP notifications:
- Generating Traps Based on SysLog Events
- Filtering Traps Based on the Trap Category
- Filtering Traps Based on the Object Identifier
Generating Traps Based on SysLog Events
Event policies can include an action that raises traps for events based on system log messages. This feature enables notification of an SNMP trap-based application when an important system log message occurs. You can convert any system log message, for which there is no corresponding trap, into a trap. If you are using network management system traps rather than system log messages to monitor your network, you can use this feature to ensure that you are notified of all the major events.
To configure a policy that raises a trap on receipt of an event,
include the following statements at the [edit event-options policy policy-name] hierarchy level:
The following example shows the sample configuration for raising
a trap for the event ui_mgd_terminate:
[edit event-options policy p1]
events ui_mgd_terminate;
then {
raise-trap;
}
Filtering Traps Based on the Trap Category
SNMP traps are categorized into many categories. The Junos OS
provides a configuration option, categories at the [edit snmp trap-group trap-group] hierarchy
level, that enables you to specify categories of traps that you want
to receive on a particular host. You can use this option when you
want to monitor only specific modules of the Junos OS.
The following example shows a sample configuration for receiving
only link, vrrp-events, services,
and otn-alarms traps:
[edit snmp]
trap-group jnpr {
categories {
link;
vrrp-events;
services;
otn-alarms;
}
targets {
192.168.69.179;
}
}
Filtering Traps Based on the Object Identifier
The Junos OS also provides a more advanced filter option that
enables you to filter out specific traps based on their object identifiers.
You can use the notify-filter option to filter out a specific
trap or a group of traps.
The following example shows the sample configuration for excluding Juniper Networks enterprise-specific configuration management traps (note that the SNMPv3 configuration also supports filtering of SNMPv1 and SNMPv2 traps as is shown in the following example):
[edit snmp]
v3 {
vacm {
security-to-group {
security-model v2c {
security-name sn_v2c_trap {
group gr_v2c_trap;
}
}
}
access {
group gr_v2c_trap {
default-context-prefix {
security-model v2c {
security-level none {
read-view all;
notify-view all;
}
}
}
}
}
}
target-address TA_v2c_trap {
address 10.209.196.166;
port 9001;
tag-list tg1;
target-parameters TP_v2c_trap;
}
target-parameters TP_v2c_trap {
parameters {
message-processing-model v2c;
security-model v2c;
security-level none;
security-name sn_v2c_trap;
}
notify-filter nf1;
}
notify v2c_notify {
type trap;
tag tg1;
}
notify-filter nf1 {
oid .1.3.6.1.4.1.2636.4.5 exclude;
oid .1 include;
}
snmp-community index1 {
community-name "$9$tDLl01h7Nbw2axN"; ## SECRET-DATA
security-name sn_v2c_trap;
tag tg1;
}
view all {
oid .1 include;
}
}