SNMP Monitoring: A Guide for MSPs

The simple network management protocol (SNMP) isn’t the newest or most glamorous topic in IT. However, SNMP monitoring remains one of the most practical remote monitoring capabilities an MSP can have in their toolbox.

Devices from a wide range of vendors support SNMP, it provides a wealth of data, and drives standardization where teams would otherwise need a custom solution. Simply put, while hyperscalers may have moved on from SNMP monitoring, it’s still helping the rest of us get work done.

In this article, we’ll take a deep dive into what SNMP monitoring is, how it works, and key tips and best practices to help you get your implementation right.

How does SNMP monitoring work?

SNMP monitoring enables an SNMP manager to monitor managed devices in two ways:

• Synchronously – “Polling” using SNMP commands such as GET, GETBULK, and WALK
• Asynchronously- Receiving notifications such as SNMP TRAPs and INFORMs.

Because SNMP is such a widely used protocol, SNMP monitoring is one of the most practical ways for administrators to monitor a variety of devices across their networks. The sections below will break down each of the key components of the SNMP monitoring process.

SNMP manager

The SNMP manager is the system that uses SNMP to monitor and manage other devices. For example, an administrator may run a network management tool on a server that centralizes SNMP monitoring for all the devices on their network.

SNMP agent

SNMP agent software runs on a managed device and enables SNMP communication to an SNMP manager. In many cases, managed devices simply need SNMP enabled and configured, and no additional software installation is required to use an SNMP agent.

Managed devices

Managed devices are the endpoints that run SNMP agent software. The devices expose metrics (CPU utilization, disk space, etc.) and information to the SNMP agent. The agent then makes that data available to management and monitoring tools. Common examples of managed devices include printers, uninterruptible power supplies (UPSes), switches, routers, servers, and firewalls.

Common SNMP monitoring commands

There are several standard SNMP commands that SNMP managers and agents use to communicate with one another. The table below details X of the most common commands and their use cases.

Note: Our example commands in the table below and throughout the remainder of this article use the popular open-source Net-SNMP application.

SNMP Command	Supported SNMP version (v1, v2c, or v3)	Use case	Example Net-SNMP command
GET	All	Retrieve data for a specific OID. Sent from a manager to an agent.	snmpget -v 1 -c public manageddevice.example.com 1.3.6.1.2.1.1.1.0
SET	All	Set a value to modify a configuration or execute a command on a device.	snmpget -v 1 -c private manageddevice.example.com sysLocation.0 s “Eating a pepper and egg on the dock of the bay”
WALK	All	Retrieves all the OIDs under a specific subtree.	snmpwalk -v 1 -c public manageddevice.example.com 1.3.6.1.2.1.1
GETNEXT	All	Retrieve the next value after a specific OID.	snmpgetnext -v 1 -c public manageddevice.example.com 1.3.6.1.2.1.1.6
GETBULK	v2c and v3	Efficiently retrieve multiple data points without multiple GETNEXT commands.	snmpbulkget -v 2c -c public manageddevice.example.com 1.3.6.1.2.1.1

In addition to these commands which are sent from an SNMP manager to an SNMP agent running on a managed device, TRAPs (v1, v2c, and v3) and INFORMs (v2c and v3) can be sent from managed devices to SNMP managers.

TRAPs and INFORMs are useful for ad-hoc alerting and notifications. For example, a network switch might send an SNMP TRAP if an interface goes down. The key difference between SNMP TRAPs and INFORMs is that an SNMP agent will send repeat messages if an INFORM is not acknowledged by the recipient.

Understanding SNMP ports

SNMP traffic being blocked by a firewall or security appliance is a common issue you might run into when configuring SNMP. Because of how SNMP works, it can be easy to get confused by the logic.

Here’s what you should know:

1. SNMP has two default UDP ports, 161 and 162.
2. UDP 161 needs to be open on the SNMP agents being monitored if you want them to respond to active SNMP monitoring requests (e.g., an SNMP GET, SET, or WALK)
   SNMP managers poll SNMP agents running on managed devices over UDP port 161. (Source)
3. UDP 162 needs to be open on the SNMP manager if you want it to receive passive SNMP notifications (e.g., an SNMP TRAP or INFORM)

SNMP agents send SNMP TRAPs and INFORMs to UDP port 162 on the SNMP manager. (Source)

Object identifier (OID)

An object identifier (OID) is an address used to refer to a specific object. SNMP OIDs are represented in dotted decimal format (e.g., 1.3.6.1.2.1) and are organized in a hierarchical tree.

That hierarchical tree helps identify exactly what an OID represents. Most OIDs you work with in IT will be under 1.3.6.1. Specific private enterprises will use their IANA-assigned enterprise number to publish information under 1.3.6.1.4.1.

Once you know an OID, you can use it to retrieve information about a managed device. For example, the OID for sysDescr is 1.3.6.1.2.1.1.1.0, so we can use an SNMP GET to read that data like this:

snmpget -v 1 -c public manageddevice.example.com 1.3.6.1.2.1.1.1.0

The output should look something like this:

iso.3.6.1.2.1.1.1.0 = STRING: “Linux PepperAndEgg-ubuntu-server 5.15.0-113-generic #123-Ubuntu SMP Mon Jun 10 08:16:17 UTC 2024 x86_64”

If we want to see all the available objects on the 1.3.6.1.2.1.1 “branch” of the OID tree, we can use an SNMP WALK, like this:

snmpwalk -v 1 -c public manageddevice.example.com 1.3.6.1.2.1.1

The output would look something like the example below. Notice how the managed device returns only OIDs that begin with 1.3.6.1.2.1.1. That’s what we mean by a “branch” of the OID tree.

iso.3.6.1.2.1.1.1.0 = STRING: “Linux PepperAndEgg-ubuntu-server 5.15.0-113-generic #123-Ubuntu SMP Mon Jun 10 08:16:17 UTC 2024 x86_64” iso.3.6.1.2.1.1.2.0 = OID: iso.3.6.1.4.1.8072.3.2.10 iso.3.6.1.2.1.1.3.0 = Timeticks: (10421648) 1 day, 4:56:56.48 iso.3.6.1.2.1.1.4.0 = STRING: “giardiniera” iso.3.6.1.2.1.1.5.0 = STRING: “PepperAndEgg-ubuntu-server” iso.3.6.1.2.1.1.6.0 = STRING: “Eating a pepper and egg on the dock of the bay” …

Management information database (MIBs)

A management information base (MIB) is like a dictionary of SNMP information that is monitorable or manageable via SNMP on a managed device. MIBs are written in a standard, hierarchical machine-readable format using Abstract Syntax Notation One (ASN.1) notation.

Adding a MIB file to an SNMP manager can make the data from OIDs more human-readable. For example, if we load the relevant MIB file to our SNMP manager and rerun our example SNMP WALK command:

snmpwalk -v 1 -c public manageddevice.example.com 1.3.6.1.2.1.1

The output gets a bit easier to understand:

SNMPv2-MIB::sysDescr.0 = STRING: Linux PepperAndEgg-ubuntu-server 5.15.0-113-generic #123-Ubuntu SMP Mon Jun 10 08:16:17 UTC 2024 x86_64 SNMPv2-MIB::sysObjectID.0 = OID: NET-SNMP-TC::linux DISMAN-EXPRESSION-MIB::sysUpTimeInstance = Timeticks: (156973) 0:26:09.73 SNMPv2-MIB::sysContact.0 = STRING: root SNMPv2-MIB::sysName.0 = STRING: PepperAndEgg-ubuntu-server SNMPv2-MIB::sysLocation.0 = STRING: Eating a pepper and egg on the dock of the bay

Scalar vs. tabular values for SNMP monitoring

Specific SNMP objects are either scalar or tabular. Scalar values are single data points that typically end in a .0 (e.g., SNMPv2-MIB::sysLocation.0). Tabular values are like rows of related information. For example, a server with 3 network interfaces will likely report 3 entries if you walk the IF-MIB::ifIndex subtree (IF-MIB::ifIndex.1, IF-MIB::ifIndex.2, and IF-MIB::ifIndex.3).

Active vs. passive monitoring

There are two common approaches for implementing SNMP monitoring on a network. Active SNMP monitoring is performed when a system or network is placed under test, and SNMP values are used to detect issues and performance bottlenecks. Passive SNMP monitoring is the periodic monitoring of SNMP data during normal operation.

SNMP versions

The SNMP versions supported on your managed devices will determine which SNMP protocols you can use to monitor them. Let’s review each of the three common SNMP versions you may encounter.

SNMP v1

SNMP v1 was the original implementation of SNMP. It supports many of the SNMP monitoring commands we have discussed so far in this article and remains widely used on internal networks.

SNMP v1 uses community strings for basic access control. A community string is a single value sent along with SNMP commands.

However, it sends data in cleartext and is less efficient than SNMP v2c. Only use SNMP v1 if you don’t have another option or aren’t concerned with security and performance requirements.

SNMP v2

While there was technically an SNMP v2, SNMP v2p, and SNMP v2u, when you hear someone say SNMP v2 today, they likely mean SNMP v2c. SNMP v2c has a larger footprint and is much more commonly used than any other “SNMP v2” implementation.

The primary improvements in SNMP v2c compared to SNMP v1 are:

• The addition of SNMP INFORM
• The addition of SNMP GETBULK
• Improved error handling
• Additional data types such as Counter64 to support larger values SNMP v1 could not

SNMP v2c also sends data in cleartext and uses community strings like SNMP v1. Therefore, it isn’t considered secure either.

SNMP v3

SNMP v3 adds encryption, usernames, and passwords to SNMP communication and is considered the most secure implementation. SNMP v3 supports User-Based Security Model (USM) authentication and View-Based Access Control Model (VACM) to implement granular access controls over MIBs.

If you’re concerned with security and want to avoid sending data in cleartext, SNMP v3 is the best choice out of these 3 SNMP monitoring protocols.

With the addition of security, SNMP v3 also became more complex than v1 and v2c. For example, varying DES/AES support between managers and agents can cause communication failures. Additionally, where administrators previously only needed to manage community strings, they now have to deal with usernames, auth passwords, and priv passwords in SNMP v3.

Why is SNMP monitoring important for MSPs?

SNMP monitoring empowers SNMPs to monitor devices from a wide range of vendors using a single protocol. As a result, MSPs can centralize, simplify, and scale their monitoring operations.

It simplifies the management of endpoints

You can monitor printers, UPS battery backups, servers, firewalls, routers, and wireless access points with SNMP alone. There are not too many protocols you can say that about. Additionally, MIBs like MIB-II from RFC1213 standardize the collection of common network data points and can reduce the guesswork involved in monitoring a new device.

It helps MSPs work more efficiently

Fewer protocols and less complexity typically mean more efficiency. While SNMP is far from perfect, it helps drive standardization. And standardization can drastically reduce the amount of time it takes to onboard new clients and devices.

It reveals critical traffic patterns

Once you’ve implemented SNMP monitoring, identifying performance bottlenecks and network issues becomes easier. For example, polling cpmCPUTotal5secRev (.1.3.6.1.4.1.9.9.109.1.1.1.1.6) on a Cisco device with a single CPU could uncover processing issues slowing down your network backbone.

It improves security

I realize saying SNMP improves security could raise some eyebrows, but bear with me for a minute. If an organization does the following:

• Use SNMP v3 with strong encryption and passwords
• Only allow read access
• Implement access control lists

An SNMP implementation can be made reasonably secure.

From there, let’s think about the added security value. You have gained visibility over a large swath of devices in your network and can now receive alerts from endpoints, firewalls, routers, servers, and smart devices for unexpected CPU, RAM, traffic, or other resource spikes that could be associated with a threat actor (e.g., a cryptojacking attack ramping up processor utilization). That increased visibility can help improve your response times and address issues before they spiral out of control.

Additionally, network scans with SNMP can discover devices or default configurations you may not have known about. Inventorying and hardening these devices can meaningfully reduce risk as well.

Best practices for SNMP monitoring

Now that you understand how SNMP works and what it can do for MSPs, let’s explore four essential SNMP monitoring best practices. Typically, tying these best practices together and making them scalable is where SNMP monitoring and management tools come in.

Custom alerts

Every network is different. SNMP can get the monitoring data for you, but alerts still need to be calibrated to avoid alert fatigue or missing critical events. Customize your alert thresholds to match your business requirements, then fine-tune from there.

Here are three tips to help you get your SNMP alerts right:

• Alert once it matters: Make sure your thresholds are high enough that action is warranted if you trigger an alert. Setting thresholds too low can bombard your technicians with irrelevant alerts.

• Understand your baselines: Knowing when to trigger an alert is tricky. Fortunately, once you’ve configured SNMP monitoring, you can capture baseline metrics to use as a frame of reference. For example,

• Auto-resolve alerts if you can: Automation is an MSP’s best friend. Where practical, trigger automations to resolve alerts. If the automation solves the problem, be sure to close the alert in the SNMP monitoring software so your technicians don’t waste their time.

Device discovery

Device monitoring starts with device discovery. Scanning your networks for SNMP devices (e.g., by using a PowerShell script) can sometimes turn up assets you didn’t know were on the network. In other cases, you may have a hard time detecting a device you expect to support SNMP. Here’s how you can improve the quality of your SNMP device discovery:

• Scan for default community strings: Scanning for default SNMP community strings like “public” and “private” can help you find devices with default configurations you may need to update.

• Make sure to use the right protocol: If the SNMP version your monitoring tool uses doesn’t match the managed devices, your discovery may fail. For SNMP, you’ll also likely need to specify what type of encryption to use (e.g., MD5 or SHA and DES or AES).

• Add SNMP credentials to your monitoring tool: To communicate with devices via SNMP monitoring software, your SNMP manager needs to know the community string (v1 and v2c) or credentials (v3) required. Make sure to regularly update the tool as new devices are deployed with new configurations so your SNMP discoveries are successful.

Custom dashboards and reporting

SNMP polling is an excellent source of time series data and device information you can use to create customized dashboards and reports for your assets. For example, you can use SNMP data to poll UPS battery voltage, printer toner levels, and switch port status.

Use SNMP’s flexibility to your advantage and create reports that help you track the metrics that matter most to your business.

Fault detection

Brake/fix is a big part of the MSP game, so the faster you can detect a fault, the better. Many managed device MIBs will support alarm tables you can poll to determine when specific issues occur. Monitoring these values enables you to quickly respond and take corrective action when something goes wrong. For example, SNMP can help you detect disk failures on RAID disks and address the problem before your clients lose data.

The best SNMP management tool

An SNMP OID monitor configuration in Syncro. (Source | Direct Link) 

If you’re an MSP, the best SNMP management tool is the one that helps you run a more profitable business. Syncro, the all in one integrated MSP platform, empowers MSPs to combine the flexibility of SNMP and OID recipes with the power of RMM and PSA automation. By integrating all your MSP tooling in one place, Syncro helps MSPs of all sizes automate and optimize their way to more profits.

If you’d like to see what Syncro can do for you, sign up for a free demo today!

Enjoy this article? Share it!