SFP Optical Transceiver Troubleshooting: Engineer's Checklist

2026年9月2日 LOG admin

Most optical transceiver faults trace back to a short list of root causes - the wrong module for the link budget, contaminated connectors, miscoded third-party optics, or a port that was already marginal before the module arrived - yet engineers often jump straight to swapping hardware. This article presents a structured SFP/SFP+ troubleshooting checklist that works through each layer in order: digital optical monitoring (DOM) data, physical inspection, compatibility coding, power levels, and fault isolation. Work it top to bottom, record what you find at each step, and you will usually be able to name the culprit before you put hands on the module.

Before You Start: Write Down the Baseline

Every troubleshooting ticket on optics gets better if you capture four facts first: the module type and part number, the link distance and fiber type, the media converter or patch panel path, and whether the link has ever worked. A link that never came up is a design or compatibility problem; a link that ran fine for two years and dropped is a physical degradation problem. Those two cases lead to completely different first actions, and the troubleshooting checklist below assumes you know which one you are in.

Also note the failure mode precisely. "The port is down" is not enough. Is the port down/down, up/down, flapping, or up with errors? A port that shows link but passes no traffic has a different cause set than a port that never lights.

Step 1: Read the DOM Data First

Digital Optical Monitoring gives the fastest look inside the module. Pull the DOM output before touching anything physical, because it is the only measurement you will have of the link's state while it was still connected:

# Cisco IOS-XE
show interface GigabitEthernet0/1 transceiver
show interface transceiver detail

# Arista EOS
show interfaces transceiver

# Juniper Junos
show interfaces diagnostics optics ge-0/0/1

# Brocade / Dell Fabric OS
sfpshow 3/1

# Linux host with SFP+ NIC
ethtool -m eth2

Record Tx power, Rx power, temperature and bias current. A module running hot, or a laser bias creeping up over time, predicts failure before the link drops. Four numbers are worth memorising as red flags:

Temperature more than 10-15 C above neighbouring modules in the same switch: check the airflow path and the module's own heat sink seating.
Tx bias current that has climbed steadily over weeks: the laser is ageing and will eventually fail the eye mask.
Rx power inside the warning band but close to the low alarm: the link has no margin and will drop with any temperature change.
Tx or Rx at roughly -30 dBm: the receiver sees no light at all. Treat it as "dark fiber", not as a weak signal.

Step 2: Physical Layer and Fiber Condition

Contamination is the number one cause of intermittent optics faults. Inspect connector end-faces with a fiber inspection probe (200x-400x magnification) and clean with the right tool: one-click cassette cleaners or lint-free wipes with isopropyl alcohol for LC/SFP, MPO one-click cleaners for multi-fiber connectors. Clean both ends - the module receptacle and the patch cable ferrule - and never assume a new module or cable is clean.

Practical rules that save repeated truck rolls:

Inspect before you clean, then inspect again after cleaning. A scratched ferrule will never be fixed by cleaning, and you need to know which problem you have.
Always cap unused ports and patch-cord ends. Dust in a parked patch panel position is the classic source of a "new" link that fails on first light-up.
Check bend radius. A patch cord zip-tied against a rail or looped tighter than 10x the cable diameter causes macrobending loss, which shows up as a few dB of extra attenuation and is invisible unless you look for it.
Check the fiber type against the optic. Single-mode patch cords into a multimode SR module is a frequent, and frequently missed, mismatch.
Confirm the polarity and the TX/RX swap on duplex LC: a reversed pair gives you a dark receiver on both ends, which looks exactly like a dead laser.

Step 3: Verify Compatibility and Coding

# Cisco
show inventory
show interface transceiver | include type|part number|serial

# Check EEPROM coding matches the platform's supported list
show interface transceiver eeprom

Unsupported or miscoded third-party optics often bring the port administratively down or fail to light. Confirm the module's type, part number and serial against the switch vendor's compatibility matrix, and check the firmware release notes - some platforms need a software upgrade to recognize newer module generations.

When a vendor rejects a module outright the log will usually say so plainly, for example an "unsupported transceiver" or "transceiver type not supported" message, or the module will appear in show inventory with an unknown type. Two things are worth knowing about coding problems:

Coding is about the EEPROM contents, not about the optical performance. A module can be electrically perfect and still be rejected because its vendor name or part number is not on the allow list.
Some platforms enforce the check only at link-up, so a module that works on one software release may be rejected after an upgrade. If a link broke immediately after a switch firmware upgrade and nothing else changed, suspect the compatibility check before you suspect the fiber.

On third-party modules, verify the coded data rate matches what the port is expected to negotiate (1G vs 10G vs 25G coding, and breakout coding for QSFP-to-SFP assemblies). A 10G module coded as 1G on a 10G-only port will simply never come up.

Step 4: Compare Tx/Rx Power Against Spec

If Rx power is low but Tx power is nominal, the fault is in the fiber path - lossy connector, bend, wrong fiber type, or excessive distance.
If Tx power is low, the module's laser is the suspect.
Rule of thumb for budget math: add 0.5-1 dB per connector pair and ~0.2 dB/km of fiber attenuation, then compare the result against the receiver sensitivity. Rx below about -20 dBm on 1G (or -15 dBm on 10G) class links indicates excessive loss.

The practical way to use this step is to compare the two ends. Read DOM on both the near and far end of the same link and compare each end's Tx against the other end's Rx:

# Near end (switch A)
Tx -3.2 dBm   Rx -6.8 dBm

# Far end (switch B)
Tx -3.0 dBm   Rx -13.9 dBm

In that example both transmitters are emitting normally, but one direction of the fiber pair has about 11 dB of loss while the other has under 4 dB. The fault is asymmetric, which means a single dirty or damaged strand - not a module whose laser is weak. That diagnosis is only possible if you read both ends; a single-end reading is enough to raise a flag but rarely enough to close a ticket.

Step 5: Isolate the Fault - Module, Fiber or Port

Isolation is the fastest path to a definitive answer. Swap in a known-good module on the suspect port, then a known-good fiber, in combination:

Good module + suspect fiber + suspect port - if it works, the original module was bad.
Suspect module + good fiber + good port - if it fails, the module is confirmed bad.
Both good but link still down - inspect the far-end port and check configuration (shutdown state, speed/duplex mismatch, wrong VLAN).

A clean reseat (power down, reseat module and connectors, power up) fixes marginal contact pressure issues, and a sustained multi-hour test confirms stability before you close the ticket.

Keep the discipline of changing one variable at a time. Technicians frequently swap the module, the fiber and the port in one go, the link comes up, and nobody learns which of the three was at fault - so the same problem returns on the next link. Write the results into the ticket as you go.

Step 6: Rule Out Configuration and Protocol Causes

Not every optics ticket is an optics problem. Once the physical layer checks out, verify:

Port state and speed: a port hard-set to 1000/full against an auto-negotiating partner will stay down or half-duplex.
Autoneg and FEC settings: on 25G/100G links, mismatched RS-FEC or CL91 settings produce link-up with errors or no link at all.
VLAN and STP: a link can be up but blocked by spanning tree, which looks like a dead link if you only test with a ping from the wrong VLAN.
Error counters: CRC and input errors on a link that is up points to the physical layer, not to the optics being "unsupported".
Interface flapping history: show interfaces | include flap or the equivalent on your platform tells you whether the link is genuinely stable or just quiet right now.

Symptom to First Move: A Short Reference

When a ticket arrives with only a symptom, the checklist above can be entered at the most likely step rather than at the top:

Link never came up on a new install: start at Step 3 (coding and compatibility) and Step 2 (polarity and fiber type), because new hardware pairs usually fail on coding or on a swapped transmit/receive pair.
Link dropped after working for months: start at Step 1 (DOM) and compare against the commissioning baseline; degradation almost always shows in the power readings first.
Link flaps: read DOM twice, minutes apart, and check the connector seating and the cable routing; a reading that moves by more than about 1 dB without physical work indicates a marginal contact.
Link is up with CRC or input errors: inspect end faces and verify the fiber type and distance before replacing anything, because errors with normal power point to signal quality rather than level.
Multiple links on the same switch fail together: suspect the switch firmware release or the compatibility check rather than a batch of coincidentally bad modules.

Step 7: Prevent the Next Incident

Baseline DOM readings on day one and store them in your monitoring platform; a trend beats a threshold every time.
Alert on Rx power within 3 dB of the low alarm, not only on alarm state, so you act before traffic drops.
Keep one spare module of each type in each data hall, with the same coding, so replacement is a known-good swap.
Log cleaning as part of the install procedure. A three-second one-click clean at install time removes the single most common cause of intermittent optics faults.
Record the module part number, serial and coding in your CMDB so the next engineer does not have to reconcile it from the console.