SNMP uses two UDP ports, and they are not a request and a response pair. UDP 161 is where a device listens for questions from a monitoring system. UDP 162 is where the monitoring system listens for traps, the notifications a device sends without being asked.
The traffic on one runs manager to device and the traffic on the other runs device to manager, so a firewall rule written for SNMP in a single direction gets polling working and loses every alert, or the reverse. Both failures present as broken monitoring rather than as a rule that was only half written.
- UDP 161: the device listens, the monitoring system asks
- UDP 162: the monitoring system listens, the device speaks first
- They are opposite directions, not two halves of one conversation
- RFC 3417 suggests both numbers rather than mandating them
- The 1990 standard permits treating every message as authentic
On this page
The two portsTwo ports that face opposite ways
The clearest way to hold this is to stop calling both of them the SNMP port.
RFC 3417 is where the numbers come from, and its language is worth reading exactly. It suggests that entities supporting command responder applications listen on UDP 161, and that entities supporting notification receiver applications listen on UDP 162. Those are two different roles on two different machines.
Command responders are the SNMP agents on network devices: a switch, a server, a printer, an uninterruptible power supply, each waiting to answer questions. A notification receiver is the monitoring system, waiting to be told that something happened.
| UDP 161 | UDP 162 | |
|---|---|---|
| Who listens | The device being monitored | The monitoring system |
| Who sends first | The monitoring system | The device |
| What it carries | Questions, and answers to them | Traps and other unsolicited notifications |
| Direction of the rule | Manager to device | Device to manager |
| If it is blocked | Nothing is collected from the devices, and graphs go flat | Polling still works, and every trap vanishes silently |
Read the bottom row. Blocking port 161 is loud, because every graph stops. Blocking port 162 is silent, because everything continues to look healthy and the one trap that would have told you otherwise never arrives. That asymmetry is why the half written firewall rule is worth naming.
Note also that RFC 3417 says suggests rather than requires. The default port numbers are universal in practice and they are configurable, which matters when a network device is not answering on the port everybody assumes.
The messagesWhat actually travels on each
The original standard, RFC 1157 from May 1990, defines five message types, and knowing which of the five you are relying on explains most SNMP behavior.
| Message | Port | What it does |
|---|---|---|
| GetRequest | 161 | Asks for the value of a named object |
| GetNextRequest | 161 | Asks for the next object, which is how a tree gets walked |
| SetRequest | 161 | Writes a value, and this is the one that changes configuration |
| GetResponse | 161 | The answer coming back |
| Trap | 162 | The device announcing something, unprompted, with no reply expected |
GetBulk and Inform do not appear in the 1990 standard at all; they came later. The practical difference worth knowing is that informs are acknowledged and traps are not. A trap is sent once over UDP and nobody retries it, so a notification lost to a dropped packet is simply gone.
SetRequest is the row to think about twice. SNMP is not only a read protocol. Write access means configuration changes over UDP, which is the reason the next section matters more than the port numbers do.
SecurityWhat the standards themselves say about the security
This is usually written as a warning about default community strings. The standards put it more plainly than any warning does.
RFC 1157 introduces the community, a string of octets that names the group a message belongs to, and describes the rules for deciding a message is authentic as an authentication scheme. Then it says something remarkable in its own text: some implementations may wish to support only a trivial authentication service that identifies all SNMP messages as authentic.
That is the root of the problem, written into the standard in 1990. A community string is a name, checked by whatever scheme the implementation chose, sent in the clear over UDP, and the standard explicitly contemplates a scheme that accepts everything. Guessing public for read and private for write still works on equipment nobody has revisited.
SNMPv3 is the answer, and RFC 3414 says exactly what it was built against. Its principal threats are modification of information, meaning an unauthorized party altering messages in transit, and masquerade, meaning operations attempted under somebody else's identity. Two more are named as secondary: disclosure, the eavesdropping risk, and message stream modification, the reordering, delaying or replaying of messages.
The word secondary is doing real work there. RFC 3414 notes that protecting against disclosure may be required as a matter of local policy, which is a standards document saying that encryption is optional.
So v3 with authentication and no privacy is a legitimate configuration, and it still sends the contents of the reply in the clear. If the reason for moving to v3 was that somebody could read the traffic, authentication alone does not fix it.
TroubleshootingWhen SNMP is not working
Graphs went flat everywhere. That is port 161, and usually a firewall, an access list on the device, or the SNMP agent not running.
Graphs are fine and no traps ever arrive. That is port 162, in the other direction, and it is the failure this page exists for. Test it by generating a trap rather than by waiting for one.
One device answers and its neighbor does not. Compare the community string or the SNMPv3 user, and compare the access list on the device itself, which is a separate security control from the network firewall.
It works from the monitoring server and not from your laptop. Expected. Most SNMP agents are configured to answer only named sources, and that is the security control doing its job.
Replies are truncated or large walks fail. RFC 3417 requires an entity to accept messages of at least 484 octets and recommends 1472. That upper figure is the familiar payload of a standard sized frame, so a path with a smaller effective size is worth checking against MTU and fragmentation.
Nothing is wrong and the data is stale. Polling is on an interval. A five minute interval cannot show a thirty second outage, and no port is at fault.
PitfallsWhere people go wrong
Calling 161 the SNMP port. It is half of it, and the missing half is the one that carries the alerts.
Opening port 162 inbound to the world. Traps in v1 and v2c are unauthenticated notifications over UDP, so anything that can reach the receiver can send it whatever traps it likes.
Leaving write access enabled. Most monitoring needs read only. SetRequest exists, and a write community on a network device reachable from the wrong place is a configuration change waiting to happen.
Assuming v3 means encrypted. RFC 3414 treats disclosure as a secondary threat and privacy as a local policy decision. Authentication without privacy is a valid v3 configuration and it is not encryption.
Testing traps by waiting. Alerts that never arrive look identical to a quiet network. Generate one on purpose the day the monitoring is set up.
Forgetting the device has its own access list. The firewall is not the only thing that decides who may ask. The agent usually has a list of permitted managers, and it is a separate place to look.
ComparisonSNMP, syslog, flow data and an agent, side by side
| Criterion | SNMP | Syslog | Flow data | An agent |
|---|---|---|---|---|
| Who starts it | Both, on different ports | The device | The device | The agent |
| What it is good at | Counters and state, on demand | Events and messages | Who talked to whom | Everything on that host |
| Needs software installed | No | No | No | Yes |
| Works on a switch or a UPS | Yes | Usually | Varies | No |
| Can change configuration | Yes, with write access | No | No | Yes |
The row that decides where SNMP stays useful is the fourth. Almost every piece of network hardware speaks SNMP, and almost none of those devices will run agents of their own, which is why a protocol designed in 1990 is still how the switches and the uninterruptible power supplies get monitored.
FAQFrequently asked questions
What port does SNMP use?
Two ports. UDP 161 on the device, where it listens for queries from a monitoring system, and UDP 162 on the monitoring system, where it listens for traps sent by network devices.
What is port 161 used for?
Polling. The monitoring system sends requests to UDP 161 on the device, and the device answers with the values it was asked for.
What is port 162 used for?
Receiving traps and other notifications. The device sends traps to UDP 162 on the monitoring system, unprompted, when something it was configured to report happens.
Is SNMP TCP or UDP?
UDP in normal use, not TCP. RFC 3417 defines the mapping onto UDP, which is also why a lost trap is simply lost rather than retransmitted.
Why are there two SNMP ports?
Because the two flows go in opposite directions. One is a question from the manager to the device and the other is an announcement from the device to the manager, so each side needs somewhere to listen.
Can SNMP ports be changed?
Yes. RFC 3417 phrases 161 and 162 as suggestions, and most implementations let you configure them. They are close to universal in practice.
What is the difference between a trap and an inform?
Informs are acknowledged and traps are not. A trap goes out once over UDP with nothing to confirm it arrived, which is why an important notification is better sent as an inform where the network device supports it.
Is SNMP secure?
Not in v1 or v2c. The community string is sent in the clear and RFC 1157 itself allows an implementation to treat all messages as authentic. SNMPv3 adds real authentication, and privacy on top of it as a separate choice.
Does SNMPv3 encrypt traffic?
Only if privacy is configured. RFC 3414 names disclosure as a secondary threat and says protection against it may be required as a matter of local policy, so authentication without encryption is a valid v3 setup.
What are the default SNMP community strings?
Public for read and private for write are the conventional default community strings, and they are still present on network devices that were installed and never revisited. Both should be changed, or the version moved to SNMPv3.
Can SNMP change a device's configuration?
Yes, through SetRequest, if write access is enabled. Most monitoring needs read only, and leaving write enabled is the larger of the two risks on this page.
Why is my monitoring showing no alerts?
Check port 162 in the direction from the devices to the monitoring system. Polling can be working perfectly while every trap is being dropped, and the result looks like a healthy network rather than a broken one.
How big can an SNMP message be?
RFC 3417 requires an entity to accept at least 484 octets and recommends supporting 1472. Larger is encouraged, and paths with a smaller usable size are worth checking when large responses fail.
What is the SNMP trap port, and what changed in SNMP v3?
The SNMP port number for polling is UDP 161, and the SNMP trap port is UDP 162, which is where devices send unsolicited alerts to the manager. SNMP v3 adds user based authentication and encryption. Versions 1 and 2c send the community string in clear text.
Keep readingRelated concepts
Read next · Protocols TCP vs UDP Why a trap that is dropped is simply gone, and what choosing the connectionless transport buys in return. Open this next10 min- Managed IT · 9 min What RMM Is, and What the Agent Can Actually Do The monitoring platform on the other end of these two ports, and what it adds on top of asking a device how it is.
- Ports · 12 min What Is a Port Number? What a port number is doing in the first place, and why two of them on two machines is the normal arrangement rather than an oddity.
- Tools · 11 min Network Management Software, and the Three Questions It Has to Answer What the polling is feeding.