Introduction to SNMP

1. Introduction to SNMP

Simple Network Management Protocol (SNMP) introduce in 1988 and declared in RFC 1157 is a protocol used for monitoring and managing devices on a network.

It allows network administrators to collect information about devices, monitor their status, and even control them remotely. SNMP simplifies the management of various devices like routers, switches, and servers.

Think of the SNMP Server as a doctor monitoring the health of their patients (the network devices).

Purpose and Importance of SNMP in Networking

SNMP plays a vital role in ensuring the health and performance of a network. Its main benefits include:

• Centralized Monitoring: Administrators can oversee the health of all devices from a single management station.
  Example: An administrator can monitor the CPU usage of routers across the network from one tool.

• Real-Time Alerts: SNMP sends immediate alerts (Traps) to notify administrators of critical events like a failed interface or high CPU usage.
  Example: If a switch port goes down, the SNMP Manager receives an alert in real time, enabling quick action.

• Remote Configuration: Administrators can modify device configurations without physical access.
  Example: An administrator can change a router’s hostname remotely through the SNMP Manager.

2. SNMP Architecture

The NMS (Network Management Station) acts as the central system that communicates with network devices to monitor and manage them. It sends requests for data (such as CPU usage, memory, or traffic) and can issue commands to adjust configurations.

Each device runs an SNMP Agent that responds to these requests and can also generate alerts (Traps or Informs) to notify the Manager of critical events, such as an interface failure or high CPU usage.

As you can see above, the NMS can communicate with this router by using the SNMP protocol.

To make this exchange possible, device information must be structured and accessible. This is where the Management Information Base (MIB) comes into play.

Management Information Base (MIB)

The MIB is a hierarchical database that organizes device information accessible via SNMP. It serves as a reference for retrieving or updating network metrics and configurations.

Structure:

• Organized in a tree-like hierarchy
• Standardized branches store general data such as system uptime
• Vendor-specific branches (e.g., Cisco-specific metrics) provide manufacturer-specific information

Example MIB Tree

MIB-2 (1.3.6.1.2.1)
├── system (1)                       // General device information
│   ├── sysDescr (1.3.6.1.2.1.1.1)   // Device description
│   ├── sysUpTime (1.3.6.1.2.1.1.3)  // Device uptime
├── interfaces (2)                   // Network interfaces
│   ├── ifNumber (1.3.6.1.2.1.2.1)   // Number of interfaces
│   └── ifTable (1.3.6.1.2.1.2.2)
└── enterprises (4.1)
    └── Cisco (9)                    // Vendor-specific data

The MIB enables consistent device management by defining where each type of data (CPU usage, memory status, interface count, etc.) is stored. This standardization ensures compatibility across devices from different vendors.

Object Identifiers (OIDs)

OIDs are unique numerical addresses used to identify data points in the MIB. You can think of an OID as the precise address that points to a specific piece of information.

• Format: Dot-separated sequence (e.g., 1.3.6.1.2.1.1.3 for system uptime). Each level in the sequence represents a branch in the MIB tree.

• Role in SNMP: The Manager sends requests that reference OIDs. The Agent retrieves the corresponding value from the MIB and sends it back.

Example: Retrieving Uptime with an OID

A network administrator wants to check the uptime of a router.

1. The SNMP Manager sends a Get Request for OID 1.3.6.1.2.1.1.3.
2. The SNMP Agent on the router looks up the corresponding value in its MIB.
3. The Agent replies with the uptime, which the Manager displays for analysis.

This ensures precise and efficient monitoring across network devices.

3. Basic SNMP Operations

SNMP allows the Manager to interact with network devices through their Agents. SNMPv1 relies on four essential message types. Other types exist, but they will be introduced when we cover SNMPv2 and SNMPv3.

SNMP Message Types

• Get – Retrieves specific information from an SNMP Agent.
• GetNext – Retrieves the next item in a list, useful for tables.
• Set – Modifies a configuration parameter remotely.
• Trap – Sends an alert when a critical event occurs.

SNMP Get Request

The Get Request is the most common operation. It is initiated by the SNMP Manager to retrieve specific data from an Agent, such as device status, CPU load, memory usage, or interface statistics.

Imagine a network administrator wants to monitor CPU usage on a router. The Manager sends a Get Request to the router’s Agent, which replies with the current CPU load.

SNMP Set Request

The Set Request allows the SNMP Manager to change a configuration parameter on a device through its Agent. Unlike the Get Request, which only retrieves information, the Set Request directly modifies device settings.

The SNMP The Manager sends a Set Request to change a router’s hostname from Router1 to BranchRouter1. The Agent applies the change, updating the device configuration.

SNMP Traps

SNMP Traps are alerts sent by the SNMP Agent to the SNMP Manager when specific events occur, such as a device rebooting, an interface going down, or a high CPU load. Unlike Get and Set Requests, Traps are initiated by the Agent, providing real-time updates without needing constant checks from the SNMP Manager.

Example: When an interface on a switch goes down, the SNMP Agent on the switch sends a Trap to notify the SNMP Manager, allowing the administrator to investigate the issue quickly.

Polling vs. Traps

SNMP provides two distinct mechanisms for monitoring device status. Here’s how they compare:

Mechanism	Trigger	Communication	Best Use Case
Polling	Manager requests data periodically	Manager-initiated	Routine performance monitoring
Traps	Event-driven notification by Agent	Agent to Manager (one-way)	Immediate event notifications

Summary of SNMP Operations

The following table summarizes SNMP operations, their purposes, and typical use cases:

Operation	Purpose	Example	Use Case
Get	Retrieve specific information	Checking CPU load on a router	Routine monitoring
GetNext	Retrieve sequential data items	Querying interfaces on a switch	Detailed data retrieval
Set	Change device configuration	Adjusting alert thresholds	Remote configuration
Trap	Real-time alert for critical events	Notifying an interface going down	Immediate alerts without constant polling

4. SNMP Configuration

To use SNMP in practice, the managed device (for example, a router) must first allow access to its Management Information Base (MIB). This is done with community strings, which act like simple passwords and define what an SNMP Manager can do.

Step 1 – Define Community Strings

Community strings are the foundation of SNMPv1 and SNMPv2c. They determine the level of access granted to the Manager:

• Read-Only (RO):
  The Manager can retrieve information but cannot change anything. This is the safest and most commonly used option.

R1(config)# snmp-server community MONITOR-RO RO

→ With this configuration, the community string MONITOR-RO gives the Manager read-only access to the router’s MIB (for example, uptime or interface counters).

• Read-Write (RW):
  The Manager can both read and modify configurations on the device. This mode should be used very carefully, as it allows remote changes.

R1(config)# snmp-server community ADMIN-RW RW

→ With this string, ADMIN-RW, the Manager can make changes such as updating the hostname.

In real networks, Read-Only is almost always preferred, while Read-Write is avoided unless strictly necessary.

Step 2 – Configure SNMP Ports

SNMP exchanges rely on two well-known UDP ports:

• UDP 161 → Used for standard operations (Get, GetNext, Set).
• UDP 162 → Used for Traps (event notifications sent from the device to the Manager).

These ports are essential for communication between the NMS and managed devices. In production, they are typically restricted so that only the NMS can use them.

Step 3 – Verify Configuration on the Router

After configuration, you can confirm the community strings with the following command:

R1# show snmp community
Community name: MONITOR-RO
Community access: RO
Community name: ADMIN-RW
Community access: RW

This output confirms that:

• MONITOR-RO has Read-Only access.
• ADMIN-RW has Read-Write access.

Step 4 – Querying the Router from an SNMP Manager

Once the router is configured, an SNMP Manager can poll it.

For example, an administrator on an NMS (192.168.1.100) wants to check the system uptime of router R1 (192.168.1.1). This information is stored in the MIB under OID 1.3.6.1.2.1.1.3.0.

Command executed from the NMS:

$ snmpget -v1 -c MONITOR-RO 192.168.1.1 1.3.6.1.2.1.1.3.0
SNMPv2-MIB::sysUpTime.0 = Timeticks: (123456) 14:23:45.67

Explanation:

• -v1 → specifies SNMP version 1.
• -c MONITOR-RO → uses the Read-Only community string configured on the router.
• 192.168.1.1 → IP address of the router.
• 1.3.6.1.2.1.1.3.0 → OID for system uptime.

The output returns the uptime in Timeticks, which can be converted into hours, minutes, and seconds.

5. Conclusion

In this lesson, we introduced SNMP and its role in network management.

• We covered the four SNMPv1 operations: Get, GetNext, Set, and Trap.
• We explained the difference between polling (Manager-driven requests) and traps (Agent-driven alerts).
• We configured SNMP on a router using community strings, verified the setup, and showed a real query from an SNMP Manager.

This demonstrates how SNMP provides both visibility (monitoring) and control (remote management) across a network.

In the next lesson, we will explore SNMPv2, which extends these capabilities with additional message types and performance improvements.