Многоадресные кадры в мосте Linux отброшены

Мне немного сложно понять вашу настройку с имеющейся информацией. Но я дам вам свою установку, чтобы вы могли посмотреть и сравнить. Существенным для многоадресной рассылки на мостах является отслеживание многоадресной рассылки, поэтому мост знает, какой порт присоединился к группе многоадресной рассылки, и может пересылать многоадресные потоки только на этот порт. По умолчанию отслеживание многоадресной рассылки _включено. Так что не отключаю.

Если я посмотрю настройки интерфейсов на моем мосту, то у меня появится вот это:

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

Важным является mcast_flood on, который является настройкой по умолчанию. fastleave onхорошо иметь, но не нужен для многоадресной рассылки. Это только для выхода из группы многоадресной рассылки без тайм-аута на мосту, если гость покидает группу. flood on/offотносится к одноадресной передаче и здесь не имеет значения.

Если гость присоединяется к группе многоадресной рассылки (, запуская клиентскую программу многоадресной рассылки ), мост отслеживает его и добавляет в свою базу данных многоадресной рассылки (mdb ). Я проверяю это с помощью:

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

У меня есть только клиент upnp, работающий (grp 239.255.255.250 )и использующий VLAN 10. Гость по-прежнему будет оставаться в группе многоадресной рассылки в течение 257,14 секунд, если он не отправит отчет igmp, чтобы остаться дольше. Мост видит, что следующий многоадресный маршрутизатор (источник )находится на порту enp1s0 и отключит его через 238,17 секунды, если источник не отправит igmp QUERY раньше.

В работающем многоадресном потоке я вижу это сообщение 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 — мой интернет-маршрутизатор (источник многоадресной рассылки ), а 192.168.10.106 — гость с потоковым клиентом.

Я думаю, проблема, с которой вы столкнулись, заключается в том, что по умолчанию мост Linux не будет пересылать кадры на MAC-адрес назначения в диапазоне 01 :80 :c2 :00 :00 :от 00 до 01 :80 :c2 :00 :00 :0f. IEEE зарезервировал этот блок адресов для протоколов, которые не должны пересылаться мостом MAC. Такие протоколы, как LLDP, LACP, xSTP и т. д., находятся в этом диапазоне.

Есть хорошая запись IEEE -, Стандартные групповые MAC-адреса :Учебное руководство . Если вы готовы к этому, можно перекомпилировать модуль ядра моста, чтобы разрешить пересылку этих кадров, но делаете это на свой страх и риск! Вам нужно будет отредактировать <source_path>/net/bridge/br_private.hи установить #defineдля BR_GROUPFWD_RESTRICTEDна 0x0u. Скомпилируйте и перезагрузите драйвер, а затем запустите:

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

Обратите внимание, что это позволит пропускать не только LLDP, но и фреймы связующего дерева. Поэтому убедитесь, что вы не вводите никаких связующих петель!