Compatibility error? CCR2216-1G-12XS-2XQ with Ubiquiti Modules

I am writing to inquire about the compatibility of my router, specifically the CCR2216-1G-12XS-2XQ model, with Ubiquiti modules. Upon attempting to connect Ubiquiti modules to my router, I encounter an issue where the module is detected but not recognized, and it shows Tx fault.

Previously, I have used SFP modules that were compatible with an older MikroTik router model. The ports on my current MikroTik router are Sfp28, whereas the modules I am using are only SFP. Could this issue be due to compatibility between Ubiquiti modules and MikroTik routers, or could it be related to the compatibility of SFP modules with Sfp28 ports?

PD: Sorry for my English, I’m not native.

Thanks.

Do you have the SKU of these particular Ubiquiti transceivers?

is UACC-CM-RJ45-1G

tried disabling auto-negotiation and fixed it to 1G/FDX ?
fixed it 90% of the time i had UBNT SFPs in my 2004s and 2116s (never got auto-neg. working below 10G with mixed/non-MT SFP modules on SFP+ and SFP28 ports)

EDIT:
do you have a screenshot of winbox showing SFP tab details of the port?

Yes, I have already tried disabling auto-negotiation and forcing it to 1G. The only thing I have achieved is that the link appears as "link ok" and "running" but with the "Tx fault" error. It shows that there is a module present in the port, but I am unable to establish traffic. This happens similarly with an SFP-RJ45 module.

I assume you also tried rebooting the Mikrotik device when setting autoneg=yes but limit the advertised to just 1Gbps/Full Duplex ?

Aka “did you turn it off and on again?” :slight_smile:

I have noticed that even if SFP/SFP+/SFP28 modules are supposed to be hotpluggable thats not always the case specially when mixing transceivers.

The original Mikrotik RJ45 transceivers are dualrate as in they supports 10M, 100M, 1G, 2.5G, 5G and 10G.

Also note that NBASE-T (that is RJ45 above 1Gbps such as 2.5G and 5G) are notorious to get the wrong speed selected when autonegged (specially Marvel chips which Mikrotik uses) where the workaround here is to adjust the advertised capabilities to only support a single combo (such as 1G/FD) and if possible also do the same for the other end of the cable (whatever gear you might have there).

When it comes to fiber transceivers there is actually no such thing as autoneg since they only support a single speed anyway but can be used as a workaround to trick the local OS if there is some compatability issues (and in that case disabling autoneg and adjusting advertised capabilities to 1G/FD or whatever often works (along with rebooting the device afterwards)).

Yes, I have restarted it. I have performed all the configurations on the link, testing if it could work, but no success. It shows “link ok,” but for example, now I’m testing the SFP-RJ45 towards a PC, and it doesn’t even recognize that there is a network cable connected. I am sending the following screenshot.
Captura de pantalla (61).png
Captura de pantalla (62).png

Technically for RJ45 its mandatory to use autonegotiation according to IEEE standard.

So that should NOT be disabled.

Also with autoneg disabled the auto mdi/mdix will also get disabled so you are then down to use the correct cable like a straight cable between your device and a host and a crossover cable if you connect your device to another router or switch.

If you scroll down in that settings page how is advertised being configured?

I assume you have tested this particular transceiver and cable in another device just to rule things out that its not broken on its own (or for that matter whats on the other end of the cable is broken)?

Have you tried plugin the transceiver in another slot?

You seem to be trying sfp2, have you tried putting it in sfp12 or such (thinking of the issue with port 1-8 on CRS354 switches in case something similar is going on here)?

You can also try to set the rate-select to low and reboot the device (while you are troubleshooting anyway):

http://forum.mikrotik.com/t/special-settings-needed-for-xs-31lc10d-and-xs-2733lc15d/169749/1

http://forum.mikrotik.com/t/sfp-rate-select/152511/1

Also what version are you currently using?

Try to boot into 7.16.beta4 testing to see if there are any changes?

Edit: That port 1-8 issue on CRS354 seems to be related to the PHY itself if its just bad soldering on a batch or something like that.

Shouldnt be the case in your case since the CCR2216 use a single phy as it seems according to the block diagram for int1-12:

https://i.mt.lv/cdn/product_files/CCR2216-1G-12XS-2XQ_220346.png

If you compare with the block diagram for CRS354:

https://i.mt.lv/cdn/product_files/CRS354-48G-4Splus2Qplus_200122.png

But its still worth and easy to test just put it in another slot as far away as possible from the current slot.

Yes, I have tried changing the module port and/or restarting the device, but the same error persists. I also attempted to configure the “Rate select” and “FEC mode” without success. When setting it to auto-negotiation, I encounter the “auto-init-failed” error, which recommends forcing a speed.
I am using MikroTik version 7.15.2.
I will try testing beta version 7.16 although I have low expectations. I will also test it on my other MikroTik when I have time, as it is located in another node.

Try another vendor’s SFP modul with “MSA compliant”:

Almost certain the UBNT module is not “MSA compliant”.
“MSA compliant” is mandatory for interop. in multi-vendor environment.

I had the same problem after upgrading to ROSv7 (http://forum.mikrotik.com/t/routeros-v7-bug-on-ros6-working-unrecognized-10gb-sfp-dac-direct-attach-cable-copper-pigtail/176197/1). If you want to use your transcievers and cables you would have to downgrade to ROSv6 or at least ROSv7.11.3 where the MSA compliance is not mandatory. Our cables started to work after the downgrade.
There was an announcement with ROSv7.12 which is deleted today - it said:

Notice - SFP/QSFP functionality has been refactored for consistent behavior and better scalability. Now, compliance with SFP/SFP+/QSFP MSA standard is mandatory. This may cause issues with SFP/QSFP modules that are not fully compliant. All current MikroTik modules abide this standard.

Shame on Mikrotik for forcing all their users the MSA compliance.