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

1) Incompatible Trap Versions

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.

2) Non-Standard Trap Formats

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.


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


3 SNMP RTUs to Fit Your Spec.

The NetGuardian RTU family scales to fit
your needs..

NetGuardian 832A

Full-featured NetGuardian 832A:

  • 32 discretes, 32 pings, 8 analogs and 8 controls.
  • 8 terminal server serial ports.
  • NEBS Level 3 certified.
  • Dial-up backup.
  • Web browser interface.
  • Pager and email notification.
  • Dual -48 VDC, -24 VDC or 110 AC.
  • 1 RU for 19" or 23" rack.

NetGuardian 480

Heavy-duty NetGuardian 480

  • 80 discretes, 4 controls.
  • Dual -48 VDC.
  • 1 RU for 19" or 23" rack.

NetGuardian 216

Economical NetGuardian 216.

  • 16 discretes, 2 analogs, 2 controls.
  • 1 terminal server serial port.
  • Single or dual -48VDC or 110 VAC.
  • 2 compact form factors for rack or wall mount.

For more: http://www.dpstele.com/rtus


Bridge the Gap Between Protocols with T/Mon

T/Mon

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.