Check out our White Paper Series!
A complete library of helpful advice and survival guides for every aspect of system monitoring and control.
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 TodayUsing 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.
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.
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.
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.
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.
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.
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.
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.
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:
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.
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.
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.
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.
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.
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.
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:
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:
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.
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.
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.
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.
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.
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:
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.
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/.
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.
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.
Morgana Siggins
Morgana Siggins is a marketing writer, content creator, and documentation specialist at DPS Telecom. She has created over 200 blog articles and videos sharing her years of experience in the remote monitoring industry.
