Fellow Cisco people, I am back!  After a long hiatus, I have decided to stop paying my hosting provider tons of money just to keep a blog with a few posts.

I never really stopped to think that SNMP was a topic that people would have an issue with.  SNMP version 1 and 2c are easy to configure, you don’t need to go super crazy with the configuration.  To really get it up and running what is really needed?  A read only community string, maybe a read/write string?  A SNMP location and contact or specific traps you are looking for?  Then version 3 comes around and while it adds some complexity for a new comer, it is not really any different than if you configure a username on a cisco router and tie a privilege level to that user.  So after someone who I know studying for their CCNA asked me a question about SNMP v3, I decided to take a deep-dive into all three versions of SNMP, complete with configuration examples!

***Disclaimer: Your SNMP implementation may vary from what I am showing/demonstrating here.  This is not intended to be a complete SNMP configuration post because I would be here for hours explaining each detail, and frankly I don’t want to bore anyone***

Alright, now that my disclaimer is out of the way, lets get some explaining done!

So SNMP or Simple Network Monitoring Protocol is a way to probe and monitor your network. There are key names for devices in SNMP

  1. SNMP Manager: This is the collection point that an SNMP device / agent points to to send SNMP informs or traps to
  2. SNMP Agent: This is the device you configure SNMP on
  3. MIB: Management Information Base, this is how SNMP OID’s are managed in a tree like structure

SNMP Traps:
This in my opinion is probably the most used of the SNMP messages. The SNMP agent will send a trap to the manager when there is a condition on the network.  These are unsolicited messages sent by the agent.  Traps are unreliable messages sent on UDP/162

SNMP Informs:
An SNMP inform is a message (same conditions met with SNMP Traps) that is sent by the SNMP agent and is acknowledged by the SNMP manager.  If the SNMP manager does not send an ACK to the SNMP agent, the agent will keep forwarding the unacknowledged messages until it receives an ACK.  SNMP informs are sent on UDP/162

Wait, I thought SNMP ran on UDP/161, what is it with this new port?  UDP/161 is what the SNMP manager will send to the SNMP agent when asking for a specific variable.  For instance, when you do an SNMPWALK or when the SNMP manager polls the SNMP agent at a set interval this is done over UDP/161, where as if the SNMP agent is sending a trap or inform to the SNMP manager, this is done over UDP/162

SNMP v1 and SNMPv2c
Both of these support only community strings when polling/pulling information from a SNMP agent.  The main difference between the two of them is that SNMP v2c supports bulk retrieval and more detailed error reporting than SNMPv1.  The configuration of them are identical to each other and I will show SNMPv2c, which is the default SNMP version on most modern Cisco IOS images.  So for our configuration example, we are going to create a read-only string of Read-Only, we are going to set a location of Atlanta, GA and a SNMP contact of RoutedInterface NOC, x4567

Lab_CSR(config)#snmp-server community Read-Only ro
Lab_CSR(config)#snmp-server location Atlanta, GA
Lab_CSR(config)#snmp-server contact RoutedInterface NOC x4567

A few quick show command to validate all is good

Lab_CSR#show snmp contact
RoutedInterface NOC x4567
Lab_CSR#show snmp location
Atlanta, GA
Lab_CSR#show snmp community | beg Read-Only
Community name: Read-Only
Community Index: Read-Only
Community SecurityName: Read-Only
storage-type: nonvolatile        active

Now, we are going to test our setup with SNMPWALK.  We are going to poll the device to look for the sysName.0 MIB string

Mike@Mikes-MBP:~$ snmpwalk -v2c -c Read-Only -m SNMPv2-MIB sysName.0
SNMPv2-MIB::sysName.0 = STRING: Lab_CSR.routedinterface.local

Perfect, exactly what we were looking for.

This is where configuration gets more involved.  SNMP v3 supports authentication and encryption, aka privacy, so you can authenticate your SNMP users as well as encrypt the payload that is going between the SNMP agent and the SNMP manager.  There are different ways we can configure SNMPv3

  • NoAuth: No Authentication or Privacy
  • Auth: Authentication, no privacy
  • Priv: Authentication and privacy

Depending on platform, authentication can be in the form of MD5 or SHA, while privacy can be DES, 3DES or AES, if using AES, you can use either 128, 192 or 256 bit algorithms.

This is going to be a basic group to user configuration.  You can also tie different views to the groups so that one group can only see a specific group of MIBs and not all the MIBs the device supports.

I am going to create the following groups

  • NA – will tie NoAuth security level to this group
  • A – will tie Auth security level to this group
  • P – will tie Priv security level to this group

The following users will be tied to the following groups

  • User Nancy to group NA
  • User Al to group A
  • User Peter to group P


! Define groups

Lab_CSR(config)#snmp-server group NA v3 noauth
Lab_CSR(config)#snmp-server group A v3 auth
Lab_CSR(config)#snmp-server group P v3 priv

! Create users and tie them to groups

Lab_CSR(config)#snmp-server user Nancy NA v3
Lab_CSR(config)#snmp-server user Al A v3 auth sha Auth-Password
Lab_CSR(config)#snmp-server user Peter P v3 auth sha P@55w0rd! priv aes 128 Pr1v@cy!

Perfect!  Let’s look at the running configuration for SNMP

Lab_CSR#show run partition snmp
Building configuration...
Current configuration: 176 bytes
Configuration of Partition - snmp
snmp-server user Nancy NA v3
snmp-server group A v3 auth
snmp-server group P v3 priv
snmp-server group NA v3 noauth

Wait, why is only the Nancy user showing up and not any other users?  When you configure a user for SNMPv3, it will store the user in nonvolatile ram.  To see the SNMP v3 users and the groups they are tied to, you can use the following command

Lab_CSR#show snmp user
User name: Al
Engine ID: 800000090300000C29BB1612
storage-type: nonvolatile        active
Authentication Protocol: SHA
Privacy Protocol: None
Group-name: A

User name: Nancy
Engine ID: 800000090300000C29BB1612
storage-type: nonvolatile        active
Authentication Protocol: None
Privacy Protocol: None
Group-name: NA

User name: Peter
Engine ID: 800000090300000C29BB1612
storage-type: nonvolatile        active
Authentication Protocol: SHA
Privacy Protocol: AES128
Group-name: P

You can just look for a particular user by using the show snmp user [username] command also.

If we look at the groups we created, I am going to pick out one, as they are all pretty much the same

Lab_CSR#show snmp group
groupname: A                                security model:v3 auth
contextname: <no context specified>         storage-type: nonvolatile
readview : v1default                        writeview: <no writeview specified>
notifyview: <no notifyview specified>
row status: active

We notice that it has a read view attached by default, but no write view.  If you wanted to make this user have the ability to have read/write capabilities, then you would need to create a view that has write privileges over the MIBs you want the group to have access to

Now that we have everything defined, lets do some SNMPWALKing!

! Nancy User

Mike@Mikes-MBP:~$ snmpwalk -v3 -u Nancy -l noauthnopriv sysName.0
SNMPv2-MIB::sysName.0 = STRING: Lab_CSR.routedinterface.local


Looking at the packet capture snippet above, it shows that Nancy used the username Nancy, but no authentication password.  The SNMP GET-Request was also sent in cleartext

! Al User

Mike@Mikes-MBP:~$ snmpwalk -v3 -u Al -l authnopriv -a sha -A Auth-Password sysName.0
SNMPv2-MIB::sysName.0 = STRING: Lab_CSR.routedinterface.local


Looking at the packet capture for Al, you see that there is an authentication password, which is encrypted but the SNMP GET-Request was still sent in clear text

! Peter User

Mike@Mikes-MBP:~$ snmpwalk -v3 -u Peter -l authpriv -a sha -A P@55w0rd! -x aes -X Pr1v@cy! sysName.0
SNMPv2-MIB::sysName.0 = STRING: Lab_CSR.routedinterface.local


OK, now were talking, you see Peter was authenticated and the SNMP GET-Request was also encrypted

The Wonderful World of SNMP
Tagged on:                                     

Leave a Reply

Your email address will not be published. Required fields are marked *

%d bloggers like this: