SFP+ port with RJ45 adapter will not pass traffic to bridge, why?

RouterOS General
1

I have a CCR2004. I’m trying to connect a laptop via a ethernet cable and a SFP+ to RJ45 adapter (S+RJ10).

(Maybe naively) I expected an SFP port with RJ45 adapter to behave the same as the native RJ45 Ethernet port… but after pulling my hair out for hours, I can confirm it does not.

Relevant configuration:

# 2026-02-03 22:34:46 by RouterOS 7.20.6
# model = CCR2004-1G-12S+2XS

/interface bridge
add frame-types=admit-only-vlan-tagged name=testBridge pvid=2 vlan-filtering=yes

/interface vlan
add interface=testBridge name=testVlan vlan-id=777

/interface bridge port
add bridge=testBridge frame-types=admit-only-untagged-and-priority-tagged interface=sfp-sfpplus3 pvid=777

add bridge=testBridge frame-types=admit-only-untagged-and-priority-tagged interface=ether1 pvid=777

/interface bridge vlan
add bridge=testBridge tagged=testBridge untagged=ether1,sfp-sfpplus3 vlan-ids=777

/ip address
add address=10.77.55.5/24 interface=testVlan network=10.77.55.0

(The rest of the config is more-or-less what came out of the box. There are no firewall rules blocking any traffic.)

Given all this, I’d expect ether1 and sfp-sfpplus3 to behave exactly the same.

And yet, when plugged into ether1, I can ping 10.77.55.5.

Plugged into sfp-sfpplus3:

PING 10.77.55.5 (10.77.55.5) 56(84) bytes of data.
From 10.77.55.4 icmp_seq=1 Destination Host Unreachable
ping: sendmsg: No route to host

Both sides claim the link is up (though only with auto-negotiation disabled, otherwise the link flip-flops).

Am I missing something obvious here? Should an SFP port with an RJ45 adapter not behave the same way a native RJ45 port does? Is this a RouterOS issue, HW compatibility issue, or some fundamental misunderstanding of how these adapters work?

FWIW, if configured as a WAN port, sfp-sfpplus3 and ether1 do behave the same - they both happily grab an IP via DHCP and pass traffic.

Thanks all!

RB5009 and 10Gtek ASF-10G2-T | Link failures
2

When you say “configured as a WAN port” you mean the ports do not belong to the testBridge bridge? Sounds like it could be a case where testBridge is hardware offloaded and the ports are software CPU based and the packets are not making it out of the switch chip to the interfaces.

3

Your config looks fine, and what you believe (that they should behave the same) is true.

Probably data is not making it through on your sfp to copper adapter.

Auto-negotiation should be enabled for these. Even if you have to force it manually, you have to force 10G. The sfp+ side of these converters speaks 10G, regardless of speed on the copper side, which is always auto-negotiated, irrespective of any setting on the device side.

1 Like
4

Thanks for the responses.

After spending more time configuring the router, I’ve come to the conclusion that the SFP ports are… temperamental.

I had a really hard time getting my Zyxel switch connected:

  • using a Mikrotik DAC, with auto-negotiation on, both sides play dead
  • with a different DAC, the link comes up - for about 30 seconds, then goes down again, repeat forever. Even if 10GBaseT is the only option allowlisted for auto-negotiation.
  • with auto-negotiation disabled and interface speed manually set to 10G, both DACs work.

So I guess SFP isn’t as plug-and-play as I’d hoped, and weird random quirks and incompatibilities are a fact of life. (Case in point - the release mechanism for the Mikrotik DAC doesn’t work on the Zyxel switch, to physically remove the cable it needs to be prodded just right with a small screwdriver or blade…)

When you say “configured as a WAN port” you mean the ports do not belong to the testBridge bridge?

Right.

Sounds like it could be a case where testBridge is hardware offloaded

I hadn’t thought about HW offloading, and another difference looking at the block diagram is that the copper port is connected to the CPU directly, while the SFPs go through a Marvel PIPE.

Still, I don’t understand how that would explain what I’m seeing.

Your config looks fine, and what you believe (that they should behave the same) is true.

Thanks. I’m glad I’m not completely crazy.

Probably data is not making it through on your sfp to copper adapter.

It is when I’m using it as the WAN port. I’m inclined to believe the bridge config has nothing to do with it, and the transceiver module for whatever reason gets along with the modem, but not my laptop :person_shrugging:

5

SFP is not plug'n'play at all. Whatever some device allows with regard to "play" is a hack which may or may not work.

6

Oh wait - so the auto-negotiation settings under /interface ethernet are for the SFP+ module interface, not the actual wire link speed?!

Indeed - with the speed forced to 10G, it finally works! (With an actual wire speed of 1G). Thank you!!

I’m still confused why another setting worked with one peer (modem) but not another (laptop), or why auto-negotiate would result in unstable link behavior, especially since both switch and SFP+ module are Mikrotik.

mkx:

SFP is not plug'n'play at all.

Can confirm :laughing: I guess I’ve gotten lucky in the past

7

As often happens, I am confused.

The official Mikrotik stance is:
https://help.mikrotik.com/docs/spaces/ROS/pages/220233794/MikroTik+wired+interface+compatibility#MikroTikwiredinterfacecompatibility-S+RJ10

S+RJ10

Use these modules only in 10G SFP+ ports with auto-negotiation enabled, forced link speeds and configurable link speed advertisements are not supported. They will negotiate to correct duplex and highest possible rate

This experience shows that INSTEAD it can (or shouild?) be set with autonegotiation off and 10 G forced speed?

@mrfox Can you share the actual export of the settings that actually work in your case?

8

There isn't much to be confused about. The correct mode for these devices, as documented by Mikrotik, is auto. This will always result in linking at 10G on the sfp side. Due to bugs, sometimes this has to be forced. ("Bug" means that you shouldn't have to. It's probably version/device/arch dependent.)

@mrfox SFP's, as God intended, were mostly meant to serve as simple electrical-optical converters. For these, the set port speeds and the actual link speeds (and FEC) correspond one-to-one.

But a copper ethernet to sfp converter can't function this way, and instead has a much more complex internal construction. The sfp side acts as an optical transceiver would, while the copper side does everything a copper ethernet port should automatically.

A similar thing happens with integrated GPON modules, where an entire SoC, with its own Linuxy operating system, is embedded in an sfp.

In case of these, there is a disconnect between what happens on the sfp interface and what goes on with the external connection.

1 Like
9

This is what works for me:


/interface ethernet
set [ find default-name=sfp-sfpplus3 ] auto-negotiation=no speed=10G-baseT
10

Yeah, that makes sense. Thanks for spelling it out for me. I thought I was setting the wire speed (to 1G, since I only have a 1G NIC on my laptop) - it never occurred to me that this was the SFP interface speed.

It’s a bit annoying this doesn’t “just work”, especially between devices from the same brand. But it sure is nice to have such an amazing community to help debug things!

11

Maybe it is my English (though I doubt it), but if I read this:

Use these modules only in 10G SFP+ ports with auto-negotiation enabled , forced link speeds and configurable link speed advertisements are not supported. They will negotiate to correct duplex and highest possible rate

I understand:

These modules will ONLY work with auto-negotiation enabled.

What came out of this thread would be written as:

These modules are ONLY compatible with 10G SFP+ ports.
Their normal and suggested operation mode is with auto-negotiation enabled, but they can ALSO, if needed, be set with auto-negotiation disabled as long as speed is forced to 10G-baseT.
They will negotiate to correct duplex and highest possible rate on the ethernet/copper port side.

12

The real problem is that the manual is never updated with new situations, and new versions, and has many gaps.

13

I don't think your English would be the problem.

In many places, Mikrotik's documentation is written very well: real-world problems are examined and features are presented that provide solutions. Concepts are discussed and examples are given - after reading it, you walk away with genuine understanding of the topic. In other places it's written as if their Confluence license was charged by the word. This case is the latter.

"Use these modules only..." contains a clear instruction, however is doesn't (strictly) imply "These modules will ONLY...", but it would be a reasonable reading.

All this doesn't change the fact that many people had situations in which only forced modes worked correctly, with Mikrotik's engineers sometimes being surprised at that. I don't know if it was followed up, or any corrective action was taken.

These modules only work in 10G bitrates on the sfp side, so it's at least not inconceivable that they would work forced to that mode.

I merely relayed the "official stance", the "unofficial, but seems to work" experiences, and gave the rationale, according to which it's not totally unexpected that forced mode 10G would work, while 1G would not.

@mrfox: If you're willing to go through the proper steps, probably including testing the latest software versions, maybe it would be useful to file a support ticket. Maybe it would lead to some minor correction.