Two MikroTiks, one fibre pair, and the wrong end of both cables
A practical fibre troubleshooting story: we investigated optical budgets, modules, speed and configuration before remembering that one transmitter must meet the other receiver.
Scope
For administrators linking two MikroTik routers with ordinary duplex LC fibre and matching SFP or SFP+ modules. BiDi single-fibre optics and MPO/MTP trunks use different polarity rules and are called out separately.
Start with the situation, not the slogan
An incident rarely arrives with a neat label. It arrives as a forwarded screenshot, a worried telephone call, or a monitoring alert written by a machine with no sense of occasion. In this case “Two MikroTiks, one fibre pair, and the wrong end of both cables” is the working heading, but the label is only a starting hypothesis. The useful work is to establish what happened, what can still happen, and which decision cannot safely wait.
Keep three clocks in view: the attacker’s opportunity, the business interruption, and the lifetime of the evidence. They do not run at the same speed. A hasty change may interrupt access but erase context; a perfect investigation conducted at geological pace may leave the organisation exposed. Good response is the slightly unglamorous art of making the next reversible decision with the best evidence currently available.
A duplex optical link uses one strand in each direction. Unlike copper Ethernet patching, a pair that is presented in the same orientation at both ends may connect transmitter to transmitter and receiver to receiver. The link remains dark while every expensive component looks suspicious.
Composite scenario
How this usually reaches the desk
Imagine the report begins with this observation: “Both routers detect their SFP modules, yet the interface stays down and one or both ends report receive loss or no meaningful receive power.” A second check returns another clue: “The modules, wavelength, fibre type, connector and supported link rate appear compatible, but swapping configuration does not create light at the receiver.” Neither fact alone tells the whole story. Together they justify a documented incident, a defined owner, and a deliberate containment decision. This is where a timeline beats a collection of heroic memories; memory is an excellent storyteller and a dreadful audit log.
This scenario combines common operational patterns; it is not presented as a report of one named incident.
What to look for
Begin with preserved, comparable evidence. One signal is rarely proof; use independent observations and a reliable timeline before declaring scope or intent.
Both routers detect their SFP modules, yet the interface stays down and one or both ends report receive loss or no meaningful receive power.
Record the exact time, source, identity, system and time zone. Compare it with a known-good baseline and with what the user or service owner expected. A surprising event is a lead, not a conviction.
The modules, wavelength, fibre type, connector and supported link rate appear compatible, but swapping configuration does not create light at the receiver.
Look for the control-plane event that made the visible activity possible: a changed credential, permission, rule, route, token or trusted device. Persistence often looks administrative because, technically, it is.
Transmit power is present at each module while received power is absent or below the module’s range—an excellent clue that the photons are attending the wrong meeting.
Correlate the report with independent telemetry before deciding scope. User testimony, identity logs, endpoint evidence and service audit records are strongest when they agree on sequence rather than merely on mood.
Field story
We investigated the photons. We should have followed the cables.
The job sounded civilised: connect two MikroTik routers with a duplex fibre run. Insert matching optics, connect the LC pair, configure the interfaces, observe link, go home with the particular satisfaction reserved for infrastructure that blinks green on the first attempt.
It did not blink green. Both routers recognised their SFP modules. The fibre was new. The optics were respectable. Configuration was inspected, re-inspected and eventually admired from several angles. Because the link was short, suspicion fell on transmit power: perhaps the receivers were being overwhelmed. This was technically plausible and therefore dangerously attractive.
We compared module specifications, changed settings, swapped modules and discussed optical budgets with the solemnity of people who would prefer the fault to require a spreadsheet. A few days later, the embarrassingly simple model finally returned: ordinary duplex fibre has a separate transmit strand and receive strand. Router A’s transmitter must arrive at Router B’s receiver, and Router B’s transmitter must arrive at Router A’s receiver.
The duplex pair had preserved the same orientation through both ends, leaving TX facing TX and RX facing RX. Each transmitter was producing light. Neither receiver was receiving the other transmitter. We reversed the two LC connectors at one end only. Link came up. The elaborate theory about excessive optical power retired without a leaving speech.
Ethernet over copper hides the crossing inside standards and electronics. A basic duplex optical path is less diplomatic: TX must physically reach RX.
This is a composite field account, but the lesson is exact. Start with the physical signal path. Expensive hypotheses remain available after the two fibres are mapped.
RouterOS evidence
Ask both MikroTiks what the optics can see
Run the monitor command on each router, replacing the interface name with the actual SFP port:
/interface ethernet monitor sfp-sfpplus1 onceRouterOS can expose module presence, connector and wavelength information, supported modes, temperature, TX bias, transmitted optical power, received optical power, receive loss and transmit fault when the module supports digital diagnostics. Place both outputs side by side and save them before swapping anything.
name: sfp-sfpplus1
status: no-link
sfp-module-present: yes
sfp-rx-loss: yes
sfp-tx-fault: no
sfp-wavelength: 1310nm
sfp-temperature: 36C
sfp-tx-power: -3.1dBm
sfp-rx-power: -40.0dBmThis illustrative output says the module is installed and reports no transmit fault. It says the local transmitter claims roughly -3.1 dBm, while the receiver sees essentially no usable light and raises receive loss. Exact absent-light values vary by module. The important comparison is not the number alone; it is the reading against that module’s documented receive range and the opposite end’s behaviour.
sfp-module-presentConfirms the router can read a module. It does not prove compatible speed, wavelength, fibre or polarity.
sfp-tx-faultReports a transmitter fault when the module provides it. no is useful, but still not proof that light reaches the far end.
sfp-rx-lossIndicates loss of received signal. On both ends, with TX power present, this should move polarity and continuity to the front of the queue.
sfp-tx-powerThe module’s transmitted power in dBm. Compare it with the vendor’s TX range; do not compare two unrelated optics and crown the larger-looking number.
sfp-rx-powerPower arriving at the receiver. It must fall between the module’s receiver sensitivity and overload limits with reasonable margin.
sfp-wavelengthHelps confirm that the modules and path are intended to work together. Matching duplex optics generally use the same wavelength; a BiDi pair deliberately uses complementary wavelengths.
The strong-signal suspicion
Could TX really be too strong?
Yes. A powerful long-reach single-mode optic across a very short, low-loss path can exceed the receiver’s maximum input. The proper test is an optical budget using the exact module datasheets: minimum and maximum transmitter output, receiver sensitivity, receiver overload, fibre loss, connectors, splices and any attenuator. Do not infer overload merely because the distance feels short.
dBm is logarithmic and commonly negative at these levels. -3 dBm is stronger than -20 dBm; zero is not “no signal”. If the receiver reports a believable value that is stronger than its specified overload threshold, stop and fit the correct optic or a designed attenuator. If the receiver reports loss or an implausibly low floor while the far transmitter reports normal TX power, the first questions are continuity, cleaning, polarity, wavelength and module compatibility.
Step by step
A troubleshooting order that respects the price of an afternoon
- Make an inventory.Record router models, RouterOS versions, interface names, module manufacturer and part number, wavelength, supported rate, single-mode or multimode fibre, connector type, distance, patch panels and couplers. Photograph labels, not laser apertures.
- Check compatibility.Both ends must support the intended rate and optical standard. Ordinary duplex modules generally match like for like. BiDi modules are a complementary pair—one transmits the wavelength the other receives—and use one strand, so do not apply this duplex-pair swap ritual to them.
- Read both monitors.Save module-present, TX fault, RX loss, wavelength, TX power, RX power, supported modes, rate and link status. Note which values are missing because not every module exposes every diagnostic.
- Reduce the path.Use known-good compatible patch leads and, where practical, temporarily bypass couplers and patch panels. Inspect and clean connectors with proper fibre tools. Keep dust caps on unused ports.
- Map TX to RX.Identify the two strands. At one end only, exchange the A and B connectors in the duplex clip or adapter so the local TX lands on the remote RX. If you swap both ends, you preserve the mistake with impressive symmetry.
- Then check rate and configuration.Once meaningful RX power exists, compare advertised and supported modes, autonegotiation requirements and explicitly configured rates for the exact routers and optics. Do not randomly toggle settings without recording the before state and rollback.
- Prove bidirectional service.Confirm link on both routers, intended rate and duplex, management and test traffic in each direction, stable RX power, interface errors and link-down counters. Leave the test running long enough to catch a flap.
- Label the result.Document strand A and B, TX/RX at both ends, module part numbers and known-good optical levels. The next engineer should find labels, not folklore.
Conclusion
The two-minute fix required two days of education
The link was not defeated by RouterOS, attenuation, receiver overload or an exotic incompatibility. It was defeated by geometry. Both transmitters were speaking into the transmitter strands; both receivers were listening to each other. Reversing the duplex pair at one end connected A TX to B RX and B TX to A RX, exactly as the link required.
The useful lesson is not merely “swap the fibres”. Blind swapping can hide a dirty connector, wrong wavelength, unsupported optic or genuine overload. The better sequence is: inventory, inspect diagnostics at both ends, establish whether light reaches each receiver, map the strands, cross TX to RX once, then verify rate, traffic, errors and stability.
And yes, a signal can be too strong. Measure it against the module specification. But when both ends confidently transmit and neither receives, allow the humble possibility that every photon is doing precisely what the cabling told it to do.
Working examples
Run it, read it, decide what changes
These examples use documentation addresses, test identities and bounded targets. Replace placeholders only inside systems you own or are explicitly authorised to operate. Read the expected result and next action before running the command; a successful command is evidence, not yet a conclusion.
Inventory exposed RouterOS services
- Prerequisites
- An authenticated administrator session from the trusted LAN.
/ip service print detail
/ip firewall filter print stats
/ip firewall nat print detail where action=dst-natRouterOS lists management services, firewall counters and destination NAT rules.
A disabled service can still be replaced by a container or forwarded host. An address restriction is only as trustworthy as the route and firewall around it.
Disable unused services, restrict management to a trusted network or VPN, and test from both allowed and external paths.
Export configuration without embedded secrets
- Prerequisites
- A secure destination and awareness that exports still contain sensitive network details.
/export terse hide-sensitive file=before-hardening
/file print where name~"before-hardening"A `.rsc` export appears in Files with sensitive values hidden where RouterOS supports it.
`hide-sensitive` does not make the export public-safe; addresses, usernames and architecture remain valuable.
Transfer it securely, hash and protect it, then take a tested binary backup according to the device recovery plan.
Watch interface and firewall evidence after a change
- Prerequisites
- A named interface and a documented expected rule.
/interface ethernet monitor ether1 once
/ip firewall filter print stats where chain=input
/log print where topics~"firewall"The interface state, rule counters and relevant logs are displayed.
A zero counter may mean no test traffic, wrong rule order or fast-path behaviour; it is not proof of blocking.
Generate one authorised allowed test and one denied external test, then verify the expected counters and logs.
What to do
Read the whole sequence before starting. Several workstreams may run in parallel, but their evidence, authority and expected outcomes still need to be explicit. Every step below points back to a concrete example; use the example as implementation evidence, not as permission to operate outside the stated scope.
Operational judgement
Containment and recovery are different verbs. Containment limits the next harmful action; recovery returns a service to trustworthy operation. Between them sits eradication: removing the access path and persistence that would make the freshly restored service merely a cleaner target. For MikroTik, Fibre and SFP, keep those decisions separate in the timeline even if a small team performs them minutes apart.
Communication is also a control. Tell affected people what is known, what remains uncertain, what they must do and when the next update will arrive. Avoid both melodrama and false reassurance. “We are investigating” is useful only when followed by an owner and a time. The goal is to reduce secondary harm without teaching a possible attacker exactly what the team has discovered.
Handover
Make the result useful to the next person
Maintain two views of the incident. The working timeline should contain detailed events, evidence locations, hypotheses and technical actions. The stakeholder update should contain confirmed impact, current containment, material uncertainty, decisions required and the next reporting time. Do not copy speculative indicators into executive statements. Equally, do not polish away uncertainty merely because it looks untidy. Both records should use absolute times with a declared time zone and should identify the source of each important fact.
At shift change, hand over the current scope, trusted administration path, preservation status, active controls, failed actions, business priorities and the next three decisions. Read back the most consequential assumptions. For this case, ensure the record begins with “Record both router models, RouterOS versions, SFP part numbers, wavelengths, fibre type, connector, link rate, distance, and the vendor’s transmit and receive limits.” and does not finish until the team has addressed “After link-up, confirm negotiated rate and duplex, traffic in both directions, errors and link flaps; label the pair and save the optical readings as the known-good baseline.” A concise, accurate handover prevents the incoming team from repeating disruptive work or mistaking a quiet telemetry gap for successful containment.
Validate before you close
Both interfaces must report link-up at the intended rate, each receiver must show power within its module’s specified range, traffic and management must work in both directions, error counters must remain stable, and the final fibre polarity and optical readings must be documented.
Capture the test, the expected result and the observed result. Where a person or business owner must accept restored service, name them in the record. A green dashboard can confirm that a component is answering; it cannot confirm that invoices, identities or restored data are trustworthy.
Finish with a compact closure note: the original trigger, confirmed scope, evidence retained, controls changed, tests passed, known gaps, residual risk, and the people responsible for the remaining work. Schedule a review while the timeline is still fresh enough to challenge. The purpose is not to find a person to blame; computers already perform blame with admirable efficiency. The purpose is to make the next response faster, safer and less dependent on one person remembering where the useful log was hidden.
Common mistakes
- Resetting systems before preserving volatile evidence and audit logs.
- Treating the first visible symptom as the complete scope of the incident.
- Restoring service without verifying that the attacker’s access path is closed.
These errors usually come from haste, unclear ownership or misplaced confidence. Build the safeguard into the runbook: a required evidence field, a second-person review, a rollback test or a specific exit criterion.
Questions people ask when the clock is running
Does one suspicious event prove compromise?
No. Treat “Both routers detect their SFP modules, yet the interface stays down and one or both ends report receive loss or no meaningful receive power.” as a reason to investigate and preserve evidence. Confidence should rise when independent identity, service, endpoint or network records support the same sequence.
Should we reset everything immediately?
Reset or revoke what the evidence and risk justify, but preserve the state you will need to understand the incident. Broad, undocumented resets can interrupt the attacker, the business and the investigation in one impressively efficient stroke.
When can the incident be closed?
Both interfaces must report link-up at the intended rate, each receiver must show power within its module’s specified range, traffic and management must work in both directions, error counters must remain stable, and the final fibre polarity and optical readings must be documented. Closure also requires named owners for residual risk and follow-up work; “it seems quiet now” is an observation, not an exit criterion.
Safety boundary
Use these steps only on systems you own or are explicitly authorised to assess. Preserve evidence, follow your organisation’s legal and regulatory obligations, and prefer reversible actions when the situation is not yet understood.
Primary references
- Ethernet and SFP monitoringMikroTik Documentation
- Securing Your RouterMikroTik Documentation
Editorial status: first edition. Review the linked vendor documentation for product- and version-specific changes before acting.