Bump. This is really a product segment Mikrotik should consider. The market today basically consists of either stupid dumb, or overpriced industrial variants with horrible and outdated software OR astonishingly expensive Cisco IE-series stuff. Something performance-wise like the hEX or new L009. 2 ...

Feel free to suggest other protocols and features that should be supported.

Bit of a long shot, but how about RDMA protocols such as RoCE or iWARP?

I will just hope that one of the MikroTik new year resolutions is to bring us cap AX Wifi6E ceiling units in 2023 :D I also hope for 6E units, but it does not look likely - at least for the first iteration. cAPGi-5HaxD2HaxD (cAP ax) https://help.mikrotik.com/docs/display/QG/Quick+Guide+-+cAP+ax Det...

I haven't seen an issue with packet loss when running mismatched speeds, but have definitely experienced packet loss with 10G DACs from FS.com (the same FS DACs work without issue on gear from other vendors). Have not experienced any issues when using 10G StarTech DACs.

Yes! This would be fantastic for so many applications. Light L3HW offload for routing would be a great add as well - set a lower cost route to this shaper device so that if it fails, traffic downstream just flows out the original path(s).

Currently at 70 days uptime on 3 CCR2004s running v6.49.2.

Last unexpected reboot on these units hit around the 76 day mark (was then on v6.48.4), so will see if these make it the same or longer on the newer code track.

Same ros version and similar config i have reboot around every 50/60 days These wound up rebooting on 6.48.4. Have since upgraded to 6.49.2 per Mikrotik support recommendation, at 55d uptime for all three devices. However am not confident that the reboot issue is resolved on this code, waiting for ...

In case any of you are experiencing issue with random reboots on 2004 and 6.49.1/7.1rc7 Please, contact us (support@mikrotik.com) with the information and attached support output files. Reboot on 6.48.4 after 76 days uptime (was latest available firmware at the time, supposedly had 'fixes' for this...

Have installed three CCR2004-1G-12S+2XS units over the past several weeks. Running 6.48.4 RouterOS and firmware on all three units, no reboots yet since each was installed... but definitely watching for a reboot to occur. Uptime: 37d 12:50:20 Uptime: 27d 12:31:48 Uptime: 12d 16:13:14 Using as intern...

Similar to this line of thought, ITU-T G.8032 (Ethernet Ring Protection Switching) support would be nice. Provides sub-50ms failover for stretched L2 ring topologies, such as some Carrier Ethernet or industrial deployments. Very much doubt this would be added as a feature, but wishes are free.

Under /ip settings you have rp-filter set to strict ; this does not work correctly with routing tables per https://wiki.mikrotik.com/wiki/Manual:I ... Properties

Try setting your rp-filter to loose and see if that helps resolve.

Appreciate you having taken a look - definitely understand wanting to see the entire config, especially as you correctly mention there are several other stages in the packet flow that can cause issues. That being said, turns out enabling NAT-T resolved the issue (was hard disabled on the HQ firewall...

Have tried a second loopback bridge 'MGMT' with no member ports - still unable to ping the CPE across the IPSEC tunnel until one of its LAN ports has been initialized. Tried the standalone MGMT bridge with a /32 inside the LAN subnet, and also separately tried as its own standalone /32 with a second...

Hello all, We have IPSec configured between a Mikrotik CPE and our HQ location using a non-Mikrotik firewall. On the 6.47.x code train specifically for new feature 'ipsec - allow specifying two peers for a single policy for failover'. We are able to successfully establish PH1/PH2, and can pass traff...