A structured lesson workspace with readable content, hands-on examples, and a clean path to completion.
Duplex mismatch is the single most common cause of "the network is slow" in switched networks, and it's almost always caused by someone hardcoding speed on one side of a link and leaving the other on auto. Ten seconds of config checking fixes it — but only if you know what to look for.
Half-duplex means a device either transmits or receives, not both at once. It's how shared media works — one speaker at a time. Full-duplex means transmit and receive happen simultaneously on separate wire pairs. Every modern switched link should be full-duplex.
| Mode | Uses CSMA/CD | Throughput | When it's correct |
|---|---|---|---|
| Half-duplex 100 Mbps | Yes | Up to 100 Mbps (shared) | Only on a hub or ancient gear |
| Full-duplex 100 Mbps | No | 100 Mbps each direction | Switch to device, switch to switch |
| Full-duplex 1 Gbps | No | 1 Gbps each direction | Modern access layer |
| Half-duplex 1 Gbps | Not defined | N/A | Does not exist — Gigabit is always full |
Gigabit Ethernet is defined as full-duplex only. If you see a 1 Gbps link trying to run half-duplex, something is very wrong — usually a hardcoded switch side forcing a mismatch or a bad SFP.
Auto-negotiation works by exchanging a burst of Fast Link Pulses (FLP) during link-up. Each side advertises what it supports — 10/100/1000, half/full — and both sides pick the highest common set. If both ends are auto, this works perfectly.
The failure mode is one-end-auto, one-end-hardcoded. The hardcoded side transmits no FLPs. The auto side sees no advertisement, falls back to parallel detection — it can figure out the speed but not the duplex. On 10/100 links, the fallback duplex is half. So the hardcoded side runs full, the auto side runs half, and both sides think everything is fine.
This is why the classic advice exists: hardcode both ends or leave both on auto. Never one. If you must hardcode speed for a legacy device, hardcode duplex too.
The interface counters tell the story. On the half-duplex side you'll see late collisions and FCS/CRC errors climbing steadily. On the full-duplex side you'll usually see runts — short, malformed frames caused by the half-duplex end cutting off transmissions mid-frame.
That `3 late collision` is a smoking gun. Late collisions happen when a frame is transmitted 512 bit-times after the start of transmission and another host's signal arrives — meaning somebody is transmitting on a wire they thought was idle. On a full-duplex port, a late collision should never occur. If you see late collisions on a port configured `full-duplex`, the far end is running half.
If Gi0/2 shows late collisions, log into the peer device and check its interface. Nine times out of ten, that side is running half-duplex, and the config shows `speed 100` without a matching `duplex full` — or vice versa. Fix it by matching the config on both sides, or by setting both back to auto.
A file server connected to switch port Gi0/18 is transferring files at ~8 MB/s while every other server does ~100 MB/s on the same switch. Users complain. `show interfaces Gi0/18` shows `full-duplex, 100Mb/s` with growing late collision counters.
Select the safest next action.
Get in the habit of leaving both sides on auto. When you can't — legacy device or contractual requirement — hardcode both speed AND duplex on both ends. It's a two-second discipline that saves hours of debugging later.
Walk through the interfaces on any switch you can access. Check duplex and counters on every port. You'll be surprised how many production switches have a late-collision counter quietly ticking up on one port nobody's complained about yet.
Finish the lesson once you have worked through the material. This awards ★ 45 XP.