snmpwalk Works. Is Your Monitoring Actually Ready?

NW Field Memo — Sun, 06 Sep 2026 09:17:12 +0000

Adapted from my original Japanese article, with AI-assisted translation and editing.

My manager: “Test this device.” (Doesn't really know the product or the technology.)

Me: “Sure.” (Also doesn't really know the product or the technology.)

If you've worked in infrastructure, that may sound familiar. I'm Goda, a network engineer sharing things I learned while figuring out the job.

SNMP comes up in a lot of network device testing. For a while, my idea of an SNMP test was simple:

Run snmpwalk.
Watch a pile of OIDs and values scroll past.
Mark SNMP as working.

A screen full of output is reassuring. It certainly looks like something is being monitored.

Then I was asked to write a test plan for a device. I added an item along the lines of “Confirm that information can be retrieved using SNMP” and sent it for review.

The feedback was:

Which OIDs will you use for CPU and memory?

The customer will probably ask. You should at least cover those.

That was when it clicked: a successful walk and successful retrieval of the metrics we need are two different things.

~~My other thought was, “Fine, you write the test plan, then.”~~

But the feedback was fair. Getting something back is not the same as getting what you need.

What did the successful walk actually prove?

snmpwalk is useful. Net-SNMP's tool uses GETNEXT requests to walk through a subtree starting from a specified OID. Net-SNMP manual

If it successfully returns values, you've established that you could read those values under those test conditions.

That matters. It does not, by itself, establish that your CPU and memory monitoring requirements are satisfied, or that every required OID is available.

I had been treating a successful command as a much broader result than it actually was.

Break “SNMP testing” into specific checks

Today, I'd separate at least these questions:

Question	What to check
Can I communicate over SNMP?	Whether the device responds to the intended request under the defined conditions
Can I monitor CPU?	The processor or resource being measured, the meaning of the value, and its averaging period
Can I monitor memory?	The resource being measured, its units, and any required conversion
Can the monitoring server collect the data?	Results from the actual monitoring server and monitoring application
Can I receive the required trap?	The notification produced by the relevant event and its documented trigger conditions

“SNMP polling: snmpwalk returns values” leaves a lot of room for interpretation.

It can be a perfectly reasonable connectivity check if you define its scope. If the goal includes CPU or memory monitoring, the acceptance criteria need to go further.

A number needs a definition

Suppose you retrieve:

What does it mean? Which resource does it describe? What are the units? Is it an instantaneous measurement or an average?

The following examples use HOST-RESOURCES-MIB to illustrate why those questions matter. Check what your actual device and software release support.

hrProcessorLoad reports an individual processor's non-idle time as a percentage, averaged over roughly the preceding minute. It is not simply an instantaneous, whole-device CPU percentage. The definition permits implementations to approximate that averaging period. RFC 2790

If it differs from the number on the device's GUI, first ask whether both displays measure the same thing over the same period.

For memory, hrStorageUsed is a count of allocation units. To express usage in bytes, multiply it by hrStorageAllocationUnits from the same table row:

Used bytes = allocation units in use × bytes per allocation unit

You also need to identify whether that row represents the memory area you intended to monitor. A readable OID is not enough; the interpretation needs to be right. RFC 2790

My laptop can read it. Can the monitoring server?

These are separate checks:

My laptop can retrieve the value.
The actual monitoring server can retrieve the value.
The monitoring application records it.
The application displays it as the metric we intended.

Don't sign off on more than your evidence supports.

A successful walk from a laptop does not establish that the monitoring system is working end to end.

That doesn't mean every device test has to cover the entire monitoring system. It means the test plan should state what this test covers, and what belongs to a later test or another team.

If end-to-end monitoring is in scope, the requirements may also call for checking threshold evaluation and alert delivery.

Network conditions matter, too. A laptop on the device's subnet and a monitoring server that reaches it through a router do not necessarily exercise the same path or access controls. Success from one does not prove access from the other.

Polling and traps need separate tests

Polling is the monitoring side asking, “What's the current value?”

A trap is the device reporting, “This event happened.”

Retrieval requests and SNMPv2 traps are distinct protocol operations. Reading an OID successfully does not prove that a trap exists for that condition, or that the device will send it in your test. RFC 3416

You need to check whether the product implements the notification and what triggers it.

Cisco ISE provides a useful documented example. The ISE 3.5 administration guide explains that manually stopping a process also stops Monit's monitoring of that process, so that operation does not produce the process-stop trap. It describes the trap as applying to an unexpected process stop that is not automatically recovered. Cisco ISE 3.5: Process-Monitoring SNMP Traps

So “I stopped the process and received no trap” is not enough to conclude that SNMP is broken.

This is an example from the ISE 3.5 documentation, not a rule for every product, release, or trap. Match your test to the documented behavior of the version you're testing.

How I'd write the test items now

My old test item was:

SNMP polling

Confirm that snmpwalk returns values.

I'd now separate it into more specific checks:

CPU monitoring

Retrieve the CPU-related metrics used by the monitoring design. Confirm that the measured resource, the meaning of the value, and the averaging period match that design.

Memory monitoring

Retrieve the memory-related metrics used by the monitoring design. Confirm that the resource, units, and any required conversion match that design.

Monitoring system collection

Collect the required metrics through the actual monitoring system and confirm that they are recorded and displayed as intended.

If the design specifies the OIDs, include them in the test plan. For table values, also record which instances to use and how to identify them.

That gives you an answer when someone later asks, “What exactly did we verify?”

A successful command is one piece of evidence

snmpwalk returns data. A ping succeeds. An SSH login works.

Each result is useful. Whether it is enough depends on the purpose of the test.

For monitoring, the question is whether we can monitor the things we're supposed to monitor. Anything outside the current test's scope should be explicitly handed over to the next test or the responsible team.

It sounds obvious now. I didn't really understand it until I had to write the test plan myself.

If your current SNMP test plan is basically “run a walk and see what happens,” I hope this gives you a few useful questions to add.

A related topic I plan to write about is whether knowing an OID tells you anything about the traps a device can send. That's another distinction I initially missed.

DEV Community: NW Field Memo