Diagnosing Ethernet Link Problems with Negotiation and Error Counters

Good to see you again. In the previous lesson, you traced how an 802.1Q trunk preserves VLAN context across a shared switch-to-switch link. That logic assumes the Ethernet link itself is healthy. In practice, an interface can show connected while delivering very poor performance because its endpoints disagree about duplex, or because the medium is corrupting frames.

This lesson develops a disciplined way to diagnose that class of fault. You will distinguish a physical link failure from a speed/duplex problem, understand what auto-negotiation actually agrees on, and use interface-counter changes over time as evidence rather than treating any single nonzero counter as a diagnosis. This is especially useful at architectural scale: a link fault should be localized and corrected without accidentally masking a systemic cabling, transceiver, or configuration-standard problem.

---

Start with the link state, but do not stop there

An Ethernet interface reports both a physical condition and a link-layer condition. On Cisco IOS-style platforms, the beginning of show interfaces commonly has this form:

GigabitEthernet1/0/24 is up, line protocol is up

The first state, up, means the physical interface detects a usable electrical or optical signal. The second, line protocol is up, indicates that the interface is operational at Layer 2.

This is a valuable first classification, but it is not a health guarantee.

Observed state	Initial interpretation	First checks
up/up	Physical signal and Layer 2 are operational.	Check negotiated speed/duplex, errors, drops, and traffic behavior.
down/down	No usable physical link.	Cable or fiber path, optics, remote port state, supported speed, power.
administratively down/down	The local interface was disabled by configuration.	Local configuration and change history.
err-disabled or similar	The platform disabled the port after detecting a condition or policy violation.	Logs and the specific err-disable reason; do not assume a cable failure.

A link can be up/up with substantial frame loss. This is the classic signature of a duplex mismatch: the endpoints establish electrical connectivity and may even pass light traffic, while sustained bidirectional traffic performs badly.

For a switch-to-switch or switch-to-firewall link, always collect evidence from both endpoints. The near end alone gives you only one perspective of the same wire.

---

Duplex and speed: the operating contract of an Ethernet link

Speed is the signaling rate, such as 10 Mb/s, 100 Mb/s, or 1 Gb/s. Duplex defines whether an endpoint may transmit while receiving:

• Half duplex permits one direction of transmission at a time. It uses carrier sensing and collision handling.
• Full duplex permits simultaneous sending and receiving. Collisions are not a normal part of its operation.

Half duplex still matters when dealing with older Fast Ethernet equipment, legacy industrial devices, or an incorrectly configured endpoint. On modern switched Gigabit Ethernet and faster links, full duplex is the normal expectation; many interfaces do not support half duplex at gigabit speeds at all.

The desired configuration policy is simple:

1. Use auto-negotiation on both ends whenever both endpoints support it properly.
2. If auto-negotiation genuinely cannot be used, hardcode the same speed and duplex on both ends.
3. Do not hardcode one end while leaving the other end on auto unless you have platform-specific evidence that the resulting behavior is correct and intended.

The third case is dangerous because the auto-negotiating endpoint may identify the speed but not learn the remote endpoint’s duplex choice.

What auto-negotiation does

At link initialization, compatible endpoints advertise their capabilities: supported speeds and duplex modes. They select the best mutually supported combination, typically the highest common speed at full duplex. On 10/100 Ethernet, this capability exchange uses Fast Link Pulses rather than ordinary Ethernet data frames.

If both endpoints advertise normally, the outcome is unambiguous:

Endpoint A capabilities: 10/100, half/full
Endpoint B capabilities: 10/100, half/full

Operational result: 100 Mb/s, full duplex

On many Cisco platforms, show interfaces status displays an a- prefix when a value was selected through auto-negotiation:

Port       Status       Duplex   Speed
Gi1/0/24   connected    a-full   a-1000

Here, a-full and a-1000 describe the operational result and indicate it was negotiated. Output conventions vary by vendor and platform, so verify the running configuration as well as the status output.

The hazardous mixed case

Consider a Fast Ethernet link:

Endpoint	Configuration	Actual behavior
Switch port	Auto speed and auto duplex	Detects the remote 100 Mb/s signal, but cannot negotiate duplex
Legacy device	Forced 100 Mb/s full duplex	Sends and receives simultaneously

The auto-negotiating switch can use parallel detection to infer the speed: 100 Mb/s. But for 10/100 Ethernet, it may default to half duplex when the peer did not participate in negotiation. The resulting state is:

Endpoint	Operational speed	Operational duplex
Switch	100 Mb/s	Half
Remote device	100 Mb/s	Full

The link can remain physically up. The fault appears under traffic because the half-duplex side follows collision rules while the full-duplex side transmits whenever it has traffic to send.

A forced speed mismatch, in contrast, is more likely to prevent the link from establishing at all. For example, one side forced to 100 Mb/s and the other forced to 1 Gb/s normally presents as down/down, not as an apparently functional but slow link.

---

Read counters as a pattern, not as isolated numbers

Ethernet includes an FCS, the Frame Check Sequence, at the end of every on-wire frame. The sender calculates it over the frame; the receiver calculates its own value and compares the results. A mismatch means the received bits differ from the transmitted bits.

Platforms label related conditions differently, but you will commonly encounter CRC, FCS, alignment, runt, and collision counters. A key operational rule is:

A nonzero historical counter is not necessarily an active fault. An increasing counter during a measured interval is evidence.

Take a baseline from each end, generate or observe normal traffic for several minutes, then collect the counters again. For an error type $E$, its interval rate can be expressed as:

$$\text{error rate}=\frac{\Delta E}{\Delta \text{received frames}}$$

The exact tolerances depend on the medium, platform, and traffic volume, but a rising CRC or late-collision count is operationally meaningful even if the percentage appears small. It represents frames that had to be discarded, retransmitted by an upper-layer protocol, or never delivered.

Counter patterns worth recognizing

Counter or condition	What it means	Frequent interpretations
CRC or FCS errors	The received frame’s integrity check failed.	Cable damage, electrical noise, bad NIC or port, optic/media issue, duplex mismatch.
Alignment or frame errors	A malformed frame also has an invalid CRC.	Duplex mismatch or a physical-medium problem.
Runts or fragments	Received frames below the Ethernet minimum size, often with bad CRC.	Duplex mismatch, collisions, cable or interface issue.
Late collisions	A collision was detected later than the valid collision window.	Strong duplex-mismatch indicator on the half-duplex side; also investigate an abnormal legacy segment.
Collisions, excessive collisions, deferred frames	Half-duplex contention behavior.	Normal only in an actual half-duplex environment; suspicious on a network expected to be full duplex.
Link flaps, lost carrier, no carrier	The signal is unstable or absent during operation.	Cable, connector, patch panel, optic, port, remote device, or media-converter problem.
Output drops or queue discards	The device could not queue traffic for transmission.	Congestion or oversubscription, not automatically a Layer 1 fault.

Counters need context. CRC/FCS errors do not prove a duplex mismatch. A damaged copper pair, poor termination, failing transceiver, contaminated fiber connector, or bad endpoint NIC can produce the same symptom. The important distinction is the pattern across both ends.

A classic duplex mismatch often looks like this:

Full-duplex endpoint	Half-duplex endpoint
Rising FCS/CRC, runts, or input errors	Rising late collisions, collisions, or excessive collisions
No legitimate collision behavior expected	Collision logic actively treats simultaneous transmit and receive as a conflict
Severe throughput loss despite an up/up link	Retries and backoff behavior reduce usable throughput

Platform counter implementation differs, so do not expect every device to display this exact split. Instead, look for asymmetric evidence that one side behaves as full duplex while the other behaves as half duplex.

The alert illustrates the most direct case: both ends are manually configured, but their duplex modes differ. The correction is not merely “clear the CRC alert.” It is to make the endpoint configurations consistent, then verify that new errors stop accumulating.

---

A repeatable incident workflow

Use this workflow for an access, inter-switch, firewall, load-balancer, or appliance Ethernet link. The command examples use Cisco IOS-style syntax; map them to your platform’s equivalent operational commands.

1. Define the affected link and establish impact

Confirm the two physical endpoints, interfaces, media type, intermediate patch panels, and connected service. Determine whether the link is:

• Completely down
• Flapping
• Up but slow or lossy
• Erroring only under load
• Carrying a reduced negotiated speed

Avoid changing speed or duplex while you are still collecting initial evidence, especially on an uplink. A configuration change resets the link and can erase the behavior you need to understand.

2. Collect a baseline from both ends

Typical commands include:

show interfaces GigabitEthernet1/0/24
show interfaces GigabitEthernet1/0/24 status
show interfaces GigabitEthernet1/0/24 counters errors
show running-config interface GigabitEthernet1/0/24
show logging | include DUPLEX|LINK|Gi1/0/24
show cdp neighbors interface GigabitEthernet1/0/24 detail

Capture these facts on both devices:

• Administrative state and operational state
• Current speed and duplex
• Whether speed and duplex were negotiated or forced
• Input and output packet counts
• CRC/FCS, alignment, runt, collision, late-collision, and carrier counters
• Link-transition logs
• Neighbor information, where a discovery protocol is available

CDP may issue a duplex-mismatch warning between Cisco neighbors. Treat it as useful corroborating evidence, not as the source of truth: CDP is a proprietary discovery protocol and does not participate in IEEE auto-negotiation.

3. Compare configuration with operational reality

A current operational value of 100 Mb/s full duplex does not itself tell you that both endpoints were configured correctly. You need both the running configuration and the status display.

For example:

Switch-A: configured auto, operational a-100
Switch-B: configured 100/full, operational 100/full

This is a configuration asymmetry. At 10/100 Ethernet, it may create the exact parallel-detection condition that causes the auto side to choose half duplex. Even if it happens to work on a particular PHY implementation, it is an avoidable operational risk.

If a manual configuration is required, document it and enforce the same exact configuration on both sides:

Endpoint A: speed 100, duplex full
Endpoint B: speed 100, duplex full

Otherwise, return both endpoints to their platform’s normal auto-negotiation configuration.

4. Use counter direction to narrow the fault domain

After recording the baseline, wait during representative traffic or generate an approved test flow. Then compare deltas.

• Late collisions on one end plus FCS/runts on the peer strongly suggests duplex mismatch.
• CRC/FCS increases on one or both ends with no collision evidence points more strongly toward the cable, connector, optic, port, or attached NIC.
• Carrier loss, link flaps, or unstable link state raises the priority of physical-path checks.
• Output drops without CRC, FCS, or collision symptoms usually points toward congestion or queue pressure instead of a damaged Ethernet medium.

A packet capture can show retransmissions or application effects, but do not expect it to show every corrupted Ethernet frame. Hardware often discards a bad-FCS frame before it reaches the capture point. Interface counters are therefore primary evidence for this specific problem.

5. Isolate physical components methodically

For copper, inspect and test the entire path, not just the patch lead visible at the switch:

• Replace the patch cable with a known-good cable.
• Reseat connectors.
• Bypass a suspect patch panel or media converter where operationally safe.
• Move the connection to known-good ports if the design permits.
• Check whether the fault follows the cable, the endpoint, or the switch port.

For fiber, validate that both sides use compatible optics and fiber types, that transmit and receive are crossed correctly, and that the selected optics support the actual distance. A link light can coexist with marginal signal quality; persistent errors and flaps matter more than the LED alone.

6. Correct, validate, and preserve the evidence

Once you correct the configuration or replace a physical component:

1. Record the repaired state on both ends.
2. Allow representative traffic to flow.
3. Confirm that new CRC/FCS, collision, and link-flap counters remain stable.
4. Confirm expected throughput and application behavior.
5. Document the root cause, including whether it was a configuration-standard gap, a failed component, or a cabling-path issue.

Prefer before-and-after snapshots over immediately clearing counters in production. Clearing counters may be appropriate in a controlled maintenance window, but the time-stamped delta is usually more valuable for incident evidence.

---

EVE-NG practice: model the diagnosis, not just the configuration

Use an EVE-NG topology with two switch-capable nodes connected by a Fast Ethernet link, plus traffic sources on each side. The goal is to practice the evidence collection sequence.

1. Configure both ends for auto-negotiation and verify a healthy baseline.
2. Collect show interfaces, show interfaces status, and error-counter output from both devices.
3. If your image supports it, configure one endpoint for 100 Mb/s full duplex and the other for 100 Mb/s half duplex.
4. Generate sustained bidirectional traffic, then compare counters at both endpoints.
5. Restore both sides to auto-negotiation, or configure the same forced 100 Mb/s full-duplex setting at both ends.
6. Verify that counter increments stop after the correction.

Virtual switching images do not always emulate PHY behavior, collision handling, or hardware error counters faithfully. If your lab does not produce late collisions or CRC increments, the lab still has value: validate the configuration logic, command workflow, and before-and-after operational state. Do not infer that an EVE-NG image’s behavior exactly matches physical access-switch hardware.

---

Key takeaways

• up/up confirms a functioning physical and Layer 2 state, but does not prove that an Ethernet link is healthy.
• The preferred operational model is auto-negotiation on both endpoints. If negotiation must be disabled, force the same speed and duplex at both ends.
• A forced endpoint paired with an auto-negotiating 10/100 endpoint can create a duplex mismatch because parallel detection can identify speed but may default the auto side to half duplex.
• A duplex mismatch commonly leaves the link up while causing severe performance loss, FCS/CRC errors, runts, and late collisions.
• CRC/FCS errors indicate corrupted received frames, but they can result from duplex mismatch or physical defects such as cabling, connectors, ports, optics, and NICs.
• Diagnose from both ends and compare counter deltas, operational state, configuration, logs, and the physical path.
• Output drops are often congestion evidence, not proof of Ethernet media corruption.

Next, you will consolidate the Ethernet foundations by reconstructing a packet’s encapsulation and de-encapsulation as it crosses switched and routed boundaries.