I wanted to post a few clarifications regarding SONOS and Spanning Tree Protocol that have been raised in this thread.
SONOS ZonePlayers use 802.1D Spanning Tree (STP) for loop prevention between wired ZonePlayers and the wireless SonosNet Mesh Network. The Spanning Tree running on ZonePlayers is compliant with IEEE 802.1D and can inter-operate with other IEEE 802.1D and IEEE 802.1w compliant devices. Note: IEEE 802.1w is an updated version of the Spanning Tree protocol called Rapid Spanning Tree. The two types of STP protocols are compatible and 802.1w should revert to inter-operate with 802.1D devices (such as Sonos). Therefore, 802.1w Ethernet switches will work with Sonos ZonePlayers.
SONOS ZonePlayers CAN be connected to Ethernet switches that do NOT support Spanning Tree as long as the Ethernet switches do not interfere with the STP BPDU packets transmitted between ZonePlayers. This is typically never the case and these switches pass the BPDU packets like any other packet.
If the Ethernet switches that Sonos ZonePlayers are wired to DOES support Spanning Tree, the Spanning Tree on those switches must be configured properly. Ethernet switches that support Spanning Tree typically have their STP settings disabled. This also typically means that these switches will block/discard the BPDUs coming from the ZonePlayers. When the ZonePlayers are not able to see BPDUs, they cannot detect there is a shared transmission medium between the Zones and this will typically result in loops in the network. The solution to allow the use of these switches with Sonos is to enable and configure the Spanning Tree on the Ethernet switches. The configuration settings on each switch are different and the appropriate documentation for those products should be consulted. Note: Some switches have a setting that is called Pass BPDUs or equivalent. This setting when present allows the BPDUs between the ZonePlayers to pass freely through the switch without actually enabling STP on the the switch. Typically, setting this function also works, but again please review the switches product documentation.
A good guideline for Ethernet switches is if the switch says it supports Spanning Tree, either 802.1D or 802.1w, then its configuration settings and user documentation should be examined before wiring multiple ZonePlayers to the switch. If the switch does not state it supports Spanning Tree, 802.1D, or 802.1w, it will probably work fine with Sonos.
SONOS ZonePlayers do NOT require a connection to the same Ethernet switch. Different ZonePlayers can be connected to different Ethernet switches which are in turn connected to each other. The only requirement is that Sonos ZonePlayers must be able to actively participate in 802.1D Spanning Tree and not have BPDU transmission blocked between them. There is no Sonos limitation that prevents wiring multiple ZonePlayers to multiple Ethernet switches.
IEEE 802.1D has a recommended bridge span limitation of 7 bridges. This means that the total number of connected bridges from one end of the network to the other should not exceed 7 bridges. This typically only comes into play when daisy chaining Sonos ZonePlayers together by wiring one ZonePlayer to the next. In this case, the guidelines is when daisy chaining ZonePlayers, do not exceed 7 ZonePlayers wired together. If wiring multiple ZonePlayer to a single Ethernet switch, typically the number of spans will only be 3 or 4 (I.e. much less than 7). Except in the daisy-chain configuration, this limit of 7 bridges/7 ZonePlayers, is rarely ever hit.
A number of comments have used the term router and switch interchangeably in regards to this topic. Sonos ZonePlayers in the same HouseHold MUST be connected to the same routed network. A Spanning Tree cannot span two or more routed networks. In addition all Sonos ZonePlayers and Controllers must be on the same routed IP network in order to properly communicate and function. Typically, two or more routed networks are not seen in the household environment except by accident (Example. A carrier provides a new router in a network that already had a router and the original router was not removed).
Hopefully this information has clarified a number of items and not added additional confusion.
Regards, Todd
Page 2 / 3
I don't know if just specifying the interface alone would be sufficient, when using wireless each Sonos device has to pick which peer to connect to in the mesh. It might also be a pain when you go from wired to wireless operation of a speaker when you want sound in a temporary location, I do that often with one of my Play 1s.
I see this advanced mode to be able to specify parameters like mesh peers, and not to make moving a player from wired to wireless ad.hoc. (if one wants to do that, they wouldn't use this mode). While I can only speak for myself, my Sonos players never move once I install them. Of course I've put a player or set of speakers connected to a player in almost every room of the house (including bathrooms and in the backyard) so I never have to move hardware around.
@Michael Bender
What problem are you trying to solve? An unstable topology? Although I've seen a few occasions where a central node is hit by a TCN flood they're rare.
SonosNet/STP typically gets things right. It already triggers the blocking of nonviable wireless tunnels, by assigning an artificially high path cost.
Also, don't overlook the fact that the spanning tree is not the only active topology. Direct Routing is used to interconnect grouped/bonded nodes, effectively short-cutting between tree branches.
What problem are you trying to solve? An unstable topology? Although I've seen a few occasions where a central node is hit by a TCN flood they're rare.
SonosNet/STP typically gets things right. It already triggers the blocking of nonviable wireless tunnels, by assigning an artificially high path cost.
Also, don't overlook the fact that the spanning tree is not the only active topology. Direct Routing is used to interconnect grouped/bonded nodes, effectively short-cutting between tree branches.
A lot of fancy stuff could be done but doing it may mean doing other stuff that more people will want to use has to be left out. Remember that Sonos devices have limited storage and memory (older one even more limited) so you can't have everything and have to prioritize.
Sorry to drag this up again but I'm pulling what little hair I have left out!!:@
I've just spent over 2 hours on the phone with support and got nowhere. In fact they changed some settings and the system was worse. Here's a summary of the issues and setup.
I have a Netgear GS748TP switch which is the main switch in the house. I have two additional unmanaged switches in two outbuildings hardwired back to the main switch. I have seven SONOS players and a Boost. One SONOS is in one outbuilding and a second in a separate outbuilding. One is hard wired (via unmanaged switch in outbuilding back to main switch in house), the other uses SONOSNet off the other - it has to as it can't connect to any players in the main house. The rest of the players are in the main house. Two on the ground floor with a Boost. They are separated by around 15ft between each player and the Boost. Another player is on the first floor and the final two are on the second floor next to each other. Within the main house, the Boost is hardwired via ethernet back to the GS748TP. Likewise one of the players on the second floor is hard wired to the GS748TP.
The problem is one of the players on the ground floor (Connect:Amp) is dropping off the network. Only a recent problem as the system has been running for nearly 10 years without problems. No changes have been made to the network except adding a Beam and another Connect:Amp recently. I've also been experiencing network problems with slow access. I was advised to swap the problem unit for another and see how that went. I did this and all seemed well but support advised there was still considerable interference in the system. At this stage the swapped unit had been running for several days with no dropouts. Support then changed various settings on the switch which caused the swapped player to dropout again! I've changed things back and the player came back on the network. However I'm not sure where my settings on the GS748TP should be. I've attached a few screenshots. Can anyone help to solve this??
I've just spent over 2 hours on the phone with support and got nowhere. In fact they changed some settings and the system was worse. Here's a summary of the issues and setup.
I have a Netgear GS748TP switch which is the main switch in the house. I have two additional unmanaged switches in two outbuildings hardwired back to the main switch. I have seven SONOS players and a Boost. One SONOS is in one outbuilding and a second in a separate outbuilding. One is hard wired (via unmanaged switch in outbuilding back to main switch in house), the other uses SONOSNet off the other - it has to as it can't connect to any players in the main house. The rest of the players are in the main house. Two on the ground floor with a Boost. They are separated by around 15ft between each player and the Boost. Another player is on the first floor and the final two are on the second floor next to each other. Within the main house, the Boost is hardwired via ethernet back to the GS748TP. Likewise one of the players on the second floor is hard wired to the GS748TP.
The problem is one of the players on the ground floor (Connect:Amp) is dropping off the network. Only a recent problem as the system has been running for nearly 10 years without problems. No changes have been made to the network except adding a Beam and another Connect:Amp recently. I've also been experiencing network problems with slow access. I was advised to swap the problem unit for another and see how that went. I did this and all seemed well but support advised there was still considerable interference in the system. At this stage the swapped unit had been running for several days with no dropouts. Support then changed various settings on the switch which caused the swapped player to dropout again! I've changed things back and the player came back on the network. However I'm not sure where my settings on the GS748TP should be. I've attached a few screenshots. Can anyone help to solve this??
The GS748TP settings look okay. Intermittent dropping of a single unit off the network is not usually a symptom of STP configuration. Interference sounds like a more likely candidate. Even possibly hardware issues if it's an old unit. At 10 years old a 'Connect:Amp' is surely an early ZP120, or is it actually a ZP100?
The Linksys EG008W that was mentioned earlier has been discontinued, any suggestion on a currently available alternative?
It should be fine. It's an unmanaged switch which should simply flood STP traffic transparently.
I've actually taken some notes on the GS108T (although my notes are for the -200)
While it shouldn't necessarily require the RSTP step, it does seem to require the IGMP Snooping set to enabled.
STP
Basic
STP Configuration
Spanning Tree State: Disable
STP Operation Mode: RSTP
BPDU: Enable
Multicast
IGMP Snooping
IGMP Snooping Configuration
IGMP Snooping Status: Enabled
Let me know
While it shouldn't necessarily require the RSTP step, it does seem to require the IGMP Snooping set to enabled.
STP
Basic
STP Configuration
Spanning Tree State: Disable
STP Operation Mode: RSTP
BPDU: Enable
Multicast
IGMP Snooping
IGMP Snooping Configuration
IGMP Snooping Status: Enabled
Let me know
Hi there,
We have had a lot of problems on many of our client sites recently.
The key to fixing these has been to set all of our managed switches with a low bridge priority.
set them to:
- switch one: 4096
- switch two: 8192
- switch three: 12288
- etc. incrementing in multiples of 4096
This will ensure that the Sonos is not the root bridge.
Mr Sonos,
Could you please set your default bridge priority to something really high?
Because Sonos MAC addresses start with 00:0E they are pretty much always the lowest MAC and will win the BRIDGE PRIORITY BATTLE by default which will lead to issues in the network because the switches will do what the Sonos tells them.
Also do we need to have IGMP snooping running for best Sonos performance? will this help to contain the multicast traffic to sonos only devices?
Is there some online training that your dealers can do that will teach us about the advanced aspects of Sonos network best practice?
Thanks.
Gerard.
We have had a lot of problems on many of our client sites recently.
The key to fixing these has been to set all of our managed switches with a low bridge priority.
set them to:
- switch one: 4096
- switch two: 8192
- switch three: 12288
- etc. incrementing in multiples of 4096
This will ensure that the Sonos is not the root bridge.
Mr Sonos,
Could you please set your default bridge priority to something really high?
Because Sonos MAC addresses start with 00:0E they are pretty much always the lowest MAC and will win the BRIDGE PRIORITY BATTLE by default which will lead to issues in the network because the switches will do what the Sonos tells them.
Also do we need to have IGMP snooping running for best Sonos performance? will this help to contain the multicast traffic to sonos only devices?
Is there some online training that your dealers can do that will teach us about the advanced aspects of Sonos network best practice?
Thanks.
Gerard.
FYI the bridge priority is set at 0x9000 (36864) for all Sonos players/bridges except for the first unit to be registered, which has a priority of 0x8000 (32768).
Also do we need to have IGMP snooping running for best Sonos performance? will this help to contain the multicast traffic to sonos only devices?
I seem to recall that people had problems when IGMP snooping was enabled, as SSDP traffic wasn't being forwarded correctly.
Anyone looking for configuration settings of managed switches should also check this thread: Working STP settings of large cabled Sonos installation
Hello,
Thank you for the explanations regarding STP.
I have well understood that SONOS ZonePlayers can be connected to Ethernet switches that do not support Spanning Tree as long as the Ethernet switches do not interfere with the STP BPDU packets transmitted between ZonePlayers.
Does this guarantee that connections will be done using the wired network?
In other words:
I have a very simple Ethernet network with a unique central switch to which RJ45 wall plugs are directly connected. My goal is to connect the Sonos ZP to the RJ45 wall plugs and be sure that the network used will be the wired one and not the Sonos Wireless Network.
Does this imply to use a manageable switch to be able to set a higher STP priority for/to the wired links?
Or with a simple switch (that does not support STP but do not interfere with the STP BPDU) the Sonos ZPs will deactivate all the wireless links?
Thank you for your help,
Regards,
Ced
Thank you for the explanations regarding STP.
I have well understood that SONOS ZonePlayers can be connected to Ethernet switches that do not support Spanning Tree as long as the Ethernet switches do not interfere with the STP BPDU packets transmitted between ZonePlayers.
Does this guarantee that connections will be done using the wired network?
In other words:
I have a very simple Ethernet network with a unique central switch to which RJ45 wall plugs are directly connected. My goal is to connect the Sonos ZP to the RJ45 wall plugs and be sure that the network used will be the wired one and not the Sonos Wireless Network.
Does this imply to use a manageable switch to be able to set a higher STP priority for/to the wired links?
Or with a simple switch (that does not support STP but do not interfere with the STP BPDU) the Sonos ZPs will deactivate all the wireless links?
Thank you for your help,
Regards,
Ced
Thank you for the explanations regarding STP.
I have well understood that SONOS ZonePlayers can be connected to Ethernet switches that do not support Spanning Tree as long as the Ethernet switches do not interfere with the STP BPDU packets transmitted between ZonePlayers.
Does this guarantee that connections will be done using the wired network?
In other words:
I have a very simple Ethernet network with a unique central switch to which RJ45 wall plugs are directly connected. My goal is to connect the Sonos ZP to the RJ45 wall plugs and be sure that the network used will be the wired one and not the Sonos Wireless Network.
Does this imply to use a manageable switch to be able to set a higher STP priority for/to the wired links?
Or with a simple switch (that does not support STP but do not interfere with the STP BPDU) the Sonos ZPs will deactivate all the wireless links?
Thank you for your help,
Regards,
Ced
A dumb switch would not add to the path cost, which means that the Sonos units will prefer the wired link over the wireless. Usually problem arises with managed switch that uses RSTP path costs, which would be higher than the wireless links. In those cases, you must manually reconfigure the managed switch to use classic STP or manually set the path costs for the Sonos ports to decent values.
Hello,
Thank you for your answer!
Regards,
Ced
Thank you for your answer!
Regards,
Ced
I have now tried to battle with STP and Sonos. My network switches are all netgear gs108t v1 + v2 and gs716t. I have two sonos components a zp90(connect) and a play:1. Theese are connected to different switches. On the play:1 the port on the switch goes into discarding state, port cost is set to 10.
Does anyone know if flow control should be enabled for the ports Sonos components are wired into?
Linksys by default sets all ports to 'none' for flow control instead of auto.
Just curious if this would help my situation. I have occasional hiccups with the STP settings where my system becomes unresponsive, but I'm trying to isolate STP issues that could possibly be causing my Linksys LAPAC1750PRO WAP's to stop working.
Linksys by default sets all ports to 'none' for flow control instead of auto.
Just curious if this would help my situation. I have occasional hiccups with the STP settings where my system becomes unresponsive, but I'm trying to isolate STP issues that could possibly be causing my Linksys LAPAC1750PRO WAP's to stop working.
Sonos does not support Ethernet and personal WiFi at the same time. E.g., if you have two Sonos devices, and configured Sonos to connect to your home WiFi, and then connect one of them to Ethernet, Sonos will NOT use your personal WiFi. It will turn the device you connected to Ethernet into a SonosNet Bridge and then the other wireless device will attempt to connect to that instead of your personal WiFi. So then the connectivity problems with the wireless node become an issue of how far/what is the signal quality between it and your wired Sonos device? In this case, if you can't get Ethernet to the wireless zone, then you might be better off disconnecting Ethernet from the wired zone and letting them both use your personal WiFi instead of SonosNet, since it sounds like you only have two Sonos devices so WiFi bandwidth shouldn't be an issue.
Or am I still miss-understanding your zone configuration?
Or am I still miss-understanding your zone configuration?
After many years of troubles and endless hours of trying to reconfigure my switches and numerous fine updates on the SONOS software providing good features to us customers, I still wonder why SONOS never provided a feature allowing to switch from the very old IEEE 802.1D-1990 standard (the one proposing the cost to be 19 for 100MB link) to the more recent version of 1998 which would be more in line of nowadays default settings off the shelf switches are using.
Is there a reason why?
Is there a reason why?
Is there a reason why?
My guess is that this is just a legacy, but requires big changes to work as expected. The players calculates a dynamic path cost depending on the wireless signal quality, and to "adjust" this according to 802.1W standards is probably not as straight forward as one would expect.
Changing this would also break all current installations, as well as breaking backward compatibility with 802.1d-only switches (although, I would guess that these are rare today). Best option would be to make this configurable, but that is another complexity added to a system that strives for simplicity. There's probably a reason that most modern switches has a "classic" mode available too, maybe because there is still a big need for it.
Another reason could be that the linux kernel only seem to support 802.1d, and 802.1w seems to be available as a separate daemon. This might not integrate well with how the Sonos player operates, or add to much memory footprint to be usable in these limited devices, who knows.
Now, I only use 1 switch, and didn't have an issue reconfiguring it to work well with Sonos. It simplifies it a bit if you can isolate all your Sonos gear to 1 switch, but you should be able to correctly configure multiple switches as well, as long as you can lower the path cost for uplinks as well.
While it shouldn't necessarily require the RSTP step, it does seem to require the IGMP Snooping set to enabled.
STP
Basic
STP Configuration
Spanning Tree State: Disable
STP Operation Mode: RSTP
BPDU: Enable
Multicast
IGMP Snooping
IGMP Snooping Configuration
IGMP Snooping Status: Enabled
Let me know
Well, had my network go down today with a storm. Was working fine but I noticed that the Playbar network cable was unplugged. Plugged it in and down it went (I have another unit plugged in).
Now I had three gs108tv2's in a chain, all with stp enabled, however this did not seem to work. Set them up as shown above and now it's working perfectly again ! Cheers.
Hello I really need your Help because you seem the best on SONOS products in the world.
If you could read the poor french forums and all the people crying for what I know now to be a broadcast storm !
I am so happy to finaly be able to put a name on my problem.
Anyway now I need you help to solve it because I don't have a managable switch with STP. Is there a quick and easy solution on the config menus of the players ?
Do i have to disable WIFI to all my RJ45 wired SONOS players ? Would it help or my only solution is to buy new switches with stp manageable ?
Excuse my english and thx for you help
Regards
Charles
If you could read the poor french forums and all the people crying for what I know now to be a broadcast storm !
I am so happy to finaly be able to put a name on my problem.
Anyway now I need you help to solve it because I don't have a managable switch with STP. Is there a quick and easy solution on the config menus of the players ?
Do i have to disable WIFI to all my RJ45 wired SONOS players ? Would it help or my only solution is to buy new switches with stp manageable ?
Excuse my english and thx for you help
Regards
Charles
Charlie, what is the model of network switch that you have? There are some unmanaged switches that block STP, though they are not common.
Deactivating the wireless on your wired Sonos players might also work, but leave it enabled on only one of them, so any wireless players can still connect.
----------
French Translation from Google... Hopefully it's accurate. :)
Charlie, ce qui est le modèle de commutateur de réseau que vous avez? Il y a des commutateurs non administrables qui bloquent STP, si elles ne sont pas communs.
Désactiver le sans fil sur vos lecteurs Sonos câblé pourrait également fonctionner, mais le laisser activé sur un seul d'entre eux, de sorte que tous les joueurs sans fil peuvent toujours se connecter.
Deactivating the wireless on your wired Sonos players might also work, but leave it enabled on only one of them, so any wireless players can still connect.
----------
French Translation from Google... Hopefully it's accurate. :)
Charlie, ce qui est le modèle de commutateur de réseau que vous avez? Il y a des commutateurs non administrables qui bloquent STP, si elles ne sont pas communs.
Désactiver le sans fil sur vos lecteurs Sonos câblé pourrait également fonctionner, mais le laisser activé sur un seul d'entre eux, de sorte que tous les joueurs sans fil peuvent toujours se connecter.
Hey MikeV what's the chances of improving SonosNet to understand the STP path metrics the rest of the world has moved onto?
I've been buying Sonos gear for 10 years and am up to 9 zones in my house and love it; you make seriously the best working and least troublesome consumer electronics in the entire market. There are other companies with a reputation for "it just works" but they can't hold a candle to Sonos. EXCEPT for this dratted STP issue which has cost me hours of troubleshooting on multiple occasions. I used to have dumb switches and they work fine because there was no other STP in the mix and I didn't know what STP was and didn't have to. I upgraded my network to a low-end Cisco switch and everything broke, after quite a bit of troubleshooting I realized this was the cause and there was a way to tell the Cisco switch to use the old path costs, problem solved. Except this year I upgraded my network to an overall much nicer Ubiquiti Unifi switch, and the problems were a lot more subtle which meant they were a lot harder to track down but once again it turns out to be my good friend, conflicting STP path costs.
So now I have this fancy switch (Unifi) and this fancy self-configuring mesh network (Sonos) and they have incompatible STP implementations and neither one can be configured because in the modern world you're not supposed to configure things.
Well. So now I get to either unplug ethernet from all but 1 of my Sonos zones so SonosNet has no loops back onto my wired LAN (but then I might be subject to wireless interference), or unplug ethernet from ALL of my Sonos zones so they join my normal WiFi network, or play around with selectively disabling wireless on only some Sonos zones (all of these leave me more exposed to the vagaries of WiFi than I want to be), or figure out how to disable STP entirely on the Unifi switch, which is apparently possible but not easy.
It would be really really nice if Sonos STP played nice with the rest of the modern world, though, pretty please?
I've been buying Sonos gear for 10 years and am up to 9 zones in my house and love it; you make seriously the best working and least troublesome consumer electronics in the entire market. There are other companies with a reputation for "it just works" but they can't hold a candle to Sonos. EXCEPT for this dratted STP issue which has cost me hours of troubleshooting on multiple occasions. I used to have dumb switches and they work fine because there was no other STP in the mix and I didn't know what STP was and didn't have to. I upgraded my network to a low-end Cisco switch and everything broke, after quite a bit of troubleshooting I realized this was the cause and there was a way to tell the Cisco switch to use the old path costs, problem solved. Except this year I upgraded my network to an overall much nicer Ubiquiti Unifi switch, and the problems were a lot more subtle which meant they were a lot harder to track down but once again it turns out to be my good friend, conflicting STP path costs.
So now I have this fancy switch (Unifi) and this fancy self-configuring mesh network (Sonos) and they have incompatible STP implementations and neither one can be configured because in the modern world you're not supposed to configure things.
Well. So now I get to either unplug ethernet from all but 1 of my Sonos zones so SonosNet has no loops back onto my wired LAN (but then I might be subject to wireless interference), or unplug ethernet from ALL of my Sonos zones so they join my normal WiFi network, or play around with selectively disabling wireless on only some Sonos zones (all of these leave me more exposed to the vagaries of WiFi than I want to be), or figure out how to disable STP entirely on the Unifi switch, which is apparently possible but not easy.
It would be really really nice if Sonos STP played nice with the rest of the modern world, though, pretty please?
I guess there's nothing to stop Sonos factoring all path costs -- wired and wireless -- by 20000, unless there's a 16-bit/65k limit in there somewhere. Given their redoubled focus on new, streaming customers -- most presumably connected via WiFi ('Standard Setup') -- in order to remain profitable, they might not feel that such tweaks are of the highest priority.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.