SNMP

As with Netflow, I’m assuming most readers are familiar with SNMP. This blogpost will serve as a refresher, and perhaps you will learn some details about SNMP that you haven’t seen before.

SNMP (Simple Network Management Protocol) is used for communication between a Network Management System (NMS) and a network device (such as a router or switch). SNMP uses a heirarchical MIB structure to allow an NMS to poll a network device to periodically gather information and statstics. SNMP also provides a way for an NMS to set configuration parameters on a device but this is seldom used. SNMP runs over UDP port 161 and 162.

SNMP Components

SNMP Manager

The manager is the NMS that preforms SNMP polling and receives SNMP notifications from SNMP agents. The NMS listens on UDP/162 for SNMP Traps and Informs.

SNMP Agent

An SNMP agent is the software running on a managed device which enables SNMP functionality. An SNMP agent responds to SNMP messages from an NMS, and optionally sends notifications to the NMS. The SNMP agent listens on UDP/161 for GETs and SETs.

SNMP MIB (Management Information Base)

SNMP variables are stored in MIBs, which are essentially well-known object identifiers. An NMS sends a GET request to obtain the values for certain MIBs, such as interface counters.

SNMP Messages

SNMP GET

Used by the NMS to obtain information from a SNMP agent. It includes the MIB that the NMS wants to get the current value of.

SNMP SET

Used by the NMS to change the value of an object on an SNMP agent. This is not often used.

SNMP Notifications

Used by the agent to alert the NMS that an event has occured. There are two types of notifications:

  • Traps

    • Does not require an acknowledgment from the NMS

  • Informs

    • Requires the NMS to acknowledge the receipt of the notification

Traps are normally used over informs, because an inform requires extra overhead. An inform must be held in memory on the SNMP agent until it is acknowledged, and might need to be retransmitted.

SNMP Versions

SNMPv2c

SNMPv2c uses a community-based security model which is quite weak. The community string used on the NMS must match the community string configured on the router. The community string is sent in plain-text over the wire.

Here the NMS is requesting the value of the object 1.3.6.1.2.1.1.5.0. The community string public is present in clear text.

Because the community string public matches what is configured on the router, the router responds with the value of that object:

Usually when companies use v2c, they bind an ACL to the SNMP agent so that SNMP requests are only permitted from the IP address of the NMS.

SNMPv3

SNMPv3 adds robust authentication and encryption features. You can use three levels of security with v3:

  1. noAuthNoPriv

    Neither authentication nor privacy (encryption) is used. The username must match for authentication. This is a poor authentication mechanism that is very similar to v2c community strings.

    Below the username was set to NOAUTHNOPRIV. There is no authentication nor privacy. The message is in plain text.

  2. authNoPriv

    Authentication is provided based on a MD5 or SHA signature. The message is still in plaintext. When you configure authNoPriv, you associate a password with the v3 username.

    Below we see an authentication parameter. This is used by the agent and NMS to ensure that each end has the correct password configured. The message is still in plaintext.

  3. authPriv

    Authentication uses MD5 or SHA as before. Additionally the message is encrypted using DES or AES.

    The message is now encrypted, so we cannot even tell if this is an SNMP GET request or reply.

SNMPv3 security level summary:

Security Level

Description

noAuthNoPriv

Uses only username for authentication. The username is in plain text.

authNoPriv

Uses authentication based on MD5 or SHA. The password associated with the username is hashed. The message body is in plain text.

authPriv

Uses the same authentication as above, plus encryption of the message body based on DES or AES.

EngineID

The EngineID is an important aspect of SNMPv3. The password for the user is hashed based on the EngineID. The EngineID is automatically generated.

By default there is no EngineID on the device. If you enable SNMP, an EngineID is generated. Even enabling SNMPv2 generates an EngineID, although the EngineID is only used for SNMPv3.

Router#show snmp engineID 
%SNMP agent not enabled

Router#conf t
Router(config)#snmp-server group my-group v3 priv                        
Router(config)#snmp-server user my-user my-group v3 auth sha mypassword priv aes 256 myaespassword     
*Oct 29 17:30:07.993: Configuring snmpv3 USM user, persisting snmpEngineBoots. Please Wait...

Router(config)#end
Router#
Router#show snmp engineID 
Local SNMP engineID: 8000000903005254000F5BE1
Remote Engine ID          IP-addr    Port

Router#show snmp user

User name: my-user
Engine ID: 8000000903005254000F5BE1
storage-type: nonvolatile        active
Authentication Protocol: SHA
Privacy Protocol: AES256
Group-name: my-group

The EngineID is generated based on the BIA (burned-in address) of the first physical interface:

Router#show snmp engineID 
Local SNMP engineID: 8000000903005254000F5BE1
Remote Engine ID          IP-addr    Port
Router#show int gi1 | in bia
  Hardware is CSR vNIC, address is 5254.000f.5be1 (bia 5254.000f.5be1)

  • If you are curious, the “800000090300” means that the organization is Cisco and the EngineID is based on the MAC address. 00:00:00:09 is Cisco, but the first bit must be 8, yeilding 80:00:00:09. 03 indicates MAC address scheme.

If you change the EngineID, the previously configured users will still have the old EngineID. You will have to delete and re-add the users. New users will have the new EngineID.

! Below the EngineID is manually changed
Router(config)#snmp-server engineID local 800000090300111122223333
Router(config)#do sho snmp engine
Local SNMP engineID: 800000090300111122223333
Remote Engine ID          IP-addr    Port
Router(config)#do sho snmp user

User name: my-user
Engine ID: 8000000903005254000F5BE1 ! The user still has the old EngineID
storage-type: nonvolatile        active
Authentication Protocol: SHA
Privacy Protocol: AES256
Group-name: my-group

Router(config)#snmp-server user my-user2 my-group v3 auth sha mypassword priv aes 256 myaespassword    
Router(config)#do sho snmp user

User name: my-user2
Engine ID: 800000090300111122223333 ! New users have the new EngineID
storage-type: nonvolatile        active
Authentication Protocol: SHA
Privacy Protocol: AES256
Group-name: my-group

User name: my-user
Engine ID: 8000000903005254000F5BE1
storage-type: nonvolatile        active
Authentication Protocol: SHA
Privacy Protocol: AES256
Group-name: my-group

The EngineID of the network device is automatically gathered by the NMS. In both my lab and the pcaps provided by Nick Russo, the NMS first sends a blank GET request with no MIB or authentication/privacy.

The Cisco device then responds with a Report for MIB 1.3.6.1.6.3.15.1.1.4.0 which is a counter for UnknownEngineIDs. This Report also contains the device’s EngineID (msgAuthoritativeEngineID) and no auth/priv parameters. Each time the device sends this MIB, the value increments by one.

The subsequent packets are now encrypted because the NMS has learned the EngineID of the device and can use this to calculate the hashes.

When configuring v3 traps, you can use a local user defined on the network device but you need to configure the device’s EngineID on the SNMP collector.

When configuring v3 informs, it appears you must configure the remote EngineID of the collector.

snmp-server engineID remote 1.1.1.1 <remote's engine ID>
snmp-server host 1.1.1.1 informs version 3 priv <user>

How interfaces are handled in SNMP

In SNMP, an interface has three values:

  1. ifIndex

    This is a unique index number that identifies each interface on a device. In order for this to persist across reboots you use the command snmp ifmib ifindex persist. Without this command, the index values for each interface could change, potentially causing issues with displaying historical statistics in the NMS.

  2. ifAlias

    This is the description of the interface. By default it is limited to 64 characters. You must use the command snmp ifmib ifalias long to increase the limit to 255 characters.

  3. ifName

    This is the name of the interface in the configuration, such as “GigabitEthernet1”

IOS-XE Configuration

General SNMP system information

Configure the location, chassis-id and contact.

snmp-server location <location>
snmp-server chassis-id <chassis-id>
snmp-server contact <contact>

I kind of think of these parameters as meta data. They can be displayed in your NMS and aid with troubleshooting when the device goes down. These are all just strings.

SNMPv2

The configuration for v2 is quite basic. Simply configure the community string. Optionally you can specify read-only, read-write, a view, and associate an ACL. The ACL controls which IPs can poll the device. This is frequently used as a form of security because simply using a community string is so weak.

snmp-server community <community-string> [ro|rw] [ACL name] [view view-name]

SNMPv3

To use SNMPv3, at a minimum you need two commands. You need to configure a group, and you need to configure a user (which references a group).

  1. Configure a group as follows. Optionally you can associate a view and access-list.

snmp-server group group-name v3 auth|noauth|priv [read view-name] [write view-name] [access ACL-name]

The security level (auth|noauth|priv) defines the minimum level a user belonging to this group must have. For example, you can configure noauth on the group and priv on the user. But you cannot configure auth on the group and noauth on the user.

2. Configure a user. The user is where you specify the auth and priv passwords.

snmp-server user name group-name v3 [auth sda|md5 password] [priv 3des|aes|des password] [access ACL-name]

The user does not appear in the running or startup config. You can only view configured users using show snmp user but this does not display the auth/priv password. The snmp users are stored in nvram:private-config which you cannot access.

Router#more nvram:private-config
%Error opening nvram:private-config (Permission denied)

SNMPv3 Summary

  • The group configures the minimum security level for all users in the group. The group determines the read and write views, if configured.

  • Each user must be associated to a group. The user is where the auth and priv encryption settings are defined. The user can use a security level above the group but not below the group.

Configuring SNMP Views

A view can be associated with both a v2c community string and a v3 group. A view defines what level of the MIB the NMS has access to. You can configure this using a full OID path or the name of the MIB.

For example, ISO is the top level of the MIB tree. You could specify iso to allow access to the entire MIB. You can also specify 1.3.6.1.2.1 or mib-2 to allow access to the tree starting at mib-2.

Configure a view as follows:

snmp-server view name included|excluded

  • If the MIB view does not exist, you will get an error message stating %Bad OID

Associate the view with the v2c community string or a group.

snmp-server community string view name
snmp-server group name v3 auth|noauth|priv read|write view-name

Configuring Notifications

Enable traps

snmp-server enable traps [notification type]

Send traps/informs using v2c:

snmp-server host nms-address traps|informs version 2c community-string

Send traps/informs using v3:

snmp-server host nms-address traps|informs version 3 auth|noauth|priv user-name

IOS-XR Configuration

SNMP configuration on IOS-XR is practically identical.

SNMPv2c

snmp-server community string [RW|RO] [IPv4|IPv6 ACL name] [view ??]

SNMPv3

snmp-server group name v3 auth|noauth|priv [read view] [write view] [IPv4|IPv6 acl-name]
snmp-server user name group-name v3 [auth md5|sha password] [priv 3des|aes|des password] [IPv4|IPv6 acl-name]

View

snmp-server view name MIB included|excluded

Notifications

snmp-server traps [notification type]
snmp-server host nms-address traps|informs version 2c [community string] 
snmp-server host nms-address traps|informs version 3 auth|noauth|priv user

Lab

In order to poll virtual routers such as a CSR1000v or XRv, you will need a virtual linux server. In this lab I’ve provided instructions on running a LibreNMS container using Docker. In CML, I use the Ubuntu node type, with one connection to my external network (for internet access) and one to my router. Within just a few minutes you can start polling your devices and experiment with v2c and v3. I have omitted information about setting up the IP address on your server.

Installing LibreNMS as a container

  1. Install Docker

sudo curl -fsSL https://get.docker.com -o get-docker.sh
sudo sh ./get-docker.sh
sudo apt-get install docker-compose

2. Clone librenms docker repo and launch the containers

git clone https://github.com/librenms/docker.git
cd docker/examples/compose/
sudo docker-compose up -d

3. Navigate to http://host-ip:8000. You should be prompted to enter in an admin user/pass/email. The email does not need to be a real email address. Once I submitted this, it hung on that page. After a few minutes I gave up and rebooted my Ubuntu server. The docker containers came back automatically upon reboot, and I was presented with a login page at http://host-ip:8000. I was then able to login with the account I had previously entered.

On your CSR1000v you can now enable SNMP and add it to LibreNMS. The minimum command you need to enable SNMP v2c is the following:

snmp-server community TEST_STRING

In LibreNMS, go to Devices - Add Device

Enter the IP of your router, port 161, and the SNMP community string

It should add successfully and you should be able to navigate to the page for your router:

Using the gear wheel on the right, delete the device.

Configure SNMPv3 on the router. You will need to define two items at minimum:

  • The group

    • This defines a group and what view it has access to. The security level is defined here (auth, noauth, or priv).

  • The user

    • The user must be associated with a group.

snmp-server group my-group v3 auth|noauth|priv [read|write my-view]
snmp-server user my-user my-group v3 auth sha|md5 my-sha-password priv 3des|aes|des [128/192/256 for aes] my-priv-password

Add the router again using SNMPv3. I used AES 256 in my lab, and had to use the AES-256-C option in LibreNMS to add the router.

Experiment with adding a XRv as well.

Further Reading/Watching

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/snmp/configuration/xe-16-6/snmp-xe-16-6-book/nm-snmp-cfg-snmp-support.html#GUID-59CB0C09-2EE9-40F5-B6DE-B8DDAB55514B

https://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k-r6-6/system-management/configuration/guide/b-system-management-cg-asr9000-66x/b-system-management-cg-asr9000-66x_chapter_0101.html

http://docs.logmatrix.com/nervecenter/guides/NC-SNMPv3-EngineIDs.pdf

http://socpuppet.blogspot.com/2013/06/snmpv3-traps-config-cisco.html

https://www.youtube.com/watch?v=_I7Jm_x35bQ&ab_channel=KeithBarker-TheOGofIT

https://www.youtube.com/watch?v=Lq7j-QipNrI

https://www.youtube.com/watch?v=K1Y9ZjwzvEc

PreviousNetflowNextVirtualization

Last updated