Wondering how a switch tells you it is in trouble before anyone calls? An SNMP trap is an unsolicited alert a device pushes to your monitoring station the moment something happens.
This guide belongs to our wider overview of SNMP.
| Item | Value |
|---|---|
| Trap receiver port | UDP port 162 |
| Delivery guarantee for a plain trap | None: no retransmissions, no acknowledgments |
| Acknowledged alternative | InformRequest-PDU |
| First variable binding in a trap | sysUpTime.0 |
| Second variable binding in a trap | snmpTrapOID.0 |
| Protocol operations specification | RFC 3416, December 2002 |
Figures come from RFC 3416 and Icinga’s trap guide. Standards and tools change, so check the sources before you rely on them.
What an SNMP trap actually is
Normally a manager asks devices for data on a schedule. A trap reverses that: the device, called the agent, speaks first and sends a short message when an event occurs, such as a link going down or a fan failing.
That makes traps a push model that complements polling. Polling tells you how a device looks every few minutes, while a trap tells you something changed right now.
The formal definition sits in RFC 3416, which says an SNMPv2-Trap-PDU “is generated and transmitted by an SNMP entity on behalf of a notification originator application”.
What is inside a trap message
A trap is small. Per the RFC, the first two variable bindings in an SNMPv2-Trap-PDU are sysUpTime.0 and snmpTrapOID.0, in that order.
- sysUpTime.0 records the time since the device’s network-management subsystem was last reinitialized, as of the event.
- snmpTrapOID.0 identifies which kind of event this is.
- Further bindings carry extra detail, such as the interface involved or a measured value.
Everything is identified by object identifiers, or OIDs. Icinga describes the context as being encoded via Object Identifiers from the Management Information Base.
How traps travel to a receiver
The monitoring side runs a trap receiver. As Icinga puts it, it sits on port 162, waits for traps, and translates them into something your monitoring stack can understand.
The steps look like this:
- An event occurs on the device, for example an interface changes state.
- The agent builds a trap and sends it over UDP to the configured receiver address.
- The receiver listens on UDP port 162, decodes the OIDs and raises an alert or logs the event.
Traps versus informs
A plain trap is fire and forget. Icinga’s guide states it bluntly: “No retransmissions, no acknowledgments.”
If the packet is lost, nobody knows. An inform fixes this: the InformRequest-PDU carries the same first two bindings as a trap, but the receiver confirms it, so the sender can try again if no confirmation arrives.
- Trap: sent once by the agent, never acknowledged, so a lost packet goes unnoticed.
- Inform: sent by the agent and acknowledged by the receiver, so the sender can retry if no confirmation comes back.
- Cost: an inform asks more of both sides, because the receiver must answer and the sender must keep track of what is still unconfirmed.
For critical alerts, informs are the safer pick when both ends support them. Traps remain common because nearly every device can send them, and they are simple to configure.
The choice is rarely all or nothing. Many teams send informs for the few events that must never be missed, such as a failed power supply or a lost uplink, and leave chatty, low-value notifications as plain traps.
When to rely on traps and when to poll
Polling and traps answer different questions. Polling asks “what is your state?” on a schedule, so the answer is always as old as the last cycle. A trap answers “what just happened?” and arrives as the event unfolds.
That difference shapes how you design monitoring. Use traps for events that need immediate attention, and use polling for trends such as traffic, temperature or disk growth, where a steady series of readings matters more than a single alert.
- Link and interface changes: ideal for traps, because you want to know the moment a port drops.
- Hardware faults: suited to traps or informs, since a failing component may not wait for the next poll.
- Capacity and performance trends: better handled by polling, which builds a history you can graph.
- Silent failures: only polling can notice a device that stopped talking entirely, because a dead device cannot send a trap.
The last point is easy to miss. A trap reports what a working device can still say, so a device that loses power or crashes completely may send nothing at all. Regular polling is what tells you the device has gone quiet.
Combining both gives you speed from traps and certainty from polling. Neither replaces the other, and most monitoring tools are built around using the two together.
Making traps readable with MIBs
Raw traps arrive as strings of numbers. Icinga notes that a receiver converts raw OIDs into clear text messages using MIBs, and that missing MIB files are why traps sometimes show up as raw OIDs.
Our page on the SNMP MIB explains how those files name each OID. To see what a device exposes in normal polling, the snmpwalk command lists its OID tree, which helps when you match trap contents to values you already know.
A readable trap usually pairs the event name from the MIB with the extra bindings it carries. Instead of a long dotted number, you see a named event, the device that sent it and the values attached, which is far easier to act on at two in the morning.
If your own devices add custom enterprise events, keep their MIB files in one place and load them into the receiver whenever you add new hardware or update firmware. A new software release can introduce new trap types, and without the matching file they will look like unfamiliar numbers again.
Troubleshooting traps that never arrive
Start with the network path. Start by making sure UDP port 162 is reachable on the receiver.
- Confirm the device has the receiver’s correct address configured as a trap destination.
- Check that the community string or user credentials match what the receiver expects.
- Import the vendor’s MIB if alerts show only numbers.
- Remember that a plain trap lost on the wire leaves no error anywhere.
Pairing traps with regular polling covers that last gap: a periodic poll can catch a persistent problem even if its trap went missing, though a transient event may still be missed.
A practical test is to trigger a harmless event on purpose, such as disabling and re-enabling an unused port on a lab device. If the receiver logs the event, the whole path works. If nothing appears, work backwards: check the receiver’s listener first, then the firewall, then the device’s trap destination settings.
Also check whether the receiver is actually running with permission to listen. Port 162 is a low-numbered port, and on many systems binding to it needs elevated rights, so a receiver started as an ordinary user can fail quietly or refuse to start.
Frequently asked questions
What port do SNMP traps use?
Show answer
Receivers listen on UDP port 162, according to Icinga’s guide. Make sure firewalls let senders reach the receiver on that port; informs also need the reply traffic allowed.
Are SNMP traps reliable?
Show answer
Plain traps are not: there are no retransmissions and no acknowledgments. Informs add acknowledgment, so use them where a missed alert would hurt.
Do traps replace polling?
Show answer
No. Traps give instant notice of events, while polling gives regular health data and catches problems whose traps were lost.
Why does my trap show only numbers?
Show answer
The receiver probably lacks the MIB that names the OIDs. Import the vendor’s MIB into your trap tool.
