Port 162: SNMP Trap — The Cry in the Dark

Port 162 carries the screams.

Not the polite queries of network management. Not the scheduled check-ins where a monitoring system asks "are you okay?" and waits for an answer. Port 162 carries the other kind of message: the unsolicited warning, the unprompted cry, the alert that a device sends because it cannot wait for someone to ask what is wrong.

This is SNMP Trap. The emergency broadcast system of network infrastructure.

What Port 162 Does

When a router overheats, when a network link goes down, when someone tries to authenticate with the wrong credentials, the device does not wait for a management system to poll it. It generates a trap and sends it immediately to port 162 on the configured management station.

Port 161 is where SNMP managers send their questions. Port 162 is where they receive the answers they did not ask for.

The distinction matters. Port 161 operates on a pull model: the manager initiates, the agent responds. Port 162 operates on a push model: the agent initiates, and the manager listens.¹ One is a conversation. The other is an alarm.

The Mechanism

SNMP Traps are Protocol Data Units (PDUs) sent over UDP from an agent (the managed device) to a manager (the monitoring system). When a significant event occurs, the agent constructs a trap message containing:

• The type of event (generic or enterprise-specific)
• A timestamp
• Variable bindings with relevant data about the event

RFC 1157 specifies this clearly: "A protocol entity receives messages at UDP port 161 on the host with which it is associated for all messages except for those which report traps. Messages which report traps should be received on UDP port 162 for further processing."²

The agent fires the trap and moves on. There is no handshake. No acknowledgment. No confirmation that anyone heard.

This is the trap's defining characteristic and its fatal flaw. UDP provides no delivery guarantee. A device can scream its warning into the network and have no way to know if the message arrived. If a trap falls in the forest and no management station hears it, did it happen?

The Six Standard Traps

RFC 1215, published in March 1991, defined six generic trap types that became the lingua franca of network alerts:³

coldStart (0): The device has reinitialized in a way that may have altered its configuration. It woke up different.

warmStart (1): The device has reinitialized, but nothing fundamental changed. It just needed a moment.

linkDown (2): A communication link has failed. Something that was connected is no longer connected.

linkUp (3): A communication link has recovered. The path exists again.

authenticationFailure (4): Someone tried to access this device and failed authentication. Someone is knocking with the wrong key.

egpNeighborLoss (5): An Exterior Gateway Protocol neighbor has been lost. The device lost a friend.

Beyond these six, vendors can define their own enterprise-specific traps for anything their hardware might need to report. A UPS running low on battery. A fan failing inside a chassis. A temperature threshold crossed. Every manufacturer can teach their devices new ways to cry.

The History

Port 162's story begins in the late 1980s, when the Internet was growing faster than anyone could manually monitor it.

In 1987, four engineers published RFC 1028: the Simple Gateway Monitoring Protocol (SGMP).⁴ Jeffrey Case, Mark Fedor, James "Chuck" Davin, and Martin Schoffstall had a problem. The early Internet was expanding, and there was no standardized way to ask a router what it was doing or tell it to change its behavior. Each vendor had their own methods. Operational data was gathered through ad-hoc, proprietary tools.

SGMP was their first answer. But it was not quite right. The protocol was too limited, too gateway-focused, not extensible enough for the Internet that was coming.

In August 1988, the Internet Activities Board published three RFCs that transformed SGMP into something more powerful: RFC 1065 (Structure of Management Information), RFC 1066 (Management Information Base), and RFC 1067 (Simple Network Management Protocol).⁵ The syntax changed. The scope expanded. The name evolved. But the original philosophy remained: keep it simple, make it work.

RFC 1157, published in May 1990, became the definitive SNMPv1 specification.² It formalized the separation: port 161 for queries, port 162 for traps.

The Internet was learning to manage itself.

Why Not Just Poll?

If a management station can ask devices for their status every few minutes, why bother with traps at all?

Mathematics.

If you manage 10,000 devices, each with 100 monitored objects, and you poll every five minutes, you generate 2 million query-response pairs every five minutes. That is network load. That is processing overhead. That is 2 million small conversations, most of which return "everything is fine."

More importantly: if you poll every five minutes, the worst-case detection time for a failure is 4 minutes and 59 seconds after it happens.⁶ Nearly five minutes of silence while a critical link is down.

Traps invert the economics. Devices stay quiet when nothing is wrong. The moment something breaks, they speak. The management station hears about the failure seconds after it occurs, not minutes.

RFC 1157 put it plainly: "Trap-directed notification can result in substantial savings of network and agent resources by eliminating the need for frivolous SNMP requests."²

But traps have a blind spot. If a device fails catastrophically, it cannot send a trap about its own death. A server that loses power does not have the courtesy to announce its departure. This is why network management uses both: traps for immediate alerts, polling to confirm ongoing health and catch the silent failures.

The Problem of Lost Cries

SNMP Traps are sent over UDP, the connectionless, best-effort protocol. The device sends its message and hopes it arrives. If the network drops the packet, the device does not know. If the management station is overwhelmed, the device does not know. If a firewall blocks the trap, the device does not know.

The device screams into the void and trusts the void to carry its voice.

SNMPv2 attempted to address this with the INFORM PDU: a trap that expects an acknowledgment.⁷ When the management station receives an INFORM, it sends back a response. If the agent does not receive that response within a timeout period, it retransmits. This is nothing more than an acknowledged trap, the protocol admitting that sometimes you need to know your cry was heard.

But INFORMs consume more resources. The agent must hold the message in memory until confirmation arrives or the timeout expires. A trap is fire-and-forget. An INFORM is fire-and-wait-and-maybe-fire-again.

Most networks still use traps. Most cries still go unacknowledged.

The Security Story

SNMP's security history is a cautionary tale.

SNMPv1 and SNMPv2c authenticate using "community strings," which are transmitted in plaintext.⁸ A community string is a password, but it is sent naked across the network for anyone with a packet sniffer to read. The default community strings on many devices are "public" for read access and "private" for write access. Millions of devices shipped with these defaults. Many were never changed.

In February 2002, the PROTOS research project released test cases that revealed vulnerabilities in how hundreds of SNMP implementations handled trap messages. CVE-2002-0012 demonstrated that attackers could use malformed SNMPv1 traps to execute denial-of-service attacks or gain administrative privileges.⁹ The vulnerability was not in the protocol specification but in how vendors implemented trap parsing. The implementation details, the corners cut, the error handling skipped, all became attack surfaces.

The echoes of 2002 continued. In December 2024, a buffer overflow vulnerability was discovered in Net-SNMP's snmptrapd daemon. Maliciously crafted trap packets could crash the daemon, halting network monitoring until manual restart.¹⁰ Twenty-two years later, trap handling was still a target.

SNMPv3 added authentication and encryption, finally allowing trap traffic to be protected from eavesdropping and tampering.¹¹ But adoption has been slow. The simplicity that made SNMP successful also made it hard to upgrade. Many networks still run v2c. Many community strings are still "public."

The cries on port 162 often travel unprotected.

What Flows Through

Imagine a data center at 3 AM.

Thousands of machines hum in climate-controlled darkness. Routers forward packets. Switches link racks together. Servers process the requests of a sleeping world.

A fan begins to fail in a storage array. The temperature rises. A threshold is crossed. The device generates a trap: enterprise-specific, vendor-defined, carrying the object identifier that means "cooling fault" and the variable binding that specifies which fan, which shelf, which chassis.

The trap flies to port 162 on a management station. Software parses the MIB, translates the object identifier into human language, triggers an alert. A pager buzzes. An on-call engineer opens their laptop.

The device did not wait to be asked. It spoke when speaking mattered.

This happens millions of times per day across the Internet. linkDown when a fiber gets cut. authenticationFailure when someone probes a router with the wrong credentials. coldStart when a device reboots after a power glitch. Every trap is a moment where a machine chose to tell someone something had changed.

Port 162 is infrastructure awareness. The nervous system of the systems that run the systems.

Related Ports