Hi there !

We are having this kind of issue:

We have a router which has VRRP interface on a bridged interface. The problem is that the traffic which is sent to the one of bridge ports is duplicating to other bridge ports. After 5 minutes (aging time) everything starting to work normaly. The thing is...that when traffic is duplicating I don't see VRRP's interface MAC address in Bridge Hosts. I wondering whether this is my misunderstanding or it's Mikrotik's issue. Maybe somebody can give a piece of advice?

Anyone ?

I see this problem since many many routerOS versions. the problem is that the bridge does not know to which interface the vrrp-interface belongs (see the Host-table on the bridge, you will not see the mac-address of the vrrp interface, like you already mentioned) ...

that is causing that all traffic that comes into the bridge and has to reach the (local) vrrp-interface is flooded out on all bridge-ports. i already have a ticket open at MT that this is a bug .. i hope they are going to fix that

Regards,
Joerg

Does anyone have any news on this? I've found the same issue. MAC addresses of VRRP interfaces aren't learned by the bridge, so they flood all ports.

One solution may be to use Bridge -> Filters and create a forward rule like:

chain forward
interfaces / out. interface = ether2
dst MAC address = MAC of VRRP interface
DROP

Repeat for each etherX interface that you go to other hosts. Do not do this for interfaces connecting to the other routers running VRRP.

I have not tested this yet.

Does anyone have any news on this? I've found the same issue. MAC addresses of VRRP interfaces aren't learned by the bridge, so they flood all ports.

One solution may be to use Bridge -> Filters and create a forward rule like:

chain forward
interfaces / out. interface = ether2
dst MAC address = MAC of VRRP interface
DROP

Repeat for each etherX interface that you go to other hosts. Do not do this for interfaces connecting to the other routers running VRRP.

I have not tested this yet.

Hi,

this is how i "fixed" it for the last years .. i dont think MT will fix it. Maybe you open a ticket with them and see what happens.

Regards,
Joerg

I have the same problem

this is how i "fixed" it for the last years .. i dont think MT will fix it. Maybe you open a ticket with them and see what happens.

Yep. On my device, ports ether2-4 are bridge members that would never host the VRRP address. ether5 connects to the backup router. So this is what I did:
This has avoided the problem, but it still sucks. I don't have any faith that Mikrotik will actually implement what we request, though. They have a long history of ignoring key features such as OpenVPN UDP.

The problem is still persists. CCR1009-8G-1S-1S+, 6.37.1.

Ran into this issue, too. Solved it by using a loop-cable on the router:

ether1: ip-address of router
vrrp1: slave of ether1 with virtual-ip address

ether2: slave of the bridge containing all other needed ports exept of ether1

loop-cable between ether1 and ether2


Anyways. This is very undesirable!
Every other Routering/Switching vendor on the market is able to do VRRP (or its competitors like HSRP, VRRP-e/a) on a VLAN, SVI or Bridge without hassle.

After a quick conversation with support, this issue was resolved within a few days in the latest release candidate:
What's new in 6.42rc35 (2018-Feb-26 10:46):
*) bridge - fixed MAC learning for VRRP interfaces on bridge;

6 years... 1 year with breaks I'm trying make work vrrp configuration in my network between CCRs. And now this works on 6.42rc35 fw. Thank you so much.
Special thanks to sup5.

As a general rule of thumb:

Always inform support about bugs. Do not rely on the forums.
Shrink the setup to the bare minimum in order to exhibit and reproduce the bug.
Add Diagrams and PCAPs etc.

Any bug I informed support about so far has been fixed.

Hi there. Is it possible to make the icmp reply comes from a virtual ip address, and not the master ip address in the vrrp configuration on the bridge with vlans when tracing a route? For example. If my default gateway ip 192.168.1.254 (virtual IP for VLANx on ccr), I recieve reply from 192.168.1.253 (master IP).

Until now, I still got this issue as I can see all the bridge members are flooded with traffic with destination MAC-Address of 00:00:5E:00:01:01, which is the mac-address of a VRRP ID1 on that bridge.
I am now solving it by adding that VRRP mac-address and bind it to one of the physical interfaces member in "/interface bridge host" section.

Hi ,

The concept of the Vrrp protocol is that both router knows which are roles and import config from one to another if something goes wrong,

Only Inexperienced user think that secondary router will get address with number 2 instead of 1 in the subnet if the first router goes bad,the key is gateway address and activate master interface to bridge

if both routers are in same bridge collision and loops will occured, so you must disable traffic in the bridge master 2 or which one you have to second router

So Vrrp is simple protocol when first router goes bad secondary router activate startup script and becomes primary nothing else in order to do that you must have only one cable directly to sense protocol like heart beat if the signal is lost router 2 becomes interface and master primary router and forward internet trafic

when router 1 goes back vice versa router 2 then becomes interface with address 2 or differenet address not gateway.

So good thing about Mikrotik router is not that they work good in Vrrp they work good in power redundancy so they can both give dc by the power unit cable they since when poe is in the switch is on.

for me that most imporant part since main router will not go bad when power supply goes off or wrong will stay up and still be functional

That is same everywhere ubiquity,dd-wrt,pfsense and other linux distribution.

Mikrotik has everything in the Gui and FreeBsd engine ready it has the fastest boot up then every other brand i tried very stable and rock solid everythink for free included in the licence

Sorry to reply to an old thread.

I'm having this exact problem with the latest rc (7.1rc4) on CCR2004 can anyone confirm if this is still an issue on 7.1rc?
When I add a VRRP interface on a bridge, every outgoing packet from the bridge is pushed back to all of the interfaces on the bridge.

I also tried to add the VRRP interface mac into bridge/hosts and bind it to a physical interface, this leads to no internet connectivity at all.

Sorry to reply to an old thread.

I'm having this exact problem with the latest rc (7.1rc4) on CCR2004 can anyone confirm if this is still an issue on 7.1rc?
When I add a VRRP interface on a bridge, every outgoing packet from the bridge is pushed back to all of the interfaces on the bridge.

I also tried to add the VRRP interface mac into bridge/hosts and bind it to a physical interface, this leads to no internet connectivity at all.

i got this probelm too ros 7.1.3 on ccr2004

I have the same problem on a CCR1009-7G-1C-1S+ with RouterOS v6.48.6. I found this thread while I was investigating why the throughput of a singe TCP connection is 3 times better with a regular VLAN interface on a bridge then with a VRRP interface on top of the VLAN interface.
I can also confirm that the MAC Adress of the VRRP interface does not appear in the Host / MAC Table of the Bridge. Consequently, alle the traffic that arrives on one Bridge port and has the VRRP interface as destination, is sent out to the other ports of the bridge.
I think this could be the reason for the massive performance drop I see wen using a VRRP interface IPv4 as the Gateway on a host behind the router instead of the non VRRP IPv4 of the router.