SNMP Interface OIDs: IF-MIB ifTable & ifXTable Reference

By the SNMP Monitoring team · Reviewed July 2026

The IF-MIB is the single most-walked MIB in networking, and this is its cheat sheet. Everything about an interface — traffic, errors, discards, link state, speed, name — is a column in one of two tables: the classic 32-bit ifTable and the high-capacity 64-bit ifXTable. Both are indexed by ifIndex, so a single index ties a port's name, counters, and status together. Paste these into a MIB browser, an allowlist, or an SNMP poller and go.

This is the reference. The alerting how-tos are the twins over in monitoring: interface traffic, errors, bandwidth, port speed. Hubs: sensors, all OIDs.

ifTable columns

The original interface table at 1.3.6.1.2.1.2.2.1, one row per interface. The columns you actually reach for:

Every octet, error and discard column is a Counter32 — cumulative, so you graph the rate (diff between polls), never the raw value.

ifXTable high-capacity columns

SNMPv2c added the extended table at 1.3.6.1.2.1.31.1.1.1 — the 64-bit counters and better names:

• ifName — 1.3.6.1.2.1.31.1.1.1.1 — short port name (e.g. Gi1/0/1)
• ifHCInOctets — 1.3.6.1.2.1.31.1.1.1.6 — 64-bit bytes in
• ifHCOutOctets — 1.3.6.1.2.1.31.1.1.1.10 — 64-bit bytes out
• ifHighSpeed — 1.3.6.1.2.1.31.1.1.1.15 — speed in Mbit/s
• ifAlias — 1.3.6.1.2.1.31.1.1.1.18 — the admin-configured description/label

These share the same ifIndex as ifTable, so ifName.5 names the port whose ifHCInOctets.5 you're reading. ifAlias is the field engineers set to label a port ("uplink-to-core") — far more useful than ifDescr for a human.

32-bit vs 64-bit counters

The one distinction that matters most on this page:

Rule: on any link 1 Gbit or faster, poll the ifHC counters. A 32-bit counter can roll over its maximum in seconds on a fast link, and a wrap between two polls corrupts the rate. Only fall back to the 32-bit objects for slow links or agents that don't expose ifXTable.

ifIndex and naming

ifIndex is the integer that joins every column of every IF-MIB table for one interface — but it is not the faceplate number, and it is not guaranteed stable. Two caveats:

• The index can change across a reboot, or shift in blocks when line cards or stack members are added.
• So don't hard-code "index 5 = WAN." Re-map periodically by walking ifName/ifDescr/ifAlias and joining on the shared index.

This is why every serious poller rebuilds its index-to-name map on a schedule rather than trusting a one-time snapshot. The reliable read pattern:

1. Walk ifName (and ifAlias/ifDescr) to build a fresh index → port map.
2. Walk the counter column you want (e.g. ifHCInOctets) keyed by the same index.
3. Join the two on ifIndex so each counter is attached to a real port name.
4. For rates, repeat the counter walk after your interval and diff per index.

Worked snmpbulkwalk example

Use snmpbulkwalk on big interface tables — many rows per request over v2c:

snmpbulkwalk -v2c -c <RO_string> <host> 1.3.6.1.2.1.31.1.1.1.6

IF-MIB::ifHCInOctets.1 = Counter64: 48213847721
IF-MIB::ifHCInOctets.2 = Counter64: 1002934771155
IF-MIB::ifHCInOctets.3 = Counter64: 0

Then pull status and names on the same indexes:

snmpbulkwalk -v2c -c <RO_string> <host> 1.3.6.1.2.1.2.2.1.8
snmpbulkwalk -v2c -c <RO_string> <host> 1.3.6.1.2.1.31.1.1.1.1

IF-MIB::ifOperStatus.1 = INTEGER: up(1)
IF-MIB::ifOperStatus.3 = INTEGER: down(2)
IF-MIB::ifName.1 = STRING: Gi1/0/1

<RO_string> is a placeholder — allowlist the specific columns you poll, not the whole iso tree.

How to monitor interfaces (how-to)

Reference ends here. The procedures — turning octets into bps, error ratios, utilization against speed, spotting a down-negotiated port — live on the twins:

• Interface traffic — octets to bits per second
• Interface errors — error/discard rates
• Bandwidth — % utilization from counters and speed
• Port speed — ifSpeed vs ifHighSpeed

Broader: network monitoring, the standard MIBs at standard MIBs, the OID catalog, and glossary.

Frequently asked questions

What is the OID for interface traffic?

Inbound bytes are ifInOctets (1.3.6.1.2.1.2.2.1.10) or, on fast links, the 64-bit ifHCInOctets (1.3.6.1.2.1.31.1.1.1.6); outbound are ifOutOctets / ifHCOutOctets. All are cumulative counters, so you diff two reads to get a rate.

What OID is interface status?

ifOperStatus (1.3.6.1.2.1.2.2.1.8) is the operational link state — up, down, or testing. Pair it with ifAdminStatus (1.3.6.1.2.1.2.2.1.7), which says whether the port is configured up or was administratively shut, so you can tell a real fault from an intentional shutdown.

What's the difference between 32-bit and 64-bit interface counters?

The 32-bit ifInOctets/ifOutOctets in ifTable are Counter32 and can wrap past their maximum in seconds on gigabit-plus links, corrupting rate math. The 64-bit ifHCInOctets/ifHCOutOctets in ifXTable (SNMPv2c and up) are Counter64 and effectively never wrap — use them on fast links.

What is ifIndex?

ifIndex is the integer that identifies an interface across every IF-MIB column — ifName, ifOperStatus, ifHCInOctets and the rest all share it. It isn't the physical port number and isn't guaranteed stable across reboots or hardware changes, so map it to a name each time rather than hard-coding it.

Key takeaways

• IF-MIB has two tables: ifTable (1.3.6.1.2.1.2.2.1, 32-bit) and ifXTable (1.3.6.1.2.1.31.1.1.1, 64-bit).
• Octets/errors/discards are Counter32 — graph the rate, not the raw value.
• Key OIDs: ifOperStatus .8, ifInErrors .14, ifHCInOctets …31.1.1.1.6, ifHighSpeed …31.1.1.1.15.
• Use 64-bit ifHC counters on 1 Gbit+ links to dodge counter wrap.
• ifIndex joins every column but isn't stable — re-map to ifName/ifAlias periodically.
• Procedures: traffic, errors, bandwidth, port speed; catalog: sensors/all.