What is SNMPWalk and When Should You Perform One?

There's an old saying you're probably familiar with: 'you have to walk before you can run.' Or maybe it isn't an old saying, maybe it's something you saw printed on vintage stock. Either way, it is certainly true. It's true in life, and it's true when setting up a system to monitor your remote stations.

That's why, before you start running your monitoring network, you should take a SNMPWalk.

An SNMPWalk is how you get a list of everything in your SNMP-protocol network that might be queried, and how you test the effectiveness of each agent's response.

In short, it's how you make sure things work. You can do this before you use your SNMP system in real scenarios, and you can do this to troubleshoot if anything goes wrong.

The SNMPWalk is more than walking around the car kicking tires: it's doing a full-scale test of every situation, every condition, and every sudden stop your equipment might take. It's a full picture of how your SNMP enabled devices communicate information. It's a walk that enables you to run.

Understanding SNMP

To start with, it's important to understand what SNMP means. Simple Network Management Protocol - or "SNMP" - is a protocol two computers use to communicate with each other. It's the language in which packets of information are sent back and forth.

Your SNMP-based monitoring system is made up of multiple devices, including a network of RTUs and master stations. All of these are addressed by their Object Identifier (OID). The OID is a long string of numbers that incorporate SNMP, the manufacturer, and other information.

The whole system is set up for these devices to talk to each other. They talk to each other using 5 different types of information.

(Note: an "SNMP manager" is essentially the central master server; an agent is the RTU or other remote network device.)

• Trap
  SNMP traps are basically an alert. An RTU sends a trap message if its parameters are triggered - for instance, if a generator fails or temperature starts getting too high. These are the most common messages sent and are essentially the whole point of the monitoring system.
• GET
  If you can't wait, your manager can send a 'GET' message out to RTUs, to query how things are working. This is especially useful if conditions are bad, and you want to stay ahead of things. This can also be automated to happen regularly, providing detection of a failed device that cannot alert the manager itself.
  However, make sure you have the community string feature tied to your Get request. The community string is a password that makes sure the device will only give away information if the community string is correct.
• GET-Response
  This is the response message from the RTU or another agent to a received 'GET' inquiry.
• GET-Next
  Sometimes that response is enough, but there might be more data being collected from the RTU or the network of RTUs. If the agent wants the full picture, a 'GETNext' request message is the process used to get it. This message type gives the manager an efficient way to get a "full update" from an agent.
  Only the first value needs to be requested directly with a GET. After receiving a response, the manager simply issues a generic "GET-Next" to get the next value from the agent. This process can repeat until every value has been retrieved.
• SET
  This is how the manager tells an agent to take action. A process can be automated, so if the master finds out, through a Trap or a 'GET-Response,' that a battery is failing, it can send a 'Set' message to activate a back-up generator. This way, the problem is solved before it gets too troublesome.

How does this work in practice? Well, let's pretend that OIDs for a system are 1.1 and 1.2 (in real life, they are each much longer, but we can simplify). 1.1 and 1.2 are both unique items within single SNMP agents. They both represent individual discrete inputs on a remote monitoring device.

The master might send a 'GET' message to 1.1 to find out how things are going, and when it finds out that temperatures are climbing a little high (1.1 is a temperature reading), will send a 'GET-Next' message. 1.2 reports that the battery is drained more than usual (1.2 is a battery voltage). Now, we're beginning to get a clear picture of an overworked system.

It's possible that the master can send a 'SET' message to slow down a turbine which is overworking and raising the temperature. That way, without anyone getting involved, your system solved a problem.

That's the way it should run. But it only does so if you take the time to run SNMPWalk initially.

How SNMPWalk Works

Before you install your system, you need to do a full evaluation of everything that needs to be monitored. It's important to know how many RTU points you'll need. Then, when you're installing, you must test all of your RTUs.

An SNMPWalk command helps you obtain a full (or partial) list of variables. This will show you what your system is capable of reporting and help you build the logic around its parameters. It will help you determine how to set up which messages, and how they should be sent.

In doing this, you will set up a library of MIBs. A Management Information Base is a file that tells the manager what information one agent can (and cannot) send and receive. In our example above, 1.1 and 1.2 could send information about their stations, but they probably can't receive a 'SET' message. They don't control that.

So, the MIB file and a verifying SNMPWalk help you determine all the logic of your SNMP network. Your master knows that if it gets a 'Trap' notification from 1.1, it needs to send a 'GET' message to 1.2.

If that 'GET-Response' comes out looking bad, it can send a 'SET' message to 1.3 to take action. That's for you and your partner to program. But you won't know that without a SNMPWalk leading to a library of SNMP MIBs.

Can I Use a SNMPWalk For Troubleshooting?

Yes, if something went wrong during your install, a SNMPWalk can help you find the glitch. A SNMPWalk and RTU troubleshooting can help you understand where there is a miscommunication or a disconnection, and you can adjust the logic with what you have learned. This way, your devices will communicate effectively.

Knowledge is Literally Power

The biggest fear for any managed device failure is leading to a shutdown. That means money is lost, manpower hours are eaten up, and probably resulting in angry customers. It might mean regulatory fines and even lawsuits. It could even mean lost lives.

So, you want to keep your devices working effectively, and that means having a monitoring system that works throughout your system. That means having your masters and agents be able to communicate. And, that will require a SNMPWalk to be able to fully set the parameters of communication.

This is complicated, which is why you want a partner who can help you during installation and implementation. The right partner can get you (and keep you) up and running.

DPS Telecom has the experience and expertise to help companies monitor what matters most - including working with SNMP applications. Our technicians can work to help you with SNMP troubleshooting and ensuring you have the best equipment. Reach out and get a quote today!

Image courtesy Shutterstock