IGMPv2 - "Störer": eine Detaildiskussion

Hallo liebe Gleichgesinnte,

 

ich möchte gerne mit euch mal in eine Detaildiskussion einsteigen.
Eins vorneweg: mein Netz und mein IPTV läuft einwandfrei.
Ich bilde mir ein, mein kleines Reich hier im Griff zu haben.

 

Ein paar Basics für den folgenden Austausch:
IGMP = Protokoll für die Verwaltung von Multicast-Gruppen
IGMP-Snooping = belauschen und auswerten von IGMP Nachrichten
IGMP-Querier = aktiver Statusabfrager

 

Auch wenn es für die Thematik eher irrelevant ist hier ein kurzer Abriss über mein Netz:
VDSL-Modem: Digitalisierungsbox Basic - in reinem Modem-Modus (für den Supervectoring 175/40 Anschluss)

Router: bintec/Funkwerk RS353jv (dessen VDSL Modem kann nur Vectoring und ist daher abgeschaltet)

Switch: D-Link DGS-1210-24P (Hardware Revision D; das ist später noch wichtig) = PoE Switch

_ daran _: 2 Stück D-Link DAP 2695 (PoE-powered)

_ daran _: Devolo DINrail 1200 Adapter
_______ daran _: 2 x TP-Link TL-PA8030p mit DX800A, IP-Cam

_ daran _: 2 Stück MR201, ein paar PC, XPENology-NAS, IBM-PDU, etc.
_ daran _: Cisco SLM2008 (PoE-powered)

_______ daran _: MR401, BluRay, SmartTV, Raspberrymatic
_ daran _: Cisco SLM2008 (PoE-powered)
_______ daran _: MR201, LAN-Drucker, Arbeits-PC Frau

_ daran _: Cisco SLM2008 (PoE-powered)
_______ daran _: Arbeits-PC ich, weiterer Privat-PC

 

Um eine Diskussion abzubiegen: der dLAN Strang mit dem Devolo und den TP-Links läuft einwandfrei, sauber, unauffällig und schnell und beeinflusst in keiner Weise das Netz negativ.

 

Jetzt zum eigentlichen Thema:
Der Router fungiert logischerweise als IGMP-Proxy zwischen LAN und WAN. Check,
Multicast wird sauber geroutet, kein Problem hier.

Danach wird's interessant.
Mein DGS-1210-24P, Hardware D, ist "eigentlich" nicht IGMPv3 fähig (das sind erst F und G, laut FAQ auf der D-Link Homepage).
Trotzdem kann ich IGMP-Snooping sauber betreiben.
Der Switch ist natürlich kein Querier. Er sollte daher lauschen und die Joins und Leaves registrieren.
Das tut er auch ganz prima, das Flackern der Port-LED bestätigt, dass Multicast nur selektiv geswitcht wird und nicht an alle Ports geht.
Zudem erkennt er selbständig den Router-Port, den muss ich ihm nicht sagen.

(Hier sollten jetzt die ersten Bilder sein, aber der Virenscan nach dem Upload läuft noch. Steht da jedenfalls.)

 

Ganz anders verhält es sich mit den Cisco-Switches:
Aktiviere ich dort das IGMP-Snooping (Querier sind sie natürlich nicht), dann läuft erstmal alles weiter.
Nach dem Programm-Umschalten des daran hängenden Receivers oder nach Erhalt eines Queries ist Schluss.
Das Bild bleibt nahezu komplett stehen, gefolgt von der bekannten Fehlermeldung des Receivers. Aber nur an diesem Receiver - alle anderen laufen unbeeindruckt weiter.
Deaktiviere ich das IGMP-Snooping wieder, läuft TV augenblicklich weiter. Also nix von wegen 15 Minuten runterfahren und warten, dass der Receiver sich wieder IGMPv3 traut.

 

Jetzt zu meinen Gedanken:
Das Snooping stelle ich mir zunächst als ein rein passives Verhalten vor. Der Switch lauscht auf Joins und Leaves und switcht den zugehörigen Multicast dementsprechend selektiv.
Versteht er die Nachrichten nicht, kann er nicht selektiv switchen.
(An diesem Punkt greift der Menüpunkt, was mit unregistriertem Multicast geschehen soll: broadcasten oder filtern. Woher der Multicast auch immer kommen mag.)
Was genau soll denn ein IGMPv2-Snooper senden, was andere zum "Downgrade" bewegt? Klar, Querier darf er natürlich nicht sein. Dazu habe ich nichts gefunden.

Fragestellung 1: ist das wirklich so passiv?
Gehen die Joins und Leaves tatsächlich einfach nur durch den Switch durch oder aggregiert er die, wenn es mehrere teilnehmende Hosts gibt? Nach meinem angelesenen Verständnis geht der erste Join tatsächlich einfach nur durch. Weitere Joins verwirft er, weil kommt ja schon. Die Frage ist insofern wichtig, weil ein "Nichtverstehen" der Nachrichten dann nicht schädlich ist - der Join läuft trotzdem durch den Switch, mehrere gleiche Joins stören zudem eigentlich nicht.

 

Das könnte übrigens auch diese "komischen" FAQ erklären, die ich mal irgendwo bei Netgear oder so gefunden habe:
Da soll genau dieses "Broadcasten von unregistriertem Multicast" explizit eingeschaltet sein. Der Switch versteht das IGMP dann zwar nicht, blockiert aber auch den Traffic nicht.
Bei meinen Ciscos wiederum hilft diese Option nicht.

 

Fragestellung 2 - die Kernfrage:
Was genau ist eigentlich das Problem, wenn im Netz eine IGMPv2 Komponente vorhanden ist?
Joins und Leaves kennt IGMPv2 ganz genauso, die mitgelieferte zulässige Source  - ajo, die kann der Switch dann halt nicht verarbeiten. So what.
Der v3-Join geht ja trotzdem durch.
Und warum sollte es das komplette Netz lahmlegen? Tut es bei mir definitiv nicht. Betroffen ist nur der Receiver hinter dem jeweiligen Cisco, alle anderen nicht.

Ganz nebenbei: die AP haben auch eine IGMP-Snooping-Funktion. Da dort aber weder IGMP-Messages noch Multicast vorbeikommt, macht sich das Aktivieren/Deaktivieren überhaupt nicht bemerkbar im Netz.
Wobei: die Queries müssten dort eigentlich genauso aufschlagen.

Trivia:
Mein DGS-1210-24P scheint sehr wohl IGMPv3 zu können, auch wenn der Hersteller was anderes meint.

Helft mir bitte mal auf die Sprünge.
Habe ich Denkfehler? Verständnisprobleme?

 

 

 

Hallo @Chili-FFM 

es gibt grundsätzlich kein Problem mit IGMPv2, es gibt nur ein Problem wenn ein weiterer Querier aktiv ist. Ich sehe hier beim Capturen eine Menge V2 Traffic, z.B. von Apple Geräten, wird alles sauber abgehandelt. Die SLM2008 können kein V3 Snooping zumindestens die die ich kenne. Querier haben die aber eigentlich nicht. Block Unknown Multicasts sollte aber auf jeden Fall aus sein. Wenn mein SLM2008 Multicasts broadcasted dann geht ihm bei höheren Datenraten die Puste aus, deswegen und wegen fehlendem V3 ersetzt. War allerdings auch ein älteres Modell.

Bei mir ist's eher andersrum:

Bei den SLM2008 ohne aktiviertes Snooping arbeiten sie problemlos (leiten es an alle aktiven Ports).

Bei dem bisschen Bandbreite sollten das Gigabit-Ports auch problemlos verkraften. 

Bei aktiviertem Snooping geht dann nichts mehr durch. Dafür habe ich keine Erklärung.

Die Querier-Funktion ist natürlich bei allen aus, das ist soweit klar.

 

Mehrere aktive Querier wären zudem auch bei IGMPv3 ein Thema. Das allein kann es also auch nicht sein... 


@Chili-FFM  schrieb:

 

Bei aktiviertem Snooping geht dann nichts mehr durch. Dafür habe ich keine Erklärung.

Block unknown oder Broadcast Storm Prevention?

 


@Chili-FFM  schrieb:

 

Mehrere aktive Querier wären zudem auch bei IGMPv3 ein Thema.


Das ist in allen Variationen ein Thema Zwinkernd

 

Was nur verwunderlich ist, daß der MR ja genau der Meinung ist, da wäre noch ein Querier aktiv.

"Es ist eine fremde Anfrage aktiv" bedeuted ja nun mal genau das.


@viper.de  schrieb:

 

Was nur verwunderlich ist, daß der MR ja genau der Meinung ist, da wäre noch ein Querier aktiv."Es ist eine fremde Anfrage aktiv" bedeuted ja nun mal genau das.

Hä? Wie kommst du darauf? Sowas habe ich nie erwähnt. 


@Chili-FFM  schrieb:

@viper.de  schrieb:

 

Was nur verwunderlich ist, daß der MR ja genau der Meinung ist, da wäre noch ein Querier aktiv."Es ist eine fremde Anfrage aktiv" bedeuted ja nun mal genau das.

Hä? Wie kommst du darauf? Sowas habe ich nie erwähnt. 


Threadtitel und der Satz "Das Bild bleibt nahezu komplett stehen, gefolgt von der bekannten Fehlermeldung des Receivers." sind dann missverständlich...

Als "Störer" wird hier allgemein ein Proxy verstanden, der sich nicht komform verhält und die Füsse stillhalt wenn es bereits einen anderen mit einer niedrigeren IP Adresse gibt.

Das wäre schlüssig, weil er in seiner Proxy-Rolle auch Querier spielen wollte und damit aktiv IGMP-Nachrichten verschicken würde 

Aber vermutlich kein Switch oder AP, der nur IGMPv2 beherrscht, würde gleich Proxy sein wollen. Das ist eher eine Router-Funktion und arbeitet auf höheren OSI-Schichten.

 

Ich verstehe einfach noch nicht, warum ein einfacher (unmanaged) IGMPv2 Switch einen negativen Einfluss auf's IPTV oder gar das ganze Netz haben soll.