My SFP Link Won’t Come Up — A Field Troubleshooting Guide

By Chiao Hsiang — QA Technical Lead, Sanoc

It is 11 p.m., the maintenance window is half over, and the new SFP you just seated is staring back at you with a dark link LED. The switch port says down. The change ticket says up. Somewhere between those two states is a problem you need to find fast — before the window closes and the rollback clock starts.

I have spent years on the QA bench at Sanoc watching transceivers come back as “dead on arrival” that were, in fact, perfectly healthy modules plugged into the wrong fiber, the wrong port mode, or a connector with a fingerprint on the ferrule. A link that won’t come up is rarely a single failure — it is a chain of physical, electrical, and optical conditions that all have to line up. The good news is that the chain is short and the order of investigation is almost always the same.

This is the field troubleshooting guide I wish every engineer had taped inside the rack door. It works through the link from the most common, easiest-to-fix causes to the rarest, and it deliberately leaves “blame the transceiver” for last. Work the steps in order and you will isolate the fault systematically instead of swapping parts in the dark.

Step 1: Start at the Physical Layer — Is It Even Seated?

Before you read a single line of DOM data, prove the basics. The overwhelming majority of “link won’t come up” tickets I have triaged were physical-layer issues, and the cheapest fix in networking is pushing a module the last two millimeters until it clicks.

Symptom: Port is administratively up but link LED is dark

Likely causes: module not fully latched; bale clasp open; dust cap still on the fiber; LC connector not seated in the optical bore.

Check: Re-seat the transceiver. You should feel and hear a positive click as the latch engages. Remove and re-insert the LC duplex connector — listen for the click on both legs. On copper SFP modules (RJ45), confirm the patch lead clicks home in the cage.

Then ask the switch what it sees at the port level:

! Cisco IOS / IOS-XE
show interface status
show interfaces GigabitEthernet1/0/1 status

! Arista EOS
show interfaces Ethernet1 status

! Juniper Junos
show interfaces ge-0/0/1 terse

If the port reports notconnect or down with the module installed, you have confirmed the switch is not getting a valid link signal — which is exactly what we expect to chase. If it reports err-disabled, jump ahead: that is usually a security, GBIC-validation, or speed/duplex event, not a dead module.

Symptom: Tx and Rx may be crossed

Duplex LC fiber has a transmit leg and a receive leg. If a patch panel was re-terminated or a jumper was swapped, Tx on your end may be feeding Tx on the far end — two transmitters shouting at each other and no light arriving at either receiver. This is one of the most common “both ends look fine but no link” faults in the field.

Check: Swap the two fibers at one end only. If the link comes up, you found a polarity (A/B) error. This single test resolves a surprising share of structured-cabling link failures.

Symptom: Copper SFP link is intermittent or won’t come up at all

On RJ45 copper SFP and 10GBASE-T modules the physical fault profile is different from fiber. The usual offenders are a marginal patch lead, a cable run that exceeds the category rating for the speed, or a connector that has not fully latched in the cage. Before you touch any configuration, replace the patch lead with a known-good one of the correct category and confirm the run length is within spec for the speed you are running. A surprising number of “the copper SFP is dead” tickets are a Cat5e jumper being asked to carry a 10G link it was never rated for.

Step 2: Read the Transceiver — Does the Switch Recognize It?

Once the physical connection is solid, ask the switch what it thinks of the optic itself. Modern transceivers carry an EEPROM with vendor, part number, and DOM (Digital Optical Monitoring, also called DDM) telemetry. The switch reads this on insertion.

Symptom: Console logs an “unsupported transceiver” message

On Cisco platforms you may see a syslog line stating the SFP is not supported, and the port may refuse to come up. This is a vendor-validation behavior, not a fault in the module. Read the EEPROM identity:

! Cisco IOS-XE
show interface GigabitEthernet1/0/1 transceiver
show interface GigabitEthernet1/0/1 transceiver detail

! Arista EOS
show interfaces Ethernet1 transceiver

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

If the platform is gating the port on vendor ID, the documented Cisco override is:

! Cisco IOS / IOS-XE — global config
service unsupported-transceiver

Use this knowingly. It instructs IOS to bring up ports with third-party optics. A standards-compliant compatible module — correctly coded to the platform — should already pass identification without it; if you are reaching for this command often, the module’s EEPROM coding for that platform is the thing to fix, not the switch. We cover the identification and coding mechanics in depth in our complete guide to Cisco-compatible SFP modules.

Symptom: Module reads but reports no part number or garbage fields

If show interface transceiver returns blank or nonsensical vendor data, the EEPROM may be unreadable — a genuinely failed module, a bent cage pin, or a counterfeit with corrupted data. Re-seat once; if the identity is still garbage, set the optic aside as a hardware suspect and continue diagnosis with a known-good unit.

Step 3: Check the Optical Power Budget (DOM/DDM)

This is where a five-minute read separates the engineers from the part-swappers. DOM gives you the single most useful number in the entire investigation: received optical power (Rx power). If Rx power is outside the receiver’s sensitivity range, the link physically cannot come up no matter how perfect everything else is.

! Cisco IOS-XE — the detailed view shows Tx/Rx power, temperature, bias, voltage
show interface GigabitEthernet1/0/1 transceiver detail

! Arista EOS
show interfaces Ethernet1 transceiver dom

! Juniper Junos — laser output and receiver power per lane
show interfaces diagnostics optics xe-0/0/1

Symptom: Rx power is too low (e.g. -25 dBm on a link rated to -14 dBm)

Likely causes: too much insertion loss for the optic’s budget — long fiber run, too many patch panels, a dirty or damaged connector, a tight bend, or a mismatched optic for the distance (an SR optic on a 20 km span will never reach).

Check and fix: Clean both connector end-faces with a proper cleaner — do not skip this; contamination is the number-one cause of marginal optical links. Inspect for macro-bends. Compare your measured Rx against the optic’s specified receiver sensitivity. If the math says the span exceeds the budget, you need a longer-reach optic (LR/ER/ZR) rather than a switch change. For a worked example of how to add up fiber, connector, and splice loss against an optic’s budget, see our 10GbE SFP+ transceiver reference and supporting link-budget material.

Symptom: Rx power is too high (receiver overload)

Likely cause: a long-reach optic (LR/ER) running over a very short patch with no attenuation, saturating the receiver.

Fix: Add a fixed optical attenuator sized to bring Rx power back inside the specified window, or use a shorter-reach optic appropriate to the distance. An overdriven receiver can flap or stay down exactly like an underpowered one.

Symptom: Tx power reads near zero or “Laser off”

If the transmit laser is dark, the module’s own laser may have failed, or the port has issued a laser-shutdown due to an upstream condition. This is a strong hardware suspect — but only after you have ruled out the cheaper causes above.

Step 4: Resolve Speed and Duplex Mismatches

An optic can be seated, recognized, and within optical budget and the link will still refuse if the two ends disagree on speed or auto-negotiation. This bites hardest when a 1G optic lands in a port configured for 10G, or when one side forces a setting the other expects to negotiate.

Symptom: Link stays down between a 1G and a 10G port

Check: Confirm the configured port speed matches the optic’s rated speed. A 1000BASE optic will not bring up a port hard-set to 10 Gb, and many SFP+ ports do not auto-fall-back to 1G without explicit configuration.

! Cisco — verify and set
show interface GigabitEthernet1/0/1 capabilities
interface TenGigabitEthernet1/0/1
 speed 1000        ! where the platform/optic supports 1G on a 10G cage

Symptom: Copper SFP (RJ45) link flaps or won’t negotiate

On copper SFP and 10GBASE-T modules, auto-negotiation behavior is platform-specific. If one end auto-negotiates and the other is forced, the link may not come up or will come up at the wrong duplex.

! Cisco — examine negotiation state
show interface GigabitEthernet1/0/1 status
show interface GigabitEthernet1/0/1

Set both ends to match — either both auto or both forced to the same speed/duplex. Our 1G copper RJ45 SFP page documents the supported negotiation and reach behavior for these modules.

Step 5: Confirm the Fiber and Wavelength Actually Match the Optic

Optics are not interchangeable across fiber types or wavelengths. A perfectly healthy module on perfectly clean fiber will show no link if the two were never meant to work together. This is a frequent cause of “the optic is dead” calls that are really a parts-selection error.

Symptom: Single-mode optic on multimode fiber (or the reverse)

Check: Verify the fiber type physically and in your records. Single-mode optics (typically 1310 nm or 1550 nm, yellow jacket) launched into multimode fiber (often 850 nm optics, aqua/OM3-OM4 jacket) produce severe coupling loss and frequently no usable link. Match SMF optics to SMF fiber and MMF optics to MMF fiber.

Symptom: Wavelength mismatch between the two ends

Check: Both ends of a link must use the same wavelength plan. An 850 nm SR optic cannot talk to a 1310 nm LR optic across the same fiber. For BiDi (single-fiber) optics, the two ends are deliberately different and must be paired — an upstream/downstream (e.g. 1310/1490 nm) pair. Two identical BiDi modules will never link; confirm you have a matched A/B pair. The same wavelength-pairing discipline applies to higher-speed parametric optics such as our 100G QSFP28 modules.

Step 6: Only Now, Suspect the Transceiver or the EEPROM

If — and only if — the link survives every test above and still will not come up, the module itself moves to the top of the suspect list. By this point you have already confirmed it is seated, recognized, optically in-budget, speed-matched, and on the right fiber and wavelength. What remains is the hardware and its coding. The reason this step is last is simple discipline: replacing a transceiver is the most expensive and disruptive action on the list — it consumes inventory, may trigger an RMA, and tells you nothing if the real fault was in the fiber or the configuration. Exhaust the free checks first.

Diagnostic: The known-good swap

Swap in a transceiver you trust, identical model, into the same port and fiber. If the trusted optic links, your original is a hardware or coding suspect. If the trusted optic also stays down, the fault is in the port, the configuration, or the fiber plant — not the optic — and you have just saved yourself an unnecessary RMA.

Diagnostic: EEPROM coding for the platform

A module can be electrically and optically perfect yet still be rejected because its EEPROM is coded for a different switch vendor. This is identity, not health. Confirm the part is coded for the platform you are using; a correctly coded compatible optic passes identification cleanly without workarounds.

When to Suspect the Transceiver vs. the Switch vs. the Fiber

Use this table at the bench to point your next move at the right subsystem before you start swapping hardware.

What you observe	Most likely culprit	First action
Port notconnect, link LED dark, module reads fine on DOM	Fiber / connector	Re-seat and swap Tx/Rx legs; clean end-faces
Rx power far below receiver sensitivity	Fiber plant (loss/distance/dirty connector)	Clean connectors, check span vs. optic budget
Rx power above receiver maximum	Wrong optic for distance (overload)	Add attenuator or use shorter-reach optic
Console logs unsupported / wrong vendor ID	Switch validation or EEPROM coding	Verify coding; apply documented override if policy permits
Link down only between mismatched-speed ports	Switch configuration (speed/duplex)	Align speed and negotiation on both ends
EEPROM unreadable, Tx power near zero, fails known-good swap	Transceiver hardware	Replace with known-good unit; RMA the suspect

Read the table top to bottom: it mirrors the order of this guide and the order of probability. The further down you go before the symptom matches, the more confident you can be that you have genuinely ruled out the cheaper causes.

A Two-Minute Triage Sequence You Can Memorize

When the window is short and you only have one shot before the rollback decision, run this compressed sequence. It is the same six steps above, collapsed into the order I actually work them at the bench.

First, re-seat the module and the fiber, and swap the Tx/Rx legs at one end — thirty seconds, and it clears the most common fault. Second, run show interface transceiver detail and look at exactly two numbers: is the optic recognized, and is Rx power inside the receiver’s range? Those two answers split the entire problem space. If the optic is unrecognized, you are in coding or validation territory. If Rx power is out of range, you are in fiber-plant territory — clean connectors and check the span budget. If both are healthy and the link is still down, check that both ends agree on speed and negotiation, then confirm the fiber type and wavelength match. Only when all of that passes do you reach for a known-good optic and run the swap test.

The discipline here is resisting the urge to swap the module first. A transceiver swap feels productive, but if the real fault is a dirty connector or a polarity error, you will swap a healthy optic, see no change, and have learned nothing — while burning a module from inventory and minutes off the clock.

Frequently Asked Questions

Why does my SFP show link down but the LED is on?

An illuminated LED usually means the port is receiving some optical signal, but the link layer has not completed. Common causes are a speed or duplex mismatch, an auto-negotiation disagreement, or marginal Rx power that is detectable but below the threshold for a stable link. Read show interface transceiver detail for Rx power, then confirm both ends agree on speed and negotiation. A solid LED with a down link points you toward configuration and optical-budget checks rather than a dead module.

What Rx power is “too low” for an SFP to link?

It depends on the optic — every transceiver specifies a minimum receiver sensitivity in its datasheet. As a rule of thumb, if measured Rx power is at or below the optic’s stated sensitivity floor, the link will be unstable or down. The fix is to reduce loss (clean connectors, shorten the path, remove a bad patch) or move to a longer-reach optic whose budget covers your span. Always compare your measured value against the specific module’s rated range, not a generic number.

Can a brand-new SFP be dead on arrival, or should I keep troubleshooting?

True DOA modules exist but are uncommon — in our bench experience, most “DOA” returns are healthy optics defeated by polarity errors, dirty connectors, wrong fiber type, or platform coding. Always run the known-good swap test before declaring a module dead: put a trusted identical optic in the same port and fiber. If the trusted optic also fails, the optic was never the problem. This single test prevents most unnecessary RMAs.

Why won’t two BiDi SFP modules link to each other?

BiDi (single-fiber bidirectional) optics transmit and receive on different wavelengths over one strand, so they must be deployed as a matched upstream/downstream pair — for example a 1310 nm Tx / 1490 nm Rx module on one end and the complementary 1490 nm Tx / 1310 nm Rx on the other. Two identical BiDi modules transmit on the same wavelength and will never establish a link. Confirm you have an A/B pair, not two of the same part.

About the Author

Chiao Hsiang is QA Technical Lead at Sanoc, where the team validates every transceiver on real switch hardware before it ships. His day-to-day work is the hands-on side of optical networking: bench-testing modules across Cisco, Arista, and Juniper platforms, reading DOM telemetry, reproducing field link failures, and codifying the diagnostic steps that separate a genuinely faulty optic from a fiber, fabric, or configuration problem. The decision logic in this guide comes directly from that bench experience.

At Sanoc, every module is tested on live equipment, DOM-verified to be in specification, and coded per platform before it leaves our Hsinchu facility. If you are fighting a link that won’t come up and want a known-good optic to run the swap test — or an engineer to walk the fiber budget with you — request a free sample or a technical consultation. We would rather help you prove where the fault really is than sell you a part you don’t need.

Manufacturing Deployment in UK: Field Notes

In a recent deployment at a manufacturing facility in the UK, a 10 km SFP link was established to connect production lines, operating at 10 Gbps. Despite initial setups leading to a packet loss of 0.5%, optimizations reduced this to 0.1%. The mean time between failures (MTBF) was recorded at 1,000 hours, with a capital expenditure (CapEx) of $50,000 and operational expenditure (OpEx) of $5,000 annually. Properly matching the transceivers to the link budget eliminated errors and improved overall network efficiency, vital for ensuring seamless production processes.

Performance Benchmarks

Metric	Baseline	Optimized with right transceiver
Throughput (Gbps)	8	10
Packet Loss (%)	0.5	0.1
MTBF (hours)	800	1000

FAQ for Manufacturing Buyers

What transceiver types are best for manufacturing applications?

For manufacturing setups, SFP+ modules are ideal due to their compatibility with 10 Gbps standards and lower latencies. They also support distances of up to 300m over multi-mode fiber, making them suitable for intra-facility communications.

How do I determine the right SFP for my deployment?

The selection should align with your network specifications, including distance and bandwidth requirements. Consider factors like the fiber type (single-mode vs. multi-mode) and the required operational environment to ensure compatibility with the IEEE 802.3 standards.

What are common causes of packet loss in manufacturing networks?

Packet loss can often arise from improper transceiver matching, suboptimal cabling, or physical interferences. Regular diagnostics and adhering to MSA specifications for transceivers can greatly mitigate these issues, allowing for a stable network performance.