Skip to content
Log in Sign up My account

4.2 Troubleshooting SNMP

Blueprint 4.2: Troubleshoot SNMP

  • SNMPv2c: community strings, access lists, traps and informs
  • SNMPv3: views, groups, users, security levels (noAuthNoPriv, authNoPriv, authPriv), engine ID

Expect exhibits of show snmp group, show snmp user and show snmp host alongside an NMS complaint ("polling fails", "no traps arrive"). The fault is almost always a mismatch between what the NMS sends and what the agent expects.

How SNMP talks

Item Value
Polling (Get, GetNext, GetBulk, Set) NMS to agent, UDP 161
Traps and informs Agent to NMS, UDP 162
Trap Unacknowledged notification. Lost if the path drops it.
Inform Acknowledged notification, retried until the NMS replies. Uses more memory on the agent.
GetBulk v2c and v3 only, efficient walks of tables 
sequenceDiagram
  participant N as NMS 192.168.100.50
  participant A as Agent R1
  N->>A: GetRequest, UDP 161, community or v3 user
  A->>N: Response with value, or no reply if rejected
  Note over A: Interface Gi1 goes down
  A->>N: Trap, UDP 162, from trap-source
  A->>N: Inform, UDP 162
  N->>A: Inform acknowledged

An agent that rejects a request usually sends nothing back. The NMS sees a timeout, not an error. That is why you troubleshoot from the router side with counters and debugs.

Version comparison

SNMPv2c SNMPv3
Identity Community string Username
Authentication Community string in clear text HMAC (SHA or MD5) per user
Encryption None DES, 3DES or AES (128, 192, 256) per user
Access control RO/RW plus optional ACL and view per community Group defines security level, read, write and notify views, optional ACL
Where secrets live Running config, readable User secrets are not shown in the running config; stored as localized keys tied to the engine ID

SNMPv2c

ip access-list standard NMS-HOSTS
 permit 192.168.100.50
!
snmp-server community R3adOnly RO NMS-HOSTS
snmp-server community Wr1teAcc RW NMS-HOSTS
snmp-server location Lab rack 4
snmp-server contact [email protected]
snmp-server ifindex persist
snmp-server trap-source Loopback0
snmp-server enable traps snmp linkdown linkup
snmp-server enable traps config
snmp-server host 192.168.100.50 version 2c R3adOnly

Three things must line up for traps: snmp-server enable traps (which notifications to generate), snmp-server host (where to send them, which version, which community or user), and a routed path from the trap-source to the NMS. Missing enable traps is the classic exam fault: polling works and no traps arrive.

snmp-server host 192.168.100.50 informs version 2c R3adOnly sends informs instead of traps.

Exam trap

The ACL on a community is checked against the NMS source address. An exhibit that permits the router's own address, or the NMS subnet with a wrong wildcard, makes polling time out even with the right community. Look at show ip access-lists match counters: a deny count that rises every poll cycle is the giveaway.

SNMPv3: views, groups, users

SNMPv3 builds access in three layers.

graph LR
  V["snmp-server view<br/>which OIDs"] --> G["snmp-server group<br/>security level, views, ACL"]
  G --> U["snmp-server user<br/>auth and priv secrets"]
  U --> H["snmp-server host<br/>where to send notifications"]
snmp-server view NOC-VIEW iso included
snmp-server view NOC-VIEW 1.3.6.1.6.3 excluded        ! hide the SNMP framework MIBs
snmp-server group NOC v3 priv read NOC-VIEW access NMS-HOSTS
snmp-server user nocuser NOC v3 auth sha AuthPass123 priv aes 128 PrivPass123
snmp-server host 192.168.100.50 version 3 priv nocuser
snmp-server enable traps

Security levels

Level Keyword in snmp-server group User needs NMS must use
noAuthNoPriv noauth Username only Username, no auth, no priv
authNoPriv auth auth sha PASS (or md5) Same auth algorithm and password
authPriv priv auth ... priv aes 128 PASS (or des, 3des) Same auth and priv algorithms and passwords

The security level in the group is a minimum. A request at a lower level than the group requires is rejected. A user created without priv cannot satisfy a priv group.

What the show commands tell you

R1# show snmp group
groupname: NOC                              security model:v3 priv
contextname: <no context specified>         storage-type: nonvolatile
readview : NOC-VIEW                         writeview: <no writeview specified>
notifyview: <no notifyview specified>
row status: active      access-list: NMS-HOSTS

R1# show snmp user
User name: nocuser
Engine ID: 800000090300525400A1B2C3
storage-type: nonvolatile        active
Authentication Protocol: SHA
Privacy Protocol: AES128
Group-name: NOC

Read these two outputs side by side. The group gives the security model and level (v3 priv), the views and the ACL. The user gives the auth and priv protocols. If the group says v3 priv and the user shows Privacy Protocol: None, the user can never get a response.

When a group is created without a read view, IOS uses a default view (shown as v1default), and there is no write view unless you configure one. An NMS that can read but not write is often a group with no write keyword.

Exam trap

The NMS uses authNoPriv but the group is v3 priv. Every request fails, even though the username and auth password are correct. Either change the NMS to authPriv with the right privacy password, or (if policy allows) create the group at the auth level. The fix is never "add the user to the running config", because SNMPv3 users never appear there.

The engine ID trap

The localized keys for each SNMPv3 user are derived from the passwords and the local engine ID. If someone changes snmp-server engineID local, every existing user stops working, because their stored keys no longer match. The fix is to re-create the users after the engine ID change. show snmp engineID shows the local engine ID.

Informs sent with SNMPv3 also need the remote engine ID of the NMS (snmp-server engineID remote 192.168.100.50 <id>) and the user defined against that remote engine. Plain v3 traps do not.

Finding the fault from the router

R1# show snmp
Chassis: 9ESBNC2LXYZ
Contact: [email protected]
Location: Lab rack 4
412 SNMP packets input
    0 Bad SNMP version errors
    37 Unknown community name
    0 Illegal operation for community name supplied
    0 Encoding errors
    375 Number of requested variables
    0 Number of altered variables
    375 Get-request PDUs
    0 Get-next PDUs
    0 Set-request PDUs
    0 Input queue packet drops (Maximum queue size 1000)
375 SNMP packets output
    0 Too big errors (Maximum packet size 1500)
    0 No such name errors
    0 Bad values errors
    0 General errors
    375 Response PDUs
    12 Trap PDUs
SNMP logging: enabled
    Logging to 192.168.100.50.162, 0/10, 12 sent, 0 dropped.
Counter rising Meaning
Unknown community name NMS is using a community string the router does not have
Illegal operation for community name supplied A Set with an RO community, or a request the view does not allow
Bad SNMP version errors NMS sends a version the router is not configured for
SNMP packets input not rising at all Requests are not reaching the router: routing, interface ACL, CoPP, or wrong target address
Trap PDUs rising but NMS sees nothing Path from trap-source to NMS, UDP 162 filtered, or NMS not listening

For SNMPv3, debug snmp packets shows each request, and show snmp user plus show snmp group show what the agent expects. When a community or group has an ACL, check its match counters with show ip access-lists as well.

Other commands: show snmp community (lists communities and their ACLs, including internal ones), show snmp host (notification targets, version and security level), show snmp view.

Exam trap

snmp-server host with version 2c but the NMS expects v3 (or the reverse) means traps arrive and are discarded by the NMS. The router side looks perfect: Trap PDUs rises and show snmp host lists the target. Check the version and security level in show snmp host against the NMS configuration.

Common SNMP failures at a glance

Symptom Check Typical fix
Polling times out, v2c show snmp counters, community ACL matches Correct community or ACL
Polling times out, v3 Group level vs NMS level, auth and priv algorithms, passwords Recreate user with correct secrets, align levels
Reads work, Sets fail Community is RO, or v3 group has no write view RW community or write view
Some OIDs return noSuchObject View excludes them Adjust snmp-server view
No traps enable traps, snmp-server host, trap-source reachability Add the missing piece
Interface graphs jump after reload ifIndex renumbered snmp-server ifindex persist
All v3 users broken after a change Engine ID changed Re-create users

Lab: SNMPv3 to a Linux poller

Topology: module lab, R1 as agent, the NMS (Ubuntu with the snmp package) as manager.

  1. Configure R1 with the SNMPv3 block above (group NOC v3 priv, user nocuser, ACL permitting 192.168.100.50) and snmp-server trap-source Loopback0.

  2. From the NMS poll the system name:

    snmpget -v3 -l authPriv -u nocuser -a SHA -A AuthPass123 -x AES -X PrivPass123 10.255.255.1 1.3.6.1.2.1.1.5.0

    The reply is SNMPv2-MIB::sysName.0 = STRING: followed by R1's name. A timeout means the request was rejected or never arrived.

  3. Start sudo tcpdump -n udp port 162 on the NMS, shut and re-enable R1 Loopback1 (create one first). You should see traps from 10.255.255.1.

  4. Save the baseline.
  5. Fault A. On the NMS change -l authPriv to -l authNoPriv and drop the -x/-X options. The request times out. On R1, debug snmp packets shows the request arriving. Explain from show snmp group why it is rejected.
  6. Fault B. On R1 run snmp-server engineID local 0000000901020304. Retry the authPriv poll: it now fails. Re-create the user with the same passwords and confirm polling recovers.
  7. Fault C. Remove snmp-server enable traps. Flap the loopback: no traps. Check show snmp and note that Trap PDUs stops rising.
  8. Fault D. Change the ACL to permit 192.168.100.5. Polls time out. Find it with show ip access-lists NMS-HOSTS.

Quick check

An NMS polls successfully with v2c but never receives traps. show snmp host lists 192.168.100.50. Trap PDUs in show snmp stays at 0. What is missing?

snmp-server enable traps (for the notification types needed). The host entry says where to send traps, but nothing tells IOS to generate them, so the counter never rises.

Why does show running-config not show the SNMPv3 user you just created?

IOS stores SNMPv3 users as localized keys, not in the running configuration. Use show snmp user to see them. This is by design (RFC 3414 behaviour), not a fault.

A group is configured snmp-server group OPS v3 auth read ALL. A user in it is created with auth sha and priv aes 128. The NMS polls with authPriv. Does it work?

Yes. The group level is a minimum. authPriv exceeds the auth requirement, and the user has the priv key needed to decrypt. An authNoPriv request from the same user would also work. A noAuthNoPriv request would not.

References