SNMP – Simple Network Management Protocol Overview

1. What Is SNMP and Why Does It Matter?

SNMP (Simple Network Management Protocol) is the industry-standard protocol for monitoring and managing network devices. It enables a central Network Management Station (NMS) to collect performance data, receive alerts, and modify configuration parameters on routers, switches, firewalls, servers, printers, and any other SNMP-capable device — all from a single management platform.

Without SNMP, an administrator would need to log into each device individually to check interface statistics, CPU utilisation, memory usage, and error counters. In a network with hundreds or thousands of devices, this is impractical. SNMP automates monitoring by allowing devices to report their status proactively and allowing the NMS to poll devices on a schedule.

SNMP Capability	Example Use Case
Performance monitoring	NMS polls every router every 5 minutes for interface utilisation — generates bandwidth trending graphs and capacity planning reports
Fault detection	When a router interface goes down, the device immediately sends a TRAP to the NMS — alerting the NOC without waiting for the next poll cycle
Configuration changes	NMS sends a SET operation to update an interface description or enable/disable an interface remotely
Inventory management	NMS queries all devices for model number, IOS version, serial number, and installed modules — builds an asset database automatically
Threshold alerting	NMS alerts when CPU exceeds 80%, memory drops below 20%, or error rate on an interface exceeds a threshold

2. SNMP Architecture — Manager and Agent

SNMP uses a manager–agent model. The manager (NMS) is the central system that requests information and issues commands. The agent is software running on each managed device that responds to manager requests and generates unsolicited alerts.

2.1 SNMP Manager (NMS)

The SNMP Manager — also called the NMS (Network Management System) — is a software application running on a management server or workstation. It is the active party: it sends requests to agents, receives responses, processes TRAP/INFORM messages, and presents network status to administrators through dashboards and alerts.

  SNMP Manager (NMS) responsibilities:

  - Sends GET requests to query device variables (interface stats, CPU, memory)
  - Sends SET requests to modify device configuration remotely
  - Receives TRAP / INFORM messages sent by agents on significant events
  - Maintains a database of network topology and performance history
  - Generates alerts, graphs, and reports for administrators
  - Runs on UDP port 162 (receives TRAPs/INFORMs from agents)

  Common NMS platforms:
  - Cisco DNA Center / Cisco Prime Infrastructure
  - SolarWinds Network Performance Monitor (NPM)
  - Nagios / PRTG / Zabbix / LibreNMS (open source)
  - Paessler PRTG Network Monitor

2.2 SNMP Agent

The SNMP Agent is software built into virtually every network device — routers, switches, firewalls, APs, servers, and printers. It passively listens for manager requests, responds with the requested data, and proactively sends TRAP or INFORM messages when significant events occur (interface down, high CPU, config change).

  SNMP Agent responsibilities:

  - Listens for GET/SET requests from the NMS on UDP port 161
  - Responds with the requested MIB variable values (GET responses)
  - Applies SET commands to modify device parameters
  - Sends TRAP messages to the NMS on UDP port 162 (unsolicited alerts)
  - Maintains the MIB — the local database of manageable variables
  - Implements access control (community strings or SNMPv3 users)

  Agents run on: Cisco routers, switches, firewalls, APs, Linux servers,
                 Windows servers, printers, UPS systems, environmental sensors

Manager–Agent Communication Flow

  SNMP communication model:

  ┌─────────────────────────────────────────────────────────────────────────┐
  │  NMS (Manager)                                     Agent (device)       │
  │                                                                         │
  │  1. GET request ────────────── UDP port 161 ──────────────────────────► │
  │     "What is the value of OID 1.3.6.1.2.1.2.2.1.10.1?"                │
  │     (inOctets on interface GigabitEthernet0/0)                          │
  │                                                                         │
  │  2. GET-RESPONSE ◄──────────── UDP port 161 ────────────────────────── │
  │     "Value = 45,231,894,012 bytes"                                      │
  │                                                                         │
  │  3. TRAP ◄─────────────────── UDP port 162 ────────────────────────── │
  │     "linkDown — GigabitEthernet0/0 is down" (unsolicited)              │
  │                                                                         │
  │  NMS sends from a high port; Agent listens on UDP 161                  │
  │  Agent sends TRAPs to NMS on UDP 162                                   │
  └─────────────────────────────────────────────────────────────────────────┘

  Key UDP ports:
  UDP 161 → SNMP requests (GET, GETNEXT, GETBULK, SET) — agent listens here
  UDP 162 → SNMP notifications (TRAP, INFORM) — NMS listens here

3. MIB — Management Information Base

The MIB (Management Information Base) is a hierarchical database of all variables that can be monitored or configured on a device via SNMP. Each variable in the MIB is called an OID (Object Identifier). The MIB is not stored on the NMS — it is a standardised description of what variables exist and how they are structured. Both the manager and the agent understand the same MIB definitions.

MIB Tree Structure

  The MIB is organised as a hierarchical tree (like a file system):

  root
  └── iso (1)
      └── org (3)
          └── dod (6)
              └── internet (1)
                  ├── directory (1)
                  ├── mgmt (2)
                  │   └── mib-2 (1)
                  │       ├── system (1)         ← sysDescr, sysUpTime, sysName
                  │       ├── interfaces (2)     ← ifDescr, ifSpeed, ifInOctets
                  │       ├── ip (4)             ← ipRoutingTable, ipAddrTable
                  │       ├── tcp (6)            ← tcpActiveOpens, tcpCurrEstab
                  │       └── udp (7)            ← udpInDatagrams
                  ├── experimental (3)
                  └── private (4)
                      └── enterprises (1)
                          ├── cisco (9)          ← Cisco-proprietary MIBs
                          │   └── ... (thousands of Cisco OIDs)
                          └── (other vendors)

  The standard MIB-2 (RFC 1213) defines universally supported objects.
  Vendors add proprietary subtrees under "private.enterprises" for
  device-specific objects not covered by standard MIBs.

OID — Object Identifier

Every variable in the MIB has a unique OID — a sequence of numbers separated by dots, corresponding to the path through the MIB tree from the root to that specific object.

  OID examples:

  1.3.6.1.2.1.1.1.0        → sysDescr — text description of the device
                               (e.g., "Cisco IOS Software, Version 16.9.4")

  1.3.6.1.2.1.1.3.0        → sysUpTime — time since the device last rebooted
                               (in hundredths of a second)

  1.3.6.1.2.1.1.5.0        → sysName — the device's configured hostname

  1.3.6.1.2.1.2.2.1.10.1   → ifInOctets.1 — bytes received on interface 1
  1.3.6.1.2.1.2.2.1.16.1   → ifOutOctets.1 — bytes transmitted on interface 1

  1.3.6.1.2.1.2.2.1.8.1    → ifOperStatus.1 — operational status of interface 1
                               (1 = up, 2 = down, 3 = testing)

  Decomposing 1.3.6.1.2.1.2.2.1.10.1:
  1       = iso
  3       = org
  6       = dod
  1       = internet
  2       = mgmt
  1       = mib-2
  2       = interfaces group
  2       = ifTable
  1       = ifEntry (a row in the interface table)
  10      = ifInOctets (the column)
  1       = instance 1 (interface index 1)

  OIDs can also be expressed as named paths (human-readable):
  iso.org.dod.internet.mgmt.mib-2.interfaces.ifTable.ifEntry.ifInOctets.1

CCNA exam tip: You do not need to memorise OID numbers for the CCNA exam. What matters is understanding that OIDs uniquely identify every SNMP-manageable variable, that the MIB is a hierarchical tree, and that standard OIDs are vendor-neutral while enterprises define their own OIDs under the private subtree.

4. SNMP Operations — GET, SET, TRAP, INFORM

SNMP defines a small set of operations for communication between the manager and agent. Each operation uses a specific message type.

4.1 GET — Retrieve a Single Variable

  NMS → Agent: GET request
  "Give me the current value of OID 1.3.6.1.2.1.1.5.0 (sysName)"

  Agent → NMS: GET-RESPONSE
  "sysName = R1-CORE"

  The GET operation retrieves the value of one or more specific OIDs.
  The NMS specifies exactly which OID(s) it wants.
  The agent returns the current value(s).

  Example — query interface status:
  GET 1.3.6.1.2.1.2.2.1.8.1 (ifOperStatus.1)
  Response: 1 (up)

4.2 GETNEXT — Walk the MIB Table

  NMS → Agent: GETNEXT request
  "Give me the next OID after 1.3.6.1.2.1.2.2.1.10 (ifInOctets)"

  The agent returns the NEXT object in the MIB tree after the specified OID.
  GETNEXT is used to traverse (walk) a MIB table row-by-row when the exact
  OIDs are not known in advance.

  NMS can repeatedly send GETNEXT to enumerate all interfaces, all routes,
  all ARP entries, etc. without knowing how many rows the table has.

4.3 GETBULK — Efficiently Retrieve Large Tables (SNMPv2c/v3)

  NMS → Agent: GETBULK request
  "Give me the next N rows of this MIB table in a single response"

  GETBULK was introduced in SNMPv2c to replace repeated GETNEXT operations.
  Instead of one GET per row (inefficient for large tables), GETBULK retrieves
  multiple rows in a single request/response exchange.

  Parameters: max-repetitions = how many rows to return per variable
  Use case: retrieving the full routing table or ARP table in one or a few
  GETBULK exchanges instead of thousands of GETNEXT operations.

4.4 SET — Modify a Variable

  NMS → Agent: SET request
  "Set OID 1.3.6.1.2.1.2.2.1.7.2 (ifAdminStatus.2) to 2 (down)"
  → Shuts down interface index 2 on the device

  The SET operation changes the value of one or more OIDs on the agent.
  This is how SNMP enables remote configuration:
  - Shutdown/bring up interfaces
  - Change interface descriptions
  - Modify SNMP parameters

  Access control: SET operations require the write community string (SNMPv1/v2c)
  or a user with write privileges (SNMPv3).
  Most deployments restrict SET access to the NMS IP address only.

4.5 TRAP — Unsolicited Alert from Agent

  Agent → NMS: TRAP message (no acknowledgement required from NMS)
  "linkDown: GigabitEthernet0/0 is now operationally down"

  TRAPs are unsolicited — the agent sends them immediately when a
  significant event occurs, without waiting for the NMS to poll.
  The NMS does NOT acknowledge a TRAP — it is a fire-and-forget message.

  Common standard TRAP types (RFC 1157):
  coldStart      → device rebooted and configuration may have changed
  warmStart      → device rebooted but configuration is unchanged
  linkDown       → an interface transitioned from up to down
  linkUp         → an interface transitioned from down to up
  authFailure    → received an SNMP message with wrong community string

  Vendor-specific traps: Cisco defines additional traps for:
  - CPU threshold exceeded
  - Memory low
  - OSPF neighbour adjacency change
  - BGP peer state change
  - Temperature threshold exceeded

  Problem with TRAPs: UDP is unreliable — TRAPs can be lost.
  If a TRAP is dropped on the network, the NMS never learns about the event.
  This is why SNMPv2c introduced INFORM.

4.6 INFORM — Acknowledged Trap (SNMPv2c/v3)

  Agent → NMS: INFORM message
  "linkDown: GigabitEthernet0/0 is down" (requires acknowledgement)

  NMS → Agent: INFORM-RESPONSE (acknowledgement)
  "Received"

  INFORM vs TRAP:
  ┌───────────────────────────────┬─────────────────────┬─────────────────────┐
  │  Feature                      │  TRAP               │  INFORM             │
  ├───────────────────────────────┼─────────────────────┼─────────────────────┤
  │  Acknowledgement              │  None               │  Yes — NMS replies  │
  │  Reliability                  │  Unreliable (UDP)   │  Reliable           │
  │  Retransmission on loss       │  No                 │  Yes (until ack)    │
  │  Agent stores message?        │  No                 │  Yes (until ack)    │
  │  NMS resource usage           │  Low                │  Higher             │
  │  SNMP version                 │  v1, v2c, v3        │  v2c, v3 only       │
  └───────────────────────────────┴─────────────────────┴─────────────────────┘

  INFORMs are preferred when reliability is critical — loss of a TRAP means
  the NMS misses a fault event. INFORMs ensure every significant event is
  delivered and acknowledged.

SNMP Message Type Summary

Operation	Direction	UDP Port	Purpose	Version
GET	NMS → Agent	161	Retrieve specific OID value(s)	v1, v2c, v3
GETNEXT	NMS → Agent	161	Get next OID in MIB tree (walk)	v1, v2c, v3
GETBULK	NMS → Agent	161	Retrieve multiple OID rows efficiently	v2c, v3
SET	NMS → Agent	161	Modify OID value — remote configuration	v1, v2c, v3
GET-RESPONSE	Agent → NMS	161	Return requested OID values to manager	v1, v2c, v3
TRAP	Agent → NMS	162	Unsolicited alert — no acknowledgement	v1, v2c, v3
INFORM	Agent → NMS	162	Acknowledged alert — reliable notification	v2c, v3

5. SNMP Versions — v1, v2c, v3

SNMP has evolved through three major versions. Each version improves on the security and capabilities of the previous one. SNMPv3 is the only version with strong security and is required in modern production environments.

5.1 SNMPv1

  SNMPv1 — RFC 1157 (1988)

  Security:    Community strings in plaintext — sent as cleartext in every packet.
               Anyone capturing network traffic can read the community string.
  Operations:  GET, GETNEXT, SET, TRAP, GET-RESPONSE
  Error handling: Limited — only a single generic error code
  Counters:    32-bit only — wraps around every 4.29 billion (suitable for
               low-speed interfaces only; wraps in minutes on GigE links)

  Still in use: Some legacy devices only support SNMPv1.
  Not recommended: Community strings are plaintext — complete security risk.

5.2 SNMPv2c

  SNMPv2c — RFC 1901 (1993, community-based SNMPv2)
  ("c" = community-based — same weak authentication as v1)

  Security:    Community strings — still plaintext. No encryption.
               Same security weaknesses as SNMPv1.
  Improvements over v1:
  - GETBULK operation — retrieve large tables efficiently
  - INFORM operation — reliable, acknowledged notifications
  - 64-bit counters (Counter64) — essential for high-speed interfaces
    (GigE link at full speed wraps a 32-bit counter in ~34 seconds;
     64-bit counters take ~585 years to wrap)
  - Better error codes — more granular error reporting
  - GET-RESPONSE replaced by RESPONSE PDU

  Most widely deployed version: many organisations still use SNMPv2c
  for monitoring (read-only) despite the security weakness, due to
  simplicity and universal device support.
  Never use SNMPv2c for SET (write) operations in production.

5.3 SNMPv3

  SNMPv3 — RFC 3411-3418 (2002)

  SNMPv3 adds a complete security model to SNMP:
  - Authentication: verifies message came from a legitimate source
  - Encryption: protects message content from eavesdropping
  - Message integrity: detects whether a message was tampered in transit
  - Anti-replay: timestamps prevent replay attacks

  SNMPv3 uses users (not community strings) for access control.
  Each user can be configured with one of three security levels:

  ┌─────────────────┬───────────────────┬─────────────┬───────────────────────┐
  │  Security Level │  Authentication   │  Encryption │  Description          │
  ├─────────────────┼───────────────────┼─────────────┼───────────────────────┤
  │  noAuthNoPriv   │  None             │  None       │  No security —        │
  │  (noauth)       │  (uses username   │             │  equivalent to        │
  │                 │   only)           │             │  community string     │
  ├─────────────────┼───────────────────┼─────────────┼───────────────────────┤
  │  authNoPriv     │  Yes              │  None       │  Messages are         │
  │  (auth)         │  MD5 or SHA       │             │  authenticated but    │
  │                 │                   │             │  still readable       │
  ├─────────────────┼───────────────────┼─────────────┼───────────────────────┤
  │  authPriv       │  Yes              │  Yes        │  Fully secure —       │
  │  (priv)         │  MD5 or SHA       │  DES or AES │  authentication AND   │
  │                 │                   │             │  encryption           │
  └─────────────────┴───────────────────┴─────────────┴───────────────────────┘

  Recommended: authPriv with SHA-256 + AES-256 for production environments.

SNMP Version Comparison

Feature	SNMPv1	SNMPv2c	SNMPv3
Authentication	Community string (plaintext)	Community string (plaintext)	Username + HMAC-MD5/SHA
Encryption	None	None	DES, 3DES, AES-128, AES-256
Message integrity	None	None	HMAC ensures integrity
Counter size	32-bit	32-bit + 64-bit (Counter64)	32-bit + 64-bit (Counter64)
GETBULK	No	Yes	Yes
INFORM	No	Yes	Yes
Production recommended	No — legacy only	Read-only only (no SET)	Yes — use authPriv

6. Community Strings (SNMPv1 / SNMPv2c)

A community string is the SNMPv1/v2c equivalent of a password. It is a plaintext string included in every SNMP message. The agent checks the community string against its configured values before processing any request. There are two types:

Community String Type	Access Granted	Typical Value
Read-only (RO)	GET and GETNEXT operations only — cannot modify any values	"public" (default — should always be changed)
Read-write (RW)	GET and SET operations — full read and write access to MIB	"private" (default — must be changed immediately)

  Security problems with community strings:

  1. Transmitted in plaintext — any packet capture reveals the string:
     Frame contents: "community: public" → anyone can read it

  2. Default values universally known:
     "public" for read and "private" for write are the default on virtually
     every SNMP device ever manufactured.
     Scanning tools can query "public" and retrieve full device information
     from any unprotected device on the Internet.

  3. No per-user access control — everyone who knows the string has
     identical access.

  4. No encryption — even custom community strings are visible to attackers.

  Best practices for community strings:
  - Change default "public" and "private" immediately
  - Use complex, non-dictionary strings
  - Restrict SNMP access with an ACL (permit only NMS IP addresses)
  - Use read-only community string for monitoring — never enable write
    access unless absolutely required
  - Upgrade to SNMPv3 for any sensitive or production environments

Configuring SNMP Community Strings on Cisco IOS

  ! Read-only community string (polling/monitoring only):
  Router(config)# snmp-server community Str0ngR0String ro

  ! Read-write community string (allows SET operations):
  Router(config)# snmp-server community Str0ngRWStr1ng rw

  ! Restrict SNMP access to NMS IP only using an ACL:
  Router(config)# ip access-list standard SNMP_ALLOWED
  Router(config-std-nacl)# permit host 10.99.1.10   ! NMS IP address
  Router(config-std-nacl)# deny any log
  Router(config-std-nacl)# exit

  Router(config)# snmp-server community Str0ngR0String ro SNMP_ALLOWED
  ! ACL is applied as the 4th argument — only NMS can use this community

  ! Verify:
  Router# show snmp community

See: show running-config

7. SNMPv3 Configuration

SNMPv3 replaces community strings with a user-based security model. Each user is associated with a group, and each group has a defined security level. Configuration requires defining views, groups, and users.

SNMPv3 Configuration Components

Component	Purpose	Command
View	Defines which portion of the MIB tree is accessible — restricts what OIDs can be read or written	`snmp-server view`
Group	Associates a security level (noAuthNoPriv, authNoPriv, authPriv) with a view — defines what security and access level the group members have	`snmp-server group`
User	Individual SNMP user with credentials — assigned to a group; authentication and privacy passwords set here	`snmp-server user`

Full SNMPv3 configuration — authPriv (most secure):

! ── Step 1: Define a view (which MIB objects are accessible) ────────────
Router(config)# snmp-server view FULL_MIB iso included
! "iso included" = allow access to the entire MIB tree under iso

! ── Step 2: Define a group with authPriv security level ─────────────────
Router(config)# snmp-server group SNMP_ADMINS v3 priv
! ↑ ↑
! version security level (priv = authPriv)

! ── Step 3: Define a user with authentication and privacy passwords ──────
Router(config)# snmp-server user nmsuser SNMP_ADMINS v3 auth sha AuthP@ssw0rd priv aes 256 Priv@ssw0rd
! ↑ ↑ ↑ ↑ ↑ ↑ ↑
! username group version hash auth-key encrypt priv-key

! ── Step 4: Configure SNMP TRAP destination (send alerts to NMS) ─────────
Router(config)# snmp-server host 10.99.1.10 version 3 priv nmsuser
! NMS IP version security-level username

! ── Step 5: Enable SNMP traps (which events to send) ─────────────────────
Router(config)# snmp-server enable traps snmp authentication linkdown linkup
Router(config)# snmp-server enable traps config ! config change traps
Router(config)# snmp-server enable traps cpu threshold ! CPU threshold

! ── Verify ────────────────────────────────────────────────────────────────
Router# show snmp
Router# show snmp user
Router# show snmp group

SNMPv3 password visibility: The snmp-server user command stores authentication and privacy passwords as hashes — they are not visible in the running-config in plaintext. However, show snmp user shows the user's group membership and authentication/privacy protocols but not the passwords themselves.

8. SNMP Trap Configuration

TRAPs (and INFORMs) are the proactive alerting mechanism of SNMP. Without traps, the NMS would only learn about problems at its next poll cycle — which might be 5 minutes away. Traps deliver alerts immediately when a significant event occurs.

  Configuring SNMP TRAPs on Cisco IOS (SNMPv2c):

  ! Define the NMS that will receive traps:
  Router(config)# snmp-server host 10.99.1.10 version 2c Str0ngR0String

  ! Enable specific trap types (or use "all" for everything):
  Router(config)# snmp-server enable traps snmp authentication linkdown linkup coldstart
  Router(config)# snmp-server enable traps ospf state-change         ! OSPF events
  Router(config)# snmp-server enable traps bgp                        ! BGP events
  Router(config)# snmp-server enable traps config                     ! config changes
  Router(config)# snmp-server enable traps envmon temperature         ! temp alerts
  Router(config)# snmp-server enable traps cpu threshold              ! CPU overload

  ! Using INFORM instead of TRAP (SNMPv2c — more reliable):
  Router(config)# snmp-server host 10.99.1.10 informs version 2c Str0ngR0String

  ! Set the device's contact and location info (good practice for NMS inventory):
  Router(config)# snmp-server contact "NOC Team - [email protected]"
  Router(config)# snmp-server location "Main DC - Rack A3 - Slot 4"

  ! Verify traps are enabled and NMS host is configured:
  Router# show snmp host
  Router# show snmp trap

See: show logging (Syslog/Traps)

9. SNMP Polling vs SNMP Traps — When to Use Each

A complete SNMP monitoring strategy uses both polling and traps — they complement each other's weaknesses.

Feature	SNMP Polling (GET)	SNMP Traps / INFORMs
Initiated by	NMS (manager) — on a schedule	Agent (device) — immediately on event
Alert speed	Delayed — only detects issues at next poll cycle (typically 1–5 minutes)	Immediate — device alerts NMS the moment the event occurs
Bandwidth impact	Continuous — regular polling traffic; scales with number of devices and poll frequency	Minimal — only generates traffic when events occur
Reliability	High — NMS controls the poll; missing data is detected as a gap in the timeseries	Medium (TRAP) / High (INFORM) — TRAPs can be lost; INFORMs are acknowledged
Primary use	Performance trending, capacity planning, baseline monitoring, SLA reporting	Fault management — real-time alerts for interface down, high CPU, authentication failures

  Combined monitoring strategy:

  Polling (every 5 minutes):
  → Collects interface utilisation, CPU, memory, error counters
  → Builds trending data for capacity planning
  → Detects gradual degradation before it becomes a crisis

  Traps (immediate on event):
  → Interface goes down → trap fires immediately → NOC alert within seconds
  → OSPF neighbour lost → trap fires → engineer investigates before users notice
  → CPU spikes → trap fires → investigation begins

  Together: polling provides the historical picture; traps provide the
  real-time alerting. Neither alone provides complete visibility.

10. Verification Commands

  ! Show SNMP overall status (community strings, trap destinations, stats):
  Router# show snmp

  ! Show configured community strings:
  Router# show snmp community

  ! Show configured SNMP trap destination hosts:
  Router# show snmp host

  ! Show which trap types are enabled:
  Router# show snmp trap | include enabled

  ! Show SNMPv3 users and their security settings:
  Router# show snmp user

  ! Show SNMPv3 groups and security levels:
  Router# show snmp group

  ! Show SNMP engine ID (unique identifier for this SNMP agent):
  Router# show snmp engineID

  ! Show SNMP packet statistics (requests received, errors, etc.):
  Router# show snmp statistics

  ! Verify specific OID value from the CLI (Cisco IOS):
  Router# show snmp mib ifmib ifindex          ! interface indices for SNMP polling

Sample Output — show snmp

  Router# show snmp
  Chassis: FTX1234ABCD
  Contact: NOC Team - [email protected]
  Location: Main DC - Rack A3 - Slot 4
  0 SNMP packets input
      0 Bad SNMP version errors
      0 Unknown community name
      0 Illegal operation for community name supplied
      0 Encoding errors
      14892 Number of requested variables
      0 Number of altered variables
      14892 Get-request PDUs
      0 Set-request PDUs
  14892 SNMP packets output
      0 Too big errors (maximum packet size 1500)
      0 No such name errors
      0 Bad values errors
      0 General errors
      14892 Response PDUs
      437 Trap PDUs

  SNMP Encryption:  Disabled
  SNMP logging: disabled

  Key metrics to monitor:
  - "Unknown community name" errors → wrong community string being used or attack
  - "Illegal operation" errors → read-only community used for SET
  - "Bad SNMP version" errors → version mismatch between NMS and agent
  - Trap PDUs count should increase when events occur

Common SNMP Troubleshooting Issues

Symptom	Likely Cause	Fix
NMS cannot poll device	Wrong community string, UDP 161 blocked by ACL, or SNMP not configured on device	Verify with `show snmp community`; check ACL with `show ip access-lists`; confirm `snmp-server community` is configured
Traps not arriving at NMS	Wrong NMS IP in `snmp-server host`, UDP 162 blocked by firewall, or traps not enabled	Verify with `show snmp host`; check firewall rules; confirm `snmp-server enable traps`
SNMPv3 authentication errors	User not configured on device, wrong auth/priv password, or security level mismatch between NMS and agent	Verify with `show snmp user` and `show snmp group`; confirm NMS uses same user, protocol, and passwords
Counter wrap — incorrect utilisation graphs	Using SNMPv1 or polling 32-bit counters on high-speed interfaces — counter wraps before next poll	Upgrade to SNMPv2c or v3 to use 64-bit (Counter64) OIDs for interface statistics

11. SNMP Summary — Key Facts

Topic	Key Fact
SNMP manager port	UDP 162 — receives TRAPs and INFORMs from agents
SNMP agent port	UDP 161 — listens for GET, GETNEXT, GETBULK, SET from NMS
MIB	Hierarchical database of all manageable variables; structured as a tree; each variable has a unique OID
OID	Dot-separated number sequence identifying a specific MIB variable (e.g., 1.3.6.1.2.1.1.5.0 = sysName)
GET	NMS retrieves specific OID value from agent — request/response
SET	NMS modifies OID value on agent — requires write access
TRAP	Agent sends unsolicited alert to NMS — UDP, no acknowledgement, can be lost
INFORM	Like TRAP but acknowledged — agent retransmits until NMS confirms receipt; v2c/v3 only
SNMPv1/v2c security	Community strings — plaintext; easily captured; no encryption
SNMPv3 security levels	noAuthNoPriv (none), authNoPriv (auth only), authPriv (auth + encryption) — use authPriv in production
SNMPv2c advantage	GETBULK, INFORM, and 64-bit counters (Counter64) added over v1
Default community strings	"public" (read-only) and "private" (read-write) — must be changed immediately on all devices

12. SNMP Concepts Quiz

1. What UDP ports does SNMP use, and which direction does each serve?

A. UDP 161 for both requests and traps — all SNMP traffic uses the same port B. UDP 161 — the agent listens here for GET, GETNEXT, GETBULK, and SET requests from the NMS. UDP 162 — the NMS listens here to receive TRAP and INFORM messages sent by agents. C. UDP 162 for requests; UDP 161 for traps D. TCP 161 for reliable polling; UDP 162 for unreliable traps

Correct answer is B. SNMP uses two UDP ports with distinct roles. UDP 161 is the agent's listening port — the NMS sends all query and configuration messages (GET, GETNEXT, GETBULK, SET) to the agent on this port, and the agent replies from port 161. UDP 162 is the NMS's listening port — agents send unsolicited alerts (TRAP, INFORM) to the NMS on port 162. SNMP uses UDP (not TCP) for both ports — lightweight and connectionless, which is appropriate for frequent polling and fire-and-forget trap messages.

2. What is the difference between a TRAP and an INFORM in SNMP, and which is more reliable?

A. TRAPs are encrypted; INFORMs are plaintext — TRAPs are more secure B. TRAPs come from managers; INFORMs come from agents C. Both are identical — INFORM is just the newer name for TRAP in SNMPv3 D. A TRAP is an unsolicited alert sent by an agent to the NMS with no acknowledgement — if lost, the NMS never knows. An INFORM is the same type of alert but requires the NMS to send back an acknowledgement. If no ack is received, the agent retransmits the INFORM. INFORMs are more reliable. INFORMs are available in SNMPv2c and v3 only.

Correct answer is D. Both TRAPs and INFORMs are unsolicited alert messages sent from an SNMP agent to the NMS to report a significant event (link down, CPU spike, etc.). The critical difference is reliability. TRAPs use UDP and are fire-and-forget — the agent sends the TRAP once and forgets about it. If the UDP packet is lost (network congestion, brief outage), the NMS never receives the alert and has no knowledge of the event. INFORMs require the NMS to send back an InformResponse (acknowledgement). The agent stores the INFORM message and retransmits it at configured intervals until it receives the acknowledgement. INFORMs are therefore significantly more reliable for fault notification.

3. What is the purpose of the MIB in SNMP, and what is an OID?

A. The MIB (Management Information Base) is a hierarchical database defining all variables that can be monitored or managed on a device via SNMP. An OID (Object Identifier) is a unique dot-separated number sequence that identifies a specific variable in the MIB tree (e.g., 1.3.6.1.2.1.1.5.0 = the device's hostname). B. The MIB is a routing table used by SNMP to find the NMS; OIDs are the IP addresses of SNMP agents C. The MIB is stored on the NMS only; agents have no knowledge of it D. The MIB is the SNMP username database; OIDs are the encrypted community strings

Correct answer is A. The MIB defines the structure and meaning of every variable that SNMP can access on a device. It is organised as a hierarchical tree — the root splits into branches (iso, org, dod, internet, mgmt, mib-2, etc.) and eventually reaches leaf nodes representing specific values like sysName, ifInOctets, or CPU utilisation. Each leaf node has a unique OID — a path through the tree expressed as numbers separated by dots. The MIB is not a single file on one device — it is a standardised schema (defined by RFCs and vendor documentation) that both the NMS and the agent understand, allowing the NMS to know the meaning of every OID it queries.

4. Why does SNMPv2c introduce 64-bit counters (Counter64), and why are 32-bit counters insufficient for modern interfaces?

A. 64-bit counters provide better compression of SNMP messages, reducing bandwidth usage B. 64-bit counters are required for SNMPv3 encryption — v1 and v2c cannot use them C. A 32-bit counter wraps at approximately 4.29 billion — on a 1 Gbps interface at full speed it wraps in about 34 seconds, far faster than a typical 5-minute poll cycle. When a counter wraps between polls the NMS cannot accurately calculate utilisation. A 64-bit counter holds 18 × 10^18 — taking ~585 years to wrap at 1 Gbps. D. 32-bit counters only support IPv4; 64-bit counters are required for IPv6 traffic monitoring

Correct answer is C. This is a practical engineering problem that SNMPv2c specifically addressed. A 32-bit counter wraps (overflows back to zero) at 2^32 = 4,294,967,295. At 1 Gbps (125,000,000 bytes/second), a byte counter wraps in 4,294,967,295 ÷ 125,000,000 ≈ 34 seconds. A typical NMS poll interval is 5 minutes (300 seconds) — the counter would wrap 8 times between polls, making it impossible to calculate accurate utilisation. At 10 Gbps the situation is 10× worse. SNMPv2c introduced the Counter64 OID type (2^64 values), which takes approximately 585 years to wrap at 1 Gbps and 58 years at 10 Gbps — well beyond any practical concern. When monitoring high-speed interfaces, always use the ifHCInOctets / ifHCOutOctets OIDs (64-bit) rather than ifInOctets / ifOutOctets (32-bit).

5. What are the three SNMPv3 security levels, and which provides the strongest security?

A. read, write, admin — admin provides full encryption and authentication B. noAuthNoPriv (no authentication or encryption), authNoPriv (authentication with MD5/SHA but no encryption), authPriv (authentication with MD5/SHA AND encryption with DES/AES). authPriv provides the strongest security and is recommended for production environments. C. community, user, admin — all three encrypt traffic but with different key lengths D. SHA, MD5, AES — AES is the strongest security level in SNMPv3

Correct answer is B. SNMPv3 defines three security levels as part of its User-based Security Model (USM). noAuthNoPriv uses only a username — no password hashing, no encryption; equivalent in security to a community string. authNoPriv adds HMAC-based authentication using MD5 or SHA — the message is verified as coming from a legitimate user and has not been tampered with, but the content is still readable by anyone who captures the packet. authPriv adds full encryption (DES, 3DES, AES-128, or AES-256) on top of authentication — the message content is unreadable to eavesdroppers AND verified as authentic. authPriv with SHA-256 and AES-256 is the recommended configuration for any production SNMP deployment.

6. What is the security risk of using the default SNMP community strings "public" and "private", and what should be done immediately on production devices?

A. The default strings are encrypted by IOS — there is no security risk if service password-encryption is enabled B. The risk is only relevant if the device is directly connected to the Internet without a firewall C. Default strings only allow read access — "private" requires additional configuration to enable write D. "public" (read) and "private" (write) are universally known defaults on virtually every network device. Any attacker with network access can query full device information using "public" and modify device configuration using "private" — without knowing any credentials. Immediate actions: change both strings to complex values, restrict SNMP access with an ACL (permit only NMS IPs), and upgrade to SNMPv3 authPriv.

Correct answer is D. This is one of the most common and dangerous misconfigurations in network security. "public" and "private" have been the default SNMP community strings on Cisco and most other vendors' devices for decades. They are published in every vendor manual and are the first strings any automated scanning tool tries. An attacker who can reach the device on UDP 161 with "public" can retrieve the full routing table, ARP table, interface statistics, and device configuration details. With "private" (read-write), they can modify interface configurations, change routing parameters, or disable interfaces. Note: "private" by default provides write access immediately — no additional configuration is required.

7. An NMS is trying to poll a Cisco router using SNMPv2c but receives no response. The router has SNMP configured. What command verifies if SNMP community strings are configured correctly, and what error in show snmp output would confirm the community string mismatch?

A. Use show snmp community to verify the configured community string. In show snmp output, an incrementing "Unknown community name" error counter confirms the NMS is using a community string that does not match what is configured on the router. B. Use debug snmp packets; the "community mismatch" counter is in show interfaces C. Use show snmp engineID; mismatched engine IDs cause polling failure D. SNMP failures are always shown in syslog only — no show command provides this information

Correct answer is A. The quickest way to verify community string configuration is show snmp community, which shows all configured community strings and their access levels (RO/RW) and associated ACLs. To confirm a mismatch is occurring, run show snmp and look at the "Unknown community name" counter in the SNMP input statistics section. Each time the NMS sends a GET with the wrong community string, this counter increments. If it is increasing while polling is failing, the community string mismatch is confirmed. Other useful counters: "Illegal operation for community name supplied" (correct community but wrong access level — e.g., using RO string for SET).

8. What operation does GETBULK perform, and why was it introduced in SNMPv2c?

A. GETBULK retrieves compressed SNMP data to reduce bandwidth — it was introduced to replace encryption overhead in SNMPv1 B. GETBULK sends multiple SET operations in a single packet — it was introduced to improve configuration speed C. GETBULK retrieves multiple consecutive MIB rows in a single request/response exchange. It was introduced to replace the inefficient SNMPv1 approach of sending a separate GETNEXT for each row — retrieving a 500-row routing table required 500 GETNEXT operations; GETBULK can retrieve it in a handful of exchanges. D. GETBULK retrieves all variables from all devices simultaneously — it was introduced to enable broadcast polling

Correct answer is C. Before GETBULK (SNMPv1 only had GET, GETNEXT, SET, and TRAP), retrieving a large MIB table required sending one GETNEXT for each row. For a routing table with 1000 entries, that meant 1000 request/response round trips — slow, bandwidth-consuming, and CPU-intensive on both the NMS and agent. GETBULK allows the NMS to specify max-repetitions (e.g., 50) — the agent returns up to 50 consecutive rows in a single response. The same 1000-row routing table can be retrieved in as few as 20 GETBULK exchanges. GETBULK is available in SNMPv2c and v3 only — it is not available in SNMPv1.

9. An administrator needs to configure SNMP monitoring on a router but wants to ensure only the NMS at 10.99.1.10 can query the device. Which configuration achieves this for SNMPv2c?

A. snmp-server community Str0ng ro followed by snmp-server host 10.99.1.10 B. Create a standard ACL permitting only 10.99.1.10, then reference it in the community string command: ip access-list standard NMS_ONLY / permit host 10.99.1.10 / snmp-server community Str0ng ro NMS_ONLY. Only the NMS IP can use this community string. C. snmp-server host 10.99.1.10 only — the "only" keyword restricts access automatically D. Configure an extended ACL blocking UDP 161 from all sources except 10.99.1.10 on every interface

Correct answer is B. On Cisco IOS, the snmp-server community command accepts an optional ACL parameter at the end. When an ACL is referenced, only source IP addresses permitted by that ACL are allowed to use that community string. Any SNMP request from an IP not permitted by the ACL is discarded — the community string is ignored even if correct. This is the standard way to restrict SNMP access to specific management hosts. The ACL must be a standard ACL (matches source IP). Option A configures the community string and trap destination but does not restrict which sources can poll. Option D would work but is more complex and could inadvertently block other legitimate traffic on the interface ACL.

10. A network uses SNMPv2c for monitoring. The security team raises a concern that SNMP community strings could be captured from network traffic. What is the correct upgrade path, and which SNMPv3 security level should be configured?

A. Upgrade to SNMPv3 and configure noAuthNoPriv — the username is enough additional security compared to a community string B. Enable service password-encryption on all devices — this encrypts the community strings in transit C. Upgrade to SNMPv3 with authNoPriv — authentication ensures messages are legitimate even if readable D. Upgrade to SNMPv3 and configure authPriv (authentication with SHA + encryption with AES). This ensures SNMP messages are authenticated (preventing spoofing) AND encrypted (preventing eavesdropping of credentials and device data). noAuthNoPriv and authNoPriv do not solve the eavesdropping problem.

Correct answer is D. The security team's concern is eavesdropping — an attacker capturing packets on the network can read SNMPv2c community strings. SNMPv3 noAuthNoPriv only adds a username but does not encrypt — an attacker can still read the username and SNMP data from captured packets. SNMPv3 authNoPriv adds HMAC authentication — this prevents message spoofing and tampering, but the message content (including OID values and the authentication exchange) is still readable in cleartext by anyone with a packet capture. Only SNMPv3 authPriv with AES encryption makes the SNMP session unreadable to eavesdroppers — the entire SNMP PDU is encrypted. For production environments, always configure authPriv with SHA-256 (or SHA-512 on modern IOS) for authentication and AES-256 for privacy. See: SNMP v2c & v3 Configuration Lab

← Back to Home