RouterOS x86 – SFP+ DOM information missing on Intel 82599ES

Hardware 3rd party hardware (x86/amd64/arm64)
1

Hardware: Intel 82599ES dual-port SFP+ NIC (PCI ID 8086:10fb)
RouterOS: Latest Long-term release

Issue:

The 10 Gbps link works correctly, but RouterOS does not expose any SFP+ module information or DOM readings in /interface ethernet monitor.

The same hardware and SFP+ module expose DOM correctly under OpenWrt, suggesting a RouterOS x86 driver or reporting limitation.

Expected behavior:

RouterOS should detect the SFP+ module and expose available diagnostics, including vendor, temperature, voltage, TX bias, TX power, and RX power.

Actual behavior:

The interface reports link-ok at 10Gbps, but no SFP-related fields are available.

Please confirm whether DOM/EEPROM access is supported for the Intel 82599ES on RouterOS x86 and whether this is a known limitation or a bug.

Thank you.

2

Best to create a support ticket.

This is at first a USER forum. Users helping out other users.

3

@jmthill

Is it a problem of NIC or SFP+ module? We do not even know if SFP+ module is officialy supported by ROS.
What about readings of other SFP+ modules used in the same NIC or same module used in another NIC model?

4

Everything works, but routeros sees the port as 10g-base-t when in reality its a 10g-base-sr:

/interface/ethernet/monitor ether1 once
name: ether1
status: link-ok
auto-negotiation: done
rate: 10Gbps
full-duplex: yes
tx-flow-control: no
rx-flow-control: no
supported: 1G-baseT-full
10G-baseT
advertising: 1G-baseT-full
10G-baseT
link-partner-advertising:
default-cable-setting: standard

In bare linux i see all the DOM info and also that its a 10g-base-sr

The sfp+ i tested are intel and also cisco branded.

My main question is: Is it supposed to be possible to see more information in bare metal x86 routeros?

Thanks

Michel

5

I did not state: it does not work.

My question is if the same NIC reports other SFP+ module wrong/incomplete too or the same module does work with other NIC properly.

BTW: bare metal ROS is not the best way to go, MT preferes using CHR VM for x86 platform

6

Nic and both sfp work fine in linux including DOM.

Is routeros supposed to expose those things in x86 version?

I really just want to know if its normal behavior or not.

7

ROS is not a "normal Linux" box. It's heavily patched so we, straight forum users, do not know the answer.

The best way is to open a ticket at the support system to get an answer for such details directly from MT.

8

Hey Michel, I think you two are kinda talking past each other. BartoszP wasn’t saying anything’s broken, he just wanted to rule out the NIC vs the module, and you’ve already done that since both show full DOM under plain Linux.

The thing is, like BartoszP said, RouterOS isn’t really “Linux” in the way you’re used to. Yeah, there’s a Linux kernel under the hood, but MikroTik builds their own kernel with whatever drivers they choose to include, often patched or older versions. And everything on top of that is their own stuff. There’s no ethtool, no standard userspace, nothing. So the fact that it works in Debian or OpenWrt doesn’t really tell you much about what RouterOS will do with the same card.

For DOM to show up in RouterOS two things have to line up: the driver they ship has to support reading the module EEPROM, and RouterOS itself has to actually ask for it and show it in "/interface ethernet monitor". My guess is the second part is where it falls apart. Those SFP fields are built around MikroTik’s own hardware where they know exactly which ports are SFP cages. On x86 the 82599 just looks like a regular ethernet port to RouterOS, which is also why it says 10G-baseT instead of SR.

If DOM monitoring actually matters to you, one option is to go the CHR route BartoszP mentioned. Run something like Proxmox on the box and let the host own the 82599, then hand it to CHR as virtio or an SR-IOV VF (the 82599 supports that). You’d still not see DOM inside RouterOS, but you’d have full ethtool -m on the host and could monitor the optics from there. Just don’t do PCI passthrough, then RouterOS owns the card again and you’re back where you started. Also keep in mind you’ll need a paid CHR license to get 10G.

I haven’t seen MikroTik document this officially though, so like BartoszP said, a support ticket is the way to go if you want a definite answer. If it turns out to be unsupported, it doesn’t hurt to ask for it as a feature request.

9

Thank you very much for the answers. But running virtualized just to be able to use ethtool is no viable solution for me.

I will open a support ticket, and ask.