What compatibility means on a switch port
A transceiver is a pluggable with a memory map inside it, and the host reads that memory before it will use the port. Rate, form factor, wavelength, reach and the vendor string are all reported back to the switch or the server, and the host compares what it reads against what its software release accepts. A module can be optically and electrically correct and still leave a port in a down state, because the check that failed was a data check rather than a physical one.
That is why every order is two questions rather than one: which module matches the link, and which coded record the host expects to read. This guide covers the second question. The rate and reach side is listed on optics selection guides, and the product range behind it is collected on optical communication products.
Why coded parts are ordered against a platform name
Coding is a programming step at the end of production. The part is written with the vendor identity and the product codes of the named platform, and it is then tested in that platform so the port comes up and the diagnostics report normally. A part coded for one switch family will usually be rejected by another, not because it is faulty but because the host does not recognise the record it read.
A coded part is tested on the platform named on the request, and it is not manufactured by that brand. Parts coded for the common platforms are collected on the Cisco, Arista and Mellanox pages, and the same rule applies to each of them.
Recommended modules and the coding they carry
| Module | Rate | Coding | Reach class | Where it usually lands |
|---|
| 10G SFP+ | 10G | Platform coded | 300 m to 80 km classes | Access and legacy aggregation ports |
| 25G SFP28 | 25G | Platform coded | 100 m to 30 km classes | Server and top of rack ports |
| 40G QSFP+ | 40G | Platform coded | 100 m to 10 km classes | Existing aggregation rows |
| 50G SFP56 | 50G | Platform coded | Per module class | Server ports on 50G platforms |
| 100G QSFP28 | 100G | Platform coded | 100 m to 100 km classes | Spine, leaf and uplink ports |
| 200G QSFP56 | 200G | Platform coded | Per module class | High rate server and fabric ports |
| 400G QSFP-DD and OSFP | 400G | Platform coded | 500 m to 450 km classes | AI and data center fabrics |
| 800G OSFP and QSFP-DD | 800G | Platform coded | 500 m to 2 km classes | New AI fabric ports |
| Coherent pluggables | 100G to 800G | Platform coded | Metro to regional classes | Router ports carrying wavelengths |
Reach classes are the standard ones for each family and the working limit is the measured budget of the link. The rate families are listed on the 100G, 400G and 800G pages.
Host checks, alarms and the fields that matter
Most rejections come from a small set of checks. The first is the identity record: the host reads a vendor name and a part string, and compares them against a supported list that changes between software releases. The second is the rate and lane structure: the host checks that the port speed matches what the module reports. The third is diagnostics, because digital monitoring thresholds are reported per lane and a lane outside its window raises an alarm even while traffic is passing.
Read the host log before assuming the module is faulty. A message naming an unsupported part is a coding question, a message naming a receive level is a link question, and the two are handled in different places.
Releases, firmware and platform generation
The same physical model can be accepted by one release and rejected by the next, because supported part lists ship with host software. Two consequences follow for an order. The release in use belongs in the request, and the platform generation matters as much as the platform name, since a coded part for an older generation of the same family is not automatically right for the current one. Where a link crosses two generations, state both ends.
Cross platform use and what cannot be promised
Some parts read correctly in more platforms than they were ordered for, and some do not read at all. Because the behaviour depends on the host release rather than on the module alone, the honest position is that cross platform use is verified per platform on the bench instead of assumed. Where a port must accept parts from more than one origin, that requirement belongs in the request. Estates are usually mixed, so group ports by platform and release, order coded parts per group, and hold one spare per group.
Coding, spares and the ordering inputs
Treat the coding with the same care as the optical specification. The inputs are the platform model and release, the port list with rates and form factors, the reach class per port, the temperature grade, and the quantity per coded group with spares on a separate line. Parts coded for the other common platforms are listed on the Juniper, HPE, Dell and Finisar pages, and the same rule applies to each of them.
How to choose, in order
- Group the ports by platform model and software release.
- Fix the rate, form factor, reach class and temperature grade per group.
- Confirm the coding inputs: platform name, platform generation and release.
- Check the host supported list against the part you intend to order.
- Order one coded part group per platform and one spare per group.
- Record the coded record of each group for the spares you will need later.
Frequently asked questions
Does coding change the optical performance?
No. Coding changes the data a host reads. Rate, reach and wavelength are set by the hardware and stay exactly the same.
Why does the same model work in one switch and not in another?
Because the two hosts read different supported lists. The part is fine, but the record it reports does not match what that host expects.
Can a coded part be used in another platform?
Sometimes, and it is verified per platform rather than assumed. State both hosts in the request if one port group has to serve more than one platform.
Do the two ends of a link need the same coding?
No. Coding is a host interface question and each end is coded for its own host. The optical requirements at the two ends still have to match.
What do you need to quote a coded order?
The platform model and software release, the port list with rates and form factors, the reach class and temperature grade per port, and the quantity per coded group with spares on a separate line.
Send the platform model with its release, the port list with rates and reach classes, and the count per coded group, and we come back with the part per port, the coding per host and the spare lines set out separately. Related reading: coherent pluggable optics, CWDM4, PSM4 and DR4 and all optics selection guides.
