Get a Live Demo

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

White Paper Series

Check out our White Paper Series!

A complete library of helpful advice and survival guides for every aspect of system monitoring and control.

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 Identify and Solve SNMP Issues


December 23, 2021


Using the Simple Network Management Protocol (SNMP) to monitor your network can be a powerful tool for increasing your network reliability. And you don't need to be an SNMP expert to monitor your managed devices effectively.

Skip this article and browse our remote monitoring solutions.

Unfortunately, SNMP implementations are often hampered by a variety of different problems. And, since many companies only offer tech support at a price (when it's offered at all), it's important that you know how to troubleshoot SNMP network monitoring issues.

SNMP issues

As one of the only companies in the network management system industry that offer a quality tech support for free, we want to assist you in identifying and solving a variety of SNMP problems, because our main goal is to help you. With this key information, you can eliminate hours of frustrating SNMP troubleshooting from your busy schedule - and save money, if you have to pay for tech support.

So, let's dive in.

Top 3 SNMP Trap Issues That Can Disrupt Your Monitoring

Some SNMP problems are caused by the content of the SNMP traps being sent. Because identifying these issues is a fairly quick process, it's a good idea to look for them before moving on to more time-intensive procedures. Be sure to check for these trap issues as you begin troubleshooting.

1. Incompatible trap versions

If your SNMP manager is configured to accept only v1 traps and your device is sending v2 traps, there will be a problem. Similarly, some managers that are configured to receive only v2 traps will not correctly understand v1 traps.

Configure your RTU to send the version of traps that your manager is set up to accept, or configure your manager to receive the type of traps that your remote equipment is sending. Generally speaking, most v2 managers can be configured to receive v1 traps.

2. Non-standard trap formats

SNMP managers can also run into trouble if a device is sending non-standard traps.

Even though SNMP is a standard protocol, some people have modified the formats of their traps to suit special needs. They might have, for example, added an extra field to their traps to transmit a particular piece of additional data. If this change was not properly documented, it can cause trouble later.

Because this is not a very common SNMP issue, it tends to be one of the more difficult to identify. If you have a stubborn SNMP problem, don't forget to check for non-standard trap formats/content.

3. Altered community names

In most SNMP implementations, the community name used by the devices and the manager is public. Some IT departments, however, have set up unique community string names on their networks. This can cause trouble with your traps because some SNMP managers will use the community name as a unique identifier. If your manager is expecting "public" but finds a customized community name instead (or vice versa), it may simply discard the trap.

Another potential problem is switches that utilize variable community names. Devices connected to Shelf 1 might be given the community name "public-1", those on Shelf 2 given "public-2", etc. Unless you have a proprietary master that is expecting traps with variable community names, it may not handle them properly.

Check for any altered community names and make any necessary adjustments. Remember that community names must match exactly and are case-sensitive.

Top 5 SNMP MIB Issues

Even if SNMP traps are being properly sent from an agent, a SNMP manager with any of the following MIB issues will create errors and reduce your network visibility, increasing the chance of a costly outage.

What is MIB

1. Needed MIB Not Compiled Onto Your SNMP Manager

A Management Information Base (MIB) file is a sort of codebook that is required to interpret traps sent from your SNMP devices. Without the appropriate MIB, your SNMP manager will not be able to handle incoming traps from an SNMP device. Remember that:

  • MIB files are generally available from your device manufacturer
  • You must compile any new MIBs into your SNMP manager
  • In some cases, device manufacturers will not provide MIBs for their devices. This is typically an attempt to force purchases of their proprietary SNMP manager or other equipment. One good way to work around this issue is to use a device that accepts manual input of trap values.

2. Incompatible MIBs

The two most common MIB types are DOS MIBs and UNIX MIBs. DOS MIBs may not work with a UNIX SNMP manager, and vice versa. Check to be sure that you are using MIBs that are compatible with your manager.

3. Missing Reference MIBs

Most main MIBs require additional reference (RFC) MIBs during compiling. If any of these RFC MIBs are missing, the main MIB will not compile properly.

Some SNMP managers will add an error message to the MIB Manager log that indicates which MIB files are missing, but - for the most part - error reporting will vary. However, you can always get a list of required reference MIBs by reading the main MIB.

Example of MIB

The above example is taken from the beginning of a typical MIB file. Remember that RFC MIBs will always be listed under "IMPORTS." Make sure that you have all RFC MIBs referenced by your main MIB and compile it again.

4. Typos in the MIB

Bad syntax in a MIB file can create errors when compiling. Exactly how much goes wrong will vary based upon the compiler that your are using. Some are less forgiving than others. Although typos in the MIB can take many forms, one of the most common is the incorrectly escaped file comment.

File comments in MIBs are offset from the rest of the file by double hyphens (--) and generally continue until the end of the line. An important exception is that comments can be ended by a second pair of hyphens on the same line. Any text on the same line after this second pair of hyphens will be parsed by the compiler as if it were normal MIB code, causing an error.

MIB typos

As you can see in the above example, the first comment does not create a problem, nor does the second. The third, however, appears outside of the second double hyphen (--) on the same line and is considered part of the MIB code during compiling. The compiler will not know how to handle it, and an error will be generated. Look for this and other typos in your MIB files.

SNMP Get and Set

5) "Pre-compiled" MIBs

Using "pre-compiled" MIBs is not always the best choice. MIBs that were compiled for a target platform other than your manager can create a range of potential problems. The MIB files you use should be text-readable before you compile them to your manager.

Don't Forget The Obvious When Troubleshooting

You don't want to spend any unnecessary time searching for complex problems, so be sure to check for these simple and "obvious" ones during troubleshooting:

  1. Is your remote device sending traps to the IP address of the target manager?
  2. Is your remote device provisioned to send traps?
  3. Is your IP addressing, including subnet and gateway, set up correctly on the remote device?
  4. Is your IP routing configuration (DNS or static) correct?

Identifying and Solving Firewall Problems

Some SNMP problems are not directly caused by either manager or agent. The network connectivity between the two devices can sometimes be impeded by a firewall. Firewalls that block UDP, SNMP, pings, or ports 161 or 162 are the most common issues. Use the following steps to identify and solve firewall problems:

1. Ping a PC near the device

A simple ICMP ping to a PC near the device is a good initial test to determine connectivity status. If your pings to the PC are not returned, try pinging the gateway. Continue working your way up the network with your pings to identify the point where they stop. Check for firewalls, especially those that block UDP, SNMP, pings, or ports 161 or 162.

Keep in mind that some networks block all ping traffic as a security measure.

2. Ping the device

Next, send another simple ICMP ping to the device to determine connectivity. If pings to the PC in Step 1 were successful, but pings sent to the device fail, the problem is almost certainly with your SNMP device.

3. Telnet and/or browse to the device

If the SNMP device you are testing supports Telnet connections or Web access, you should attempt to connect using one of these methods. If pings succeed but Telnet and/or browsing is blocked, this is a very good indication that you have a firewall issue.

4. Confirm the port configuration of the device

For additional security, some devices may use non-standard ports. If so, make sure that these ports are not blocked by a firewall and are accepted by the manager. Another potential solution is to reconfigure the device to use standard ports.

5. Confirm that important IP addresses are not blocked

A firewall may simply be blocking the IP address of your device and/or manager. Confirm that these or any other needed IP addresses are not being blocked.

6. Trace the route to the device

Tracing the "hops" that network traffic is following to reach the device can allow you to pinpoint a tricky firewall issue. A simple trace can be performed from the Command Prompt of Windows:

  • Open a Command Prompt in your Windows
  • Type "tracert", a single space, and the IP address of the device you are trying to reach (i.e. "tracert")
  • Press return to start the trace
  • Show the output to your IT department to identify potential firewall problems

Using a Network Diagnostic Tool to Examine In-Depth The Paths of your SNMP Traps

If your SNMP traps are not traveling over your network from your SNMP agent to master, you need to pinpoint the location of the problem in order to solve it.

Packet Sniffer and MIB Browser

No matter the manufacturer of your SNMP remote, a combination of a packet sniffer, such as Wireshark and MIB Browser can help you troubleshoot a wide range of network problems.

SNMP Wireshark is a network protocol analyzer and is available at no cost at https://www.wireshark.org/.

MIB Browser is an SNMP network management tool. The free version works for our purposes and is available at https://www.ireasoning.com/.


  1. First, select a PC on your network that is as close to your SNMP master as possible.
    Ideally, the PC and the SNMP master will be directly connected to the same hub. Hubs are better suited for this analysis than switches because they always send all received packets out on all ports. If you use a switch, your PC running Wireshark may not receive the packets that you need to perform your analysis.
  2. Install Wireshark and MIB Browser onto the selected PC.
  3. Start Wireshark and MIB Browser.
  4. In Wireshark, assign your PC's network card (NIC) as the capture interface in the Capture Interfaces window:
    Wireshark Capture
    Wireshark capture interface
  5. In MIB Browser, define the IP and port settings for your SNMP remote.
    • Input the IP address of your SNMP remote into the "Address" field.
    • Click the "Advanced..." button and specify the appropriate IP port (default is 161 for most SNMP devices) and any other necessary settings for your SNMP remote.
    MIB Browser Address
  6. Return to Wireshark and start a new Capture.
    Wireshark Start capture
  7. In MIB Browser, send a Get to your SNMP remote.
    • Any GetResponses received will appear in the list on the right of the screen.
    • If you receive no GetResponses, make sure that you have correctly specified the IP address and port number for your SNMP RTU. If you still do not receive GetResponses, you have a network problem or your RTU is not sending traps properly.
      MIB Browser Get
  8. Return to Wireshark and stop the Capture.
  9. Examine the packets captured by Wireshark, looking for SNMP in the "Protocol" column.
    • You can sort packets by protocol clicking on "Protocol" column header to group all SNMP packets together.
    Wireshark Packet
  10. If your traps are incorrectly addressed, they will never reach your manager.
    • If traps are coming through but not displayed on your SNMP manager, your SNMP RTU may simply be sending traps to the wrong IP address. Check for this problem in the "Destination" IP address column in Wireshark.
  11. If your traps appear to be correctly addressed, you may have a problem with your SNMP manager configuration.
    • To further isolate the problem to your SNMP manager, you may use the Trap Sender in the MIB Browser to send test traps to your SNMP manager while you monitor its display. The Trap Sender is located in the Tools menu. Simply specify the IP address of your manager and a few other settings, then click the "Send Trap" button to send a test trap. If these test traps are not displayed by your SNMP manager, the problem is almost certainly with the configuration of your manager.
    MIB Browser trap sender
    MIB Browser trap sender test
  12. If you received no SNMP traps, you must check your network and RTU configurations separately to determine the cause of the problem. One good next step is to identify another PC on the network that is as close to your SNMP remote as possible (ideally connected via Hub to ensure complete visibility in Wireshark).
    Install Wireshark and MIB Browser on that PC and repeat this procedure. By conducting the test as close to your RTU as possible, you will minimize the effect of firewalls and other potential network problems. If you still do not see traps in Wireshark after testing again, your SNMP remote may not be sending traps properly, or at all.

How to Verify That Your SNMP Device is Sending Traps

If traps aren't being properly sent from your SNMP device, they obviously won't make it to their destinations.

Your SNMP device may have a debug mode option. Once in debug mode, you will see a display of traps being sent out by the device. By creating events at the site and watching the debug-mode trap display, you can determine whether traps are trying to be sent.

Remember that you may need to reconfigure the remote to send a trap in response to the event you're generating.

Another testing method is to look for a cold start trap following bootup. Power cycle your device and watch for the trap that, on many SNMP devices, is sent when booting. Check your device documentation to ensure that you don't waste time looking for a cold start trap that your device isn't designed to send.

If traps are not being sent, you have an issue with your SNMP device. If they are being sent, double-check your network setup, firewalls, MIB files, and trap formats.

The Bottom Line

Learning how to detect and solve problems with your SNMP network is very important. But it also important to make sure your vendor can give you quality tech support. When the time comes that you need a reliable service to help you solve a big issue, you don't want to have to rely on automated messages.

At DPS, we design and manufacture all of our products, so when you call tech support, you'll be talking to the same engineers that have experience working with your unique solution.

We want to help you. So, if you have any questions about SNMP, troubleshooting, or simply about remote monitoring, you can simply contact us and you'll get a quick answer from a real person.