If your infrastructure predates 2016, you built it around a simple mental model: more speed
means a bigger, faster version of the same thing. That model breaks completely once you cross
into 25G-and-up territory. The lane architecture changes, the optics change, the error-
correction requirements change, and the failure modes change. None of it is a firmware update
away.
This is the first post in a series on high-speed Ethernet. Before we get into transceivers, polarity,
and FEC in detail, here’s the architecture you need to understand first.
Lanes Are the Unit That Matters, Not “Speed”
A lane is a single electrical or optical path running at a fixed signaling rate. Everything above 10G is built by bundling lanes, not by cranking up a dial.
- 10G = one 10G lane
- 25G = one 25G lane (802.3by, ratified 2016)
- 40G = four 10G lanes (802.3ba)
- 100G = four 25G lanes (802.3bm, and later 802.3cd variants)
This is where a lot of confusion starts, because “four lanes” doesn’t mean the same physical thing across every variant. 40GBASE-LR4 and 100GBASE-LR4/ER4 genuinely do run multiple wavelengths over a single strand of single-mode fiber using CWDM (Coarse Wavelength Division Multiplexing – several wavelengths spaced far enough apart that the lasers don’t need precise temperature control, combined and split inside the transceiver itself) — that’s true WDM. But the short-reach variants most data centers actually deploy, 40GBASE-SR4 and 100GBASE-SR4, use parallel fiber: four separate transmit/receive fiber pairs inside one MPO/MTP connector, each carrying its own lane on multimode fiber. No wavelength multiplexing involved. Mixing these two models up is one of the most common misunderstandings people carry into their first 100G deployment, and it matters the moment you’re troubleshooting a link and trying to figure out whether you’re chasing a wavelength problem or a fiber-pair problem. In short, SR4 and LR4 both say “4,” but one means four fibers and the other means four colors — which is exactly what determines whether a bad link is a fiber-pair problem or a wavelength problem.
And for anyone about to ask “what about 50G” — 50G doesn’t scale the way 40G and 100G do. Those two bundle more lanes at a fixed per-lane rate — four 10G lanes and four 25G lanes respectively. Single-lane 50G (802.3cd) keeps one lane and changes the modulation instead, using PAM4 signaling (four amplitude levels per symbol, carrying two bits per signaling interval) on one lane to hit 50 Gbps, versus four lanes of NRZ signaling (the older two-level scheme that carries one bit per interval) for 100GBASE-SR4. Different modulation, different lane count, different electrical characteristics. It’s architecturally its own thing, not a stepping stone between 25G and 100G.
Why 40G Isn’t Dead
Speed adoption moves from the core outward — financial trading floors and hyperscalers push 100G first, everyone else follows on a slower curve. Right now 40G and 25G are sitting in the price/performance sweet spot for campus aggregation, hospital networks pushing real-time imaging and patient data, and on-prem data centers that don’t have hyperscaler budgets or hyperscaler traffic volumes.
Two practical reasons 40G survives:
- The server is usually the bottleneck before the link is. Swapping a NIC from 40G to 100G does nothing if the application, the PCIe bus, or the storage backend can’t feed it.
- QSFP+ (40G) modules are mechanically compatible with QSFP28 (100G) ports. You can often upgrade a core switch to 100G and keep 40G distribution switches hanging off it — assuming the switch ASIC and firmware actually support mixed-rate operation, which isn’t universal and is worth confirming with your vendor before you assume it. Where it works, it lets you upgrade the core surgically instead of ripping out the whole plant at once.
25G: The Base Unit, and Why It’s Sensitive
25G per lane became the industry’s building block because the math scales cleanly — 4x25G gets you 100G, 4x100G gets you 400G. It’s also economically attractive: 25G optics have come down in price enough that they’re now routinely deployed at scale in leaf-spine fabrics, commonly in a 48x25G-server / 6x100G-uplink rack layout, all running the same underlying lane technology.
The catch is signal tolerance. A 25G lane is far less forgiving of loss and reflection than a 10G lane running over the same physical plant.
Pro tip: OM4 multimode fiber that’s carried 10G cleanly for years is not automatically ready for 25G or 100G-SR4. A connector that’s slightly dirty or has minor end-face damage will barely register as a problem at 10G and will cause consistent packet loss at 25G. Clean and inspect your connectors, and test the actual link before cutover — don’t assume a fiber plant “passes” just because it’s been quiet at a lower speed.
100G Doesn’t Get New Problems — It Gets 25G’s Problems, Four Times Over
Because 100G-SR4 is four independent 25G lanes, any marginal condition that a single 25G lane tolerates gets multiplied across the link. A cabling plant that was “good enough” for 40G (4x10G, NRZ, more forgiving) can fail outright at 100G with random packet loss and flapping links — not because anything changed, but because the margin for error that existed at 10G-per-lane never existed at 25G-per-lane.
Two specifics worth knowing before you deploy:
- FEC often has to be configured manually, not negotiated. For optical modules using clause 82/91 encoding, FEC is typically a manual setting on both ends of the link — mismatched FEC settings between two devices is a classic cause of a link that “should work” but doesn’t. (Backplane/copper links using clause 73 autonegotiation are the exception — FEC there can be negotiated automatically.) Check both ends explicitly; don’t assume. (Note these clause numbers are section numbers within IEEE 802.3, not vendor settings.)
- There’s no auto-MDIX equivalent on fiber. Auto-MDIX is a copper concept. On fiber, TX/RX polarity has to be managed correctly across the MPO cassette, trunk, and patch cords, and getting it wrong doesn’t throw an obvious error — it just doesn’t link, or links with faults that look unrelated to polarity. We’ll dedicate a full post in this series to sorting this out.
Interoperability and Testing
The IEEE standard is the floor, not the ceiling — vendors regularly build proprietary features on top of it. BiDi optics are a good example: early proprietary BiDi implementations locked you into a single vendor’s transceivers, though standards-based BiDi from multiple transceiver vendors is now interoperable in many cases. Worth confirming compatibility explicitly rather than assuming either way, since it varies by vendor and product line.
Where mixed-vendor risk is still very real is troubleshooting: if you’re running third-party optics and a link fails, vendor support will often point at the module first, whether or not it’s the actual cause. That’s the practical case for vendor-neutral test equipment — something that lets you validate the physical layer, confirm FEC settings on both ends, read pre-FEC bit error rate per lane, and verify end-to-end performance with the actual modules you’re deploying, before anything touches production. The pre-FEC number is the one worth insisting on. FEC will mask a marginal lane completely: the link looks flawless after correction while error correction is quietly running near its limit, and then it falls over the first time anything on the plant shifts — a patch cord reseated, a temperature swing, a connector that picks up dust. Post-FEC clean tells you the link works today. Pre-FEC tells you how much margin you have left, which is the whole question at 25G per lane. We’ll come back to this later in the series. It turns “swap parts and see if it goes away” into an actual diagnosis.
