SNMP v2c and v3 Configuration on Cisco IOS

SNMP (Simple Network Management Protocol) is the universal language of network monitoring. Every Cisco router, switch, and firewall exposes thousands of variables — interface counters, CPU load, memory usage, BGP neighbour state, temperature sensors — through a structured database called the MIB (Management Information Base). An NMS (Network Management Station) queries these variables using SNMP Get requests and receives proactive alerts through Traps. The protocol's weakness has always been security: SNMPv1 and v2c use a plain-text community string as the only authentication mechanism, transmitted unencrypted in every packet — readable by anyone with a packet capture tool. SNMPv3 resolves this entirely, adding per-user authentication (HMAC-MD5 or HMAC-SHA) and optional payload encryption (AES or 3DES), making it the only version acceptable in security-conscious environments.

This lab configures both versions on NetsTuts-R1: SNMPv2c with a read-only and a read-write community string for backwards compatibility with legacy NMS tools, and SNMPv3 with the authPriv security level (authentication plus encryption) for production monitoring. Traps and informs are configured to alert a centralised NMS at 192.168.10.100. For time-stamped SNMP trap messages, the router must have NTP configured — see NTP Configuration. For ACL-based restriction of SNMP access, the ACL fundamentals are covered in Standard ACL Configuration. For securing management access to the router itself, see SSH Configuration and AAA TACACS+ Configuration. For the complementary syslog monitoring layer see Syslog Configuration. For flow-based traffic monitoring see NetFlow Configuration.

1. SNMP Architecture and Core Concepts

The Three Components

Every SNMP deployment has three actors. Understanding their roles explains why each IOS command is needed:

Component	Role	Examples
SNMP Agent	Runs on the managed device (router, switch, AP). Listens on UDP/161 for queries. Sends traps on UDP/162. Maintains the MIB for that device	Cisco IOS `snmp-server` process on R1, a switch, or a firewall
NMS (Network Management Station)	The monitoring server. Polls agents with Get requests, receives traps, stores historical data, generates alerts and graphs	SolarWinds, Zabbix, PRTG, Nagios, Cisco Prime Infrastructure, LibreNMS
MIB (Management Information Base)	A hierarchical database of variables (objects) the agent exposes. Each object has a unique numeric identifier — the OID (Object Identifier)	Cisco IOS MIB: `1.3.6.1.4.1.9`. Interface table: `1.3.6.1.2.1.2.2` (ifTable)

SNMP Operations

Operation	Direction	UDP Port	Purpose
Get	NMS → Agent	161	Retrieve the current value of a single OID. NMS initiates, agent responds
GetNext	NMS → Agent	161	Retrieve the next OID in the MIB tree. Used to walk the MIB and discover all available objects
GetBulk (v2c/v3)	NMS → Agent	161	Retrieve multiple OID values in one request. More efficient than repeated GetNext operations for polling large tables (e.g., the full interface table)
Set	NMS → Agent	161	Write a value to a writable OID on the agent (e.g., change interface description, set system name). Requires read-write community string or SNMPv3 read-write user
Trap	Agent → NMS	162	Agent-initiated alert for an event (link up/down, config change, high CPU). Fire-and-forget — no acknowledgement. The agent does not know if the NMS received the trap
Inform (v2c/v3)	Agent → NMS	162	Like a trap but with acknowledgement. NMS sends an acknowledgement (InformResponse). If no acknowledgement is received within the timeout, the agent retransmits. More reliable than traps for critical events
Response	Agent → NMS	161	Agent's reply to Get, GetNext, GetBulk, or Set requests. Contains the requested OID values or an error code

OID Structure — Understanding the MIB Tree

  OID:  1  .  3  .  6  .  1  .  2  .  1  .  1  .  1  .  0
        │     │     │     │     │     │     │     │     └─ instance (0 = scalar)
        │     │     │     │     │     │     │     └─ sysDescr (1)
        │     │     │     │     │     │     └─ system (1) subtree
        │     │     │     │     │     └─ mib-2 (1)
        │     │     │     │     └─ mgmt (2)
        │     │     │     └─ internet (1)
        │     │     └─ dod (6)
        │     └─ org (3)
        └─ iso (1)

  Common OIDs on Cisco IOS:
  ┌──────────────────────────────────────────────────────────────────┐
  │  1.3.6.1.2.1.1.1.0    sysDescr     — IOS version string         │
  │  1.3.6.1.2.1.1.3.0    sysUpTime    — Timeticks since last reset  │
  │  1.3.6.1.2.1.1.5.0    sysName      — hostname                    │
  │  1.3.6.1.2.1.1.6.0    sysLocation  — snmp-server location value  │
  │  1.3.6.1.2.1.2.2.1.2  ifDescr      — interface name (table)      │
  │  1.3.6.1.2.1.2.2.1.10 ifInOctets   — input byte counter          │
  │  1.3.6.1.2.1.2.2.1.16 ifOutOctets  — output byte counter         │
  │  1.3.6.1.4.1.9.2.1.57 ciscoSysCPU  — 5-min CPU average (Cisco)   │
  └──────────────────────────────────────────────────────────────────┘

OIDs beginning with 1.3.6.1.2.1 are standard MIB-II objects — universally supported by all SNMP agents. OIDs beginning with 1.3.6.1.4.1.9 are Cisco private enterprise MIBs — Cisco-specific objects not available on non-Cisco devices. Enterprise number 9 is Cisco's IANA-assigned private enterprise number.

2. SNMPv1 vs v2c vs v3 — Security Comparison

Feature	SNMPv1	SNMPv2c	SNMPv3
Authentication	Community string (plain text, no hashing)	Community string (plain text, no hashing)	Per-user — HMAC-MD5 or HMAC-SHA password hash
Encryption	None — all data in clear text	None — all data in clear text	Optional — AES-128, AES-192, AES-256, or 3DES
Security levels	noAuthNoPriv (community string only)	noAuthNoPriv (community string only)	noAuthNoPriv / authNoPriv / authPriv
Bulk operations	Not supported (GetNext only)	GetBulk supported — efficient table polling	GetBulk supported
Informs	Not supported	Supported — acknowledged traps	Supported with full authentication and encryption
64-bit counters	Not supported (32-bit wraps at ~4 Gbps in 8 seconds)	Supported (Counter64) — required for high-speed interfaces	Supported
IETF recommendation	Obsolete — do not use	Permitted for legacy NMS; not for security-sensitive environments	Recommended for all production deployments

SNMPv3 Security Levels Explained

Security Level	Auth	Encryption	IOS Keyword	Use Case
noAuthNoPriv	Username match only — no password	None	`noauth`	Lab / test only. Not suitable for production
authNoPriv	HMAC-MD5 or HMAC-SHA password	None — payload visible in packet capture	`auth`	Better than v2c but SNMP data (OID values) readable by an observer
authPriv	HMAC-MD5 or HMAC-SHA password	AES-128 / AES-192 / AES-256 / 3DES	`priv`	Production standard — both identity and data are protected. Recommended by Cisco and NIST

Why MD5 is still used in SNMPv3. HMAC-MD5 in SNMPv3 is used for message authentication (HMAC), not for password storage. HMAC-MD5 computes a keyed hash to verify message integrity — the collision vulnerabilities that make MD5 unsuitable for password hashing do not apply to HMAC usage. That said, Cisco recommends SHA (or SHA-256 on newer IOS-XE versions) for new deployments. In this lab, SHA is used for the auth protocol.

3. Lab Topology & Design

NetsTuts-R1 is the managed device (SNMP agent). An NMS server at 192.168.10.100 polls R1 and receives traps. An ACL restricts SNMP queries to only the NMS IP address — preventing any other host from querying the agent even if they know the community string or SNMPv3 credentials:

                    192.168.10.0/24 — Management LAN
                              |
                          Gi0/0 (192.168.10.1)
                         NetsTuts-R1
                    SNMP Agent — UDP/161 (queries)
                               — UDP/162 (traps outbound)
                              |
              ┌───────────────┴───────────────┐
         192.168.10.100                  192.168.10.5
           NMS Server                    Admin PC
        (Zabbix / LibreNMS)          (MIB browser:
         polls R1 via SNMP            MIB Browser Pro
         receives traps/informs        OID queries)

  ┌──────────────────────────────────────────────────────────────┐
  │  SNMPv2c READ-ONLY:  community = NetsTuts-RO2026            │
  │  SNMPv2c READ-WRITE: community = NetsTuts-RW2026!           │
  │  (Both restricted to ACL SNMP-ACCESS: permit 192.168.10.100) │
  ├──────────────────────────────────────────────────────────────┤
  │  SNMPv3 Group:   NETSTUTS-V3-GROUP  (authPriv / AES)        │
  │  SNMPv3 User:    snmpv3user                                  │
  │  Auth: SHA  / Auth password: Auth@NetsTuts2026               │
  │  Priv: AES  / Priv password: Priv@NetsTuts2026               │
  ├──────────────────────────────────────────────────────────────┤
  │  Trap destination (v2c + v3): 192.168.10.100                 │
  │  Source interface: Loopback0 (192.168.10.1)                  │
  └──────────────────────────────────────────────────────────────┘

Parameter	Value
Router hostname	NetsTuts-R1
Management interface	Gi0/0 — 192.168.10.1/24
NMS server IP	192.168.10.100
SNMPv2c RO community	NetsTuts-RO2026
SNMPv2c RW community	NetsTuts-RW2026!
SNMPv3 group	NETSTUTS-V3-GROUP
SNMPv3 username	snmpv3user
Auth protocol / password	SHA / Auth@NetsTuts2026
Privacy protocol / password	AES 128 / Priv@NetsTuts2026
Trap/inform destination	192.168.10.100

4. Step 1 — Create the SNMP Access Control ACL

An SNMP access restriction ACL must be created before the community strings or SNMPv3 users that reference it. This ACL permits only the NMS server IP to query the agent — all other sources are implicitly denied:

NetsTuts-R1>en
NetsTuts-R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.

! ── SNMP access restriction ACL ──────────────────────────────────
NetsTuts-R1(config)#ip access-list standard SNMP-ACCESS
NetsTuts-R1(config-std-nacl)#remark Permit NMS server only
NetsTuts-R1(config-std-nacl)#permit host 192.168.10.100
NetsTuts-R1(config-std-nacl)#exit

! ── Optional: permit the admin PC for MIB browser access ─────────
! NetsTuts-R1(config)#ip access-list standard SNMP-ACCESS
! NetsTuts-R1(config-std-nacl)#permit host 192.168.10.5
! NetsTuts-R1(config-std-nacl)#exit

The SNMP ACL is a standard ACL — it matches only source IP addresses. It is applied to the snmp-server community command directly, not to an interface. This means it restricts who can query the SNMP agent regardless of which interface the query arrives on. An implicit deny any at the end blocks all other sources. For ACL syntax review, see Standard ACL Configuration.

5. Step 2 — Global SNMP Settings

These global commands configure the SNMP agent identity — descriptive fields that appear in the MIB and in NMS dashboards. They do not affect security but are required for good NMS housekeeping:

! ── Agent identity information ────────────────────────────────────
NetsTuts-R1(config)#snmp-server contact [email protected]
NetsTuts-R1(config)#snmp-server location "NetsTuts HQ - Server Room A - Rack 3"
NetsTuts-R1(config)#snmp-server chassis-id NetsTuts-R1

! ── Restrict SNMP queries to management interface (Gi0/0) ─────────
! Source interface ensures traps originate from a consistent IP
NetsTuts-R1(config)#snmp-server trap-source GigabitEthernet0/0
NetsTuts-R1(config)#snmp-server source-interface informs GigabitEthernet0/0

snmp-server contact populates the sysContact OID (1.3.6.1.2.1.1.4.0) and snmp-server location populates sysLocation (1.3.6.1.2.1.1.6.0). These are visible in any MIB browser and help NMS operators identify and locate devices quickly. snmp-server trap-source pins all outbound trap packets to a specific interface IP, ensuring the NMS receives traps from a consistent, routable address even if the router has multiple interfaces. If a loopback interface is available, use it as the trap source for resilience — loopbacks stay up even when physical interfaces fail.

6. Step 3 — Configure SNMPv2c Community Strings

Two community strings are configured: a read-only string for the NMS to poll data, and a read-write string for NMS tools that need to modify device parameters. Both are locked to the SNMP-ACCESS ACL:

! ── Read-only community string ────────────────────────────────────
! RO = can only perform Get/GetNext/GetBulk — cannot Set values
NetsTuts-R1(config)#snmp-server community NetsTuts-RO2026 RO SNMP-ACCESS

! ── Read-write community string ───────────────────────────────────
! RW = can perform Get AND Set — treat this like a password
NetsTuts-R1(config)#snmp-server community NetsTuts-RW2026! RW SNMP-ACCESS

Community strings are NOT passwords. They are transmitted in plain text in every SNMPv2c packet — any device on the network path between the NMS and the agent that captures traffic can read the community string from the UDP packet header. A read-write community string gives that attacker the ability to change the router's running configuration via SNMP Set operations. Always: (1) use a non-default string (never public or private), (2) restrict with an ACL, and (3) prefer SNMPv3 for any environment where security matters. If SNMPv2c read-write is not required, omit it entirely.

Configuring SNMPv2c Trap Destination

! ── SNMPv2c trap destination ──────────────────────────────────────
! Uses the RO community string for the trap packet
NetsTuts-R1(config)#snmp-server host 192.168.10.100 version 2c NetsTuts-RO2026

! ── Enable specific trap types ────────────────────────────────────
NetsTuts-R1(config)#snmp-server enable traps snmp authentication linkdown linkup
NetsTuts-R1(config)#snmp-server enable traps config
NetsTuts-R1(config)#snmp-server enable traps envmon
NetsTuts-R1(config)#snmp-server enable traps bgp
NetsTuts-R1(config)#snmp-server enable traps ospf
NetsTuts-R1(config)#snmp-server enable traps cpu threshold
NetsTuts-R1(config)#snmp-server enable traps syslog

Trap Type	Event Triggered	OID / Notification
`snmp authentication`	SNMP request received with incorrect community string or invalid SNMPv3 credentials	authenticationFailure (1.3.6.1.6.3.1.1.5.5)
`snmp linkdown / linkup`	Physical interface transitions from up to down or down to up	linkDown (1.3.6.1.6.3.1.1.5.3) / linkUp (.5.4)
`config`	Running configuration is modified (any `conf t` change committed)	ciscoConfigManEvent (Cisco MIB)
`envmon`	Environmental thresholds: temperature, fan, voltage, power supply state change	Cisco ENVMON MIB traps
`bgp`	BGP neighbour state change (established / idle)	bgpBackwardTransition / bgpEstablished — see BGP Overview
`ospf`	OSPF neighbour state change or LSA threshold exceeded	OSPF-MIB traps — see OSPF Overview
`cpu threshold`	CPU utilisation crosses the rising or falling threshold	cpmCPURisingThreshold (Cisco)
`syslog`	A syslog message of severity ≤ configured level is generated	ciscoSyslogMIB notifications

7. Step 4 — Create the SNMPv3 Group

SNMPv3 configuration on Cisco IOS follows a three-step model: View → Group → User. A View defines which OIDs are accessible. A Group links a security level and a view. A User is the credential assigned to the group. The group is configured first:

  SNMPv3 Configuration Hierarchy:

  snmp-server view [VIEW-NAME] [OID-subtree] included/excluded
        │
        ▼
  snmp-server group [GROUP-NAME] v3 priv
        │  ├─ read  [VIEW-NAME]
        │  ├─ write [VIEW-NAME]
        │  └─ access [ACL-NAME]
        │
        ▼
  snmp-server user [USERNAME] [GROUP-NAME] v3
        └─ auth sha [auth-password]
           priv aes 128 [priv-password]

! ── Step 4a: Create a MIB view ────────────────────────────────────
! "included" = allow access to this OID subtree
! Using the standard "internet" subtree covers all MIB-II and Cisco MIBs
NetsTuts-R1(config)#snmp-server view NETSTUTS-VIEW internet included

! ── Alternative: restrict to specific subtrees only ──────────────
! NetsTuts-R1(config)#snmp-server view NETSTUTS-VIEW 1.3.6.1.2.1 included
! NetsTuts-R1(config)#snmp-server view NETSTUTS-VIEW 1.3.6.1.4.1.9 included

! ── Step 4b: Create the SNMPv3 group ──────────────────────────────
! Security model: v3
! Security level: priv (authPriv — auth + encryption)
! Read view:  NETSTUTS-VIEW (NMS can poll these OIDs)
! Write view: NETSTUTS-VIEW (NMS can set these OIDs)
! Access ACL: SNMP-ACCESS (restrict to NMS IP)
NetsTuts-R1(config)#snmp-server group NETSTUTS-V3-GROUP v3 priv read NETSTUTS-VIEW write NETSTUTS-VIEW access SNMP-ACCESS

The snmp-server view internet included command creates a view named NETSTUTS-VIEW that includes the entire internet OID subtree (1.3.6.1) — all standard MIB-II objects and all Cisco enterprise MIBs. If a more restrictive view is needed (e.g., read-only access to interface counters but not routing tables), use specific OID subtrees with included and excluded keywords. The write view is optional — omit it if the SNMPv3 user should be read-only. Including access SNMP-ACCESS on the group applies the same IP restriction to SNMPv3 that the community ACL applies to v2c.

8. Step 5 — Create the SNMPv3 User

The user is added to the group and carries the authentication and privacy credentials. Important: the snmp-server user command must be entered after the group it references. The credentials are hashed on the router — they do not appear in plain text in the running configuration:

! ── Create SNMPv3 user ────────────────────────────────────────────
! Format: snmp-server user [username] [group] v3
!         auth [md5|sha] [auth-password]
!         priv [des|3des|aes 128|aes 192|aes 256] [priv-password]
!
NetsTuts-R1(config)#snmp-server user snmpv3user NETSTUTS-V3-GROUP v3 auth sha Auth@NetsTuts2026 priv aes 128 Priv@NetsTuts2026

! ── Verify the user was created ───────────────────────────────────
NetsTuts-R1(config)#end
NetsTuts-R1#show snmp user

User name: snmpv3user
Engine ID: 800000090300C0A80A0164
storage-type: nonvolatile        active
Authentication Protocol: SHA
Privacy Protocol: AES128
Group-name: NETSTUTS-V3-GROUP

Why the SNMPv3 user does not appear in running-config. show running-config will NOT show the snmp-server user command. The user credentials are stored in a separate, non-plaintext SNMP engine database. To verify SNMPv3 users, always use show snmp user. The Engine ID shown in the output is unique to this router and is used as part of the SNMPv3 key derivation process — this is why SNMPv3 users created on one router cannot be copied to another router by simply repeating the command; the derived keys will differ because the Engine ID differs.

Configure SNMPv3 Trap Destination

! ── SNMPv3 trap destination ───────────────────────────────────────
! informs = acknowledged traps (more reliable than traps)
! version 3 priv = use authPriv security level
! snmpv3user = the user credentials to authenticate the inform
NetsTuts-R1(config)#snmp-server host 192.168.10.100 informs version 3 priv snmpv3user

! ── For simple traps (no acknowledgement) instead of informs: ─────
! NetsTuts-R1(config)#snmp-server host 192.168.10.100 traps version 3 priv snmpv3user

! ── Inform retry and timeout settings ─────────────────────────────
! Default: 3 retries, 15-second timeout
NetsTuts-R1(config)#snmp-server engineID local 800000090300C0A80A0164

Traps vs Informs: A trap is UDP fire-and-forget — the agent sends it once and assumes the NMS received it. An inform is an acknowledged trap — the NMS must reply with an InformResponse, and the agent retransmits if no acknowledgement is received within the timeout period. For critical events (link failures, config changes), informs are preferred because missed traps in a congested network would leave the NMS unaware of the event. The trade-off is slightly more agent CPU usage for retransmission tracking.

9. Step 6 — Configure CPU and Interface Threshold Traps

Threshold-based traps fire when a monitored value crosses a defined boundary — providing proactive alerts before problems become outages. CPU and interface error thresholds are the most operationally useful:

! ── CPU threshold trap ────────────────────────────────────────────
! Rising threshold: send trap when 5-min CPU average exceeds 80%
! Falling threshold: send trap when CPU drops back below 60%
! Interval: 5 seconds polling interval for CPU measurement
NetsTuts-R1(config)#process cpu threshold type total rising 80 interval 5 falling 60 interval 5
NetsTuts-R1(config)#snmp-server enable traps cpu threshold

! ── Interface error threshold ─────────────────────────────────────
! Send trap when input error rate on any interface exceeds 500/min
NetsTuts-R1(config)#snmp-server enable traps entity

! ── Memory threshold trap ─────────────────────────────────────────
! Alert when free processor memory drops below 20%
NetsTuts-R1(config)#memory free low-watermark processor 20480

! ── SNMP manager / NMS definition (optional for informs) ─────────
NetsTuts-R1(config)#snmp-server manager
NetsTuts-R1(config)#snmp-server manager retries 3
NetsTuts-R1(config)#snmp-server manager session-timeout 600

process cpu threshold configures the IOS CPU tracking process to trigger SNMP traps when thresholds are crossed. The rising threshold fires once when the value first crosses the boundary upward; it does not retrigger again until the value drops below the falling threshold and then rises again — preventing alert storms. snmp-server manager enables the router to act as an SNMP manager itself (sending Get/Set requests to other devices) in addition to being an agent — needed for inform acknowledgement processing.

10. Step 7 — Complete Configuration and Save

The full SNMP configuration assembled in order, with write memory to persist it:

NetsTuts-R1(config)#end
NetsTuts-R1#show running-config | section snmp

snmp-server engineID local 800000090300C0A80A0164
snmp-server group NETSTUTS-V3-GROUP v3 priv read NETSTUTS-VIEW write NETSTUTS-VIEW access SNMP-ACCESS
snmp-server view NETSTUTS-VIEW internet included
snmp-server contact [email protected]
snmp-server location NetsTuts HQ - Server Room A - Rack 3
snmp-server chassis-id NetsTuts-R1
snmp-server community NetsTuts-RO2026 RO SNMP-ACCESS
snmp-server community NetsTuts-RW2026! RW SNMP-ACCESS
snmp-server trap-source GigabitEthernet0/0
snmp-server source-interface informs GigabitEthernet0/0
snmp-server enable traps snmp authentication linkdown linkup
snmp-server enable traps config
snmp-server enable traps envmon
snmp-server enable traps bgp
snmp-server enable traps ospf
snmp-server enable traps cpu threshold
snmp-server enable traps syslog
snmp-server enable traps entity
snmp-server manager
snmp-server manager retries 3
snmp-server manager session-timeout 600
snmp-server host 192.168.10.100 version 2c NetsTuts-RO2026
snmp-server host 192.168.10.100 informs version 3 priv snmpv3user

NetsTuts-R1#write memory
Building configuration...
[OK]

Note: snmp-server user snmpv3user does not appear in the running-config output. This is expected — verify the user with show snmp user separately. Also note that community strings may appear in the running-config as plain text or as a type 7 encrypted form depending on whether service password-encryption is active — however, type 7 encryption is easily reversible and should not be relied on for security. ACL restriction via SNMP-ACCESS is the real protection for v2c community strings. Save the configuration with write memory. For SNMP-triggered threshold alerting with IP SLA see IP SLA Syslog Alerting.

11. Verification

show snmp

NetsTuts-R1#show snmp

Chassis: NetsTuts-R1
Contact: [email protected]
Location: NetsTuts HQ - Server Room A - Rack 3
0 SNMP packets input
    0 Bad SNMP version errors
    0 Unknown community name
    0 Illegal operation for community name supplied
    0 Encoding errors
    0 Number of requested variables
    0 Number of altered variables
    0 Get-request PDUs
    0 Get-next PDUs
    0 Set-request PDUs
    0 Input queue packet drops (Maximum queue size 1000)
0 SNMP packets output
    0 Too big errors (Maximum packet size 1500)
    0 No such name errors
    0 Bad value errors
    0 General errors
    0 Response PDUs
    0 Trap PDUs

SNMP Dispatcher:
   queue 0/75 (current/max), 0 dropped
SNMP Engine:
   queue 0/1000 (current/max), 0 dropped

SNMP logging: enabled
    Logging to 192.168.10.100.162, 0/10, 0 sent, 0 dropped

After the NMS begins polling, the counters in this output populate: Get-request PDUs increments with each poll cycle, Response PDUs increments with each reply. Unknown community name counter incrementing indicates either a misconfigured NMS (wrong community string) or a scan/probe from an unauthorised host — this counter triggers the snmp authentication trap. Monitor this counter to detect SNMP brute-force scanning.

show snmp community

NetsTuts-R1#show snmp community

Community name: NetsTuts-RO2026
Community Index: cisco0
Community SecurityName: NetsTuts-RO2026
storage-type: nonvolatile       active

Community name: NetsTuts-RW2026!
Community Index: cisco1
Community SecurityName: NetsTuts-RW2026!
storage-type: nonvolatile       active

show snmp group

NetsTuts-R1#show snmp group

groupname: NETSTUTS-V3-GROUP                  security model:v3 priv
readview : NETSTUTS-VIEW                      writeview: NETSTUTS-VIEW
notifyview: *tv.FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
row status: active   access-list: SNMP-ACCESS

groupname: v1default                          security model:v1
readview : *tv.FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF writeview: <no writeview specified>
notifyview: *tv.FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
row status: active

groupname: v2cdefault                         security model:v2c
readview : *tv.FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF writeview: <no writeview specified>
notifyview: *tv.FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
row status: active

The output confirms NETSTUTS-V3-GROUP is configured with security model v3 priv (authPriv), has both read and write views set to NETSTUTS-VIEW, and has the SNMP-ACCESS ACL applied. The v1default and v2cdefault groups are auto-created by IOS and should be noted — they have no ACL restriction and wide-open views. These should be removed in a hardened configuration: no snmp-server group v1default v1 and no snmp-server group v2cdefault v2c.

show snmp user

NetsTuts-R1#show snmp user

User name: snmpv3user
Engine ID: 800000090300C0A80A0164
storage-type: nonvolatile        active
Authentication Protocol: SHA
Privacy Protocol: AES128
Group-name: NETSTUTS-V3-GROUP

show snmp host

NetsTuts-R1#show snmp host

Notification host: 192.168.10.100  udp-port: 162   type: inform
user: snmpv3user   security model: v3 priv

Notification host: 192.168.10.100  udp-port: 162   type: trap
user: NetsTuts-RO2026   security model: v2c

Verifying from the NMS — SNMPv2c Get (Linux/CLI)

! ── SNMPv2c Get from admin PC (snmpget utility) ───────────────────
$ snmpget -v 2c -c NetsTuts-RO2026 192.168.10.1 1.3.6.1.2.1.1.1.0

SNMPv2-MIB::sysDescr.0 = STRING: Cisco IOS Software, Version 15.7(3)M4,
RELEASE SOFTWARE (fc1) Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2019 by Cisco Systems, Inc.

! ── SNMPv2c walk — retrieve all ifDescr values ───────────────────
$ snmpwalk -v 2c -c NetsTuts-RO2026 192.168.10.1 1.3.6.1.2.1.2.2.1.2

IF-MIB::ifDescr.1 = STRING: GigabitEthernet0/0
IF-MIB::ifDescr.2 = STRING: GigabitEthernet0/1
IF-MIB::ifDescr.3 = STRING: GigabitEthernet0/2
IF-MIB::ifDescr.4 = STRING: Loopback0

Verifying from the NMS — SNMPv3 Get (Linux/CLI)

! ── SNMPv3 Get with authPriv ──────────────────────────────────────
$ snmpget -v 3 \
  -u snmpv3user \
  -l authPriv \
  -a SHA \
  -A "Auth@NetsTuts2026" \
  -x AES \
  -X "Priv@NetsTuts2026" \
  192.168.10.1 \
  1.3.6.1.2.1.1.5.0

SNMPv2-MIB::sysName.0 = STRING: NetsTuts-R1

! ── SNMPv3 walk — retrieve sysUpTime ─────────────────────────────
$ snmpget -v 3 -u snmpv3user -l authPriv -a SHA -A "Auth@NetsTuts2026" \
  -x AES -X "Priv@NetsTuts2026" 192.168.10.1 1.3.6.1.2.1.1.3.0

DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (487263) 1:21:12.63

The -l authPriv flag specifies the SNMPv3 security level. -a SHA selects the authentication algorithm, -A provides the auth password, -x AES selects AES encryption, and -X provides the privacy password. These parameters must match exactly what was configured on the router — any mismatch results in an authentication failure (no response from the agent, not an error message). Run debug snmp packet on the router to observe incoming SNMPv3 request processing and diagnose authentication failures.

Verification Command Summary

Command	What It Shows	Key Field to Check
`show snmp`	SNMP packet counters, trap logging destination, queue statistics	Incrementing Get-request and Response PDU counters confirm NMS is polling; "Unknown community name" counter shows auth failures
`show snmp community`	Configured v2c community strings, their access level and storage type	Both communities present with storage-type: nonvolatile and status: active
`show snmp group`	All SNMP groups with security model, views, and ACL assignments	NETSTUTS-V3-GROUP shows "security model: v3 priv", correct views, and access-list: SNMP-ACCESS
`show snmp user`	SNMPv3 users with group membership, auth protocol, privacy protocol, and engine ID	snmpv3user shows Authentication Protocol: SHA and Privacy Protocol: AES128, Group-name: NETSTUTS-V3-GROUP
`show snmp host`	Configured trap/inform destinations with user, security model, and UDP port	Both v2c trap and v3 inform entries for 192.168.10.100 present
`show snmp view`	MIB views with included/excluded OID subtrees	NETSTUTS-VIEW includes the "internet" subtree (1.3.6.1)
`show ip access-lists SNMP-ACCESS`	ACL entries and hit counters	Match counter increments with each SNMP poll from 192.168.10.100 — confirms ACL is functioning
`debug snmp packet`	Real-time SNMP packet processing — requests, responses, authentication checks	Displays incoming OID requests and whether authentication passed or failed. Always disable with `no debug all` after use

12. Using a MIB Browser to Verify SNMP

A MIB browser provides a graphical way to walk the MIB tree, query specific OIDs, and verify that SNMP responses are correct. The procedure below uses MIB Browser Free Tool (iReasoning), which supports both SNMPv2c and SNMPv3:

  ── SNMPv2c Query in iReasoning MIB Browser ──────────────────────

  1. File → Load MIBs → load CISCO-IOS-MIBs (or use bundled standard MIBs)

  2. Address bar: enter 192.168.10.1

  3. Community: NetsTuts-RO2026
     SNMP Version: v2c

  4. In the MIB tree, expand:
       MIB-2 → system → sysDescr
       Right-click → Get
       Result pane shows: "Cisco IOS Software, Version 15.7(3)M4 ..."

  5. For interface counters, expand:
       MIB-2 → interfaces → ifTable → ifEntry → ifInOctets
       Right-click → Walk
       Result: one row per interface showing input byte counters

  ── SNMPv3 Query in iReasoning MIB Browser ───────────────────────

  1. Edit → Preferences → SNMP Settings

  2. SNMP Version: v3
     Security Level: authPriv
     User Name:      snmpv3user
     Auth Protocol:  SHA
     Auth Password:  Auth@NetsTuts2026
     Priv Protocol:  AES
     Priv Password:  Priv@NetsTuts2026

  3. Click OK. Run a Get on sysName (1.3.6.1.2.1.1.5.0)
     Result: "NetsTuts-R1"

  4. Run a MIB Walk from the root to discover all accessible OIDs
     Operations → Walk → starting OID: 1.3.6.1
     MIB browser populates the tree with all available objects

Common OID to Test	MIB Path	Expected Result
`1.3.6.1.2.1.1.1.0`	MIB-2 → system → sysDescr	IOS version string including model and software version
`1.3.6.1.2.1.1.3.0`	MIB-2 → system → sysUpTime	Time in hundredths of a second since last reload
`1.3.6.1.2.1.1.4.0`	MIB-2 → system → sysContact	"[email protected]" — confirms contact was set
`1.3.6.1.2.1.1.5.0`	MIB-2 → system → sysName	"NetsTuts-R1" — confirms hostname
`1.3.6.1.2.1.1.6.0`	MIB-2 → system → sysLocation	"NetsTuts HQ - Server Room A - Rack 3"
`1.3.6.1.2.1.2.1.0`	MIB-2 → interfaces → ifNumber	Number of interfaces (e.g., 4)
`1.3.6.1.4.1.9.2.1.57.0`	Cisco → local → cpu → avgBusy5	5-minute CPU average as a percentage integer (e.g., 3)

Triggering a test trap from IOS. To verify the NMS is receiving traps without waiting for a real event, use: NetsTuts-R1# snmp-server host 192.168.10.100 version 2c NetsTuts-RO2026 then manually generate a link event by administratively shutting and re-enabling an interface: interface Gi0/1 → shutdown → no shutdown. A linkDown and linkUp trap pair will be sent to the NMS. Confirm receipt in the NMS trap log or with show snmp counter increments.

13. Troubleshooting SNMP Issues

Problem	Symptom	Cause	Fix
NMS receives no response to SNMPv2c Get	MIB browser shows "Request timed out" or "No response" for every OID query against the router	Community string mismatch, ACL blocking the NMS IP, SNMP not enabled (no `snmp-server community` command), or a firewall/ACL on the path blocking UDP/161	Verify community string: `show snmp community`. Check ACL hit counter: `show ip access-lists SNMP-ACCESS` — if it does not increment when the NMS queries, the traffic is not arriving. Enable debug: `debug snmp packet` to observe incoming requests. Check interface ACLs blocking UDP/161 with `show ip interface Gi0/0`. Check syslog for related messages with `show logging`.
SNMPv3 Get returns no response or authentication failure	SNMPv3 queries from the NMS produce no response. `show snmp` shows incrementing "Bad SNMP version errors" or the NMS log shows authentication failure	Auth or privacy password mismatch between NMS configuration and router, wrong security level specified by the NMS (e.g., NMS sends authNoPriv but group requires priv), or the SNMPv3 user was created before the group it references	Verify user exists: `show snmp user`. Confirm auth and priv protocols match what the NMS is configured to use. Verify group security level: `show snmp group` — must show "v3 priv". Re-enter the user: `no snmp-server user snmpv3user` then recreate. Run `debug snmp packet` for detailed per-request failure reason.
NMS not receiving traps after interface shutdown	An interface goes down on the router but no linkDown trap appears at the NMS. `show snmp host` shows the trap destination is configured	Trap type not enabled (`snmp-server enable traps snmp linkdown` missing), trap-source interface is down so traps cannot leave, or a firewall is blocking UDP/162 outbound to the NMS	Verify trap types: `show running-config \| include snmp-server enable traps` — confirm "linkdown linkup" is listed. Check the trap-source interface is up: if using Gi0/0 as trap-source and Gi0/0 is the affected interface, traps cannot use it. Use a Loopback as trap-source instead. Check path: `ping 192.168.10.100` from the router. Verify UDP/162 is not blocked on any ACL between R1 and the NMS.
"Unknown community name" counter incrementing	`show snmp` shows the "Unknown community name" counter increasing. Authentication failure traps may be firing to the NMS	An NMS or monitoring tool is sending SNMPv2c queries with the wrong community string — either a misconfigured NMS, a legacy tool using the default "public" community, or a network scanner probing for SNMP	Enable `debug snmp packet` briefly to identify the source IP of the bad community requests. Check if a legitimate NMS is misconfigured with the old community string. If the source is unknown, review `show ip access-lists SNMP-ACCESS` to confirm the ACL is rejecting the source. Consider adding an explicit `deny any log` to SNMP-ACCESS to log rejected SNMP attempts to syslog.
SNMPv3 user not visible in running-config after save	After `write memory` and reload, `show running-config` does not show the `snmp-server user` command. Administrator thinks the user was lost	This is expected IOS behaviour. SNMPv3 user credentials are stored in the SNMP engine database, not in the plain-text running-config. The user persists across reloads but will not appear in `show running-config`	Verify with `show snmp user` — if the user is listed there, it is correctly configured and will survive a reload. Do not re-enter the user command thinking it was lost — this recreates it unnecessarily and may cause the NMS to experience authentication failures if the engine ID changes.
v1default and v2cdefault groups present with no ACL	`show snmp group` shows default groups with no access-list — any source can query using a compatible community string	IOS auto-creates v1default and v2cdefault groups on SNMP enablement. They have no view restriction or ACL by default and are mapped to the "public" view internally	Remove the default groups: `no snmp-server group v1default v1` and `no snmp-server group v2cdefault v2c`. Also explicitly disable SNMPv1: `no snmp-server community public` and `no snmp-server community private` if those default community strings were created. Verify with `show snmp group` that only NETSTUTS-V3-GROUP and the v2c communities remain.

Key Points & Exam Tips

SNMP has three versions. SNMPv1 and v2c use plain-text community strings for authentication — transmitted unencrypted in every packet. SNMPv3 adds per-user HMAC authentication (SHA or MD5) and optional AES encryption. For any security-sensitive environment, SNMPv3 with authPriv is the only acceptable choice.
SNMP uses UDP/161 for queries (NMS polls the agent) and UDP/162 for traps and informs (agent alerts the NMS). Both ports must be permitted on any firewall or ACL between the NMS and managed devices.
An SNMP ACL on the snmp-server community command restricts which source IPs can query the agent — regardless of which interface the query arrives on. Always use an ACL to restrict SNMP access to the NMS IP only. Never use default community strings (public / private).
SNMPv3 configuration follows the View → Group → User hierarchy: a view defines accessible OIDs, a group links a security level (noauth/auth/priv) to a view, and a user carries the authentication credentials and is assigned to a group.
The snmp-server user command does not appear in the running-config. SNMPv3 user credentials are stored in the SNMP engine database. Always verify with show snmp user.
Traps are fire-and-forget UDP notifications from agent to NMS. Informs are acknowledged — the NMS must reply with InformResponse, and the agent retransmits if no reply is received. Use informs for critical events where delivery confirmation matters.
The snmp-server trap-source command pins outbound trap packets to a specific interface IP. Use a Loopback interface as the trap source in production — loopbacks remain up even when physical interfaces fail, ensuring traps continue to flow during partial network failures.
SNMPv2c adds GetBulk and 64-bit counters (Counter64) to SNMPv1. Counter64 is critical for high-speed interfaces: a 32-bit counter wraps around (rolls over to zero) at approximately 4 GB of data — at 1 Gbps, this happens every 34 seconds, making the counter useless for accurate traffic measurement.
IOS auto-creates v1default and v2cdefault SNMP groups with no ACL restriction. These should be removed in hardened configurations: no snmp-server group v1default v1.
On the CCNA exam: know the SNMP component roles (agent/NMS/MIB), UDP ports 161/162, the v1/v2c/v3 security differences, SNMPv3 security levels (noAuthNoPriv/authNoPriv/authPriv), the difference between a trap and an inform, community string syntax (RO vs RW), and the show snmp / show snmp user verification commands.

Next Steps: SNMP monitoring is now configured for both legacy v2c and secure v3 access. The next complementary monitoring layer is syslog — which sends event log messages from the router to a centralised log server for audit trails and troubleshooting. See Syslog Configuration. For NTP time-stamping that makes SNMP trap timestamps and syslog messages accurate, ensure NTP Configuration is complete. For the ACL fundamentals behind the SNMP-ACCESS restriction, revisit Standard ACL Configuration. For securing the management plane alongside SNMP, see AAA TACACS+ Configuration, AAA RADIUS Configuration, and Login Security and Brute-Force Protection. For flow-based traffic monitoring complement to SNMP see NetFlow Configuration.

TEST WHAT YOU LEARNED

1. A network administrator configures SNMPv2c with community string "NetsTuts-RO2026" and restricts access with an ACL permitting only 192.168.10.100. An attacker at 192.168.10.200 captures network traffic and reads the community string from a UDP/161 packet. What can the attacker do with this information, and what does this illustrate about SNMPv2c?

A. Nothing — the ACL prevents any host other than 192.168.10.100 from using the community string, so capturing it provides no actionable capability B. The attacker can use the community string from a spoofed source IP of 192.168.10.100 to query the router, or they may be able to exploit it if ACL enforcement is bypassed. More broadly, this illustrates the core weakness of SNMPv2c: community strings are transmitted in plain text in every packet, making them trivially readable by anyone on the network path. SNMPv3 with authPriv encrypts the entire PDU, making captured traffic useless to an attacker C. The attacker can use the community string but only for SNMPv1 queries, not v2c — v2c community strings are hashed before transmission D. The attacker cannot use the community string because it was configured as RO (read-only), which disables all query types by default for non-NMS hosts

Correct answer is B. SNMPv2c community strings are transmitted in the clear — they appear as plain ASCII text in the UDP payload of every SNMP packet. Any device on the network path (router, switch, mirror port, tapped cable) that captures traffic can read the string from a Wireshark packet capture in seconds. The ACL restricts which source IPs the agent will respond to, but if the attacker can spoof the NMS IP (192.168.10.100) on the same VLAN, the ACL offers little protection. More critically, on an unencrypted network segment, the attacker doesn't even need to spoof — they could position a rogue device on the management VLAN. This is why SNMPv2c community strings should never be considered passwords and why SNMPv3 authPriv is the production standard. With authPriv, the entire PDU including OID values and community identity is AES-encrypted — a captured packet reveals nothing useful.

2. After configuring SNMPv3 with `snmp-server user snmpv3user NETSTUTS-V3-GROUP v3 auth sha Auth@NetsTuts2026 priv aes 128 Priv@NetsTuts2026`, the administrator runs `show running-config` and cannot find the user command. Has the configuration been lost?

A. Yes — the write memory command must be run immediately after the user command to persist it to NVRAM, otherwise it is held only in volatile SNMP memory and is not saved to the startup-config B. Yes — IOS requires the user command to be re-entered after every reload; SNMPv3 users are session-based and do not persist in the configuration C. No, but the user must be re-entered using the nonvolatile keyword to be stored persistently: snmp-server user snmpv3user ... nonvolatile D. No — this is expected IOS behaviour. SNMPv3 user credentials are stored in the SNMP engine database, not in the plain-text running-config or startup-config. The user persists across reloads. Always use show snmp user (not show running-config) to verify SNMPv3 users are present and correctly configured

Correct answer is D. This is a well-known IOS behaviour that surprises many administrators. The snmp-server user command configures credentials that are stored in a separate SNMP engine database maintained by IOS. This database is persisted across reloads independently from the startup-config. The reason it does not appear in the running-config is related to security — storing hashed or derivable key material in the plain-text config file would expose it. The user entry is shown only by show snmp user, which displays the username, group membership, auth protocol, privacy protocol, storage type (nonvolatile confirms it is persistent), and the engine ID it is bound to. The storage-type: nonvolatile active in the output of show snmp user confirms the user will survive a reload. Do not re-enter the user command unnecessarily, as changing the engine ID or recreating users can cause temporary authentication failures at the NMS.

3. What is the difference between an SNMP trap and an SNMP inform, and in what scenario should informs be preferred over traps?

A. A trap is a fire-and-forget UDP notification — the agent sends it once with no acknowledgement and no retransmission if lost. An inform requires the NMS to send an InformResponse acknowledgement; if the agent receives no acknowledgement within the timeout period, it retransmits. Informs are preferred for critical events (link failures, authentication failures, config changes) where missing the notification would leave the NMS with an inaccurate view of network state B. A trap uses TCP for reliable delivery while an inform uses UDP — the difference is the transport protocol, not the acknowledgement mechanism C. Traps are supported by all SNMP versions while informs are SNMPv3-only. The primary difference is that informs carry encryption and traps do not D. There is no functional difference in delivery reliability — both use the same retransmission mechanism. The difference is that informs carry a timestamp while traps do not

Correct answer is A. Both traps and informs use UDP (unreliable, connectionless). The reliability difference is at the SNMP application layer. A trap is sent once — the agent fires the notification and immediately forgets about it. If the UDP packet is dropped in transit (congested link, buffer overflow on a switch), the NMS never receives the notification and has no way to know it happened. An inform includes a PDU ID and the agent maintains a retransmission buffer. The NMS must respond with a GetResponse PDU containing the same PDU ID to acknowledge receipt. If the agent receives no acknowledgement within the configured timeout (default: 15 seconds), it retransmits. After the configured maximum retries (default: 3), the agent gives up and logs the unacknowledged inform. Informs also have higher overhead: each retransmission consumes agent CPU and memory, and the NMS must process acknowledgements. The practical recommendation is: use informs for high-priority events (bgp state change, config change, authentication failure) and traps for high-frequency, lower-priority events (CPU polling, interface statistics) where an occasional missed notification is acceptable.

4. An administrator needs to give the NMS read access to interface statistics (ifTable) but must prevent it from reading routing table information (ipRouteTable). How is this implemented in SNMPv3?

A. Apply an extended ACL to the snmp-server group command that permits the ifTable OID range and denies the ipRouteTable OID range B. Configure the SNMPv3 user with the read-only keyword followed by the permitted OID subtree — SNMPv3 user definitions include per-user OID scope restrictions C. Create an SNMP view using snmp-server view with specific included and excluded statements for the relevant OID subtrees. Assign this restricted view as the read view on the SNMPv3 group. The group then grants access only to OIDs defined in the view: snmp-server view RESTRICTED-VIEW 1.3.6.1.2.1.2 included (interfaces) with 1.3.6.1.2.1.4.21 excluded (routing table) D. Restrict OID access using a numbered standard ACL on the SNMP agent interface with source = NMS and destination = the OID subnet range

Correct answer is C. SNMP views are the mechanism for OID-level access control. A view is a named list of OID subtrees that are included or excluded from access. The snmp-server view [VIEW-NAME] [OID-subtree] included/excluded command builds the view incrementally — multiple lines are needed to build a complex view. For example: snmp-server view RESTRICTED-VIEW 1.3.6.1.2.1.2 included includes the entire interfaces MIB subtree (ifTable). snmp-server view RESTRICTED-VIEW 1.3.6.1.2.1.4.21 excluded then explicitly excludes the ipRouteTable OID subtree. The view is then assigned as the read view on the SNMPv3 group: snmp-server group NETSTUTS-V3-GROUP v3 priv read RESTRICTED-VIEW. Any NMS query for an OID not in the view receives an "No such name" or "Not in view" error. This provides fine-grained access control without requiring firewall rules or per-OID ACLs — the view enforcement is done entirely within the SNMP agent on the router.

5. A router's Gi0/0 is configured as both the management interface and the SNMP trap-source. Gi0/0 goes down due to a cable failure. What happens to SNMP trap notifications during the outage, and how should the configuration be improved?

A. Traps continue flowing because the router automatically switches to the next available interface as the trap source when the configured source is down B. The SNMP agent detects the interface failure and increases the trap retransmission rate to ensure the NMS receives the notification before the interface goes fully down C. Traps are queued locally on the router and transmitted automatically once the interface recovers — no configuration change is needed D. When the configured trap-source interface goes down, the router has no source IP to originate traps from and stops sending them. The linkDown trap for Gi0/0 itself is lost since the interface cannot transmit. The fix is to use a Loopback interface as the trap source: snmp-server trap-source Loopback0. Loopback interfaces are always up as long as the router is running, ensuring trap delivery survives any physical interface failure

Correct answer is D. This is a classic operational problem. When snmp-server trap-source GigabitEthernet0/0 is configured and Gi0/0 goes down, the router loses the source IP for outbound SNMP trap packets. The router requires a valid, up interface with an IP address to originate any IP packet. If the only configured source IP (Gi0/0) is down, the trap cannot be sent. This creates a catch-22 for linkDown events: the event you most want to know about (interface failure) is exactly the event that prevents the notification from being sent. The standard solution is a Loopback interface. A Loopback interface never has a physical carrier to fail — it stays up as long as the router's IOS process is running. Configure: interface Loopback0 → ip address 10.255.255.1 255.255.255.255, then snmp-server trap-source Loopback0. The Loopback IP must be reachable from the NMS — ensure it is advertised via the routing protocol (OSPF, EIGRP) or via static route at the NMS. This same principle applies to syslog source interfaces and NTP.

6. What does the SNMPv2c Counter64 data type resolve that was a limitation of SNMPv1, and why does this matter for a 10 Gbps interface?

A. Counter64 extends the SNMP community string length from 32 characters to 64, allowing stronger passphrases for v2c deployments B. SNMPv1 uses 32-bit counters (Counter32) that hold a maximum value of approximately 4.29 billion (2³²). At 10 Gbps, this counter wraps around (resets to zero) in about 3.4 seconds. When the NMS polls every 5 minutes, multiple wrap-arounds have occurred — making traffic rate calculations completely inaccurate. Counter64 holds up to 18.4 × 10¹⁸ and wraps only after years at 100 Gbps — fully adequate for modern high-speed interfaces C. Counter64 allows SNMP OID values to be encoded in 64-bit binary, doubling the number of addressable objects in the MIB tree compared to SNMPv1's 32-bit OID addressing D. Counter64 doubles the SNMP PDU size limit from 1500 to 3000 bytes, allowing the NMS to retrieve more OIDs per GetBulk request without fragmentation

Correct answer is B. Counter32 maximum = 4,294,967,295 bytes (≈ 4 GB). At 10 Gbps = 1,250,000,000 bytes/second, the counter rolls over in 4,294,967,295 / 1,250,000,000 = 3.44 seconds. At 100 Gbps, it wraps every 0.34 seconds. An NMS polling every 5 minutes would observe the counter having wrapped hundreds of times. The NMS cannot determine how many times the rollover occurred and therefore cannot compute an accurate traffic rate. With Counter64 (2⁶⁴ = 18.4 × 10¹⁸), a 100 Gbps interface takes 18.4 × 10¹⁸ / 12,500,000,000 = approximately 46,000 years to wrap. SNMPv2c introduced the ifHCInOctets and ifHCOutOctets OIDs (HC = High Capacity, Counter64) specifically for this purpose. High-capacity (HC) interface counters should always be used on interfaces operating above 100 Mbps. MIB-II's original 32-bit ifInOctets/ifOutOctets remain available for compatibility but are unreliable for fast interfaces.

7. `show snmp group` on a newly configured router shows `v1default` and `v2cdefault` groups with no access-list applied. Why is this a security concern, and what should be done?

A. These groups are internal to IOS and cannot be removed or exploited — they have no community string association and are inaccessible from the network B. These groups represent SNMPv3 users that IOS creates by default — they should be given strong passwords to prevent anonymous access C. The default groups have no ACL restriction and map to a broad view of the MIB. Any host that sends an SNMPv1 or SNMPv2c packet with a community string that maps to these groups can query the agent without IP restriction. They should be removed with no snmp-server group v1default v1 and no snmp-server group v2cdefault v2c, and default community strings public and private should also be explicitly removed D. The v1default and v2cdefault groups are placeholders only and are never associated with actual community strings unless an administrator explicitly assigns them — they pose no security risk in their default state

Correct answer is C. IOS automatically creates v1default and v2cdefault groups when SNMP is first enabled. These groups have no ACL, giving them open access to the full MIB view from any source IP. Additionally, many IOS versions ship with default community strings "public" (read-only) and "private" (read-write) pre-configured or easily exploitable. A network scanner using the "public" community string against 192.168.10.1 would receive a valid SNMP response from the v2cdefault group, revealing the full MIB including interface configurations, routing table contents, and system details. The hardening steps are: (1) no snmp-server community public and no snmp-server community private to remove default community strings. (2) no snmp-server group v1default v1 and no snmp-server group v2cdefault v2c to remove the unrestricted default groups. (3) Confirm with show snmp group that only the intentionally configured groups with ACL restrictions remain. This is a standard IOS SNMP hardening step included in the Cisco Security Configuration Guide.

8. The NMS administrator reports that SNMP traps are occasionally missing during periods of high network utilisation, particularly for config-change events. Traps are currently configured with `snmp-server host 192.168.10.100 version 2c NetsTuts-RO2026`. What change improves reliability for these critical events?

A. Change the trap destination to use informs instead of traps: snmp-server host 192.168.10.100 informs version 2c NetsTuts-RO2026. Informs require the NMS to send an acknowledgement (InformResponse). If the inform is dropped, the agent retransmits up to the configured retry count. This provides guaranteed delivery for critical events at the cost of slightly higher agent overhead B. Increase the trap UDP packet size limit with snmp-server packetsize 8192 so that trap packets are less likely to be dropped in favour of smaller packets during congestion C. Configure a secondary trap destination with the same community string — the agent will send to both destinations simultaneously, doubling the probability of at least one copy being received D. Upgrade to SNMPv3 traps — v3 traps use TCP instead of UDP and therefore provide built-in retransmission through TCP's reliability mechanism

Correct answer is A. This is the precise use case for SNMP informs. During high network utilisation, UDP packets (including SNMP traps) can be dropped by overloaded switch buffers or router queues. A trap is fire-and-forget — when it is dropped, neither the agent nor the NMS knows the event was missed. The NMS log shows no record of the config change, creating a dangerous monitoring gap. Switching to informs: snmp-server host 192.168.10.100 informs version 2c NetsTuts-RO2026 enables the acknowledgement mechanism. The agent keeps the inform in a retransmission queue until the NMS acknowledges it with InformResponse or until the retry limit is exhausted. Default retransmit settings can be tuned: snmp-server manager retries [n] and snmp-server manager session-timeout [seconds]. Note that SNMPv3 informs (answer D is incorrect about TCP — all SNMP uses UDP regardless of version) still use UDP but with the same acknowledgement mechanism at the application layer. The upgrade to informs does add moderate agent memory overhead since unacknowledged informs must be buffered for retransmission.

9. An administrator configures the SNMPv3 group before the view it references: `snmp-server group NETSTUTS-V3-GROUP v3 priv read NETSTUTS-VIEW` followed by `snmp-server view NETSTUTS-VIEW internet included`. Then the user is created. SNMPv3 queries return "No such name" for all OIDs. What is the likely cause?

A. The view name must match the group name exactly — using NETSTUTS-VIEW as a view and NETSTUTS-V3-GROUP as a group causes a name conflict that disables read access B. The internet keyword in the view is invalid for SNMPv3 — the full OID 1.3.6.1 must be specified numerically: snmp-server view NETSTUTS-VIEW 1.3.6.1 included C. The order of configuration is the problem — the view must be defined before the group. When the group was configured before the view existed, IOS created the group with a null read view. Removing and recreating the group after the view is defined resolves the issue D. In this scenario the configuration order is acceptable since IOS resolves view references dynamically. However, "No such name" for all OIDs indicates the write view was omitted — when a group has no read view explicitly assigned (or the view was empty when the group was created), queries succeed at the SNMP level but return "no such name" because the agent applies an empty view. Alternatively, the ACL may be blocking the query source. Verify with show snmp group that NETSTUTS-VIEW appears as the readview and show ip access-lists SNMP-ACCESS that the NMS source is permitted

Correct answer is D. "No such name" in SNMPv3 (technically "noSuchObject" or "noSuchInstance") means the SNMP query reached the agent and was authenticated, but the requested OID is not accessible in the view assigned to the user's group. The most common causes: (1) The read view assigned to the group is empty or incorrectly named — verify with show snmp group that "readview: NETSTUTS-VIEW" appears and not "readview: <no readview specified>". (2) The view itself was incorrectly created — verify with show snmp view that NETSTUTS-VIEW includes the internet (1.3.6.1) subtree. (3) The ACL is blocking the source — verify with show ip access-lists SNMP-ACCESS that the querying IP is permitted and the match counter increments. (4) A common gotcha: after fixing the view or group, the SNMPv3 user may need to be re-created for the group association to pick up the new view assignment. Run no snmp-server user snmpv3user NETSTUTS-V3-GROUP v3 then recreate the user.

10. A Cisco router connects two sites over a WAN. The router has Gi0/0 (LAN, 192.168.10.1) and Serial0/0/0 (WAN, 10.1.1.1). The NMS is at 192.168.10.100. SNMP is configured with trap-source GigabitEthernet0/0. The Serial WAN link fails. Which of the following is true about SNMP trap delivery in this scenario?

A. No traps are sent because the SNMP agent requires a WAN connection to reach the NMS whenever a WAN interface fails B. The router automatically generates a trap for the Serial0/0/0 linkDown event, but the trap is sent out Gi0/0 using its IP as the source — this configuration is correct and no changes are needed C. Traps for the Serial0/0/0 linkDown event are successfully sent out Gi0/0 (192.168.10.1) to the NMS because the trap-source is Gi0/0 which is still up. The NMS receives the linkDown notification correctly. This is the correct behaviour — the trap-source is the originating IP of the trap, not the interface through which the event occurred. The LAN path to the NMS remains intact and the trap is delivered normally D. IOS delays the Serial linkDown trap by 30 seconds to allow the WAN link to recover before alerting the NMS — this prevents false-positive notifications during brief WAN flaps

Correct answer is C. This scenario tests understanding of what snmp-server trap-source actually controls. The trap-source sets the source IP address placed in the UDP packet header when the router originates a trap — it is not the interface that must be up for the event to trigger a trap, nor is it the interface the trap exits through. When Serial0/0/0 goes down, IOS generates a linkDown notification for that interface. The router then creates the trap UDP packet, sources it from Gi0/0's IP (192.168.10.1), and routes it to 192.168.10.100 (the NMS) using the best available path — which is Gi0/0 since the LAN is intact. The NMS receives the trap reporting a linkDown on Serial0/0/0, sourced from 192.168.10.1. This is the desired behaviour. The concern arises only when the trap-source interface itself fails (e.g., the Gi0/0 LAN link goes down) — then the trap has no source IP and cannot be sent. That is why Loopback0 is the recommended trap-source for production routers with multiple physical interfaces.

Back to Home