# 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:

- An SNMP client (manager)
- An SNMP server (agent)
- A Management Information Base (MIB)

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 16 provides definitions for the basic SNMP terms.

Table 16: SNMP Terminology

Term | Meaning
--- | ---
agent | Also referred to as server; a managed device, such as a router, that collects and stores management information
client | Sometimes called a network management station (NMS) or simply a manager; a device that executes management applications that monitor and control network elements
community | A logical group of SNMP-managed devices and clients in the same administrative domain
entity | Refers to both a server and a client
event | A condition or state change that may cause the generation of a trap message
managed object | A characteristic of something that can be managed, such as a list of currently active TCP circuits in a device
group | SNMPv3 term; a set of users with the same access privileges to the router
MIB | Management Information Base; a collection of managed objects residing in a virtual information store
network element | Also known as a managed device; a hardware device, such as a PC or a router
notification | A message that indicates a status change (equivalent to a trap)
server | Also referred to as agent; a managed device, such as a router, that collects and stores management information
trap | Message sent by an SNMP server to a client to indicate the occurrence of a significant event, such as a specifically defined condition or a threshold that was reached. Managed devices use traps to asynchronously report certain events to clients.
user | SNMPv3 term; an individual who accesses the router
view | SNMPv3 term; defines the management information available to the user: read, write, or notification

## 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.

  | Note: JunosE Software supports SNMP packet mirroring traps; however, the packet mirroring-related SNMP commands, categories, and traps are visible in the CLI only to authorized users. See JunosE Policy Management Configuration Guide for information about using SNMP with secure packet mirroring.

## 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 software image bundle that is available for downloading from the Juniper Networks website. 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 3410–3418, 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 for messages
- Explicit access control

## 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:

- An SNMP community name
- An SNMP view name
- A user’s privilege level
  - Read-only (ro)
  - Read-write (rw)
  - Administrator (admin)
- An IP access list name

## 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:

- Notification—Message that informs you of a status change; the equivalent of a trap in SNMPv1.
- View—Definition of the management information that is available: read, write, or notification. Predefined views are available for each group:
  - everything—Includes all MIBs associated with the router, except the packetMirror MIB
  - user—Includes all MIBs associated with the router, except the packetMirror MIB and standard and enterprise MIBs used to configure SNMP operation
  - nothing—Excludes all MIBs
  - mirrorAdmin—Includes the packetMirror MIB
- User—An 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.
- Group—A set of users with the same access privileges to the router. Three predefined groups are available: admin, public, and private. Table 17 shows the security levels and views associated with these groups.

  Table 17: Relationship Among Groups, Security Levels, and Views

  Group Name | Security Level | Read View | Write View | Notification/ Trap View
  --- | --- | --- | --- | ---
  admin | authentication and privacy | everything | everything | everything
  mirror | authentication and privacy | mirrorAdmin | mirrorAdmin | mirrorAdmin
  public | none | user | nothing | nothing
  private | authentication only | user | user | user

## 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.

| Note: Disabling the proxy function on a particular virtual router disables the use of proxy through that virtual router. You can, however, use the proxy function to access a proxy-disabled virtual router through another virtual router that does have the proxy function enabled.

## 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 18 shows the structure of the SnmpEngine ID.

Table 18: SnmpEngineID Structure Object

Octet Assignment | Description
--- | ---
1 – 4 | E Series router SNMP management private enterprise number
5 | Indicates that octets 6–15 contain information determined by the E Series router
6 – 11 | The MAC address for the device. For E120 and E320 routers, the MAC address is a unique ID based on chassis ID.
12 – 15 | The 32-bit (4 octet) router index (or routerUID)

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 1–16777215, 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.

Object | Value
--- | ---
SnmpEngineID | 0x80:00:13:0a:05:00:90:1a:00:04:6c:80:00:00:01
contextEngineID | 0x80:00:13:0a:05:00:90:1a:00:04:6c:80:00:00:01
contextName | router1

## SNMP Attributes

The software automatically maps predefined SNMPv1/v2c attributes to predefined SNMPv3 attributes, as shown in Table 19.

Table 19: Relationship Between SNMPv1/v2c and SNMPv3 Attributes

Attribute | SNMPv1/v2C Value | SNMPv3 Value
--- | --- | ---
Community | admin | admin
View |  | everything
Privilege | rw | rw
Community | public | public
View |  | user
Privilege | ro | ro
Community | private | private
View |  | user
Privilege | rw | rw

## SNMP Operations

SNMP has the five operations defined in Table 20.

Table 20: SNMP Operations

SNMP Operation | Definition
--- | ---
Get | Allows the client to retrieve an object instance from the server.
GetNext | Allows the client to retrieve the next object instance from a table or list within a server.
GetBulk | Makes it easier to acquire large amounts of related information without initiating repeated GetNext operations. GetBulk is not available in SNMPv1.
Set | Allows the client to set values for the objects managed by the server.
Notification | Used by the server to asynchronously inform the client of some event. (Called a trap in SNMPv1.)

## SNMP PDU Types

SNMP offers the six types of PDUs defined in Table 21.

Table 21: SNMP PDU Types

SNMP PDU Type | Definition
--- | ---
Get Bulk | Transmitted by the client to the server to obtain the identifiers and the values of a group or collection of variables rather than one variable at a time. GetBulk is not available in SNMPv1.
Get Next Request | Transmitted by the client to the server to obtain the identifiers and the values of variables located after the designated variables.
Get Request | Transmitted by the client to the server to obtain the values of designated variables.
Get Response | Transmitted by the server to the client in response to a Get Request, a Get Next Request, or a Set Request PDU.
Set Request | Transmitted by the client to the server to modify the values of designated variables.
Notification | Transmitted by the server, on its own initiative, to inform the client of a special event noted on a network device. (Called a trap in SNMPv1.)