Overview
SNMP is a protocol that manages network devices, such as your E-series router. The goal of SNMP is to simplify network management in two ways:
- By defining a single management protocol that can be used to manage any network device from any vendor.
This feature reduces the complexity of the network management application because the application does not need to support a large number of proprietary management protocols for the mix of vendors' devices in the network.
- By defining a single, consistent representation of managed information that is commonly deployed in network devices.
For example, SNMP uses a common form and semantics for interface statistics, a process that supports consistent interpretation and meaningful comparison.
SNMP is an application-level protocol that comprises the following three elements:
SNMP defines a client-server model in which a client (manager) obtains information from the server (agent) through two mechanisms:
- A request/response protocol by which the client configures and monitors the server. In this instance, the information is solicited.
- Asynchronous notifications (called traps) by which the server, on its own initiative, reports notable changes in the router's status to the client. In this instance, the information is unsolicited.
Terminology
Table 17 provides definitions for the basic SNMP terms.
SNMP Features Supported
This SNMP implementation provides the following:
- Standard SNMP MIB support for services and interfaces as defined by the Internet Engineering Task Force (IETF)
- A set of AS number version 1 notated enterprise MIBs for all management functions not addressed by standard MIBs
- A multilingual SNMP server that supports SNMPv1, SNMPv2c, and SNMPv3 protocols
- Enhanced security and management features supported in SNMPv3
- Traps for alarm and state change events
- Bulk data collection and retrieval
- Management of virtual routers
- Secure audit logging for packet mirroring traps and Juni-PACKET-MIRROR MIB access
NOTE: You can disable the management interface through SNMP. But, if you disable the management interface, you can no longer access the router
through SNMP.
SNMP Client
The SNMP client runs on a network host and communicates with one or more SNMP servers on other network devices, such as routers, to configure and monitor the operation of those network devices.
SNMP Server
The SNMP server operates on a network device, such as a router, a switch, or a workstation. It responds to SNMP requests received from SNMP clients and generates trap messages to alert the client(s) about notable state changes in the network device.
The SNMP server implementation operates over UDP/IP only. It can receive requests directed to any IP address configured on the router. SNMP requests and responses are received or sent on UDP port 161. SNMP traps are sent from UDP port 162 by default or from a configurable port. For traps sent from UDP port 162, you can configure the destination UDP port for each recipient with the snmp-server host command.
SNMP MIBs
A MIB specifies the format of managed data for a device function. The goal of a MIB is to provide a common and consistent management representation for that function across networking devices.
Your router supports both standard and enterprise SNMP MIBs.
Standard SNMP MIBs
A standard MIB is defined by a body such as the IETF and fosters consistency of management data representation across many vendors' networking products.
Juniper Networks E-series Enterprise MIBs
An enterprise MIB is defined by a single vendor. In addition to providing consistency of management data representation across that vendor's product line, the enterprise MIB also accounts for proprietary functions and value-added features not addressed by standard MIBs.
For example, boot record extensions to the enterprise MIB enable configuration of the release (.rel) files for each router, slot, and subsystem. The extensions also enable booting through the factory defaults, the running configuration, or a configuration (.cnf) file.
Accessing Supported SNMP MIBs
For complete information about the SNMP MIBs supported by your router, see the E-series System Software CD, shipped with your router. In the MIBs folder you will find information about all supported standard and Juniper Networks E-series Enterprise (proprietary) MIBs.
SNMP Versions
This SNMP server implementation supports:
- SNMPv1 (defined in RFC 1157)
- SNMPv2c (Community-based SNMPv2, defined in RFC 1901 and RFC 3416)
- SNMPv3 (compliant with RFCs 34103418, STD 62)
The server encodes SNMP responses using the same SNMP version received in the corresponding request and encodes traps using the SNMP version configured for the trap recipient.
SNMPv2c supports the capabilities defined for SNMPv1 and provides greater power and flexibility through the addition of several features, including:
- More detailed error codes
- GetBulk operation for efficient retrieval of large amounts of data
- 64-bit counters
SNMPv3 is an extensible SNMP framework that supplements the SNMPv2c framework by supporting:
Security Features
As users transfer more sensitive information, such as billing details, through the Internet, security becomes more critical for SNMP and other protocols. SNMPv3 provides the user-based security model (USM) to address authentication and data encryption.
Authentication provides the following benefits:
- Only authorized parties can communicate with each other. Consequently, a management station can interact with a device only if the administrator configured the device to allow the interaction.
- Messages are received promptly; users cannot save messages and replay them to alter content. This feature prevents users from sabotaging SNMP configurations and operations. For example, users can change configurations of network devices only if authorized to do so.
SNMPv3 authenticates users through the HMAC-MD5-96 or HMAC-SHA-96 protocols; CBC-DES is the encryption or privacy protocol. The SNMP agent recognizes up to 32 usernames that can have one of the following security levels:
- No authentication and no privacy (none)
- Authentication only (auth only)
- Authentication and privacy (priv)
In contrast, SNMPv1and SNMPv2c provide only password protection, through the community name and IP address. When an SNMP server receives a request, the server extracts the client's IP address and the community name. The SNMP community table is searched for a matching community. If a match is found, its access list, if nonzero, is used to validate the IP address. If the access list number is zero, the IP address is accepted. A nonmatching community or an invalid IP address causes an SNMP authentication error. Each entry in the community table identifies:
Management Features
Management features of SNMPv3 allow you to specify who will receive notifications and to define MIB views that users in different groups can access:
- NotificationMessage that informs you of a status change; the equivalent of a trap in SNMPv1.
- ViewDefinition of the management information that is available: read, write, or notification. Predefined views are available for each group:
- everythingIncludes all MIBs associated with the router, except the packetMirror MIB
- userIncludes all MIBs associated with the router, except the packetMirror MIB and standard and enterprise MIBs used to configure SNMP operation
- nothingExcludes all MIBs
- mirrorAdminIncludes the packetMirror MIB
- UserAn individual who requires access to the router. The router may provide authentication and privacy for the user through SNMPv3. Each user is associated with a group.
- GroupA set of users with the same access privileges to the router. Three predefined groups are available: admin, public, and private. Table 18 shows the security levels and views associated with these groups.
Virtual Routers
All SNMP-related CLI commands operate in the context of a virtual router, which means that you must configure users, traps, communities, and so on for each server. You must set the context using the virtual-router command and then configure SNMP.
The show snmp commands show only statistics and configuration information for the server/SNMP agent that corresponds to the current virtual router context.
The exceptions to this convention are the snmp-server contact and the snmp-server location commands. With these commands, single instances of the contact and the location are created regardless of the number of virtual routers.
Creating SNMP Proxy
Your JUNOSe software allows you to configure multiple virtual routers. Each virtual router has its own SNMP server. At router initialization, SNMP creates a server for each existing virtual router.
When router-specific data is required, the requestor can direct a request to a particular server for a virtual router through the base community string extension: for example, SNMP get public@megaRouter.
NOTE: In addition to the @ selector character, the system also supports the % selector character. For example, SNMP get public%megaRouter.
When any system server parses a request and detects an extended community string, it acts as proxy by forwarding the request to the server corresponding to the virtual router name in the extension (for example, megaRouter). The target server then processes the request and generates a response, which is then returned to the proxy server and subsequently transmitted to the requester.
The JUNOSe implementation of SNMPv3 communicates with virtual routers by assigning each proxy agent an SNMP engine ID. This difference is unimportant to users of the CLI. However, if you use other SNMPv3 applications to manage the router, refer to the following section.
Disabling and Reenabling SNMP Proxy
The ability to proxy SNMP from a virtual router (VR) is enabled by default whenever you create a virtual router agent. However, you can disable or reenable the proxy feature on each virtual router agent to address any network security issues. To disable proxy on an agent (router), you must use SNMP or the CLI snmp-server proxy disable command.
Communicating with the SNMP Engine
The SNMP engine performs the following tasks for SNMPv3:
- Sends and receives messages.
- Prepares messages and extracts data from messages.
- Authenticates, encrypts, and decrypts messages.
- Determines whether access to a managed task is allowed.
Each SNMP engine has an SnmpEngine ID, a hexadecimal number 15 octets long. Table 19 shows the structure of the SnmpEngine ID.
Indicates that octets 615 contain information determined by the E-series router
Request protocol data units (PDUs) for the SNMP engine must contain the corresponding contextEngine ID and contextName for the SNMP engine. When the system receives a PDU, it examines the contextEngine ID and contextName, and forwards the request to the corresponding virtual router.
- The contextEngine ID is the same as the SnmpEngine ID.
- The contextName is an internally derived ASCII string associated with the router. It has the format routerN, where N is a number (with no leading zeros) in the range 116777215, corresponding to the least significant 24 bits of the 32-bit router index (or router UID). You can obtain the contextName for a specific router through the Juniper-ROUTER-MIB from the juniRouterContextName object in the juniRouterTable, which is indexed by the 32-bit router index (juniRouterIndex).
The following table shows examples of the E-series router SNMP engine objects that are associated with the default virtual router.
SNMP Attributes
The software automatically maps predefined SNMPv1/v2c attributes to predefined SNMPv3 attributes, as shown in Table 20.
SNMP Operations
SNMP has the five operations defined in Table 21.
SNMP PDU Types
SNMP offers the six types of PDUs defined in Table 22.