Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Navigation
Guide That Contains This Content
[+] Expand All
[-] Collapse All

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

    This section describes the following:

    Terminology

    Table 1 provides definitions for the basic SNMP terms.

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

    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 command-line interface (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.

    This section describes the following:

    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 2 shows the security levels and views associated with these groups.

      Table 2: 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.

    This section describes the following:

    Creating an 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 identifier (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 an 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 3 shows the structure of the SnmpEngine ID.

    Table 3: 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 media access control (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 4.

    Table 4: 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 5.

    Table 5: 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 6.

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

    Published: 2014-08-12