[Contents] [Prev] [Next] [Index] [Report an Error] [No Frames]


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:

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.

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:

Terminology

Table 17 provides definitions for the basic SNMP terms.



Table 17: 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:

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:

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:

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:

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:

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:



Table 18: 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:

Each SNMP engine has an SnmpEngine ID, a hexadecimal number 15 octets long. Table 19 shows the structure of the SnmpEngine ID.



Table 19: 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

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



Table 20: 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 21.



Table 21: 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 22.



Table 22: 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.)



[Contents] [Prev] [Next] [Index] [Report an Error] [No Frames]