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.

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.

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 covers the setup if you need it.

1. Walk the interface descriptions to see what exists and map the indexes:

   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):

   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:

   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 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: 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 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.