Actually, ignore what I said about virsh nwfilter-list, I don't think
they are actually used as the SG scripts do their work instead.

On 2020-06-24 14:56, n...@li.nux.ro wrote:

Hi, The issue with SG was the they were not applied at all, if we are talking about the same thing. :) With regards to VRRP, a shared network without SG should allow this kind of traffic, of course also depending on your sysctl arp settings. I know that by default libvirt will apply a mac filtering rule, I am not sure how you are checking the firewall rules there, but it could be that, see the active filters: virsh nwfilter-list Having said that, how are you using vrrp? Through keepalived? If you use the vmac feature it will most likely not work due to filters similar like the one I mentioned above. This applies to most hypervisors (libvirt,hyperv, vmware). What worked for us in a restrictive network environment (virt, but non-cloudstack) was to use increase the usage of gratuitous arp requests, such as is described here: https://serverfault.com/a/822004 hth On 2020-06-24 14:26, Andrija Panic wrote: Hm... I recall there was some issue trying that with security groups, but I might be wrong. @Nux! do you recall such issue, or was it my imagination? On Wed, 24 Jun 2020 at 14:12, Rahimov Sherzodjon Murodjon o'g'li <shrakhi...@beeline.uz.invalid> wrote: We faced a problem with VRRP running on guest machines in our Cloudstack 4.13.0.0<https://4.13.0.0> cluste with KVM as a hypervisor. We are using Security Groups in which multicast is enabled for VRRP. EBTables is empty. Also there is no virtual router in the network where we are trying to configure VRRP as it is a non-routable subnet for communication between several guest machines. For some reason we can't resole VRRP VIP by ARP. Are there any limitations for using VRRP in Cloudstack? What can be the reason of this? --

Andrija Panić

Reply via email to