Vendor coding on optical modules
The module is in your hand, the port stays dark, and the optics have nothing to do with it: the switch read a name in the module's memory, that name is not its own, and it refused.
Estimate my cost →The refusal is not optical, it is administrative #
A pluggable module is a standardised object: the mechanical form factor, the electrical interface and the wavelengths follow agreements between vendors, and two compliant modules talk to each other whoever made them. The blockage is elsewhere. On insertion, the equipment reads a memory inside the module, finds a manufacturer name in it, compares it against a list and refuses to bring the port up if the name is not there. No optical measurement enters that decision: the laser works, the fibre is fine, the budget is correct, and the port stays dark. Read the equipment log before dismantling anything.
What a module's memory holds #
A few hundred bytes, publicly structured so that any equipment can read them. Of the dozen fields it carries, only two decide the refusal.
| Field | What it is for | Role in the refusal |
|---|---|---|
| module type and connector | recognising an optical module with an LC connector | none |
| compliance codes | rate, reach, fibre type | none |
| wavelength and reaches | checking the module matches the link | none |
| manufacturer name | identifying who built the module | triggers the refusal |
| manufacturer part number | identifying the exact model | also checked by some equipment |
| serial number, build date | traceability, warranty | none |
| two checksums | detecting a corrupted memory | a badly recoded module is rejected here, before the name is read |
The manufacturer name is not a signature #
It is text, written once at the factory, and nothing in the standard protects it: any manufacturer can write any name there. So-called compatible modules are exactly that, modules whose maker wrote in the name your equipment expects. No component is counterfeited and no circuit is copied: the module comes from its own factory, with its own optics, and only the internal label claims otherwise. Some vendors add a signature of their own on top, in an area the standard leaves free. It is harder to reproduce, and it explains why certain models stay temperamental where others go in without a word.
What each vendor does with it #
Behaviour varies between vendors, and between product lines from the same vendor. The table gives the tendency, not a guarantee: only the documentation for your exact model commits, and it is read before ordering.
| Vendor | Default tendency | What you see |
|---|---|---|
| Cisco | refuses, unless an option is explicitly enabled | the port goes into error, the log names the module as unsupported |
| Juniper | usually accepts, without supporting | the module works, a warning appears in the log |
| Arista | accepts, and documents it | the module shows as unsupported in the inventory, and works |
| HPE and Aruba | depends on the line and the release | some models refuse, others accept with a warning |
| MikroTik | accepts | no check of this kind |
| Extreme | generally accepts | a log warning is possible |
The option that allows unrecognised modules #
Several vendors, Cisco first among them, ship it themselves. It is documented and prints its own warning when enabled. It changes nothing in law or in contract: it shifts responsibility. The link comes up, and if an incident occurs on it, support is entitled to ask for one of their own modules before investigating. The immediate saving is paid for in future friction. Make that trade-off calmly and write it down: it should not fall to whoever happens to be there, on a night shift, in front of a dark port.
Three questions to tell whether coding is the cause #
Does the equipment display the module's type, reach and serial number? If it does, the memory was read correctly, so the module is electrically and mechanically sound. Does the log name the module as unsupported? A coding refusal is almost always named explicitly, and an optical fault never produces that message. Do transmitted and received power show plausible values? If they do, light is flowing and the problem is elsewhere. The guide to optical modules and connectors covers how to read those readings.
What the law says, and what it is made to say #
One claim circulates on every trade forum: tying a warranty to the purchase of branded parts would be illegal. It rests on a real American statute, the Magnuson-Moss Warranty Act, which prohibits conditioning a warranty on the use of branded parts unless those parts are supplied free of charge. That statute targets consumer products. An infrastructure switch sold between businesses generally is not one, and the argument does not transpose.
On the European side, I know of no European instrument specifically targeting the locking of optical modules on professional equipment: the recent texts on repairability and spare parts concern consumer goods. Competition law could apply to a locking practice, but that presupposes a market analysis and a dominant position, which is a different debate from a port refusing a module. This guide describes a practice and the state of the standards; it does not give legal advice, and a warranty question on a real contract goes to a lawyer.
What coding to order does to a spares stock #
Third-party manufacturers sell modules whose memory carries the vendor name of your choice, specified at order time, and boxes exist to rewrite those fields. This is common and it works. A module coded for one vendor stays coded for that vendor, and another vendor's equipment will refuse it. A reserve built without thinking about this becomes unusable the day the estate changes brand. Write the coding on each module, not just its reach.
Programming boxes #
A pocket box, connected over USB or Bluetooth, writes those fields in seconds and presents the module under more than two hundred brands, Cisco and Juniper among them. Common models cover SFP through QSFP-DD, handle whole batches and read the module's internal readings along the way. Reckon on around 470 euros excluding tax for one, the price of three or four modules. A reserve that served a single vendor then serves the whole estate, and the outlay pays for itself quickly.
These boxes reconfigure their own maker's modules, not anyone's. You will not take a Cisco module and present it as a Juniper. The dependency does not disappear, it changes hands: it moves from the vendor of your switches to the maker of your modules. That is a far better deal, and it is not freedom.
What cannot be reconfigured #
Not everything can be reconfigured, and the box makers say so themselves. FS, for one, states that its HPE-compatible modules generally cannot be reconfigured for hardware reasons, with a few models excepted. The same note adds that attempting it on an unsupported module can cause irreversible damage. Check your exact model before putting it on the box, and do not discover that limit on your last spare, on a night shift.
Changing a DWDM module's channel #
These boxes also set the wavelength. A DWDM link occupies one precise channel of the standard grid, and a route carries dozens of them: covering each channel with its own module demands an inventory nobody keeps.
The wavelength of a fixed-channel module is a property of its laser, and no software moves it; what can be edited in memory is the DECLARED value, which may satisfy equipment that checks it but does not move a single photon. Only a tunable module really changes channel, because its laser is built for it. On that one, the box or the switch command line sets the channel, and a single reference then replaces the whole row.
For a spares stock: a tunable module costs more per unit and costs far less as a reserve.
What to have brought #
No data centre keeps spare optical modules. A module is coded to a vendor, it is expensive, and covering the form factors, reaches and codings would demand an inventory no operator carries. Many sites sell a patch cord or a power cord at the desk, some provide them. Never a module. At three in the morning, the only recourse is someone who has one in their bag. You can post what you are missing on the requests board, where it stays visible for 48 hours.
- One module per reach and per coding actually present in your estate. Write the coding on the module with a marker.
- One single-mode and one multimode LC/LC patch cord, plus an LC/SC adapter. Check before travelling whether the site sells them.
- A visual fault locator and something to clean an end face. Dust causes more outages than coding, and is fixed in ten seconds.
- A console cable suited to your equipment, with its adapter. It is the only way to read the log when the network is down.
- Two power cords, with the sockets your servers actually use. Redundant power needs two, and the site's power strip does not necessarily carry the same sockets as the old one.
What DataColoc knows, and what it does not #
We record site by site what can be verified: how long a badge takes, whether an escort is mandatory, out-of-hours access, whether tools are made available, and whether emergency patch cords and power cords are sold or provided. Those points appear on every site's page, together with the question to ask when the answer is not declared. We do not know which modules your estate uses, what coding they carry, or what your support contract allows. Those three answers are yours: write them where the on-call engineer will find them.
What to take away #
A rejected module is rarely a faulty module, and the equipment log names the cause. The option allowing unrecognised modules is documented, and it shifts support responsibility. The American legal argument everyone cites targets consumer products and does not transpose to professional equipment. Coding is chosen at order time and written on the module, failing which a spares reserve expires at the first change of brand. For choosing the module and computing the optical budget, see the guide to modules and connectors; for fibre, connectors and cross-connects, the data centre cabling guide.
FAQ #
The electrical interface between a pluggable module and its port is standardised, and a compliant module poses no particular risk. The risk sits on the power side: a long-reach module on a very short link saturates the receiver at the far end, which an attenuator corrects. Coding says nothing about a module's quality.
Probably, and the log will say so. If the equipment displays type, reach and serial number, the memory was read correctly: look for a line naming the module as unsupported. Without that line, check the optical readings, the fibre, or a standards mismatch between the two ends.
Dedicated boxes exist and the practice is common. Two traps: the checksums, which must be recomputed, failing which the module looks completely dead; and the signature some vendors add in a free area of the memory, which changing the name alone does not reproduce.
It depends on your contract, and the question belongs before the incident. The tendency is that a vendor investigates on its own hardware and asks for the third-party module to be replaced before going further. That removes a variable rather than refusing on principle. So compare the purchase price AND that potential extra delay.
The inventory would be unmanageable: form factors, reaches, fibre types and vendor codings combine into hundreds. Sites keep what is universal, patch cords, power cords, sometimes tools, and nothing specific to one estate. Check on the site's page what it declares it keeps, and treat the module as yours to bring.
That is the position of a third-party module seller, and it has every interest in being true. It rests on an American statute aimed at consumer products, which an infrastructure switch generally is not. The real risk is not there anyway: nobody will withdraw your warranty because a third-party module is fitted, but support may ask for it to be replaced before investigating an incident on that link, which costs you delay at the worst moment. The only answer that binds anyone is your own contract, obtained in writing before the incident.
Start from your estate's real inventory, not from a catalogue. List the reaches in use and, for each, the brand of the equipment at both ends. You end up with a short list, often three or four references, and that is the one to duplicate. Write the coding on each module: in a year nobody will remember, and a module with unknown coding is no better than an empty box.
Written on 15 September 2026.
From reading to comparing: relevant data centers
Estimate my cost → Compare data centers