Download our free SNMP White Paper. Featuring SNMP Expert Marshall DenHartog.
This guidebook has been created to give you the information you need to successfully implement SNMP-based alarm monitoring in your network.
1-800-693-0351
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 Todayby Andrew Erickson
You'll find SNMP (Simple Network Management Protocol) in virtually every network management environment. If you don't understand SNMP, you're at a serious disadvantage.
Fortunately, the popularity SNMP means that many people have had decades to develop useful tools for you. Even better, many of these tools are free.
Net-SNMP is one such free tool that you can use in your SNMP projects. With it, you can:
This works well in both corporate/industrial and IT/hobbyist scenarios. In these situations, you're very likely using Unix or Linux or Windows.
Net-SNMP is a toolkit. It probably not your final goal. It's something you'll use on the way.
If you're making SNMP software of some kind, you might integrate it into your project. It's open-source, after all.
You might use Net-SNMP to make your device an active SNMP agent supporting the SNMP protocol. If you're making a high-volume printer, for example, you're probably focused on other areas. Integrating Net-SNMP gives your users more options without requiring you to write an SNMP implementation from scratch. You'll supply the payload message, and Net-SNMP will format the output into an SNMP trap for you.
You can also call Net-SNMP from the command line to test your SNMP setup. This is a vital troubleshooting step as you move toward a complete monitoring system. You can receive TRAPs, send SET requests, and do just about any other SNMP management function.
When you've set up your SNMP network, it's time to stop testing and start your actual use.
If you built Net-SNMP into your own home brew system, you'll continue using it as your SNMP manager.
If you were just using it to test, you'll transition now to your actual SNMP manager.
Even though Net-SNMP was a great tool to set up your SNMP system, you now how to set up your SNMP manager (remote host).
One of your early steps is to compile your MIB files into your manager. Think of these like "driver files" that tell your manager how to talk to each SNMP agent. If you don't load ("compile") them into your manager, your system just won't work.
That's a big question. There are many factors you need to consider.
You should mainly focus on:
Your SNMP manager is serious business. It's the core of your remote network management. You need it to work all the time.
Look for proven designs from companies who can give you a long client list of big-name companies.
Ask whether you get dual redundant hard disks or SSDs. Ask whether your can run on two servers simultaneously (primary/secondary configuration).
All of these factors improve the chance that your SNMP manager will stay online.
There's nothing worse than maximizing your investment and minimizing your reward. Why pour effort into designing and testing your system if your team can't understand it?
You did your homework. You tested with Net-SNMP (or built it into your own manager). Don't drop the ball now.
Grid displays (similar to an email inbox) are fine if they're clear, and they must also correlate "alarm" and "clear" events and show you only the active alarms.
Even better are map displays. These overlay any alarm conditions on geographic maps, rack photos, custom sorted menus, or any other image file you choose.
Don't forget that user-based systems offer an advantage here, too. If you can limit each user to just the information they need to know, that's important.
You'll reduce the time your team spends sifting through data they don't need. This shifts their focus to the important things.
Sure, it's a very important protocol, and quite likely your most important. But what else do you use besides SNMP?
Do you have DNP3? MODBUS? CANBUS? TL1? A proprietary protocol? A legacy protocol?
None of those can be piped directly into your SNMP manager. You need some way to handle that data to avoid managing multiple incompatible systems.
You could use after-the-fact conversion devices to change other protocols to SNMP, but that hardly makes sense in this context. You're in the process of choosing your SNMP manager anyway, so why not choose the right one from the start?
Look for an SNMP manager that supports multiple protocols. They do exist, even though they're not exceedingly common. The SNMP world is simple enough and massive enough that some programmers can get away with focusing on nothing else.
That hardly helps you, though, when you've got MODBUS from your generators and TL1 from legacy SONET gear. You need an alarm master that acts as both an SNMP manager and handles your other important protocols.
Virtually all networks have a variety of data sources. Traditional contact closures, physical relays latched by your revenue-generating equipment, are a major one. They aren't protocol-based at all.
To bring these under your new SNMP umbrella, you need an SNMP RTU. These boxes convert relay closures to SNMP traps.
As you add them, your SNMP manager might make it easy. If it doesn't, you can always use Net-SNMP again to do some quick troubleshooting.
You might need a way to convert SNMP back into legacy contact closures Yes, this absolutely sounds unusual. Hear me out.
Believe it or not, many people end up needing to convert SNMP to traditional relay outputs. How can this possibly be true?
Well, there are legal requirements for things like fire panels that can put you in this situation. If you're required by law to tie into a "too basic to fail" device like that, you have to do it.
But much of the world, and certainly the SNMP world, isn't built with that application in mind anymore.
So, what's an engineer to do when backed into this particular corner?
Well, fortunately for you, that engineer actually did bring this problem to DPS a few years ago. That led us to develop our "TrapRelay" line of devices. These are effectively "backwards RTUs", which take incoming SNMP traps and convert it back into contact closures.
You use this device by defining TRAPs and (optionally) variable bindings that trigger a corresponding relay. The big choice you need to make is capacity, with the TrapRelay currently being built with 8, 32, or 64. This capacity range addresses different fire panel designs - and also other use cases.
Even though SNMP is a standard, it now exists in several versions to deal with an evolving world. Net-SNMP has evolved to match these protocol evolutions.
Security was (and remains) a big concern for the first two versions of SNMP (v1 & v2c). There was no encryption of any kind built into those earlier versions. It was entirely up to the network administrators to protect network traffic in other layers.
SNMPv3 arrived to handle that problem, but what about the massive stacks of gear that were already installed?
Servers and other high-powered systems were able to evolve naturally because they had the hardware horsepower to handle encryption once it was developed. Small embedded devices, on the other hand, often had no hope of gaining SNMPv3 through a firmware update.
So, what's the solution here?
The solution to legacy devices that don't support SNMPv3 is an SNMP proxy box.
This is simple in concept, but there's a lot going on under the hood:
An SNMP proxy has two independent network interfaces. The first one connects to your unsecured SNMPv1 or SNMPv2c gear. This can be just one piece of equipment or an entire self-contained network at one physical location.
The other side of your SNMP proxy box connects to your main network. It only communicates via encrypted SNMPv3 back to your SNMPv3 manager.
In this way, all unsecured SNMP traffic that would have been transmitted between your agents and master is eliminated. It's replaced by encrypted v3 traffic.
A good proxy will be bidirectional, supporting not just TRAPs but also SETs and GETs in the opposite direction.
Of course, diagnostic tools like Net-SNMP are incredibly useful in this type of application, since you can test out both sides of your proxy device. Since your application will be increasing in complexity (agents AND the proxy box AND your SNMP manager), troubleshooting tools are supremely important.
If something isn't working on your first attempt, use Net-SNMP to follow the data thread. If you can't get TRAPs to go through, start at the agent. Use Net-SNMP to see if the TRAP is being sent via v1 or v2c.
If that's working, move Net-SNMP above your SNMP proxy and look for a v3 TRAP.
Of course, in the other direction, you can send SETs and GETs from Net-SNMP to your proxy in v3. If that works, you can send v1/v2c SETs/GETs to your older SNMP gear from a network position below the proxy box. The result of each test is an important clue to which part of your SNMP implementation is failing.
There's nothing like talking to an expert, especially when you're just getting started.
I work at DPS alongside many other engineers. SNMP is the most common protocol we use. We have experience working with Net-SNMP.
If you need any help, even if you don't immediately need a NetGuardian RTU or T/Mon SNMP manager, I'm happy to help you. I can help you troubleshoot with Net-SNMP and other recommended software tools.
Just give me a call at 559-454-1600 or send me a quick online message.
Just give me a call at 559-454-1600 or send me a quick online message.
SNMP may not actually be "simple", but I'll do my best to make it easy for you.
