Bridge: Multicast issues

[dave558]

Hi

I'm having issues with multicast Ethernet frames getting forwarding to all my virtual guest in a KVM virtualised environment.

Here's a few articles I've been referring to for setting up my bridge:
https://wiki.debian.org/BridgeNetworkConnections
http://wiki.libvirt.org/page/Networking

Certain multicast frames are going through to the KVM guest such as Microsoft NLB which does not include any IP information. Ethernet frames with set IP information and a multicast destination MAC aren't being forwarded by the bridge interface, I can see it arrive at the bridge interface but doesn't get forwarded thereafter.

I've configured the kernel state to have arp/iptables ignore bridge traffic through changing the following fields
* bridge-nf-call-arptables
* bridge-nf-call-iptables
* bridge-nf-call-ip6tables

From my understanding and how I've configured the bridge, it should behave just like a switch, so I'd expect that multicast MAC address to be forwarded to all virtual interfaces by the bridge interface.

It seems frames is being filtered out by IP, how can I get these traffic to be passed to all virtual interface? Thanks in advance.

[dave558]

Some more information about how the system's configure, ebtables and iptables are used for L2/L3 filtering. A virtual IP. (192.168.1.1) has a multicast MAC paired with it (03:11:11:11:11:11). Although the Ethernet MAC is multicast, it's not being forwarded to all virtual interface on the network. Interfaces on the system is the bridge interface (br0) and multiple virtual interface for the guest (vnet0, vnet1, vnet2, etc.).

ARP, NLB and various other broadcast traffic is getting through to all virtual interfaces, so it just this IP with the multicast Ethernet address that's having issues. After analysing the traffic again, I noticed that the ICMP request does arrive at the bridge interface but it doesn't not get forwarded to the virtual interface. ebtables has been configured to filter by bridging, so it should be forwarding packets to the virtual interfaces based on MAC multicasting.

It seems to be these frames for L3 filtering instead of L2. Will try a few a things to see if I can fix the problem.

In the meantime, any suggestions will be greatly appreciated. Thank you.

[dave558]

Ok, ebtables is definitely not forwarding packets for iptables to process.

IPtables only processes packets intended for the bridge interface itself. All the bridge traffic gets passed to straight to the virtual interface as soon as it arrives as expected; I have configured system variables to not have IPtables filter any bridge traffic and for it to pass straight to the vnets.

So the problem here is occurring at the bridge interface and possible with ebtables. When packet arrives, it appears decision is made by looking at the type of traffic on whether to multicast/broadcast frames. e.g. ARP, NLB will get through. With IP packets, the bridge does create a table of MAC and associated virtual ports. IP packet with a matching destination port will simply get placed in ebtables' forward chain and which then gets forwarded to the intended target.

However, IP with multicast MAC address seems to simply get dropped. Will see if there's a work around.

[dave558]

Seems ebtables just doesn't know what to do with IP packets with multicast MAC addresses and simply dropping them. From the tests I ran, I think ebtables checks for protocol type firstly and if it's a multicast/broadcast type like ARP/NLB etc, the ports will be flooded.

However, with IP packets it doesn't seem to pick up the convention of multicast MAC address ie first significant bit set in the first octet of the MAC, hence doesn't flood all ports. I've forwarding packets to known multicast MAC address such as CDP/STP but to no avail.

I have managed to work around problem by forwarding to the broadcast MAC address by using the following:
ebtables -t nat -A PREROUTING -d 03:11:11:11:11:11 -j dnat --to-destination ff:ff:ff:ff:ff:ff

It works and due to the layout of my network, it shouldn't make any difference whether traffic is broadcast or multicast. Anyway, I might write to the developers about this and see if it's indeed a bug of some sort.