Acknowledged by support, a fix is on the way.
Depends on the needs...
As an edge router it can easily handle 10Gbps fibre internet links with firewall, queues, BGP, IPSec etc. and a couple of 10Gbps LAN interfaces which is pretty good for the price, and for LAN switching you should connect it to something with hardware offloading such as any of the CRS models as is the usual setup...
Mainly Cisco.
CCR2004, CCR2116.
- 3-4 Gbps in the CCR2004.
- Up to 7 Gbps on the CCR2116.
In the case of the CCR2004-1g-12s+2xs using the Passive Intelligent Port Extender - PIPE - 98PX1012, you will never be able to forward traffic in off-load hardware. Everything will have to go to the CPU.
It can even do Kernel bypass, but you will have to go up and down on PCI and CPU.
The only thing I ask of MikroTik regarding this matter is that they make it clear in the documentation that hardware offloading is not possible with this type of hardware. Stubborn customers continue to buy this in the false hope that one day a savior version will come along, and then blame consulting for not being able to make better use of the box.
I don't know which Cisco models, but I believe all Telco and DC line models support VXLan.
So I believe that's the way to go.
The same goes for EVPN.
P.S.: Cisco's support for EVPN with MPLS is known to have some limitations.
As with the scenarios we've been working on here, I imagine that Traffic Engineering is within the scope of your scenario. So, taking MPLS out of the scenario... That leaves SRv6.
I wouldn't bet on MikroTik implementing SRv6 anytime soon.
But what we can consider is VXLan over IPv6 as encapsulation, and letting the SRv6 of the next-layer equipment handle the TE.
The questions I have now are ones I will need to test extensively.
- VRF hardware offload on the CRS3XX, with routing protocols, route-leaking, firewall raw, and rules.
- Will it work well?
- VXLan with IPv6 as underlay com hardware offload.
- Will it work well?
- Hardware offload on the VRF on the CRS3XX, considering VXLan interfaces with VTEPs in IPv6.
- Will it work well?
If all this is working well, then we have a model to use MikroTik equipment with some level of decency as PEs in a low-cost carrier network delivering L2VPN and L3VPN.
Which is really irrelevant if you are using it as it is designed and that is as a low cost fast (over 10Gbps) router...
And MikroTik states pretty clearly that nothing can be offloaded to HW:
Since 98PX1012 isnt a switch but a port extender which is also clearly visible on a block diagram:
Can't update from this version to the latest alpha (ab524 at the moment). If I'm updating as usual, it shows that beta1 is newer. If I use downgrade, it doesn't do anything.
IMHO - Another point in favor for:
- Beta and RC releases should be marked as [testing] chain;
- Alpha or "ab" Releases should be marked as [development] chain;
I would also be in favor of placing a restriction on the device-mode where by default only [long-term] and [stable] are allowed. And after enabling the specific functionality, then allow [testing] and [development].
This would prevent naughty children from playing with fire.
Agree.
But, they have problems with determining which version is newer. Logically, beta comes after ab and this is probably the reason it thinks beta is newer. But in fact this ab was released a couple of hours ago while the beta was released about 2 weeks ago. I think they should use build date instead of release channel to detect what is newer and what is older.
*) sfp - fixed linking for hAP ax S and hEX S (2025) with "1G-baseX" link-mode;
still not working, of the port, connected to the Mikrotik is only 1G fixed.
Agreed. Now perhaps some allowed-upgrade-channels=stable,long-term so it's controllable. I've long argued there should be MORE device-mode controls which help fill in gaps in the policy system by just disabling certain features beyond the ones declared "dangerous", and functions more like "skin" that removes the UI.
Here I'm not so sure... I sorta like that testing is "rc", or an "rc" a future patch version, with the idea they languish longer in that state. And development is either "beta" or "alpha", depending on the testing channel that populated (e.g. an "rc" of a new minor testing becomes "alpha" of next version, and some future "7.23.1" might live in testing.
At some level IDK, other than channels should always be progressively older --> newer, i.e. "testing" is never newer than "development".
I would keep access management separated and not abuse device-mode for access management. But when it comes to disabling features device-wide, as device-mode already does for some sections, yes absolutely. Mikrotik, we need more device mode. 
What's new in 7.24beta2 (2026-Jun-10 10:44):
- app - allow HTTP for Gitea when "check-certificate=no";
- app - fixed home-assistant default config files;
- app - fixed making empty directories when running configuration export;
- app - make secrets sensitive to avoid polluting configuration export;
- bgp - fixed advertisement print handling by "dst" when destination is in VRF;
- bgp - fixed EVPN label corruption and correct EVPN type-5 output;
- bgp - fixed IPv6 End-of-Route processing;
- bgp - improved stability on MP (multiprotocol) parsing;
- bgp - removed "save-to" from "resend" command;
- bgp-vpn - fixed blackhole route export;
- bridge - added ARP inspection and IP source guard support;
- certificate - always use all trust stores for downloaded CRL validation;
- certificate - general improvements in certificate handling;
- console - fixed argument mappings in "do" block for monitor commands;
- console - fixed missing comments in scripts (introduced in v7.24beta1);
- console - fixed proplist order in monitor commands;
- console - fixed quoted input issues for multi-argument properties;
- console - fixed UTF-8 comparisons on some architectures;
- console - improved "print detail" mode;
- console - make execute non-blocking when file parameter is used (introduced in v7.24beta1);
- container - fixed missing config.json issue when upgrading from version 7.20.8 or older;
- defconf - set "configuration.dtim-period=3" for WiFi;
- defconf - use "add-dns-entries=yes" on devices with DHCP server;
- dhcp - fixed processing of DHCP options that are longer than 255 bytes;
- discovery - added "discovery" logging topic (additional fixes);
- discovery - added "last-breath" feature;
- disk - added "last-seen" property that displays disk model and serial when removed;
- disk - added error message when disk state transitions from good to bad;
- disk - avoid reading SCSI stats all the time to allow disks to go to sleep;
- disk - improved error message when a swap file is created without "file-size" specified;
- ethernet - removed "1G-baseT-half" link mode on RTL8367 switch;
- fetch - added option to force HTTP/2 only (only for ARM64 and x86/CHR devices);
- interface - fixed duplicate MAC warning for wireless, wifi, macsec, w60g interfaces (introduced in v7.23);
- ip-service - show service name for "l2tp";
- ipsec,ike2 - fixed active connection termination;
- ipsec,ike2 - fixed SA payload validation;
- ipsec,ike2 - improved pending child SA cleanup and removal of dangling SAs during Phase 2 deletion;
- ipv6,ra - correctly process RAs advertising previously expired prefix;
- ipv6,ra - fixed prefix invalidation;
- isis - fixed missing "l2.lsp-refresh-interval" parameter;
- l2tp - allow fragmentation of large IPv6 packets;
- l3hw - added HW offloaded VRF support on 98DX8208, 98DX8216, 98DX8212, 98DX8332, 98DX3257, 98DX4310, 98DX8525, 98DX3255, 98CX8410 switches (additional fixes);
- leds - added dark mode support for L009;
- lte - cap IPv6 prefix lifetime for ipv6-interface;
- lte - do not add extra /128 IPv6 address for ipv6-interface;
- lte - limit IPv6 prefix lifetime only when lifetime is advertised as infinity;
- lte - make modem MAC persistent for R11e-LTE6 and R11l-LTE7 modems;
- lte - remove site local DNS for ipv6-interface;
- netwatch - fixed issue where ICMP probes did not accept TTL exceeded packets when "accept-icmp-time-exceeded" was enabled;
- netwatch - increased maximum packet size to 65535;
- ospf - added missing interface parameters (additional fixes);
- ospf - allow comments on static interfaces;
- ospf - fixed interface passive flag update in WinBox;
- ospf - fixed unresolved route problem when "routing-table" setting is used;
- pimsm - make "hash-mask-length" parameter naming consistent and fixed typos;
- poe-out - firmware update for 802.3at capable boards (the update will cause a brief power interruption to poe-out interfaces);
- poe-out - firmware update for 802.3bt capable boards (the update will cause a brief power interruption to poe-out interfaces);
- ppp - disable/enable modem radio state depending on ppp interface state (additional fixes);
- ppp - fixed ppp-out stability issue (additional fixes);
- ppp - improved "info" command for BG77 and BG770 modems;
- ppp - only show pin in export with "show-sensitive" flag;
- route - allow to add route with link-local destination address;
- route - fixed memory leak when flapping addresses or interfaces with routing protocols running;
- route - fixed static route flag handling by WinBox on disable;
- sftp - fixed branding package upload;
- switch - increase "ingress-rate" and "egress-rate" maximum value to 400G;
- traffic-generator - fixed injecting pcap/pcapng files on MIPSBE architecture;
- tunnel - fixed stability issue caused by a misconfigured routing loop under bridge (introduced in v7.22);
- vrrp - fixed stability issue when "sync-connection-tracking" is enabled;
- wifi - improved roaming/steering behavior for WiFi 7 MLO (additional fixes);
- wifi - upgraded wifi-qcom driver;
- winbox - added "Network" configuration menu for WiFi;
- winbox - added missing values to "AFI" setting under "Routing/BGP" menus;
- winbox - fixed "Connection Bytes" field under "IP/Firewall" menu;
- winbox - fixed "EC/IO" scaling for LTE interface;
- winbox - fixed empty value in "Immediate Gateway" under "IP/Routes" menu;
- winbox - fixed value unset under "MPLS/LDP Neighbor" menu;
- winbox - fixed WinBox v3 stability issue when Netinstall package is enabled (introduced in v7.24beta1);
- winbox - move "EAP" under "Security" tab for WiFi;
- winbox - show priority bits in "VLAN ID" field under "Tools/Packet Sniffer" menu;
- wireguard - fixed peer recreation on interface change;
- x86 - fixed IRQ displaying per CPU on Intel 700 series NIC;
Last time we saw this changelog message, 7.15beta introduced issues (especially these "sa query timeout") and took until 7.19.2 to be resolved. I hope this time this goes well and improves wifi-qcom.
@CGGXANNX what's fixed here? 
Any release notes for that new driver? I am aware of two bugs:
- when the signal level is quite low, like -90 and lower, the "registration" tab shows random values in the Signal column. This is not fixed. (the "Scan" function shows correct values so it cannot simply be a hardware limitation)
- the "distance" value is ignored above 20km. has this been fixed? (not tested that yet)
Is there any updates on other devices getting arm64 support like the E60iUGS (hEX Refresh 2025), or is it still just the L009 that can be reinstalled to arm64?
Thanks for a quick fix 
Thank you very much for VRF support. Is there anything we have to enable to get it running or will it "just work" without any additional configuration steps needed?
It means EVPN Type-5 Routes are already working on this version?
It covers L3VPN Routes also?
Edit:
It means EVPN Type-5 Routes are already working with VXLan on this version?
It covers L3VPN Routes also?
P.S.: If true, I'm really excited to test this! But my work schedule until the end of the month, and the angry wife I have at home, will not allow this to happen before the week of June 29th.