Ruankao Network Engineer (Intermediate) study materials
Ruankao Network Engineer (Intermediate) study resources

Gigabit to a Mezzanine Desk Bank Over a 132 m Cat5e Run

Ruankao Network Engineer (Intermediate) · Put your knowledge to work in context.

All case studies

Gigabit to a Mezzanine Desk Bank Over a 132 m Cat5e Run

A logistics company has fitted out a mezzanine office whose cable path is 132 m from the floor distribution frame. The contractor pulled a single Cat5e UTP bundle for 12 desks, and for about 40 m of the run it shares a metal tray with the 380 V feeder of a variable-frequency-driven conveyor. After cutover, the eight desks nearest the tray negotiate 1000BASE-T and then reset repeatedly; the switch ports show rising FCS and alignment errors that spike whenever the conveyor starts. The copper certification report shows a 132 m length and 'PASS' for the permanent link, but the test was performed with the conveyor switched off. Users now run at 100 Mb/s or lose connectivity, and the IP desk phones on the same switch show audible jitter. Management wants gigabit to every desk within six weeks, the conduit is already full, and any spending above a small switch plus optics must be justified in writing.

1. Identify the two independent reasons this link cannot deliver reliable 1 Gb/s, and explain why the 'PASS' certificate does not contradict your diagnosis.

Read the worked answer

Reason 1 - distance. The 1000BASE-T channel limit is 100 m (90 m horizontal + up to 10 m of patch cords). At 132 m the insertion loss, return loss and delay skew are outside the standard, so the link cannot be certified as a compliant channel even if a permanent-link test at that length reports pass. 1000BASE-T uses all four pairs with PAM-5 and echo cancellation, so it degrades earlier than 100BASE-TX, which uses only two pairs - that is exactly why the ports fall back to 100 Mb/s or bounce.

Reason 2 - noise. Running unshielded twisted pair alongside a VFD feeder exposes it to high dv/dt common-mode noise. The switching frequency of the drive produces impulsive coupling that FCS detects as errors; the correlation with conveyor start is the signature.

Why the certificate is not evidence. A permanent-link test excludes the patch cords, so it does not certify the channel the host actually uses. More importantly, it was run with the conveyor off, so the alien-noise environment that causes the failures was absent. A passing test in a quiet condition says nothing about operation under the real disturbance.

Predict the symptom before touching cable: errors appear only under load and only when the drive runs, and the link trains down rather than failing outright. That combination points to margin, not to a hard break.

2. Give your recommended remediation, with at least one rejected alternative and the reasons.

Read the worked answer

Recommendation: fibre to a small mezzanine switch. Pull OM3 (or OM4 for future 10G) from the IDF to an 8- or 12-port switch on the mezzanine, using the existing conduit since a duplex LC fibre is far thinner than a copper bundle. Fibre is immune to the VFD noise and is not distance-limited at 132 m. Costs to justify: two SFP modules, the access switch, a small UPS and local power for the phones - if the phones need PoE, take PoE from the new local switch rather than trying to power them over fibre.

Rejected: shielded Cat6A in the same tray. Even with F/UTP and proper bonding, the run is still 132 m, so it fails the channel length rule no matter how good the shielding is. It would buy noise immunity and still not deliver compliant gigabit.

Rejected: move or add an IDF. Technically the cleanest fix, but it means a new power-fed closet, backbone cabling and building works; the six-week window and the budget make it disproportionate for 12 desks.

Rejected: leave copper at 100 Mb/s for the phones and fibre only the PCs. Viable as a stopgap, but it perpetuates a non-compliant copper run in a noisy tray and creates two parallel cabling systems to maintain.

State the acceptance criterion up front: line-rate bidirectional traffic for 24 h with the conveyor cycling, zero CRC/FCS increase on the new ports.

3. What testing and documentation would you require before signing off the new link?

Read the worked answer

Test the thing that failed, not just continuity.

  1. Certify the copper that remains as a channel, with patch cords in place, and record the noise environment - if any copper stays, it is for phones only and should be documented as 100 Mb/s maximum.
  2. Certify the fibre with an OTDR or light-source/power-meter pair at both wavelengths, recording end-to-end loss per strand against the budget; label both ends and record the pair polarity.
  3. Prove the service under load. Run an iperf3 or RFC 2544 style test at line rate in both directions for a sustained period with the conveyor starting and stopping on its normal cycle. Watch interface error counters and output drops before and after; the pass condition is zero incremental CRC/alignment errors.
  4. Prove the latency-sensitive service. Run a concurrent VoIP-quality check (jitter, loss, MOS estimate) on the desk phones during the load test, because the original complaint included jitter.
  5. Document the as-built path, the fibre type and connector, switch port assignments, VLANs for voice and data, the UPS, and the residual risk if any copper remains. Record the acceptance results with timestamps and the person who witnessed them, so the six-week deadline is defended with evidence rather than opinion.