Simple Network Management Protocol (SNMP)

1. Why Networks Need Management

A corporate network can contain hundreds or thousands of routers, switches, servers, printers, and workstations. An administrator needs current information about device availability, interface counters, link utilisation, and resource thresholds. Manual access to each device cannot provide that information at the required scale or frequency.

A standardized, scalable method is therefore needed to monitor and manage network devices. The Simple Network Management Protocol (SNMP) provides that method. It defines messages and object names that devices and management applications can use to exchange management information over an IP network. An NMS can then collect the information, display it, and apply alerting or configuration policies.

2. Core Components of the SNMP Architecture

The SNMP architecture uses a manager and managed entities. A managed device can host an SNMP agent, while a Network Management Station (NMS) runs manager applications and receives notifications. The separation lets a manager use the same protocol operations across different device vendors, while each agent maps those operations to its local hardware and software state.

• Managed Device

  This is any device on the network that contains information that needs to be monitored or managed. This can be anything from a simple printer to a complex core router. Examples include switches, servers, workstations, firewalls, and even environmental sensors.

• SNMP Agent

  The SNMP agent is a software module that runs on a managed device. It exposes local management information, such as memory usage, CPU load, or interface statistics, as SNMP objects. It listens for requests from a manager, obtains the requested values, and sends responses. It can also originate notifications when a configured event occurs.

• Network Management Station (NMS)

  The NMS is the management application used by administrators to monitor and control the network. It queries agents on managed devices, collects performance data, displays graphs or dashboards, and analyzes the results for trends or faults. The NMS can also receive notifications such as traps and informs sent by agents.

3. MIB and OID Definitions

The NMS and agents need shared definitions for the management information they exchange. These definitions are supplied by the Management Information Base (MIB) modules and Object Identifiers (OIDs).

The Management Information Base and MIB modules

The MIB is a formal specification that defines manageable objects, their identifiers, types, and access information. A MIB module is commonly represented as text using the Structure of Management Information (SMI), whose notation is based on ASN.1 (Abstract Syntax Notation One). For each parameter, such as system uptime or the number of packets on interface 2, the MIB defines several properties:

• A textual name (e.g., 'sysUpTime').
• A unique address, called an Object Identifier (OID).
• The data type of the parameter (e.g., integer, counter, string).
• The access rights (e.g., read-only or read-write).

The MIB itself is a schema, not a database that must be stored on the device. The NMS loads the relevant MIB module to interpret the object names and values received from an agent. The agent can implement the objects without carrying the module text. The module also records object syntax and access rules, which keeps the interpretation of a returned value consistent between tools.

Object identifiers and the MIB tree

The OID is a unique address for a managed object or object instance. OIDs form a global hierarchy, often called the MIB tree. Its roots and branches are assigned through international standards organizations such as ISO and ITU, with subtrees delegated to other organizations. For example:

When an NMS wants to know the system description of a device, it requests the value of the OID $1.3.6.1.2.1.1.1.0$. The final $.0$ is an instance identifier, indicating that this is a scalar object (an object that has only one instance). For tabular objects, like an interface table, the instance identifier would correspond to the row index (e.g., the interface number).

4. Core SNMP Operations

The NMS and agents communicate with a small set of Protocol Data Units (PDUs). Each PDU identifies an operation and carries object names, values, or status information.

• GET Request: This is a message sent from the NMS to an agent to retrieve the value of one or more specific OIDs. For example: "GET $1.3.6.1.2.1.1.1.0$".
• GETNEXT Request: This is used to "walk" the MIB tree. It asks the agent for the value of the OID that comes next in the MIB tree after the one specified. This is useful for discovering all the objects a device supports or for reading all the rows in a table without knowing how many rows there are.
• GETBULK Request:Defined for the SNMPv2 protocol family and also used by SNMPv3, this operation extends the idea of GETNEXT. It allows an NMS to request a block of data in one transaction (for example, "give me the next 10 objects"), reducing round trips when polling large tables such as routing tables.
• SET Request:Sent from the NMS to an agent to change the value of a managed object, provided that object is defined as read-write in the MIB. This is how SNMP is used for management and configuration (e.g., changing a device's contact name or shutting down an interface).
• TRAP: Unlike the previous commands initiated by the manager, a TRAP is an unsolicited, asynchronous notification sent from an agent to an NMS. Agents can be configured to send traps for events such as a link going down, a device rebooting, or an authentication failure. A trap has no acknowledgement requirement, so the agent cannot determine from the operation whether the manager received it.
• INFORM: An INFORM is similar to a TRAP, but it is a confirmed notification. When an agent sends an INFORM, it expects an acknowledgment from the NMS. If no acknowledgment is received, the agent can re-send the INFORM. This provides more reliability for critical alerts.
• Response: This is the message used by the agent to send back the data requested by GET, GETNEXT, or GETBULK messages, or to confirm the success/failure of a SET command.

5. Evolution of SNMP Versions and Security

SNMP versions differ in their protocol operations and security models. The changes from SNMPv1 through SNMPv3 address scalability, counter size, authentication, privacy, and access control.

• SNMPv1: The First Version

  The first version of SNMP relied on a very simple authentication mechanism called community strings. These were essentially plain-text passwords shared between the NMS and all its agents. An NMS would send a community string with its request, and if it matched the one configured on the agent, access was granted. This method is insecure, as anyone who captures the network traffic can read the community string and use it to gain unauthorized access.

• SNMPv2c: Community-based v2

  SNMPv2 introduced several protocol improvements, including the efficient 'GETBULK' operation and support for 64-bit counters (essential for monitoring high-speed network interfaces where 32-bit counters could wrap around too quickly). However, the most widely deployed variant, SNMPv2c, still used the same insecure community-string-based security model as SNMPv1. The 'c' in v2c stands for "community".

• SNMPv3: Standardized Security Models

  SNMPv3 adds a security subsystem and separates security models from access control. The User-based Security Model (USM) is the commonly used model for authenticating messages and providing privacy. It replaces the global community string with individual users and credentials. Access rights are defined separately through the View-based Access Control Model (VACM). Together these mechanisms provide three security services:

  • Authentication: Verifies the message source and detects modification in transit. USM includes the older HMAC-MD5-96 and HMAC-SHA-96 algorithms, while later extensions also define HMAC-SHA-2 variants. The algorithm choice depends on the implementation and deployment policy.
  • Privacy (Encryption): Scrambles the content of the SNMP message to prevent it from being read by eavesdroppers. An older USM variant uses DES, while a USM privacy extension also defines AES; the choice depends on the implementation and deployment policy.
  • Access Control: VACM allows administrators to define precisely which objects a user or security group may read or modify, providing granular management permissions.

  SNMPv3 defines three security levels: 'noAuthNoPriv' (no authentication and no privacy), 'authNoPriv' (authentication without privacy), and 'authPriv' (authentication with privacy). The selected level should follow the deployment policy; "authPriv" supplies both protections when management data requires them.

6. SNMP and the Transport Layer: UDP

SNMP defines transport mappings and is commonly deployed over the User Datagram Protocol (UDP). UDP avoids connection setup and has a small header, which suits polling and notifications, but it does not guarantee delivery or ordering and does not provide retransmission or error correction for damaged datagrams. Its checksum can detect some corruption when it is used.

• The NMS sends requests to the agent's port $161$.
• The agent sends TRAPs or INFORMs to the NMS's port $162$.

Because UDP is connectionless, delivery failures remain possible and the transport does not order messages. For notifications that need confirmation, the 'INFORM' PDU requires an acknowledgement and the application can retransmit it, adding reliability above UDP.