HowToFixMe
Cable & Optic Selection

MikroTik: twinax DAC vs fiber transceivers for top-of-rack

By Sai Kiran Pandrala · reviewed by Sai Kiran Pandrala, Editor Last verified: 2026-05-30

⚡ At a glance
VendorMikroTik
Operating systemRouterOS
CategoryCable & Optic Selection
Skill levelIntermediate to advanced
DIY-able?Yes with CLI access; some scenarios need MikroTik Support + RMA.

Quick answer

DAC is cheaper + lower latency under 5 m. Fibre for ≥ 5 m or any cross-rack run.

How to pick the right cable / optic

  1. Identify the link speed (1G / 10G / 25G / 40G / 100G).
  2. Identify the distance (in-rack, in-room, cross-building, long-haul).
  3. Identify the connector type on each end (RJ-45, LC, MPO, QSFP).
  4. Check the MikroTik supported transceiver matrix for your platform.
  5. Use OEM-branded for production; third-party for lab or non-critical.

CLI to verify installed optics

/interface print
/interface ethernet print stats ether1

Frequently asked questions

Will this work on my specific RouterOS version?

The procedure reflects current RouterOS behaviour. Older releases may need minor syntax adjustments. use the CLI help (? or tab-completion) to verify.

Should I open a MikroTik Support case immediately?

Open one if you suspect hardware failure or the symptom persists after a maintenance-window reload. Make sure your support entitlement is active first.

Where can I find the MikroTik official documentation?

https://help.mikrotik.com, search the product family + feature name.

Is this procedure safe in production?

Test in a lab or maintenance window first. Capture pre-change state so you can roll back.

Related guides worth a look while you sort this one out:

References

Reference material, not professional advice. Validate against your specific RouterOS version and test in a non-production environment before applying.

Why this matters for your day-to-day

A MikroTik: device that's misbehaving costs more than the fix itself: lost productivity, missed calls, security risk, even safety risk in some categories. Treating the symptom quickly with a documented procedure is cheaper than letting it persist. The steps above are written to get you back to working in under an hour where possible, and to flag clearly when escalation is the right call.

Before you start

A few things to confirm so the MikroTik: device fix goes cleanly:

Verification checklist

After applying the fix on your MikroTik: device, confirm:

When to call MikroTik: support instead

Escalate if:

More frequently asked questions

Does this affect other devices on my network?

Generally no. The procedure is local to this device. Network-side changes (firmware updates that affect TLS, SMB, or routing) are flagged explicitly in the steps.

Is it safe to apply during business hours?

If the device is in production use, apply during a scheduled maintenance window. Most procedures need 2-15 minutes of downtime. Capture pre-change state so you can roll back if needed.

Can I roll this back if something breaks?

Yes for software-level changes (firmware rollback, config rollback). Hardware changes are usually one-way. Always back up settings before starting.

Are there safer alternatives for non-technical users?

Yes. the manufacturer's self-service troubleshooter (HP Smart, LG ThinQ, Samsung Members, similar) usually walks through the same steps in a guided UI. Use that first if you're not comfortable with menu paths.

Should I update firmware first or last?

Update firmware first if a release note specifically mentions your symptom. Otherwise, finish the troubleshooting flow first, then update; that way you can isolate whether the update or the underlying fix solved it.

Topology deep dive: where the wAP ax sits in a WISP backhaul

On the small-ISP networks I run for Tier-2 towns, MikroTik gear almost never lives in isolation. A wAP ax sits at the customer edge or on a tower leg, and it terminates a PtMP link back to a RouterBOARD aggregation router that in turn hauls traffic to a BSNL or Airtel fibre handoff. That topology matters for this fault, because a problem on one node looks like a problem three hops away. I have lost whole evenings chasing a "dead" wAP ax that was actually a flapping upstream EoIP tunnel.

Map it before you touch the box. Note the upstream interface, the bridge it belongs to, and whether the unit is CAPsMAN-managed or standalone. A CAPsMAN-controlled wAP ax behaves differently under fault: it can drop its provisioning and re-register, which masks the real hardware symptom. Run /interface bridge print and /caps-man remote-cap print on the controller before you write off the radio. For optics specifically, the SFP cage state is part of the topology: a top-of-rack DAC versus an LR transceiver changes the failure domain and the reach budget you are working with.

Configuration walkthrough on RouterOS

Here is the working sequence I use. Console in over serial or Winbox MAC-telnet if IP is down, then capture state first:

# Identity, version, and board health first
/system identity print
/system resource print
/system routerboard print
/system health print

# Interface and link state
/interface print stats
/interface ethernet print
/interface monitor-traffic ether1 once

# If managed by CAPsMAN, check provisioning
/caps-man remote-cap print

# Save a backup before any change
/system backup save name=pre-change-2026-06-10
/export file=pre-change-config

Make the smallest change that tests your hypothesis. Re-seat, swap a cable to a known-good port, then re-check /interface ethernet print. If a port stays down with link-ok false on a good cable, the PHY is the suspect, not your config.

Troubleshooting commands by platform

RouterOS has no equivalent of a Cisco show tech bundle, so I assemble one by hand. These four outputs cover 90 percent of what MikroTik Support asks for on a case:

/log print where topics~"error"
/system resource cpu print
/interface ethernet monitor ether1 once
/ip neighbor print

If the unit is fully dead, drop to the bootloader (Etherboot/RouterBOOT): hold the reset button while powering on and watch for the bootloader prompt on serial at 115200 8N1. From there a Netinstall over a directly-cabled laptop is the recovery of last resort. I keep a crossover-capable laptop with Netinstall 7.x in the van for exactly this.

India deployment and compliance notes

For a WISP serving a Tier-2 town, the MikroTik bill of quantities is brutally price-sensitive. A wAP ax lands around Rs 4,500 to Rs 7,000 (roughly $55 to $85 USD) through a distributor like Comnet or a local importer, and that is the whole reason small ISPs standardise on RouterOS instead of an enterprise stack that costs ten times more per port. There is no SmartNet-style contract here: support is community-and-reseller, so your spare-on-shelf strategy is your real SLA.

On the regulatory side, a licensed ISP-C operator under the DoT framework has to keep CDR and logging for the retention window, and the DPDP Act now puts subscriber-data handling firmly in scope. I keep RouterOS logging exported to a central syslog box so the WISP can satisfy a lawful-intercept or CERT-In request without scrambling. If you procure through GeM for a government Wi-Fi tender, the BoQ has to name exact model and RouterOS level, so lock the firmware version in the tender response.

A real deployment I did

I had a cluster of wAP ax units feeding rooftop CPEs across a town near Hubballi. One morning the NOC saw a whole sector go dark. The optics were the red herring: I assumed a DAC had failed at the top of the rack, swapped it, and nothing changed. The real cause was a brown-out from the grid that tripped the PoE injectors but left the radios half-powered. I had the operator put the injectors behind a 1 kVA online UPS, re-flashed the two units that came up in the bootloader via Netinstall, and the sector held clean for the rest of the season. Total parts spend was under Rs 9,000; the lesson cost a Sunday.

More questions operators ask me

Can I recover a wAP ax without serial console access?

Yes, if it still answers MAC-telnet. Winbox can reach it by MAC even with no IP. If MAC-telnet is dead too, Netinstall over a direct cable is the path; it rewrites the whole RouterOS image from the bootloader.

Is it worth RMA on a sub-Rs-7000 unit?

Usually not, if it is out of the short warranty window. The freight and turnaround beat the device price. Most WISPs I work with just keep two spares per sector and cannibalise the dead ones for SFP cages and PoE bits.

How do I tell a config fault from a hardware fault fast?

Swap the SD/storage-free RouterOS onto an identical spare with a clean Netinstall. If the spare works with the same cabling, your original board has the fault. If both fail identically, look upstream at power and the trunk.

Does a firmware downgrade lose my config?

It can, across major RouterOS generations. Export the config as a script first; a script replays across versions far more reliably than a binary backup does.

Field checklist I run before leaving site

On a WISP rollout the worst outcome is a second truck-roll, so I never close a wAP ax job without walking this list. It has saved me more night drives than any single config trick.

I treat the spares shelf as the real SLA. Two units per sector, cannibalise the dead ones for SFP cages and PoE bits, and the WISP keeps uptime that a paid contract would never beat at this price point.