Host compatibility
Coded for your host.
Confirmed before production.
How third-party transceiver coding actually works, and the information we need to get it right the first time.
How it works
Coding, EEPROM and the MSA.
Pluggable transceivers follow multi-source agreements that fix the mechanical envelope, the electrical interface and the layout of the module memory, which is why optics from different manufacturers can share the same cage. Inside that memory, a small EEPROM page holds identification fields such as vendor name, part number, revision, serial number, date code, wavelength and supported media, protected by checksums. When a module is inserted, the host reads those fields and decides how to present the port and, on some platforms, whether to accept the module at all. Coding a third-party module means writing identification values that the intended host recognises for the interface type in question. The host software version matters because the tables and checks that read this information change between releases and between platform families, so a module that a host accepts on one software train may be reported differently on another. That is why the platform, the exact model, the software version and the port type are needed before production rather than after delivery. Compatibility is then confirmed for that specific combination, case by case. Platform and product names appear in this reference only to identify the host equipment a module is coded to work with. They are the trademarks of their respective owners, and their use here is descriptive and does not imply any affiliation, approval or endorsement.
Platforms
Notes by host family.
Platform names identify the equipment a module is coded for. They are trademarks of their owners and no affiliation or endorsement is claimed.
| Platform | Common series | What to send us | Reading module data on the host |
|---|---|---|---|
| Cisco | Catalyst, Nexus, ISR and ASR series | Send the platform family, the exact model and line card, the running software version, IOS, IOS XE or NX-OS, and the port type and cage. Behaviour differs between families and between software trains, and some releases require a host command before third-party optics are used. Coding for the combination you name is confirmed per case before production. | show interfaces transceiver detail |
| Juniper | EX, QFX, MX and SRX series | Provide the chassis and line card model, the Junos version, and the interface type and speed the port is configured for. Junos reports module identification and diagnostics in detail, so the output from the target port is useful evidence when a coding question arises. The coding for your model and Junos release is confirmed case by case. | show interfaces diagnostics optics |
| HPE and Aruba | Aruba CX, ArubaOS-Switch, FlexNetwork and Comware series | Say which line the switch belongs to, because ArubaOS-Switch, Aruba CX and Comware-based FlexNetwork products behave differently and use different diagnostic commands. Provide the model, the firmware version and the port type. Coding is prepared for the specific line and release you name, and confirmed before production rather than assumed from the brand alone. | show interfaces transceiver detail on ArubaOS, or display transceiver diagnosis interface on Comware |
| Huawei | S series campus switches, CE series data center switches, NE routers | Provide the exact model, the VRP software version and the port type, and say whether the port is on a fixed panel or an expansion card. Diagnostic output from the target port helps confirm how the host reads module identification. The coding for that model and release is confirmed for your case before production begins. | display transceiver diagnosis interface |
| Arista | 7000 series data center switches | Provide the switch model, the EOS version and the port and speed configuration, including whether a port is used in breakout mode, since breakout affects which module type is appropriate. EOS reports module type and diagnostics clearly, which makes verification straightforward. Coding for your model and EOS release is confirmed per case. | show interfaces transceiver detail |
| Dell and Dell EMC | PowerSwitch S and Z series, N series | State the model and whether it runs SmartFabric OS10, an earlier Dell networking release or a third-party network operating system, since the same hardware can be shipped with different software. Include the version and the port type. Coding is prepared for that software and model combination and confirmed before production. | show interface ethernet 1/1/1 transceiver |
| Extreme Networks | ExtremeSwitching and Summit series | Provide the model, the operating system and version, EXOS or a Fabric Engine release, and the port type. Product lines acquired from other vendors are still in service under the Extreme name and do not all behave the same way, so the exact model matters more than the brand. Coding is confirmed per case. | Confirm in the host documentation |
| MikroTik | CRS and CCR series running RouterOS | Provide the model and the RouterOS version, and say which cage the module goes into, since the SFP and SFP+ ports on the same unit can differ in the rates they support. RouterOS reports module identification and diagnostics per interface, which is useful for verification. Coding is confirmed for the model and release you name. | /interface ethernet monitor sfp-sfpplus1 |
| Ubiquiti | UniFi and EdgeSwitch series | State the exact model and firmware version and whether the device is managed through a controller or directly, as the information available for a module differs between the two. Note the port rate the link is intended to run at. Coding for that model and firmware is confirmed case by case before production. | Confirm in the host documentation |
| Netgear | M4250, M4300 and M4350 series and other managed switches | Provide the model number and firmware version, and the port type, since the SFP and SFP+ cages across this range vary in the rates and module types they accept. Where management is through the web interface only, a screenshot of the port and module status page is useful evidence. Coding is confirmed per case. | Confirm in the host documentation |
| TP-Link and Omada | JetStream managed switches and Omada-managed devices | Give the exact model and hardware revision as well as the firmware version, because hardware revisions within one model name can differ. Say whether the device is standalone or adopted by an Omada controller. Coding for that model, revision and firmware is confirmed before production rather than inferred from the product family. | Confirm in the host documentation |
| Zyxel | XGS, GS and XS series managed switches | Provide the model and firmware version and the port type, and say whether the port is a combo port shared with an RJ45 interface, as combo ports can behave differently from dedicated fiber cages. Coding is prepared for the specific model and release named and confirmed before production. | Confirm in the host documentation |
| Other and white-box (ONIE, SONiC) | ONIE-booted bare metal switches running SONiC or another open network operating system | For open platforms, the network operating system matters more than the hardware brand. Provide the switch model, the operating system and version, and the port and breakout configuration. These platforms usually read and display the module memory without restricting it, so diagnostic output from the target port is the most direct way to confirm how a module is being read. | show interfaces transceiver eeprom |
All trademarks, brand names and platform names used here are the property of their respective owners and serve only to describe the host equipment a module is coded for. MARS transceivers, cables and network devices are independently manufactured third-party products. No affiliation with, sponsorship by, approval by or endorsement from any equipment manufacturer is claimed or implied. Final compatibility is confirmed for the exact host model and software version supplied by the buyer before production, and is not represented as certification by any platform vendor.
Next step
Tell us which host you are connecting.
Send the platform, model and software version and we will confirm the coding options for your configuration.