MIB Viewer

SNMP TRAP

A trap is a notification an agent sends to a manager on its own initiative, without being asked - the reverse of the usual GET/manager-asks-first flow. An interface going down, a hardware sensor crossing a threshold, a process crashing: these are the kinds of events that make sense to report immediately, rather than waiting for the next scheduled poll to happen to notice.

Traps are sent over UDP, conventionally to port 162 on the manager (distinct from port 161, which agents listen on for incoming requests).

Traps are fire-and-forget

This is the single most important thing to understand about traps: the agent sends one, and that's it. There's no acknowledgment, no confirmation the manager actually received it, and no automatic retry if it gets lost - a dropped UDP packet, a manager that's briefly down, a firewall rule blocking port 162, and the notification simply never arrives, with the agent having no way to know that happened. This makes traps genuinely unsuitable as the only mechanism for anything where a missed notification would be a real problem - which is exactly the gap INFORM exists to close.

v1 traps vs. v2c/v3 traps

The actual message format differs meaningfully between versions:

  • SNMPv1 traps use a dedicated PDU format with a fixed, predefined set of generic trap types - coldStart, warmStart, linkDown, linkUp, authenticationFailure, egpNeighborLoss, and a catch-all enterpriseSpecific for anything vendor-defined beyond that fixed list.
  • SNMPv2c/v3 traps instead use the same general PDU structure as other operations, identifying which specific notification this is via a special varbind, snmpTrapOID, whose value is the OID of a NOTIFICATION-TYPE defined in some MIB - giving vendors a much more flexible, MIB-defined way to describe exactly what happened, rather than being limited to the old fixed list.

Interpreting a raw trap

A trap arrives as a bundle of OIDs and values, same as any other SNMP PDU - and just like anywhere else in SNMP, those OIDs are meaningless numbers without the right MIB loaded to translate them. This is a common practical annoyance: a trap-receiving tool (like snmptrapd) logs the raw numeric OIDs it received, and without the matching MIB, you're left staring at something like 1.3.6.1.6.3.1.1.5.3 with no indication it actually means linkDown.

Configuring a device to send traps

An agent has to be explicitly told where to send traps - typically a destination IP, port, and (for v1/v2c) the community string to include, or (for v3) the target user and security parameters. Without this configured, a device won't send anything unprompted no matter what happens to it, even if it fully supports traps in principle.