agentleFS
arsalllsarsallls/claude-network-skills/skills/network-interface-health/SKILL.md

network-interface-health

Skill70 starsChanged 7 months agoMITView on GitHub

Diagnosing network interface errors including CRC errors, input/output drops, runts, giants, duplex mismatches, flapping, and speed negotiation failures on Cisco IOS/IOS-XE devices.

We split this skill into the rules it gives an agent

3 rules. 0 are common, 1 is distinctive, and 2 are very specific to this project.

  • 0

    Common

    Most of the 5 edited versions we read keep these.

  • 1

    Distinctive

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Always check both ends of a link — errors are received, not transmitted

    line 237
  2. Very specific:

    Use show interfaces | include error|reset|drop for a quick system-wide health check

    line 239
  3. Very specific:

    Use no keepalive when connecting IOS to devices that don't support keepalives (some firewalls, servers)

    line 242

“Common” is measured: kept by at least 6 in 10 of the 5 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Network Interface Health

Patterns for reading interface counters, identifying error types, and diagnosing the root cause of interface problems. Interface health is the first check in almost every network troubleshooting session.

When to Activate

  • Investigating packet loss or high latency on a specific link
  • Diagnosing CRC errors, input drops, or output drops on an interface
  • Troubleshooting duplex mismatches or speed negotiation issues
  • Investigating an interface that is flapping (going up and down)
  • Reviewing interface health after a cable replacement or hardware change
  • Building automation to monitor interface error counters at scale

Reading show interfaces Output

GigabitEthernet0/0 is up, line protocol is up
  Hardware is iGbE, address is aabb.cc00.0100
  Description: UPLINK-TO-CORE
  Internet address is 10.0.0.1/30
  MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA, loopback not set
  Full-duplex, 1000Mb/s, media type is T
  ...
  5 minute input rate 1234000 bits/sec, 890 packets/sec
  5 minute output rate 987000 bits/sec, 720 packets/sec
     1234567 packets input, 987654321 bytes, 0 no buffer
     Received 45 broadcasts (0 IP multicasts)
     0 runts, 0 giants, 0 throttles
     12 input errors, 12 CRC, 0 frame, 0 overrun, 0 ignored
     0 watchdog, 0 multicast, 0 pause input
     1098765 packets output, 876543210 bytes, 0 underruns
     0 output errors, 0 collisions, 2 interface resets
     0 unknown protocol drops
     0 babbles, 0 late collision, 0 deferred
     0 lost carrier, 0 no carrier, 0 pause output
     0 output buffer failures, 0 output buffers swapped out

Counter Reference

CounterWhat it meansCommon cause
CRCFrames received with checksum mismatchBad cable, duplex mismatch, failing NIC/SFP
input errorsSum of all input error typesSee sub-counters
runtsFrames shorter than 64 bytesDuplex mismatch, collisions
giantsFrames larger than MTUJumbo frames with no jumbo support, misconfigured MTU
input drops (no buffer)Frames dropped — RX buffer fullInterface oversubscription, inbound traffic burst
output dropsFrames dropped in TX queueEgress congestion, QoS tail drop
interface resetsInterface hardware resetFlapping, keepalive failure, driver issue
collisionsLate/excessive collisionsHalf-duplex operation or duplex mismatch
throttlesInput rate throttled by IOSSevere inbound oversubscription

Diagnosing Specific Issues

CRC Errors

CRC errors almost always mean a physical layer problem.

# Confirm CRC errors are incrementing (run twice, compare)
show interfaces GigabitEthernet0/0 | include CRC|input errors

# Steps:
# 1. Check cable — replace with a known-good cable
# 2. Check duplex and speed settings (mismatch is the most common cause)
show interfaces GigabitEthernet0/0 | include duplex|speed

# 3. Check SFP or transceiver
show interfaces GigabitEthernet0/0 transceiver

# 4. Check the connected switch/device's interface for counters too
# CRC errors are almost always on the receiving side of the bad signal

Duplex Mismatch

The most common cause of CRC errors, collisions, and degraded throughput.

# Symptom: CRC errors on both ends, poor throughput, collisions
show interfaces Gi0/0 | include duplex|speed|collision

# Fix: Set explicit duplex and speed on both ends (never leave one as auto and one as fixed)
interface GigabitEthernet0/0
  duplex full
  speed 1000

# OR leave both ends as auto-negotiate (acceptable when both sides support it)
interface GigabitEthernet0/0
  duplex auto
  speed auto
  no shutdown

Input Drops (Buffer Overrun)

# Symptom: 'no buffer' or high input drop counter
show interfaces GigabitEthernet0/0 | include drops|throttle|buffer

# Cause: inbound traffic rate exceeds what IOS can process
# Options:
# 1. Check for traffic bursts — high input rate at time of drops
show interfaces GigabitEthernet0/0 | include input rate

# 2. Increase input hold queue (IOS default: 75 packets)
interface GigabitEthernet0/0
  hold-queue 300 in

# 3. Consider hardware upgrade if sustained oversubscription

Output Drops (Egress Congestion)

# Symptom: output drops incrementing under load
show interfaces GigabitEthernet0/0 | include output drops|queue

# Cause: egress interface is congested — packets arrive faster than they leave
# Options:
# 1. Enable QoS to prioritize critical traffic
# 2. Increase tx-ring-limit (hardware queue depth)
interface GigabitEthernet0/0
  tx-ring-limit 128

# 3. Check for asymmetric routing sending too much traffic to one interface

Interface Flapping

# Check syslog for flap events
show logging | include GigabitEthernet0/0|changed state

# Check uptime counter — low value = recently flapped
show interfaces GigabitEthernet0/0 | include line protocol|reset

# Common causes:
# - Faulty cable or SFP
# - Keepalive mismatch (disable keepalives if connecting to non-IOS devices)
#   interface GigabitEthernet0/0
#     no keepalive
# - Speed/duplex negotiation failure
# - Power instability on connected device

Python: Polling Interface Counters

import re
from typing import Any

INTF_DETAIL_RE = re.compile(
    r"^(?P<interface>\S+) is (?P<status>(?:administratively )?down|up)"
    r", line protocol is (?P<protocol>up|down)",
    re.IGNORECASE | re.MULTILINE,
)
SPEED_DUPLEX_RE = re.compile(
    r"(?P<duplex>Full|Half|Auto)-duplex.*?(?P<speed>\d+\s*[MG]b(?:ps)?|Auto-speed|unknown)",
    re.IGNORECASE,
)
ERRORS_RE = re.compile(
    r"(?P<in_errors>\d+) input errors.*?(?P<crcs>\d+) CRC",
    re.IGNORECASE | re.DOTALL,
)

def parse_interface_health(raw: str) -> list[dict[str, Any]]:
    matches = list(INTF_DETAIL_RE.finditer(raw))
    results = []
    for i, m in enumerate(matches):
        name = m.group("interface")
        entry: dict[str, Any] = {
            "interface": name,
            "status": m.group("status"),
            "protocol": m.group("protocol"),
            "duplex": "unknown",
            "speed": "unknown",
            "input_errors": 0,
            "crc_errors": 0,
        }
        # Slice from this interface header to the start of the next one (or end of string)
        # This avoids reading counters from a neighbouring interface block
        end = matches[i + 1].start() if i + 1 < len(matches) else len(raw)
        chunk = raw[m.start():end]
        sd = SPEED_DUPLEX_RE.search(chunk)
        if sd:
            entry["duplex"] = sd.group("duplex")
            entry["speed"] = sd.group("speed")
        err = ERRORS_RE.search(chunk)
        if err:
            entry["input_errors"] = int(err.group("in_errors"))
            entry["crc_errors"] = int(err.group("crcs"))
        results.append(entry)
    return results

def find_unhealthy_interfaces(raw: str, crc_threshold: int = 0) -> list[dict]:
    return [
        i for i in parse_interface_health(raw)
        if i["crc_errors"] > crc_threshold
        or i["status"] != "up"
        or i["protocol"] != "up"
    ]

Anti-Patterns

# BAD: Ignoring incrementing CRC errors — small numbers can indicate a developing fault
# A few CRCs per day will grow into thousands if the root cause isn't addressed

# BAD: Mixing auto-negotiate on one side with fixed speed/duplex on the other
# Fixed end transmits without flow control signals; auto end falls back to half-duplex
interface GigabitEthernet0/0
  duplex full      # fixed
  speed 1000       # fixed
# Partner interface left as auto — will negotiate half-duplex, causing collisions and CRCs

# BAD: Clearing counters without first noting baseline values
# Counters tell you history — clear only when you need a fresh measurement window
clear counters GigabitEthernet0/0   # loses historical data

# BAD: Only checking one side of a link
# CRC errors occur on the receiver. If Gi0/0 shows CRCs, check the transmitter
# on the OTHER end of the cable — the problem is usually there

Best Practices

  • Always check both ends of a link — errors are received, not transmitted
  • Baseline counter values with show interfaces before a change window; compare after
  • Use show interfaces | include error|reset|drop for a quick system-wide health check
  • Explicitly set duplex full and speed 1000 (or appropriate value) on uplinks where you control both ends — on uplinks to ISP or third-party equipment, leave both sides as auto-negotiate
  • Configure SNMP polling on ifInErrors and ifOutDiscards OIDs for automated alerting
  • Use no keepalive when connecting IOS to devices that don't support keepalives (some firewalls, servers)

Related Skills

  • cisco-ios-patterns
  • network-bgp-diagnostics
  • network-config-validation

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

Reviews can't be read right now.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.