Hands-On Lab: Configuring SNMPv3

This hands-on lab configures SNMPv3 with full authentication and encryption on a router, verifying successful polling using proper credentials and confirming an SNMPv2c-style plaintext community string no longer works at all, addressing the security gap identified in an earlier SNMP lab.

SNMPv3 ConfigurationauthPriv Security LevelUSM Group and User

~3 min read · Updated Sep 26, 2026

Lab Objective

Configure SNMPv3 with a user requiring both authentication and encryption, verify a management station can successfully poll the device using the correct credentials, and confirm the vulnerability identified in an earlier SNMPv2c lab — plaintext community strings — no longer applies.

Lab Purpose

The SNMPv2c lab covered earlier in this series specifically noted that its community string travels in plaintext, vulnerable to interception, and recommended SNMPv3 wherever genuine security matters. This lab implements that recommendation directly, configuring SNMPv3's User-based Security Model (USM) with authPriv, the highest security level combining both authentication and encryption.

Lab Topology

R1 ---- Gi0/0: 192.168.95.1/24

SNMP management station: 192.168.95.50/24
(same topology as the earlier SNMPv2c lab)

Task 1: Create an SNMPv3 Group with authPriv Security

Configure an SNMP group requiring authentication and privacy (encryption).

Task 2: Create an SNMPv3 User in That Group

Configure a user with SHA authentication and AES encryption, assigned to the group.

Task 3: Verify SNMPv3 Polling Succeeds with Correct Credentials

From the management station, poll R1 using the correct SNMPv3 username, authentication password, and encryption password.

Task 4: Verify Polling Fails with an Incorrect Authentication Password

Attempt to poll using the correct username but a wrong authentication password and confirm it is rejected.

Task 5: Confirm Plaintext SNMPv2c Access No Longer Works

Remove the SNMPv2c community string from the previous lab and confirm SNMPv2c-style polling now fails entirely.

Solution and Verification

R1(config)# snmp-server group SECURE-GROUP v3 priv

-- "v3 priv" specifies SNMPv3 with the
-- authPriv security level -- both
-- authentication and encryption required,
-- the strongest of SNMPv3's three levels
-- (noAuthNoPriv, authNoPriv, authPriv)

R1(config)# snmp-server user secureadmin SECURE-GROUP v3 auth sha AuthPass2026 priv aes 128 PrivPass2026

-- SHA for authentication integrity, AES
-- for encrypting the actual SNMP payload --
-- a stark contrast to SNMPv2c's single
-- plaintext community string

ManagementStation> snmpget -v3 -u secureadmin -l authPriv \
  -a SHA -A AuthPass2026 -x AES -X PrivPass2026 \
  192.168.95.1 sysDescr.0

SNMPv2-MIB::sysDescr.0 = STRING: Cisco IOS Software, ...
-- Successful poll, with the SNMP payload
-- itself now encrypted in transit, unlike
-- the earlier SNMPv2c lab

ManagementStation> snmpget -v3 -u secureadmin -l authPriv \
  -a SHA -A WrongPassword999 -x AES -X PrivPass2026 \
  192.168.95.1 sysDescr.0

Authentication failure (incorrect password, community
or key)
-- Rejected immediately -- the authentication
-- check fails before any data would even
-- be considered for release

R1(config)# no snmp-server community ReadOnlyStr123 RO 30

ManagementStation> snmpget -v2c -c ReadOnlyStr123 192.168.95.1 sysDescr.0

Timeout: No Response from 192.168.95.1
-- SNMPv2c access is now completely gone --
-- the community string configured in the
-- earlier lab no longer exists, and only
-- the properly authenticated and encrypted
-- SNMPv3 path remains functional

Key Takeaway

SNMPv3's authPriv level directly closes the plaintext exposure inherent to SNMPv2c's community string, discussed as a known limitation in the earlier SNMP lab — both the authentication credential and the actual polled data travel encrypted, and unlike an ACL restriction which only limits which hosts can attempt access, SNMPv3 ensures that even a host on the permitted list cannot succeed without presenting genuinely correct cryptographic credentials.

Written & researched by Dr. Shahin Siami

Related Articles

Hands-On Lab: Configuring EIGRP Stub Routing

This hands-on lab configures a branch router as an EIGRP stub, verifying it advertises only its own connected and summary routes while the hub router correctly avoids querying the stub during a topology change elsewhere in the network.

Continue

Hands-On Lab: Configuring EIGRP Named Mode

This hands-on lab reconfigures a classic EIGRP setup into EIGRP named mode, organizing address-family and interface-specific configuration into a more structured hierarchy, and verifies functional equivalence with the classic configuration style used throughout earlier EIGRP labs in this series.

Continue

Hands-On Lab: Configuring ERSPAN Across a Routed Network

This hands-on lab configures Encapsulated RSPAN (ERSPAN) to mirror traffic across a Layer 3-routed network rather than a single Layer 2 trunk, extending the RSPAN concept from the previous lab beyond the boundaries of a single VLAN or switched domain.

Continue

Hands-On Lab: Configuring RSPAN Across Switches

This hands-on lab configures Remote SPAN (RSPAN) using a dedicated RSPAN VLAN carried across a trunk, allowing traffic mirrored on one switch to be monitored by a capture device connected to an entirely different switch, extending the local SPAN concept covered in an earlier lab across the network.

Continue

Hands-On Lab: Configuring In-Service Software Upgrade (ISSU) on a Stack

This hands-on lab performs an In-Service Software Upgrade across a StackWise stack, upgrading each member's IOS image one at a time while the stack continues forwarding traffic throughout, verifying zero downtime compared to the disruptive reload approach used in earlier IOS upgrade labs.

Continue

Hands-On Lab: Configuring Cisco Catalyst StackWise Traditional Stacking

This hands-on lab configures traditional Catalyst stacking (StackWise) across three switches using stack cables, contrasting its single-tier, chassis-proximity requirement against the StackWise Virtual pair covered in the previous lab, which allows switches to be located much farther apart.

Continue