When I Look At My MIB Files, I Don't See Long Strings Of Numbers Like That

Alarm Master Choice: T/Mon NOC


T/Mon NOC has many features to make your alarms more meaningful, including:

1. Detailed, plain English alarm descriptions include severity, location and date/time stamp.

2. Immediate notification of COS alarms, including new alarms and alarms that have cleared

3. Standing alarm list is continuously updated.

4. Text message windows displaying specific instructions for the appropriate action for an alarm.

5. Nuisance alarm filtering, allowing your staff to focus its attention on serious threats.

6. Pager and email notifications sent directly to maintenance personnel, even if they're away from the NOC.

7. Derived alarms and controls that combine and correlate data from multiple alarm inputs and automatically control remote site equipment to correct complex threats.

For more information, check out T/Mon on the Web at

When I Look At My MIB Files, I Don't See Long Strings Of Numbers Like That

That's because each element of an OID only needs to be defined once. Remember, in ASN.1 notation, once a term is defined, it can be used as a building block to define other terms. The last number of an OID - its most specific element - refers back to the more general elements defined earlier in the MIB.

Here's how the last four elements in our sample OID are defined in the DPS Telecom MIB:

dpsInc OBJECT IDENTIFIER ::= {enterprises 2682}
dpsAlarmControl OBJECT IDENTIFIER ::= {dpsInc 1}
dpsRTU OBJECT IDENTIFIER ::= {dpsAlarmControl 2}
VARIABLES { sysDescr, sysLocation, dpsRTUDateTime }
DESCRIPTION "Generated when all points clear."
::= 102

Look at how each term is defined as the term that came immediately before it in the OID, plus one more element. For example, dpsInc is enterprises ( plus one more element, called 2682. The next term, dpsAlarmControl, is dpsInc (, plus one more element, called 1. And so on. Each term in the OID is defined as an extension of earlier terms, going all the way back to the root term, iso.

An OID is meaningless unless every element it refers to is specifically called out and identified in the MIB. So when you're compiling your MIB files on your SNMP manager, you need to supply not only the OIDs defined by your equipment vendor, but also OIDs for public entities: iso, org, dod, internet, and so on.

So every MIB file needs to describe the entire OID tree?

Fortunately, no. The upper levels of the OID tree - the parts that define the general OID structure - are defined in a series of standard reference MIB files called RFCs.

(The initials stand for Request for Comment. The RFCs that define SNMP OIDs are part of a larger group of RFC documents that define the Internet as a whole.)

Learn SNMP the Easy Way: Attend DPS Telecom Factory Training.

Factory Training Classroom

"I had heard of SNMP, but I never knew what SNMP was until I learned it at DPS Factory Training. I'm not at all scared about SNMP now." -Derek Willis, Paul Bunyan Telephone

Learn SNMP in-depth and hands-on, in a totally practical class that will teach you how to get the most from your network monitoring. At a DPS Factory Training Event, you'll learn how to turn SNMP theory into a practical plan for improving your network visibility.

The 4-day training course covers SNMP alarm monitoring ASCII alarm parsing and processing. You'll learn about configuring and using derived alarms and controls. You'll set up automatic e-mail and SMS notifications. It's the easiest and most complete way to learn SNMP alarm monitoring. You'll learn from the same technicians who have designed hundreds of successful SNMP monitoring implementations.

For Factory Training Events dates and registration information, call 1-800-693-3314 today or see us on the Web at www.dpstelecom.com/training.