Define interface-counter semantics before alerting on errors

An interface counter is meaningful only when the collector knows what the interface represents, whether its identity remained stable, how wide the counter is, and whether it reset. Otherwise a wrap, reboot, or re-index can look like a giant error burst or impossible traffic rate.

Source fact:

IETF RFC 2863 defines the Interfaces Group MIB used to describe network interfaces through management protocols. It specifies objects for interface identity, type, speed, administrative and operational state, traffic octets and packets, errors, discards, multicast and broadcast counts, and relationships among layered interfaces. It also addresses high-capacity counters and the limitations of smaller counters at higher speeds.

The specification recognizes discontinuities and the operational need to determine when counters may have changed non-continuously. It distinguishes ifAdminStatus from ifOperStatus and provides interface-stack relationships rather than assuming every row represents one physical port. These semantics allow a management application to interpret data; they do not require every device to attribute every fault in the same vendor-specific way.

Boundary

Standard MIB object names do not guarantee uniform hardware accounting. Vendors may count frames before or after a pipeline stage, expose logical and physical layers differently, or omit unsupported detail. Polling intervals, missed polls, counter width, device uptime, interface-index persistence, link aggregation, and speed changes affect derived rates. An increasing discard counter does not identify whether the root cause is congestion, policy, resource pressure, or another implementation condition.

Applicability questions

• Is each monitored row mapped to a stable asset, interface name, physical location, and service purpose?
• Which counters are 32-bit or 64-bit, and can they wrap inside the polling interval at expected line rates?
• How does the collector detect device restart, interface discontinuity, re-indexing, and replacement?
• Which logical interfaces duplicate or aggregate traffic seen elsewhere?
• What platform documentation explains each error or discard counter used for alerting?

DSE recommendation:

Build a device-family counter dictionary that records source object, width, collection interval, unit, discontinuity signal, interface layer, and vendor meaning. Use stable identifiers and inventory reconciliation rather than treating ifIndex alone as permanent. Discard samples across a restart or unexplained discontinuity instead of calculating a rate through them.

Generate controlled traffic and a bounded fault in a lab or maintenance window to verify octet, packet, error, and discard behavior. Set alert thresholds from service impact, interface rate, baseline, duration, and topology role rather than one universal raw count. Correlate with queue, optics, link, routing, and application signals before assigning a cause. Review monitoring logic after hardware or software changes.

Verification and evidence

Retain the counter dictionary, device/version matrix, MIB source, interface mappings, poll timestamps, discontinuity handling, raw values, calculation formula, and controlled-test results. A sample alert should be reproducible from stored raw data and should identify whether a wrap or reset was excluded. Compare collector output with local device counters during commissioning.

Official references

• IETF RFC 2863