A 100 Mb/s link that only works when forced to 10 Mb/s
A branch office in a rented building has 12 desks served by a 24-port unmanaged 10/100 switch. The run to the accounts desk is roughly 85 m of Cat5e pulled through a shared conduit and terminated on a keystone jack at one end and a patch panel at the other. The installer cannot say whether T568A or T568B was used at each end. The user reports that large file copies stall and that the port shows a steadily rising CRC and alignment error count at 100 Mb/s; when the technician forces the NIC to 10 Mb/s half duplex the link is stable but slow. Swapping the patch cords and moving to a spare switch port changes nothing. The landlord will not allow new conduit and the existing conduit is full, but a second, unterminated Cat5e cable was pulled at installation time and is still available. The office works 09:00-18:00 and carries VoIP calls on the same switch, so stable latency matters. Budget covers re-termination and certification, or a pair of media converters, or a 5 GHz wireless bridge.
1. Explain why the link is stable at 10 Mb/s yet fails at 100 Mb/s, and say whether the unknown T568A/T568B termination is the probable cause.
Read the worked answer
Signalling difference. 10BASE-T and 100BASE-TX both use only pairs 1-2 and 3-6, so a fault on pairs 4-5 or 7-8 cannot explain this symptom (that trap belongs to 1000BASE-T, which needs all four pairs). The real difference is spectral: 10BASE-T runs Manchester coding at 10 Mbaud, while 100BASE-TX runs 4B/5B at 125 Mbaud over MLT-3. A defect that spoils high-frequency behaviour - excessive untwisting at a jack, a split pair, a crushed or kinked section, a staple through the jacket, moisture ingress - leaves the low-speed signal perfectly readable but destroys near-end crosstalk and return loss at 100 Mb/s. The PHY then either fails to train or trains and produces CRC and alignment errors, exactly what is seen.
Is the A/B mix the cause? Unlikely. A genuine A-at-one-end, B-at-the-other cable is a crossover; modern switch ports and NICs implement auto-MDIX, so it links and runs at 100 Mb/s. The mix must still be corrected, but it is a red herring here. Two further checks support the HF-fault theory: forcing 10 Mb/s half duplex removes the symptom, and changing patch cords or switch ports does not, which places the defect in the permanent link rather than the patch area.
2. Give an ordered diagnostic plan with the reading you expect at each step, and say how you would use the result to choose between re-termination and using the spare cable.
Read the worked answer
- Read the port counters first. Record CRC, alignment, and FCS errors on the switch port and the NIC. Growth only at 100 Mb/s confirms a link-integrity problem, not an application or duplex problem.
- Substitute known-good patch cords at both ends. No change expected, which isolates the permanent link.
- Run a certifier in permanent-link mode from both ends, not a simple continuity tester. Expect one of: wiremap pass with a split-pair warning (pairs correctly pinned but the signal and return are on different twists), a NEXT or return-loss fail, or a length over 90 m.
- Inspect the terminations. Look for more than 13 mm of untwisted conductor at the jack and at the patch panel, nicked conductors from the punch-down tool, and a jack punched to a different standard than the panel.
- Use TDR distance-to-fault. If the fault reports within about 2 m of an end, re-termination is the fix. If it reports mid-span, the cable is damaged and no amount of re-termination will recover 100 Mb/s.
Decision rule. End-localised fault plus a clean wiremap after re-termination: keep the existing run. Mid-span fault, or a re-terminated run that still fails NEXT/return loss: abandon the run and terminate the spare cable that is already in the conduit, which needs no landlord consent and no new conduit work.
3. Compare re-termination, a media converter pair, and a 5 GHz wireless bridge for this desk, and state the acceptance evidence you would record.
Read the worked answer
Re-termination plus certification is the first action because it is the cheapest and it is the only option that fixes the actual defect. It also restores full-duplex 100 Mb/s, which matters for a desk running VoIP alongside file copies.
Media converters do not help. They still drive the same copper pair with the same high-frequency impairment; the conversion adds a latency hop, a second power point, and another failure item. They would only be rational if the medium changed, for example to fibre over the spare duct, which is not available here.
A 5 GHz bridge is a shared, unlicensed, half-duplex medium. It adds milliseconds of latency with jitter, is exposed to interference and fade, and gives one desk a link with different failure modes from the rest of the floor. It is acceptable only as a documented temporary measure, never as the permanent VoIP path.
Acceptance evidence to file:
- A permanent-link certification report per TIA-568 (wiremap, length, insertion loss, NEXT, return loss) showing PASS, with the tester's calibration date.
- Zero new CRC/alignment errors on the port over a 24-hour soak while the desk does a large file copy and takes calls.
- Duplex and speed confirmed as auto-negotiated 100 Mb/s full duplex at both ends, with no late collisions.