SNMP OIDs and MIBs Explained (Port 161, v2c vs v3)

Updated: October 2026

Every switch, printer and UPS on your network keeps count of something: bytes in, errors out, toner left, minutes of battery. SNMP is how a monitoring tool asks for those numbers, and it asks by address, not by name. Here's what an OID is, how MIBs turn those addresses into something readable, and how to poll devices on port 161 without leaving a community string open to anyone on the LAN.

What Is an OID?

An OID, or object identifier, is a dotted string of numbers that points to one value on a device. Each number is a branch in a single global tree. Read it left to right and you walk from the root down to the exact counter you want.

SNMP lives under 1.3.6.1, the iso.org.dod.internet branch. Two sub-branches matter day to day. 1.3.6.1.2.1 is mib-2, where the standard objects every vendor implements sit. 1.3.6.1.4.1 is enterprises, where each vendor gets its own number and builds its own subtree.

So 1.3.6.1.2.1.1.3.0 means: mib-2, then the system group, then sysUpTime, then instance 0. RFC 1213 defines sysUpTime as the time since the agent was last re-initialized, in hundredths of a second. The trailing .0 marks a single value. Table columns end with an index instead, like the interface number.

A handful of OIDs answer most first-day questions:

OID vs MIB: The Address and the Dictionary

The OID is the address. The MIB, or management information base, is the dictionary that names it. A MIB file is plain text that lists each object, its OID, its data type (Counter32, TimeTicks, OCTET STRING) and whether it's read-only.

The agent on the device doesn't need the MIB to answer. Ask it for 1.3.6.1.2.1.1.5.0 and it returns the hostname. Your monitoring tool loads the MIB so it can show "sysName" instead of a string of numbers, and so it knows a counter from a gauge.

Standard MIBs ship with every monitoring tool: SNMPv2-MIB for the system group, IF-MIB for interfaces, HOST-RESOURCES-MIB for CPU, memory and storage. Vendor MIBs cover everything else, like a firewall's session count or a UPS's battery temperature. You download those from the vendor's support site and load them into your NMS.

This r/ccna question gets the model almost right, and the top reply tightens it up: the OID is the numeric address, the MIB is the dictionary, and the agent just returns the value.

One MIB detail causes real bad data: counter size. The original interface counters are 32 bits wide, and RFC 2863 (June 2000) spells out how fast they wrap. At 10 Mb/s, ifInOctets can roll over in just over 57 minutes. At 1 Gb/s, it can roll over in 34 seconds. If you poll every five minutes, the graph lies. The RFC requires 64-bit counters (the ifHC objects) on interfaces faster than 20 Mb/s, so poll ifHCInOctets and ifHCOutOctets on anything modern.

How SNMP Talks: Get, Walk, Traps (Ports 161 and 162)

SNMP runs over UDP. RFC 3417 has agents listen on port 161 for requests and has managers listen on port 162 for notifications. That split explains two different firewall rules: the monitoring server reaches out to 161 on every device, and every device reaches back to 162 on the monitoring server.

Polling is the manager asking. GET fetches one OID. GETNEXT fetches whatever comes next in the tree, which is how a walk works: keep asking for the next one until you leave the subtree. GETBULK, added in v2c, pulls many rows in one round trip, which matters on big interface tables. SET writes a value, and read-only is the right default for monitoring.

Traps are the device talking first. A link goes down, a power supply fails, and the device sends a trap to port 162 without being asked. An inform is a trap that expects an acknowledgement, so it gets resent if it's lost.

The net-snmp tools make this concrete. Here's the same device queried three ways:

bash
# One value: uptime
snmpget -v2c -c <community> 10.0.0.5 1.3.6.1.2.1.1.3.0

# A walk: every interface name
snmpwalk -v2c -c <community> 10.0.0.5 1.3.6.1.2.1.2.2.1.2

# SNMPv3 with authentication and encryption
snmpwalk -v3 -l authPriv -u monitor -a SHA -A '<auth-pass>' -x AES -X '<priv-pass>' 10.0.0.5 1.3.6.1.2.1.1

On Windows, the SNMP agent isn't installed by default. Since Windows 10, version 1809, it's a Feature on Demand, added with DISM /Online /Add-Capability /CapabilityName:SNMP.Client~~~~0.0.1.0. On Windows machines you manage with an agent or PowerShell, WMI and CIM usually give you more than SNMP will.

SNMPv1 and v2c vs SNMPv3

Versions 1 and 2c authenticate with a community string. It's a shared password, and it crosses the network in plain text inside every packet. CISA's advisory TA17-156A (June 2017) puts it plainly: with v1 or v2 in use, "an adversary could sniff network traffic to determine the community string." Many devices also ship with a default read community, and "public" is the usual one.

A read-only string can be enough to do damage. Cisco's advisory for CVE-2025-20352 (September 24, 2025) covers a flaw in the SNMP subsystem of IOS and IOS XE. An attacker with a v2c read-only community string, or valid v3 credentials, could crash the device. With admin credentials too, they could run code as root on IOS XE. Cisco reported exploitation in the wild after local administrator credentials were compromised.

SNMPv3 replaces the community string with users, and each user runs at one of three security levels:

CISA's guidance is to run SNMPv3 at the highest level the device supports, which is authPriv on most gear, with different passwords for authentication and encryption. It also recommends ACLs that limit who can query, and a separate management network for SNMP traffic.

How RMM and NMS Tools Use SNMP

Plenty of devices can't run a monitoring agent: switches, firewalls, printers, UPS units, storage arrays, even some air conditioners. SNMP is the one language nearly all of them speak, which is why it has lasted.

A monitoring tool uses it in three steps. Discovery scans a subnet on port 161 and reads sysObjectID (1.3.6.1.2.1.1.2.0), which points into the vendor's enterprise branch and tells the tool what the device is. A template then decides which OIDs to poll and how often. Thresholds and trap rules turn those numbers into alerts. The same OIDs feed network discovery tools that map what's plugged in where, which a separate network mapping guide covers.

The tools differ mostly in how much of that template work they do for you. Our roundup of network management software compares them, and the LibreNMS review shows what an open-source option handles out of the box.

This r/sysadmin thread from July 2026 asks whether anyone still uses SNMP. The replies land on yes, with v3 preferred. One admin describes a printer-supply contract that uses SNMP page counts to ship toner before it runs out.

Jeremy's IT Lab covers SNMP managers, agents, messages and MIBs end to end in this CCNA lesson:

A Safe SNMP Setup, Step by Step

Start with what's already answering. A scan of your subnets on UDP 161 usually turns up devices nobody remembers enabling. Then work down this order:

1. List every device that responds on 161, and turn SNMP off on the ones you don't monitor.
2. Move every device that supports it to SNMPv3 authPriv, with SHA and AES and separate passwords for each.
3. Where v2c has to stay, replace default communities with long random strings, and keep them read-only.
4. Restrict queries with ACLs, so only your monitoring servers can reach port 161.
5. Put SNMP traffic on a management VLAN, away from user traffic.
6. Poll the 64-bit ifHC counters on anything faster than 20 Mb/s.
7. Patch network gear on the same cycle as servers, since the SNMP stack itself can carry bugs.

OIDs, in Short

An OID is the numeric address of one value on a device. The MIB is the dictionary that names it, port 161 is where you ask, and port 162 is where traps arrive. Use v3 authPriv, poll the 64-bit counters and lock the protocol down, and SNMP stays one of the cheapest sources of monitoring data you have.

Next, see how monitoring tools put these numbers to work in our network management software roundup.