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.
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.)
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.
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.
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.
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
You need to see DPS gear in action. Get a live demo with our engineers.
Check out our White Paper Series!
A complete library of helpful advice and survival guides for every aspect of system monitoring and control.
Have a specific question? Ask our team of expert engineers and get a specific answer!
Sign up for the next DPS Factory Training!
Whether you're new to our equipment or you've used it for years, DPS factory training is the best way to get more from your monitoring.Reserve Your Seat Today