In SNMP's IF-MIB, what does ifAdminStatus up with ifOperStatus down say about an interface, and how is that different from both being down?
answer
- desired versus actual
- one is writable, one is not
- a fault is presumed
- a shutdown is not a fault
basics
~20 sifAdminStatus is the desired state and ifOperStatus the actual one. Admin up with oper down means the interface should work but cannot, so RFC 2863 presumes a fault; both down means it was disabled on purpose, with no fault implied.
solid answer
~40 sIn IF-MIB (RFC 2863), `ifAdminStatus` is the **desired** state, read-write, with values `up(1)`, `down(2)` and `testing(3)`; `ifOperStatus` is the **current operational** state, read-only, with `up(1)`, `down(2)`, `testing(3)`, `unknown(4)`, `dormant(5)`, `notPresent(6)` and `lowerLayerDown(7)`. The RFC gives `down` two meanings: if `ifAdminStatus` is not down and `ifOperStatus` is down, a fault condition is presumed (a dead link, a missing signal); if `ifAdminStatus` is down, `ifOperStatus` will normally be down too and no fault is implied, because someone disabled it. So monitoring alerts on admin-up and oper-down, and ignores ports that are administratively down. The finer oper states matter too: `lowerLayerDown` blames an interface beneath it in the stack, and `dormant` means it is waiting for an external event.
go deeper
Recall that ifAdminStatus is what the interface is told to be and ifOperStatus is what it actually is, and that admin up with oper down is the fault case.
Explain the full ifOperStatus value set, especially lowerLayerDown, dormant and notPresent, and why only one of the two objects is writable.
Show alert rules built on both objects, the short wait RFC 2863 asks for when admin is down but oper is not, and how ifLastChange exposes flaps between polls.
Weigh status polling against linkUp and linkDown notifications for detecting outages across a large estate, including what each misses.
## Two objects, two questions The Interfaces Group MIB (RFC 2863) keeps two status objects in every `ifTable` row, and they answer different questions. | Object | Meaning | Access | Values | |---|---|---|---| | `ifAdminStatus` | the **desired** state, what the operator or configuration asked for | read-write | `up(1)`, `down(2)`, `testing(3)` | | `ifOperStatus` | the **current operational** state, what the interface is actually doing | read-only | `up(1)`, `down(2)`, `testing(3)`, `unknown(4)`, `dormant(5)`, `notPresent(6)`, `lowerLayerDown(7)` | `ifAdminStatus` can be changed by management action, including an SNMP set where the agent allows writes, or by the device's own stored configuration. `ifOperStatus` can only be observed. When a managed system initialises, every interface starts with `ifAdminStatus` `down(2)` and is then moved to `up(1)` or `testing(3)` by configuration or by a manager, or left down. ## Reading the combinations RFC 2863 section 3.1.13 spells out that `ifOperStatus` `down` means different things depending on `ifAdminStatus`: - **Admin up, oper up**: the interface is meant to work and does. Healthy. - **Admin up, oper down**: the interface is meant to work and cannot. The RFC says "a fault condition is presumed to exist". This is the combination to alert on. - **Admin down, oper down** (or `notPresent`): someone disabled it. There is "not (necessarily) a fault condition". Paging on this is noise. - **Admin down, oper still up**: usually a brief lag while the interface finishes work such as transmitting a packet. The RFC tells a manager to wait a short while and check again, raising an error only if the condition persists and `ifLastChange` has not moved. ## What happens after an interface is enabled When `ifAdminStatus` changes to `up`, the RFC lists what `ifOperStatus` should do: 1. go to `up` if and only if the interface can send and receive packets; 2. go to `lowerLayerDown` if an interface beneath it in the interface stack is preventing it; 3. go to `dormant` if it is operable but waiting for an external event, such as an on-demand link waiting for traffic or an incoming connection; 4. stay `down` if an error or fault is detected; 5. go to `unknown` if its state cannot be ascertained; 6. go to `testing` if tests must run first; 7. stay `notPresent` if components, typically hardware, are missing. `ifLastChange` records the value of `sysUpTime` when the interface entered its current operational state, so a poller can tell a long-standing outage from a flap that happened between polls. ## Why the distinction matters in monitoring - **Alert logic**: alert on `ifAdminStatus` = up and `ifOperStatus` = down (and usually `lowerLayerDown`); suppress ports that are administratively down. A rule on `ifOperStatus` alone pages for every unused, shut port. - **Root cause in stacks**: `lowerLayerDown` points down the stack, for example a logical interface whose physical port lost link, so the alert belongs on the lower row. - **Flaps between polls**: a poll every few minutes can miss a down-and-up. A changed `ifLastChange` reveals it; the IF-MIB `linkDown` and `linkUp` notifications, sent as `ifOperStatus` enters or leaves `down` (but not to or from `notPresent`), report it as it happens. - **Utilisation of a down port**: an interface that is down carries no traffic, so its octet deltas fall to zero. Checking the status objects separates a real outage from a polling or counter problem. ## A worked reading A poll of a 10 Gb/s uplink and the logical interface stacked on it returns: | Row | `ifAdminStatus` | `ifOperStatus` | Reading | |---|---|---|---| | physical port | `up(1)` | `down(2)` | meant to work, cannot: a fault, so this row gets the alert | | logical interface above it | `up(1)` | `lowerLayerDown(7)` | down only because the port beneath it is down | | unused spare port | `down(2)` | `down(2)` | shut on purpose: no alert | One fault, one alert: the physical port. The logical row explains the knock-on effect, and the spare port is noise that a rule on `ifOperStatus` alone would have paged on.
- Why is ifOperStatus read-only while ifAdminStatus is read-write?`ifAdminStatus` records an intention, so a manager or the device's configuration may set it. `ifOperStatus` reports what the interface can actually do, which depends on cabling, the far end, lower layers and hardware; writing it would only make the MIB lie. To bring an interface up you set the desired state and observe whether the operational state follows.
- When does the IF-MIB linkDown notification fire relative to ifOperStatus?RFC 2863 ties it to the operational state: `linkDown` is generated just before `ifOperStatus` enters `down` from another state, and `linkUp` just after it leaves `down`, except that transitions to or from `notPresent` generate neither. It carries `ifIndex`, `ifAdminStatus` and `ifOperStatus`, so the receiver can tell a shutdown from a fault.
A light switch and the bulb it controls: the switch is ifAdminStatus, the light you see is ifOperStatus. Switch on and room dark means something is broken; switch off and room dark is exactly what you asked for.
saying these in an interview costs you the question
- ifAdminStatus and ifOperStatus are two names for the same state
- Any interface with ifOperStatus down is a fault worth paging on
- A manager can bring a link up by writing ifOperStatus
- Admin down with oper still up is always an immediate error
- Oper down with admin up just means someone shut the port