Dear Mikrotik team,
I would like to offer HA gateways for devices using VRRP and still use L3HW offloading on redundant CCR2216.
I use Mikrotik switches in the core fore bridging and use a lot of MLAGs to have high availability. Unfortunately, both MLAGs and VRRP currently rule out the use of L3HW.
I would also like to use VRFs, but that also stands in the way of L3 offloading.
Will anything change in the foreseeable future? VRRP would be most important to me.
Thank you very much!
-Boris
write this to support@mikrotik.com
Done. I thought the forum would be the right place. #SUP-189051
We’ve also encountered the limitations regarding VRRP and L3 hardware offloading, particularly on the CCR2216 in redundant setups. Like many others, we’re aiming to build highly available network designs using VRRP for redundancy. Unfortunately, the current restrictions on using VRRP alongside L3HW offloading significantly reduce the practical usability of this powerful feature.
In environments that rely on high availability and performance, being forced to choose between redundancy and hardware acceleration creates a difficult trade-off. The ability to use VRRP with hardware offloading would be a major step forward for a wide range of deployments—especially in enterprise and service provider networks.
We understand that architectural or technical constraints may exist, but if there’s any roadmap toward enabling VRRP (or even basic HA mechanisms) with L3HW, it would be very valuable for many of us to know.
We hope MikroTik considers making this a priority. There’s clearly strong demand for this capability, and it would unlock the full potential of the CCR series in mission-critical setups.
[]
We understand that architectural or technical constraints may exist, but if there’s any roadmap toward enabling VRRP (or even basic HA mechanisms) with L3HW, it would be very valuable for many of us to know.
[]
possibility always there. maybe.
but the fact that vrrp with l3hw logic they contradict each other is the biggest obstacle. one needs to pre-emptive the route and the other needs to remember and just deliver the packet.
how will they get along with each other?
They surely do not contradict each other in principle. If other vendors can do it, Mikrotik can do it too. Standard enterprise network designs are based on these features working together.
A major issue with MikroTik is that they don’t clearly communicate what their hardware can or cannot support in realistic network designs. I had to find out the hard way in my lab.
hello mudrc,
well i beg to differ about your thoughts on vrrp and l3hw offloading that they don't contradict in principle. but I'm open for some input 
and it's interesting enough that you have other vendors vrrp and l3hw offloading solutions worked for you. would you elaborate?
If you have your L2/L3 boundary on an L3 switch and want to make it highly available (i.e., using two devices), a First Hop Redundancy Protocol (such as VRRP or HSRP) is inevitable. You could avoid using FHRP by deploying a stack or cluster, but that isn’t available on MikroTik either.
I believe that in the Cisco world, using an FHRP on standalone L3 switches is fully supported. That’s why I’m saying it should be possible in principle.
interesting 
while hsrp nor glbp they are indeed Cisco's proprietary protocols prior to open standard vrrp - i barely heard any layer 3 switching clustering (of course that doesn't apply to any servers farm clusters) in place of fhrp like you said. l2 clustering yes - but never heard l3 switching clustering. because I think that if it does exist that probably would cause another headache for the existing ip routing protocols. don't you think?
edited…
aaa… my bad.
@ mudrc. yes you are right. i have forgot that l3 switch clustering did exist. maybe that chapter already booked for future plans for MT? master-slave, orchestration etc.
hmm… but probably some already knew that why vrrp still being used today in comparison to existing dynamic routing protocols.
funtastic reminder. thank you 