Two Gigabytes in Four Hours
Users at a branch office report that copying a 2 GB file to the data-center file server takes about four hours. The same file from a different branch takes six minutes. Ping from a branch PC to the server shows 0% loss and 22 ms average round trip. The branch uplink is 1 Gbps fiber. The branch access-switch port facing the router reports 1 Gbps full duplex. The router interface facing the switch reports 100 Mbps half duplex, with auto-negotiation enabled on both ends. Router counters show climbing late collisions, FCS/CRC errors, and runts; the switch port shows no FCS errors and no collisions. Throughput between two PCs on the same branch switch is normal at about 940 Mbps.
1. Diagnose the problem and explain why each measurement looks the way it does.
Read the worked answer
This is a duplex mismatch: one side is full duplex and the other half duplex at different speeds.
Why each reading fits:
- Ping is clean. ICMP echo packets are tiny and the load is trivial, so they rarely collide. Loss-based testing does not exercise the link the way bulk transfer does. This is the trap in the ticket - "ping is fine" is being read as "the link is fine."
- RTT of 22 ms is normal for the distance; latency is not the issue. Four hours for 2 GB is roughly 1.1 Mbps effective throughput, which is a corruption/retransmission problem, not a slow path.
- Counters. The half-duplex router transmits whenever it likes and expects CSMA/CD; the full-duplex switch transmits at the same time, so the router sees late collisions (collisions detected after the 64-byte slot) and truncated frames - runts. The switch never detects a collision because it is full duplex; it just receives frames the router mangled. Corrupted frames arriving from the router register as FCS/CRC errors on the router's own counters for transmitted-then-collided frames.
- Why no errors on the switch port? The switch's transmit direction reaches the router cleanly; the damage is on the router's transmit direction.
- Local throughput is fine because the fault is on the uplink, not in the switch fabric or the branch LAN.
The speed mismatch (1 Gb vs 100 Mb) and the duplex mismatch usually share one cause: the two ends failed to negotiate, so they fell back inconsistently.
2. Explain the likely mechanism that produced 100/half on one end and 1 Gbps/full on the other, and why forcing settings on one side only makes it worse.
Read the worked answer
How it happens. Autonegotiation is a two-way exchange of capabilities over the link. If the negotiation never completes - a media converter or SFP that does not pass FLP (fast link pulse) information, a bad pair, or a port that has been hard-set - each side falls back on its own defaults. On copper, that typically yields 100 Mbps half duplex on one end while the other end, still trying, settles on whatever it can. In a fiber or media-converter path the usual culprit is a cheap converter that regenerates the optical link but does not carry the negotiation, so the switch reports gigabit while the router side drops to 100/half.
Why forcing one side is worse. If you hard-set one end to 100/full and leave the other on auto, the auto side sees no negotiation and defaults to half duplex. You have manufactured the exact mismatch you were trying to fix. The rule for copper is: leave both ends on auto, or hard-set both ends identically (speed and duplex). Never mixed.
Where to look first here: the 1 Gb fiber uplink means there is almost certainly a media converter or SFP in the path. That component, not the router config, is the prime suspect - and it also explains why the branch works at all while performing nine times slower than expected.
3. Give the remediation plan and the verification steps that would prove the fix rather than assume it.
Read the worked answer
Remediation
- Identify and document every element in the uplink path - switch port, patch, converter/SFP, router interface - and record current speed/duplex on each.
- Set both ends to auto where the media supports it. If a converter is preventing negotiation, replace it with one that passes negotiation (or with a direct fiber SFP), rather than papering over it with a hard-set on one end.
- If a hard-set is unavoidable, set both ends to the same speed and duplex, and note it in the configuration documentation so the next engineer does not revert one side to auto.
- Clear the interface counters immediately before and after the change.
Verification - all four, not just the first
- Counters: late collisions, FCS/CRC, and runts stop incrementing over a sustained period, checked on both devices. Old counters stay high forever, so clearing is mandatory.
- Speed and duplex: both sides report 1 Gbps full duplex (or the intended fixed values).
- Real workload: a timed copy of the actual 2 GB file, not a synthetic ping or a small transfer. Expect minutes, not hours; roughly 6 minutes matches the peer branch.
- Sustained load: a short iperf-style test between the branch and the data center to confirm throughput holds under load, since the fault only appeared under bulk transfer.
Prevention: poll CRC and late-collision counters on uplink ports as a monitoring alert. Interface errors are one of the few leading indicators that show up long before users open a ticket.