TransWikia.com

Multicast frames in Linux bridge dropped

Unix & Linux Asked by Tanvir K on December 29, 2021

I have one VM running on an x86 host using libvirt. The interface of the VM is created as follows :

<interface type='bridge'>
      <mac address='52:54:00:d0:18:eb'/>
      <source bridge='intfe2'/>
      <target dev='vnet4'/>
      <model type='virtio'/>
      <alias name='net4'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/>
    </interface>

intfe2 = Linux bridge that exists on the host as follows:

# brctl show intfe2
bridge name     bridge id               STP enabled     interfaces
intfe2          8000.90e2bab68ff8       no              enp2s0f0
                                                        vnet4

Now, LACP is configured inside the VM on interface vnet4 and same has been configured on an actual router that uses the interface enp2s0f0 of the host machine.

I can see multicast frames coming from both these interfaces on the host.

# tcpdump -ni vnet4 -e
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vnet4, link-type EN10MB (Ethernet), capture size 262144 bytes
15:56:48.160017 34:30:b4:59:06:00 > 01:80:c2:00:00:02, ethertype Slow Protocols (0x8809), length 124: LACPv1, length 110
15:56:49.162163 34:30:b4:59:06:00 > 01:80:c2:00:00:02, ethertype Slow Protocols (0x8809), length 124: LACPv1, length 110

# tcpdump -ni enp2s0f0 -e
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp2s0f0, link-type EN10MB (Ethernet), capture size 262144 bytes
15:57:46.173002 ac:4b:c8:89:d7:c1 > 01:80:c2:00:00:02, ethertype Slow Protocols (0x8809), length 124: LACPv1, length 110
15:57:47.171282 ac:4b:c8:89:d7:c1 > 01:80:c2:00:00:02, ethertype Slow Protocols (0x8809), length 124: LACPv1, length 110
15:57:48.171252 ac:4b:c8:89:d7:c1 > 01:80:c2:00:00:02, ethertype Slow Protocols (0x8809), length 124: LACPv1, length 110

I’m running Ubuntu Xenial:

# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 16.04.2 LTS
Release:        16.04
Codename:       xenial

My questions are :

  1. Why are they not flooded ?
  2. Does linux bridge avoids forwarding L2 multicast frames ?

From some links like multicast frames in Linux virtual-switch I even disabled the IGMP snooping as follows :

echo "0" > /sys/devices/virtual/net/intfe2/bridge/multicast_snooping

Also toggling the values for /sys/devices/virtual/net/intfe2/bridge/multicast_querier

Any pointers?

2 Answers

I think the issue you're hitting is that, by default, a Linux bridge will not forward frames to a destination MAC address in the range 01:80:c2:00:00:00 through 01:80:c2:00:00:0f. The IEEE reserved this block of addresses for protocols that must not be forwarded by a MAC bridge. Protocols such as LLDP, LACP, xSTP, etc., are all in this range.

There's a nice IEEE write-up, Standard Group MAC Addresses: A Tutorial Guide. If you're up for it, it is possible to recompile the bridge kernel module to allow forwarding of these frames, but do so at your own peril! You'll need to edit <source_path>/net/bridge/br_private.h and set the #define for BR_GROUPFWD_RESTRICTED to 0x0u. Compile and reload the driver, and then run:

echo 255 > /sys/class/net/<bridge_name>/bridge/group_fwd_mask

Note that this will let through not just LLDP, but spanning tree frames as well. So be sure you don't introduce any bridging loops!

Answered by TerpEE93 on December 29, 2021

It is a bit difficult for me to understand exactly your setup with the available information. But I will give you my setup so you can look and compare. Essential for multicast on bridges is multicast snooping so the bridge knows which port has joined to a multicast group and can forward multicast streams only to this port. Default setting of multicast_snooping is on. So I do not disable it.

If I look at the settings of the interfaces on my bridge it shows me this:

host ~$  sudo bridge -d link show
3: enp1s0 state UP : <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br0 state forwarding priority 32 cost 4
    hairpin off guard off root_block off fastleave on learning on flood on mcast_flood on
5: vnet0 state UNKNOWN : <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br0 state forwarding priority 32 cost 100
    hairpin off guard off root_block off fastleave on learning on flood off mcast_flood on

Important is mcast_flood on which is default setting. fastleave on is nice to have but not needed for multicast. It's only for leaving a multicast group without a timeout on the bridge if a guest leaves the group. flood on/off belongs to unicast and is here not relevant.

If a guest joins a multicast group (starting a multicast client program) the bridge snoops it and add it to its multicast database (mdb). I check it with:

host ~$ sudo bridge -d -s mdb show
dev br0 port vnet0 grp 239.255.255.250 temp  vid 10 257.14
router ports on br0: enp1s0  238.17 temp

I have just a upnp client running (grp 239.255.255.250) and use VLAN 10. The guest will still stay in the multicast group for 257.14 seconds if it does not send a igmp REPORT to stay longer. The bridge sees that the next multicast router (the source) is on port enp1s0 and will kick it out after 238.17 seconds if the source does not send a igmp QUERY before.

On a running multicast stream I see this igmp messages:

host ~$ sudo tcpdump -i vnet0 -n igmp
18:38:59.628249 IP 192.168.10.2 > 224.0.0.1: igmp query v3
18:39:02.502110 IP 192.168.10.106 > 224.0.0.22: igmp v3 report, 2 group record(s)
18:41:04.647731 IP 192.168.10.2 > 224.0.0.1: igmp query v3
18:41:13.061858 IP 192.168.10.106 > 224.0.0.22: igmp v3 report, 2 group record(s)
18:43:09.637111 IP 192.168.10.2 > 224.0.0.1: igmp query v3
18:43:19.525836 IP 192.168.10.106 > 224.0.0.22: igmp v3 report, 2 group record(s)
...

192.168.10.2 is my internet router (multicast source) and 192.168.10.106 is the guest with streaming client.

Answered by Ingo on December 29, 2021

Add your own answers!

Ask a Question

Get help from others!

© 2024 TransWikia.com. All rights reserved. Sites we Love: PCI Database, UKBizDB, Menu Kuliner, Sharing RPP