Short answer: if a 25G, 28G, or 100G DAC cable seats fine, shows the module as present, and still won't link up, flaps continuously, or falls back to a lower speed, the cause is almost always a Forward Error Correction (FEC) mismatch, not a bad cable. Above 10G, FEC is required to keep the link stable, and every switch and NIC vendor defaults to a different FEC mode. When the two ends of the link don't agree, the port simply never comes up.
This has become one of the most common cross-vendor complaints on networking and homelab forums over the past year, showing up on Cisco, Juniper, Arista, Mikrotik, Ubiquiti, and Fortinet gear alike, almost always with the same symptom: the module is detected, but the port never links.
What FEC Actually Does, and Why 25G+ Needs It
Forward Error Correction adds redundant data to a signal so the receiving end can detect and correct bit errors without asking for a retransmit. At 1G and 10G, copper and optical links normally have enough signal margin that FEC is optional. At 25G and above, the signal margin shrinks enough that FEC moves from optional to effectively mandatory, since IEEE 802.3by defines RS-FEC as the baseline for reliable 25GbE operation over DAC.
The problem is that FEC is not one single setting. Common variants include:
- RS-FEC (Reed-Solomon, Clause 91), the modern standard for 25G, 50G, and 100G lanes
- FC-FEC, or Base-R (Clause 74, Fire-Code), an older, lighter-weight mode still used on some 10G and 40G links
- No FEC at all, sometimes still viable at short DAC lengths, but rarely the default above 10G
The Failure Pattern: Module Detected, Link Never Comes Up
Before assuming a bad cable, check whether your symptoms match this pattern, which is the signature of an FEC mismatch rather than a hardware fault:
- Both ends show the DAC module as physically present and correctly identified
- The port stays in a no-link or down state indefinitely
- The link comes up briefly, then flaps or drops repeatedly
- The link only stabilizes after falling back to a lower negotiated speed
- FEC or CRC error counters climb steadily once the link does come up
Why Vendors Disagree on FEC Defaults
There is no single industry default. Each vendor's switch or NIC firmware picks its own FEC behavior per port speed, which is exactly why a DAC cable can link perfectly between two switches from the same vendor and fail completely between mixed vendors.
- Cisco (Catalyst/Nexus): often forces RS-FEC on 25G/100G ports by default; check "show interface" FEC status and match the far end explicitly rather than relying on autonegotiation alone
- Juniper (EX/QFX): FEC is generally configurable per interface, auto by default; set fec91 or fec-none explicitly on both ends if autonegotiation fails
- Arista: follows IEEE defaults closely and auto-negotiates FEC where supported, usually the most forgiving platform, but still needs manual FEC alignment against non-Arista gear
- Ubiquiti (UDM/USW): 25G SFP28 ports commonly run FEC enabled with limited manual override; third-party 25G DACs without matching FEC support are a frequent no-link cause
- MikroTik (RouterOS/SwOS): FEC behavior varies by RouterOS version and port type and is not always exposed in SwOS; check "interface ethernet monitor" for FEC and status detail
- Fortinet (FortiSwitch): FEC defaults differ across FortiSwitch models even on the same DAC part number; Fortinet's own knowledge base documents identical DAC cables failing to link between different FortiSwitch models over this exact issue
Troubleshooting Framework: Fixing a DAC Link That Won't Come Up
Work through these in order rather than assuming the cable itself is defective:
- Confirm both ends detect the module and cable correctly before touching any speed or FEC settings
- Check the FEC state on each side individually; most platforms expose this in interface or transceiver status commands
- Force both ends to the same FEC mode, typically RS-FEC, for 25G+ rather than leaving both on auto if autonegotiation is not converging
- If forcing FEC on does not help, try forcing it off on both ends; some short passive DACs link reliably with FEC disabled entirely
- Re-check speed negotiation after adjusting FEC, since a stuck FEC negotiation is often mistaken for a speed mismatch
- Watch CRC and FEC-corrected error counters for a few minutes after any change to confirm the link is actually stable, not just up
When to Disable FEC vs. Force It On
- Short passive DAC runs under 1-2 meters at 25G can sometimes run FEC-off reliably; longer runs almost always need FEC on
- If one end is hard-fixed on RS-FEC by firmware, common on Cisco and Ubiquiti, match the other end rather than fighting the fixed side
- Mixed-vendor links should default to matching whichever side is least configurable first, since it is usually faster than trying to override firmware-locked behavior
Resilient Tec pre-tests DAC cables across mixed vendor pairs, so the FEC and coding behavior is already validated before the cable reaches your rack, rather than something you discover after a failed deployment.
FAQ
Does every 25G DAC cable require FEC? Not always, but RS-FEC is the IEEE baseline for reliable 25GbE, and most switch vendors enable it by default. Short passive runs are the main exception where FEC-off can still work.
Why did my DAC cable work with one switch brand but not another? The cable itself is standards-compliant; the two switches simply defaulted to different FEC modes. This is a firmware configuration mismatch, not a hardware incompatibility.
Can I just disable FEC to fix a no-link DAC connection? Sometimes, especially on short runs, but disabling FEC on a link that needs it can trade a hard failure for intermittent errors instead. Match FEC modes explicitly rather than only disabling it.
Does enabling FEC add latency? Yes, but it is measured in nanoseconds and is negligible for almost every real-world workload compared to the cost of a flapping or down link.