Multicast im LAN nicht von allen Hosts empfangen

695
André Fernandes

Ich schreibe eine Anwendung, um Multicast-Updates von einem Strommessgerät zu erhalten, das in mein LAN eingesteckt ist. Das Gerät sendet alle paar Minuten Pakete an die Multicast-Gruppe 224.192.32.19:22600, und ich kann sie von einem der Hosts (einem Himbeer-Pi) lesen.

Das Seltsame ist, dass ich beim Versuch, einen zweiten Listener-Host hinzuzufügen, keinen Multicast-Verkehr von dieser Gruppe auf seiner Benutzeroberfläche finden konnte.

Das Netzwerklayout ist wie folgt: Netzwerklayout

Das gesamte Netzwerk befindet sich am selben physischen Standort unter demselben Subnetz 192.168.xx. Zwischen Sender und Empfänger befinden sich 2 TP-Link WDR3600-Router, auf denen DD-WRT ausgeführt wird, sowie ein "dummer" TP-Link-Gigabit-Switch mit 8 Ports (als Porterweiterung). Alles ist über Ethernet verbunden.

Weitere Details:

  • Zu den "NOK" -Hosts gehören ein Windows-7-Laptop, eine überbrückte Linux-VM auf demselben Laptop und ein anderer Linux-Laptop
  • Wenn Sie einen "NOK" -Host direkt an den Dumb-Switch anschließen, bei dem sich der "OK" -Host befindet, hat dies keine Auswirkungen
  • Ein direktes Anschließen an den sekundären Router (1 Ethernet "Hop" näher an der Quelle) hat keine Auswirkungen
  • Ich kann keinen IGMP-Verkehr für diese Gruppe auf einem der Hosts finden, einschließlich des funktionierenden
  • Snooping des Netzwerkverkehrs für IGMP Ich sehe zwei Join-Anforderungen, die 224.0.0.22beim Start meiner Anwendung ausgeführt werden.

Die Gruppenmitgliedschaft wird vom Kernel registriert und von angezeigt

~ $ 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-Code, der den Socket aus der Listener-Anwendung initialisiert, lautet wie folgt:

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) 

Was fehlt mir hier? Das Ausführen der Listener-Anwendung auf dem funktionierenden Host war ausreichend, um den Multicast-Datenverkehr zu empfangen. Warum ist dies nicht der Fall für die zusätzlichen Listener?

0
Wenn die Hosts kein IGMP sprechen, sollten sie - falls überhaupt - zumindest, um sie zukunftssicher zu machen, wenn einige Ihrer Switches sich darauf verlassen. grawity vor 7 Jahren 0
Sie zeigen zwei Router in Ihrem Diagramm an, sagen jedoch nicht aus, welche Subnetze die einzelnen Schnittstellen haben (Router benötigen unterschiedliche Subnetze für jede Schnittstelle). Ich denke, Sie verwenden möglicherweise routingfähige Geräte, aber Sie verwenden sie eigentlich nur als Switches, daher haben Sie sie falsch etikettiert und das Diagramm wird verwirrend. Können Sie Ihr Diagramm korrigieren? Spiff vor 7 Jahren 0
Sie haben recht, im Kontext dieses Problems werden sie lediglich als Layer-2-Switches verwendet (alles befindet sich im selben IP-Subnetz). Die Tatsache, dass es sich um Router handelt, wird dadurch jedoch nicht ungültig. Diese Tatsache und die Ausführung von DD-WRT könnten dazu beitragen, eine Lösung oder einen Weg zur Fehlerbehebung zu finden. André Fernandes vor 7 Jahren 0
Die Tatsache, dass es sich um Router handelt, ist nur von Bedeutung, wenn der Datenverkehr geroutet wird. Multicast wird wie Broadcast nicht so weitergeleitet wie Unicast. Möglicherweise kann Multicast-Routing verwendet werden, unterscheidet sich jedoch erheblich vom Unicast-Routing. Multicast mit IGMP hat besondere Probleme bei LANs mit mehreren Switches. Eine Switch-to-Switch-Verbindung leitet IGMP-Anforderungen nur dann weiter, wenn es einen Mrouter gibt. Ich habe [eine Antwort] (http://networkengineering.stackexchange.com/a/28302/8499) zu NESE, in der das Problem und die Lösungen für Cisco- und HP-Switches erläutert werden. Ron Maupin vor 7 Jahren 0

1 Antwort auf die Frage

0
André Fernandes

Es stellte sich heraus, dass dies ein Routerproblem war. Nach dem Neustart des sekundären Routers begannen alle Hosts, die Multicast-Pakete erwartungsgemäß zu empfangen.

Ich würde sagen, es war entweder ein DD-WRT-Fehler oder eine staatliche Korruption, die die Verteilung des Multicast-Verkehrs beeinträchtigte.