What Is Port 161?
Port 161 is the default SNMP port an agent listens on so a management system can query the device it runs on. The protocol defines the message formats. Port 161 is where the requests arrive and the replies leave.
The port belongs to the device being watched. A switch, router, firewall, server or UPS runs an agent bound to 161, and the conversation always starts from the management side.
Port 161 rarely works alone. Its counterpart, port 162, carries traffic in the opposite direction, and the two cover the polling and alerting halves of SNMP between them.
A branch office switch shows the pair at work. The management station asks it for interface counters on port 161, and when a link drops, the switch pushes an alert back on port 162.
What Is Port 161 Used For?
Port 161 is used for polling, where the management system asks and the device answers. The agent listens there continuously and returns the value held against each requested object identifier.
Everything collected on a schedule arrives through this port:
Interface data: throughput, errors, discards and link state per port
Resource data: CPU load, memory utilization and disk capacity
Hardware health: power supply status, fan state and chassis temperature
Device identity: system name, location, uptime and software build
Port 161 also accepts Set requests, which write a value instead of reading one. An operator can disable an interface or change a configuration variable without opening a console session. Because writes are possible, the port needs tighter treatment than a read-only service.
This request and reply pattern separates SNMP polling from agent-based monitoring that ships data outward on its own schedule.
Which Ports Does SNMP Use?
SNMP ports are four registered numbers, though most environments open only two. The table below lists each one, the direction traffic moves, and what it carries across monitored network devices.
Port | Transport | Listener | Direction | What it carries |
161 | UDP (TCP optional) | Agent on the device | Manager to agent | Get, GetNext, GetBulk and Set requests, plus the agent's replies |
162 | UDP (TCP optional) | Manager or trap receiver | Agent to manager | Traps and informs raised by the device |
10161 | DTLS over UDP, TLS over TCP | Agent on the device | Manager to agent | The same requests, wrapped in a transport security layer |
10162 | DTLS over UDP, TLS over TCP | Manager or trap receiver | Agent to manager | Secured notifications |
Ports 10161 and 10162 appear only where the transport security model is in use. Plenty of production networks never enable them.
What Is Port 162 Used For?
Port 162 is used to receive notifications the device sends without being asked. The listener here is the management system, which reverses the roles compared to port 161.
Devices raise them the moment something changes: a power supply fails, a fan stops turning, an interface flaps, or a configuration gets written.
Two notification types share the port:
Traps: fire and forget, so the sender never learns whether the message landed
Informs: acknowledged and retransmitted until a reply comes back, which suits alerts worth the extra traffic
Both formats are covered in more depth under SNMP traps.
What's the Difference Between Port 161 and Port 162?
The difference between port 161 and port 162 is which side opens the conversation and what prompts it.
Who listens: the agent listens on 161, the management system listens on 162
What starts it: a scheduled request starts 161 traffic, a change on the device starts 162 traffic
What it answers: 161 answers "what is the state right now", 162 answers "something just changed"
When it fails: a lost request on 161 shows up as a polling gap, a lost trap on 162 passes unnoticed
Environments run both because they cover different timescales. On a five-minute polling cycle, an interface that drops just after a poll stays invisible for the rest of that cycle, and a trap on 162 closes that window. Polling alone reacts slowly to sudden faults, and traps alone give alarms with no baseline behind them.
Does SNMP Use TCP or UDP?
SNMP uses UDP by default on both 161 and 162. UDP carries no connection setup and no retransmission logic, so a polling cycle against thousands of devices costs very little compared with connection-oriented network protocols.
The trade-off is delivery:
A dropped request disappears, and the manager notices only when the reply timer expires
A dropped trap disappears more quietly, because nothing on either side tracks it
A busy link can reorder or delay responses, which reads as a slow device
TCP transport is defined for SNMP and some agents support it. It stays uncommon, since holding connection state for every polled device costs more than the reliability returns.
Do SNMP Versions Affect the Port Numbers?
SNMP versions don't change the port numbers. SNMPv1, SNMPv2c and SNMPv3 all use 161 for requests and 162 for notifications, and one agent can serve several versions on the same port.
What changes is the security model inside the message:
SNMPv1 and v2c: authenticate with a community string sent in cleartext
SNMPv3: adds user-based authentication, message integrity checking and payload encryption
Port numbers also stay the same over IPv6. Only the address family changes, so an agent reachable at an IPv6 address still answers on 161.
How Do You Check Whether Port 161 Is Working?
Checking port 161 means confirming three things in order: the agent is listening, the path is open, and the credentials match. Test them separately, because all three fail in a way that looks identical from the management console.
On the device: confirm the SNMP service is running and bound to 161, and check that the agent's allowed-manager list includes your polling system
Along the path: verify that inbound UDP 161 survives every firewall, router ACL and security group between manager and device
From the manager: issue a single Get against a common object such as system uptime, which proves reachability and credentials together
An SNMP walk against port 161 goes further, returning the full set of objects the device will expose. Run it once during onboarding to see what a device can report before building anything on top of it.
Can the Default SNMP Ports Be Changed?
The default SNMP ports can be changed on most agents and management systems, though the change buys less than it appears to. A non-standard port slows casual scanning, and a determined scan finds the service anyway.
The operational cost lands elsewhere:
Every network discovery profile, firewall rule and monitoring template that assumed 161 needs the new value
A device commissioned later from an old runbook goes unmonitored until somebody notices
Documentation and vendor guidance still describe 161, so every troubleshooting session starts with a correction
Where the change is warranted, record it against the device group as a configuration item.
How Should Port 161 Be Secured?
Port 161 is secured by limiting who can reach it and encrypting what passes through. An agent answers anyone holding a valid community string, so exposure is the first control.
Port 161 is safe to open on an internal management network with the controls below in place. It should never face the internet.
Restrict inbound 161 at the firewall to the addresses of your polling systems, and allow inbound 162 only from monitored subnets
Keep both ports off any internet-facing interface, since an open 161 is readily abused in reflection and amplification attacks
Prefer SNMPv3 with authentication and privacy on anything carrying sensitive topology or configuration data
Replace default community strings, and give read-only credentials to any system that never needs to write
Log denied attempts on both ports so that scanning activity surfaces during review
What Causes Port 161 and 162 Problems?
Port 161 and 162 problems usually trace back to something in the path between manager and agent. The symptom points to the cause more reliably than it first appears.
No polling data at all: a filtered port, a stopped agent, a source address outside the agent's permitted list, or a community string that no longer matches. Access control lists on intermediate hops block this traffic quietly
No alerts arriving: the device was never told where to send them, the receiver isn't listening on 162, or the messages are dropped in transit
Intermittent gaps: packet loss, an overloaded agent that deprioritizes management traffic, or timeouts set too tight for the round trip
Slow or partial responses: a device answering a bulk request larger than it can handle, which returns a truncated result instead of an error
Explore More IT Terms
Browse our comprehensive IT glossary to learn more about technology terminology.