Test scenario: Two interfaces in the same VRF. This VRF is part of an MPLS L3VPN, but the test scenario is just between two nodes connected to two different VLANs, two different subnets, same VRF routing between each other. Instead of getting the expected line-rate routing, it all appears to be going through the CPU which jumps to 100% and provides abysmal performance.
Is this per expectation? Are there plans to fix it? Does VRF HW offload work on any MikroTik hardware?
Thanks!
Hi,
Unfortunately, L3HW doesn’t support VRF yet. The hardware (switch chip) supports it, but the feature has not yet been implemented in RouterOS. There are plans to add VRF L3HW, but I cannot share the ETA at the moment of writing.
Any chance of an ETA now? on CCR2216 99% of people will most likely use some form of VRF which kills any form of L3HW from being available.
I watch ever beta being released just to see if this feature is available.
this topic is gone silent, Any ETA? for this feature request
I also want to know the answer.
I appreciate you cannot give specific timelines, but it would help to at least know whether L3HW VRF is something you’re actively working on, planning to work on, or don’t have it anywhere in short-term plans.
While L3HW offloading may seem like a good idea, the implementation has been complete garbage. Every other vendor handles VRFs in a useful way. If you turn on L3HW offloading then all your VRF’s are useless except the main table. This seems like a complete lack of foresight from Mikrotik, since most users especially the ones replacing CCR1036/1072’s will most likely be using VRF’s for internet traffic and management separation; like we are. So now that Mikrotik is 7.18 versions into ROS V7 with years to figure this out, what the hell happened?.
I guess we’re just supposed to put all our routing in the main table and YOLO our way to security with a ton of firewall rules or skip HW offload? This may be the time to switch to Vyos since they’ve been doing VRF’s right for a couple major versions now.
Even in 6.49 VRF’s worked as expected, but we’re using CCR1072’s for that and management and public routes are fine in their respective VRFs. What about CPU usage, in non L3HW offload mode our test CCR2216/2116 routers get huge spikes on multiple cores for a simple 300MB speedtest, I can’t imagine how that will scale out to hundreds of users. I guess the marketing department over at MT just loved the idea that one day in the future L3HW offloading would actually serve the customers in the new product lines.
Just my $0.02
I agree, without l3hwoff in VRF makees 2216 less efficient, atleast in my use case as Internet gateway for the medium scale ISP, with just 20Gbps traffic without firewall any firewall rules and natting it is hitting 60% cpu on all the cores, even BGP is not full table.
Can Mikrotik ateast give a time frame for this features to implement? 
I agree! it’s an important feature to enable as soon as possible please!
A friendly bump. It would be amazing to use mikrotik gear as a PE, but without l3hw offload for VRFs I’m unable to buy more gear or recommend. Can we please get a timeline Mikrotik?
it’s ready when ready! but I think it will be close to fruition because they need to fix this inline with their EVPN implementation in 7.20
You are making a lot of assumptions.
They may initially not support Type5 routes, or if they support them then forwarding may be CPU only.
I hope this is not the case, but based on history it might be.
Yeah you’re right it could be a far fetched, I just want to be optimistic about it because I want them to succeed and finally align themselves on where they are good at routing and switching, hoping someday we might reconsider their gear again in our edge and core.