How to Configure SNMP on a Cisco Router (v2c and v3)

Step 1 — Decide v2c vs v3 (and why it matters)

SNMP lets a network management station (NMS) read operational data from a device — interface stats, CPU, memory, uptime — and receive event notifications when something changes. There is no single "turn SNMP on" command; the agent starts running the moment you configure a community string (v2c) or a user/group (v3).

Two versions are in play. SNMPv2c authenticates with a community string, which is a shared secret sent in cleartext in every packet — anyone who can capture the traffic can read it. SNMPv3 replaces that with per-user authentication (a hashed credential) and, at its top level, payload encryption. That difference is the whole security story: choose v3 authPriv whenever management traffic crosses any path you do not fully control, and reserve v2c for a trusted, isolated management segment where you have accepted that risk.

Two UDP ports matter throughout: the NMS polls the device on UDP 161 (it pulls data on demand), and the device pushes event notifications to the NMS on UDP 162. Keep those two directions straight — they are configured separately, and mixing them up is behind a lot of "SNMP isn't working" tickets.

Step 2 — Configure SNMPv2c community strings (RO vs RW)

A community string is a plaintext password. Read-only (RO) permits GET operations — the NMS can read OIDs but not change anything. Read-write (RW) additionally permits SET operations, which is far more dangerous than it sounds: an attacker holding an RW string can reconfigure the device over SNMP, or make the router copy its own running-config off to a server they control. Almost all monitoring needs only RO, so treat RW as something you deliberately justify, not a default.

RO versus RW is your primary security control in v2c, but it is not the only one. Bind each community to a standard ACL so that only your NMS is even allowed to use the string, and never ship the well-known defaults public or private. Remember that the community appears in cleartext in show running-config; service password-encryption only wraps it in weak type-7 obfuscation, which is trivially reversible and should not be mistaken for protection.

R1(config)# access-list 20 permit host 10.0.0.5
R1(config)# snmp-server community Gf-Ro-9x2 RO 20
!
! RW is shown only to explain the risk — avoid it in production.
! Anyone with this string can write config to the router.
R1(config)# snmp-server community Gf-Rw-secret RW 20

Step 3 — Set the device identity (location and contact)

These two commands populate the sysLocation and sysContact OIDs so your NMS displays where the device physically sits and who owns it. This is not a security control, but it is what turns a red alarm at 2 a.m. into an actionable ticket instead of a scavenger hunt. Set them on every managed device.

R1(config)# snmp-server location Bldg-3 IDF-2 Rack-4
R1(config)# snmp-server contact netops@goldfishnetworks.com

Step 4 — Send v2c traps to your NMS

Polling and traps are two different mechanisms. Polling is the NMS pulling data from the device on UDP 161 whenever it wants — that is what your community string enables. A trap is the opposite direction: the device itself initiates a message to the NMS on UDP 162 the instant an event occurs, so you learn about a downed interface without waiting for the next poll cycle. Configuring a community does not enable traps; you must add a receiver and enable the notification types explicitly.

The trap community string in the snmp-server host line is separate from your polling community, and it too travels in cleartext. Enabling traps with no keyword turns on essentially every supported notification, which is noisy — scope it to the events you actually watch. If you need delivery guarantees, use informs instead of traps: an inform is acknowledged and retransmitted until the NMS confirms receipt, whereas a trap is fire-and-forget with no retry.

R1(config)# snmp-server host 10.0.0.5 version 2c Gf-Trap-str
R1(config)# snmp-server enable traps snmp linkdown linkup coldstart warmstart
R1(config)# snmp-server enable traps config
!
! Optional: send acknowledged informs instead of fire-and-forget traps
R1(config)# snmp-server host 10.0.0.5 informs version 2c Gf-Trap-str

Step 5 — Configure SNMPv3 (group, user, and the three security levels)

SNMPv3 drops the shared community string in favor of named users with per-user credentials, and it defines three security levels you need to understand before you type anything. noAuthNoPriv is username only — no authentication, no encryption — and should be avoided. authNoPriv authenticates every message (an HMAC using SHA or MD5) so it cannot be forged or replayed, but the data itself still travels in cleartext. authPriv, the level you want, both authenticates the message AND encrypts the payload (AES or DES), so a capture reveals neither the credentials nor the data.

Build it in order: first create a group at the security level you intend to enforce (priv), then create a user inside that group carrying auth and priv credentials. The user's credentials must satisfy the group's level — a priv group expects a user that has both an auth method and a priv method. Prefer SHA over MD5 and AES over DES. The exact strongest algorithms available (for example SHA-256 or AES-256) vary by platform and IOS version, so confirm what your hardware supports against Cisco's current SNMP configuration guide for your platform rather than assuming.

Optionally bind a view to the group to restrict which part of the MIB tree the user can read. A read-only view is a good belt-and-suspenders control even though v3 users cannot write unless you grant a write view. Note that v3 credentials are localized to the device's SNMP engine ID — if you change or regenerate the engine ID, existing users break and must be recreated.

R1(config)# snmp-server group GF-ADMINS v3 priv
R1(config)# snmp-server user gfmon GF-ADMINS v3 auth sha Auth-Pass-123 priv aes 128 Priv-Pass-456
!
! Optional: restrict the group to a read-only view of the MIB tree
R1(config)# snmp-server view GF-VIEW iso included
R1(config)# snmp-server group GF-ADMINS v3 priv read GF-VIEW

Step 6 — Send v3 (authPriv) notifications

For v3 notifications you reference the user and the security level instead of a community string, so the traps carry the same authentication and encryption as your polling. Match the security keyword (priv) to how the user was built; if the group is priv, the trap host must specify priv as well.

R1(config)# snmp-server host 10.0.0.5 version 3 priv gfmon
R1(config)# snmp-server enable traps snmp linkdown linkup

Step 7 — Verify the configuration

show snmp confirms the agent is running and reports the contact, location, and packet counters (useful for seeing whether polls and traps are actually being sent and received). show snmp community lists your v2c strings with their RO/RW access and any bound ACL. show snmp group shows each group's security level and view bindings.

show snmp user is the one people forget: it lists v3 users with their auth and priv protocols and their group. It matters because IOS does not display snmp-server user lines in show running-config — those lines carry the localized secret keys, so they are hidden. If show run looks empty of your v3 user, that does not mean the command failed; verify with show snmp user. Finally, show snmp host lists your configured trap and inform receivers so you can confirm notifications will actually be delivered.

R1# show snmp
R1# show snmp community
R1# show snmp group
R1# show snmp user
R1# show snmp host

Common problems (and the fix)

1) RW left enabled, or set to a guessable string. An RW community is an administrative credential in cleartext. Anyone who can reach UDP 161 and guess it can SET OIDs to reconfigure the device or make it export its running-config. Fix: do not configure RW unless you genuinely need SNMP writes; use RO for monitoring, never use public or private, bind every community to an ACL scoped to the NMS, and move to v3.

2) Expecting v2c to be encrypted. In v2c the community string IS the authentication, and it is sent in the clear in every packet — a capture anywhere on the path reveals it, and it also sits in cleartext in show run. Fix: run v2c only on an isolated, trusted management segment behind an ACL, or better, use v3 authPriv so credentials are hashed and the payload is encrypted.

3) Community configured but no traps ever arrive. A community enables polling only — the NMS pulls data on demand. Traps are device-initiated and require both an snmp-server host receiver and snmp-server enable traps for the events you want. Configure one without the other and you will see poll data but never an event notification. Fix: add the host and enable the specific traps, then confirm with show snmp host.

4) A v3 user appears "missing" from the running-config. IOS deliberately omits snmp-server user lines from show running-config because they contain the localized secret keys, and engineers assume the command did not take. Fix: verify with show snmp user, not show run. Also remember that regenerating or changing the SNMP engine ID invalidates existing v3 users' localized keys, so they must be recreated.

5) v3 security-level mismatch. A user's credentials must satisfy the group's level. If the group is priv but you poll as authNoPriv, or you created the user with auth only and no priv aes 128 <pass>, the device denies access — often with no obvious log entry. Fix: define the group at the intended level, give the user matching auth AND priv parameters, poll at that same level, and cross-check with show snmp group and show snmp user.