Finding and solving problems in your SNMP implementation can be tough.
This guide helps you identify and solve SNMP issues.
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 TodaySome SNMP problems are caused by the content of the SNMP traps being sent. Because identifying these issues is a fairly quick process, it is 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 v1 traps and your device is sending v2 traps, you will encounter problems. Similarly, some managers that are configured to receive v2 traps will not correctly parse v1 traps.
Configure your RTU to send the version of traps that your manager is setup 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. Although 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 find yourself with a stubborn SNMP problem, don't forget to check for nonstandard 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 names on their networks. This can cause trouble with your SNMP 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.
Let's take a look at some remotes from the NetGuardian RTU family. Those RTUs scale to fit your needs.
Full-featured NetGuardian 832A
Heavy-duty NetGuardian 480
Economical NetGuardian 216
With 2 SFP fiber interfaces, an integrated 1000BaseT Ethernet switch and SNMPv3 support, the new NetGuardian 216F can handle virtually any monitoring need.
T/Mon integrates legacy protocols into modern SNMP monitoring systems. You don't have to scrap your older equipment, delay SNMP migration, or suffer with multiple incompatible monitoring systems. T/Mon supports a wide range of legacy protocols in addition to SNMP traps, providing complete visibility on a single display. For larger network configurations, T/Mon mediates legacy protocols and can forward alarms as traps to your SNMP-compatible MOM.
Do you have a nagging SNMP problem that is reducing your network visibility?
We've put together a troubleshooting guide based on conversations with real-world users in DPS Telecom's Tech Support department.
If you have any additional questions you are more than welcome to call us and we can discuss SNMP in more specific details as well.
Download the free Practical Guide to SNMP Troubleshooting Here.
Previous Page
Understanding the OIDNext Page
5 Common MIB Issues