Multicast not working on macvtap device

I have a problem with my virtual network and IPv6 network discovery (multicast traffic).

(The setup might seem a little bit involved and I don't remember the exact reasons for every design decision. Nevertheless the network proved to be stable and maintainable. Still possible there's room for optimization and simplification.)

My setup is this:

• qemu/kvm host ("qemu") is running Debian 10; I'm using virt-manager for administration where possible- one VM ("fw") is running a virtualized firewall/router with Ubuntu 18.04- NIC of fw is connected to "Bridge br0: Host device eno1":

# brctl show
bridge name bridge id       STP enabled interfaces
br0     8000.f44d306689b5   no      eno1
                            vnet0
                            vnet1

• inside of fw I have created several VLAN devices for my different subnets to be filtered by the firewall
• my other VM ("server") is connected to "Host device br0.10: macvtap (source mode: Bridge)" (br0.10 is the VLAN device for VLAN-id 10 on br0.
• I have configured a global unicast /64-subnet (from tunnelbroker.net) in which fw and server have an address of that subnet configured
• I could ping the link-local address of server from fw

The problem:

• I could not ping the global-unicast address of server from fw
• tcpdump on fw showed neighbor solicitations where going out, but no replies were coming in
• tcpdump on qemu on br0 also showed the neighbor solicitations and no replies
• (the workaround) switching macvtap0 to promiscous mode solved the problem. Neighbor solications where received by server and replied to.

My questions are: Why do I have to switch macvtap0 to promiscuous mode manually? Isnt't multicast a standard network feature that should work "out of the box" with a VM? (Or is my setup so untypical, that my use case is not covered?)

Solution 1:

I found an answer at Superuser: https://superuser.com/questions/944678/how-to-configure-macvtap-to-let-it-pass-multicast-packet-correctly/1033768#1033768 I'll just copy sourcejedi's answer here:

libvirt's macvlan has gained support for multicast. Unfortunately it is disabled by the default setting trustGuestRxFilters="no", and the documentation is not explicit that this breaks multicast. As you observed, breaking multicast also breaks IPv6.

https://bugzilla.redhat.com/show_bug.cgi?id=1035253#c15

You may be able to work around this by manually setting trustGuestRxFilters="yes". There is a limitation: "support depends on the guest network device model, as well as the type of connection on the host". "Currently it is only supported for the virtio device model, and for macvtap connections on the host".

https://libvirt.org/formatdomain.html#elementsNICS

IMO the natural model would be to allow multicast by default. Blocking multicast reception, on a network you think you're directly connected to, is an unpleasant surprise. Especially since macvtap still seems to allow sending multicast packets (as well as spoofed MAC source addresses!).