7
Linux: einige Minuten nach Gruppeneintritt funktioniert Multicast nicht mehr
Hallo alle miteinander,
vor einer Weile hatte ich einige Fragen in Bezug auf UPnP und das Routing/die Firewall-Konfiguration in dem Zusammenhang. Zuhause habe ich zwei (drei) Subnetze eingerichtet, um die Server- von den Client-Hosts zu trennen, wobei ein APU2E4-Board mit Debian als Router/Firewall fungiert. Darauf läuft unter anderem SMCRoute, um die UPnP/SSDP-Anfragen von Medien-Playern im "User-Netz" zum Medien-Server (minidlna) im zweiten Subnetz möglich zu machen.
Insgesamt funktioniert das nun alles einwandfrei (inkl. Firewall mit iptables) - bis es vor ein paar Tagen dann damit, aus für mich nicht nachvollziehbaren Gründen, vorbei war. Von einem Moment auf den nächsten, und ohne, dass ich etwas an der Konfiguration geändert hätte, wurde der Medien-Server im anderen Subnetz nicht mehr gefunden (das gleiche Problem trat bereits früher zwei oder dreimal auf, konnte aber durch einen Neustart der Firewall "behoben" werden). Also habe ich angefangen, mir die Situation genauer anzuschauen und bin auf Folgendes gestoßen:
Nachdem SMCRoute gestartet wurde, dauert es einige wenige Minuten, bis die beschriebene Situation auftritt. Wird SMCRoute neu gestartet oder verlasse ich manuell die MC-Gruppe (239.255.255.250) und rejoine (smcroutectl leave/join enp1s0 239.255.255.250), funktioniert es wieder für einige Minuten, bis sich die Situation wiederholt.
Mit tcpdump konnte ich feststellen, dass dann gar keine Pakete an 239.255.255.250 mehr auf der Schnittstelle registriert werden (auf der zweiten hingegen schon). ip maddress listet das Interface nach wie vor als Mitglied der MC-Gruppe.
Darüber hinaus habe ich einen Test mit iperf gemacht: auf der Server- und auf der Client-Seite. Das führt zum gleichen Problem. Zuerst registriert der iperf-Server die Anfragen vom Client – doch ein paar Minuten später ist es damit vorbei. Da SMCRoute zu der Zeit nicht lief (und auch sonst keine MC-Routen etabliert worden waren), scheint es sich also eher allgemein um ein Problem mit Multicast zu handeln und nicht speziell um ein MC-Routing-Problem. Zusammengefasst würde ich es damit so beschreiben:
Ein paar Minuten, nachdem ein Interface einer MC-Gruppe beigetreten ist, kommen keine Pakete an die entsprechende MC-Adresse auf diesem Interface mehr an (bis man die Gruppe verlassen und neu betreten hat).
Ich war die letzten Tage auf der Suche nach Erklärungen und Lösungen, konnte aber rein gar nichts in der Richtung finden. Hat vielleicht hier jemand eine Idee, worum es sich dabei handeln könnte? Oder zumindest, in welche Richtung ich suchen sollte, um der Ursache auf die Spur zu kommen?
Vielen Dank und bis später.
vor einer Weile hatte ich einige Fragen in Bezug auf UPnP und das Routing/die Firewall-Konfiguration in dem Zusammenhang. Zuhause habe ich zwei (drei) Subnetze eingerichtet, um die Server- von den Client-Hosts zu trennen, wobei ein APU2E4-Board mit Debian als Router/Firewall fungiert. Darauf läuft unter anderem SMCRoute, um die UPnP/SSDP-Anfragen von Medien-Playern im "User-Netz" zum Medien-Server (minidlna) im zweiten Subnetz möglich zu machen.
Insgesamt funktioniert das nun alles einwandfrei (inkl. Firewall mit iptables) - bis es vor ein paar Tagen dann damit, aus für mich nicht nachvollziehbaren Gründen, vorbei war. Von einem Moment auf den nächsten, und ohne, dass ich etwas an der Konfiguration geändert hätte, wurde der Medien-Server im anderen Subnetz nicht mehr gefunden (das gleiche Problem trat bereits früher zwei oder dreimal auf, konnte aber durch einen Neustart der Firewall "behoben" werden). Also habe ich angefangen, mir die Situation genauer anzuschauen und bin auf Folgendes gestoßen:
Nachdem SMCRoute gestartet wurde, dauert es einige wenige Minuten, bis die beschriebene Situation auftritt. Wird SMCRoute neu gestartet oder verlasse ich manuell die MC-Gruppe (239.255.255.250) und rejoine (smcroutectl leave/join enp1s0 239.255.255.250), funktioniert es wieder für einige Minuten, bis sich die Situation wiederholt.
Mit tcpdump konnte ich feststellen, dass dann gar keine Pakete an 239.255.255.250 mehr auf der Schnittstelle registriert werden (auf der zweiten hingegen schon). ip maddress listet das Interface nach wie vor als Mitglied der MC-Gruppe.
Darüber hinaus habe ich einen Test mit iperf gemacht:
iperf -s -u -B 239.255.255.250 i 1iperf -c 239.255.255.250 -u -T 32 t 3 i 1Ein paar Minuten, nachdem ein Interface einer MC-Gruppe beigetreten ist, kommen keine Pakete an die entsprechende MC-Adresse auf diesem Interface mehr an (bis man die Gruppe verlassen und neu betreten hat).
Ich war die letzten Tage auf der Suche nach Erklärungen und Lösungen, konnte aber rein gar nichts in der Richtung finden. Hat vielleicht hier jemand eine Idee, worum es sich dabei handeln könnte? Oder zumindest, in welche Richtung ich suchen sollte, um der Ursache auf die Spur zu kommen?
Vielen Dank und bis später.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 589175
Url: https://administrator.de/contentid/589175
Ausgedruckt am: 14.11.2024 um 01:11 Uhr
7 Kommentare
Neuester Kommentar
Zuhause habe ich zwei (drei) Netzwerke eingerichtet,
Was denn nun 2 oder 3 ??Noch eine Frage vorab:
Die Netzwerk Switches die deine 2 oder 3 Netze bedienen sind das ungemanagte Dummswitches oder können die IGMP Snooping ? Wenn ja...
- Ist das aktiviert ?
- Welche IGMP Version ?
- Wer ist der Querier im Netz bzw. ist die Querier Funktion aktiviert im Switch ?
Fehlersuche im lokalem Netzwerk (RSTP, MRP, Multicast)
MC Hammer und/oder VLC sind also wie immer deine besten Freunde dabei !
Es sind insgesamt drei Netze, eins davon ist allerdings für das MC-Routing nicht relevant (es gibt auch keinen entsprechenden Eintrag in der smcroute.conf).
Einen Switch gibt es in dem Zusammenhang gar nicht (auch keine Bridge-Schnittstellen beim Router). Es existiert nur das APU2E4-Board als Router, wobei auf der einen Seite (über 2 NICs mit je eigenem Subnetz) ein Server (Proxmox VE) und auf der anderen eine FritzBox als Internet-Gateway und WLAN-AP angeschlossen ist. Die Clients/Medien-Player befinden sich im WLAN und sollen auf den Medien-Server (Container) in einem der beiden Server-Netze zugreifen können.
(Korrektur: ) Der Router kann auf allen Interfaces IGMP v3 verwenden. Starte ich minidlna, wird v3 registriert, beim VLC jedoch v2.
Danke schon mal für den Link.
Ergänzung: ansonsten ist mir noch aufgefallen, dass ein IGMP-Report zu 239.255.255.250 vom Router-Interface zum User-Netz (enp1s0) verschickt wird, wenn SMCRoute gestartet wurde - danach aber nicht mehr.
Einen Switch gibt es in dem Zusammenhang gar nicht (auch keine Bridge-Schnittstellen beim Router). Es existiert nur das APU2E4-Board als Router, wobei auf der einen Seite (über 2 NICs mit je eigenem Subnetz) ein Server (Proxmox VE) und auf der anderen eine FritzBox als Internet-Gateway und WLAN-AP angeschlossen ist. Die Clients/Medien-Player befinden sich im WLAN und sollen auf den Medien-Server (Container) in einem der beiden Server-Netze zugreifen können.
(Korrektur: ) Der Router kann auf allen Interfaces IGMP v3 verwenden. Starte ich minidlna, wird v3 registriert, beim VLC jedoch v2.
Danke schon mal für den Link.
Ergänzung: ansonsten ist mir noch aufgefallen, dass ein IGMP-Report zu 239.255.255.250 vom Router-Interface zum User-Netz (enp1s0) verschickt wird, wenn SMCRoute gestartet wurde - danach aber nicht mehr.
tja wenn das join group "vergessen" wird dann ist da halt doch irgendeine Art von Spoofing aktiv bzw eine Fehlfunktion.
Normalerweise hast du beim Starten ein "join group" an 224.0.0.1 bzw. 224.0.0.22, das sind virtuelle IPs die der Router / Switch / ddein APU2E4 emulieren muß da alle Management-Aktiviten (hier join / leave group) an genau diesese beiden Addressen gehen, und nur der "normale" Multicast Traffic geht dann an die regulär registrierte IP (bei dir wohl 239.255.255.250)
Tausch das Ding mal gegen einen Hub oder Switch der für Multicast transparent ist.
Normalerweise hast du beim Starten ein "join group" an 224.0.0.1 bzw. 224.0.0.22, das sind virtuelle IPs die der Router / Switch / ddein APU2E4 emulieren muß da alle Management-Aktiviten (hier join / leave group) an genau diesese beiden Addressen gehen, und nur der "normale" Multicast Traffic geht dann an die regulär registrierte IP (bei dir wohl 239.255.255.250)
Tausch das Ding mal gegen einen Hub oder Switch der für Multicast transparent ist.
Ich konnte das Problem in der Zwischenzeit beheben. Es war einfach die Firewall, die die einkommenden IGMP-Reports blockiert hat... Nun kann ich zwar nicht verstehen, warum das vorher anstandslos funktioniert hat (dass die Firewall die ganze Zeit nicht aktiv war, ist mehr als unwahrscheinlich...), aber immerhin läuft es jetzt (wieder).
ie die einkommenden IGMP-Reports blockiert hat...
Kleine Ursache...große Wirkung.Fazit: Bei Firewalls besser 2mal ins Regelwerk sehen.
Im Grunde kann man dort immer eine Regel ALLOW 224.0.0.0 /4 eingeben um sicher zu gehen.
Ja, in der Tat... Immerhin war das eine Gelegenheit, etwas über Multicast zu lernen 
Das heißt, hier gleich den ganzen Adressbereich zuzulassen, ist keine "bad practice"?
Ich habe nun erstmal folgende Regel hinzugefügt:
War aber am Überlegen, ob ich das nicht einschränken sollte, wenn ich weiß, dass nur bestimmte Adressen verwendet werden, etwa:
Das heißt, hier gleich den ganzen Adressbereich zuzulassen, ist keine "bad practice"?
Ich habe nun erstmal folgende Regel hinzugefügt:
-A INPUT -s 192.168.0.0/24 -d 224.0.0.0/4 -i enp1s0 -p igmp -j ACCEPTWar aber am Überlegen, ob ich das nicht einschränken sollte, wenn ich weiß, dass nur bestimmte Adressen verwendet werden, etwa:
-A INPUT -s 192.168.0.0/24 -d 224.0.0.1,224.0.0.2,224.0.0.22,239.255.255.250 -i enp1s0 -p igmp -j ACCEPTwenn ich weiß, dass nur bestimmte Adressen verwendet werden, etwa:
Ist natürlich etwas wasserdichter. Nur da MC ja nicht im öffentlichen Internet übertragen wird ist das vernachlässigbar.
