Hi Daniel,

In deiner Signalkette müssten alle beteiligten  Switches IGMPv3 fähig und am besten „unmanaged“ sein. Bei „managed“ Switches müsste man noch von Hand die korrekten STP Settings einstellen. 

Hi Daniel,

ich würde Dir empfehlen Dich mit Deinem Systemintegrator über dies Thema zu unterhalten,

Wie Ralf ( @Superschlumpf ) bereits erwähnte verwendet SONOS, wenn es per LAN angeschlossen ist, STP und lässt sich eigentlich nur sauber betreiben wenn auch die ganze Infrastruktur entsprechend konfigurierbar ist. - heißt managebarer Switch usw.

In Deinem Fall sehe ich sogar die Notwendigkeit und den Einsatz von VLANs gegeben.
Ich würde min. Deine KNX-Technik und ggf. weitere IoT-Komponenten in ein eigenes VLAN verbannen.
Und für Deine WLAN-APs ist min. auch ein weiteres VLAN (das Gast-(W)LAN) mehr als sinnvoll.

Damit SONOS in solch einem Umfeld (insbesondere wenn es rein via LAN und ggf. mit deaktivierten WLAN-Interfaces) sauber betrieben werden kann muss STP ebenfalls korrekt konfiguriert sein.
Und es müssen entsprechende Regel für das Routing zwischen den VLANs erstellt werden.
Das erfordert einiges an Erfahrung mit einem solchen Netzwerk.
... ich kann nicht beurteilen ob Du so etwas leisten kannst !?

Grundsätzlich solltest Du alle SONOS-Geräte, welche via LAN angeschlossen sind, mit dem Core-Switch verbinden. Switch-Kaskaden (ins besondere über unmanaged Switches) sind in solch einem Fall zu vermeiden. - das ist kein Stromnetz wo man einfach eine Mehrfachsteckdose einsetzt !!!
Wenn dennoch ein weiterer Switch erforderlich ist, dann muss dieser genauso konfigurierbar sein wie der Core-Switch und die Ports müssen für SONOS speziell eingestellt werden.
… also nicht ganz trivial das Ganze..   

Btw., den Move im EG wirst Du so (über Dein WLAN und den AP) betreiben können, für die ONE im KG solltest Du Dir aber einen anderen Weg überlegen.
Entweder bekommt die dann auch einen LAN-Anschluss, oder Du musst Dich eines BOOSTs bedienen der per LAN angeschlossen ist. Die ONE will via SONOS-Net (also dem SONOS-eigenen WLAN) versorgt werden, da all Deine anderen SONOS-Geräte via LAN angeschlossen sind. … Oder Du musst sicherstellen dass sie von einem anderen SONOS-Player via SONOS-Net Verbindung bekommt.

@daniel.danzinger, ich finde außerdem keine Informationen, dass der DGS‑1024D IGMP Snooping-fähig ist. Es ist immer anzuraten, dasselbe Modell zu nehmen, wenn man mehrere Switches einsetzt.

IGMP ist hier zunächst ein nachrangiges Problem!

Durch die Art und Weise der Netzanbindung aller Komponenten kommt es hier zu einem Broadcast-Storm da zudem MC-Pakete von den eingesetzten Switches in BCs umgewandelt werden. Das flutet nach kurzer Zeit das ganze Netz und legt es lahm. - das trifft dann irgendwann auch die KNX-Installation !

Da hilft nur saubere Konfiguration und STP.

Schon klar, aber das sind alles unkonfigurierbare Switche, wo will man da STP einstellen?

@daniel.danzinger, für konfigurierbare Switche gibt es eine Anleitung, mittlerweile sogar auf Deutsch, nur weiß ich nicht, ob die Übersetzung akkurat ist.

Sonos STP Switch Settings

Konfigurieren der STP-Einstellungen für die Verwendung mit Sonos

gar nicht, die muss man austauschen, oder SONOS bis auf einen Anschluss-Punkt vom LAN nehmen und dann mit dem “einfachen” SONOS-Net arbeiten.
Oder SONOS halt komplett auf das eigene (priv.) WLAN umstellen. 

Hallo zusammen,
vielen Dank für die ausführlichen Erläuterungen und Informationen.

Ich bin zwar Software-Entwickler, habe jedoch mit Netzwerktechnik nur wenig Berührungspunkte.

Das mit den Switches ist historisch gewachsen.. zentralen 24-Port-Switch hatten wir beim Einzug angeschafft und verkabelt.
Danach wurde entschieden die Access-Points schaltbar (Nacht-Modus) zu machen (zus. PoE-Switch). Und jetzt die Entscheidung für Sonos, aber halt über LAN angebunden. Da ich vom Wohnzimmer nicht so viele Netzwerkkabel in den Technikraum verlegen kann, wurde ein zusätzlicher Switch fürs WZ angeschafft.

So wie ich Peter verstanden habe, bringt es nichts, den 24-Port-Switch auf einen unmanaged mit IGMP-Snooping zu wechseln, oder? Alle 3 Switches müssten getauscht und entsprechend konfiguriert werden. Verstehe ich das richtig?

Irgendwie hört sich das alles etwas komisch an. Die verwendete Hardware sollte doch im Stande sein mit STP klarzukommen. D-Link ist sicherlich nicht der Premiumhersteller schlechthin, aber dass der Switch da Probleme macht, fände ich sehr komisch. Die TP-Link Kosten sind definitiv ok, den 8 Port Switch nutze ich selbst.

Daniel schreibt, dass er seine Beam verkabeln wollte… Was heißt denn das genau? Wurde nur die Beam per Kabel angeschlossen oder die anderen Sonos Geräte auch? 

Gemäß Skizze hängen 4x ONE und die Beam am TP-Link TL-SG 108v3. Den habe ich selbst (funktioniert einwandfrei), vermutlich ist es die Kaskadierung verschiedener Switchtypen, die hier den Broadcast-Storm auslöst. Ist aber nur die Vermutung eines Laien.

Ich verstehe es so, dass die Skizze der Soll-Zustand ist. Mir ist nicht ganz klar, wann der Fehler aufgetreten ist, denn Daniel schrieb er hätte versucht die Beam anzuschließen. Wenn der Rest zu dem Zeitpunkt nicht per LAN angeschlossen war, kann es auch kein Broadcaststorm gewesen sein. 

Wenn Deine Prio auf LAN-Betrieb und SONOS z. T. mit aktivem WLAN-Interface liegt, dann ja.

Wenn Du es realisieren kannst, dass bei ALLEN SONOS-Geräten das WLAN-Interface deaktiviert ist (würde ich aber auf keinen Fall empfehlen), dann sollte IGMPv3-Fähigkeit an den Switchen, an denen SONOS angeschlossen ist ausreichen.
… der MOVE ist dabei außen vor, weil der kein SONOS-Net kann.
… den kannst Du nur über Dein priv. WLAN integrieren.
… den sehe ich aber eh ein wenig als Problemkind. Dem würde ich mich in Deiner stationären Installation ggf. entledigen und auf der Terrasse oder Garten eher einen Außen-LS getrieben von einem AMP, oder eine P1 / ONE mit Überdachung vorsehen.

Und wenn Du es wie ich geschrieben habe ganz richtig machen willst, dann brachst Du für eine saubere VLAN-Infrastruktur eh geeignete Switches und musst tauschen.
Alles in ein und dem selben LAN-Segment, gerade mit Deiner KNX-Installation sehe ich als fahrlässig.
Da gibt es sicherlich nicht nur Lichtsteuerung sondern auch so was wie Motorschlösser oder Türöffner ... !?
Da solltest Du aufräumen und Nägel mit Köpfen, und keine halben Sachen machen.

Deine APs sind über die TP-Link Management Software verwaltbar und unterstützen V(W)LANs.
Mit dem(n) richtigen Switche(s) aus dem selben Programm (und ggf. den passenden Controller / Router) hast Du alles aus einem Guss und sparst Dir zudem einen Haufen an Konfigurations- und Pflege-Aufwand, auch wenn es anfänglich einen gewissen Invest bedeutet. … aber es ist ja Weihnachten. 

… so würd ich es jedenfalls machen.

Hallo Dieter,
danke für deine Antwort!
Ich hatte gestern nur die Beam an den 8-fach-Switch gehängt. Die anderen sind derzeit im WLAN eingebunden.

Also bevor hier das Problem nicht gefunden wurde, würde ich gar nix tauschen. Peter ist da meiner Meinung nach ein bisschen vorschnell… denn wenn nur die Beam angeschlossen war, dann kann es kein Broadcast-Storm gewesen sein. 

Hi Dieter, ich tippe darauf dass der DGS‑1024D das Problemkind ist. Je nach Stellung des DIP Switch für Port Isolation and Storm Control schaltet der ggf. den Port für den TL-SG108 ab und ggf. wieder ein !? 
Ob da ursächlich MCs, welche er zu BCs wandelt verantwortlich sind bleibt nur zu vermuten.
Definitiv will die Beam aber mit der Move und dem One am unteren Zweig kommunizieren.

Du hast meinen Post vor Deinem aber schon gelesen !?
… da stehen auch Optionen ohne Tausch.

Moin Peter, den habe ich in der Tat nicht gesehen. Sorry. Aber wie geschrieben kann es ja gar kein STP Problem sein, wenn er nur die Beam per LAN angeschlossen hat. Mir fällt kein plausibler Grund ein warum, dass einen Broadcast-Storm erzeugen sollte. Da liegt eher noch irgendwas anderes im Argen oder es wurde ein weiteres Sonos Gerät unbemerkt per Kabel angeschlossen.

Zur Not den D-Link mal kurz abklemmen und nur den TP-Link nutzen, dann sollten wir mehr wissen. 

IPTV arbeitet z.B. ebenfalls mit Multicast, wenn ein solcher Receiver zusammen mit nur einer Sonoskomponente am TL-SG 108v3 hängt, reicht das, um einen Broadcast-Storm auszulösen.

der TL-SG 108v3 ist da dann aber NICHT das Problem. - der “Unterstützt QoS nach IEEE802.1p sowie IGMP-Snooping”

Probleme würde dann ebenfalls der DGS‑1024D machen, weil der den MC als BC auf alle Ports verteilen würde.

Da gebe ich Dir Recht. - bei nur einem SONOS-LAN-Gerät kommt das noch nicht zum Tragen

Was passiert eigentlich mit den BPDU-Paketen wenn SONOS noch die SSID des WLANs bekannt ist und ein Node (die ONE und der MOVE) noch darüber verbunden sind?
Die Beam wird diese ja zurück ins LAN senden.
Das sind ja auch eine Art BCs !?
Wie reagiert der DGS‑1024D auf solche Pakete ?

Sehe ich als ersten Schritt zur Problemeingrenzung auch so.

Ich weiß es nicht hundertprozentig, aber ich meine, dass Sonos-Geräte, die im normalen WLAN hängen gar kein STP nutzen und es komplett deaktiviert wird. Diesen Eindruck bestätigt auch 1400er Status Page. 

Die Player im WLAN dürften auf die BPDUs also gar nicht antworten und daher sollte es auch zu keinen BC-Storm kommen, wenn nur die Beam im LAN hängt. 

Stimmt, ich hätte “im Zusammenspiel mit dem DGS‑1024D” dazuschreiben sollen (zu faul dazu gewesen).

Im WLAN-Betrieb gibt es auch kein STP, allerdings sollte man schon darauf achten, dass sich mit Ausnahme des Move alle Komponenten im SonosNet (WM:0) befinden. Mann könnte natürlich einen reinen LAN/WLAN-Mischbetrieb erzwingen, indem man bei allen verkabelten Komponenten das WLAN-Modul deaktiviert. Aber ich bekomme bei dieser Betriebsart Kopfweh.

Hallo Ralf, Peter und Greta,

vielen herzlichen Dank für eure zahlreichen Antworten. 

Ich habe euren Tipp beherzigt: den D-Link-Switch überbrückt und beide TP-Links zusammengehängt (1x Sonos- und 1x AP-Switch). Fazit: alle möglichen Einstellungen funktionieren (nur LAN, Mischbetrieb, nur WLAN der verschiedenen Sonos-Geräten etc.).
Danach habe ich den D-Link-Switch wieder dazwischengehängt und siehe da, es funktioniert spannenderweise weiterhin. Auch hier kann ich wieder alle Einstellungen durchprobieren und Switches ein- und ausschalten ohne jegliche Störungen zu verursachen. Das Netzwerk ist stabil, ich hoffe das bleibt weiterhin so.  Ich halte euch auf dem Laufenden.

Meine Vermutung ist nun, dass die Einstellung “Port Isolation & Storm Control” am D-Link-Switch ev. die Probleme verursacht hat. Ich habe diese gestern im Zuge der Netzwerk-Probleme mal deaktiviert und nicht wieder aktiviert. Kann das damit etwas zu tun haben?

Auf jeden Fall nochmal vielen Dank für eure Hilfe und v.a. Zeit!!

Schöne Grüße
Daniel

PS: danke auch für den Tipp mit den managed Switches inkl. VLANs für KNX und WLAN, darüber werde ich mich informieren.

Auf jeden Fall, das wird definitiv der Grund gewesen sein.

D.h. aber nicht. dass das jetzt so in Ordnung ist.
Du hast zwar derzeit (augenscheinlich) keine Probleme, aber diese Funktion erfüllt ja einen Zweck.
Deine Probleme liegen jetzt unterhalb der “Sichtbarkeit”. Heißt soviel wie, sie sind weiterhin vorhanden, es erfolgt nur keine Prävention.

Sollte Dein Netzwerk, zu und nach welchem Zeitpunkt auch immer, unerträglich langsam werden oder mit unüblichen Aussetzern reagieren, dann solltest Du Dich an diese deaktivierte Schutzfunktion wieder erinnern. - an einem BC-Storm (oder auch Loops im Netz) ist nämlich schon so manch ein Netzwerker verzweifelt.    

Der DGS‑1024D ist laut Datenblatt ein Unmanaged Switch, wieso kann man da was konfigurieren?

Es gibt 3 DIP-Schalter:

Aber meine Aussage mit den Managed Switches bezog sich auf einen ev. Tausch und nicht auf den DGS-1024D