Implementing SNMP on Cisco IOS XR Software

Simple Network Management Protocol (SNMP) is an application-layer protocol that provides a message

format for communication between SNMP managers and agents. SNMP provides a standardized

framework and a common language used for the monitoring and management of devices in a network.

Prerequisites for Implementing SNMP on Cisco IOS XR Software

You must be in a user group associated with a task group that includes the proper task IDs for SNMP

commands. For detailed information about user groups and task IDs.

SNMP Functional Overview

The SNMP framework consists of three parts:

• An SNMP manager

• An SNMP agent

• A MIB

SNMP Manager

The SNMP manager is the system used to control and monitor the activities of network hosts using

SNMP. The most common managing system is called a network management system (NMS). The term

NMS can be applied to either a dedicated device used for network management, or the applications used

on such a device. A variety of network management applications are available for use with SNMP. These

features range from simple command-line applications to feature-rich graphical user interfaces (such as

the CiscoWorks2000 line of products).

SNMP Agent

The SNMP agent is the software component within the managed device that maintains the data for the

device and reports these data, as needed, to managing systems. The agent and MIB reside on the router.

To enable the SNMP agent, you must define the relationship between the manager and the agent.

MIB

The MIB is a virtual information storage area for network management information, which consists of

collections of managed objects. Within the MIB there are collections of related objects, defined in MIB

modules. MIB modules are written in the SNMP MIB module language, as defined in STD 58,

RFC 2578, RFC 2579, and RFC 2580. Note that individual MIB modules are also referred to as MIBs;

for example, the Interfaces Group MIB (IF-MIB) is a MIB module within the MIB on your system.

The SNMP agent contains MIB variables whose values the SNMP manager can request or change

through Get or Set operations. A manager can get a value from an agent or store a value into that agent.

The agent gathers data from the MIB, the repository for information about device parameters and

network data. The agent can also respond to manager requests to get or set data.

A manager can send the agent requests to get and set MIB values. The agent can respond to these requests.

Independent of this interaction, the agent can send unsolicited notifications (traps) to the manager to

notify the manager of network conditions.

SNMP Notifications

A key feature of SNMP is the ability to generate notifications from an SNMP agent. These notifications

do not require that requests be sent from the SNMP manager. On the Cisco IOS XR software, unsolicited

(asynchronous) notifications can be generated only as traps. Traps are messages alerting the SNMP

manager to a condition on the network. Notifications can indicate improper user authentication, restarts,

the closing of a connection, loss of connection to a neighbor router, or other significant events.

Inform requests (inform operations) are not supported on the Cisco IOS XR software.

Traps are less reliable than informs because the receiver does not send any acknowledgment when it

receives a trap. The sender cannot determine if the trap was received. An SNMP manager that receives

an inform request acknowledges the message with an SNMP response protocol data unit (PDU). If the

manager does not receive an inform request, it does not send a response. If the sender never receives a

response, the inform request can be sent again. Thus, informs are more likely to reach their intended

destination.

However, traps are often preferred because informs consume more resources in the router and in the

network. Unlike a trap, which is discarded as soon as it is sent, an inform request must be held in memory

until a response is received or the request times out. Also, traps are sent only once, and an inform may

be retried several times. The retries increase traffic and contribute to a higher overhead on the network.

Thus, traps and inform requests provide a trade-off between reliability and resources.

Case:the agent router sends a trap to the SNMP manager. Although the manager receives the trap,

it does not send any acknowledgment to the agent. The agent has no way of knowing that the trap reached

its destination.

Case: the agent sends a trap to the manager, but the trap does not reach the manager. Because the

agent has no way of knowing that the trap did not reach its destination, the trap is not sent again. The

manager never receives the trap.

SNMP Versions

The Cisco IOS XR software supports the following versions of SNMP:

• Simple Network Management Protocol Version 1 (SNMPv1)

• Simple Network Management Protocol Version 2c (SNMPv2c)

• Simple Network Management Protocol Version 3 (SNMPv3)

Both SNMPv1 and SNMPv2c use a community-based form of security. The community of managers

able to access the agent MIB is defined by an IP address access control list and password.

SNMPv2c support includes a bulk retrieval mechanism and more detailed error message reporting to

management stations. The bulk retrieval mechanism supports the retrieval of tables and large quantities

of information, minimizing the number of round-trips required. The SNMPv2c improved error handling

support includes expanded error codes that distinguish different kinds of error conditions; these

conditions are reported through a single error code in SNMPv1. Error return codes now report the error

type. Three kinds of exceptions are also reported: no such object exceptions, no such instance

exceptions, and end of MIB view exceptions.

SNMPv3 is a security model. A security model is an authentication strategy that is set up for a user and

the group in which the user resides. A security level is the permitted level of security within a security

model. A combination of a security model and a security level will determine which security mechanism

is employed when an SNMP packet is handled.

You must configure the SNMP agent to use the version of SNMP supported by the management station.

An agent can communicate with multiple managers; for this reason, you can configure the Cisco IOS-XR

software to support communications with one management station using the SNMPv1 protocol, one

using the SNMPv2c protocol, and another using SMNPv3.

Comparison of SNMPv1, v2c, and v3

SNMP v1, v2c, and v3 all support the following operations:

• get-request—Retrieves a value from a specific variable.

• get-next-request—Retrieves the value following the named variable; this operation is often used to

retrieve variables from within a table. With this operation, an SNMP manager does not need to know

the exact variable name. The SNMP manager searches sequentially to find the needed variable from

within the MIB.

• get-response—An operation that replies to a get-request, get-next-request, and set-request sent by

an NMS.

• set-request—An operation that stores a value in a specific variable.

• trap—An unsolicited message sent by an SNMP agent to an SNMP manager when some event has

occurred.

SNMPv1, v2c, and v3 Feature Support

Feature SNMP v1 SNMP v2c SNMP v3

Get-Bulk Operation No Yes Yes

Inform Operation No Yes (no on theCisco IOS XR software) Yes (no on theCisco IOS XR)

64 Bit Counter No Yes Yes

Textual Conventions No Yes Yes

Authentication No No Yes

Privacy (Encryption) No No Yes

Authorization and Access

Controls (Views) No No Yes

Security Models and Levels for SNMPv1, v2, v3

The security level determines if an SNMP message needs to be protected from disclosure and if the

message needs to be authenticated. The various security levels that exist within a security model are as

follows:

• noAuthNoPriv—Security level that does not provide authentication or encryption.

• authNoPriv—Security level that provides authentication but does not provide encryption.

• authPriv—Security level that provides both authentication and encryption.

Three security models are available: SNMPv1, SNMPv2c, and SNMPv3. The security model combined

with the security level determine the security mechanism applied when the SNMP message is processed.

SNMP Security Models and Levels

Model Level Authentication Encryption What Happens

v1 noAuthNoPriv Community string No Uses a community string match for authentication.

v2c noAuthNoPriv Community string No Uses a community string match for authentication.

v3 noAuthNoPriv Username No Uses a username match for authentication.

v3 authNoPriv HMAC-MD5 or

HMAC-SHA No Provides authentication based on the

Hash-Based Message Authentication

Code (HMAC) Message Digest 5

(MD5) algorithm or the HMAC

Secure Hash Algorithm (SHA).

v3 authPriv HMAC-MD5 or

HMAC-SHA DES Provides authentication based on the

HMAC-MD5 or HMAC-SHA

algorithms. Provides Data Encryption

Standard (DES) 56-bit encryption in

addition to authentication based on

the Cipher Block Chaining (CBC)

DES (DES-56) standard.

SNMPv3 Benefits

SNMPv3 provides secure access to devices by providing authentication, encryption and access control.

These added security benefits secure SNMP against the following security threats:

• masquerade—The threat that an SNMP user may assume the identity of another SNMP user to

perform management operations for which that SNMP user does not have authorization.

• message stream modification—The threat that messages may be maliciously reordered, delayed, or

replayed (to an extent that is greater than can occur through the natural operation of a subnetwork

service) to cause SNMP to perform unauthorized management operations.

• disclosure—The threat that exchanges between SNMP engines could be eavesdropped. Protecting

against this threat may be required as a matter of local policy.

In addition, SNMPv3 provides access control over protocol operations on SNMP managed objects.

SNMPv3 Costs

SNMPv3 authentication and encryption contribute to a slight increase in the response time when SNMP

operations on MIB objects are performed. This cost is far outweighed by the security advantages

provided by SNMP v3.

Order of Response Times from Least to Greatest

Security Model Security Level

SNMPv2c noAuthNoPriv

SNMPv3 noAuthNoPriv

SNMPv3 authNoPriv

SNMPv3 authPriv

User-Based Security Model

SNMPv3 User-Based Security Model (USM) refers to SNMP message-level security and offers the

following services:

• Message integrity—Ensures that messages have not been altered or destroyed in an unauthorized

manner and that data sequences have not been altered to an extent greater than can occur

nonmaliciously.

• Message origin authentication—Ensures that the claimed identity of the user on whose behalf

received data was originated is confirmed.

• Message confidentiality—Ensures that information is not made available or disclosed to

unauthorized individuals, entities, or processes.

SNMPv3 authorizes management operations only by configured users and encrypts SNMP messages.

USM uses two authentication protocols:

• HMAC-MD5-96 authentication protocol

• HMAC-SHA-96 authentication protocol

USM uses CBC-DES (DES-56) as the privacy protocol for message encryption.

View-Based Access Control Model

The View-Based Access Control Model (VACM) enables SNMP users to control access to SNMP

managed objects by supplying read, write, or notify access to SNMP objects. It prevents access to objects

restricted by views. These access policies can be set when user groups are configured with the

snmp-server group command.

MIB Views

For security reasons, it is often valuable to be able to restrict the access rights of some groups to only a

subset of the management information within the management domain. To provide this capability, access

to a management objects is controlled through MIB views, which contain the set of managed object types

(and, optionally, the specific instances of object types) that can be viewed.

Access Policy

Access policy determines the access rights of a group. The three types of access rights are as follows:

• read-view access—The set of object instances authorized for the group when objects are read.

• write-view access—The set of object instances authorized for the group when objects are written.

notify-view access—The set of object instances authorized for the group when objects are sent in a

notification.

IP Precedence and DSCP Support for SNMP

SNMP IP precedence and DSCP support delivers QoS specifically for SNMP traffic. You can change the

priority setting so that SNMP traffic generated in a router is assigned a specific QoS class. The IP

Precedence or IP DSCP code point value is used to determine how packets are handled in Weighted

Random Early Detection (WRED).

After the IP Precedence or DSCP is set for the SNMP traffic generated in a router, different QoS classes

cannot be assigned to different types of SNMP traffic in that router.

The IP Precedence value is the first three bits in the Type of Service (ToS) byte of an IP header. The IP

DSCP code point value is the first six bits of the Differentiate Services (DiffServ Field) byte. You can

configure up to eight different IP Precedence markings or 64 different IP DSCP markings.

How to Implement SNMP on Cisco IOS XR Software

Configuring SNMPv3

No specific command enables SNMPv3; the first snmp-server global configuration command that you

issue enables SNMPv3. Therefore, the sequence in which you issue the snmp-server commands for this

task does not matter.

SUMMARY STEPS

1. configure

2. snmp-server engineid local engine-id

3. snmp-server view view-name oid-tree {included | excluded}

4. snmp-server group name {v1 | v2c | v3 {auth | noauth | priv}} [read view] [write view] [notify

view] [access-list-name]

5. snmp-server user username groupname {v1 | v2c | v3 [auth {md5 | sha} {clear | encrypted}

auth-password [priv des56 {clear | encrypted} priv-password]]} [access-list-name]

6. end

commit

7. show snmp

8. show snmp engineid

9. show snmp group

10. show snmp users

11. show snmp view

Command or Action Purpose

Step 1

configure

Example:

RP/0/RP0/CPU0:router# configure

Enters global configuration mode.

Step 2

snmp-server engineid local engine-id

Example:

RP/0/RP0/CPU0:router(config)# snmp-server engineID

local 00:00:00:09:00:00:00:a1:61:6c:20:61

(Optional) Specifies the identification number of the

local SNMP engine.

Step 3

snmp-server view view-name oid-tree {included |

excluded}

Example:

RP/0/RP0/CPU0:router(config)# snmp-server view

view_name 1.3.6.1.2.1.1.5 included

Creates or modifies a view record.

Step 4

snmp-server group name {v1 | v2c | v3 {auth |

noauth | priv}} [read view] [write view] [notify

view] [access-list-name]

Example:

RP/0/RP0/CPU0:router(config)# snmp-server group

group_name v3 noauth read view_name1 write

view_name2

Configures a new SNMP group, or a table that maps

SNMP users to SNMP views.

Step5

snmp-server user username groupname

{v1 | v2c | v3 [auth {md5 | sha} {clear |

encrypted} auth-password [priv des56 {clear |

encrypted} priv-password]]} [access-list-name]

Example:

RP/0/RP0/CPU0:router(config)# snmp-server user

noauthuser group_name v3

Configures a new user to an SNMP group.

Step 6

end

commit

Example:

RP/0/RP0/CPU0:router(config)# end

RP/0/RP0/CPU0:router(config)# commit

Saves configuration changes.

• When you issue the end command, the system

prompts you to commit changes:

Uncommitted changes found, commit them

before exiting(yes/no/cancel)?

[cancel]:

– Entering yes saves configuration changes to

the running configuration file, exits the

configuration session, and returns the router

to EXEC mode.

– Entering no exits the configuration session

and returns the router to EXEC mode without

committing the configuration changes.

– Entering cancel leaves the router in the

current configuration session without exiting

or committing the configuration changes.

• Use the commit command to save the

configuration changes to the running

configuration file and remain within the

configuration session.

Step 7 show snmp

Example:

RP/0/RP0/CPU0:router# show snmp

(Optional) Displays information about the status of

SNMP.

Step 8

show snmp engineid

Example:

RP/0/RP0/CPU0:router# show snmp engineid

(Optional) Displays information about the local SNMP

engine.

Step 9

show snmp group

Example:

RP/0/RP0/CPU0:router# show snmp group

(Optional) Displays information about each SNMP

group on the network.

Step 10

show snmp users

Example:

RP/0/RP0/CPU0:router# show snmp users

(Optional) Displays information about each SNMP

username in the SNMP users table.

Step 11

show snmp view

Example:

RP/0/RP0/CPU0:router# show snmp view

(Optional) Displays information about the configured

views, including the associated MIB view family

name, storage type, and status.

Configuring SNMP Trap Notifications

This task explains how to configure the router to send SNMP trap notifications

SUMMARY STEPS

1. configure

2. snmp-server engineid local engine-id

3. snmp-server group name {v1 | v2c | v3 {auth | noauth | priv}} [read view] [write view] [notify

view] [access-list-name]

4. snmp-server user username groupname {v1 | v2c | v3 [auth {md5 | sha} {clear | encrypted}

auth-password [priv des56 {clear | encrypted} priv-password]]} [access-list-name]

5. snmp-server host address [traps] [version {1 | 2c | 3 [auth | noauth | priv]}] community-string

[udp-port port] [notification-type]

6. snmp-server traps [notification-type]

7. end

commit

8. show snmp host

DETAILED STEPS

Command or Action Purpose

Step 1

configure

Example:

RP/0/RP0/CPU0:router# configure

Enters global configuration mode.

Step 2

snmp-server engineid local engine-id

Example:

RP/0/RP0/CPU0:router(config)# snmp-server engineID

local 00:00:00:09:00:00:00:a1:61:6c:20:61

(Optional) Specifies the identification number of the

local SNMP engine.

Step 3

snmp-server group name {v1 | v2c | v3 {auth |

noauth | priv}} [read view] [write view] [notify

view] [access-list-name]

Example:

RP/0/RP0/CPU0:router(config)# snmp-server group

group_name v3 noauth read view_name1 write

view_name2

Configures a new SNMP group, or a table that maps

SNMP users to SNMP views.

Step 4

snmp-server user username groupname

{v1 | v2c | v3 [auth {md5 | sha} {clear |

encrypted} auth-password [priv des56 {clear |

encrypted} priv-password]]} [access-list-name]

Example:

RP/0/RP0/CPU0:router(config)# snmp-server user

noauthuser group_name v3

Configures a new user to an SNMP group.

Step 5

snmp-server host address [traps] [version {1 | 2c |

3 [auth | noauth | priv]}] community-string

[udp-port port] [notification-type]

Example:

RP/0/RP0/CPU0:router(config)# snmp-server host

12.26.25.61 traps version 3 noauth userV3noauth

Specifies SNMP trap notifications, the version of

SNMP to use, the security level of the notifications,

and the recipient (host) of the notifications.

Step 6

snmp-server traps [notification-type]

Example:

RP/0/RP0/CPU0:router(config)# snmp-server traps bgp

Enables the sending of trap notifications and specifies

the type of trap notifications to be sent.

• If a trap is not specified with the notification-type

argument, all supported trap notifications are

enabled on the router. To display which trap

notifications are available on your router, enter the

snmp-server traps ? command.

Step 7

end

commit

Example:

RP/0/RP0/CPU0:router(config)# end

RP/0/RP0/CPU0:router(config)# commit

Saves configuration changes.

• When you issue the end command, the system

prompts you to commit changes:

Uncommitted changes found, commit them

before exiting(yes/no/cancel)?

[cancel]:

– Entering yes saves configuration changes to

the running configuration file, exits the

configuration session, and returns the router

to EXEC mode.

– Entering no exits the configuration session

and returns the router to EXEC mode without

committing the configuration changes.

– Entering cancel leaves the router in the

current configuration session without exiting

or committing the configuration changes.

• Use the commit command to save the

configuration changes to the running

configuration file and remain within the

configuration session.

Step 8

show snmp host

Example:

RP/0/RP0/CPU0:router# show snmp host

(Optional) Displays information about the configured

SNMP notification recipient (host), port number and

security model.

Setting the Contact, Location, and Serial Number of the SNMP Agent

This task explains how to set the system contact string, system location string, and system serial number

of the SNMP agent.

Note The sequence in which you issue the snmp-server commands for this task does not matter.

SUMMARY STEPS

1. configure

2. snmp-server contact system-contact-string

3. snmp-server location system-location

4. snmp-server chassis-id serial-number

5. end

commit

DETAILED STEPS

Command or Actions Purpose

Step 1

configure

Example:

RP/0/RP0/CPU0:router# configure

Enters global configuration mode.

Step 2

snmp-server contact system-contact-string

Example:

RP/0/RP0/CPU0:router(config)# snmp-server contact

Dial System Operator at beeper # 27345

(Optional) Sets the system contact string.

Step 3

snmp-server location system-location

Example:

RP/0/RP0/CPU0:router(config)# snmp-server location

Building 3/Room 214

(Optional) Sets the system location string.

Step 4

snmp-server chassis-id serial-number

Example:

RP/0/RP0/CPU0:router(config)# snmp-server

chassis-id 1234456

(Optional) Sets the system serial number.

Step 5

end

commit

Example:

RP/0/RP0/CPU0:router(config)# end

RP/0/RP0/CPU0:router(config)# commit

Saves configuration changes.

• When you issue the end command, the system

prompts you to commit changes:

Uncommitted changes found, commit them

before exiting(yes/no/cancel)?

[cancel]:

– Entering yes saves configuration changes to

the running configuration file, exits the

configuration session, and returns the router

to EXEC mode.

– Entering no exits the configuration session

and returns the router to EXEC mode without

committing the configuration changes.

– Entering cancel leaves the router in the

current configuration session without exiting

or committing the configuration changes.

• Use the commit command to save the

configuration changes to the running

configuration file and remain within the

configuration session.

Defining the Maximum SNMP Agent Packet Size

This task shows how to configure the largest SNMP packet size permitted when the SNMP server is

receiving a request or generating a reply.

Note The sequence in which you issue the snmp-server commands for this task does not matter.

SUMMARY STEPS

1. configure

2. snmp-server packetsize byte-count

3. end

commit

DETAILED STEPS

Command or Actions Purpose

Step 1 configure

Example:

RP/0/RP0/CPU0:router# configure

Enters global configuration mode.

Step 2

snmp-server packetsize byte-count

Example:

RP/0/RP0/CPU0:router(config)# snmp-server

packetsize 1024

(Optional) Sets the maximum packet size.

Step 3

end

commit

Example:

RP/0/RP0/CPU0:router(config)# end

RP/0/RP0/CPU0:router(config)# commit

Saves configuration changes.

• When you issue the end command, the system

prompts you to commit changes:

Uncommitted changes found, commit them

before exiting(yes/no/cancel)?

[cancel]:

– Entering yes saves configuration changes to

the running configuration file, exits the

configuration session, and returns the router

to EXEC mode.

– Entering no exits the configuration session

and returns the router to EXEC mode without

committing the configuration changes.

– Entering cancel leaves the router in the

current configuration session without exiting

or committing the configuration changes.

• Use the commit command to save the

configuration changes to the running

configuration file and remain within the

configuration session.

Changing Notification Operation Values

Once SNMP notifications have been enabled, you can specify a value other than the default for the source

interface, message queue length, or retransmission interval.

This task explains how to specify a source interface for trap notifications, the message queue length for

each host, and the retransmission interval.

Note The sequence in which you issue the snmp-server commands for this task does not matter.

SUMMARY STEPS

1. configure

2. snmp-server trap-source interface-type interface-number

3. snmp-server queue-length length

4. snmp-server trap-timeout seconds

5. end

commit

DETAILED STEPS

Command or Actions Purpose

Step 1

configure

Example:

RP/0/RP0/CPU0:router# configure

Enters global configuration mode.

Step 2

snmp-server trap-source interface-type

interface-number

Example:

RP/0/RP0/CPU0:router(config)# snmp-server

trap-source POS 0/0/1/0

(Optional) Specifies a source interface for trap

notifications.

Step 3

snmp-server queue-length length

Example:

RP/0/RP0/CPU0:router(config)# snmp-server

queue-length 20

(Optional) Establishes the message queue length for

each notification.

Step 4

snmp-server trap-timeout seconds

Example:

RP/0/RP0/CPU0:router(config)# snmp-server

trap-timeout 20

(Optional) Defines how often to resend notifications

on the retransmission queue.

Step 5

end

commit

Example:

RP/0/RP0/CPU0:router(config)# end

RP/0/RP0/CPU0:router(config)# commit

Saves configuration changes.

• When you issue the end command, the system

prompts you to commit changes:

Uncommitted changes found, commit them

before exiting(yes/no/cancel)?

[cancel]:

– Entering yes saves configuration changes to

the running configuration file, exits the

configuration session, and returns the router

to EXEC mode.

– Entering no exits the configuration session

and returns the router to EXEC mode without

committing the configuration changes.

– Entering cancel leaves the router in the

current configuration session without exiting

or committing the configuration changes.

• Use the commit command to save the

configuration changes to the running

configuration file and remain within the

configuration session.

Setting IP Precedence and DSCP Values

This task describes how to configure IP Precedence or IP DSCP for SNMP traffic.

Prerequisites

SNMP must be configured.

SUMMARY STEPS

1. configure

2. snmp-server ipv4 precedence value

snmp-server ipv4 dscp value

3. end

commit

DETAILED STEPS

Command or Actions Purpose

Step 1

configure

Example:

RP/0/RP0/CPU0:router# configure

Enters global configuration mode.

Step 2

snmp-server ipv4 precedence value

snmp-server ipv4 dscp value

Example:

RP/0/RP0/CPU0:router(config)# snmp-server dscp 24

Configures an IP precedence or IP DSCP value for

SNMP traffic.

Step 3 end

commit

Example:

RP/0/RP0/CPU0:router(config)# end

RP/0/RP0/CPU0:router(config)# commit

Saves configuration changes.

• When you issue the end command, the system

prompts you to commit changes:

Uncommitted changes found, commit them

before exiting(yes/no/cancel)?

[cancel]:

– Entering yes saves configuration changes to

the running configuration file, exits the

configuration session, and returns the router

to EXEC mode.

– Entering no exits the configuration session

and returns the router to EXEC mode without

committing the configuration changes.

– Entering cancel leaves the router in the

current configuration session without exiting

or committing the configuration changes.

• Use the commit command to save the

configuration changes to the running

configuration file and remain within the

configuration session.

Configuring SNMPv3: Example

Setting an Engine ID

This example shows how to set the identification of the local SNMP engine:

RP/0/RP0/CPU0:MiniQ(config)# snmp-server engineID local

00:00:00:09:00:00:00:a1:61:6c:20:61

Note Once the engine ID has been configured, the SNMP agent restarts.

Verifying the Identification of the Local SNMP Engines

This example shows how to verify the identification of the local SNMP engine:

RP/0/RP0/CPU0:router(config)# show snmp engineid

SNMP engineID 00000009000000a1ffffffff

Creating a View

There are two ways to create a view:

• You can include the object identifier (OID) of an ASN.1 subtree of a MIB family from a view by

using the included keyword of the snmp-server view command.

• You can exclude the OID subtree of the ASN.1 subtree of a MIB family from a view by using the

excluded keyword of the snmp-server view command.

This example shows how to create a view that includes the sysName (1.3.6.1.2.1.1.5) object:

RP/0/RP0/CPU0:router(config)# snmp-server view view_name 1.3.6.1.2.1.1.5 included

This example shows how to create a view that includes all the OIDs of a system group:

RP/0/RP0/CPU0:router(config)# snmp-server view view_name 1.3.6.1.2.1.1 included

This example shows how to create a view that includes all the OIDs under the system group except the

sysName object (1.3.6.1.2.1.1.5), which has been excluded:

RP/0/RP0/CPU0:router(config)# snmp-server view view_name 1.3.6.1.2.1.1 included

RP/0/RP0/CPU0:router(config)# snmp-server view view_name 1.3.6.1.2.1.1.5 excluded

Verifying Configured Views

This example shows how to display information about the configured views:

RP/0/RP0/CPU0:router# show snmp view

v1default 1.3.6.1 - included nonVolatile active

view_name 1.3.6.1.2.1.1 - included nonVolatile active

view_name 1.3.6.1.2.1.1.5 - excluded nonVolatile active

Creating Groups

If you do not explicitly specify a notify, read, or write view, the Cisco IOS XR software uses the v1

default (1.3.6.1). This example shows how to create a group that utilizes the default view:

RP/0/RP0/CPU0:router(config)# snmp-server group group-name v3 auth

The following configuration example shows how to create a group that has read access to all the OIDs

in the system except the sysUpTime object (1.3.6.1.2.1.1.3), which has been excluded from the view

applied to the group, but write access only to the sysName object (1.3.6.1.2.1.1.5):

snmp-server view view_name1 1.3.6.1.2.1.1 included

snmp-server view view_name1 1.3.6.1.2.1.1.3 excluded

snmp-server view view_name2 1.3.6.1.2.1.1.5 included

snmp-server group group_name v3 auth read view_name1 write view_name2

Verifying Groups

This example shows how to verify the attributes of configured groups:

RP/0/RP0/CPU0:router# show snmp group

groupname: group_name security model:usm

readview : view_name1 writeview: view_name2

notifyview: v1default

row status: nonVolatile

Creating and Verifying Users

Given the following SNMPv3 view and SNMPv3 group configuration:

snmp-server view view_name1 1.3.6.1.2.1.1 included

snmp-server group group_name v3 noauth read view_name write view-name

This example shows how to create a noAuthNoPriv user with read and write view access to a system

group:

RP/0/RP0/CPU0:router(config)# snmp-server user noauthuser group_name v3

Note The user must belong to a noauth group before a noAuthNoPriv user can be created.

This example shows how to verify the attributes that apply to the SNMP user:

RP/0/RP0/CPU0:router# show snmp user

User name: noauthuser

Engine ID: localSnmpID

storage-type: nonvolatile active

Given the following SNMPv3 view and SNMPv3 group configuration:

snmp-server view view_name 1.3.6.1.2.1.1 included

snmp group group_name v3 priv read view_name write view_name

This example shows how to create authNoPriv user with read and write view access to a system group:

RP/0/RP0/CPU0:router(config)# snmp-server user authuser group_name v3 auth md5 clear

auth_passwd

Note Because the group is configured at a security level of Auth, the user must be configured as auth at a

minimum to access this group (priv users could also access this group). The authNoPriv user configured

in this group, authuser, must supply an authentication password to access the view. In the example,

auth_passwd is set as the authentication password string. Note that clear keyword is specified before the

auth_passwd password string. The clear keyword indicates that the password string being supplied is

unencrypted.

This example shows how to verify the attributes that apply to SNMP user:

RP/0/RP0/CPU0:router# show snmp user

User name: authuser

Engine ID: localSnmpID

storage-type: nonvolatile active

Given the following SNMPv3 view and SNMPv3 group configuration:

snmp view view_name 1.3.6.1.2.1.1 included

snmp group group_name v3 priv read view_name write view_name

This example shows how to create an authPriv user with read and write view access to a system group:

RP/0/RP0/CPU0:router(config)# snmp-server user privuser group_name v3 auth md5 clear

auth_passwd priv des56 clear priv_passwd

Note Because the group has a security level of Priv, the user must be configured as a priv user to access this

group. In this example, the user, privuser, must supply both an authentication password and privacy

password to access the OIDs in the view.

This example shows how to verify the attributes that apply to the SNMP user:

RP/0/RP0/CPU0:router# show snmp user

User name: privuser

Engine ID: localSnmpID

storage-type: nonvolatile active

Configuring Trap Notifications: Example

The following example configures an SNMP agent to send out different types of traps. The configuration

includes a v2c user, a noAuthNoPriv user, anauthNoPriv user, and an AuthPriv user:

Note The default User Datagram Protocol (UDP) port is 161. If you do not a specify a UDP port with the

udp-port keyword and port argument, then the configured SNMP trap notifications are sent to port 161.

snmp-server host 10.50.32.170 version 2c userv2c udp-port 2345

snmp-server host 10.50.32.170 version 3 auth userV3auth udp-port 2345

snmp-server host 10.50.32.170 version 3 priv userV3priv udp-port 2345

snmp-server host 10.50.32.170 version 3 noauth userV3noauth udp-port 2345

snmp-server user userv2c groupv2c v2c

snmp-server user userV3auth groupV3auth v3 auth md5 encrypted 140F0A13

snmp-server user userV3priv groupV3priv v3 auth md5 encrypted 021E1C43 priv des56

encrypted 1110001C

snmp-server user userV3noauth groupV3noauth v3 LROwner

snmp-server view view_name 1.3 included

snmp-server community public RW

snmp-server group groupv2c v2c read view_name

snmp-server group groupV3auth v3 auth read view_name

snmp-server group groupV3priv v3 priv read view_name

snmp-server group groupV3noauth v3 noauth read view_name

This example shows how to verify the configuration SNMP trap notification recipients host, the

recipients of SNMP trap notifications. The output displays the following information:

• The IP address of the configured notification host

• The UDP port where SNMP notification messages are sent

• The type of trap configured

• The security level of the configured user

• The security model configured

RP/0/RP0/CPU0:router(config)# show snmp host

Notification host: 10.50.32.170 udp-port: 2345 type: trap

user: userV3auth security model: v3 auth

Notification host: 10.50.32.170 udp-port: 2345 type: trap

user: userV3noauth security model: v3 noauth

Notification host: 10.50.32.170 udp-port: 2345 type: trap

user: userV3priv security model: v3 priv

Notification host: 10.50.32.170 udp-port: 2345 type: trap

user: userv2c security model: v2c

Setting an IP Precedence Value for SNMP Traffic: Example

The following example shows how to set the SNMP IP Precedence value to 7:

RP/0/RP0/CPU0:router# configure

RP/0/RP0/CPU0:router(config)# snmp-server ipv4 precedence 7

RP/0/RP0/CPU0:router(config)# exit

Uncommitted changes found, commit them before exiting(yes/no/cancel)? [cancel]: y

RP/0/RP0/CPU0:router#

Setting an IP DSCP Value for SNMP Traffic: Example

The following example shows how to set the IP DSCP value of SNMP traffic to 45:

RP/0/RP0/CPU0:router# configure

RP/0/RP0/CPU0:router(config)# snmp-server ipv4 dscp 45

RP/0/RP0/CPU0:router(config)# exit

Uncommitted changes found, commit them before exiting(yes/no/cancel)? [cancel]: y

RP/0/RP0/CPU0:router#

Monitoring CPU utilization on IOS-XR based platforms using SNMP tools

One of the frequently asked questions is how to monitor CPU utilization on RP, RSP, PRP and Line Cards on IOS-XR based devices using SNMP tools, like MRTG.

Few easy steps described below will help to understand which OIDs have to be used for polling and how differentiate RP, RSP and Line Cards on different platforms.

All examples below, taken from IOS-XR based devices, i.e. CRS, XR12000 and ASR9000 running XR release 4.0.1 with SNMPv2.

Step 1.

snmpwalk for the OID (1.3.6.1.4.1.9.9.109.1.1.1.1.2 ) for the object "cpmCPUTotalPhysicalIndex" gives the PhysicalIndex mapping of cards

NMS% snmpwalk -v2c -c 1.3.6.1.4.1.9.9.109.1.1.1.1.2

SNMPv2-SMI::enterprises.9.9.109.1.1.1.1.2.2 = INTEGER: 2359704

SNMPv2-SMI::enterprises.9.9.109.1.1.1.1.2.18 = INTEGER: 10154515

SNMPv2-SMI::enterprises.9.9.109.1.1.1.1.2.34 = INTEGER: 33511382

SNMPv2-SMI::enterprises.9.9.109.1.1.1.1.2.50 = INTEGER: 48351593

SNMPv2-SMI::enterprises.9.9.109.1.1.1.1.2.514 = INTEGER: 24635790

SNMPv2-SMI::enterprises.9.9.109.1.1.1.1.2.530 = INTEGER: 38114433

RP/0/RP0/CPU0:CRS#sh platform

Node Type PLIM State Config State

------------- ----------------- ---------------- --------------- -----------------------------------------------

0/0/CPU0 MSC 4OC192-POS/DPT IOS XR RUN PWR,NSHUT,MON

0/1/CPU0 MSC 8-10GbE IOS XR RUN PWR,NSHUT,MON

0/2/CPU0 MSC Jacket Card IOS XR RUN PWR,NSHUT,MON

0/3/CPU0 MSC-140G 14-10GbE IOS XR RUN PWR,NSHUT,MON

0/RP0/CPU0 RP(Active) N/A IOS XR RUN PWR,NSHUT,MON

0/RP1/CPU0 RP(Standby) N/A IOS XR RUN PWR,NSHUT,MON

Step 2.

It is possible now to figure out which card is what by polling OID (1.3.6.1.2.1.47.1.1.1.1.7) for object "entPhysicalName" using the

values received in step 1

NMS% snmpwalk -v2c -c 1.3.6.1.2.1.47.1.1.1.1.7.2359704

SNMPv2-SMI::mib-2.47.1.1.1.1.7.2359704 = STRING: "0/0/* - cpu"

NMS% snmpwalk -v2c -c 1.3.6.1.2.1.47.1.1.1.1.7.10154515

SNMPv2-SMI::mib-2.47.1.1.1.1.7.10154515 = STRING: "0/1/* - cpu"

NMS2% snmpwalk -v2c -c 1.3.6.1.2.1.47.1.1.1.1.7.33511382

SNMPv2-SMI::mib-2.47.1.1.1.1.7.33511382 = STRING: "0/2/* - cpu"

NMS% snmpwalk -v2c -c 1.3.6.1.2.1.47.1.1.1.1.7.48351593

SNMPv2-SMI::mib-2.47.1.1.1.1.7.48351593 = STRING: "0/3/* - cpu"

NMS% snmpwalk -v2c -c 1.3.6.1.2.1.47.1.1.1.1.7.24635790

SNMPv2-SMI::mib-2.47.1.1.1.1.7.24635790 = STRING: "0/RP0/* - host"

NMS% snmpwalk -v2c -c 1.3.6.1.2.1.47.1.1.1.1.7.38114433

SNMPv2-SMI::mib-2.47.1.1.1.1.7.38114433 = STRING: "0/RP1/* - host"

So, according to the given example we can identify each RP and/or Line Card and given PhysicalIndex.

Step 3

snmpwalk for the OID (1.3.6.1.4.1.9.9.109.1.1.1.1.7) for the object "cpmCPUTotal1minRev" gives the

CPU utilization percent for one minute for the index above and if, for example, we are talking about RP0 and RP1

we should look at the indexes 514 and 530

NMS% snmpwalk -v2c -c 1.3.6.1.4.1.9.9.109.1.1.1.1.7.514

SNMPv2-SMI::enterprises.9.9.109.1.1.1.1.7.514 = Gauge32: 2

NMS% snmpwalk -v2c -c 1.3.6.1.4.1.9.9.109.1.1.1.1.7.530

SNMPv2-SMI::enterprises.9.9.109.1.1.1.1.7.530 = Gauge32: 1

Corresponding data from the router:

RP/0/RP0/CPU0:CRS#sh proc cpu loc 0/rp0/cpu0

CPU utilization for one minute: 2%; five minutes: 3%; fifteen minutes: 3%

RP/0/RP0/CPU0:CRS#sh proc cpu loc 0/rp1/cpu0

CPU utilization for one minute: 1%; five minutes: 1%; fifteen minutes: 2%

For other line cards:

NMS% snmpwalk -v2c -c 1.3.6.1.4.1.9.9.109.1.1.1.1.7.2

SNMPv2-SMI::enterprises.9.9.109.1.1.1.1.7.2 = Gauge32: 3

NMS% snmpwalk -v2c -c 1.3.6.1.4.1.9.9.109.1.1.1.1.7.18

SNMPv2-SMI::enterprises.9.9.109.1.1.1.1.7.18 = Gauge32: 3

NMS% snmpwalk -v2c -c 1.3.6.1.4.1.9.9.109.1.1.1.1.7.34

SNMPv2-SMI::enterprises.9.9.109.1.1.1.1.7.34 = Gauge32: 5

NMS% snmpwalk -v2c -c 1.3.6.1.4.1.9.9.109.1.1.1.1.7.50

SNMPv2-SMI::enterprises.9.9.109.1.1.1.1.7.50 = Gauge32: 2

Corresponding data from the router:

RP/0/RP0/CPU0:CRS#sh proc cpu loc 0/0/cpu0

CPU utilization for one minute: 3%; five minutes: 3%; fifteen minutes: 3%

RP/0/RP0/CPU0:CRS#sh proc cpu loc 0/1/cpu0

CPU utilization for one minute: 3%; five minutes: 3%; fifteen minutes: 3%

RP/0/RP0/CPU0:CRS#sh proc cpu loc 0/2/cpu0

CPU utilization for one minute: 5%; five minutes: 4%; fifteen minutes: 4%

RP/0/RP0/CPU0:CRSproc cpu loc 0/3/cpu0

CPU utilization for one minute: 2%; five minutes: 2%; fifteen minutes: 2%

Step 4.

Polling the OID (1.3.6.1.4.1.9.9.109.1.1.1.1.8) for the object "cpmCPUTotal5minRev" gives the CPU

utilization percent for 5 minute for the index above and, again, if we are talking about RP0 and RP1

we should look at the indexes 514 and 530

NMS% snmpwalk -v2c -c 1.3.6.1.4.1.9.9.109.1.1.1.1.8.514

SNMPv2-SMI::enterprises.9.9.109.1.1.1.1.8.514 = Gauge32: 2

NMS% snmpwalk -v2c -c 1.3.6.1.4.1.9.9.109.1.1.1.1.8.530

SNMPv2-SMI::enterprises.9.9.109.1.1.1.1.8.530 = Gauge32: 1

And corresponding data from the router:

RP/0/RP0/CPU0:CRS#sh proc cpu loc 0/rp0/cpu0

CPU utilization for one minute: 2%; five minutes: 2%; fifteen minutes: 2%

RP/0/RP0/CPU0:CRS#sh proc cpu loc 0/rp1/cpu0

CPU utilization for one minute: 1%; five minutes: 1%; fifteen minutes: 1%

The same approach works for XR12000 routers, as it shown in given example

-Obtaining PhysicalIndex mapping

NMS% snmpwalk -v2c -c 1.3.6.1.4.1.9.9.109.1.1.1.1.2

SNMPv2-SMI::enterprises.9.9.109.1.1.1.1.2.17 = INTEGER: 26932192

SNMPv2-SMI::enterprises.9.9.109.1.1.1.1.2.33 = INTEGER: 16733769

SNMPv2-SMI::enterprises.9.9.109.1.1.1.1.2.49 = INTEGER: 65129206

RP/0/1/CPU0:XR12000#sh platform

Node Type PLIM State Config State

------------------------------------------------------------------------------------------------------------

0/1/CPU0 PRP(Active) N/A IOS XR RUN PWR,NSHUT,MON

0/2/CPU0 L3LC Eng 5+ Jacket Card IOS XR RUN PWR,NSHUT,MON

0/3/CPU0 L3LC Eng 5+ Jacket Card IOS XR RUN PWR,NSHUT,MON

-Verifying which card should be used for polling

NMS% snmpwalk -v2c -c 1.3.6.1.2.1.47.1.1.1.1.7.26932192

SNMPv2-SMI::mib-2.47.1.1.1.1.7.26932192 = STRING: "0/1/CPU0 - host"

NMS% snmpwalk -v2c -c 1.3.6.1.2.1.47.1.1.1.1.7.16733769

SNMPv2-SMI::mib-2.47.1.1.1.1.7.16733769 = STRING: "0/2/CPU0 - host"

NMS% snmpwalk -v2c -c 1.3.6.1.2.1.47.1.1.1.1.7.65129206

SNMPv2-SMI::mib-2.47.1.1.1.1.7.65129206 = STRING: "0/3/CPU0 - host

-Verifying CPU utilization for one minute (as an example)

NMS% snmpwalk -v2c -c 1.3.6.1.4.1.9.9.109.1.1.1.1.7.17

SNMPv2-SMI::enterprises.9.9.109.1.1.1.1.7.17 = Gauge32: 2

Corresponding data from the router from Active PRP, so, without "location" keyword

RP/0/1/CPU0:XR12000#sh proc cpu

CPU utilization for one minute: 2%; five minutes: 2%; fifteen minutes: 1%

And finally, example for ASR9000

-Obtaining PhysicalIndex mapping

NMS% snmpwalk -v2c -c 1.3.6.1.4.1.9.9.109.1.1.1.1.2

SNMPv2-SMI::enterprises.9.9.109.1.1.1.1.2.2 = INTEGER: 52690955

SNMPv2-SMI::enterprises.9.9.109.1.1.1.1.2.2082 = INTEGER:35271015

SNMPv2-SMI::enterprises.9.9.109.1.1.1.1.2.2098 = INTEGER: 8695772

RP/0/RSP0/CPU0:ASR9000#sh platform

Node Type State Config State

----------------------------------------------------------------------------------------------------------

0/RSP0/CPU0 A9K-RSP-4G(Active) IOS XR RUN PWR,NSHUT,MON

0/0/CPU0 A9K-4T-E IOS XR RUN PWR,NSHUT,MON

0/1/CPU0 A9K-40GE-E IOS XR RUN PWR,NSHUT,MON

-Verifying which card should be used for polling

NMS% snmpwalk -v2c -c 1.3.6.1.2.1.47.1.1.1.1.7.52690955

SNMPv2-SMI::mib-2.47.1.1.1.1.7.52690955 = STRING: "module 0/RSP0/CPU0"

NMS% snmpwalk -v2c -c 1.3.6.1.2.1.47.1.1.1.1.7.35271015

SNMPv2-SMI::mib-2.47.1.1.1.1.7.35271015 = STRING: "module 0/0/CPU0"

NMS% snmpwalk -v2c -c 1.3.6.1.2.1.47.1.1.1.1.7.8695772

SNMPv2-SMI::mib-2.47.1.1.1.1.7.8695772 = STRING: "module 0/1/CPU0"

-Verifying CPU utilization for one minute (as an example)

NMS% snmpwalk -v2c -c 1.3.6.1.4.1.9.9.109.1.1.1.1.7.2

SNMPv2-SMI::enterprises.9.9.109.1.1.1.1.7.2 = Gauge32: 3

Corresponding data from the router:

RP/0/RSP0/CPU0:ASR9000#sh proc cpu

CPU utilization for one minute: 3%; five minutes: 3%; fifteen minutes: 3%

So, the mentioned OIDs should be used on NMS system for polling IOS-XR based devices to get CPU utilization on different Line Cards and RP, RSP and PRP

SNMPWALK

NAME

snmpwalk - retrieve a subtree of management values using SNMP GETNEXT requests

SYNOPSIS

snmpwalk [APPLICATION OPTIONS] [COMMON OPTIONS] [OID]

DESCRIPTION

snmpwalk is an SNMP application that uses SNMP GETNEXT requests to query a network entity for a tree of information.

An object identifier (OID) may be given on the command line. This OID specifies which portion of the object identifier space will be searched using GETNEXT requests. All variables in the subtree below the given OID are queried and their values presented to the user. Each variable name is given in the format specified in variables(5).
If no OID argument is present, snmpwalk will search the subtree rooted at SNMPv2-SMI::mib-2 (including any MIB object values from other MIB modules, that are defined as lying within this subtree). If the network entity has an error processing the request packet, an error packet will be returned and a message will be shown, helping to pinpoint why the request was malformed.
If the tree search causes attempts to search beyond the end of the MIB, the message "End of MIB" will be displayed.

OPTIONS

-Cc

Do not check whether the returned OIDs are increasing. Some agents (LaserJets are an example) return OIDs out of order, but can complete the walk anyway. Other agents return OIDs that are out of order and can cause snmpwalk to loop indefinitely. By default, snmpwalk tries to detect this behavior and warns you when it hits an agent acting illegally. Use -Cc to turn off this check.

-CE {OID}

End the walk at the specified OID, rather than a simple subtree. This can be used to walk a partial subtree, selected columns of a table, or even two or more tables within a single command.

-Ci

Include the given OID in the search range. Normally snmpwalk uses GETNEXT requests starting with the OID you specified and returns all results in the MIB subtree rooted at that OID. Sometimes, you may wish to include the OID specified on the command line in the printed results if it is a valid OID in the tree itself. This option lets you do this explicitly.

-CI

In fact, the given OID will be retrieved automatically if the main subtree walk returns no useable values. This allows a walk of a single instance to behave as generally expected, and return the specified instance value. This option turns off this final GET request, so a walk of a single instance will return nothing.

-Cp

Upon completion of the walk, print the number of variables found.

-Ct

Upon completion of the walk, print the total wall-clock time it took to collect the data (in seconds). Note that the timer is started just before the beginning of the data request series and stopped just after it finishes. Most importantly, this means that it does not include snmp library initialization, shutdown, argument processing, and any other overhead.

In addition to these options, snmpwalk takes the common options described in the snmpcmd(1) manual page.

EXAMPLES

The command:

snmpwalk -Os -c public -v 1 zeus system
will retrieve all of the variables under system:
sysDescr.0 = STRING: "SunOS zeus.net.cmu.edu 4.1.3_U1 1 sun4m"
sysObjectID.0 = OID: enterprises.hp.nm.hpsystem.10.1.1
sysUpTime.0 = Timeticks: (155274552) 17 days, 23:19:05
sysContact.0 = STRING: ""
sysName.0 = STRING: "zeus.net.cmu.edu"
sysLocation.0 = STRING: ""
sysServices.0 = INTEGER: 72
(plus the contents of the sysORTable).
The command:
snmpwalk -Os -c public -v 1 -CE sysORTable zeus system
will retrieve the scalar values, but omit the sysORTable.

VARIABLES

size=2 width="100%" noshade style='color:black' align=center>

NAME

variables - Format of specifying variable names to SNMP tools.

SYNOPSIS

system.sysdescr.0

DESCRIPTION

Variable names are in the format of Object Identifiers (ASN.1). There are several methods of representation. Each variable name is given in the format of A.B.C.D..., where A, B, C, and D are subidentifiers in one of two forms of notation. Each subidentifier may be encoded as a decimal integer, or a symbol as found in the RFC1066 MIB. The case of the symbols is not significant.
If there is no leading "." in the variable name, the name will be formed as if having been preceded with "iso.org.dod.internet.mgmt.mib.". A "." must be placed before the first variable if the user is to fully specify the name. For example:

1.1.0 system.sysDescr.0 and 1.sysDescr.0
all refer to the same variable name. Likewise:
.1.3.6.1.2.1.1.1.0 .iso.org.dod.internet.mgmt.mib.system.sysdescr.0 .1.3.6.1.2.1.1.sysdescr.0
All refer to the same variable name.
The description of the variables in the MIB is given in the set of MIB files defined by the MIBS environment variable (or the default list defined at compilation time) and the MIB files in the /usr/local/share/snmp/mibs directory (or the MIBDIRS environment variable).

The snmpwalk command is designed to perform a sequence of chained GETNEXT requests automatically, rather than having to issue the necessary snmpgetnext requests by hand.

The snmpwalk is designed to retrieve multiple OIDs and values from the remote agent. But unlike most of the other command-line tools, it can only work with a single starting OID. It is not possible to supply multiple OIDs as part of the same command.

Or more accurately - it is possible to specify several OIDs, but everything other than the first one will be ignored!

SNMP, at its core, allows a management station to treat its network as a distributed database of health and configuration information (and much more). It's an IETF standardized protocol and "should" work the same way across every implementation. Even the data that can be retrieved and manipulated via SNMP is standardized in TUT:MIBs so conversing with one host about, for example, its routing table can be done in the same way regardless of which vendor created the device being spoken to.

SNMP stands for "Simple Network Management Protocol". The protocol is "simple" (but not necessarily its implementation) as it contains only a few important operations. These operations are functionally:

GET	Retrieve data from a network node
GETNEXT	Retrieve the next element from a network node (more on this later)
SET	Send configuration or control commands to a network node
TRAP	A network node can send a notification to the management station
INFORM	An acknowledged trap (network nodes can try and send it again if no acknowledgement is received)

CONFD SNMP

Overview
ConfD is a powerful solution for building on-device management systems for all kinds of networking equipment. The ConfD SNMP Agent is an integrated SNMP agent providing northbound SNMP interfaces for element management and monitoring.

Fully Featured SNMP Support
ConfD SNMP Agent is fully featured and supports SNMP v1, v2c, and v3 including the various security features in v3 including USM and VACM. The MIB compiler supports SMIv1 and SMIv2. ConfD can be used both as master-agent or sub-agent in scenarios where an existing SNMP agent needs to coexist in the same element. The following RFCs are supported:

The ConfD SNMP Agent can use ConfD’s AAA as well as SNMP-specific authentication schemes to manage access.

ConfD Integration
ConfD provides an environment where SNMP and other agents such as NETCONF, Web UI, and CLI, coexist and use the same built-in database for configuration storage and the same set of instrumentation functions for controlling managed objects. Simple bindings from SNMP MIB objects to YANG objects are all that is needed to open up a configuration database to be accessed by an SNMP manager. Developers avoid the time consuming work of writing a separate set of instrumentation functions just for SNMP.

SNMP Gateway
ConfD SNMP Gateway makes data from existing SNMP agents available through the management interfaces (such as CLI and NETCONF). In this scenario, ConfD co-exists with an SNMP agent on the device and uses the SNMP protocol to retrieve data from the agent presenting it as a part of a unified view of all configuration and operational data to the northbound agents.

Platform Support
ConfD supports most versions of Linux and is implemented as a lean daemon with few library dependencies and efficient use of RAM, and disk footprint.

Loading MIBs

The ConfD SNMP agent have the following built-in MIBs:

• SNMPv2-MIB, a mandatory MIB for an agent. This MIB is always loaded at start-up.

• SNMP-MPD-MIB, a mandatory MIB for an agent. This MIB is always loaded at start-up if the

agent is configured for SNMPv3.

• SNMP-FRAMEWORK-MIB, a mandatory MIB for an agent. This MIB is always loaded at startup

if the agent is configured for SNMPv3.

• SNMP-COMMUNITY-MIB, handles SNMP v1 and v2c communities.

• SNMP-VIEW-BASED-ACM-MIB, handles the view based access control.

• SNMP-USER-BASED-SM-MIB, handles the user based access control.

• SNMP-TARGET-MIB, to be able to configure targets for SNMP traps.

• SNMP-NOTIFICATION-MIB, defines SNMP traps.

• IPV6-TC, defines some IPv6 specific TEXTUAL-CONVENTIONs.

• TRANSPORT-ADDRESS-MIB, defines some OBJECT-IDENTITYs for transport protocols. This

MIB module cannot be loaded as a built-in module in the agent. If some other MIB IMPORTs this

MIB, then it needs to be compiled and loaded as other non-built-in MIBs.

• SNMP-USM-AES-MIB, defines an OBJECT-IDENTITY for the AES privacy protocol. This MIB

module must not be loaded into the agent.

These MIBs of course must have their corresponding YANG .fxs files loaded in order for the SNMP

agent to work (see the next section). The MIBs themselves are not required to be loaded. The user

decides which MIBs should be loaded, and there may be reasons to not provide SNMP access to

certain MIBs.

The MIBs: SNMPv2-MIB, SNMP-MPD-MIB and SNMP-FRAMEWORK-MIB, are always loaded

into the ConfD SNMP agent at start-up. These MIBs are required for an SNMP agent.

The other built-in MIBs are not loaded per default, which means that they cannot be accessed/

configured via SNMP but of course via for example CDB init files (see Section 5.8, “Loading initial

data into CDB”) NETCONF, or even CLI directly. If the intention is to have these MIBs loaded, they

must be listed in confd.conf without any explicit paths to where they are stored as shown in the

example below

Other MIBs (that are not built-in) are loaded by specifying their absolute or relative paths, or

alternatively the MIBs can be loaded from ConfDs loadPath. We recommend that these MIBs are

loaded from the load path. This is how other data model files (.fxs etc) are handled.

The main reason for this recommendation is how MIBs can be dynamically reloaded. MIBs that are

explicitly listed are reloaded by giving the command confd --reload. If any MIB cannot be loaded

for whatever reason, ConfD halts. MIBs in the load path are reloaded using the data model upgrade

functions,

---------------------------------------------

What is the MIB?

The MIB, or Management Information Base, is an

ASCII text file that describes SNMP network elements

as a list of data objects. Think of it as a dictionary of the

SNMP language — every object referred to in an

SNMP message must be listed in the MIB.

What does the MIB do?

The fundamental purpose of the MIB is to translate

numerical strings into human-readable text. When an

SNMP device sends a Trap or other message, it identifies

each data object in the message with a number

string called an object identifier, or OID. (OIDs are

defined more fully later in this paper.)

The MIB provides a text label called for each OID.

Your SNMP manager uses the MIB as a codebook for

translating the OID numbers into a human-readable

display.

Why do I need the MIB?

Your SNMP manager needs the MIB in order to

process messages from your devices. Without the MIB,

the message is just a meaningless string of numbers.

How do I get the MIB into my SNMP

manager?

Your SNMP manager imports the MIB through a software

function called compiling. Compiling converts

the MIB from its raw ASCII format into a binary format

the SNMP manager can use.

Why is the MIB important?

Because as far as SNMP managers and agents are concerned,

if a component of a network device isn’t

described in the MIB, it doesn’t exist.

For example, let’s say you have an SNMP RTU with a

built-in temperature sensor. You think you’ll get temperature

alarms from this device — but you never do,

no matter how hot it gets. Why not? You read the

RTU’s MIB file and find out that it only lists discrete

points, and not the temperature sensor. Since the sensor

isn’t described in the MIB, the RTU can’t send Traps

with temperature data.

Why do I need to understand the MIB?

As you can see, the MIB is your best guide to the real

capabilities of an SNMP device. Just looking at the

physical components of a device won’t tell you what

kind of Traps you can get from it. You might think it’s

strange that a manufacturer would add a component to

a device and not describe it in the MIB. But the fact is,

a lot of devices have sketchy MIBs that don’t fully

support all their functions.

When you’re planning your SNMP monitoring, you

need to be able to read MIBs so you can have a realistic

idea of what capabilities you have. When you’re

evaluating new SNMP equipment, examine its MIB

file carefully before you purchase.

How do I look at a MIB?

AMIB file is just ASCII text, so you can view it in any

word processor or text editor, such as Microsoft

Notepad. Some manufacturers provide precompiled

MIBs in binary format, but those aren’t readable. You

want the raw ASCII version of the MIB file.

Note: MIB files are sometimes provided as Unix text

files. Unix text format is significantly different from

DOS/Windows text format. DOS/Windows text files

have a carriage return and a line feed at the end of each

line; Unix files only have a line feed. If you want to

view MIB files on a Windows PC, ask your vendor for

a DOS-formatted version, or you can use a conversion

utility to convert between text formats.

Will I need to edit the MIB?

Generally speaking, no. MIB files aren’t really

designed to be edited by the end user. Theoretically,

you could edit the text descriptions of managed

objects to be more user-friendly, but it’s better to use

your SNMP manager’s presentation software to create

a useful display.

How do I read the MIB?

To read a MIB file, you have to understand just a little

about how the MIB is structured. Don’t worry — you

don’t have to master MIB notation in order to get useful

information from the MIB. In this paper we’re

going to cover just the essentials you need to know to

discover the telemetry capabilities of SNMP devices.

What does a MIB look like?

For an example, here are the first few lines of the standard

DPS Telecom MIB file:

DPS-MIB-V38 DEFINITIONS ::= BEGIN

IMPORTS

DisplayString

FROM RFC1213-MIB

OBJECT-TYPE

FROM RFC-1212

enterprises

FROM RFC1155-SMI;

dpsInc OBJECT IDENTIFIER ::= {enterprises 2682}

dpsAlarmControl OBJECT IDENTIFIER ::= {dpsInc 1}

tmonXM OBJECT IDENTIFIER ::= {dpsAlarmControl 1}

tmonIdent OBJECT IDENTIFIER ::= {tmonXM 1}

tmonIdentManufacturer OBJECT-TYPE

SYNTAX DisplayString

ACCESS read-only

STATUS mandatory

DESCRIPTION “The TMON/XM Unit manufacturer.”

::= {tmonIdent 1}

tmonIdentModel OBJECT-TYPE

SYNTAX DisplayString

ACCESS read-only

STATUS mandatory

DESCRIPTION “The TMON/XM model designation.”

Wow! What language is that?

The MIB is written in ASN.1 notation. (The initials stand for

Abstract Syntax Notation 1.) ASN.1 is a standard notation

maintained by the ISO (International Organization for

Standardization) and used in everything from the World Wide

Web to aviation control systems.

A full description of ASN.1 is completely beyond the scope of

this white paper — standard references to ASN.1 run up to 600

pages. For our purposes, there are only a few things to understand

about ASN.1:

1. It’s human-readable.

2 It’s specifically designed for communication between dissimilar

computer systems, so it’s the same for every

machine.

3. It’s extensible, so it can be used for describing almost anything.

4. Once a term is defined in ASN.1, it can be used as a building

block for making other terms. This is very important

for understanding MIB structure — you’ll see why later

on.

How ASN.1 builds new terms out of existing

terms

ASN.1 defines each term as a sequence of components, some

of which may be sequences themselves. To give a simplified

example, here’s how you might describe a letter in ASN.1:

Letter ::= SEQUENCE {

opening OCTET STRING,

body OCTET STRING,

closing OCTET STRING,

address AddressType

}

Note that while most of the elements in this sequence are

defined using a primitive element (the “octet string,” which is

the equivalent of a byte), the address is simply defined as a

text string, “AddressType.” You can do this because

AddressType is defined in another sequence, like so:

AddressType ::= SEQUENCE {

name OCTET STRING,

number INTEGER,

street OCTET STRING,

city OCTET STRING,

state OCTET STRING,

zipCode INTEGER

}

For a computer parsing the sequence “Letter,” AddressType

will be read as an instruction to insert the octet string and integer

structures listed in the sequence that defines AddressType

What terms are defined in the MIB?

The elements defined in the MIB can be extremely broad (for

example, all objects created by private businesses) or they can

be extremely specific (like a particular Trap message generated

by a specific alarm point on an RTU.)

Each element in the MIB is given an object identifier, or OID.

An OID is a number that uniquely identifies an element in the

SNMP universe. Each OID is associated with a human-readable

text label.

What is the function of an OID?

The OIDs identify the data objects that are the subjects of an

SNMP message. When your SNMP device sends a Trap or a

GetResponse, it transmits a series of OIDs, paired with their

current values.

The location of the OID within the overall SNMP packet is

shown in Figure 1.

What does an OID look like?

Here’s an example: 1.3.6.1.4.1.2681.1.2.102

OK ... but what does it mean?

The OID is a kind of address. It locates this particular element

within the entire SNMP universe. The OID describes a tree

structure, as shown in Figure 2, and each number separated by

a decimal point represents a branch on that tree.

The first few numbers identify the domain of the organization

that issued the OID, followed by numbers that identify objects

within the domain. Imagine if your home address started

“Universe, Milky Way Galaxy ...” and ended with your house

number. In a similar way, each OID begins at the root level of

the OID domain and gradually becomes more specific.

Each element of the OID also has a human-readable text designation.

From left to right, our sample OID reads:

1 (iso): The International Organization for Standardization,

(org): An ISO-recognized organization.

6 (dod): U.S. Department of Defense, the agency originally

responsible for the Internet.

1 (internet): Internet OID.

4 (private): Private organizations.

1 (enterprises): Business enterprises.

2682 (dpsInc): DPS Telecom.

1 (dpsAlarmControl): DPS alarm and control devices.

2 (dpsRTU): DPS remote telemetry unit.

102 (dpsRTUsumPClr): A Trap generated when all the

alarm points on an RTU are clear

When I look at my MIB files, I don’t see long

strings of numbers like that

That’s because each element of an OID only needs to be

defined once. Remember, in ASN.1 notation, once a term is

defined, it can be used as a building block to define other

terms. The last number of an OID — its most specific element

— refers back to the more general elements defined

earlier in the MIB.

Here’s how the last four elements in our sample OID are

defined in the DPS Telecom MIB:

dpsInc OBJECT IDENTIFIER ::= {enterprises 2682}

dpsAlarmControl OBJECT IDENTIFIER ::= {dpsInc 1}

dpsRTU OBJECT IDENTIFIER ::= {dpsAlarmControl 2}

dpsRTUsumPClr TRAP-TYPE

ENTERPRISE dpsRTU

VARIABLES { sysDescr, sysLocation,

dpsRTUDateTime }

DESCRIPTION “Generated when all points

clear.”

::= 102

Look at how each term is defined as the term that came

immediately before it in the OID, plus one more element.

For example, dpsInc is enterprises (1.3.6.1.4) plus one more

element, called 2682. The next term, dpsAlarmControl, is

dpsInc (1.3.6.1.4.2682), plus one more element, called 1.

And so on. Each term in the OID is defined as an extension

of earlier terms, going all the way back to the root term, iso.

An OID is meaningless unless every element it refers to is

specifically called out and identified in the MIB. So when

you’re compiling your MIB files on your SNMP manager, you

need to supply not only the OIDs defined by your equipment

vendor, but also OIDs for public entities: iso, org, dod, internet,

and so on.

So every MIB file needs to describe the entire

OID tree?

Fortunately, no. The upper levels of the OID tree — the parts

that define the general OID structure — are defined in a series

of standard reference MIB files called RFCs.

(The initials stand for Request for Comment. The RFCs that

define SNMP OIDs are part of a larger group of RFC documents

that define the Internet as a whole.)

The RFC MIB defines a basic dictionary of terms that vendors

use to write their own equipment-specific MIBs. So a vendorcreated

MIB doesn’t have to define the entire OID tree. The

vendor’s MIB file only has to define the unique OIDs that

describe the vendor’s equipment.

At the beginning of every MIB file is an IMPORTS line that

calls out the terms used in the MIB and the RFC MIB that

defines those terms.

Let’s take another look at the very beginning of the DPS

Telecom MIB:

DPS-MIB-V38 DEFINITIONS ::= BEGIN

IMPORTS

DisplayString

FROM RFC1213-MIB

OBJECT-TYPE

FROM RFC-1212

enterprises

FROM RFC1155-SMI;

From this IMPORTS line we can read that the DPS

MIB is written using three terms defined in other MIBs

— DisplayString, OBJECT-TYPE and enterprises —

and these terms are defined in the RFC MIBs listed.

All MIB files are written as extensions of the master

RFCs. For this reason, you’ll sometimes hear people

say that there’s only one MIB for all SNMP devices,

and that individual MIB files are merely subsections of

the unified Management Information Base.

That may be true in theory, but in real life, you only

need to worry about the equipment you use, the MIBs

that support your equipment, and the RFCs that support

those MIBs.

So I’m reading the MIB. What information

am I looking for?

You don’t need to carefully read over every last line of

the MIB file. For your purposes, you’re only looking

for particular items that will tell you what elements of

the device you can monitor and control.

A well-written MIB will be divided into sections.

Sections will be identified by comment lines. (In MIB

notation, comments lines are identified by two

hyphens.) So if you find a line that reads something

like:

—- TRAP definitions

You know you’ve found what you’re looking for.

There are also text labels that identify the MIB objects

you’re interested in. For example, in SNMP v1 MIBs,

Traps are identified by the text label “TRAP-TYPE.” If

you know the text labels for the kinds of objects you’re

looking for, you can scan the MIB in a series of Ctrl-F

searches.

The MIB objects you need to know

From the perspective of a telemetry manager, what you

need to know from the MIB is:

1. What other RFC MIBs you need to support this

device

2. What event reports (Traps) the device can send to

the SNMP manager

3. What information you can request from the device

(the SNMP equivalent of an alarm poll)

4. What characteristics of the device you can control

via SNMP

RFC MIBs

The first thing you should look for in the MIB is what

RFC MIBs are required to support this device. The

necessary RFCs will be called out in the IMPORTS

line at the beginning of the MIB.

Traps: Event Reports

For telemetry purposes, the MIB elements you’re most

interested in are what Traps the device can send. Traps

are often described as alarms, but it’s better to think of

them as event reports.

When a Trap is called out in the MIB, it means that the

device is configured to generate a report whenever the

element listed changes state. This doesn’t mean that

the event is necessarily important. Many Traps are

merely status messages.

In SNMP v1 MIBs, Traps are always designated with

the text label TRAP-TYPE. Here’s an example from

the MIB for the DPS Telecom NetGuardian RTU::

dpsRTUp8005Set TRAP-TYPE

ENTERPRISE dpsRTU

VARIABLES { sysDescr, sysLocation,

dpsRTUDateTime,

dpsRTUAPort, dpsRTUCAddress,

dpsRTUADisplay, dpsRTUAPoint,

dpsRTUAPntDesc, dpsRTUAState }

DESCRIPTION “Generated when discrete

point 5 is set.”

::= 8005

Fortunately, you can ignore a lot of this gobbledygook.

OBJECT-TYPE

FROM RFC-1212

enterprises

FROM RFC1155-SMI;

From this IMPORTS line we can read that the DPS

MIB is written using three terms defined in other MIBs

— DisplayString, OBJECT-TYPE and enterprises —

and these terms are defined in the RFC MIBs listed.

All MIB files are written as extensions of the master

RFCs. For this reason, you’ll sometimes hear people

say that there’s only one MIB for all SNMP devices,

and that individual MIB files are merely subsections of

the unified Management Information Base.

That may be true in theory, but in real life, you only

need to worry about the equipment you use, the MIBs

that support your equipment, and the RFCs that support

those MIBs.

I want to use a device feature that

isn’t described in the MIB. What can

I do?

You can ask the vendor to extend the MIB to

include this feature. DPS Telecom has extended its

MIB to support client needs. But you need to

understand that extending a MIB is actually a software

development project. The MIB is not just a

text file. It’s also a software interface document to

the embedded firmware of your SNMP device.

Making additions to the MIB requires rewriting

the device firmware.

This is a serious project, involving writing code,

debugging it, and undergoing a thorough quality

assurance process.

Here are the elements that you’re interested in:

TRAP-TYPE: This tells you it’s a Trap.

DESCRIPTION: This is a human-readable description of the

Trap. It should give you a good basic indication of what the

Trap signifies.

VARIABLES: This tells you actual information will be

included in the Trap. When an actual Trap is sent, each of these

variables will be paired with a numerical value that indicates

its current state. A variable-and-value pair is called a variable

binding.

The variables look pretty cryptic, but it’s easy to find out what

they mean. Each variable is a text label for an OID defined

elsewhere in the MIB. You can do a

Ctrl-F search for any variable term and find its definition. For

example, “dpsRTUAPort” is defined in the DPS MIB like this:

dpsRTUAPort OBJECT-TYPE

SYNTAX INTEGER

ACCESS read-only

STATUS mandatory

DESCRIPTION “RTU port number.”

::= {dpsRTUAlarmEntry 1}

Trap variables are your best guide to what alarms you’ll get

from an SNMP device. Depending on the device, the variables

can be highly detailed or they can be vague summary alarms.

Object-Types: Data you can read and sometimes

write

When reading the MIB, you’ll also want to know what information

you can directly request from the device, and what

information you can send to the device. These functions are

controlled by the SNMP commands GetRequest and

SetRequest.

If you want to translate these commands into classic telemetry

terms, you can roughly think of a GetRequest as an alarm poll

and a SetRequest as a control command.

GetRequests and SetRequests operate on a type of element

called an object-type. Object-types are called out in the MIB

like this:

tmonAState OBJECT-TYPE

SYNTAX DisplayString (SIZE (8))

ACCESS read-only

STATUS mandatory

DESCRIPTION “The current alarm state.”

::= {tmonAlarmEntry 4}

There are many different kinds of object-types. The specific

object-types you might find in a MIB depend on the type of

device, what kind of components it has, what the functions of

those components, are, etc.

You’re probably not going to be interested in every object-type

listed in the MIB, because you’re not going to be interested in

everything about the device’s functions.

When searching for object-types, it’s helpful to start with a

plan of what functions of the device you want to manage.

What information do you want to retrieve? What controls do

you want to set? Knowing the device’s functions and how you

want to use them will help you narrow down what object-types

you should look for in the MIB.

Access

The most important entry in an object-type description is the

ACCESS line. This controls whether you can read and write

the data described in the object-type.

There are three access settings: not-accessible, read-only and

read-write.

Not-accessible means the object-type is there, but you can’t

request the data in a GetRequest.

Read-only means you can request the data in a GetRequest,

but you can’t write new data for the object-type in a

SetRequest.

Read-write means you’re free to retrieve the data in a

GetRequest and write new data for the object-type in a

SetRequest.

In the example of the alarm state object-type:

tmonAState OBJECT-TYPE

SYNTAX DisplayString (SIZE (8))

ACCESS read-only

STATUS mandatory

DESCRIPTION “The current alarm state.”

::= {tmonAlarmEntry 4}

The access here is read-only, because the alarm state is set by

the alarm input on that alarm point.

Here’s an example of an object-type with read-write access:

dpsRTUDateTime OBJECT-TYPE

SYNTAX DisplayString (SIZE (23))

ACCESS read-write

STATUS mandatory

DESCRIPTION “The RTU system date and time.”

::= {dpsRTUIdent 4}

Here the access is read-write, because this is a value that you

can set from your SNMP manager. You can retrieve the current

settings from the RTU’s internal clock through a GetRequest.

And if the clock needs to be reset, you can write new data in a

SetRequest.

Quick Primer on SNMP

Messages

In SNMP v1, there are only 5 basic PDUs

(program datagram units):

GetRequest: a manager-to-agent message

requesting the current value of a managed

object.

GetNext: a manager-to-agent message

requesting the current value of the managed

object one number after the one named in

the request. (This is a way of walking down

a table of values.)

SetRequest: a manager-to-agent message

that writes a new value to a managed object

GetResponse: an agent-to-manager message

in response to a GetRequest or a

SetRequest. In either case, the message

reports the current value of the managed

object named in the manager’s request

Trap: an agent-to-manager message reporting

a change in the value of a managed

object

====================

SNMPv3 - User Security Model

This is the first of two articles describing the security features of the SNMP version 3 protocol. The SNMPv3 RFCs describe a new framework that is used for defining the relationships between the SNMP versions 1, 2, and 3 specifications. This framework is partitioned in a modular fashion and is heavily based on previous work (i.e. SNMPv1, SNMPv2c, SNMPv2u, and SNMPv2*).

Two core modules within the framework are the User-based Security Model (USM) and the View-based Access Control Model (VACM). The USM is in charge of authenticating/encrypting/decrypting SNMP packets and the VACM is in charge of administering access to MIB data. This article gives an overview of the USM, and next month we will take a look at the VACM.

The USM is specified in RFC 2574. A weak point of all the previous well known SNMP versions has been the lack of a solid, agreed upon, security scheme. In designing the USM, these classic security threats had to be addressed:

Modification of Information (Data Integrity)

Ensure that the data is not maliciously altered during transit by an unauthorized entity.

Masquerading (Data Origin Authentication)

Ensure that it is known exactly who and where the data came from to prevent an unauthorized entity from assuming the identity of an authorized user.

Disclosure (Data Confidentiality)

Ensure that an unauthorized entity cannot eavesdrop on the data exchanges.

Message Stream Modification (Message Timeliness)

Ensure that the data was received in a timely manner to prevent malicious re-ordering of data by an unauthorized entity.

The USM is able to protect SNMPv3 packets from the above threats by utilizing a concept of multiple users where each user provides secret keys for authentication and privacy. The authentication protocols specified for use are HMAC-MD5 and HMAC-SHA. The privacy protocol specified is CBC-DES. The RFC states that the security protocols used for the USM are considered acceptably secure at the time of its writing. However, the model allows for new authentication and privacy protocols to be specified at a future time if the need arises.

Concepts

The SNMPv3 framework introduces many new concepts. Most of these concepts are used by multiple modules within the framework. Here are a few that are used by the USM:

snmpEngineID

A unique identifier for an SNMP engine within an administrative domain. The value of this octet string cannot be zero length, all '0x00'H, or all '0xFF'H. The snmpEngineID is usually computed using a combination of the enterprise number, IP or MAC address, and an administratively assigned string.

snmpEngineBoots

A count of the number of times an SNMP engine has re-booted or re-initialized since the snmpEngineID was last set. This counter is initially set to zero.

snmpEngineTime

The number of seconds since the snmpEngineBoots counter was last incremented. This counter is initially set to zero. If the snmpEngineTime reaches its maximum (2147483647), then the snmpEngineBoots is incremented by one and the snmpEngineTime starts counting again from zero.

snmpSecurityLevel

There are three possible security levels: noAuthNoPriv, authNoPriv, and authPriv. The noAuthNoPriv level specifies no authentication or privacy is performed. The authNoPriv level specifies that authentication is performed but not privacy. And the authPriv level specifies that both authentication and privacy are being performed. One reason why a noAuthPriv security level does not exist is because a message authentication digest is needed to ensure the integrity of the security parameters, namely the privacy parameters (i.e. DES salt).

Authoritative SNMP Engine

In order to protect against message replay, delay, and redirection, one of the communicating SNMP engines is designated as the Authoritative SNMP Engine. The Authoritative SNMP Engine is an engine which receives SNMP messages which need a response. This is always the agent that a manager communicates with.

SNMPv3 Packet Format

-------------------------

/|\ | msgVersion |

| |-----------------------|

| | msgID |

| |-----------------------| USM Security Parameters

| | msgMaxSize |

| |-----------------------| /-------------------------------

scope of |-----------------------| / |-----------------------------|

authentication | msgSecurityModel | / | msgAuthoritativeEngineBoots |

| |-----------------------|/ |-----------------------------|

| | msgSecurityParameters | |-----------------------------|

| |-----------------------|\ |-----------------------------|

| /|\ | | \ | msgAuthenticationParameters |

| | | | \ |-----------------------------|

| | | | \ | msgPrivacyParameters |

| scope of | scopedPDU | \-------------------------------

| encryption | |

| | | |

\|/ \|/ | |

-------------------------

The SNMP packet structure for version 3 has been changed to accommodate the use of a security model like the USM.

msgVersion

The SNMP version of the packet (e.g. 1, 2 or 3).

msgID

The msgID is used to coordinate request and response messages between manager and agent. A msgID in a response must be the same as the msgID received in the request.

msgMaxSize

The msgMaxSize conveys the maximum message size the sender is able to accept from another SNMP engine.

msgFlags

The msgFlags is a single octet which is used to convey how the message is to be processed. For instance, two bits of the msgFlags are used to specify whether or not the packet has been authenticated and whether or not it has been encrypted.

msgSecurityModel

SNMPv3 was designed for the use of multiple co-existing security models. The msgSecurityModel field specifies the security model that was used to generate the message. Therefore, the receiving entity knows which security model must be used to perform security processing upon message reception.

msgSecurityParameters

The msgSecurityParameters is an octet string that contains the security model specific data. This data is defined by and used only by the security model specified by the msgSecurityModel.

scopedPDU

The scopedPDU contains the normal PDU and information for identifying the administratively unique context for processing the PDU.

USM Security Parameters

The USM uses the msgSecurityParameters to hold five values. These values are used by the authentication module to ensure data integrity and origin authentication, by the timeliness module to protect against message delay or replay, and by the privacy module to protect against message payload disclosure.

msgAuthoritativeEngineID

The snmpEngineID of the authoritative engine is always put in this field no matter which side the packet originates from.

msgAuthoritativeEngineBoots

The snmpEngineBoots of the authoritative engine.

msgAuthoritativeEngineTime

The snmpEngineTime of the authoritative engine.

msgUserName

The name of the user whose secret keys were used to possibly authenticate and encrypt the packet.

msgAuthenticationParameters

If the packet has been authenticated, then this field contains the computed HMAC-MD5 or HMAC-SHA message digest for the packet.

msgPrivacyParameters

If the scopedPDU of the packet has been encrypted, then this field contains the salt (i.e. random variant) that was used as input to the DES algorithm.

Agent Discovery

As mentioned above, the USM requires that the snmpEngineID, snmpEngineBoots, and snmpEngineTime of the authoritative engine be placed in the msgSecurityParameters. This requires the non-authoritative engine (i.e. manager) to know these values for the authoritative engine (i.e. agent) before a GET, NEXT, or SET operation can be completed.

This is achieved by a discovery process. There are two discovery transactions that occur. The first is to discover the snmpEngineID of the agent. The second is to discover the snmpEngineBoots and snmpEngineTime. The second transaction is only needed if the manager wants to use a security level of authNoPriv or authPriv. This is because the msgAuthoritativeEngineBoots and msgAuthoritativeEngineTime are used by the timeliness module which is part of the authentication process.

The first discovery transaction is initiated by the manager sending an SNMPv3 packet with the msgAuthoritativeEngineID containing a bogus value. When the agent receives a packet where the msgAuthoritativeEngineID is different than its own, the packet is discarded and a discovery packet is returned to the manager. The returned discovery packet contains the correct snmpEngineID which must be used by the manager.

The second discovery transaction requires an authenticated packet be sent to the agent. This means that the authentication flag is set in the msgFlags, and the msgAuthenticationParameters contains the computed message digest for the packet. The secret key used for authenticating the packet is from the user specified in msgUserName. What makes this a discovery packet is that the msgAuthoritativeEngineBoots and msgAuthoritativeEngineTime contain bogus values. When the agent receives this packet, it is first authenticated. Once the authentication is completed, the msgAuthoritativeEngineBoots and msgAuthoritativeEngineTime values are checked. Since the values are bogus, the packet is discarded and a second discovery packet is returned to the manager. The returned discovery packet is authenticated, using the same user, and contains the correct values of the snmpEngineBoots and snmpEngineTime which must be used by the manager.

Timeliness

Once a manager has learned the snmpEngineBoots and snmpEngineTime of an agent, the manager must maintain its own local notion of what these values are supposed to be. This requires the manager to increment the learned snmpEngineTime every second so the value will be very close to the master values maintained by the agent. If the snmpEngineTime rolls over, then the snmpEngineBoots must be incremented. A manager must keep local notions of these values for each agent in which it wishes to communicate.

The timeliness checks by an agent are considered part of the authentication process and are done right after the received packet has been authenticated. If the msgAuthoritativeEngineBoots is different than the agent's current value of the snmpEngineBoots, the packet is discarded and a discovery packet is sent back to the manager. If that check passes, then the msgAuthoritativeEngineTime is checked against the agent's current value of the snmpEngineTime. If the difference between the two is more or less than 150 seconds, the packet is discarded and a discovery packet is sent back to the manager. If both of the checks pass, then the packet is considered to have been received in a timely manner and processing continues.

The value of +/- 150 seconds for the comparison of the snmpEngineTime is the default value specified by the RFC. This value could be modified to something more suitable based on the speed and size of your network.

Authentication

The USM specifies the use of the Message Digest 5 (MD5) and Secure Hash Algorithm 1 (SHA-1) algorithms for authenticating SNMPv3 packets. These algorithms are used to create unique fixed sized message digests, also called digital signatures or fingerprints, of a variable length message. MD5 creates a digest of 128 bits (16 bytes) and SHA-1 creates a digest of 160 bits (20 bytes). Both MD5 and SHA-1 cannot be used directly as a message authentication code because they do not use secret keys as input to derivate the computed message digest. This is why the Keyed Hashing for Message Authentication (HMAC) algorithm in combination with MD5 and SHA-1 is used for computing message digests. The HMAC algorithm defines a procedure for appending a secret key to the data and then computing the MD5 or SHA-1 message digest. This guarantees that parties who wish to compute identical message digests for the same block of data must share a common secret key. Here are the steps that are taken for sending and receiving an authenticated SNMPv3 packet:

Sending an authenticated SNMPv3 packet:

The entire packet is created. The authentication flag is turned on in the msgFlags, and the msgAuthenticationParameters is zeroed out.

A message digest is computed of the packet using the secret authentication key for the user specified in msgUserName. The algorithm used (i.e. HMAC-MD5 or HMAC-SHA) is determined by the authentication protocol specified for the user in the User Table.

The computed message digest is inserted in the msgAuthenticationParameters.

The packet is sent.

Receiving an authenticated SNMPv3 packet:

The packet is received.

If the authentication flag is turned on in the msgFlags, then continue with the authentication process at step 3. If the packet was not authenticated by the sender, authentication is skipped.

The msgAuthenticationParameters is saved.

The msgAuthenticationParameters is zeroed out.

The computed message digest is compared to the previously saved msgAuthenticationParameters. If they are different then the packet is not authentic and it is dropped. If they are the same, then the packet is authentic and processing may continue.

Privacy

The USM specifies the use of the Cipher Block Chaining mode to the Data Encryption Standard (CBC-DES) algorithm for encrypting and decrypting SNMPv3 packets. The scope of the encryption only covers the scopedPDU which contains the PDU and context data used by the VACM. The DES algorithm takes three inputs. These inputs are the data to be encrypted, a 56 bit secret key, and a 56 bit randomly generated salt which is used to ensure that two different initialization vectors are used for two different data inputs encrypted with the same secret key. For two parties to use encryption during communication, each must share a secret privacy key as well as the salt used to derivate the initialization vector. The secret privacy keys are stored in the User Table, and the salt is transmitted with the packet in the msgPrivacyParameters. Here are the steps that are taken for sending and receiving an encrypted packet.

Sending an encrypted SNMPv3 packet:

The entire packet is created, and the authentication and privacy flags are turned on in the msgFlags.

A random salt value is computed.

The scopedPDU is encrypted using the salt and the secret privacy key for the user specified in msgUserName.

The salt is inserted into the msgPrivacyParameters.

Authenticate the packet as previously described.

The packet is sent.

Receiving an encrypted SNMPv3 packet:

The packet is received.

If the authentication flag is turned on in the msgFlags, then the packet must be authenticated as previously described and continue to step 3. If the authentication flag is turned off in the msgFlags then decryption is skipped.

If the privacy flag is turned on in the msgFlags, then continue with the decryption process at step 4. If the packet was not encrypted by the sender, the decryption is skipped.

Decrypt the scopedPDU using the salt specified in the msgSecurityParameters and the secret privacy key for the user specified in msgUserName.

Continue processing the packet.

User Table

Every agent maintains a User Table which is used to store all the users that have access to the system via SNMP. Each user entry in the table contains the following information, all of which can be modified via SNMP operations on the USM MIB:

User Name

A human readable string representing the name of the user.

Authentication Protocol

An indication of whether or not messages sent or received on behalf of this user can be authenticated and if so, which authentication protocol to use. The current values for this field are: usmNoAuthProtocol, usmHMACMD5AuthProtocol, and usmHMACSHAAuthProtocol.

Authentication Key

The localized secret key used by the authentication protocol for authenticating messages.

Privacy Protocol

An indication of whether or not messages sent or received on behalf of this user can be encrypted and if so, which privacy protocol to use. The current values for this field are: usmNoPrivProtocol and usmDESPrivProtocol.

Privacy Key

The localized secret key used by the privacy protocol for encrypting and decrypting messages.

The User Table has a spin lock associated with it named usmUserSpinLock. A spin lock is an advisory lock which is used to allow several SNMP managers to coordinate their attempts in modifying a MIB table. The concept is simple. Whenever a change is going to be made to the User Table on an agent, the value of the usmUserSpinLock must be retrieved via a GET command by the manager. Then the manager sends a SET command to the agent which contains a PDU to set the usmUserSpinLock and whatever variables in the User Table that need to be modified. The value of the usmUserSpinLock in the SET command must be the value that was retrieved in the previous GET command. Once the agent receives the message containing the SET command, the usmUserSpinLock is immediately processed. If the current value of the usmUserSpinLock is not the same as the value specified in the SET command, the SET operation has failed and an error is returned. If the two values are the same, then the User Table variables specified in the PDU of the SET command are set. When the agent has finished processing the entire PDU, the usmUserSpinLock value is incremented by one. As you can see, if the value of the usmUserSpinLock is different when it is being set, then the User Table has been modified since the initial retrieval of the usmUserSpinLock value.

Localized Keys

A localized key is a concept that allows the use of the same password for a user on many different agents. It would be very cumbersome to be forced to remember a different password for each agent the user exists. The localized key is computed using a one way hash function (e.g. MD5 or SHA-1) against a secret password and the snmpEngineID of the agent where the user exists. This results in secret keys that, although use the same password, are completely different for each agent.

Changing Keys

The USM introduces the KeyChange type which describes a convention for using secret keys. The KeyChange definition provides a secure means of sending localized keys across networks which allows users to change their keys. The following steps will occur when a user changes their key:

Manager:

The user enters in a new password.

The localized key is computed using the new password and the snmpEngineID of the agent where the key is going to be changed.

A one-way function is used to produce a value from the old key.

This value is exclusively or'ed (XOR) with the new key.

The final KeyChange value is sent to the agent in a SET operation.

Agent: (after receiving the KeyChange SET operation)

The same one-way function that the manager used to produce a value from the old key is performed.

This value is exclusively or'ed (XOR) with the received KeyChange to produce the new key.

The new key for the user is set in the User Table.

Creating/Cloning Users

It is possible to create a new user in an agent's User Table. This is performed by cloning an existing user. All the data for the clone-from user is copied to the newly created entry for the new user. Once the new user entry has been created, it is suggested to immediately change the keys. Note that you can only create a new user by cloning from another existing user. This requires that the User Table for a particular agent must be initialized to contain the minimum set of users needed in your environment.

Using your SNMPv3 manager of choice, here is an example of how to create a new user from an existing user named foo and changing the secret keys. Note that the actual name of the new user being created is not shown here because the name is specified in the OID index of the variables which are being set. The User Table is indexed by the user name.

First get the spin lock value and create the user. To ensure the new user entry cannot be immediately used, set the status to createAndWait.

sValue = GET (usmUserSpinLock)

SET((usmUserSpinLock = sValue),

(usmUserCloneFrom = foo),

(usmUserStatus = createAndWait))

Next, change the secret privacy key. Note you must know the secret privacy key for foo to compute the KeyChange. The privKeyChange value is computed using the privacy key of the clone-from user and the new secret key to be used for the new user. Make sure to use the spin lock. Also, the usmUserPublic variable can be written as part of the procedure for changing a user's secret key, and later read to determine whether the change of the secret was completed.

sValue = GET(usmUserSpinLock)

SET((usmUserSpinLock = sValue),

(usmUserPrivKeyChange = privKeyChange),

(usmUserPublic = randomValue))

if (randomValue != GET(usmUserPublic)) then try again

If the new user is never going to use encryption, then you can set the privProtocol to usmNoPrivProtocol and not bother with changing the privacy key.

sValue = GET(usmUserSpinLock)

SET((usmUserSpinLock = sValue),

(usmUserPrivProtocol = usmNoPrivProtocol))

Now change the secret authentication key. Note you must know the secret authentication key for foo to compute the KeyChange. The authKeyChange value is computed using the authentication key of the clone-from user and the new secret key to be used for the new user. Once again, make sure to use the spin lock.

sValue = GET(usmUserSpinLock)

SET((usmUserSpinLock = sValue),

(usmUserAuthKeyChange = authKeyChange),

(usmUserPublic = randomValue))

if (randomValue != GET(usmUserPublic)) then try again

If the new user is never going to use authentication, then you can set the authProtocol to usmNoAuthProtocol and not bother with changing the authentication key.

sValue = GET(usmUserSpinLock)

SET((usmUserSpinLock = sValue),

(usmUserAuthProtocol = usmNoAuthProtocol))

Finally, activate this new user by setting the status to active.

sValue = GET(usmUserSpinLock)

SET((usmUserSpinLock = sValue),

(usmUserStatus = active))

Conclusion

This overview of the USM should give you an understanding of what is involved in authenticating and encrypting/decrypting SNMPv3 packets. In addition, you can start to think about how you will configure the agents in your environment when you deploy SNMPv3 capable routers, switches, and servers. Next month I will take a look at the VACM and show how it is used to administer access to MIB data.

SNMPv3 - View Access Control Model

This is the second of two articles presenting the new security features defined by SNMPv3. In the previous article, we looked at the User-based Security Model (USM) and how it authenticated, encrypted, and decrypted SNMPv3 packets. Now I'll examine the View-based Access Control Model (VACM) which provides access control and is specified in RFC 2575.

The Access Control Subsystem of an SNMP entity has the responsibility for checking whether a specific type of access to a specific managed object is allowed. Access control occurs in the agent when processing SNMP retrieval or modification request messages from a manager, and also when a notification message must be sent to the manager.

As you will see the concepts introduced by the VACM are rather complex and confusing. The motivations for these concepts are based off the problems with the SNMPv1 and SNMPv2c community string. The community string is used to identify the requesting entity, the location of the requesting entity, determine access control information, and determine MIB view information. Both flexibility and functionality are lost by using this single community string variable. The VACM elaborates on the community string concept by allowing a much stricter and more dynamic access control model that is easy to administer.

SNMPv3 Packet Format

-------------------------

/|\ | msgVersion |

| |-----------------------|

| | msgID |

| |-----------------------|

| | msgMaxSize |

| |-----------------------|

| | msgFlags |

scope of |-----------------------|

authentication | msgSecurityModel |

| |-----------------------|

| | | /-------------------

| | | / |-----------------|

| |-----------------------|/ | contextName |

| /|\ | | |-----------------|

| | | | | |

| | | | | |

\|/ \|/ | | | |

-------------------------\ | |

\ | |

\-------------------

The SNMP packet structure for version 3 has been changed to accommodate the use of a security model like the USM and an access control model like the VACM.

msgVersion

The SNMP version of the packet (e.g. 1, 2 or 3).

msgID

The msgID is used to coordinate request and response messages between manager and agent. A msgID in a response must be the same as the msgID received in the request.

msgMaxSize

The msgMaxSize conveys the maximum message size the sender is able to accept from another SNMP engine.

msgFlags

msgSecurityModel

msgSecurityParameters

The msgSecurityParameters is an octet string which contains the security model specific data. This data is defined by and used only by the security model specified by the msgSecurityModel. We saw in the previous article how the USM used this field for authenticating, encrypting, and decrypting SNMPv3 messages.

scopedPDU

The scopedPDU contains the normal PDU and information for identifying the administratively unique context for processing the PDU.

VACM Parameters

The VACM uses the msgFlags, msgSecurityModel, and scopedPDU field for determining message access. The msgFlags are used to determine the security level of the message (i.e. noAuthNoPriv, authNoPriv, or authPriv), the msgSecurityModel specifies the security model used to secure the message, and the scopedPDU which contains the context and managed object OIDs. The scopedPDU contains the following fields:

contextEngineID

The contextEngineID uniquely identifies an SNMP entity that may access an instance of a managed object within a particular context.

contextName

The unique name of the context for which the PDU data administratively belongs.

PDU (data)

An SNMP Protocol Data Unit contains an operation for information that is named in the context which is identified within an administrative domain by the combination of the contextEngineID and the contextName. See RFC1905 for more information about SNMP PDUs.

All of these parameters are passed to the isAccessAllowed mechanism. This is the single entry point into the VACM for determining whether or not access is granted to the message. Every var-bind in the PDU is individually checked for access. If it is determined that one of the var-binds (i.e. managed objects) is un-accessible to the message, then an error is returned to the caller and processing stops. There are four tables that are defined by the VACM which are used for determining access. Each table is responsible for a different aspect of the access mechanism and each of these tables are remotely configurable using the VACM MIB.

Context Table

A context is defined as a collection of managed objects accessible by an SNMP entity. In other words, a name is given to a subset of managed objects. It is possible for an object to exist in more than one context and it is possible that an SNMP entity have access to more than one context. The vacmContextTable is used to store all the locally available contexts. The table is indexed by a contextName and each row in this table contains:

vacmContextName

A unique human readable string which names a context.

The contextName found within the scopedPDU is searched for in the vacmContextTable. If the message's specified contextName is not found in the table, access is denied and noSuchContext is returned. Else access checking continues if the contextName exists.

Security To Group Table

A group name is used to define an access control policy for a group of principals. Note that a principal is more specific than an SNMP entity. It is more like an individual user operating from an SNMP entity. A group is a set of zero of more securityModel and securityName tuples on whose behalf managed objects can be accessed. The combination of a securityModel and a securityName maps to at most one group. That is, a given principal whose communications are protected by a given securityModel can only be included in one group. The vacmSecurityToGroupTable is used to store group information and is indexed by a securityModel and securityName. Each row in this table contains:

vacmSecurityModel

An SNMPv3 security model (i.e. USM).

vacmSecurityName

A name representing a principal in a security model independent format. In the case of the USM, this securityName is identical to the userName.

vacmGroupName

A human readable string which identifies the group that this table entry belongs.

The securityName used to index into this table is retrieved by the msgSecurityModel when the message is processed (i.e. authenticated and decrypted). Then the securityName and msgSecurityModel tuple is searched for in the table. If an entry is not found, access is denied and noSuchGroupName is returned. Else if an entry is found then the corresponding groupName is returned and access checking continues.

Access Table

The vacmAccessTable is used to store the access rights defined for groups. In determining if access is allowed, one entry must be selected and the proper viewName from that entry must be used for further access checking. There may be multiple access rights defined for a single group and the access right chosen from that set is determined by which is the "most secure". This means the entry with the highest security model or with the longest context prefix match is chosen. See the vacmAccessTable MIB description for the details of the algorithm. This table is indexed by a groupName, contextPrefix, securityModel, and securityLevel. Each row in this table contains:

vacmGroupName

The name of the group that this access right applies.

vacmAccessContextMatch

A simple form of wildcarding. If set to exact, the index contextName must exactly match the value in vacmAccessContextPrefix. If set to prefix, the index contextName can simply match the first few starting characters of the value in vacmAccessContextPrefix.

vacmAccessContextPrefix

An index contextName must match exactly or partially the value of this object.

vacmAccessSecurityModel

The securityModel that must be used in order to gain access to this access right.

vacmAccessSecurityLevel

The minimum securityLevel that must be used in order to gain access to this access right. A security level of noAuthNoPriv is less than authNoPriv and authNoPriv is less than authPriv.

vacmAccessReadViewName

The authorized MIB viewName used for read access. If the value is the empty string then there is no active view configured for read access.

vacmAccessWriteViewName

The authorized MIB viewName used for write access. If the value is the empty string then there is no active view configured for write access.

vacmAccessNotifyViewName

The authorized MIB viewName used for notify access. If the value is the empty string then there is no active view configured for notify access.

The contextName used when indexing this table is the valid contextName that was already matched within the vacmContextTable. The groupName used is the one returned from the lookup into the vacmSecurityToGroupTable. The securityModel is specified in the message's msgSecurityModel, and the securityLevel is specified in the msgFlags. If an access right was not found, access is denied and noAccessEntry is returned.

Once an access right has been chosen, the appropriate viewName specified by the access right must be chosen. The view name to use is determined by the SNMP operation defined in the PDU. For GET and NEXT operations the vacmAccessReadViewName is used. For SET operations the vacmAccessWriteViewName is used. For TRAP operations the vacmAccessNotifyViewName is used. If the appropriate viewName is not configured within the access right, access is denied and noSuchView is returned.

Finally, if the access right has been chosen and the appropriate viewName has been configured within the access right, access checking continues.

View Tree Family Table

The vacmViewTreeFamilyTable is used to store MIB views. A MIB view is defined as a family of view subtrees which is a pairing of an OID subtree value together with a bit string mask value. The mask indicates which sub-identifiers of the associated subtree OID are significant to the MIB view's definition.

For each possible managed object instance, that instance belongs to a particular MIB view if both of the following conditions are true:

The OID of the managed object must contain at least as many sub-identifiers as the OID subtree.

Each sub-identifier in the OID of the managed object matches the corresponding sub-identifier of the OID subtree whenever the corresponding bit of the mask is non-zero.

When the configured value of the mask is shorter than required to perform the above test, its value is implicitly extended with ones. Consequently, a view subtree family having a family mask of zero length always corresponds to a mask of all ones which in turn corresponds to a single MIB subtree.

For example, suppose the following MIB views have been defined:

(A) subtree: 1.3.6.1.2.1

mask: 1 1 1 1 1 1

(B) subtree: 1.3.6.1.2.1.1.1

mask: 1 1 1

mask: none

(D) subtree: 1.3.6.1.2.1.1

mask: 1 1 0 1 0 1 1

(E) subtree: 1.3.6.1.2.1.2

mask: 1 1 0 1 0

(F) subtree: 1.3.6.1.2.1

mask: 1 1 0 1 0 1

Here are some OIDs that are checked against the above MIB views in order to determine if they are a part of the view or not. You can see that by using a subtree mask, a managed object can be included in multiple MIB views or no MIB views.

1.3.6.1.2.1 belongs to: A, F

1.2.6.1.2.1.1 belongs to: none of them

1.3.6.1.3.1 belongs to: F

1.3.4.1.4.1.2 belongs to: E, F

1.3.6.1.2.1.1.1.0 belongs to: A, B, D, F

1.3.6.1.2 belongs to: none of them

All the MIB views are stored in the vacmViewTreeFamilyTable which is indexed by a viewName and an OID of a MIB subtree. Note that the VACM MIB defines the vacmViewSpinLock advisory lock which is used to allow several SNMP managers to coordinate their attempts in modifying the table. The use of this spin lock is identical to that of the USM's usmUserSpinLock explained in the previous article. Each row in the vacmViewTreeFamilyTable contains:

vacmViewTreeFamilyViewName

A human readable name for the MIB view.

vacmViewTreeFamilySubtree

The OID subtree which when combined with the mask defines a one or more MIB view subtrees.

vacmViewTreeFamilyMask

A bit mask which, in combination with the corresponding OID subtree, defines one or more MIB view subtrees.

vacmViewTreeFamilyType

Indicates whether or not the corresponding MIB view subtrees defined by the OID subtree and mask are included or excluded from the MIB view.

The viewName used to index into this table for access checking is the authorized viewName specified by the access right chosen from the vacmAccessTable. The OID of a managed object found in the var-bind of the PDU is checked against the MIB view. If the OID is not a part of the MIB view, access is denied and notInView is returned. If the OID is a part of the MIB view then access has been granted and accessAllowed is returned.

Overall Picture

The algorithm defined by the VACM for determining access is somewhat complex and hard to understand. Here is a flow chart that shows the inputs and outputs to each of the four tables just described. The RFC gives the example that the securityModel and securityName determines Who. The contextName determines Where. The securityModel and securityLevel determines How. The viewType (i.e. read, write, or notify) determines Why. The OID of the managed object determines What and the instances of the managed object determines Which.

contextName

securityModel |

| | | securityLevel

| | securityName | |

| | | | |

| \|/ \|/ \|/ |

| --------------- ----------------- |

| --------------- ----------------- |

| | | |

| groupName contextName |

| | | |

| ------------------- | ---------

| | | |

-------------------------- | | |

| | | | variableName

\|/\|/\|/\|/ (OID)

---------------- |

| Access Table | |

---------------- |

| |

viewName |

| |

| --------------

| |

\|/ \|/

--------------

| View Table |

--------------

\|/

ACCESS IS GRANTED OR DENIED!

Conclusion

This overview of the VACM should give you an understanding of what is involved in administering access control for SNMPv3 packets. In addition, you can start to think about how you will configure the agents in your environment when you deploy SNMPv3 capable routers, switches, and servers.

Much care should be taken when configuring each of the VACM tables. A minor mis-configuration can open a huge security hole in your network by allowing unauthorized access to potential sensitive data. Try to test your table configurations first on a test network before making any modifications to a live network device.

The SNMPv3 framework is defined to ensure the modularity of the security subsystem and the access control subsystem. As of right now, the USM and VACM have been defined for security and access control. There is nothing stopping you from implementing either a new security module or access control model or both. In the future, expect to see the IETF update or replacement these modules as they become outdated and needs change. In any case given the modularity of the SNMPv3 framework, defining and plugging in a new module will be quite painless.

Python/Networking/Security/Virtualization Fundamentals

Pages

Saturday, March 24, 2012

SNMP

SNMPWALK

SYNOPSIS

DESCRIPTION

OPTIONS

EXAMPLES

VARIABLES

SYNOPSIS

DESCRIPTION

No comments:

Post a Comment