Some 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.
The NetGuardian RTU family scales to fit
For more: http://www.dpstele.com/rtus
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.
There is no other network on the planet that is exactly like yours. For that reason, you need to build a monitoring system that's the right fit for you.
"Buying more than you need" and "buying less than you need" are real risks. You also have to think about training, tech support, and upgrade availability.
Send me a quick online message about what you're trying to accomplish. I'll work with you to build a custom PDF application diagram that's a perfect fit for your network.
Your network isn't off-the-shelf.
Your monitoring system shouldn't be, either.
We'll walk you through this with a customized monitoring diagram.
Just tell us what you're trying to accomplish with remote monitoring.Get a Custom Diagram