SNMP

SNMP overview

This section provides an overview of the Simple Network Management Protocol (SNMP).

SNMP architecture

The Nokia Network Services Platform (NSP) is composed of managers and SNMP agents. The manager is the entity through which network management tasks are facilitated. Agents interface managed objects. Managed devices, such as bridges, hubs, routers, and network servers can contain managed objects. A managed object can be a configuration attribute, performance statistic, or control action that is directly related to the operation of a device.

Managed devices collect and store management information and use Simple Network Management Protocol (SNMP). SNMP is an application-layer protocol that provides a message format to facilitate communication between SNMP managers and agents. SNMP provides a standard framework to monitor and manage devices in a network from a central location.

An SNMP manager controls and monitors the activities of network hosts which use SNMP. An SNMP manager can obtain (get) a value from an SNMP agent or store (set) a value in the agent. The manager uses definitions in the management information base (MIB) to perform operations on the managed device such as retrieving values from variables or blocks of data, replying to requests, and processing traps.

Between the SNMP agent and the SNMP manager the following actions can occur:

  • The manager can get information from the agent.

  • The manager can set the value of a MIB object that is controlled by an agent.

  • The agent can send traps to notify the manager of significant events that occur on the router.

Management information base

A MIB is a formal specifications document with definitions of management information used to remotely monitor, configure, and control a managed device or network system. The agent’s management information consists of a set of network objects that can be managed with SNMP. Object identifiers are unique object names that are organized in a hierarchical tree structure. The main branches are defined by the Internet Engineering Task Force (IETF). When requested, the Internet Assigned Numbers Authority (IANA) assigns a unique branch for use by a private organization or company. The branch assigned to Nokia (TiMetra) is 1.3.6.1.4.1.6527.

The SNMP agent provides management information to support a collection of IETF specified MIBs and a number of MIBs defined to manage devices and network data unique to Nokia’s router.

SNMP protocol operations

Between the SNMP agent and the SNMP manager the following actions can occur:

  • The manager can get information from the agent.

  • The manager can set the value of a MIB object that is controlled by an agent.

  • The agent notifies the manager of significant events that occur on the router.

SNMP versions

The agent supports multiple versions of the SNMP protocol:

  • SNMP Version 1 (SNMPv1) is the original Internet-standard network management framework.

    SNMPv1 uses a community string match for authentication.

  • The OS implementation uses SNMPv2c, the community-based administrative framework for SNMPv2. SNMPv2c uses a community string match for authentication.

  • In SNMP Version 3 (SNMPv3), USM defines the user authentication and encryption features. View Access Control MIB (VACM) defines the user access control features. The SNMP-COMMUNITY-MIB is used to associate SNMPv1/SNMPv2c community strings with SNMPv3 VACM access control.

    SNMPv3 uses a username match for authentication.

SNMPv3 authentication and privacy protocols

The following SNMPv3 authentication protocols are supported:

  • HMAC-MD5-96
  • HMAC-SHA-96
  • HMAC-SHA-224
  • HMAC-SHA-256
  • HMAC-SHA-384
  • HMAC-SHA-512

The following SNMPv3 privacy protocols are supported:

  • CBC-DES
  • CFB128-AES-128
  • CFB128-AES-192
  • CFB128-AES-256

Management information access control

By default, the OS implementation of SNMP uses SNMPv3. SNMPv3 incorporates security model and security level features. A security model is the authentication type for the group and the security level is the permitted level of security within a security model. The combination of the security level and security model determines which security mechanism handles an SNMP packet.

To implement SNMPv1 and SNMPv2c configurations, several access groups are predefined. These access groups provide standard read-only, read-write, and read-write-all access groups and views that can simply be assigned community strings. To implement SNMP with security features, security models, security levels, and USM communities must be explicitly configured. Optionally, additional views which specify more specific OIDs (MIB objects in the subtree) can be configured.

Access to the management information in as SNMPv1/SNMPv2c agent is controlled by the inclusion of a community name string in the SNMP request. The community defines the sub-set of the agent’s managed objects can be accessed by the requester. It also defines what type of access is allowed: read-only or read-write.

The use of community strings provide minimal security and context checking for both agents and managers that receive requests and initiate trap operations. A community string is a text string that acts like a password to allow access to the agent on the router.

Nokia’s implementation of SNMP has defined three levels of community-named access:

read-only
grants only read access to objects in the MIB, except security objects
read-write
grants read and write access to all objects in the MIB, except security objects
read-write-all
grants read and write access to all objects in the MIB, including security objects

User-based security model community strings

User-based security model (USM) community strings associates a community string with an SNMPv3 access group and its view. The access granted with a community string is restricted to the scope of the configured group.

Views

Views control the access to a managed object. The total MIB of a router can be viewed as a hierarchical tree. When a view is created, either the entire tree or a portion of the tree can be specified and made available to a user to manage the objects contained in the subtree. Object identifiers (OIDs) uniquely identify managed objects. A view defines the type of operations for the view such as read, write, or notify.

OIDs are organized in a hierarchical tree with specific values assigned to different organizations. A view defines a subset of the agent’s managed objects controlled by the access rules associated with that view.

The Nokia SNMP agent associates SNMPv1 and SNMPv2c community strings with a SNMPv3 view.

Use the commands in the following context to configure SNMP views.

configure system security snmp view

The following system-provisioned views are particularly useful when configuring SNMPv1 and SNMPv2c:

  • iso

    It is intended for administrative-type access to the entire supported object tree (except Lawful Interception). Use the commands in the following context to configure the "ISO" view automatically associated with any SNMP community that has access permissions of r, re, or raw.

    configure system security snmp
  • no security

    Similar to ISO view, you can remove access to several security areas of the object tree (such as SNMP communities, user and profile configuration, SNMP engine ID, and so on). The no-security view is generally recommended over the ISO view to reduce access to security objects.

  • LI view

    This view provides access to a small set of Lawful Interception related objects.

  • GMT view

    This view provides access to IF-MIB and a few other basics. Use the commands in the following context to automatically associate the management view with any SNMP community that has an access-permission of GMT, as configured in the following context.
    configure system security snmp
  • VPRN view

    This limits access to objects associated with a specific VPRN (for example, the per-VPRN logs and SNMP access feature). Use the commands in the following context to automatically associate the VPRN view with any SNMP community configured in the following context.
    configure service vprn snmp

Access groups

Access groups associate a user group and a security model to the views the group can access. An access group is defined by a unique combination of a group name, security model (SNMPv1, SNMPv2c, or SNMPv3), and security level (no-authorization-no privacy, authorization-no-privacy, or privacy).

An access group, in essence, is a template which defines a combination of access privileges and views. A group can be associated with one or more network users to control their access privileges and views.

When configuring access groups, the no-security view is generally recommended over the iso view to restrict access to security objects.

A set of system-provisioned access groups and system-created communities are available in SR OS. The system-provisioned groups and communities that begin with ‟cli-” are only used for internal CLI management purposes and are not exposed to external SNMP access.

Additional access must be explicitly configured if the preconfigured access groups and views for SNMPv1 and SNMPv2c do not meet your security requirements.

Users

By default, authentication and encryption are not configured. You can modify the authentication that a user must use to be validated by the router. SNMP authentication allows the device to validate the managing node that issued the SNMP message and determine if the message has been tampered with.

User access and authentication privileges must be explicitly configured. In a user configuration, a user is associated with an access group, which is a collection of users who have common access privileges and views (see Access groups).

Per-VPRN logs and SNMP access

Configuration of VPRN-specific logs (with VPRN-specific syslog destinations, SNMP trap, notification groups, and so on) is supported in addition to the global logs configured under configure log. By default, the event streams for VPRN logs contain only events that are associated with the particular VPRN.

Use the following command to enable access to the entire system-wide set of events (VPRN and non-VPRN).

configure log services-all-events

Each VPRN service can be configured with a set of SNMP v1/v2c community strings. These communities are associated with the system provisioned SNMP view called "vprn-view", which limits SNMP access to objects associated with a specific VPRN (along with a few basic system level OIDs).

SNMP communities configured under a VPRN are also associated with the SNMP context "vprn". For example, walking the ifTable (IF-MIB) using the community configured for VPRN 5 returns counters and status for interfaces in VPRN 5 only.

Per-SNMP community source IP address validation

SNMPv1 and SNMPv2c requests can be validated against per-snmp-community allow lists of configured source IPv4 and IPv6 addresses. Source IP address lists can be configured and then associated with an SNMP community.

Use the command options in the following context to configure source access lists:

  • MD-CLI
    configure system security snmp source-access-list
  • classic CLI
    configure system security snmp access

SNMPv1 and SNMPv2c requests that fail the source IP address and community validation checks are discarded and are logged as SNMP event 2003 authenticationFailure (suppressed by default under ‟event-control”).

SNMP versions

SNMPv1 and SNMPv2c do not provide security, authentication, or encryption. Without authentication, a non-authorized user could perform SNMP network management functions and eavesdrop on management information as it passes from system to system. Many SNMPv1 and SNMPv2c implementations are restricted read-only access, which, in turn, reduces the effectiveness of a network monitor in which network control applications cannot be supported.

To implement SNMPv3, an authentication and encryption method must be assigned to a user to be validated by the router. SNMP authentication allows the router to validate the managing node that issued the SNMP message and determine if the message was tampered with.

SNMPv1 and SNMPv2c configuration and implementation flow depicts the configuration requirements to implement SNMPv1/SNMPv2c and SNMPv3.

Figure 1. SNMPv1 and SNMPv2c configuration and implementation flow

Best practices for SNMP information retrieval

This section describes best practices for achieving optimal performance when retrieving high volumes of data from SR OS using SNMP.

SNMP GetBulkRequest

The SNMP GetBulkRequest method should be used instead of GetRequest or GetNextRequest.

During GetBulkRequest processing, the SR OS SNMP layer uses all the objects from the application data that it can from the returned table row to continue filling in the SNMP reply.

To maximize the advantage of SR OS pre-fetching and caching optimizations, construct GetBulkRequests with a sequential list of OIDs that represent sequential columns from the same SNMP table row. For example, enter the following objects and OIDs in the GetBulkRequest request to perform a row-by-row retrieval:

interface A, counter 1, counter 2, counter 3, counter N
interface B, counter 1, counter 2, counter 3, counter N
... 
interface Z, counter 1, counter 2, counter 3, counter N

Do not perform column-by-column retrievals for GetBulkRequest requests, as in the following example:

interface A, counter 1 
interface B, counter 1
... 
interface Z, counter 1
interface A, counter 2 
interface B, counter 2
... 
interface Z, counter 2
interface A, counter 3 
interface B, counter 3
... 
interface Z, counter 3
interface A, counter N 
interface B, counter N
... 
interface Z, counter N

To align all responses at the start of a row, avoid performing GetBulkRequests that result in more data than can fit in a single response. This can be accomplished by limiting the max-repetitions depending on the number of repeaters and OIDs, and the size of data returned for each repeater and OID.

Queueing, RTT, and collection performance

The best collection performance is achieved if the SNMP manager keeps the SNMP input queue of the SR OS router filled, but without overflowing it. If maximum performance is required, then the SNMP manager should always have at least two outstanding requests toward the SR OS router: one request that the SR OS router is currently processing (but to which it has not replied yet), and one request that is waiting in the SNMP input queue of the SR OS router.

When the 7750 SR replies to the request, it immediately processes the next request if one is waiting in the input queue.

When the SNMP manager receives the reply, it immediately sends another request to the 7750 SR SNMP input queue.

If the round trip time (RTT) between the SNMP manager and the 7750 SR is significant, the SNMP manager may need to have more than two outstanding requests to maximize collection performance.

The SNMP manager must also avoid sending too many requests at a high rate without waiting for responses. A large number of outstanding requests can cause a backup in the SNMP input queue in SR OS. A backup can cause a long delay in response to the last item in the queue and a timeout on the SNMP manager. It can also cause discards at the SNMP input queue in SR OS.

Configuration notes

This section describes SNMP configuration restrictions.

General

To avoid management systems attempting to manage a partially booted system, SNMP remains in a shut down state if the configuration file fails to complete during system startup in classic or mixed configuration mode. While shutdown, SNMP gets and sets are not processed. However, notifications are issued if an SNMP trap group has been configured.

To enable SNMP, the portions of the configuration that failed to load must be initialized properly. Use the following command to start SNMP:

  • MD-CLI
    configure system management-interface snmp admin-state enable
  • classic CLI
    configure system snmp no shutdown

Use the following command to change the SNMP engine ID:

Caution: If you change the SNMP engine ID, save the current configuration and then reboot. This ensures that previously configured SNMP communities and logger trap-target notify communities are valid for the new engine ID.
  • MD-CLI
    configure system management-interface snmp engine-id
  • classic CLI
    configure system snmp engineID

Configuring SNMP with CLI

This section provides information about configuring SNMP with CLI.

SNMP configuration overview

This section describes how to configure SNMP components which apply to SNMPv1 and SNMPv2c, and SNMPv3 on the router.

Configuring SNMPv1 and SNMPv2c

Nokia routers are based on SNMPv3. To use the routers with SNMPv1 and/or SNMPv2c, SNMP community strings must be configured. Three pre-defined access methods are available when SNMPv1 or SNMPv2c access is required. Each access method (r, rw, or rwa) is associated with an SNMPv3 access group that determines the access privileges and the scope of managed objects available. The community command is used to associate a community string with a specific access method and the required SNMP version (SNMPv1 or SNMPv2c). The access methods are:

read-only
grants read only access to the entire management structure with the exception of the security area
read-write
grants read and write access to the entire management structure with the exception of the security area
read-write-all
grants read and write access to the entire management structure, including security

If the predefined access groups do not meet your access requirements, then additional access groups and views can be configured. The usm-community command is used to associate an access group with an SNMPv1 or SNMPv2c community string. Nokia does not recommend associating a usm-community with an SNMP access group that is configured with the li (lawful intercept) context.

Use the following command to configure SNMP trap destinations.

configure log snmp-trap-group

Configuring SNMPv3

The SR OS implements SNMPv3. If security features other than the default views are required, you must configure the following:

  • configure views

  • configure access groups

  • configure SNMP users

Basic SNMP security configuration

This section provides information to configure SNMP and an example of a common configuration.

At minimum, you must configure the following for SNMP:

  • the community string for SNMPv1 and SNMPv2c
  • the following for SNMPv3:
    • view

    • SNMP group

    • access

    • SNMP user

The following example shows configuration of SNMP default views, access groups, and access attempts.

MD-CLI

[ex:/configure system security snmp]
A:admin@node-2# info
    access "snmp-ro" context "" security-model snmpv1 security-level no-auth-no-privacy {
        read "no-security"
        notify "no-security"
    }
    access "snmp-ro" context "" security-model snmpv2c security-level no-auth-no-privacy {
        read "no-security"
        notify "no-security"
    }
    access "snmp-rw" context "" security-model snmpv1 security-level no-auth-no-privacy {
        read "no-security"
        write "no-security"
        notify "no-security"
    }
    access "snmp-rw" context "" security-model snmpv2c security-level no-auth-no-privacy {
        read "no-security"
        write "no-security"
        notify "no-security"
    }
    access "snmp-rwa" context "" security-model snmpv1 security-level no-auth-no
-privacy {
        read "iso"
        write "iso"
        notify "iso"
    }
    access "snmp-rwa" context "" security-model snmpv2c security-level no-auth-no-privacy {
        read "iso"
        write "iso"
        notify "iso"
    }
    access "snmp-trap" context "" security-model snmpv1 security-level no-auth-no-privacy {
        notify "iso"
    }
    access "snmp-trap" context "" security-model snmpv2c security-level no-auth-no-privacy {
        notify "iso"
    }
    attempts {
        count 20
        time 5
        lockout 10
    }
    view "iso" subtree "1" {
        mask "ff"
        type included
    }
    view "no-security" subtree "1" {
        mask "ff"
        type included
    }
    view "no-security" subtree "1.3.6.1.6.3" {
        mask "ff"
        type excluded
    }
    view "no-security" subtree "1.3.6.1.6.3.10.2.1" {
        mask "ff"
        type included
    }
    view "no-security" subtree "1.3.6.1.6.3.11.2.1" {
        mask "ff"
        type included
    }
    view "no-security" subtree "1.3.6.1.6.3.15.1.1" {
        mask "ff"
        type included
    }

classic CLI

A:node-2>config>system>security>snmp# info detail
----------------------------------------------
              view iso subtree 1
                  mask ff type included
              exit
              view no-security subtree 1
                  mask ff type included
              exit
              view no-security subtree 1.3.6.1.6.3
                  mask ff type excluded
              exit
              view no-security subtree 1.3.6.1.6.3.10.2.1
                  mask ff type included
              exit
              view no-security subtree 1.3.6.1.6.3.11.2.1
                  mask ff type included
              exit
              view no-security subtree 1.3.6.1.6.3.15.1.1
                  mask ff type included
              exit
              access group snmp-ro security-model snmpv1 security-level no-auth-no-
privacy read no-security notify no-security
              access group snmp-ro security-model snmpv2c security-level no-auth-no-
privacy read no-security notify no-security
              access group snmp-rw security-model snmpv1 security-level no-auth-no-
privacy read no-security write no-security notify no-security
              access group snmp-rw security-model snmpv2c security-level no-auth-no-
privacy read no-security write no-security notify no-security
              access group snmp-rwa security-model snmpv1 security-level no-auth-no-
privacy read iso write iso notify iso
             access group snmp-rwa security-model snmpv2c security-level no-auth-no-
privacy read iso write iso notify iso
              access group snmp-trap security-model snmpv1 security-level no-auth-
no-
privacy notify iso
              access group snmp-trap security-model snmpv2c security-level no-auth-
no-privacy notify iso
              attempts 20 time 5 lockout 10

Configuring SNMP components

Configuring community strings

SNMPv1 and SNMPv2c community options include the community string. The community string defines the relationship between an SNMP manager and agent. The community string acts like a password to allow access to the agent. The access granted with a community string is restricted to the scope of the configured group.

You can specify one or more of the following characteristics associated with the string:

  • read-only, read-write, and read-write-all permission for the MIB objects accessible to the community

  • the SNMP version, SNMPv1 or SNMPv2c

Default access features are pre-configured by the agent for SNMPv1/SNMPv2c.

Use the commands in the following context to configure the community options:

configure system security snmp community
MD-CLI
[ex:/configure system security snmp]
A:admin@node-2# info
    community "IotIpW28Ls8QOTInrJydyerOnvF+U1aq hash2" {
        access-permissions rwa
        version both
    }
    community "X7FnnghnQFm3LicdiQLBGibbOpPGzbdp hash2" {
        access-permissions r
        version v2c
    }
    community "yuumEiY8oD40Uo5/FCkzYi9Uz0Cc2pke hash2" {
        access-permissions r
        version both
    }
classic CLI
A:node-2>config>system>security>snmp# info
----------------------------------------------
           community "uTdc9j48PBRkxn5DcSjchk" hash2 rwa version both
           community "Lla.RtAyRW2" hash2 r version v2c
           community "r0a159kIOfg" hash2 r version both
---------------------------------------------- 

Configuring views

Use the commands in the following context to configure SNMP view options.

configure system security snmp view
MD-CLI
[ex:/configure system security snmp]
A:admin@node-2# info
    view "testview" subtree "1" {
        mask "ff"
    }
    view "testview" subtree "1.3.6.1.2" {
        mask "ff"
        type excluded
    } 
classic CLI
A:node-2>config>system>security>snmp# info
----------------------------------------------
                view "testview" subtree "1"
                    mask ff
                exit
                view "testview" subtree "1.3.6.1.2"
                    mask ff type excluded
                exit
                
----------------------------------------------

Configuring access groups

SNMP access group configuration creates an association between an SNMP context, security model, security level, and SNMP views. The access groups can then be used to control SNMP access to the router. Access groups must be configured unless security is limited to the preconfigured access groups and views for SNMPv1 and SNMPv2. The access group is defined by the unique combination of the SNMP context, security model, and security level.

Use the commands in the following context to configure SNMP access groups.

configure system security snmp access
SNMP access group and view configuration (MD-CLI)
[ex:/configure system security snmp]
A:admin@node-2# info
    access "testgroup" context "" security-model usm security-level privacy {
        read "testview"
        write "testview"
        notify "testview"
    }
    view "testview" subtree "1" {
        mask "ff"
    }
    view "testview" subtree "1.3.6.1.2" {
        mask "ff"
        type excluded
    }
SNMP access group and view configuration (classic CLI)
A:node-2>config>system>security>snmp# info
----------------------------------------------
                view "testview" subtree "1"
                    mask ff
                exit
                view "testview" subtree "1.3.6.1.2"
                    mask ff type excluded
                exit
                access group "testgroup" security-model usm security-level privacy read "testview" write "testview" notify "testview"
----------------------------------------------

To deploy user-based SNMPv3, combine SNMP access groups with other SNMP configuration options in the configuration of local users. Use the commands in the following context to configure SNMP access and authentication for a user:

  • MD-CLI
    configure system security user-params local-user user
  • classic CLI
    configure system security user
SNMP access and authentication for a user (MD-CLI)
[ex:/configure system security user-params local-user user "testuser"]
A:admin@node-2# info
    password "password123"
    access {
        snmp true
        console 
    }
    console  {
        member false
    }
     snmp {
        group "testgroup"
        authentication {
            authentication-protocol hmac-md5-96
            authentication-key "9Mx3EjegOfz5g8oZaO49tD/rw2Nlwuvv3H0Uvuppj48= hash2"
            privacy {
                privacy-protocol cfb128-aes-128
                privacy-key "BkkXpC7xTVuZIsUewNJcuyf8FiOPZJK0oCZ277fRdMY= hash2"
            }
        }
    }
SNMP access and authentication for a user (classic CLI)
A:node-2>configure system security user "testuser"
A:node-2>config>system>security>user# info
----------------------------------------------
             password "$2y$10$yQPzYQ8B1h.lxUmz3v56M.ekU3S/3V3HNjJ7/4ntrm8B1Oc2S/G/i"
             access snmp
             console
                 no member "default"
             exit
             snmp
                 authentication hash2 hmac-md5-96 9Mx3EjegOfz5g8oZaO49tD/rw2Nlwuvv3H0Uvuppj48= privacy cfb128-aes-128 BkkXpC7xTVuZIsUewNJcuyf8FiOPZJK0oCZ277fRdMY=
                 group "testgroup"
             exit
----------------------------------------------
Note:

Use the following command to generate authentication and privacy keys.

tools perform system management-interface snmp generate-key

An offline tool can also be used to generate the authentication and privacy keys. In addition to the Nokia Network Services Platform (NSP), which includes the password2key tool, several third-party tools are also available for use. For example, snmpv3-hashgen in the Python SNMPv3-Hash-Generator package generates the correct keys.

Configuring USM communities

User-based security model (USM) community strings associate a community string with an SNMPv3 access group and its view. The access granted with a community string is restricted to the scope of the configured group.

By default, the OS implementation of SNMP uses SNMPv3. However, to implement SNMPv1 and SNMPv2c, USM community strings must be explicitly configured.

Nokia does not recommend associating a usm-community with an SNMP access group that is configured with the li (lawful intercept) context.

You can associate a community string with an SNMPv3 access group and its view. The access granted with a community string is restricted to the scope of the configured group.

Use the commands in the following context to configure USM community options.

configure system security snmp usm-community

Configuring other SNMP options

Use the commands in the following context to configure SNMP system options such as an SNMP engine ID that uniquely identifies the node, the maximum SNMP packet size generated by the node, and the port for receiving SNMP request messages and sending replies:

  • MD-CLI
    configure system management-interface snmp
  • classic CLI
    configure system snmp

The following example shows configuration of the management interface for SNMP.

MD-CLI
[ex:/configure system management-interface snmp]
A:admin@node-2# info
    admin-state disable
    engine-id 0000197f0000daf1ff000000
    general-port 161
    packet-size 1500 
classic CLI
A:node-2>config>system>snmp# info detail
----------------------------------------------
         shutdown
         engineID "0000197f0000daf1ff000000"
         packet-size 1500
         general-port 161
----------------------------------------------\