Cisco SNMP Configuration: Complete Run Book for SNMPv2c, SNMPv3, Traps, and Polling on IOS/IOS-XE

What Is SNMP and Why Does It Matter

Simple Network Management Protocol (SNMP) is a foundational protocol for network monitoring, telemetry collection, and device management. When your NMS (Network Management System) polls a Cisco router or switch for interface counters, CPU utilization, or memory statistics, SNMP is doing the heavy lifting. When a device sends an alert about a link failure or an environmental condition, SNMP traps deliver that event to your monitoring platform in real time.

Cisco IOS and IOS-XE support SNMP versions 1, 2c, and 3. In production environments, SNMPv1 should never be deployed. SNMPv2c is still widely used but relies on cleartext community strings with no encryption or per-user authentication. SNMPv3 adds authentication (MD5 or SHA) and optional encryption (DES, 3DES, AES), making it the correct choice for any environment that must meet compliance standards or a security baseline.

This run book covers complete SNMPv2c and SNMPv3 configuration on Cisco IOS/IOS-XE, including views, groups, users, traps, informs, ACL restrictions, threshold alerts, and all verification commands needed to confirm a working deployment.

SNMP Architecture Overview

SNMP operates on a manager/agent model. The SNMP agent runs on each managed device and exposes data through a Management Information Base (MIB) — a hierarchical tree of OIDs (Object Identifiers). The NMS queries these OIDs using GET and GETNEXT operations, or receives unsolicited notifications via traps and informs.

• SNMP GET: The NMS polls the agent for a specific OID value.
• SNMP GETNEXT / GETBULK: The NMS walks the MIB tree efficiently to retrieve multiple values in sequence.
• SNMP SET: The NMS writes a value to a writable OID. Requires a read-write community string or an SNMPv3 user with write privileges.
• SNMP TRAP: The agent sends an unsolicited notification to the NMS with no acknowledgment required.
• SNMP INFORM: The agent sends a notification and waits for acknowledgment. More reliable than traps, at the cost of slightly higher overhead.

SNMPv3 introduces two key models: the User Security Model (USM), which handles per-user authentication and encryption, and the View-Based Access Control Model (VACM), which controls which portions of the MIB tree each user or group can access. Together these eliminate the primary weaknesses of earlier SNMP versions.

SNMPv2c Configuration

SNMPv2c remains the most commonly deployed SNMP version in legacy environments. While it lacks per-user authentication, you can significantly reduce risk by restricting SNMP access to known management IPs using an ACL bound directly to the community string.

Step 1: Create an ACL to Restrict SNMP Access

Always bind a standard ACL to your community strings to limit which hosts can poll the device. Using a named ACL makes future management straightforward.

sw-infrarunbook-01# configure terminal

! Define the NMS hosts permitted to poll via SNMP
sw-infrarunbook-01(config)# ip access-list standard ACL-SNMP-ALLOWED
sw-infrarunbook-01(config-std-nacl)# permit 10.10.10.100
sw-infrarunbook-01(config-std-nacl)# permit 10.10.10.101
sw-infrarunbook-01(config-std-nacl)# deny any log
sw-infrarunbook-01(config-std-nacl)# exit

Step 2: Configure a Read-Only Community String

! Read-only community restricted to ACL-SNMP-ALLOWED
sw-infrarunbook-01(config)# snmp-server community inframon-ro RO ACL-SNMP-ALLOWED

Step 3: Configure a Read-Write Community String (If Required)

Avoid read-write SNMP access unless your NMS specifically requires it for configuration management. If required, bind it to a separate, more restrictive ACL than the read-only community.

sw-infrarunbook-01(config)# ip access-list standard ACL-SNMP-RW
sw-infrarunbook-01(config-std-nacl)# permit 10.10.10.100
sw-infrarunbook-01(config-std-nacl)# deny any log
sw-infrarunbook-01(config-std-nacl)# exit

sw-infrarunbook-01(config)# snmp-server community inframon-rw RW ACL-SNMP-RW

Step 4: Set Device Identity Fields

The location and contact fields are stored in standard MIB-II OIDs and are retrieved by most NMS platforms during discovery to populate the device inventory.

sw-infrarunbook-01(config)# snmp-server location "Data Center - Rack 14 - U12"
sw-infrarunbook-01(config)# snmp-server contact "NOC Team - noc@solvethenetwork.com"

Step 5: Configure an SNMP Trap Destination for SNMPv2c

! Send traps to NMS at 10.10.10.100 using v2c and read-only community
sw-infrarunbook-01(config)# snmp-server host 10.10.10.100 version 2c inframon-ro

! Enable specific trap categories
sw-infrarunbook-01(config)# snmp-server enable traps snmp authentication linkdown linkup coldstart warmstart
sw-infrarunbook-01(config)# snmp-server enable traps config
sw-infrarunbook-01(config)# snmp-server enable traps envmon
sw-infrarunbook-01(config)# snmp-server enable traps cpu threshold
sw-infrarunbook-01(config)# snmp-server enable traps syslog

Step 6: Pin the Trap Source Interface

Always bind SNMP traps to a loopback or management interface so that the source IP is stable and predictable in your NMS, regardless of which physical path is used to reach the trap receiver.

sw-infrarunbook-01(config)# snmp-server trap-source Loopback0

SNMPv3 Configuration

SNMPv3 uses a three-tier model: Views define which portions of the MIB are accessible, Groups bind views to security levels, and Users are assigned to groups with specific authentication and privacy credentials. This architecture provides per-user accountability and cryptographic integrity that are completely absent in SNMPv2c.

SNMPv3 Security Levels

• noAuthNoPriv: No authentication, no encryption. Provides no meaningful security advantage over SNMPv2c.
• authNoPriv: Authentication via MD5 or SHA, but no encryption. Protects against credential spoofing but not packet interception.
• authPriv: Authentication plus encryption using AES-128, AES-192, AES-256, or DES. Required for all production environments handling sensitive network telemetry.

Step 1: Define an SNMP View

Views restrict which OIDs are visible to a group. Defining a custom view is best practice — it limits what your NMS can enumerate to exactly what it needs, reducing the blast radius if SNMPv3 credentials are ever compromised.

! Grant access to the full internet subtree but exclude the SNMPv3 framework MIB
sw-infrarunbook-01(config)# snmp-server view VIEW-INFRAMON internet included
sw-infrarunbook-01(config)# snmp-server view VIEW-INFRAMON 1.3.6.1.6.3 excluded

! Alternatively, restrict to MIB-II only (interfaces, IP, TCP, UDP, ICMP stats):
! snmp-server view VIEW-MIBIONLY 1.3.6.1.2.1 included

Step 2: Create an SNMPv3 Group

Groups bind the security level to the read and write views. Groups do not hold credentials — they define policy. All users assigned to a group inherit that group's security level and MIB access.

! Read-only group with authPriv security level bound to VIEW-INFRAMON
sw-infrarunbook-01(config)# snmp-server group GRPV3-RO v3 priv read VIEW-INFRAMON

! Read-write group (configure only if NMS requires write access)
sw-infrarunbook-01(config)# snmp-server group GRPV3-RW v3 priv read VIEW-INFRAMON write VIEW-INFRAMON

Step 3: Create SNMPv3 Users

Users are assigned to groups with explicit authentication and privacy parameters. Use SHA for authentication and AES-128 or higher for encryption. Avoid MD5 and DES in new deployments — both are considered cryptographically weak by modern standards and should not be used where compliance frameworks apply.

! Primary monitoring user with SHA authentication and AES-128 encryption
sw-infrarunbook-01(config)# snmp-server user nms-poller GRPV3-RO v3 auth sha Str0ng@uth2024 priv aes 128 Str0ngPr1v2024

! Secondary monitoring user for a backup NMS
sw-infrarunbook-01(config)# snmp-server user nms-backup GRPV3-RO v3 auth sha B@ckupAuth9876 priv aes 128 B@ckupPr1v9876

Note: SNMPv3 user credentials are hashed and stored in a non-retrievable form. They will not appear in

show running-config

. Use

show snmp user

to confirm that users exist and to verify their group membership and security parameters.

Step 4: Apply an ACL to the SNMPv3 Group

Even with SNMPv3 cryptographic authentication, restricting polling by source IP is valuable defense-in-depth. Apply the ACL at the group level using the

access

keyword.

! Re-apply the group definition with ACL restriction
sw-infrarunbook-01(config)# snmp-server group GRPV3-RO v3 priv read VIEW-INFRAMON access ACL-SNMP-ALLOWED

Step 5: Configure an SNMPv3 Trap Destination

! Send SNMPv3 traps to 10.10.10.100 using authPriv level with user nms-poller
sw-infrarunbook-01(config)# snmp-server host 10.10.10.100 version 3 priv nms-poller

! Enable trap categories relevant to production monitoring
sw-infrarunbook-01(config)# snmp-server enable traps snmp authentication linkdown linkup coldstart warmstart
sw-infrarunbook-01(config)# snmp-server enable traps config
sw-infrarunbook-01(config)# snmp-server enable traps envmon
sw-infrarunbook-01(config)# snmp-server enable traps cpu threshold
sw-infrarunbook-01(config)# snmp-server enable traps bgp
sw-infrarunbook-01(config)# snmp-server enable traps ospf
sw-infrarunbook-01(config)# snmp-server enable traps syslog

sw-infrarunbook-01(config)# snmp-server trap-source Loopback0

SNMP Inform Requests

Informs are acknowledged SNMP notifications. If the NMS does not send an acknowledgment within the configured timeout, the agent retransmits up to the configured retry count. This makes informs substantially more reliable than fire-and-forget traps for critical event delivery across unreliable paths or congested links.

! SNMPv2c informs to primary NMS
sw-infrarunbook-01(config)# snmp-server host 10.10.10.100 informs version 2c inframon-ro

! SNMPv3 informs using authPriv
sw-infrarunbook-01(config)# snmp-server host 10.10.10.100 informs version 3 priv nms-poller

! Tune retransmit count and timeout (seconds)
sw-infrarunbook-01(config)# snmp-server inform retries 5
sw-infrarunbook-01(config)# snmp-server inform timeout 30

SNMP Engine ID

The SNMP Engine ID uniquely identifies each SNMP agent instance. For SNMPv3, the Engine ID participates in the HMAC computation for user authentication — meaning credentials created on the NMS for a specific Engine ID will not work against a different Engine ID. When pre-provisioning SNMPv3 users on an NMS before device discovery, you must supply the Engine ID manually. In high-availability scenarios where two devices share a logical identity, setting a static Engine ID ensures credential consistency.

! Display the current Engine ID
sw-infrarunbook-01# show snmp engineID
Local SNMP engineID: 80000009030010F301234567

! Optionally configure a static Engine ID
! WARNING: Changing the Engine ID invalidates all existing SNMPv3 user credentials
sw-infrarunbook-01(config)# snmp-server engineID local 80000009030010F301234567

SNMP CPU and Memory Threshold Traps

Cisco IOS-XE can generate SNMP traps when CPU or memory crosses configurable thresholds. Configuring these proactive alerts is essential for catching runaway processes or resource exhaustion before the device becomes unresponsive.

! Generate a rising trap when the 5-second CPU average exceeds 80%
sw-infrarunbook-01(config)# process cpu threshold type total rising 80 interval 5

! Generate a falling trap when CPU drops back below 60% (for NMS state clearing)
sw-infrarunbook-01(config)# process cpu threshold type total falling 60 interval 5

! Enable the CPU threshold trap
sw-infrarunbook-01(config)# snmp-server enable traps cpu threshold

! Alert when free processor memory drops below 20 MB
sw-infrarunbook-01(config)# memory free low-watermark processor 20480

Removing SNMPv1 and SNMPv2c for Hardening

Once your environment has fully migrated to SNMPv3, remove all community strings. This eliminates cleartext credential exposure and ensures no legacy NMS or scanning tool can successfully poll the device using weaker SNMP versions.

! Remove each community string by name
sw-infrarunbook-01(config)# no snmp-server community inframon-ro
sw-infrarunbook-01(config)# no snmp-server community inframon-rw

! Verify no communities remain
sw-infrarunbook-01# show snmp community

! To disable the SNMP agent entirely (removes ALL SNMP config including v3 users)
! WARNING: This is irreversible without reconfiguring from scratch
sw-infrarunbook-01(config)# no snmp-server

Verification and Troubleshooting

Verifying SNMP Configuration

! Show global SNMP counters and configuration summary
sw-infrarunbook-01# show snmp

! Show configured community strings (v1/v2c)
sw-infrarunbook-01# show snmp community

! Show all configured SNMPv3 groups
sw-infrarunbook-01# show snmp group

! Show all configured SNMPv3 users (credentials are not shown, only parameters)
sw-infrarunbook-01# show snmp user

! Show configured views and the OID subtrees they permit or exclude
sw-infrarunbook-01# show snmp view

! Show trap and inform host destinations
sw-infrarunbook-01# show snmp host

! List all supported MIB modules on the device
sw-infrarunbook-01# show snmp mib

Checking SNMP Packet Counters

sw-infrarunbook-01# show snmp
Chassis: FXS2142Q0GE
Contact: NOC Team - noc@solvethenetwork.com
Location: Data Center - Rack 14 - U12
3421 SNMP packets input
    0 Bad SNMP version errors
    0 Unknown community name
    0 Illegal operation for community name supplied
    0 Encoding errors
 3421 Number of requested variables
    0 Number of altered variables
 3421 Get-request PDUs
    0 Get-next PDUs
    0 Set-request PDUs
    0 Input queue packet drops (Maximum queue size 1000)
3439 SNMP packets output
    0 Too big errors (Maximum packet size 1500)
    0 No such name errors
    0 Bad values errors
    0 General errors
 3421 Response PDUs
   18 Trap PDUs

Debugging SNMP

! Debug SNMP packet exchange — use with caution on active polling devices
sw-infrarunbook-01# debug snmp packets
sw-infrarunbook-01# debug snmp requests

! Confirm SNMP agent is listening on UDP 161
sw-infrarunbook-01# show udp | include 161

! Check ACL hit counters to confirm NMS polling traffic is being permitted
sw-infrarunbook-01# show ip access-lists ACL-SNMP-ALLOWED

Testing SNMP Connectivity from a Linux NMS

# Test SNMPv2c GET for sysDescr OID
snmpget -v2c -c inframon-ro 10.10.10.1 1.3.6.1.2.1.1.1.0

# Test SNMPv3 GET with authPriv
snmpget -v3 -l authPriv -u nms-poller -a SHA -A "Str0ng@uth2024" -x AES -X "Str0ngPr1v2024" 10.10.10.1 1.3.6.1.2.1.1.1.0

# Walk the full MIB-II subtree via SNMPv3
snmpwalk -v3 -l authPriv -u nms-poller -a SHA -A "Str0ng@uth2024" -x AES -X "Str0ngPr1v2024" 10.10.10.1 1.3.6.1.2.1

Complete SNMPv3-Only Production Configuration

The following is a self-contained, production-ready SNMPv3 configuration for a Cisco IOS-XE device. It uses no community strings, restricts polling to specific NMS hosts via ACL, enforces the authPriv security level with SHA authentication and AES-128 encryption, and configures proactive CPU threshold traps.

! ============================================================
! SNMP SOURCE RESTRICTION ACL
! ============================================================
ip access-list standard ACL-SNMP-ALLOWED
 permit 10.10.10.100
 permit 10.10.10.101
 deny any log

! ============================================================
! SNMP DEVICE IDENTITY
! ============================================================
snmp-server location "Data Center - Rack 14 - U12"
snmp-server contact "NOC Team - noc@solvethenetwork.com"

! ============================================================
! SNMPv3 VIEW
! ============================================================
snmp-server view VIEW-INFRAMON internet included
snmp-server view VIEW-INFRAMON 1.3.6.1.6.3 excluded

! ============================================================
! SNMPv3 GROUP (read-only, authPriv, ACL-restricted)
! ============================================================
snmp-server group GRPV3-RO v3 priv read VIEW-INFRAMON access ACL-SNMP-ALLOWED

! ============================================================
! SNMPv3 USERS (SHA auth + AES-128 priv)
! ============================================================
snmp-server user nms-poller GRPV3-RO v3 auth sha Str0ng@uth2024 priv aes 128 Str0ngPr1v2024
snmp-server user nms-backup GRPV3-RO v3 auth sha B@ckupAuth9876 priv aes 128 B@ckupPr1v9876

! ============================================================
! SNMPv3 TRAP DESTINATION
! ============================================================
snmp-server host 10.10.10.100 version 3 priv nms-poller
snmp-server trap-source Loopback0

! ============================================================
! TRAP CATEGORIES
! ============================================================
snmp-server enable traps snmp authentication linkdown linkup coldstart warmstart
snmp-server enable traps config
snmp-server enable traps envmon
snmp-server enable traps cpu threshold
snmp-server enable traps bgp
snmp-server enable traps ospf
snmp-server enable traps syslog

! ============================================================
! CPU THRESHOLD TRAPS
! ============================================================
process cpu threshold type total rising 80 interval 5
process cpu threshold type total falling 60 interval 5

! ============================================================
! NO SNMPv1/v2c COMMUNITIES (verify with: show snmp community)
! ============================================================

Frequently Asked Questions

Q: What is the difference between SNMPv2c and SNMPv3?

A: SNMPv2c uses cleartext community strings for both authentication and access control. Any host that knows the community string and can reach UDP port 161 can poll or (with a read-write community) modify the device. SNMPv3 replaces community strings with per-user credentials backed by cryptographic authentication (MD5 or SHA) and optional payload encryption (DES, 3DES, or AES). This eliminates credential sniffing and replay attacks, makes per-user auditing possible, and satisfies most compliance frameworks that prohibit cleartext management protocols.

Q: Why does my SNMPv3 user password not appear in show running-config?

A: Cisco IOS-XE converts SNMPv3 user authentication and privacy passwords into localized keys using the Engine ID as part of the HMAC derivation process. These hashed keys are stored internally but are never displayed in the running or startup configuration. To verify that a user exists and confirm its group membership and security parameters, use

show snmp user

. If you lose the passwords, you must delete the user with

no snmp-server user <username>

and recreate it.

Q: What is the difference between SNMP traps and SNMP informs?

A: Traps are unacknowledged, fire-and-forget notifications sent from the agent to the NMS. If the NMS is unreachable or drops the packet, the event is lost permanently. Informs require the NMS to send an acknowledgment. If the agent does not receive acknowledgment within the configured timeout, it retransmits up to the configured retry count. Informs are more reliable for critical events such as BGP session drops or hardware failures, but they consume more memory on the agent because unsent informs must be queued.

Q: How do I restrict SNMP polling to specific NMS hosts on Cisco IOS-XE?

A: For SNMPv2c, bind a standard ACL directly to the community string:

snmp-server community <string> RO <acl-name>

. For SNMPv3, apply the ACL at the group level using the

access

keyword:

snmp-server group <group> v3 priv read <view> access <acl-name>

. In both cases, the ACL should explicitly deny all other sources with

deny any log

to capture unauthorized polling attempts in the syslog.

Q: Can I run SNMPv2c and SNMPv3 simultaneously on the same Cisco device?

A: Yes. Cisco IOS-XE supports concurrent SNMPv2c community strings and SNMPv3 users on the same device. Both can coexist without conflict. This is common during migrations where legacy NMS platforms do not yet support SNMPv3. The recommended approach is to run both versions in parallel during the migration window, then remove the community strings once all NMS components have been confirmed working with SNMPv3.

Q: Which SNMP version should I use in a new deployment?

A: Always use SNMPv3 with the authPriv security level for new deployments. Configure SHA for authentication (not MD5) and AES-128 or higher for encryption (not DES). Supplement SNMPv3 with an ACL restricting polling to specific NMS IP addresses. This combination satisfies PCI-DSS, CIS Cisco IOS Benchmark, and DISA STIG requirements that explicitly prohibit unencrypted management protocols.

Q: What is an SNMP view and why should I configure one?

A: An SNMP view defines a named subset of the MIB tree using included and excluded OID subtrees. Views are assigned to SNMPv3 groups and control exactly which OIDs members of that group can read or write. Without a custom view, an SNMPv3 group defaults to access to the entire MIB tree. Configuring a restrictive view — for example limiting access to MIB-II and Cisco enterprise MIBs while excluding the SNMPv3 framework MIB subtree — reduces the attack surface if credentials are compromised and prevents NMS platforms from inadvertently walking sensitive OIDs.

Q: What is the SNMP Engine ID and why does it matter for SNMPv3 users?

A: The Engine ID is a globally unique identifier for an SNMP agent, typically derived from the device MAC address or chassis serial number. For SNMPv3, it is used as an input to the HMAC key derivation function when user credentials are created. This means that SNMPv3 user keys are Engine ID-specific — keys generated for one Engine ID will not authenticate against a device with a different Engine ID. If you need to pre-provision users on the NMS before discovering a new device, you must supply the correct Engine ID using

show snmp engineID

on the device side.

Q: How do I configure CPU threshold traps on Cisco IOS-XE?

A: Use the

process cpu threshold type total rising <percent> interval <seconds>

command to define the rising threshold and optionally a corresponding falling threshold for NMS state clearing. Then enable the trap category with

snmp-server enable traps cpu threshold

. The interval value specifies the averaging window in seconds — common choices are 5 seconds for short-burst detection or 60 seconds for sustained load alerting. The trap is sent to all configured

snmp-server host

destinations.

Q: How do I completely disable SNMP on a Cisco IOS-XE device?

A: Issue the

no snmp-server

command in global configuration mode. This single command removes all SNMP configuration from the device including all community strings, SNMPv3 views, groups, and users, all trap and inform destinations, the trap source interface binding, and the location and contact fields. The SNMP agent process stops listening on UDP port 161 immediately. Verify with

show snmp

— the output will show that SNMP is disabled. Note that this action is complete and irreversible; full reconfiguration will be required to re-enable SNMP.

Q: My SNMP polling returns Unknown community name errors. How do I troubleshoot?

A: First, confirm the community string matches exactly (case-sensitive) using

show snmp community

. Second, check whether an ACL is bound to the community and verify that the NMS source IP is explicitly permitted:

show ip access-lists ACL-SNMP-ALLOWED

. Third, enable

debug snmp packets

and trigger a poll from the NMS — the debug output will show the incoming request, community string received, and the reason for rejection. Finally, verify the NMS is sending to UDP port 161 on the correct management IP and not a transit address that may not be accessible.

Q: How do I send SNMP traps from a specific source IP on Cisco IOS-XE?

A: Use

snmp-server trap-source <interface>

to pin all outgoing trap and inform packets to a specific interface IP. The most reliable choice is a Loopback interface, since loopbacks are always up and always have a consistent IP. This ensures that your NMS can correlate incoming traps to the correct device entry in its inventory regardless of which physical uplink path the trap traverses. Without this command, the device selects the source IP based on the routing table lookup for the trap destination, which can produce different source addresses depending on the active path.