MIB Viewer

Notifications

NOTIFICATION-TYPE is the macro used in SNMPv2c/v3 MIBs to define a specific kind of unsolicited event a device can report - the formal, MIB-level definition underlying an individual TRAP or INFORM. Where an OBJECT-TYPE defines a data point you can query, a NOTIFICATION-TYPE defines an event the device can proactively report, along with exactly what data comes bundled with it.

A typical definition

linkDown NOTIFICATION-TYPE
    OBJECTS { ifIndex, ifAdminStatus, ifOperStatus }
    STATUS  current
    DESCRIPTION
        "A linkDown trap signifies that the SNMP entity,
        acting in an agent role, has detected that the
        ifOperStatus object for one of its communication
        links is about to enter the down state."
    ::= { snmpTraps 3 }

The OBJECTS clause is the important part: it lists exactly which other OIDs' current values get bundled into the notification when it's sent - here, which interface changed, and its admin and operational status. This is what lets a manager receiving a linkDown notification know immediately which interface it was about, without needing a separate follow-up query.

How this connects to what actually arrives over the wire

When a v2c/v3 trap or inform is sent, it includes a special varbind, snmpTrapOID, whose value is the OID of the specific NOTIFICATION-TYPE that fired - 1.3.6.1.6.3.1.1.5.3 for the example above. A receiving tool with the right MIB loaded can look up that OID, recognize it as linkDown, and correctly interpret the rest of the bundled varbinds according to that notification's own OBJECTS list.

Standard vs. vendor-defined notifications

Like objects, notifications come in both standard, cross-vendor forms (link up/down, cold/warm start, authentication failure - all defined in core MIBs every implementation is expected to support) and vendor-specific ones defined in private, enterprise MIBs - a fan failure, a specific hardware fault code, a license expiring. Interpreting a vendor-specific notification correctly requires that vendor's own MIB.

Why an unrecognized trap OID is such a common frustration

If a monitoring platform receives a trap whose snmpTrapOID it doesn't have a matching NOTIFICATION-TYPE definition for, it can typically still show the raw data it received - the OID itself, and whatever varbinds came with it - but can't tell you in plain language what actually happened, or reliably label the accompanying data. This is exactly the same underlying problem as an unknown OID anywhere else in SNMP: the right MIB simply isn't loaded (or, for a genuinely non-existent OID, doesn't exist anywhere at all).