LogoفارسیFA

Hands-On Lab: Configuring SNMP

This hands-on lab configures SNMPv2c on a router with a read-only community string, verifies a management station can successfully poll device information, and covers why SNMPv3 is preferred for production environments requiring authentication and encryption.

SNMP Community StringSNMPv2c ConfigurationSNMPv3 Security

~3 min read · Updated Sep 23, 2026

Lab Objective

Configure SNMPv2c on a router with a read-only community string, verify an SNMP management station can successfully retrieve device information, and understand why SNMPv3 is the more secure alternative for production use.

Lab Purpose

SNMP allows a centralized management platform to poll device status (interface counters, CPU utilization, memory) without an administrator manually logging into every device individually. SNMPv2c remains common for its simplicity, but its community string is transmitted in plaintext, making SNMPv3 the appropriate choice wherever genuine security matters.

Lab Topology

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

SNMP management station: 192.168.95.50/24

Task 1: Configure Basic Addressing

Configure R1's interface connecting to the management segment.

Task 2: Configure a Read-Only SNMP Community String

Configure SNMPv2c with a read-only community string.

Task 3: Restrict SNMP Access to the Management Station

Apply an ACL to the SNMP community configuration so only the designated management station can poll the device.

Task 4: Verify SNMP Polling Succeeds

From the management station, poll R1's system description using the configured community string.

Task 5: Verify Unauthorized Polling Fails

Attempt to poll R1 from an unauthorized host and confirm it is rejected.

Solution and Verification

R1(config)# interface gigabitethernet0/0
R1(config-if)# ip address 192.168.95.1 255.255.255.0
R1(config-if)# no shutdown

R1(config)# access-list 30 permit 192.168.95.50

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

-- "RO" specifies read-only access -- this
-- community string can retrieve information
-- but cannot change any device configuration

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

SNMPv2-MIB::sysDescr.0 = STRING: Cisco IOS Software, ...
-- Successful poll from the authorized station

UnauthorizedHost (192.168.95.99)> snmpget -v2c -c ReadOnlyStr123 192.168.95.1 sysDescr.0

Timeout: No Response from 192.168.95.1
-- The ACL blocks this host from querying
-- R1 at all, even with the correct community
-- string -- the ACL restriction is enforced
-- independently of the community string itself

Key Takeaway

SNMPv2c's community string functions essentially as a shared password transmitted entirely in plaintext across the network, making it vulnerable to interception — while an ACL restriction like the one configured here adds a meaningful layer of protection by limiting which hosts can even attempt to query the device, SNMPv3 remains the recommended choice wherever genuine authentication and encryption are required, since it eliminates this plaintext exposure entirely.

Written & researched by Dr. Shahin Siami

Related Articles

Hands-On Lab: Configuring OSPF Virtual Links

This hands-on lab connects a disconnected area to the backbone using an OSPF virtual link, addressing a design violation where an area does not have a direct physical connection to Area 0, and verifies routes flow correctly once the virtual link is established.

Continue

Hands-On Lab: Configuring an OSPF NSSA Area

This hands-on lab configures Area 1 as an NSSA, redistributing a local external route directly from within that area and verifying it propagates as a Type 7 LSA before being translated to Type 5 at the ABR, while inter-area routes from elsewhere remain blocked exactly as in a standard stub area.

Continue

Hands-On Lab: Configuring OSPF Stub and Totally Stubby Areas

This hands-on lab configures a leaf area as a standard stub area, then upgrades it to a totally stubby area, comparing the routing table size at each stage and verifying only a default route remains once fully configured.

Continue

Hands-On Lab: Configuring Multi-Area OSPF with Route Summarization

This hands-on lab configures multi-area OSPF across three routers, designating an ABR that summarizes several subnets from a leaf area into a single route advertised toward the backbone, tying together the area design and summarization concepts covered earlier in this series.

Continue

Hands-On Lab: Configuring EIGRP for IPv6

This hands-on lab configures EIGRP for IPv6 between two routers, activating the protocol directly on each interface similar to OSPFv3's approach, and highlights the mandatory router ID requirement unique to EIGRPv6.

Continue

Hands-On Lab: Configuring OSPFv3 for IPv6

This hands-on lab configures OSPFv3 between two routers to dynamically route IPv6 traffic, comparing its configuration syntax against the OSPFv2 labs covered earlier in this series while highlighting the interface-level activation approach OSPFv3 uses.

Continue
Previous ArticleNext Article