Quadros multicast na ponte Linux caíram

Question

Eu tenho uma VM em execução em um host x86 usando libvirt . A interface da VM é criada da seguinte forma:

<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 = Ponte do Linux que existe no host da seguinte forma:

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

Agora, o LACP é configurado dentro da VM na interface vnet4 e o mesmo foi configurado em um roteador real que usa a interface enp2s0f0 da máquina host.

Eu posso ver quadros multicast provenientes dessas duas interfaces no 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

Estou executando o Ubuntu Xenial:

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

Minhas perguntas são:

1. Por que eles não são inundados?
2. A ponte linux evita o encaminhamento de quadros multicast L2?

De alguns links, como quadros multicast no comutador virtual Linux Eu até desabilitei o snooping IGMP da seguinte forma:

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

Também alterna os valores para /sys/devices/virtual/net/intfe2/bridge/multicast_querier

Algum apontador?

    

Answer 1

É um pouco difícil para mim entender exatamente sua configuração com as informações disponíveis. Mas eu vou te dar minha configuração para que você possa olhar e comparar. O essencial para multicast em bridges é o snooping multicast, portanto, a bridge sabe qual porta se uniu a um grupo multicast e pode encaminhar fluxos multicast somente para essa porta. A configuração padrão de multicast_snooping está ativada. Então eu não desabilito isso.

Se eu olhar as configurações das interfaces na minha ponte, isso me mostrará:

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

Importante é mcast_flood on , que é a configuração padrão. fastleave on é bom ter, mas não é necessário para multicast. É apenas para deixar um grupo de multicast sem um tempo limite na ponte se um convidado sair do grupo. flood on/off pertence a unicast e não é relevante aqui.

Se um convidado ingressar em um grupo de multidifusão (iniciando um programa cliente de multicast), a bridge a bisbilhotará e a adicionará ao seu banco de dados multicast (mdb). Eu verifico com:

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

Eu tenho apenas um cliente upnp em execução (grp 239.255.255.250) e uso VLAN 10. O convidado ainda permanecerá no grupo multicast por 257,14 segundos se ele não enviar um RELAT do igmp para ficar mais tempo. A ponte vê que o próximo roteador de multidifusão (a origem) está na porta enp1s0 e a expulsa depois de 238,17 segundos, se a fonte não enviar um igbur QUERY antes.

Em um fluxo multicast em execução, vejo essas mensagens igmp:

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 é o meu roteador de internet (fonte multicast) e 192.168.10.106 é o convidado do cliente de streaming.