Deny of service in case of multicast network temporary problems

[kivarun]

I am using vrrpd on virtual guests inside Hyper-V cloud. Some times, I don't know the reason why, hypervisor drops multicast packets for small periods of time 3-10 seconds. After that we lost connections between VIP IP and clients outside his subnet. I did small investigation and found the reason - in case of multicast network problem bacup node become master, after restoring multicast connections between nodes, secondary node returns to backup state and nobody revert ARP table back on routers.

Steps to reproduce:

1. Configure two nodes of VRRP cluster.
2. Drop multicast traffic on backup node. iptables -A INPUT -d 224.0.0.18 -j DROP
   Backup node lost the master, become new master end send "magic packet" to rewrite ARP table on router
3. Allow multicast traffic on backup node. iptables -D INPUT -d 224.0.0.18 -j DROP
   Backup node found the master, switch to backup state and stop serve the VIP IP.
   Routers still sending traffic to backup node due ARP table

[fredbcode]

Hello,

The behaviour expected is when the backup didn't receives packets it become master.
It's how vrrp works, nothing wrong.

You can update the delay or/and send a ping from the VIP address, with Backup/Master scripts, to the first router/switch

Disable the spanning tree on switch can be useful

Virtual MAC works inside Hyper-V ?

[kivarun]

We do not use Virtual MAC because. I had issues with Virtual MAC before. Some times kernel revert interface MAC back and vrrpd do nothing with it.
Why master do not send magic packets when detects another one master with less priority? I think it will solve this kind of issues.

[fredbcode]

Yes vmac is problematic with virtual machine

"when detects another one master with less priority", you can't have two masters at same time, something else is wrong in this case.
If the master sends a magic packet, the vip still present on another server and generates conflict later

The magic packet is only useful when the state change to flush the arp table and worst in you first example the master can't see the second server because the mutticast is just dropped (so just two blinded masters at the same time)

Working with two masters is just impossible, if the two vrrpd can communicate it must make a choice (be master/be backup) , if two can't communicate nothing works at all.

[kivarun]

May be slaves can do multicast advertisements too? Just to let master know multicast is working?

if two can't communicate nothing works at all.
In case of two nodes all works fine till multicast back to live