Многоадресная рассылка в локальной сети не принимается всеми хостами

619
André Fernandes

Я пишу приложение для получения многоадресных обновлений с устройства измерения тока, которое подключено к моей локальной сети. Устройство отправляет пакеты в группу многоадресной рассылки 224.192.32.19:22600 каждые несколько минут, и я могу их нормально читать с одного из хостов (Raspberry Pi).

Странно то, что когда я пытался добавить второй хост слушателя, я не мог найти многоадресный трафик из этой группы на ее интерфейсе.

Схема сети следующая: network layout

Вся сеть находится в одном физическом месте, в одной подсети 192.168.xx. Между отправителем и получателем (ями) находятся 2 маршрутизатора TP-Link WDR3600 с DD-WRT и «тупой» 8-портовый гигабитный коммутатор TP-Link (используется в качестве расширителя портов). Все подключено через Ethernet.

Более подробная информация:

  • Хосты «NOK» включают в себя ноутбук с Windows 7, подключенную к Linux виртуальную машину на том же ноутбуке и другой ноутбук с Linux
  • подключение хоста «NOK» непосредственно к немому коммутатору, где хост «OK» не имеет никакого эффекта
  • подключение напрямую к вторичному маршрутизатору (1 Ethernet-узел, расположенный ближе к источнику) не имеет никакого эффекта
  • Я не могу найти трафик IGMP для этой группы ни на одном из хостов, включая рабочий
  • Наблюдая за сетевым трафиком для IGMP, я вижу 2 запроса на присоединение, 224.0.0.22когда мое приложение запускается.

Членство в группе регистрируется ядром и отображается

~ $ netstat -ng IPv6/IPv4 Group Memberships Interface RefCnt Group --------------- ------ --------------------- lo 1 224.0.0.1 eth0 1 224.192.32.19 eth0 1 224.0.0.251 eth0 1 224.0.0.1 

Код Python, который инициализирует сокет из приложения слушателя, выглядит так:

sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM, socket.IPPROTO_UDP) sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) sock.bind((self.mcast_group, self.mcast_port)) mreq = struct.pack("4sl", socket.inet_aton(self.mcast_group), socket.INADDR_ANY) sock.setsockopt(socket.IPPROTO_IP, socket.IP_ADD_MEMBERSHIP, mreq) 

Что мне здесь не хватает? Достаточно просто запустить приложение прослушивателя на рабочем хосте, чтобы получить многоадресный трафик. Почему это не относится к дополнительным прослушивателям?

0
Если хосты не говорят на IGMP, они _should_ - по крайней мере, чтобы сделать их на будущее, когда некоторые из ваших коммутаторов начинают полагаться на это. grawity 7 лет назад 0
Вы показываете два маршрутизатора на своей диаграмме, но не говорите, какие подсети находятся вне каждого интерфейса (маршрутизаторам нужны разные подсети для каждого интерфейса). Я думаю, что вы, возможно, используете устройства с поддержкой маршрутизации, но на самом деле вы используете их только в качестве коммутаторов, поэтому у вас их неправильно помечают, и это делает вашу диаграмму запутанной. Вы можете исправить свою диаграмму? Spiff 7 лет назад 0
Вы правы, в контексте этой проблемы они используются исключительно как коммутаторы уровня 2 (все находится в одной подсети IP). Это не делает недействительным тот факт, что они являются маршрутизаторами. Этот факт и использование DD-WRT может помочь найти решение или способ устранения неполадок. André Fernandes 7 лет назад 0
Тот факт, что они являются маршрутизаторами, имеет значение, только если ваш трафик маршрутизируется. Многоадресная передача, как и широковещательная рассылка, не маршрутизируется так, как одноадресная. Можно использовать многоадресную маршрутизацию, но она сильно отличается от одноадресной маршрутизации. Многоадресная рассылка с IGMP имеет особые проблемы в сетях с несколькими коммутаторами. Соединение типа «коммутатор-коммутатор» не передает запросы IGMP, если не существует mrouter. У меня есть [ответ] (http://networkengineering.stackexchange.com/a/28302/8499) на NESE, который объясняет проблему и решения для коммутаторов Cisco и HP. Ron Maupin 7 лет назад 0

1 ответ на вопрос

0
André Fernandes

Оказывается, это была проблема маршрутизатора, после перезапуска вторичного маршрутизатора все хосты начали получать многоадресные пакеты, как и ожидалось.

Я бы сказал, что это либо ошибка DD-WRT, либо какое-то повреждение состояния, которое скомпрометировало распределение многоадресного трафика.