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: 03.07.2025 um 12:07 Uhr
34 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!!
Update:
Ich habe die beiden "Ausreißer" in der Zwischenzeit neu gestartet und anfänglich sah es auch so aus, als würde das Ganze danach funktionieren "as designed". D.h. alle Switche hatten tatsächlich den gleichen Querier (.65).
Nun war ich letzte Woche im Urlaub und siehe da:
Gleiches Spiel wie vorher: Die beiden fraglichen Sophos-Switche haben sich wieder auf die .60 als Querier geeinigt, während alle anderen (auch die 3te Sophos (.167)) wie vorgesehen die .65 als Querier listen (welche diese Rolle auch selbst innehat).
Further suggestions?
Ich habe die beiden "Ausreißer" in der Zwischenzeit neu gestartet und anfänglich sah es auch so aus, als würde das Ganze danach funktionieren "as designed". D.h. alle Switche hatten tatsächlich den gleichen Querier (.65).
Nun war ich letzte Woche im Urlaub und siehe da:
Gleiches Spiel wie vorher: Die beiden fraglichen Sophos-Switche haben sich wieder auf die .60 als Querier geeinigt, während alle anderen (auch die 3te Sophos (.167)) wie vorgesehen die .65 als Querier listen (welche diese Rolle auch selbst innehat).
Further suggestions?
Klarer Bug in der Switchfirmware! Da solltest du einen Case im Sophos TAC aufmachen.
Das solche Exotenhersteller die OEM Ware verwenden mit der Querrier Election nicht richtig umgehen können ist leider keine Seltenheit... ;-(
Das solche Exotenhersteller die OEM Ware verwenden mit der Querrier Election nicht richtig umgehen können ist leider keine Seltenheit... ;-(
Ich habe eben die Querier-Rolle auf .65 deaktiviert und schon wenige Augenblicke später springen die beiden Sophos-Switche auf sich selbst (.68 auf .68 / .69 auf .69), obwohl auf beiden die Rolle deaktiviert ist.
Spricht (auch) für einen Fehler in der Firmware, oder?
Spricht (auch) für einen Fehler in der Firmware, oder?
Einige Augenblick später ändert .68 die Meinung und ändert die Querier-Adresse auf .69.
Wird immer besser...
Wird immer besser...
Die beiden Netgear's (.65 (bisheriger Querier) und .66) schwenken auch auf .69 um...
Die dritte Sophos wiederum bleibt bei .65.
Mehr als abschalten kann ich das ja nicht (.69):
Die dritte Sophos wiederum bleibt bei .65.
Mehr als abschalten kann ich das ja nicht (.69):
Das wiederspricht aber der Theorie, daß ohne Topologieänderung auch keine Änderung des Queriers erfolgt (ohne Neustart).
Denn auch die .66 hat sehr schnell nach Deaktivierung des Queriers auf .65 die Querier-IP auf .69 geändert...
Und im Log von .60 (welche ja vor Deaktivierung von .65 die ganze Zeit angeblich Querier für .68 und .69 war) wurde kurz danach ein Election-Prozeß protokolliert (seit dem 06.06. nicht mehr):
Denn auch die .66 hat sehr schnell nach Deaktivierung des Queriers auf .65 die Querier-IP auf .69 geändert...
Und im Log von .60 (welche ja vor Deaktivierung von .65 die ganze Zeit angeblich Querier für .68 und .69 war) wurde kurz danach ein Election-Prozeß protokolliert (seit dem 06.06. nicht mehr):
Nur zur Klarstellung (Screenshot von Querier .69)
Diese Einstellung wiederspricht sich, oder?
Oder könnte mit "Querier Status" (Einstellungsmöglichkeit: On/Off) etwas anderes gemeint sein?!
Diese Einstellung wiederspricht sich, oder?
Oder könnte mit "Querier Status" (Einstellungsmöglichkeit: On/Off) etwas anderes gemeint sein?!
Mittlerweile haben sich alle auf Querier .69 eingeschossen (.167 erst nach Neustart - wollte nicht länger warten, alle anderen eigenständig und relativ schnell)
Diese Einstellung widerspricht sich, oder?
Nicht undbedingt....In VLAN 1 rennt Snooping mit Ver. 2 im Querrier Mode. In VLAN 10 mit Ver. 3 im Non Querrier Mode. Ist ja erstmal nur eine simple Info, nicht mehr und nicht weniger.
Das so ein Mischmasch natürlich Bullshit ist weisst du als Profi auch selber. Ist zwar alles mehr oder minder kompatibel aber dennoch sollte man solch ein kontraproduktives Gemische von Querier, non Querrier und Versionen innerhalb einer Box oder netzwerkweit niemals machen. Sowas ich schlechtes bzw. mangelhaftes MC Design.
- Eine einheitliche IGMP Version durchgängig über alle Maschinen. Wenn alte oder Billo Gurken kein Ver. 3 supporten, belasse es durchgängig bei Ver. 2.
- 2 Maschinen sind Querrier und dann durchgängig für alle VLANs. Einer Primär, zweiter Backup. In der Regel sind das immer die Switches die nah an den Multicast Quellen sind oder man nimmt einfach die Core Switches.
- Alle anderen Switches sind non Querrier also Querrier = OFF. Wie oben schon mehrfach gesagt kann es immer nur einen aktiven Querrier in einer L2 Domain geben.
Fast immer sind das dann Spanning Tree Outages, Spanning Tree Mismatches und/oder ein falsches oder fehlerhaftes Spanning Tree Design ohne Root und Backup Root Switches die eine feste Topologie vorgeben usw. usw. Mit dem Resultat das sich der Primärquerrier und der Backup NICHT mehr "sehen" können (Split Brain). Das wäre dann ein Hinweis auf weitere gravierende Probleme im Netz.
Ich habe eben nochmal eine paar Internetquellen gecheckt wg. dem Election-Prozeß:
In allen Dokumenten wird explizit von der "niedrigsten IP-Adresse" (Querier) gesprochen...
In allen Dokumenten wird explizit von der "niedrigsten IP-Adresse" (Querier) gesprochen...
Sinn macht das was die Sophos-Switche treiben so oder so aber nicht...
Spanning Tree ist überall inaktiv. Wir sehen bei dieser Topologie keine Notwendigkeit und hatten bereits "Überraschungen" in der Vergangenheit...
Snooping ist übrigens nur in VLAN1 aktiv - das geht aus dem Screenshot nicht hervor. Sorry. Hätte ich vielleicht nur die erste Zeile posten sollen...
Ich meinte mit "widerspricht sich" (ohne ie natürlich ) dass der "Querier status" auf "off" steht und die Switch trotzdem Querier ist...
Die Erklärung im Handbuch ist natürlich wieder Handbuch-typisch erschöpfend und nachvollziehbar...
Snooping ist übrigens nur in VLAN1 aktiv - das geht aus dem Screenshot nicht hervor. Sorry. Hätte ich vielleicht nur die erste Zeile posten sollen...
Ich meinte mit "widerspricht sich" (ohne ie natürlich
) dass der "Querier status" auf "off" steht und die Switch trotzdem Querier ist...Die Erklärung im Handbuch ist natürlich wieder Handbuch-typisch erschöpfend und nachvollziehbar...
Snooping ist übrigens nur in VLAN1 aktiv
Na ja, der Screenshot oben zeigt aber etwas deutlich anderes in Bezug auf VLAN 10. Oder das GUI "haluziniert". Spanning Tree ist überall inaktiv.
Oha...bei der Anzahl von Switches ist das eher fahrlässig. Gibt es denn zumindestens eine andere Art der Loop Prevention in dem Netz? So ein Netz ganz ohne zu fahren zeugt leider auch nicht grade von guter Planung. Aber nundenn, jeder kann auch ohne Helm oder Gurt fahren wenn er will und meint das es befreiender ist.
Ein gut und wasserdicht designtes Spanning Tree ist eine sichere und absolut überraschungsfreie Sache die mehr Konstanz und Verlässlichkeit in die gesamte Infrastruktur bringt.
dass der "Querier status" auf "off" steht und die Switch trotzdem Querier ist...
Da hast du absolut Recht. Das ist ein gravierender Bug. Zu mindestens im GUI. Wenn das auch noch im Betrieb so sein sollte (Wireshark) ist es ein noch gravierender Firmware Bug. Wie gesagt, in Billo OEM Ware bedauerlicherweise leider keine Seltenheit! ist natürlich wieder Handbuch-typisch erschöpfend und nachvollziehbar...
Solche pauschalen Statements sind sicher Hersteller spezifisch.
Hier wirds deutlicher - Einstellungen sind getrennt (verschiedene Fenster):
Die Anzeige ist in der Tat wirr und unlogisch. Müsste man so verstehen das IGMP Snooping zwar konfiguriert ist aber im VLAN 10 deaktiviert ist. Ebenso die Querrier Funktion. Damit ist die Anzeige zu mindestens für das VLAN 10 aber in sich unlogisch.
Das mag daher rühren das beim Gros der seriösen Hersteller es in der Regel 2 Optionen gibt bei VLAN Switches:
Was gilt kann dann wohl nur das Handbuch klären oder die technische Hotline.
Das mag daher rühren das beim Gros der seriösen Hersteller es in der Regel 2 Optionen gibt bei VLAN Switches:
- Konfiguriert man IGMP Snooping als Global Command, ist es automatisch aktiv für ALLE VLANs auf dem Switch kann aber explizit für einzelne VLANs wieder deaktiviert werden.
- Wird IGMP Snooping VLAN spezifisch konfiguriert, gilt es immer nur für das bestimmte VLAN. In allen anderen L2 VLANs wird MC Traffic dann geflutet wie bei unmanaged Switches auch.
Was gilt kann dann wohl nur das Handbuch klären oder die technische Hotline.
Wenn das denn nun die Lösung war bitte deinen Thread dann auch als erledigt schliessen!
Wie kann ich einen Beitrag als gelöst markieren?
Wie kann ich einen Beitrag als gelöst markieren?
Ich habe einen Case bei Sophos aufgemacht...
So wie es aussieht, läßt sich das (momentan) tatsächlich nicht deaktivieren auf den Switchen...
Wenn man das entsprechende Console Command ausführt (was m.E. dasselbe tut wie die GUI-Einstellung) verliert
die Switch zwar die Querier-Rolle, allerdings nur für wenige Minuten...
So wie es aussieht, läßt sich das (momentan) tatsächlich nicht deaktivieren auf den Switchen...
Wenn man das entsprechende Console Command ausführt (was m.E. dasselbe tut wie die GUI-Einstellung) verliert
die Switch zwar die Querier-Rolle, allerdings nur für wenige Minuten...
So wie es aussieht, läßt sich das (momentan) tatsächlich nicht deaktivieren auf den Switchen...
Na ja, war ja zu erwarten bei billiger OEM Ware die Sophos da vertreibt. Auf die Firmware Entwicklung haben die wenig bis keinen Einfluss. allerdings nur für wenige Minuten...
Der nächste Bug... Hört sich leider alles recht gruselig und wenig vertrauenswürdig an. 
