Get a Live Demo

You need to see DPS gear in action. Get a live demo with our engineers.

Get the SNMP Fast Track GuideBook

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.

DPS is here to help.


Have a specific question? Ask our team of expert engineers and get a specific answer!

Learn the Easy Way

Sign up for the next DPS Factory Training!

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

How to Use Net-SNMP in Common Troubleshooting Scenarios

by 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.

SNMP agent and manager communicating with TRAPs, SETs, and GETs.
Net-SNMP will help you troubleshoot SNMP architectures like this one, where an agent communicates with your SNMP manager by sending TRAPs, receiving GET/SET requests, and responding to those requests.

Net-SNMP is an open-source SNMP toolkit

Net-SNMP is one such free tool that you can use in your SNMP projects. With it, you can:

  • Ask an SNMP device for information. You can make single GET requests, walk available data with GETNEXT requests, an more. This function serves as a test for what your SNMP manager will eventually do once operational.
  • Browse MIB files using a GUI. This makes it much easier to understand MIBs. Although they're ASCII files that are technically "human-readable", that doesn't make them easy to read. Graphical presentations are much better, especially when you're a beginner.
  • Receive SNMP notifications (usually TRAP messages). Again, this mimics what your SNMP manager will eventually do. This help you test your object identifier values and other important settings.
  • Integrate SNMP into your own software application. There are active APIs for Perl and C. There are other APIs for PHP, Java, and Python that were in some state of development in 2020.
  • Net-SNMP Works under Multiple Operating Systems
  • You can use Net-SNMP on Unix and related operating systems. You can also run it using a Windows OS.

This works well in both corporate/industrial and IT/hobbyist scenarios. In these situations, you're very likely using Unix or Linux or Windows.

What is my goal when using Net-SNMP?

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.

A single SNMP manager using 3 MIB files to interpret trap messages, and send SET/GET requests, to 3 separate SNMP agents.
Net-SNMP helps you verify that a basic SNMP configuration like this one is operating properly. You can use it as a kind of "test kit" to simulate an SNMP manager as you set up agents.

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 I'm done with Net-SNMP, now what?

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.

You must compile your MIB modules into your 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.

What SNMP manager should I choose?

That's a big question. There are many factors you need to consider.

You should mainly focus on:

  1. High reliability
  2. A clear interface
  3. Multi-protocol support

If your SNMP manager isn't reliable, it can't do its job

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.

You need an SNMP manager with a clear interface your team can use easily

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.

Don't focus only on SNMP

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?

A multi-protocol T/Mon master station collecting alarms from SNMP, TL1, ASCII messages, Badger, Larse, NEC, and other equipment.
When choosing an SNMP manager, consider that you may have other protocols in your network. Choose a universal alarm master that will handle SNMP and your other protocols as a single, unified management system.

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.

You need a way to convert legacy inputs to SNMP

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?

A TrapRelay 64 device converting SNMP traps into contact closures for a fire alarm panel.
You may not expect it, but many people desperately need conversion of modern SNMP TRAPs back into traditional relay closures. You can use Net-SNMP to verify that traps are arriving as expected before you install your Trap Relay device.

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.

Security-conscious organizations need conversion to SNMPv3

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?

Smart SNMP proxy devices can convert older gear to SNMPv3

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.

SNMP v1 and v2c being mediated to SNMPv3 via SNMP proxy device.
It's possible to use an SNMP proxy to convert older SNMP devices to v3. Net-SNMP can be a key part of your troubleshooting process.

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.

What if I need more help with SNMP?

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.

Two DPS engineers working at DPS headquarters.
DPS engineers will help you with your SNMP project - even if you don't have an immediate need to buy RTUs or a master station. Just pick up the phone.

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.