Physical path
Confirm installation, polarity, routing and cleanliness.
Steps 01, 04 and 05NRCube Deployment & Qualification Guide
Troubleshooting a Link That Does Not Come Up
A controlled method for isolating physical, optical, platform, configuration and service-layer causes without losing the original evidence.
Start at the bottom of the stack
The transceiver is one possible cause—not the default conclusion.
A link depends on the installed optics, fiber path, platform acceptance, port configuration and protocol operation. Effective troubleshooting begins at the physical layer and moves upward only after each lower layer is understood.
The objective is not merely to make the interface turn green. It is to identify, record and correct the actual cause so the same failure is less likely to recur.
Diagnostic model
Four phases. Twelve controlled checks.
Follow the evidence rather than jumping between unrelated changes.
Optical evidence
Use diagnostics and power measurements in context.
Steps 03 and 06Platform and configuration
Validate support, logs, speed, FEC and controlled substitution.
Steps 02, 07, 08 and 09Network and service
Move upward only after the physical link is stable.
Steps 10, 11 and 12Troubleshooting process
Work through the link in a documented sequence.
Some investigations will resolve before Step 12. Preserve the same sequence and evidence discipline.
Physical path
Confirm the physical link
Verify the installed product and topology before reviewing software.
- Correct transceiver and intended port
- Module fully seated
- Fiber connected to the intended endpoints
- No visible connector or cable damage
- Correct route and acceptable bend radius
Platform
Verify platform compatibility
A module can physically fit while remaining unsupported in the selected port mode.
- Platform and software support
- Port type and configured speed
- Required coding profile
- Supported optical family
- Native or breakout operating mode
Optical evidence
Check DOM/DDM
Once the module is detected, compare diagnostics at both endpoints.
- Temperature and supply voltage
- Laser bias current
- Transmit optical power
- Receive optical power
- Warning and alarm thresholds
Physical path
Validate polarity and fiber path
Confirm that every lane reaches the intended receiver through the full channel.
- TX-to-RX alignment
- MPO polarity and cassette method
- Patch-panel and cross-connect mapping
- Breakout orientation and lane mapping
- End-to-end fiber continuity
Physical path
Clean and inspect connectors
Contamination is common and may not be visible without appropriate inspection.
- LC and MPO end faces
- Patch cords and trunk interfaces
- Dust or oil contamination
- Scratches and physical damage
- Clean, reconnect and retest
Optical evidence
Review optical power levels
Compare measured TX and RX against the exact product limits and expected channel budget.
- Transmit-power range
- Receive-power range
- Total expected path loss
- Receiver overload limit
- Operating margin
Configuration
Verify speed and FEC
Modern Ethernet links require both ends to agree on the relevant operating parameters.
- Configured port speed
- Autonegotiation behavior
- FEC mode
- Electrical lane configuration
- Native or breakout mode
Platform
Check platform logs
Use messages from both endpoints to correlate detection, alarms and link events.
- Unsupported-transceiver messages
- Authentication or coding failures
- Loss-of-signal events
- Link flapping and excessive errors
- FEC and optical threshold alarms
Isolation
Substitute known-good components
When uncertainty remains, replace one variable at a time and record the outcome.
- Local optic
- Patch cord
- Fiber path
- Remote optic
- Remote port
Network
Verify Layer 2 and Layer 3
After Layer 1 is stable, verify the network configuration that uses the link.
- VLAN and trunk configuration
- Port-channel membership
- IP addressing
- Routing adjacencies
- MTU consistency
Network
Verify protocol operation
Confirm the relevant control plane or storage-fabric state.
- OSPF neighbor, area and interface state
- BGP peer, ASN and route exchange
- EVPN control plane, VTEP reachability and routes
- Storage link initialization and port login
- Fabric services where applicable
Service
Validate end-to-end service
A protocol up-state does not by itself prove that the required service is healthy.
- Packet loss
- Latency
- Interface and application errors
- Throughput
- Application connectivity
Power-reading examples
Values require the exact product specification.
The following numbers illustrate reasoning only. They are not universal pass/fail thresholds.
TX0 dBm
→RX−3 dBm
Compare the 3 dB difference with the expected route loss and operating margin.
TX0 dBm
→RX−19 dBm
Investigate route length, attenuation, connectors, patching and whether the selected optical family is suitable.
Controlled substitution
Change one variable at a time.
A known-good component is useful only when the original condition, replacement and outcome are recorded.
Local optic↓Patch cord↓Fiber path↓Remote optic↓Remote port
Do not swap several components together.
The link may recover, but the actual cause—and confidence in the remaining components—will be lost.
End-to-end flow
Move upward only when the preceding layer is stable.
Physical installation→Platform validation→DOM/DDM→Fiber path→Cleaning→Optical power→Speed / FEC→Platform logs→Known-good substitution→Layer 2→Layer 3→Protocols→Service
NRCube review guidance
Keep every observation and unknown visible.
Capture the original state before making changes. A documented sequence is often the fastest route to a permanent root-cause finding.
Restore service—but also preserve enough evidence to explain why it failed.
Record during the investigation
- Both endpoint platforms and ports
- Installed product identities
- DOM readings and thresholds
- Port speed, mode and FEC
- Fiber route and polarity
- Connector cleaning or changes
- Every component substitution
- Exact platform log messages
- Configuration changes
- Final root cause and corrective action
Troubleshooting summary
A reliable diagnosis follows the stack and preserves evidence.
Physical layer↓Optical layer↓DOM/DDM↓Platform↓Configuration↓Protocols↓Service
The investigation is complete when the link is stable, the service is validated and the actual cause is documented.