IGMP - Unterschiedliche Querier (Mixed Switch Network)
Hallo Admins!
Ich benötige eure Inspiration bei der weiteren Fehlersuche zum Thema Multicast (IPv4).
Wir haben seit einiger Zeit (nach der Aktualisierung der Serverlandschaft) Problem mit Geräten im Netzwerk, die
Ihre Konfiguration über Multicast abgleichen (evtl. schon vorher, vielleicht ist es nicht so aufgefallen).
Anfänglich hatte wir massive Störungen bei diesen Geräten, die ich im nachhinein auf Broadcasting schieben möchte.
Nach Prüfung/Aktivierung von IGMP Snooping auf allen Switchen und der Umkonfiguration eines Routers (genauer: die
IP-Adresse) hatte sich die Sache etwas beruhigt, allerdings waren die o.g. speziellen Geräte weiterhin von Störungen
betroffen.
Nach intensiver Beobachtung kam ich zu dem Schluß, daß das IGMP Snooping (und speziell die Sache mit dem Querier)
irgendwie nicht rund läuft. Erschwerend kommt hinzu, daß wir Switche von 3 verschiedenen Herstellern einsetzen (historisch
bedingt).
Mittlerweile hat sich die Sache etwas eingependelt und die meisten Switche scheinen sich an die Spielregeln zu halten.
Allerdings gibt es 2 Abweichler und ich komme nicht dahinter, wieso das so ist.
Von 11 Switchen nutzen 9 den gleichen Querier (warum genau diesen ist mir allerdings auch schleierhaft), die beiden
Abweichler nutzen eine Switch als Querier, die sich selber gar nicht als Querier versteht.
Grundsätzlich ist auf allen Switchen "IGMP Snooping" aktiviert sowie die Möglichkeit als Querier zu fungieren.
Hier ein Schema des Netzwerks:
Falls jemand etwas Licht ins Dunkel bringen könnte, wäre ich dem/derjenigen sehr verbunden...
Gruß, Oli
Ich benötige eure Inspiration bei der weiteren Fehlersuche zum Thema Multicast (IPv4).
Wir haben seit einiger Zeit (nach der Aktualisierung der Serverlandschaft) Problem mit Geräten im Netzwerk, die
Ihre Konfiguration über Multicast abgleichen (evtl. schon vorher, vielleicht ist es nicht so aufgefallen).
Anfänglich hatte wir massive Störungen bei diesen Geräten, die ich im nachhinein auf Broadcasting schieben möchte.
Nach Prüfung/Aktivierung von IGMP Snooping auf allen Switchen und der Umkonfiguration eines Routers (genauer: die
IP-Adresse) hatte sich die Sache etwas beruhigt, allerdings waren die o.g. speziellen Geräte weiterhin von Störungen
betroffen.
Nach intensiver Beobachtung kam ich zu dem Schluß, daß das IGMP Snooping (und speziell die Sache mit dem Querier)
irgendwie nicht rund läuft. Erschwerend kommt hinzu, daß wir Switche von 3 verschiedenen Herstellern einsetzen (historisch
bedingt).
Mittlerweile hat sich die Sache etwas eingependelt und die meisten Switche scheinen sich an die Spielregeln zu halten.
Allerdings gibt es 2 Abweichler und ich komme nicht dahinter, wieso das so ist.
Von 11 Switchen nutzen 9 den gleichen Querier (warum genau diesen ist mir allerdings auch schleierhaft), die beiden
Abweichler nutzen eine Switch als Querier, die sich selber gar nicht als Querier versteht.
Grundsätzlich ist auf allen Switchen "IGMP Snooping" aktiviert sowie die Möglichkeit als Querier zu fungieren.
Hier ein Schema des Netzwerks:
Falls jemand etwas Licht ins Dunkel bringen könnte, wäre ich dem/derjenigen sehr verbunden...
Gruß, Oli
Kommentieren
Teilen
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 673321
Url: https://administrator.de/forum/igmp-snooping-multicast-netzwerk-673321.html
Ausgedruckt am: 12.06.2025 um 15:06 Uhr
16 Kommentare
Neuester Kommentar
Wie wirkt sich die Störung aus? Ich konnte bisher nur rauslesen: massive Störungen, läuft nicht rund. Gibt es Wireshark Mitschnitte?
Du hast hier vermutlich ein falsches Verständnis was den Querrier angeht in einer L2 Multicast Domain. Es gibt nämlich immer nur einen einzigen Querrier. In der Regel ist das ausschliesslich der Router oder Firewall die auch Multicast routet mit PIM also das L3 Device im Netz.
Technisch kann man natürlich mehrere Querrier konfigurieren für ein Backup aber Standard bedingt sorgt ein Querrier Election Prozess dafür das es in einer L2 Domain immer nur einen aktiven Querrier
https://notes.networklessons.com/igmp-snooping-querier-election
Gewinnen tut immer der mit der niedrigsten IP Adresse alle anderen werden über den Election Prozess inaktiv.
Es ist also schlicht und einfach eine falsche IGMP Konfig wenn du auf allen 11 Switches den Querrier aktivierst. Querrier laufen in einem sauber customizten Multicast Netz lediglich nur auf den L3 Core Switches also den Switches die im Core zentral das L3 Forwarding machen. In einem klassisch designten Netz sind das immer 2 Core Maschinen in einem HA oder Stacking Setup. Folglich hat man auch nur max. 2 Querrier von denen einer dann im Standby ist. (s.o.)
Reine Layer 2 Switches die an so einem Core mit LAGs etc. angebunden sind, sind niemals Querrier, das sind immer nur die L3 Maschinen.
Das macht ja auch gar keinen Sinn weil die ja immer nur ein einziges IP Interface haben im Management Netz. IGMP Snooping funktioniert nur über ein IP Interface. Im Management Netz wird aber in der Regel niemals Multicasting gemacht. Es sei denn man hat ein dummes, flaches, nicht segmentiertes Netz und fährt alles in einer einzigen L2 Domain. Sowas gibts aber eigentlich nur noch bei einfachen Heimnetzen aber nicht in einem Enterprise Umfeld.
Nach deiner Beschreibung folgt deine IGMP Konfiguration also generell einem falschen Ansatz und das dann Chaos herrscht verwundert nicht weiter. Als ausgewiesener Admin sollte man diese einfachen Multicasting Binsenweisheiten eigentlich alle kennen?! 🧐
Wichtig ist auch zu beachten das Switch übergreifend zwingend eine gemeinsame IGMP Protokollversion verwendet wird. Empfehlenswert ist hier immer Ver.3 zu verwenden um auch alle SSM Multicast Verfahren sicher abzudecken. Ver.3 ist rückwärtskompatibel.
Du kannst davon ausgehen das wenn du dein Querrier Chaos korrigierst das auch alles sauber laufen wird. Es ist dabei völlig egal ob man ein Multi Vendor Umfeld fährt wie du oder eine Monokultur hat. IGMP ist ein internationaler Standard an den sich alle Hersteller halten.
Weitere Informationen auch zu wasserdichten Test- und Troubleshooting Verfahren liefert dir ein hiesiger Multicast / IGMP Thread.
Vielleicht hilft auch etwas KnoffHoff Auffrischung zum Thema Multicast: https://www.youtube.com/watch?v=AvbSMBKBZgY Alle 6 Teile sind sehenswert.
Ansonsten wären die vom Kollegen @NordicMike oben angesprochen Informationen sehr hilfreich für eine zielführende Hilfe.
Technisch kann man natürlich mehrere Querrier konfigurieren für ein Backup aber Standard bedingt sorgt ein Querrier Election Prozess dafür das es in einer L2 Domain immer nur einen aktiven Querrier
https://notes.networklessons.com/igmp-snooping-querier-election
Gewinnen tut immer der mit der niedrigsten IP Adresse alle anderen werden über den Election Prozess inaktiv.
Es ist also schlicht und einfach eine falsche IGMP Konfig wenn du auf allen 11 Switches den Querrier aktivierst. Querrier laufen in einem sauber customizten Multicast Netz lediglich nur auf den L3 Core Switches also den Switches die im Core zentral das L3 Forwarding machen. In einem klassisch designten Netz sind das immer 2 Core Maschinen in einem HA oder Stacking Setup. Folglich hat man auch nur max. 2 Querrier von denen einer dann im Standby ist. (s.o.)
Reine Layer 2 Switches die an so einem Core mit LAGs etc. angebunden sind, sind niemals Querrier, das sind immer nur die L3 Maschinen.
Das macht ja auch gar keinen Sinn weil die ja immer nur ein einziges IP Interface haben im Management Netz. IGMP Snooping funktioniert nur über ein IP Interface. Im Management Netz wird aber in der Regel niemals Multicasting gemacht. Es sei denn man hat ein dummes, flaches, nicht segmentiertes Netz und fährt alles in einer einzigen L2 Domain. Sowas gibts aber eigentlich nur noch bei einfachen Heimnetzen aber nicht in einem Enterprise Umfeld.
Nach deiner Beschreibung folgt deine IGMP Konfiguration also generell einem falschen Ansatz und das dann Chaos herrscht verwundert nicht weiter. Als ausgewiesener Admin sollte man diese einfachen Multicasting Binsenweisheiten eigentlich alle kennen?! 🧐
Wichtig ist auch zu beachten das Switch übergreifend zwingend eine gemeinsame IGMP Protokollversion verwendet wird. Empfehlenswert ist hier immer Ver.3 zu verwenden um auch alle SSM Multicast Verfahren sicher abzudecken. Ver.3 ist rückwärtskompatibel.
Du kannst davon ausgehen das wenn du dein Querrier Chaos korrigierst das auch alles sauber laufen wird. Es ist dabei völlig egal ob man ein Multi Vendor Umfeld fährt wie du oder eine Monokultur hat. IGMP ist ein internationaler Standard an den sich alle Hersteller halten.
Weitere Informationen auch zu wasserdichten Test- und Troubleshooting Verfahren liefert dir ein hiesiger Multicast / IGMP Thread.
Vielleicht hilft auch etwas KnoffHoff Auffrischung zum Thema Multicast: https://www.youtube.com/watch?v=AvbSMBKBZgY Alle 6 Teile sind sehenswert.
Ansonsten wären die vom Kollegen @NordicMike oben angesprochen Informationen sehr hilfreich für eine zielführende Hilfe.
1
Ich habe mir im Zuge der Fehlersuche natürlich sehr vieles an Literatur - meist der Hersteller - als auch Videos angesehen...
Daß das Auswürfeln über die MAC-Adresse passiert, lese ich hier zum ersten Mal. Wenn ich mich recht erinnere ist immer von einer (speziell dafür eingetragenen) "virtuellen" IP-Adresse die Rede oder der IP-Adresse im jeweiligen VLAN als Fallback (Doku Netgear).
Des weiteren spielt es ja bei Funktion m.E. keine Rolle ob es 2 potentielle Querier sind oder 20... Dafür gibt es ja
die Election-Prozedur. Nur einen Querier zu haben, wird ja auch nicht empfohlen (obwohl es dann
wohl 100%-tig funktionieren würde - bis zum Ausfall desselben).
Wieso treiben die beiden Sophos-Switche hier ein anderes Spielchen? Die 3te Sophos (gleiches Modell wie eine der beiden anderen) funktioniert ja auch wie sie soll... Und die Konfiguration der 3 ist gleich bis auf die IP.
Wir haben übrigens keine "reinen" Layer 2 Switche - was wäre das deiner Ansicht? Unmanaged?
Daß das Auswürfeln über die MAC-Adresse passiert, lese ich hier zum ersten Mal. Wenn ich mich recht erinnere ist immer von einer (speziell dafür eingetragenen) "virtuellen" IP-Adresse die Rede oder der IP-Adresse im jeweiligen VLAN als Fallback (Doku Netgear).
Des weiteren spielt es ja bei Funktion m.E. keine Rolle ob es 2 potentielle Querier sind oder 20... Dafür gibt es ja
die Election-Prozedur. Nur einen Querier zu haben, wird ja auch nicht empfohlen (obwohl es dann
wohl 100%-tig funktionieren würde - bis zum Ausfall desselben).
Wieso treiben die beiden Sophos-Switche hier ein anderes Spielchen? Die 3te Sophos (gleiches Modell wie eine der beiden anderen) funktioniert ja auch wie sie soll... Und die Konfiguration der 3 ist gleich bis auf die IP.
Wir haben übrigens keine "reinen" Layer 2 Switche - was wäre das deiner Ansicht? Unmanaged?
Daß das Auswürfeln über die MAC-Adresse passiert, lese ich hier zum ersten Mal.
Sorry, verwechselt im Eifer des Gefechts. Niedrigste "IP" sollte das natürlich heissen."virtuellen" IP-Adresse die Rede oder der IP-Adresse im jeweiligen VLAN als Fallback
Das ist richtig! Da IGMP ja ein IP Protokoll ist kann es logischerweise nur an Ports oder in VLANs arbeiten wo auch eine IP Adresse ist. In völlig isolierten L2 Netzen ohne Router oder Enddevice was IGMP fähig ist kann es auch kein Snooping geben bzw. passiert das mit einer falschen IP wenn dazu bei vielen Billoswitches die Management IP genommen wird. Genau deshalb ist IGMP bei reinen L2 Switches immer im passive Mode also OHNE Querrier.Desweiteren spielt es ja bei Funktion m.E. keine Rolle ob es 2 potentielle Querier sind oder 20
Aus rein technsicher Sicht ja. Aus einer designtechnischen Sicht aber nicht, denn das ist schlicht unsaubere Frickelei. Warum sollte man Switches solche unnötige Last aufbürden die ja rein aus unsauberer Konfig resultiert?? Kein verantwortungsbewusster Netzwerk Admin würde sowas machen. Das weisst du als gestandener Admin auch selber.Wieso treiben die beiden Sophos-Switche hier ein anderes Spielchen?
Na ja...was erwartet man von einem Firewall Hersteller der keine eigene Switchentwicklung und damit KnowHow hat und nur Billo OEM Barebones von Massenherstellern kauft um das sein Firmenlogo raufzubäppeln?? Das ist ja kein Sophos Produkt. Das da vielleicht einmal etwas nicht ganz koscher mit dem Protokollhandling läuft liegt in der Natur der Sache weil die Firmware woanders entwickelt wird. Gerade bei den Election Prozessen wird da sehr häufig geschludert und dann bricht Chaos aus.Das kann man aber von Extern ohne zumindestens einen Wireshark Trace der den Election Prozess einmal mitschneidet nicht beurteilen. Da muss man schon sehr genau hinsehen und bei denen dann einen Bug Report Case eröffnen in der Hoffnung das die das fixen lassen.
Zumal du auch noch nicht dediziert beschrieben hast WIE dein Fehlerbild genau aussieht??
Der Wireshark sollte nachdem der Election Prozess durch ist immer nur einen einzigen Querrier zeigen. Hast du mehr stimmt was nicht. IGMP Snooping kann immer nur mit einem singulären Querrier laufen.
Wir haben übrigens keine "reinen" Layer 2 Switche - was wäre das deiner Ansicht? Unmanaged?
Nein, unmanaged natürlich nicht. Das wäre ja auch unsinnig denn dann könnten die gar kein IGMP! Das könne grundsätzlich nur managed Switches. 
Damit sind L3 Switches gemeint also solche die auch routen können. L2 only Switches haben keinerlei Routing Funktion.
Das sind die 2 grundsätzlichen Basiskategorien von LAN Switches. Eine Frage nach solchen Banalitäten von einem "Admin" verwundert dann etwas?? 🤔
Was ich allerdings noch nicht gemacht habe - was aber eigentlich egal sein sollte - ist die 2 fragwürdigen Switch neu zu starten (was bei der 3ten mind. 1x gemacht wurde, da sie bisher nur rumliegt; d.h. da ist nur Uplink angeschlossen, da
sie noch nicht im produktiven Einsatz ist.
Im Log der 60er Switch finde ich noch folgende Einträge (spricht übrigens auch für IP-Election-Theorie):
Ist allerdings vom 05. Juni. Seither keine Einträge mehr dieser Art. Würde auch behaupten, daß alle seither "stable" die
.65 als Querier nutzen (bis auf die 2 natürlich).
sie noch nicht im produktiven Einsatz ist.
Im Log der 60er Switch finde ich noch folgende Einträge (spricht übrigens auch für IP-Election-Theorie):
Ist allerdings vom 05. Juni. Seither keine Einträge mehr dieser Art. Würde auch behaupten, daß alle seither "stable" die
.65 als Querier nutzen (bis auf die 2 natürlich).
Seither keine Einträge mehr dieser Art.
Das wäre auch normal. Der Election Prozess läuft ja nur ein einziges Mal ab wenn der Switch ins Netz kommt. Solange es keine Topology Changes im Netz gibt (Spanning Tree Events) findet auch kein weiterer Election Prozess statt. Einfache Logik... Sinnvollerweise aktivierst die nur 2 Querrier auf ausgewiesenen LAN Switches des gleichen Herstellers und lässt die anderen im passive Mode laufen also ohne Querrier. Das wäre best Practise in einem multi Vendor Umfeld!
Willst du helfen oder auf meiner Unwissenheit herumreiten?
Ich würde keine Fragen in einem Forum stellen, wenn ich die Lösung bereits hätte...
Ich würde keine Fragen in einem Forum stellen, wenn ich die Lösung bereits hätte...
Die einfache Lösung ware dein falsches Design zu korrigieren. (s.o.)
Aber ok, Message verstanden, Bin dann mal raus....
Aber ok, Message verstanden, Bin dann mal raus....
Wie ich schon sagte, ich habe viel gelesen und da kann ja nicht alles falsch gewesen sein... nichts für ungut...
"Viel" ist bekanntlich auch viel relativ!! Jede gute MC Literatur beschreibt solche einfachen Design Praktiken auf den ersten Seiten. Fragt sich wirklich was du da gelesen hast...aber egal.
OK. Weitere Meldungen?
Evtl. Erfahrungen mit Sophos? ... btw... was steckt denn hinter Sophos Switchen und warum sollten diese dann auto-
matisch schlecht sein? Könnte ja auch Cisco oder sonstwer mit "ernstzunehmenden" Produkten sein...
Evtl. Erfahrungen mit Sophos? ... btw... was steckt denn hinter Sophos Switchen und warum sollten diese dann auto-
matisch schlecht sein? Könnte ja auch Cisco oder sonstwer mit "ernstzunehmenden" Produkten sein...
Könnte ja auch Cisco oder sonstwer mit "ernstzunehmenden" Produkten sein...
Nope, ganz sicher nicht...! Trace von ein paar Catalysten oder CBS kann ich dir gerne schicken...Sophos verkauft bekanntlich nur OEM Ware bei den Switches nichts Eigenes haben also nur wenig Einfluss auf die Firmware. FW gut aber Switches kauft man deshalb nie bei denen. Aber ganz andere Baustelle und hier nicht Thema....
ich will ja nicht nachtreten... aber ne Firewall ist sowas wie ein Router + Switch mit Zusatzfunktionen - die grundlegenden "Netzwerkskills" sollten die Jungs von Sophos wohl beherrschen...
aber ich wollte ja nicht nachtreten...
aber ich wollte ja nicht nachtreten...
sorry! 
Hier mal ein kurzer Mitschnitt einer VM die hinter .66 hängt:
Ist völlig normal und sieht unauffällig aus.
.1 ist hier der Switch (Cisco Catalyst) und .11 ein geschwätziger Winblows 10 PC der, wie üblich, vorlaut und indiskret alle seine Infos per MC ins Netz bläst.
Beispiel Ruckus ICX Switch 7150 der im Verbund mit den Ciscos werkelt (multi Vendor ):
.254 Switch, .146 der gleiche PC wie oben.
Works as designed!!
.1 ist hier der Switch (Cisco Catalyst) und .11 ein geschwätziger Winblows 10 PC der, wie üblich, vorlaut und indiskret alle seine Infos per MC ins Netz bläst.
- 224.0.0.251 ist eine nicht routingfähige Link Local Adresse und ist mDNS zugewiesen.
- 224.0.0.252 dito. aber LLMNR
- 239.255.255.250 ist SSDP
Cisco#sh ip igmp snooping groups dynamic
Vlan Group Type Version Port List
-----------------------------------------------------------------------
1 239.255.255.250 igmp v3 Fa0/15, Gi0/1.254 Switch, .146 der gleiche PC wie oben.
Switch#show ip multicast group
Display all groups on all ports.
p-:physical, ST:static, QR:querier, EX:exclude, IN:include, Y:yes, N:no
VL228 : 2 groups, 2 group-port
group p-port ST QR life mode source
1 239.255.255.250 e1/1/5 no no 260 EX 0
2 224.0.1.40 e1/1/9 no no 260 EX 0 Works as designed!!
