---
type: Article
title: "SNMP Interface Info"
description: "Before graphing traffic you need the interface inventory: names, link state and rated speed from the ifTable, and why a link dropping to down is a top alert."
resource: "https://snmp-monitoring.com/sensors/network/interface-info/"
tags: [sensors, snmp]
timestamp: 2026-07-13T00:00:00Z
---

# SNMP Interface Info

Before you can graph a single byte of traffic, you need to know what interfaces a device even has — and SNMP interface info is how you find out. It's the inventory layer: the names, the link states, the rated speeds that describe every port on a box. This page covers what that descriptive data contains, the exact `ifTable` OID that returns it, how to read the operational status of a link, and why an interface that quietly drops to *down* is one of the most useful alerts you can wire up.

## What is Interface Info and why monitor it

Interface info is the static and semi-static description of each network interface a device presents: its name, its type, how fast it's rated, and whether it's currently up or down. Where the traffic counters tell you *how much* is flowing, interface info tells you *what exists and whether it's alive*. Every managed switch, router, server, and firewall publishes this through the same standard table, which makes it the natural starting point for any monitoring setup.

The single most operationally valuable field here is link state. An interface has an *administrative* status (what you configured — enabled or shut) and an *operational* status (what's actually happening on the wire). When those two disagree — admin says up, operational says down — you've got a cable, a transceiver, or a far-end device that's failed. That mismatch is gold for alerting.

There's a subtler reason interface info deserves attention first: the `ifIndex` that keys every row isn't guaranteed to stay put. On many devices it's stable across a reboot, but on some it can shuffle when hardware is added, a module is reseated, or the OS re-enumerates its NICs. If your traffic and error graphs are pinned to raw index numbers and those numbers move, you end up graphing `eth3` under a label that still says `eth0`. Re-reading `ifDescr` periodically and reconciling it against your expected map is how you catch that quietly before it corrupts a week of history.

Why monitor it? A few concrete payoffs. You catch a critical uplink going down the moment it happens, instead of when users start complaining. You detect a duplex or speed mismatch — a gigabit port that negotiated down to 100 Mbps and is now a silent bottleneck. And you keep an accurate map of which `ifIndex` maps to which physical port, so the traffic and error graphs you build on top actually point at the right interface. Get the interface info right and every other network sensor becomes trustworthy. Get it wrong and you're graphing the wrong port. That's the whole case for reading SNMP interface info first.

![Diagram of an external SNMP poller reading ifDescr, ifSpeed and ifOperStatus from a switch's ifTable for interface info discovery](https://snmp-monitoring.com/img/sensors/interface-info-poll.webp)

## The OID: 1.3.6.1.2.1.2.2.1

The OID that holds all of this is `1.3.6.1.2.1.2.2.1` — the `ifTable` (`ifEntry`) from the IF-MIB, defined in RFC 2863. It's a table: one row per interface, each row keyed by an integer `ifIndex`, with a set of columns describing that interface. Three columns carry the day-to-day useful information.

| Column | OID | Meaning |
|---|---|---|
| `ifTable` (parent) | `1.3.6.1.2.1.2.2.1` | Interface table, one row per `ifIndex` |
| `ifDescr` | `1.3.6.1.2.1.2.2.1.2` | Interface name / description (text) |
| `ifSpeed` | `1.3.6.1.2.1.2.2.1.5` | Rated speed in bits per second (`Gauge32`) |
| `ifOperStatus` | `1.3.6.1.2.1.2.2.1.8` | Operational link state (enumerated integer) |

`ifDescr` at column `.2` is a human-readable label like `eth0` or `GigabitEthernet0/1`. `ifSpeed` at `.5` is the interface's rated bandwidth in bits per second — handy, though note it maxes out at ~4.29 Gbps because it's a 32-bit gauge, which is why fast links report speed through `ifHighSpeed` in the extensions table instead. And `ifOperStatus` at `.8` — the interface status OID everyone actually wants — is an enumerated integer: `1` = up, `2` = down, `3` = testing, `4` = unknown, `5` = dormant, `6` = notPresent, `7` = lowerLayerDown. For most alerting you care about one thing: is it `1`, or is it not?

## How to query it

Any Net-SNMP client reads the `ifTable` in seconds. These examples assume an SNMPv2c agent with a read-only community; the [snmpd.conf guide](/setup/snmpd-conf.md) covers the setup if you need it.

1. **Walk the interface descriptions** to see what exists and map the indexes:
   ```bash
   snmpwalk -v2c -c public 10.0.0.5 1.3.6.1.2.1.2.2.1.2
   ```
   Sample output:
   ```
   IF-MIB::ifDescr.1 = STRING: lo
   IF-MIB::ifDescr.2 = STRING: eth0
   ```
2. **Read the operational status** of a specific interface (here `ifIndex` 2):
   ```bash
   snmpget -v2c -c public 10.0.0.5 1.3.6.1.2.1.2.2.1.8.2
   ```
   ```
   IF-MIB::ifOperStatus.2 = INTEGER: up(1)
   ```
3. **Render the whole table** as a grid with `snmptable`:
   ```bash
   snmptable -v2c -c public 10.0.0.5 1.3.6.1.2.1.2.2.1
   ```

When it comes back empty, the cause is almost always the same: the OID isn't in the agent's view. Add the `ifTable` subtree to your [OID allowlist](/setup/oid-allowlist.md) and walk again. A request that hangs instead is a different animal — wrong community, wrong port, or a firewall in the path — not the OID.

## Normal vs alarming values & thresholds

Interface info isn't a smooth numeric metric you set a ceiling on. It's mostly state, so you alert on state transitions rather than crossing a line. Here's what healthy versus alarming looks like:

- **`ifOperStatus` = up(1) on interfaces that should be up** — normal. This is the baseline you want.
- **`ifOperStatus` = down(2) on a monitored uplink** — alarming. Alert immediately; a load-bearing link just failed.
- **Admin up but operational down (`lowerLayerDown` / `down`)** — a physical fault: unplugged cable, dead transceiver, failed far end.
- **`ifSpeed` lower than expected** — a negotiation problem; a gigabit port that came up at 100 Mbps is a silent bottleneck.
- **`ifDescr` or `ifIndex` mapping changed** — interfaces got renumbered (common after a reboot or hardware change); your other graphs may now point at the wrong port.

The rule of thumb: don't alert on unmonitored or intentionally-disabled ports — you'll drown in noise. Pick the interfaces that matter (uplinks, server NICs, trunk ports), watch their `ifOperStatus`, and treat a drop to anything other than `up(1)` as a real event.

## Alerting on this metric externally

Watching `ifOperStatus` from a box that sits on the same network has an obvious weakness: if the interface that fails is the one carrying your monitoring traffic, the alert never leaves the building. The link goes down, and the tool meant to tell you about it goes down with it. You find out from users instead.

Polling from outside removes that dependency. It's the principle behind [double durability](/monitoring/double-durability.md): an independent checker reads the interface state from beyond your network, so a downed uplink still generates an alert even though the device can no longer reach your internal collector. SNMP being a pull protocol makes this clean — the external side simply reads `1.3.6.1.2.1.2.2.1.8` on its own schedule.

In practice that's what [ostr.io Monitoring](https://ostr.io/service/monitoring) provides: agentless, zero-setup checks from outside your network, with real-time email and SMS alerts the moment a watched interface stops reporting *up* — so a failed link reaches you even when the device that owns it can't.

![Table view of SNMP interface info showing ifIndex, interface name, speed and operational status with one link marked down](https://snmp-monitoring.com/img/sensors/interface-info-status.webp)


## FAQ

**What's the difference between `ifOperStatus` and `ifAdminStatus`?**
`ifAdminStatus` is the state you configured — whether the interface is administratively enabled or shut. `ifOperStatus` (column `.8`, the interface status OID) is what's actually happening on the wire. When admin says up and operational says down, you have a physical fault worth alerting on.

**Which OID gives me the interface name?**
`ifDescr` at `1.3.6.1.2.1.2.2.1.2`. Walk that column first — it maps each `ifIndex` to a readable name like `eth0`, which you'll need to label every other interface graph correctly.

**Why does `ifSpeed` show the wrong number on a 10G link?**
`ifSpeed` is a 32-bit gauge that tops out around 4.29 Gbps, so it can't represent faster links accurately. For high-speed interfaces read `ifHighSpeed` from the [interface traffic](/sensors/network/interface-traffic.md) extensions table instead.

**Which SNMP version should I use?**
SNMPv2c is fine for read-only polling on a trusted network and is what most setups run. Move to SNMPv3 when you need authentication and encryption on the wire.

## Conclusion

SNMP interface info lives in one table — the `ifTable` at `1.3.6.1.2.1.2.2.1` — where `ifDescr` (`.2`) names each interface, `ifSpeed` (`.5`) gives its rated speed, and `ifOperStatus` (`.8`) tells you whether the link is actually up. It's the inventory every other network sensor depends on, so read it first, alert on the status transitions that matter, and keep your index-to-port mapping accurate. Publish the table in your [snmpd.conf](/setup/snmpd-conf.md), confirm it survives your [OID allowlist](/setup/oid-allowlist.md), and see the rest of the [sensor & OID catalog](/sensors/index.md) or the [full OID list](/sensors/all.md). Reading link state from outside is what turns "the port is down" into an alert instead of a surprise.