How to Monitor Port Speed via SNMP (ifSpeed vs ifHighSpeed)

By the SNMP Monitoring team · Reviewed July 2026

A port that silently negotiates down is one of the sneakiest problems on a network. The link light is green, ifOperStatus says up, everything looks fine — but a gigabit port came up at 100 Mbit because someone crimped a cable badly or a switchport got pinned to the wrong speed. Now a tenth of the capacity you planned for is quietly gone, and you won't notice until the link saturates and users complain. SNMP catches this the moment it happens, if you know which object to read and which one lies to you on fast links.

This is the how-to for link speed and negotiation. The full IF-MIB object reference is the twin page interface OIDs. Parent: network monitoring.

ifSpeed vs ifHighSpeed

There are two speed objects and they don't agree on units, which is the source of endless confusion:

• ifSpeed (1.3.6.1.2.1.2.2.1.5) — the interface's current speed in bits per second. A gigabit port reports 1000000000. It's a 32-bit value, so it saturates at about 4.29 Gbit/s — meaning a 10G, 25G or 40G port can't be represented correctly and will misreport.
• ifHighSpeed (1.3.6.1.2.1.31.1.1.1.15) — the same speed expressed in megabits per second. A gigabit port reports 1000; a 10G port reports 10000. Because the unit is Mbit/s, it comfortably represents links far beyond what ifSpeed can.

Simple rule: read ifSpeed for a quick human-readable bps on links up to a gigabit, but use ifHighSpeed as the source of truth for anything 10G and above. Most monitoring systems poll both and prefer ifHighSpeed when it's non-zero.

Reading port speed

Get a single port, or walk the whole switch. For one interface where you know the ifIndex:

snmpget -v2c -c <RO_string> <host> 1.3.6.1.2.1.2.2.1.5.3 1.3.6.1.2.1.31.1.1.1.15.3

IF-MIB::ifSpeed.3 = Gauge32: 1000000000
IF-MIB::ifHighSpeed.3 = Gauge32: 1000

Both agree: index .3 is a healthy 1 Gbit port. To sweep every port and spot the odd one out, walk ifHighSpeed across the device:

snmpwalk -v2c -c <RO_string> <host> 1.3.6.1.2.1.31.1.1.1.15

IF-MIB::ifHighSpeed.1 = Gauge32: 1000
IF-MIB::ifHighSpeed.2 = Gauge32: 1000
IF-MIB::ifHighSpeed.3 = Gauge32: 100
IF-MIB::ifHighSpeed.4 = Gauge32: 1000

Index .3 reads 100 while its neighbours read 1000. On a rack of gigabit ports, that's your down-negotiated link staring back at you. Map the index to a name with ifName and go look at the cable. <RO_string> is a placeholder — keep real community strings out of committed scripts.

Detecting a speed drop

The catch: SNMP reports the current negotiated speed, not "the speed this port is supposed to be." A 100 Mbit reading is only a problem if that port ought to be doing a gigabit. So you compare against a baseline:

1. Record each port's expected speed once — either its historical normal or a documented design value.
2. Poll ifHighSpeed per interface on your regular interval.
3. Compare current speed to the recorded baseline for that ifIndex.
4. Alert when current is lower than expected — especially the classic 1000 → 100 drop.
5. Cross-check ifOperStatus (.8) so you only alert on links that are actually up; a down port reading 0 or a stale value isn't a negotiation fault.

That baseline comparison is what turns a raw speed reading into a useful alert. Without it you're just logging numbers; with it you catch the mis-negotiation the day it happens.

Speed and utilization

There's a second reason wrong speed hurts, beyond lost capacity: speed is the denominator in every utilization calculation. If a port down-negotiates to 100 Mbit but your monitoring still thinks it's a gigabit, your utilization percentage reads ten times too low — the link is actually saturated while the dashboard shows 8%. That's how a "we have plenty of headroom" graph coexists with users screaming about slowness.

So re-read ifHighSpeed regularly and feed the current value into the utilization math, not a hard-coded assumption. The full formula lives on bandwidth monitoring; the point here is that it's only as correct as the speed you pass it.

Duplex caveat

One thing SNMP's IF-MIB does not give you is duplex. There's no half/full-duplex flag in ifTable or ifXTable. Duplex lives in a separate MIB — the EtherLike-MIB, object dot3StatsDuplexStatus — if the device implements it. This matters because a duplex mismatch (one end full, the other half) produces exactly the late collisions and error trickle covered on interface errors. If speed looks right but a link is still misbehaving, duplex is the next thing to check — through EtherLike-MIB or the device CLI, not the standard interface table. See the reference twin for where these objects sit.

Reference

This is the how-to for link speed. For object types, the full interface column list and status enumerations, use the reference twin: interface OIDs. Related: bandwidth and interface traffic. Definitions at glossary; full index at all sensors.

Frequently asked questions

What OID is interface speed in SNMP?

ifSpeed (1.3.6.1.2.1.2.2.1.5) gives speed in bits per second, and ifHighSpeed (1.3.6.1.2.1.31.1.1.1.15) gives it in megabits per second. Use ifHighSpeed as the reliable one, especially on 10G and faster links.

Why is ifSpeed wrong on a 10G port?

Because ifSpeed is a 32-bit value in bits per second and tops out around 4.29 Gbit/s. Anything faster overflows that ceiling and reports incorrectly, so a 10G, 25G or 40G port must be read via ifHighSpeed, which uses Mbit/s and has plenty of headroom.

How do I detect a down-negotiated port?

Record each port's expected speed as a baseline, poll ifHighSpeed regularly, and alert whenever the current value is below the baseline for that ifIndex — the classic case being a gigabit port that comes up at 100. Cross-check ifOperStatus so you only flag links that are actually up.

Can SNMP show duplex?

Not from the standard IF-MIB — there's no duplex object there. Duplex is exposed by the EtherLike-MIB via dot3StatsDuplexStatus, if the device implements it. A duplex mismatch shows up indirectly as rising interface errors.

Key takeaways

• Two speed objects: ifSpeed (bps, 32-bit, caps ~4.29 Gbit) and ifHighSpeed (Mbit/s, reliable for 10G+).
• Use ifHighSpeed as the source of truth on fast links; ifSpeed misreports 10G and above.
• Detect down-negotiation by comparing current speed to a recorded baseline per ifIndex.
• Speed is the denominator of utilization — a stale speed makes a saturated link look idle.
• Duplex isn't in IF-MIB; it's dot3StatsDuplexStatus in the EtherLike-MIB.
• Types and columns: interface OIDs; an off-box external check via external monitoring still pages you when the site itself goes dark.