Project: interface error and utilisation monitor

Goal and what you will build

A link with a slowly failing optic may drop only a small fraction of frames, but that is enough to make voice calls choppy and file copies slow. Full monitoring platforms catch this, yet building your own small monitor teaches you exactly how they work. You will write a script that reads interface counters from lab devices, waits, reads them again, calculates rates and reports any interface whose errors or utilisation are too high.

Use lab devices or ones you are responsible for, with a read-only account. Polling is light, but keep the interval sensible (one to five minutes) on real equipment.

Design and the maths

Interface counters are cumulative: they only go up until the device reboots or someone clears them. A single reading tells you little. Two readings, t seconds apart, give a rate:

• Error rate = (errors now minus errors before) divided by (packets now minus packets before), as a percentage.
• Utilisation = (octets now minus octets before) multiplied by 8, divided by t, divided by the interface speed in bits per second, as a percentage.

For example, 750,000,000 octets received in 60 seconds on a 1 Gbps link is 750,000,000 x 8 / 60 = 100 Mbps, which is 10 percent utilisation. The bandwidth calculator helps you check your sums.

Tune thresholds to your environment; a backup link at 90 percent at 2 a.m. may be normal.

Build it step by step

1. Install NAPALM: pip install napalm pyyaml.
2. Read speeds with get_interfaces() and counters with get_interfaces_counters().
3. Take two samples, compute deltas and handle counter resets (a negative delta means the counter was cleared or wrapped).
4. Print a sorted table of problem interfaces and exit with a non-zero code if any alert fired, so schedulers and pipelines can react.
5. Test by generating traffic between two lab hosts, for example with iperf3, and watch utilisation rise.

#!/usr/bin/env python3
import os, sys, time
from napalm import get_network_driver

INTERVAL = 60          # seconds between samples
WARN_UTIL = 70.0       # percent
WARN_ERR = 0.01        # percent of packets

def sample(conn):
    return conn.get_interfaces_counters(), time.time()

def main(host):
    driver = get_network_driver("ios")
    alerts = []
    with driver(host, os.environ["NET_USER"], os.environ["NET_PASS"]) as conn:
        speeds = {n: i["speed"] for n, i in conn.get_interfaces().items()}  # Mbps
        before, t0 = sample(conn)
        time.sleep(INTERVAL)
        after, t1 = sample(conn)
    secs = t1 - t0
    for name, now in after.items():
        old = before.get(name)
        if not old or speeds.get(name, 0) <= 0:
            continue
        d_oct = now["rx_octets"] - old["rx_octets"]
        d_pkt = now["rx_unicast_packets"] - old["rx_unicast_packets"]
        d_err = now["rx_errors"] - old["rx_errors"]
        if d_oct < 0 or d_err < 0:
            continue                       # counters cleared or wrapped
        util = d_oct * 8 / secs / (speeds[name] * 1_000_000) * 100
        err = (d_err / d_pkt * 100) if d_pkt > 0 else 0.0
        if util >= WARN_UTIL or err >= WARN_ERR:
            alerts.append((name, round(util, 1), round(err, 3)))
    for name, util, err in sorted(alerts, key=lambda a: -a[1]):
        print(f"ALERT {host} {name}: rx util {util}% errors {err}%")
    return 1 if alerts else 0

if __name__ == "__main__":
    sys.exit(main(sys.argv[1]))

Tip: this example measures the receive direction. Repeat the calculation with the tx_ counters, because congestion is usually seen as output drops on the sending side.

How to extend it and show it

• Use SNMP (Simple Network Management Protocol) 64-bit counters such as ifHCInOctets with SNMPv3 for devices without NAPALM support; 32-bit counters wrap quickly on fast links.
• Store samples in a time-series database and graph them, or switch to streaming telemetry.
• Only alert after several bad samples in a row to avoid noise, and post alerts to chat with a webhook.
• Run across many devices in parallel with Nornir.

For your portfolio, include a lab diagram, a worked example of the utilisation maths in the README, and output captured while you deliberately loaded a link with iperf3. Explain counter resets and 64-bit counters: interviewers like candidates who understand the numbers behind the graphs.