A question on this:
Is there a reason you have to use routing marks/tables with FIB enabled for routing rule selectors?
(Assuming these tables/marks are not used elsewhere)
Thank you for implementing it so fast for the older models.
- Is "and fasttrack/NAT/vxlan offload is limited only to
maintable" a hardware limitation or simply not implemented in software yet? - Do you intend to implement?
- Soon or who knows?
During long long time, the only thing that did work on RouterOS for that kind of work was mangle.
So many many people think this is the correct way of doing that.
They insist in not understanding that mangle is a Firewall thing, and VRF is a Router thing.
So, what come now is reeducation of using the correct tools for the correct problems.
Same is occurring in bridge/vlans theme.
There are a lot of stubborn still creating a bridge for each vlan, not using vlan filtering, and using the F*****G "admit-all" like there is no tomorrow on devices that are strongly focused on SwitchChips features.
Those "very intelligent" people are the ones that complains that a CCR2116 has less power then a CCR1036.
To start to solve things like that I mentioned, education, reeducation, and re-reeducation...
With changing of default configs to the methodology that works with switchchips is what will solve.
This applies to the bridge and the firewall rules.
I'm not very familiar with this setup, so please correct me if I'm wrong.
In the Linux kernel, this situation is handled differently - with policy routing rules (/routing/rule), where there is one large table, and for expensive clients a lookup can be performed in the small tables first.
And with L3HW you can create ACL rules (/interface/ethernet/switch/rule) to steer the ingress traffic into VRF. The docs is missing new-vrf setting.
However, we do not have switch that supports hardware offloading of 1 million routes.
- FastTrack/NAT limit to
mainis a software limitation. Theoretically, hardware can offload connections from different VRFs. - As soon as software implementation is done, we can implement the hw offloading. The latter shouldn't take long.
- who knows?
Sadly, no news on http/2 multiplexing support for dns-over-https?
Correcting:
"No MIKROTIK switch currently supports hardware offloading of 1 million routes."
Specialized Chips from Juniper, Cisco, or Nokia can reach 10-20 millions entries on TCAM. Even More!
Talking about merchant silicom
- Broadcom StrataXGS(Tomahawk, Trident), that is the series of chips for Datacenter(small TCAM, Lean Buffer, low latency), cane reach 512K Entries.
- NVidia Spectrum SN4000 is very close to StrataXGS
- Broadcom StrataDNS(Jericho, Qunran, Dune), can reach 10 Millions routes(or more), including deep-buffer.
But, despite:
"No MIKROTIK switch currently supports hardware offloading of 1 million routes."
It seems MikroTik has an interesting mechanism that competes with FIB compression and Longest Prefix Matching (LPM) techniques(Juniper and Arista has great techniques for that).
In some way, RouterOS keeps only the routes with the highest hit-ratio within that tiny space of 1Kâ4K routes (depending on the model), and when there isn't a match on that tiny space I assume the lookup happens via the CPU.
That looks interesting.
I believe it is important not to confuse routes resulting from route leaks across VRFs with Policy-Based Routing (PBR).
And even more importantly... do not confuse leaked VRF routes with PBR or Mangle; the latter operates at a completely different layer of network forwarding.
- Standard routes perform forwarding based on a lookup of the destination address (and the VRF, of course).
- Policy-Based Routes perform forwarding based on lookups involving criteria other than the destination address and VRF, yet without relying on a connection tracking (conntrack) lookup.
- Mangle, by its very nature, relies on connection tracking and markingâa state table distinct from the routing table.
are you sure about that 'most active routes are hardware offloaded' method? i read that hw/sw depends only on prefix length. has anything changed?
When considering other vendors(specially Juniper, and Cisco), I am certain about FIB compression and LPM.
When it comes to MikroTikâand given that the information originates from themâI am not certain of anything.
However, I am certain that the concept of "partial offloading" exists in their documentation (Confluence) and that it covers LPM.
I recall reading somethingâalmost marketing-speakâpraising the clever way MikroTik found to keep the most important routes within the offload space. I admit I am not sure whether that referred to route offloading or connection tracking offloading.
Do not be too ridiculous. Please.
How many zeros after leading digit are in the actual price of these "big pricy toys for boys and girls"? Four or five? Does the price include licence for all funcionalities?
Do you expect including all these chips into 2000$ device with almost unlimited updates?
I konow that "no demand means no supply" but be more realistic.
"Ridiculous" is to tell lies.
And trying to convince colleaguesâwho might not have deep expertise in architectureâthat something doesn't exist when it actually does... that amounts to lying.
Furthermore...
As I mentioned, there are multiple lines of switch chips, each with its own price point.
A Broadcom Trident3 costs orders of magnitude less than a Jericho2.
From what I hear, Marvell is investing heavily to deliver a line of switch chips to compete with Broadcomâs StrataDNX and Nvidiaâs Quantumâchips designed to support full routing and deep buffering.
There is also talk that a certain merchant silicon and switch chip company is subsidizing development by firms in the Baltic region to improve switch chip utilization in the entry-level device market.
However most (I hope) of MT users are aware that there are "bigger"/"better"/"faster" solutions. It does not mean that they do not exists, they are just out of the reach when it comes to the budget ones want to spend on networking gear.
I'm aware that there exist faster, more fancy and luxury cars but if my budget has some limit I'd say "they do not exist for me". Kind of "repression syndrome" for healthier and calmer life 
Of course, I was referring to MikroTik switches. I've edited my post.
What's new in 7.24rc2 (2026-Jul-10 11:58):
- ! fixed a service security issue, home user with default config not affected, but we recommend the upgrade for all users regardless;
- bridge - fixed MLAG MAC address handling issues related to aging, flushing and moving (additional fixes);
- certificate - added "ISRG Root X2", "Root YE" and "Root YR" to SMIPS built-in root certificate authorities store;
- certificate - added "Root YE" and "Root YR" to built-in root certificate authorities store;
- dhcpv4-server - fixed "expires-after" field for disabled static lease (introduced in v7.23);
- dns - fixed an issue where the resolve command was not functional when the "type" was specified (introduced in v7.24beta2);
- fastpath - properly fall back to SlowPath when FastPath is not possible due to fragmentation;
- ipsec,ike2 - use peer certificates also when identity has one set for peer matching;
- l3hw - allow VLAN tagged traffic inside VXLAN tunnel (additional fixes);
- netinstall - added Netinstall package (additional fixes);
- snmp - added WiFi current channel "mtxrWifiInterfacesCurrentChannel" OID to MIKROTIK-MIB;
- snmp - improved SNMPv3 request processing logic;
- ssh - make SSH packet validation more strict (additional fixes);
- system - improved handling of data re-sending on authorization requests (introduced in v7.22);
- system - improved stability;
- system - updated certificate for Windows executable signing;
- tftp - limit maximum simultaneous session count to 100;
- usb - fixed USB Ethernet interface default-name;
- wifi - improved roaming/steering behavior for WiFi 7 MLO (additional fixes);
- wireguard - added support for domain names in client-dns;
- wireguard - added warning when allowed-address overlaps with another peer on the same interface;
- wireguard - fixed wg-export comments output and case when endpoint is not set;
- wireguard - fixed whitespace handling in AllowedIPs during wg-import;
- wireguard - improved wg-export to print endpoint domain name;
- wireguard - improved wg-import to quietly ignore wg-quick specific keys;
- wireguard - reconfigure peer only when meaningful changes are detected;
It would also be very useful when the current channel would be available as a column in the device list.
(so you can see it in the devices table without having to open the device, going to status tab, and see it there)
Does this means that in this release MLO and FT will be supported at the same time or am I just reading to much into this? Do not have the hardware to test right now but would be great it FT works with MLO.
fastpath - properly fall back to SlowPath when FastPath is not possible due to fragmentation;
Any more detail to provide on this? I'm assuming this is for IPv4 only? Did this arise out of wireguard issues?
rc2 still has problems with tagged traffic and bridged vxlan
if i add:
add bridge=bridge1 tagged=sfp-sfpplus2,vxlan1 vlan-ids=123,125
both vlans get through
if i do:
add bridge=bridge1 tagged=sfp-sfpplus2,vxlan1 vlan-ids=123-125
only frames tagged with vlan 123 geth through.
! fixed a service security issue, home user with default config not affected, but we recommend the upgrade for all users regardless;
????
It's the CVE solution (ppp services related), already solved in 7.23.2 and 7.21.5.