/skill

Network Interface Health

Credit

This skill is based on the original community work. Keep this credit when you share or change it.

Use this skill when a network problem may come from a port, cable, fiber, optic, network card, busy link, or wrong link setting.

Main rule

A counter total may be old. Check if it is still going up.

1. Record the time and counter values.
2. Wait during normal traffic.
3. Read the same counters again.
4. Find the change between the two checks.
5. Compare both ends of the link.

Do not clear counters before you save the first values.

Gather data

On a switch or router, use the matching commands for that device:

show interfaces <interface>
show interfaces <interface> status
show logging | include <interface>|changed state|line protocol

On Linux:

ip -s link show <interface>
ethtool <interface>
ethtool -S <interface>

Also record:

• Device name
• Interface name
• Time
• Link state
• Speed and duplex
• Traffic rate
• Error and drop counters
• Recent link logs
• The port at the other end

Use the same time span on both ends.

Read the counters

Counter names differ by device and driver. Do not treat a missing counter as zero. Mark it as unknown.

Diagnose CRC and input errors

1. Prove that the counter is rising.
2. Check both ends of the link.
3. Match the error time with link flap logs.
4. Check speed and duplex on both ends.
5. Check optic power levels if the device shows them.
6. Clean fiber ends before replacing fiber parts.
7. Replace one part at a time. Start with the patch cable.
8. Measure again after each change.

Receive errors often point to the signal arriving at that port. The fault may be in the cable, the sending port, or either optic.

Diagnose drops

1. Split input drops from output drops.
2. Compare the traffic rate with link speed.
3. Check queue and QoS counters.
4. Check for short traffic bursts. A low average rate can hide a full queue.
5. Check CPU load if packets pass through the device CPU.
6. Check if the link carries traffic from many smaller links.
7. Prove congestion before changing queue sizes.

A cable fault often causes CRC or frame errors. It does not often cause only output drops.

Check speed and duplex

Prefer auto negotiation when both ends support it.

If one end must use fixed speed or duplex, set both ends to the same values. Write down why the fixed setting is needed.

Do not use fixed speed or duplex on one end and auto settings on the other.

show interfaces <interface> | include duplex|speed

For fiber links, also check that both optics support the same speed, fiber type, and light range.

Handle special cases

• A counter may reset after a reboot, driver reload, port reset, or manual clear. Start a new baseline.
• A small counter may wrap back to zero on an old device. Check device uptime and counter size.
• An admin-down port is not a link fault unless it should be up.
• A port channel can hide one bad member. Check each member port.
• A virtual interface has no cable. Check its parent port, bridge, bond, or host path.
• A bond or team may move traffic to another member. Check every member and recent failover logs.
• Linux driver counter names are not standard. Read the driver notes when a name is unclear.
• Some switch counters count normal events in special link modes. Check the vendor meaning before calling them faults.
• A busy SPAN or mirror port may drop copied packets without harming live traffic.
• Errors from a test tool may come from the test host. Check the host port and CPU too.
• Do not compare raw totals from ports with different uptime.

Parse command output safely

Split the text from one interface header to the next. Do not use a fixed number of characters. Long blocks can cause a counter to be missed or assigned to the wrong port.

Keep missing values as None. A missing value is not the same as zero.

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,\s+(?P<crc>\d+) CRC",
    re.I,
)
OUTPUT_ERROR_RE = re.compile(r"(?P<output>\d+) output errors", re.I)
OUTPUT_DROP_RE = re.compile(r"(?P<drops>\d+) output drops", 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(block)
        output_errors = OUTPUT_ERROR_RE.search(block)
        output_drops = OUTPUT_DROP_RE.search(block)
        duplex = DUPLEX_RE.search(block)

        interfaces.append({
            "name": header.group("name"),
            "status": header.group("status"),
            "protocol": header.group("protocol"),
            "duplex": duplex.group("duplex") if duplex else None,
            "speed": duplex.group("speed").strip() if duplex else None,
            "input_errors": int(errors.group("input")) if errors else None,
            "crc_errors": int(errors.group("crc")) if errors else None,
            "output_errors": (
                int(output_errors.group("output"))
                if output_errors else None
            ),
            "output_drops": (
                int(output_drops.group("drops"))
                if output_drops else None
            ),
        })

    return interfaces

Test the parser with:

• One interface
• Many interfaces
• A very long interface block
• Missing counters
• Admin-down ports
• Different letter case
• The last interface in the text

Concrete example

A user says:

Users lose access through switch port Gi1/0/12 for a few seconds each hour.

Use this flow:

1. At 10:00, record 120 CRC and 3 link changes.
2. Check the port at the other end.
3. Wait 10 minutes while traffic is active.
4. At 10:10, record 168 CRC and 4 link changes.
5. Note that CRC rose by 48 and the link changed once.
6. Check logs near the link change time.
7. Confirm that speed and duplex match on both ends.
8. Replace the patch cable.
9. Start a new baseline.
10. Check again after 10 minutes.

If CRC no longer rises, the cable was the likely cause. If it still rises, test the optics, fiber, network card, and ports one at a time.

Slow internet with a healthy LAN

1. Check WAN errors and drops.
2. Check LAN uplink use and output drops.
3. Check for short bursts, not just average use.
4. Check gateway CPU load.
5. Compare wired and wireless tests.
6. Check the service provider only after the local path is clean.

Avoid these mistakes

• Clearing counters before saving a baseline
• Checking only one end of the link
• Treating an old total as a live fault
• Treating a missing counter as zero
• Mixing fixed and auto speed or duplex
• Blaming a cable for output drops before checking congestion
• Changing many parts at once
• Ignoring port channel members
• Comparing counters from different time spans
• Changing routing or firewall rules before checking clear link faults

Related skills

• Agent: network-troubleshooter
• Skill: network-config-validation
• Skill: homelab-network-setup