1. SNMP
  2. Legacy integration
  3. Chapter4b

7 Essential Telemetry Features That The Average SNMP Manager Doesn't Support

PROBLEM #1: "My biggest problem is human resistance to change. I want to integrate SNMP alarms to our data operations center to correlate failures with impact on services, but support personnel are resistant to move to a new surveillance system."

PROBLEM #2: "My biggest problem is that SNMP won't give me the visibility I need. The IT staff likes SNMP, but I need change of state alarms."

The real problem here, like in many SNMP implementations, is that the IT and telemetry staff are working at cross-purposes. They need different kinds of information from their network monitoring, and they're not going to be happy with the same system.

It's tempting to think that the only reason staff resist new systems is because of inertia, but usually they're resistant for a reason, like the guy who wants COS alarms - a feature that standard SNMP managers DON'T support.

In fact, there's a whole bunch of classic telemetry features that aren't supported by ANY standard, off-the-shelf SNMP manager. And these aren't trivial features - they're essential for getting prompt, effective notification of network problems, reducing service restoration times and maintaining even average network reliability.

T/Mon Alarm Displays
T/Mon displays alarms in multiple ways to provide the most useful information.

Here's my list of 7 essential telemetry features that the average SNMP manager doesn't support:

  1. Detailed alarm descriptions: A basic SNMP manager doesn't record the location, time, severity, or a precise description of the alarm. You can adapt the SNMP manager to monitor those factors, but that means databasing every monitored point in your network and every SNMP trap it might send.
  2. Change of state alarms: Basic SNMP managers can't tell you whether a trap represents an alarm condition or a clear condition. If you want to add COS alarms to your SNMP manager, it will take even more database work, including analyzing multiple variable bindings within the trap packet.
  3. Standing alarm list: This is a big one. If you don't have an accurate standing alarm list, you can completely lose visibility of network threats. A typical SNMP manager lists just new traps and acknowledged traps. Imagine what might happen to your remote site equipment if a system operator acknowledged an alarm and then, for whatever reason, didn't correct the alarm. Who would know the alarm was still standing?
  4. User identification: Basic SNMP managers don't identify system operators or record who acknowledges alarms. If somebody mishandles an alarm, you've got no way of knowing who did it.
  5. Multiple user security: The typical SNMP manager isn't designed for multi-user security. All traps are posted to one list, all users can see it, and all users can acknowledge all alarms.
  6. Alarm sorting and filtering: Like I said, basic SNMP managers display all alarms to everybody. That means you can't sort out just the alarms you need to see, you can't correlate alarms by site or equipment type, and you're going to get drowned in nuisance alarms.
  7. Pager and email notifications: Can you afford a 24-7 NOC? Do alarms only happen during business hours M-F, 8-5? Pager and email alerts are crucial for adequate network monitoring, and basic SNMP managers don't support them.