CCNA online course

Simple Network Management Protocol (SNMP) for CCNA

Learn SNMP architecture, MIBs, OIDs, operations, versions, security, ports, Cisco IOS configuration, monitoring data, and troubleshooting for CCNA.

Simple Network Management Protocol (SNMP) is an application-layer protocol used to monitor and, when permitted, manage networked devices. Network management systems use SNMP to collect information from routers, switches, firewalls, wireless controllers, servers, and other managed devices.

SNMP is primarily a network-operations tool rather than an application used directly by end users. An NMS polls devices for status and counters, stores the results, displays dashboards, and creates alerts. Devices can also send event notifications when important changes occur.

SNMP Purpose and Use Cases

SNMP provides visibility into device health and network performance. Common monitoring data includes interface state, traffic counters, errors, discards, CPU and memory use, system uptime, environmental sensors, inventory, and vendor-specific status.

• Interface monitoring: Determine whether an interface is administratively enabled and operationally up.
• Performance monitoring: Calculate traffic rates and utilization from inbound and outbound counters.
• Fault detection: Identify rising error counters, failed fans, high temperature, power problems, or link-state changes.
• Inventory: Collect system descriptions, serial-related data when supported, software information, hardware details, and neighbor information.
• Capacity planning: Compare traffic and resource-use trends against historical baselines.

SNMP supports two complementary monitoring styles:

• Polling: The NMS periodically sends requests to an agent and receives current object values. For example, it can poll interface byte counters every five minutes.
• Event-driven notification: An agent sends a trap or inform when a configured event occurs, such as an interface going down. Notifications can reduce detection delay, but they should complement polling rather than replace it.

SNMP Architecture

Manager, agent, and managed device

An SNMP manager is the system that sends queries, receives notifications, stores results, and presents information to administrators. A complete network management system (NMS) commonly acts as the SNMP manager. It may include polling, graphing, alerting, reporting, and inventory functions.

An SNMP agent is software running on a managed device. The agent obtains local information from the device operating system and hardware, exposes that information as managed objects, and returns values to authorized managers. A managed device is the router, switch, firewall, wireless device, server, or other system being monitored.

A typical polling exchange works like this:

1. The NMS sends a request for one or more object identifiers (OIDs).
2. The agent checks the request against its configured security and access rules.
3. The agent reads the requested values from the device.
4. The agent returns a response containing values or an error.
5. The NMS stores the result and may calculate rates, compare thresholds, or create an alert.

The information exposed by an agent is organized into a Management Information Base. SNMP itself defines how values are requested and transported; the MIB definitions explain what those values mean.

MIBs and Object Identifiers

Management Information Base

A Management Information Base (MIB) is a structured collection of definitions for managed objects. An object represents a measurable or configurable value, such as system uptime, interface octets, interface status, or a temperature sensor.

A MIB file supplies human-readable names, descriptions, data types, access permissions, and relationships for numeric OIDs. The MIB file is normally loaded by the NMS or an SNMP tool; it is not necessarily stored on the monitored device. The device agent can return numeric OIDs and values even when the manager does not have the corresponding MIB file.

Object identifiers and the OID tree

An object identifier (OID) is a hierarchical numeric identifier for a managed object. Each number represents a branch in a global tree. For example, a system object might be represented in dotted notation as 1.3.6.1.2.1....

A simplified path through common SNMP branches is:

iso(1)
└── org(3)
    └── dod(6)
        └── internet(1)
            ├── directory(1)
            ├── mgmt(2)
            │   └── mib-2(1)
            ├── experimental(3)
            └── private(4)
                └── enterprises(1)

• iso: The International Organization for Standardization branch.
• org: The organizations branch.
• dod: The U.S. Department of Defense branch.
• internet: The branch used for Internet-related definitions.
• mgmt: The management branch.
• mib-2: A common standard group of Internet management objects.
• private enterprises: The branch where vendors publish enterprise-specific objects.

Standard objects such as system name and uptime are useful across many vendors. Enterprise OIDs expose platform-specific information, such as a particular temperature sensor or hardware state. A vendor MIB is needed to translate those numeric enterprise OIDs into meaningful names and descriptions.

Example: polling an interface

An NMS can request an interface's operational status and byte counters. If the inbound counter changes from one poll to the next, the NMS calculates a rate using the counter difference and elapsed time. A rising error counter may lead an administrator to investigate cabling, duplex settings, optics, congestion, or hardware.

SNMP Operations and Message Types

SNMP operations are request and response messages exchanged between a manager and an agent. A walk is not a separate SNMP protocol operation: it is a series of GetNext or GetBulk requests used to traverse a portion of the OID tree.

Get, GetNext, and GetBulk

Get retrieves a specific OID. GetNext asks for the next object after a supplied OID, which allows a manager to discover a table without knowing every entry in advance. GetBulk retrieves multiple values in one exchange and is more efficient for large tables. GetBulk is available in SNMPv2c and SNMPv3, not SNMPv1.

Set and Response

Set changes a writable object. For example, a platform may expose a writable value for a limited configuration operation. Set access is operationally risky because an incorrect value can affect availability or security. Monitoring normally requires read-only access, so write access should be disabled unless there is a specific, documented need.

A Response carries requested values or reports errors such as an unsupported OID, an inaccessible object, or an invalid value.

Traps and informs

A trap is an asynchronous notification sent by an agent without requiring acknowledgement. It is fast, but a lost UDP packet means the manager may never know that the event occurred.

An inform is also asynchronous, but the manager acknowledges it with a Response. If the sender does not receive the acknowledgement, it can retry according to its implementation. Informs are available in SNMPv2c and SNMPv3.

SNMP Versions

In SNMPv1 and SNMPv2c, a community string is a shared text value used to identify and authorize requests. It is not a secure password. Community strings can be transmitted in clear text, so an observer able to capture the traffic may learn them.

SNMPv2c adds useful operations such as GetBulk and Inform, but the “c” means community-based security remains. It does not provide the user authentication and encryption supplied by SNMPv3.

SNMPv3 uses users, groups, security levels, authentication, message integrity, privacy encryption, and access control. Its security levels are:

SNMP Security

• Use SNMPv3, preferably authPriv, whenever supported.
• Use read-only access by default. Configure read-write access only for a clearly justified automation requirement.
• Restrict permitted manager addresses with ACLs, management-plane policies, or equivalent device controls.
• Use a dedicated management network or management VRF where appropriate.
• If v1 or v2c is unavoidable, use unique, non-default community strings and protect them as sensitive credentials.
• Use least privilege: give each monitoring identity only the object access it needs.
• Log authentication failures, configuration changes, and unexpected polling sources.
• Rotate community strings and SNMPv3 credentials according to organizational policy.
• Protect configuration backups because they may contain communities, usernames, or encrypted credential material.

A read-only community permits retrieval but not modification. A read-write community can permit Set operations, making compromise significantly more damaging. In the legacy scenario, a monitoring server might use a read-only community and an ACL that permits only 192.0.2.10; there is no reason to configure a read-write community for ordinary polling.

Transport Protocols and Ports

SNMP normally uses UDP. Requests and responses use UDP port 161. Traps and informs are normally sent to the manager on UDP port 162.

Firewalls and ACLs must allow UDP 161 from authorized managers to agents and allow return traffic. They must also allow UDP 162 from authorized devices to the NMS when traps or informs are used. Routing, UDP loss, filtering, control-plane policies, management VRFs, and the selected source interface can all affect operation.

Cisco IOS SNMP Configuration Concepts

Legacy SNMPv2c read-only access

The following example permits only one monitoring host to poll a Cisco IOS device with a read-only community:

access-list 10 permit 192.0.2.10
snmp-server community <read_only_community> ro 10

Replace the example address with the actual NMS address and use a unique community value. This is a legacy compatibility example; prefer SNMPv3 in production.

Device identification

snmp-server contact <operations_contact>
snmp-server location <site_and_rack_or_room>

Contact and location values help operations staff identify ownership and physical placement when an alert appears.

Trap receiver

snmp-server host 192.0.2.10 version 2c <notification_community>
snmp-server enable traps

The NMS must be reachable and listening for UDP 162. Enable only useful notification categories where the IOS release supports category-specific selection; indiscriminate notification generation can create alert noise.

SNMPv3 group and user

snmp-server group <group_name> v3 priv
snmp-server user <username> <group_name> v3 auth sha <auth_password> priv aes 128 <privacy_password>
snmp-server host 192.0.2.10 version 3 priv <username>

This creates a group requiring authentication and privacy, creates a user in that group, and configures a notification destination. Exact algorithms and syntax vary by IOS release and platform. Use strong unique secrets, protect configuration backups, and add an ACL or named view when a more restrictive policy is required.

Verification

show running-config | include snmp
show snmp
show snmp community
show snmp user
show snmp group

Available commands vary by IOS family and software version. Verification should include both device output and a real polling test from the NMS.

Monitoring Data Commonly Collected

• Interface administrative and operational status.
• Inbound and outbound octet and packet counters.
• Interface errors, discards, collisions where applicable, and calculated utilization.
• CPU and memory utilization.
• System name, description, uptime, contact, and location.
• Temperature, fan state, power status, and other environmental data when supported.
• Neighbor, hardware inventory, software, and vendor-specific telemetry where exposed by the platform.

Operational Design and Best Practices

• Choose SNMPv3 when the device and monitoring platform support it.
• Use read-only monitoring as the default.
• Permit polling only from known NMS addresses and preferably across a dedicated management path.
• Set consistent names, contact values, and physical locations across devices.
• Choose trap and inform categories deliberately to avoid alert fatigue.
• Poll often enough to detect relevant changes, but avoid unnecessary load on devices and the NMS.
• Use baselines and thresholds. A counter increasing normally is not itself a fault; the rate, error relationship, and historical behavior matter.
• Use 64-bit high-capacity counters on high-speed interfaces when available. Counters can wrap, especially older 32-bit counters, and a wrap can look like a sudden decrease.
• Document communities and SNMPv3 users securely, and standardize approved configuration templates.

For time-correlated alerts and logs, consistent clock settings are important; see configuring NTP on a Cisco device. SNMP is also one part of a broader monitoring design that may include syslog, NetFlow or IPFIX, and streaming telemetry.

Troubleshooting SNMP

The monitoring server cannot poll the device

1. Confirm IP reachability between the manager and agent.
2. Verify that UDP 161 is not blocked by an ACL, firewall, control-plane policy, or management VRF problem.
3. Confirm that the manager and device use the same SNMP version.
4. For v1 or v2c, verify the community string and its associated ACL.
5. For v3, verify the username, group, security level, authentication algorithm, privacy algorithm, and secrets.
6. Confirm that the agent is enabled and supported on the platform.

Traps or informs are not received

• Verify the configured destination address.
• Verify UDP 162 reachability and that the NMS is listening.
• Confirm that the relevant notification category is enabled.
• Check routing and source-interface selection, especially with multiple interfaces or VRFs.
• Confirm that the NMS accepts the configured version and, for informs, the required credentials.

SNMPv3 authentication or privacy failures

• Ensure both sides use the same security level.
• Verify the username, authentication algorithm, privacy algorithm, and secrets.
• Check platform support for the selected algorithms.
• Review NMS logs for engine-ID discovery or time-synchronization issues where applicable.

Object names cannot be resolved

Load the appropriate standard or vendor MIB files on the management system. Confirm that the device software and hardware support the requested OID. Testing with a numeric OID helps distinguish a MIB-name resolution problem from an SNMP communication problem.

Interface counters or utilization appear incorrect

• Check the polling interval and counter type.
• Account for counter rollover, especially with 32-bit counters on fast interfaces.
• Use 64-bit counters when supported.
• Confirm that the NMS calculates rates from counter deltas and elapsed time correctly.

Exam-Relevant Notes

• SNMP is an application-layer protocol.
• UDP 161 is used for manager queries and agent responses; UDP 162 is used for traps and informs.
• SNMPv2c adds GetBulk and Inform but still relies on insecure community strings.
• SNMPv3 provides user-based authentication, integrity, encryption, groups, and access control.
• noAuthNoPriv means no authentication and no encryption; authNoPriv means authentication without encryption; authPriv means authentication with encryption.
• Traps are unacknowledged; informs require acknowledgement.
• GetBulk is available in SNMPv2c and SNMPv3, not SNMPv1.
• A MIB explains OIDs for people and tools; it is not necessarily stored on the device.
• SNMP walks use repeated GetNext or GetBulk operations.

Practical SNMP Scenarios

Polling a router interface

The NMS queries the router agent for interface status and byte counters. It calculates traffic rates from counter changes between polling intervals. If an error counter rises, the administrator investigates physical media, duplex, optics, or congestion.

Receiving a link-state event

A switch detects an interface transition from up to down and sends a trap or inform. The monitoring server associates the event with the interface and creates an alert. Polling can then confirm the current state.

Secure SNMPv3 deployment

The network team creates an SNMPv3 group requiring authentication and privacy, assigns a monitoring user limited read access, and configures the NMS with matching security parameters. The NMS can then poll device health without exposing a community string or unencrypted monitoring content.

Interpreting an OID

A tool requests a standard object such as system name or uptime. The NMS uses a MIB to display the numeric OID as a meaningful object name. A vendor enterprise OID may be required for a platform-specific sensor, such as temperature.