
Network Interface Health
Diagnose link-level packet loss, CRCs, duplex mismatches, and counter trends on switches, routers, and Linux hosts with before/after evidence.
Overview
Network Interface Health is an agent skill most often used in Operate (also Ship launch prep) that diagnoses interface errors, flaps, and counter trends on network gear and Linux hosts.
Install
npx skills add https://github.com/affaan-m/everything-claude-code --skill network-interface-healthWhat is this skill?
- Structured workflow: baseline counters, wait interval, re-sample, compare increments
- CLI recipes for Cisco-style show interfaces and Linux ip -s link / ethtool -S
- Counter reference table for CRC, runts, giants, drops, and duplex-related symptoms
- Compare both ends of a link before hardware swaps
- Change-window before/after evidence capture for interface flaps
- Counter reference table covering CRC, runts, giants, drops, and related receive/transmit errors
Adoption & trust: 1.2k installs on skills.sh; 210k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You have flaky connectivity or rising error counters but no disciplined before/after link evidence to separate cable, port, duplex, or congestion causes.
Who is it for?
Solo devops founders or SREs debugging production NIC or switch-port issues with CLI access to gear and hosts.
Skip if: Pure application-layer bugs with clean interface counters and stable ping—start upstream in app logs instead.
When should I use this skill?
Packet loss, latency spikes, interface CRCs/drops/flaps, or rising ifInErrors, ifOutErrors, and ifOutDiscards need link-level diagnosis.
What do I get? / Deliverables
You produce a counter trend report, mapped symptom-to-cause hypotheses, and both-end link checks suitable for a fix or change rollback decision.
- Baseline and follow-up counter comparison notes
- Symptom-to-likely-cause table keyed to observed counters
- Recommended next physical or config checks before hardware swap
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Operate is where production links fail intermittently and interface counters explain symptoms better than app logs alone. Monitoring subphase fits trending ifInErrors, ifOutDiscards, and baseline-vs-interval counter comparison.
Where it fits
Trend ifOutDiscards on a congested uplink during a traffic spike.
Map rising CRC counts to cable or optic replacement before escalating to the ISP.
Capture baseline and post-deploy interface stats during a cutover window.
How it compares
Link-layer diagnostic playbook, not a cloud uptime dashboard or synthetic HTTP monitor alone.
Common Questions / FAQ
Who is network-interface-health for?
Indie operators and small teams responsible for routers, switches, or bare-metal/Linux networking without a dedicated NOC.
When should I use network-interface-health?
In Operate monitoring when errors or flaps trend up, and in Ship launch when you need pre/post change-window interface proof on critical links.
Is network-interface-health safe to install?
It suggests read-oriented show and ethtool commands but you control execution; review the Security Audits panel on this page before installing.
SKILL.md
READMESKILL.md - Network Interface Health
# Network Interface Health Use this skill when a network symptom might be caused by a physical link, switch port, cable, transceiver, duplex setting, or congested interface. ## When to Use - A host or VLAN has packet loss, latency spikes, or intermittent reachability. - A switch or router interface shows CRCs, runts, giants, drops, resets, or flaps. - You need to compare both ends of a link before replacing hardware. - A change window needs before/after interface counter evidence. - Monitoring reports rising `ifInErrors`, `ifOutErrors`, or `ifOutDiscards`. ## How It Works Interface counters are evidence, but the trend matters more than the absolute number. Capture a baseline, wait a measurement interval, capture again, then compare increments. ```text show interfaces <interface> show interfaces <interface> status show logging | include <interface>|changed state|line protocol ``` On Linux hosts: ```text ip -s link show <interface> ethtool <interface> ethtool -S <interface> ``` ## Counter Reference | Counter | Meaning | Common cause | | --- | --- | --- | | CRC | Received frame checksum failed | Bad cable, dirty fiber, bad optic, duplex mismatch | | input errors | Aggregate receive-side errors | Check sub-counters before concluding | | runts | Frames below minimum Ethernet size | Duplex mismatch, collision domain, faulty NIC | | giants | Frames larger than expected MTU | MTU mismatch or jumbo-frame boundary | | input drops | Device could not accept inbound packets | Burst, oversubscription, CPU path, queue pressure | | output drops | Egress queue discarded packets | Congestion, QoS policy, undersized uplink | | resets | Interface hardware reset | Flapping, keepalive, driver, optic, power | | collisions | Ethernet collision counter | Half duplex or negotiation mismatch | ## Diagnosis Flow ### CRCs Or Input Errors 1. Confirm counters are incrementing, not just historical. 2. Check both ends of the link. Receive-side errors usually point to the signal arriving on that side, not necessarily the port reporting the error. 3. Replace patch cable or clean/replace fiber and optics. 4. Confirm speed/duplex settings match on both sides. 5. Check logs for flap events around the same timestamp. ### Drops 1. Separate input drops from output drops. 2. Compare interface rate against capacity. 3. Check QoS policy, queue counters, and whether the link is an oversubscribed uplink. 4. Treat queue tuning as secondary. First prove whether the link is congested. ### Duplex And Speed Prefer auto-negotiation on modern Ethernet links when both sides support it. If one side must be fixed, configure both sides explicitly and document why. Never mix fixed speed/duplex on one side with auto on the other. ```text show interfaces <interface> | include duplex|speed ``` ## Safe Parser Example Slice each interface block from one header to the next. Do not use an arbitrary character window; large interface blocks can cause counters to be missed or assigned to the wrong port. ```python import re from typing import Any HEADER_RE = re.compile( r"^(?P<name>\S+) is (?P<status>(?:administratively )?down|up), " r"line protocol is (?P<protocol>up|down)", re.I | re.M, ) ERROR_RE = re.compile(r"(?P<input>\d+) input errors, (?P<crc>\d+) CRC", re.I) DROP_RE = re.compile(r"(?P<output>\d+) output errors", re.I) DUPLEX_RE = re.compile(r"(?P<duplex>Full|Half|Auto)-duplex,\s+(?P<speed>[^,]+)", re.I) def parse_show_interfaces(raw: str) -> list[dict[str, Any]]: headers = list(HEADER_RE.finditer(raw)) interfaces = [] for index, header in enumerate(headers): end = headers[index + 1].start() if index + 1 < len(headers) else len(raw) block = raw[header.start():end] errors = ERROR_RE.search(bl