Why Your SFP Module Works on MikroTik but Not on Cisco (And 3 Ways to Fix It)
Your third-party SFP works on MikroTik, but Cisco rejects it? Learn why vendor coding causes this, plus 3 proven fixes: CLI commands, EEPROM recoding, or pre-coded modules.
You plug a 10G SFP+ module into your MikroTik switch — link comes up instantly. You move the exact same module to a Cisco Catalyst or Nexus switch, and the port goes dead. The log shows something like:
%PHY-4-UNSUPPORTED_TRANSCEIVER: Unsupported transceiver found in Gi1/0/1
%PM-4-ERR_DISABLE: gbic-invalid error detected on Gi1/0/1, putting Gi1/0/1 in err-disable stateNothing is wrong with your module. The optics, the laser, the electronics — all fully functional. What's missing is a few bytes of data inside the module's memory chip. This guide explains exactly what's happening and gives you three practical ways to solve it, including what to do if you're sitting on a whole batch of modules that won't work.
Quick answer: MikroTik switches accept almost any standards-compliant SFP. Cisco switches read the module's EEPROM and check for a Cisco-specific compatibility code. If the code isn't there, the port is disabled. You can fix this by (1) entering two CLI commands on the switch, (2) recoding the module's EEPROM with a coding board, or (3) buying modules pre-coded for Cisco. Each option has trade-offs — we'll walk through all three below.
Why the Same Module Behaves Differently on Different Switches
Every SFP, SFP+, SFP28, or QSFP module contains a small EEPROM memory chip. This chip stores identification data defined by the SFF-8472 industry standard: vendor name, part number, serial number, supported data rates, wavelength, and — critically — vendor-specific compatibility fields.
When you insert a module, the switch reads this EEPROM over the I2C bus. What happens next depends entirely on the switch vendor's policy:
| Switch platform | Behavior with third-party/generic SFPs |
|---|---|
| MikroTik | Open policy. Accepts virtually any standards-compliant module. No vendor check. |
| Ubiquiti, TP-Link, most white-box | Generally open. Some models show a warning but still work. |
| Cisco Catalyst (IOS/IOS-XE) | Checks for Cisco vendor coding. Without it: err-disable state, port shut down. CLI workaround exists. |
| Cisco Nexus (NX-OS) | Also checks vendor coding. The classic CLI workaround does not exist on most NX-OS platforms — coding is often the only path. |
| HPE / Aruba | Varies by line. Some log warnings, some disable DDM, some block entirely. |
| Juniper, Arista | Usually link up with a warning; Arista has a hidden config flag. |
| Dell OS10 | Requires an unlock license or specific configuration on some platforms. |
This is why your module "works on MikroTik but not on Cisco." It's not a hardware defect and not a quality issue — it's a vendor lock-in check implemented in the switch firmware. The module simply doesn't carry the ID data the Cisco switch is looking for.
Important nuance most guides skip: the check is about identity data, not performance. A properly recoded third-party module is electrically and optically identical to how it was before recoding. Only the identification metadata changes.
First, Confirm This Is Actually a Coding Problem
Before touching any solution, spend two minutes ruling out other causes. Run these commands on the Cisco switch:
show interfaces status err-disabled
show inventory
show interfaces gi1/0/1 transceiver detail
show logging | include TRANSCEIVER|GBICHow to read the results:
- Port listed as err-disabled with cause
gbic-invalid→ coding issue. Continue with this guide. show inventoryshows the module with correct part data, but there's no link → likely a fiber-side problem instead: wrong wavelength pairing (especially with BiDi modules — a 1270nm module must face a 1330nm module), reversed TX/RX, dirty connectors, or single-mode vs multi-mode mismatch.- Module not detected at all, no log entry, nothing in inventory → possible physical issue: module not fully seated, damaged gold fingers, or a dead module. Reseat it, clean the contacts, and test it in another device.
- Command
service unsupported-transceiverdoesn't exist on your switch → note that some entry-level platforms (for example, Catalyst 2960L LAN Lite images) don't include the workaround commands at all. On those devices, only Options 2 and 3 below will help.
If your symptoms match the first case — the module works on MikroTik, and Cisco throws gbic-invalid or UNSUPPORTED_TRANSCEIVER — you have a coding problem. Here are your three ways out.
Option 1: The CLI Workaround (Free, but Limited)
Cisco IOS and IOS-XE include two undocumented commands that tell the switch to tolerate non-Cisco modules:
Switch# configure terminal
Switch(config)# service unsupported-transceiver
Switch(config)# no errdisable detect cause gbic-invalid
Switch(config)# end
Switch# write memoryThen reset the port:
Switch(config)# interface gi1/0/1
Switch(config-if)# shutdown
Switch(config-if)# no shutdownRemove and reinsert the module. In most cases, the link comes up.
When you enter the first command, the switch displays a warning stating that Cisco may withhold warranty support if a fault is traced to third-party transceivers. This is worth understanding accurately: your switch warranty is not automatically voided, but Cisco TAC can decline to troubleshoot issues while third-party optics are installed, and may ask you to swap in Cisco-branded modules during a support case.
Where this option falls short — and why many teams avoid it:
- It doesn't work everywhere. Most Cisco Nexus (NX-OS) data center switches do not support these commands. If your network includes Nexus, the CLI route is a dead end there.
- Some IOS images lack the command. Entry-level license tiers (e.g., LAN Lite) may not include it, and you can't type your way around a command that doesn't exist in the image.
- It lives in your running config. The commands are visible in
show running-config. In audited enterprise or carrier environments, an undocumented override sitting in every switch config is something many network teams are not allowed to deploy as policy. - You must configure every switch. With 5 switches, fine. With 50 switches across customer sites you don't control, it doesn't scale — and you may not even have config access to a customer's switch.
- DDM/DOM may be incomplete. On some platforms, digital diagnostics (TX/RX power readings, temperature) display incorrectly or not at all for uncoded modules, which hurts long-term monitoring.
Best for: lab environments, small networks you fully control, quick emergency fixes.
Not enough for: Nexus deployments, customer-site installations, audited environments, or anyone who wants modules that "just work" in any Cisco port without touching the switch config.
Option 2: Recode the Modules You Already Own (Best for Batches)
This is the option most troubleshooting guides never mention — and for anyone holding stock, it's usually the most economical.
Since the compatibility check only reads EEPROM data, you can rewrite that data. Using an SFP coding board (also called a programming board) connected to a PC, you write a Cisco-compatible code file into the module's EEPROM. After recoding, the switch reads the module as Cisco-compatible and brings the port up — no CLI workarounds, no config changes, full DDM support.
What you need:
- A coding board that supports your form factor (SFP, SFP+, SFP28, QSFP+, QSFP28). It's a small USB-connected device with a cage you insert the module into, plus coding software.
- The correct code file for your target platform — e.g., a Cisco Catalyst code, a Cisco Nexus code, an HPE code. Codes differ by platform and data rate, so "Cisco code" for a 10G SFP+ is not the same as for a 25G SFP28.
The workflow takes about a minute per module:
- Insert the module into the coding board
- Read and back up the current EEPROM (always keep the original)
- Load the target code file and write it
- Verify the checksum, then test in the target switch
The real-world math: why this beats replacing your stock
Here's a scenario we see constantly. A network integrator has 25 pairs of 25G BiDi SFP28 modules originally coded generic/MikroTik. A new project requires them to run in Cisco Nexus switches — where the CLI workaround isn't available.
- Replacing all 50 modules with Cisco-coded units: you pay full price × 50, and your existing stock becomes dead inventory.
- Recoding: buy one pair of Cisco-coded modules (or just the code file) plus one coding board — a one-time cost of roughly $200–300 including shipping. Copy the verified working code to the remaining 24 pairs yourself. Total incremental cost: under $300 to rescue 50 modules.
And the coding board keeps paying for itself. Next month, when a different project needs those modules in HPE or Juniper equipment, you load a different code file and reprogram them again. One inventory pool now serves every switch brand your customers run. For ISPs, system integrators, and resellers, this effectively turns generic modules into universal modules.
Things to know before recoding:
- Write-protected modules exist. Some manufacturers password-protect the EEPROM. A good coding board vendor maintains a password database and can tell you in advance whether your specific modules can be recoded.
- Use verified codes, not guesses. A wrong or corrupted code can leave a module unrecognized everywhere. This is why the "buy one coded pair, clone it" approach is safer than hand-editing hex values from forum posts — you're copying a factory-verified, checksum-correct code.
- Cisco Catalyst and Cisco Nexus codes are different. If you run both, confirm which platforms you need codes for. (When our customers order, we ask for the exact switch model to send the right code the first time.)
- The module's optical specs don't change. A 10km module stays a 10km module. Recoding changes identity, not physics — so it can't make an incompatible data rate or wavelength magically work.
Best for: anyone with existing stock (even 5+ modules), integrators serving multi-vendor environments, ISPs, Nexus users, and teams that can't modify customer switch configs.
Option 3: Buy Modules Pre-Coded for Your Platform (Best for New Purchases)
If you're buying new modules anyway, the cleanest solution is to have them coded for your target platform before they ship. You tell the supplier "these will run in Cisco Nexus 9300" or "Catalyst 9300 + some ports on Huawei," and the modules arrive plug-and-play — correct code, correct DDM behavior, tested before dispatch.
A capable transceiver supplier should be able to:
- Code any module for Cisco (Catalyst and Nexus), Huawei, HPE/Aruba, Juniper, Arista, MikroTik, Dell, and other major platforms at no extra cost
- Ship mixed-coding batches (e.g., 10 pairs Cisco-coded + 10 pairs HPE-coded from the same product)
- Provide the code file along with the modules, so you can re-clone or re-verify later
- Supply a coding board so you can switch platforms yourself down the road
That last point matters more than most buyers realize. Ask your supplier one question before ordering: "If my switch platform changes next year, can I recode these modules myself, and will you provide the code files?" A supplier who says yes is selling you a flexible asset. A supplier who says no is selling you future dead stock.
Best for: new deployments, buyers who know their switch platforms in advance, and anyone who wants zero on-site configuration work.
Which Option Should You Choose? (Decision Table)
| Your situation | Recommended path |
|---|---|
| Small lab / home network, IOS switch, 1–2 modules | Option 1 — CLI commands, done in 60 seconds |
| Cisco Nexus switches (NX-OS) | Option 2 or 3 — CLI workaround usually unavailable |
| You already own a batch of generic/MikroTik-coded modules | Option 2 — recode; buy one coded pair + board, clone the rest |
| Installing at customer sites where you can't touch switch config | Option 2 or 3 — modules must work on insertion |
| Buying new modules for a known platform | Option 3 — order pre-coded, arrives plug-and-play |
| Multi-vendor environment (Cisco + Huawei + HPE mix) | Option 2 + 3 combined — pre-coded batches plus a coding board for flexibility |
| Audited enterprise where undocumented commands are banned | Option 2 or 3 — keep switch configs clean |
Frequently Asked Questions
Will a recoded module damage my Cisco switch?
No. Recoding only changes identification data in the EEPROM. The module's electrical and optical behavior is unchanged. Standards-compliant transceivers — coded or not — interoperate safely; the vendor check is a business policy, not a safety mechanism.
Does using third-party or recoded SFPs void my Cisco warranty?
The switch warranty is not automatically voided. However, Cisco's support policy allows TAC to require Cisco-branded transceivers during troubleshooting, and to withhold support for faults traced to third-party components. Many organizations accept this trade-off given that branded optics often cost 5–10× more for identical hardware.
Why does my module work but show no TX/RX power readings on Cisco?
Incomplete or missing DDM data is a symptom of generic coding on a platform that expects vendor-specific DDM fields. Correct platform coding typically restores full diagnostics.
Can one module be coded for two platforms at once?
A module carries one code at a time. If you regularly move modules between platforms, keep a coding board on hand — switching codes takes about a minute per module.
I have BiDi modules. Anything special to watch for?
Yes — BiDi modules work in wavelength pairs (e.g., 1270nm-TX on one end, 1330nm-TX on the other). If your link fails even after coding is fixed, verify you've deployed the modules as an A/B pair, not two of the same side. Coding and wavelength pairing are independent requirements; you need both right.
My switch is a Catalyst 2960L / entry-level model and the CLI command doesn't exist. Now what?
Some license tiers ship without the workaround commands. Recoding the module (Option 2) or buying Cisco-coded modules (Option 3) works regardless of what commands your IOS image includes.
The Bottom Line
An SFP that works on MikroTik but fails on Cisco isn't broken — it's just speaking the wrong dialect. You can teach the switch to tolerate it (CLI), teach the module to speak Cisco (recoding), or buy modules that speak Cisco from day one (pre-coded). The right choice depends on how many modules you have, which Cisco platforms you run, and whether you control the switches they'll live in.
Whatever you do, don't throw away working inventory or pay 5–10× for branded optics just to pass an EEPROM check. A $200 coding setup or a supplier who codes for free solves this permanently.
Facing This Issue Right Now? We Can Fix It This Week.
At Axonode Solution, compatibility coding isn't an add-on — it's how we ship every order:
- ✅ Free platform coding on all modules — Cisco Catalyst, Cisco Nexus, Huawei, HPE, Juniper, Arista, MikroTik, and 30+ other platforms. Just tell us your switch model.
- ✅ Rescue your existing stock — if you're holding modules with the wrong coding, we supply verified code files and coding boards (SFP/SFP+/SFP28/QSFP28) so you can reprogram your entire inventory yourself.
- ✅ Every module tested before dispatch — including DDM verification on the target platform coding.
- ✅ Full range in stock — 1G to 100G, including 10G/25G BiDi up to 40km, CWDM/DWDM.
Send an Inquiry Now → 💬 WhatsApp Us
Or skip the forms entirely: message us on WhatsApp (+86 134 8078 2233) with your switch model + module quantity, and we'll reply within 12 hours with a compatibility confirmation and quote — including the exact coding your platform needs.
Not sure whether your modules can be recoded? Send us the module model and a photo of the label — we'll check the EEPROM protection status for free before you spend anything.
