Solved
Magenta TV - FB 7590 - IGMPv2 multicast router 0.0.0.0 ignored
6 years ago
Hallo in die Runde,
kurz eines vorweg, habe zu diesem Thema schon den ein oder anderen Beitrag gelesen, bin daraus aber nicht so richtig schlau geworden.
Habe hier einen VVDSL100 mit FB 7590. Magenta TV lief bis vor kurzem eigentlich relativ stabil, dann kam es aber immer öfter vor das es Standbild gab, mit der Meldung "Wiedergabe nicht möglich".
Beim Umschalten gab es während Unicast keine Problem, nach dem switch auf Multicast dann aber wieder extreme Ruckler und kein Ton.
Dachte mir natürlich es liegt an meinem nicht IGMP fähigen Switch (obwohl es bislang, seit Einführung Entertain TV, gut lief) an dem der MR 401 hängt, also den Receiver direkt an LAN1 der FB angeschlossen und alles brav neugestartet. Lief kurz, dann wieder der gleiche Fehler.
Anschließend habe ich alles, außer meinen PC, von den LAN Ports der FB abgezogen und wieder probiert, Fehler bleibt.
Dachte also mein PC ist der Übeltäter. Wireshark gestartet und wirklich merkwürdige Einträge gesehen.
Der Receiver sendet, warum auch immer, IGMPv2 Leave Group Messages, anschließend kommen von der Source IP 0.0.0.0 Membership Querys, das ganze sieht sich die FB wohl eine gewisse Zeit an (mal haben 6 Messages gereicht, mal 200), anschließend Standbild und Fehler "IGMPv2 multicast router 0.0.0.0 ignored" im Log der FB .
Lösen konnte ich das ganze bisher, indem ich den MR einfach mal zurückgesetzt hab, seitdem läuft er wunderbar und nicht ein einziges IGMPv2 Paket, alles nur v3.
Nun aber die Frage.
Wie kommt es zu diesen IGMPv2 Verhalten am MR , kann dies durch den nicht IGMPv3 fähigen Switch kommen an dem der Receiver hängt und wenn ja, warum war der Fehler dann immer noch da wenn ich den MR direkt an die FB anschließe und beides zusammen neu starte?
Habe bei anderen Beiträgen immer wieder den Begriff IGMP Störer gelesen, kann mir darauf aber keinen Reim machen, warum sollte der meinen MR “stören” und zum Rückfall auf v2 zwingen. Bei der Fehlersuche nach so einem “Störer” wird es eh schwierig, da in diesem Netzwerk extrem viele Geräte hängen, paar IP Kameras, Repeater, Richtfunk-WLAN inkl. zusätzlichem AP in meinem Nebengebäude, 5 Rechner, unzählige Geräte per WLAN, PV Anlage, Energie Manager usw.
Könnt mich mit Fachbegriffen bombardieren, komme aus der Netzwerkwelt. Nur das Verhalten hier kann ich mir bisher nicht erklären
Zur ersten Fehlereingrenzung lasse ich den MR einfach mal dauerhaft laufen solange alles geht und dazu Wireshark auf meinem Server, der sollte dann ja sehen wenn ein “Störer” zuschlägt.
Bin für jeden weiteren Tipp dankbar.
Das ich den Switch, an dem der MR hängt tausche, habe ich mir übrigens fest vorgenommen, nur das Verhalten würde ich eben gerne aus technischer Sicht und auf Protokollebene verstehen.
Gleichzeitg würde es mir vermutlich wenig bringen diesen Switch zu tauschen, wenn es dann auch noch von anderen Quellen Einflüsse geben könnte. Grundsätzlich habe ich aber an jedem anderem Gerät (AP, Switches) IGMP Snooping deaktiviert, soweit dies einstellbar war.
So, sorry für den langen Text, aber kurz lässt sich sowas schwer zusammenfassen
7437
22
This could help you too
641
0
7
4 years ago
1479
0
1
1600
0
8
Accepted Solution
accepted by
6 years ago
Es reicht nicht, wenn die FB die Queries ignoriert - was sie laut Logmeldung ja sogar durchaus macht.
Der/Die/Das v2 Query darf bei keinem anderen Multicast-Teilnehmer ankommen. Denn der Standard schreibt einem IGMPv3 Gerät vor bei Eintreffen eines v2 Pakets auf IGMPv2 runter zu gehen. Deshalb wird manchmal von einem "Störer" gesprochen. Ein v1 oder v2 Gerät im Netz reicht aus um das ganze Netz "runterzuziehen" und das ganze Netz muss nach Abschalten des Störers zurückgesetzt werden, damit es sich wieder traut v3 zu sprechen.
Normalerweise ist das Verhalten auch eher unkritisch. Im Fall von IPTV ist es aber problematisch weil IGMPv2 die SSM -Option nicht mehr hat und die ist mittlerweile Pflicht. Ohne SSM wird an vielen Anschlüssen der Multicast nicht mehr zum Router geliefert und dann hat der selbst gar nichts zum Weiterleiten, selbst wenn er gar nicht aktiv blockt.
0
Accepted Solution
accepted by
6 years ago
Muss diesen alten Beitrag mal aktualisieren.
Mittlerweile wurde mir vom Hersteller des Energie Managers eine Beta-Firmware bereitgestellt die das IGMPv2 Problem löst.
Firmware läuft 1a und es treten keinerlei Störungen mehr auf.
Wer also Probleme mit einem B-control EM 300 (hat den überhaupt einer
) hat, dem kann geholfen werden.
Muss die Firma B-Control bzw. TQ-Automation hier auch mal lobend erwähnen, erlebt man wohl eher selten das soetwas in dann doch so "relativ" kurzer Zeit behoben wird.
0