VMware ESXi and vSphere Cluster Management

Simple Network Management Protocol (SNMP): Network Monitoring and Management

Learn how SNMP managers and agents communicate, how MIBs and OIDs organize data, which UDP ports SNMP uses, and why SNMPv3 is preferred for secure monitoring.

Simple Network Management Protocol (SNMP) is an application-layer protocol for monitoring and managing information from network-attached devices. It lets a network management station collect operational data, display trends, and receive alerts when important events occur.

SNMP is commonly used with routers, switches, servers, printers, firewalls, wireless controllers and access points, power devices, storage systems, and other infrastructure endpoints.

SNMP Purpose and Application-Layer Role

SNMP operates at the application layer of the TCP/IP model. It defines messages and data structures that management software uses to request information from devices or receive device-generated notifications.

SNMP primarily provides visibility. An NMS can use it to monitor interface status, traffic counters, CPU utilization, memory usage, uptime, temperature, and error counts. Some SNMP objects are writable, so SNMP can also modify selected device settings through the SET operation. However, configuration through SNMP should be tightly controlled and is less common in monitoring-only deployments.

SNMP is not a replacement for every management method. Administrators may use a command-line interface, an HTTPS interface, automation APIs, or model-driven telemetry for configuration and more detailed operational workflows.

SNMP-Managed Network Architecture

A typical SNMP deployment contains a management platform and many managed devices.

• Network Management Station (NMS): The management platform that polls devices, receives notifications, stores measurements, creates graphs, and alerts administrators. It is also called an SNMP manager.
• SNMP manager: The management-side process that sends requests to agents and processes responses, traps, and informs.
• Managed device: A network-attached device being monitored or managed.
• SNMP agent: Software running on a managed device. It collects local device data, exposes management objects, responds to requests, and can generate notifications.

The relationship is many-to-one from the NMS perspective: one NMS can communicate with many agents. For example, an NMS may poll a router, switch, firewall, server, and printer, each of which provides information through its local agent.

MIBs and OIDs

A Management Information Base (MIB) is an organized collection of management objects. An object represents a value or capability that SNMP can query, monitor, or sometimes modify.

An Object Identifier (OID) is the unique hierarchical numeric identifier assigned to a managed object. OIDs form a tree. A manager does not need to memorize the entire numeric tree; NMS software commonly uses MIB definitions to display readable names and interpret returned values.

• Interface operational state
• Interface input and output counters
• Packet and error counts
• CPU utilization
• Memory usage
• System uptime
• Temperature and power status
• Device restart or hardware alarms

Standard MIBs describe widely used objects. Vendors can publish vendor-specific MIBs that expose additional information, such as platform sensors, hardware modules, wireless client data, or specialized firewall statistics.

Polling and Event-Driven Notifications

Manager-Initiated Polling

Polling is the periodic process in which the NMS requests values from an agent. For example, an NMS may query a switch every five minutes for interface state, traffic counters, and error counters. It can graph the results and alert when an error rate or utilization threshold is exceeded.

Polling provides regular measurements and can detect conditions even when a device does not send a notification. Its disadvantages include traffic overhead and a delay between an event and the next poll.

Agent-Originated Notifications

A device can send a notification when a significant event occurs instead of waiting for the next poll. Examples include an interface state change, high temperature, device restart, or port-security violation.

• Trap: An unsolicited, unacknowledged notification sent by an agent to an NMS. The sender does not require confirmation that the NMS received it.
• Inform: A notification that requests acknowledgment from the receiving manager. This provides stronger delivery confirmation than a trap, although it adds response traffic.

Polling supports proactive measurement and trend analysis. Notifications support rapid incident detection. A production monitoring design commonly uses both.

SNMP Operations

GETNEXT is useful when a manager needs to traverse a sequence of objects, such as interface entries. GETBULK reduces the number of exchanges when retrieving many values, especially from tables. SET can change writable values, but read-only access is usually safer for monitoring.

SNMP Transport and UDP Ports

SNMP normally uses UDP. UDP avoids connection setup and keeps management exchanges lightweight, but it does not itself guarantee delivery.

UDP port 161 is the standard destination port where agents receive manager requests. UDP port 162 is the standard destination port where the NMS receives traps and informs. These assignments describe the receiving service: requests go to the agent on 161, while notifications go to the manager on 162.

SNMP Versions and Security

A community string is a shared value used by SNMPv1 and SNMPv2c. It provides basic access control but is not equivalent to strong authentication. Community strings can be exposed through traffic capture or poor configuration, and those versions do not provide adequate modern confidentiality and integrity protections.

SNMPv3 uses named users and can provide the following protections:

• Authentication: Verifies the identity associated with a message and helps detect unauthorized modification.
• Integrity protection: Helps ensure that a message was not changed in transit.
• Privacy: Encrypts the contents of the message.
• User-based access control: Associates users with groups, views, permissions, and security policies.

SNMPv3 Security Levels

• noAuthNoPriv: No authentication and no encryption.
• authNoPriv: Authentication and integrity protection, but no encryption.
• authPriv: Authentication, integrity protection, and encryption. This is normally the strongest choice when supported by the environment.

Use read-only access for monitoring identities whenever possible. Apply least privilege, restrict permitted NMS source addresses with ACLs, isolate the management plane, and avoid exposing SNMP to untrusted networks. Disable SET access or limit writable views unless a documented operational requirement exists.

Operational Example: Port-Security Alerting

Consider a switch configured to send SNMP notifications to an NMS:

1. An unauthorized device causes a port-security violation on an access interface.
2. The switch detects the event locally.
3. The SNMP agent creates a trap containing event details such as the interface and violation type.
4. The switch sends the trap to the NMS notification listener at UDP port 162.
5. The NMS records the event, correlates it with the device and interface, and alerts an administrator.

This trap is different from normal polling. During polling, the NMS periodically sends a request to the switch agent at UDP port 161. The trap is unsolicited: the switch sends it when the event happens, without waiting for the next poll.

Basic Cisco IOS SNMPv3 Configuration Concepts

The following example creates a read-only SNMPv3 identity, limits access to one NMS address, configures the NMS as a notification receiver, and enables notifications. Replace the example address and credential placeholders according to your security policy.

ip access-list standard SNMP-MANAGERS
 permit 192.0.2.10
snmp-server view MONITOR iso included
snmp-server group NMS-GROUP v3 priv read MONITOR access SNMP-MANAGERS
snmp-server user nmsuser NMS-GROUP v3 auth sha <auth-password> priv aes 128 <privacy-password>
snmp-server host 192.0.2.10 traps version 3 priv nmsuser
snmp-server enable traps

• ip access-list standard SNMP-MANAGERS identifies approved management sources.
• snmp-server view defines the objects visible to the group. A production view should expose only the required data where practical.
• snmp-server group associates the group with SNMPv3 privacy, a read view, and the source ACL.
• snmp-server user creates the SNMPv3 user and selects authentication and privacy algorithms.
• snmp-server host defines the NMS notification destination and SNMPv3 security settings.
• snmp-server enable traps enables notification generation. Operational policy should select only the categories that are needed rather than enabling unnecessary event types.

Verification Commands

show snmp
show snmp user
show snmp group
show snmp host
show access-lists SNMP-MANAGERS
show running-config | section snmp

• show snmp displays general SNMP status and counters.
• show snmp user verifies configured SNMPv3 users and security settings.
• show snmp group verifies group security levels, views, and access relationships.
• show snmp host verifies notification destinations and versions.
• show access-lists SNMP-MANAGERS verifies the permitted management sources and ACL matches.
• show running-config | section snmp displays the active SNMP-related configuration for comparison with the NMS settings.

Connectivity and Deployment Requirements

• Permit UDP 161 from the NMS to managed devices for polling.
• Permit UDP 162 from managed devices to the NMS for traps and informs.
• Apply these permissions only on approved management paths.
• Restrict SNMP source addresses with device ACLs and network firewalls.
• Send logs and notifications only to authorized management systems.
• Use accurate device identity information and synchronized clocks so the NMS can correlate events correctly.

Successful polling does not prove that traps are correctly configured. Polling and notifications can use different destination addresses, security settings, ACL paths, and receive ports. A device can answer requests on UDP 161 while its traps are sent to the wrong NMS address or blocked before reaching UDP 162.

SNMP Troubleshooting

The NMS Cannot Poll a Device

• Confirm IP routing and management-interface reachability between the NMS and device.
• Check whether UDP 161 is blocked by an ACL, firewall, security policy, or intermediate path.
• Compare the SNMPv3 username, security level, authentication algorithm, privacy algorithm, and credentials on both sides.
• Verify that the NMS source address is allowed by the device's SNMP ACL.
• Confirm that the SNMP agent is enabled and that the user, group, and view permissions exist.

Polling Works but No Traps Arrive

• Verify that a notification destination is configured with the correct NMS address.
• Check the notification version and SNMPv3 security settings.
• Confirm that UDP 162 is allowed on the route and at the NMS host firewall.
• Verify that the relevant trap category is enabled.
• Confirm that the NMS is listening for notifications.
• Generate a controlled test event where appropriate and inspect device and NMS event logs.
• Check that the device uses the expected source interface and address when sending notifications.

SNMPv3 Authentication or Decryption Errors

• Check for a security-level mismatch, such as authPriv expected by one side but authNoPriv configured by the other.
• Compare credentials and authentication and privacy algorithms exactly.
• Review the NMS credential entry if the device was replaced, restored, or assigned a different SNMP engine identity.
• Confirm that both endpoints support the selected security algorithms.

Exam-Ready Summary

• SNMP is an application-layer network monitoring and management protocol.
• The NMS or SNMP manager sends requests and processes responses and notifications.
• The SNMP agent runs on the managed device and exposes local management information.
• A MIB organizes management objects; an OID uniquely identifies an object in the hierarchy.
• GET requests one value; GETNEXT and GETBULK retrieve successive values efficiently; SET modifies writable values.
• Agents normally receive manager requests on UDP 161.
• NMS systems normally receive traps and informs on UDP 162.
• Traps are unacknowledged notifications; informs request acknowledgment.
• SNMPv1 and SNMPv2c use community strings and lack adequate modern security protections.
• SNMPv3 supports user-based security, authentication, integrity protection, and privacy encryption.
• Read-only permissions, least privilege, ACLs, and management-plane isolation reduce risk.

For related study, see the SNMP reference lesson.