[...]
Ist das verständlich?
Ne, sorry, ich hab trotz mehrfachem Lesen nicht verstanden was Du bezwecken / verändern willst.
Wenn ich in einem SOHO-Netz keine managed Component / Switche habe, dann brauch ich mir auch keine Gedanken über STP machen.
Wenn ich in meinem Netzwerk allerdings solche Geräte (professionelle oder semi-professionelle egal) einsetze, dann sollte ich auch in der Lage sein und das Wissen haben diese korrekt zu konfigurieren. ! - oder ich muss mir halt jemanden einkaufen der dies kann. Das ist doch kein Punkt für SONOS !?
Den einzigen Punkt den ich hier für SONOS sehe ist der, dass sie in ihrer Produktbeschreibung / Benutzerhandbuch viel offensiver und offensichtlicher auf die möglichen Probleme mit einer solchen Infrastruktur bei inkorrekter Konfiguration hinweisen müssten / sollten.
@Peter_13
Ich stimme Dir absolut zu: Wenn jemand die Investition in (semi-)professionelles Netzwerkequipment für zuhause nicht scheut, sollte er auch das Geld für einen Spezi einplanen, der ihm dieses einrichtet.
Niemand bei Sinn und Verstand käme auf die Idee, sich einen neuen Heizkessel billig im Netz zu schiessen und diesen ohne die Unterstützung eines Fachbetriebes selbst zurecht zu dengeln und in Betrieb zu nehmen. Ähnliches sollte es bei bestimmten IT-Themen sein.
Hier sind wir ohne wenn und aber einer Meinung.
Worum es mir geht ist eher klassisches Pareto. Es geht nicht um jeden Sonderfall, sondern um eine Mehrheit der Einzelfälle, die möglicherweise einfacher zu lösen wären.
Machen wir uns nix vor: Mesh wird immer gängiger in Consumer-Lösungen. Natürlich werden die Techniken darunter so weit abstrahiert, dass der Endbenutzer von den Zusammenhängen nix mitbekommt.
Mesh kann non-blocking aber nicht ohne Spanning Tree funktionieren. (Vorausgesetzt, der Hersteller hält sich an Standards und kocht kein mega-proprietäres Süppchen).
Spanning Tree in einem geswitchten Netz benötigt die kooperative herstellerübergreifende Mitarbeit aller Komponenten, es sei denn, man baut „Inseln“.
Mein Vorschlag entspricht so einer Insel:
Wenn nur eine Sonos-Komponente mit einem Netzwerkkabel versehen ist, benötigt die LAN-Seite des Sonos-Netzes keine Spanning Tree-Unterstützung.
Innerhalb des SonosNet-Mesh kann alles wie gewohnt laufen.
Davor (im LAN/WLAN) des Endanwenders können Fritten, Ubis und ähnliches treiben, was sie wollen. Es können weder parallele Broadcasts an einem anderen Port reinkommen, noch irgendwelche STP-Ankündigungen das Netz durchpuzzeln.
Es wäre eine einfache, nahezu immer funktionierende Lösung:
Hast Du Probleme, sorge dafür, dass genau eine Sonos-Komponente verkabelt ist und der Rest „WM:0“. Das Netz und die Komponenten davor wären dann völlig egal.
Klar, in komplexeren Umgebungen oder dem Klassiker mit den dicken Betonmauern, in dem zwingend mehrere Kabelverbindungen der Sonos-Hobel benötigt werden, hilft das nicht. Aber sonst nahezu immer.
Oder habe ich einen Gedankenfehler?
Viele Grüße
Thomas
Vielleicht ein Denkfehler meinerseits: Genügt es da nicht, bei Bedarf das WLAN-Modul jeder weiteren verkabelten Komponente in der Sonos-App zu deaktivieren? Dadurch entfällt zwar die Switch-Kompatibilitätsfrage, andererseits fallen diese Speaker als Meshknoten aus. Und der Sinn mehrerer verkabelter Komponenten ist die Reichweite des SonosNets zu erweitern, nicht bloß bei dicken Betonmauern, sondern auch Stockwerkübergreifend. Außerdem bringt es meiner Meinung nach nichts, sich auf Sonos zu konzentrieren, wenn der gesamte Netzwerkaufbau schon latent von Multicastpaketen überschwemmt ist oder aus anderen Gründen ein Broadcaststorm kurz bevorsteht. Sonos ist da bloß ein Dominostein, nicht der Auslöser.
@Peter_13
....
Oder habe ich einen Gedankenfehler?
Ja, ich denke den hast Du.
Nicht STP ist das Problem, sondern die Komponenten (sprich die Switches) welche konfigurierbar, aber nicht korrekt konfiguriert sind.
Wenn SONOS nur mit einem Bein am LAN hängt, dann kann es auch zu keinem Loop kommen. - da ist es auch egal ob der Switch korrekt oder inkorrekt, oder auch nicht konfigurierbar ist.
Wenn SONOS mit mehr als einem Bein am LAN hängt, dann kann es halt systembedingt zu diesen Schleifen kommen. - das gilt allerdings nicht nur für Netze mit SONOS. Das kann auch passieren wenn man mehr als einen WLAN-AP unter ein und der selben SSID auf gleichem Funkkanal in seinem Netz betreibt.
Betreibt man dies nun mit einem 0815-unmanaged Switch, fällt OttoNormalVerbraucher i.d.R. noch nicht einmal etwas auf. Im einfachsten Fall ist es ein etwas "wertigerer" "Smart-Switch" und verfügt über Port-/Loop-Protection ... und jetzt schaltet dieser den Port ab, halt wegen dem vermeintlichen Loop.
Für OttoNormalVerbraucher jetzt vollkommen unerklärlich und natürlich verschuldet durch SONOS oder den / die scheißteuren APs.
Das selbe gilt übrigens auch wenn es sich um einen (semi)professionellen managed Switch ohne entsprechende korrekte Konfiguration handelt. - dann sind es ggf. nicht SONOS oder die APs die Schuld sind, sondern der scheißteure managed Switch.
Letztlich liegt in allen Fällen der Fehler oder die Ursache aber in Layer 8, und somit wie so oft vor den Maschinen bzw. zwischen den Ohren.
Lange Rede kurzer Sinn. IMHO macht es keinen Sinn hochkomplexe Technologie derart zu abstrahieren, dass sie für OttoNormalVerbraucher wie ein Staubsauger oder Toaster plug 'n play-fähig werden um damit den gelehrnten und geschulten System-Techniker zu ersetzen.
Es gibt einfach systematische Grenzen welche nicht überschritten werden sollten. Kein Laie traut sich freiwillig an 230 / 400 V Niederspannung ran. - vermutlich weil dort Leib und Leben dadurch bedroht sind. Schade dass dies bei der Netzwerktechnich nicht ebenso ist. 
Nicht STP ist das Problem, sondern die Komponenten (sprich die Switches) welche konfigurierbar, aber nicht korrekt konfiguriert sind.
Naja, auch bei einem vermeintlich korrekt funktionierenden und konfigurierten Switch streiten sich Netzwerkumgebung und Sonos-System auch bei nur einer Verbindung um den Status als STP-Root-Bridge - also den „Chef im Ring“.
Die vermeintlich korrekte Konfiguration laut Sonos (https://support.sonos.com/s/article/2118?language=de) sorgt dann dafür, dass jegliche STP-Aktion der beteiligten Switche/Netzwerkdevices an die Sonos-Umgebung delegiert wird. Äh, nun ja….
STP arbeitet ja nicht als Storm-Erkenner, sondern prophylaktisch. Die STP-Root-Bridge eines Netzes entscheidet bei Aktivierung eines Links an jedem Switch im Netz, ob ein Port in einem Netz überhaupt „hochgeht“ und Pakete durchlässt. Das betrifft sämtliche Pakete, nicht nur Broad- und Multicasts.
Cisco empfiehlt beispielsweise, die Rolle der Root-Bridge über das manuelle Setzen der Priorität immer dem Switch mit dem meisten Dampf (=CPU und Backplane-Bandbreite) und der höchsten Verfügbarkeit zu geben. Laut Sonos-Howto wäre das dann im Worst-Case im S2 eine Play:1……
Mag Netzwerk-Layer 2-Nerdkram sein, aber ich finde das unglücklich und unnötig.
Viele Grüße
Thomas
Hallo Thomas, ich will jetzt keine Grundsatzdiskussion über STP führen, aber ich denke hier gehen unsere Sichtweisen / Informationsstände ein wenig auseinander.
Nicht nur SONOS, sonder auch Cisco sehen (korrekter Weise) den oberen Knoten der Baumstruktur als STP-RootBridge vor. In der Regel ist dieser Knoten dann ein Core-Switch an rel. exponierter Stelle. Und ich wüsste nicht wo da dann etwas an die SONOS-Umgebung delegiert wird.
Die Eigenschaft des (Spanning Tree) Protokolls ist halt, dass es die Kosten für jede einzelne Route zum Ziel ermittelt und darüber dann den günstigsten Weg bestimmt. Die Entscheidung über die Aktivierung oder Deaktivierung einer Strecke, oder vielmehr der Ports für die Strecke erfolgt dann nicht gesteuert von der RootBridge, sondern durch Auswertung der BPDU-Pakete von jedem Port selbst.
Das diese Aktivierung / Deaktivierung dann sämtlichen Traffic auf dem betroffenen Port betrifft liegt auf der Hand und ist Sinn und Zweck dieser Technologie. Ich kann hier auch keine unnötigen Ansätze erkennen.
Einzig als unglücklich sehe ich dass SONOS hier immer noch nur auf STP setzt, anstelle das weitaus performantere / robustere RSTP zu implementieren. Aber gut, wenn das als nicht erforderlich gesehen wird, dann muss man halt damit leben dass der Aufbau der Baumstruktur nach einer Unterbrechung bis zu 4 / 5 Min. dauern kann. - ist halt in der Natur des Protokolls verankert.
Also entweder reden wir aneinander vorbei und ich hab Dich immer noch nicht verstanden, oder Du solltest Dir noch einmal ganz genau die Funktionsweise von STP anschauen !?
@Peter_13
Also entweder reden wir aneinander vorbei und ich hab Dich immer noch nicht verstanden, oder Du solltest Dir noch einmal ganz genau die Funktionsweise von STP anschauen !?
Letzteres, mea culpa.
Mein Gedankenfehler:
Sonos empfiehlt bei der Switch-Konfig eine manuelle Bridge-Priorität von 4096. Ich bin irgendwie in meinem verqueren Hirn davon ausgegangen, dass das ein hoher Wert sei, sprich: „Delegiere an Sonos.“
Das Gegenteil ist der Fall. 4096 ist der niedrigst-sinnvolle Wert, d. h. die Empfehlung von Sonos lautet „mache Deinen Switch zum Chef“.
Danke für Deine Geduld und die Empfehlung zur aktiven Suche nach Nachhilfe, hat geholfen. 
Ich geh mich mal eingraben.
Thomas
@Hedy L.
….ich verstehe den Sinn Deiner „Beispiele“ nicht?
→ es ist beides Mal der gleiche Text, einmal in deutsch, einmal in englisch
→ genau hierüber sprechen wir die ganze Zeit, inklusive dieses Artikels als Quelle (?)
Oder gibt es hier irgendeinen versteckten Bot, der einfach nur nach bestimmten Keywords scannt und unzusammenhängend Supportartikel und Google-Ergebnisse unter dem Namen „Hedy“ postet? 
(sorry, nicht zu Ernst nehmen, could not resist)
Ich hatte nicht den Eindruck, dass Sie den Supportartikel kannten und habe vorsichtshalber die deutsche und englische Version verlinkt, weil manche Switche eine deutsche Oberfläche haben werden und ich daher dachte, Sie könnten beides gebrauchen. :)
Ich hatte nicht den Eindruck, dass Sie den Supportartikel kannten
Ähm, ich hatte ihn selber verlinkt…
Ich hatte nicht den Eindruck, dass Sie den Supportartikel kannten
Ähm, ich hatte ihn selber verlinkt…
Ah sorry, habe Ihren vor 4 Stunden geposteten Beitrag jetzt erst gesehen.
