Skip to content

SNMP

SNMP (Simple Network Management Protocol) lets a monitoring system query devices for status (interface counters, CPU, temperature) and receive alerts (traps) when something goes wrong — without needing to log into each device individually.

Versions

Version Security Notes
v1 / v2c Community-string based — sent in plaintext Simple, widely supported, but the "password" (community string) is visible to anyone sniffing the traffic
v3 Username/password with authentication and optional encryption The only version that should be used if SNMP crosses any network segment you don't fully trust

Never leave default community strings in place. public (read-only) and private (read-write) are the well-known defaults on essentially every vendor's gear — an unchanged default is a standing invitation to anyone who can reach the device.

Basic Configuration (v2c)

Cisco IOS — global configuration mode (conf t):

snmp-server community <read-only-string> RO
snmp-server community <read-write-string> RW
snmp-server host 10.0.99.5 version 2c <read-only-string>
snmp-server enable traps

snmp-server enable traps with no keyword enables all supported notification types — individual types can be enabled instead, one per command (e.g. snmp-server enable traps envmon).

This is the same pattern already used in Security Hardening — replace the placeholder strings with real, non-default values. Restrict RW community access as tightly as possible, or avoid it entirely if the monitoring system only needs to read data.

Cisco IOS — global configuration mode (conf t):

snmp-server group MONITORS v3 priv
snmp-server user monitor-user MONITORS v3 auth sha <auth-password> priv aes 128 <priv-password>
! v3 trap destination — replaces the v2c host line above
snmp-server host 10.0.99.5 version 3 priv monitor-user

auth sha authenticates who's asking; priv aes 128 encrypts the actual data in transit — v2c does neither. The version 3 priv host line matters just as much as the user: without it, traps still leave the switch as plaintext v2c with a community string, even though polling is encrypted.

Restricting SNMP Access

Same principle as SSH Management Only — don't expose SNMP beyond the management VLAN:

Cisco IOS — global configuration mode (conf t):

access-list 10 permit 10.0.99.0 0.0.0.255
snmp-server community <read-only-string> RO 10

The trailing 10 ties the community string to ACL 10, so only sources matching that ACL can query with it.

Port-wise: SNMP polls are UDP 161, initiated by the monitoring server toward the device; traps are UDP 162, initiated by the device toward the server. The two flows run in opposite directions — both need rules when the firewall sits between the monitoring host and the management VLAN.

Verification

Cisco IOS — privileged EXEC:

! SNMP engine status, packet counts
show snmp
! Configured community strings (names only — RO/RW is not shown)
show snmp community
! Shows each string's RO/RW level and ACL binding
show run | include snmp-server community
! Configured trap destinations
show snmp host
! Configured SNMPv3 users
show snmp user

Caution: snmp-server user lines never appear in show running-config — IOS deliberately hides them, so show snmp user is the only way to confirm a v3 user exists. That also means v3 users are not captured in config-file backups: after restoring a saved config to a switch, re-create the SNMPv3 user by hand or SNMPv3 access is silently lost.

From the monitoring server side, an snmpwalk against the device is the usual first test that SNMP is actually reachable and answering.