Skip to main content

One of the consistent issues I (and many network implementors) have with Sonos equipment is dealing with the older/pre-standard STP path costs Sonos equipment presently uses (10 for Fast Ethernet vs the  commonly used 19). This is especially problematic with when multiple tiered switches are installed on a network and path cost modification isn’t practical.

Unifi (Ubiquiti) based switching networks can be especially problematic in this regard. Unifi switching can be set to STP or RSTP, but path costing can’t be edited persistently.

With Sonos S2 coming, are there any plans to modernize / update the spanning tree implementation to support the current STP path cost standards, or better yet, support RSTP?

Sonos, please support RSTP, or at least update your STP path costs! This is such a nightmare to deal with on managed switches!


Pleeeeease do this. More devices use rstp now than stp. It makes sonos a nightmare in larger IOT home networks


Okay - Question : If you reserve the IP address for the SONOS device - Does that help? I have just purchased a Dream machine UDM-US, US-8-60W, 2 US-Flex-Mini and 1 UniFi Switch Flex - I want to split everything off IoT, Sonos ( can put this in IoT), Work, Family - I read one post that talked about being able to turn on RSTP but turning on STP on ports connected to SONOS. Reserving IPs will not solve everything - so not say it will - It would seem to help with 45 seconds to get an IP address.

 

It might help if your only issue is DHCP taking a long time.  Sonos will screw up your network if you do anything more than home-run all your ethernet back to your UDM-P or main switch.  (FWIW, I have UDM-P and 24-port PoE Unifi.) An example is adding a PoE mini switch from UBNT that I wanted to use behind the TV to connect AppleTV, STB, TV, and Sonos.  One little USW-Flex-Mini was perfect for this.  No power wall-wart needed.  Not to be though.  STP issues started causing all my traffic to pass over the SonosNet 2.4Ghz 100mb network. Unless I turn off wifi on the Sonos connected there, I can’t use the USW-Flex-Mini.  I need the wifi on though because one odd-ball Sonos3 is closest to that one and can’t get cat6 pulled to it.

I will note that the In-wall access point (UAP-IW-HD-US) does work with my Sonos PlayBase (which needs wifi for the rear Sonos1 rears) because it behaves strangely.  The UAP-IW-HD-US makes everything attached to it appear to be connected to the uplink port almost like a FEX.  I wasn’t happy that I couldn’t see the UAP-IW-HD-US as a switch in some ways at first, but this turned out to be a lucky thing and it works despite the Sonos STP stupidity.

 

Sonos: Please support RSTP in S2!  Come on...


I am a HEAVY user of Sonos right now.  We are looking at a new home build.  I work in IT.  I am considering abandoning Sonos over this issue.  It is pitiful this hasn’t been addressed.  It’s been a chronic problem for years.  It’s a simple fix.  It would vastly improve larger implementation setup with multi-tiered switches and larger Wi-Fi deployments.  And STP?  Support RSTP and be done with it.  Alternatively, let me disable the BRIDGE portion of WI-FI so I don’t get port blocking in the UniFi gear.  

 

I rarely comment in the forums here, but this is a pretty simple change to embrace a networking standard - of which your products really HEAVILY to make things work.  By supporting these standards, users will get more consistent results without as much frustration.  This is a win/win for everyone involved, not the least of which is SONOS own tech support team.  


Yes, you can implement the older STP which also disables RSTP.  This begs the question of why.  It’s because SONOS uses non-standard link costs in their RSTP implementation.  Anytime there is a new device added to the network, you’re going to have to wait 45 seconds or more just to get an IP address.  That’s stupid.  Update the route costs so RSTP works.  Bingo, bango, everyone’s happy.  


I think the rest of us are happy already. 

Was that assessment based on some polling? Or, by “the rest of us”, do you mean the vast majority of households who don’t use Sonos or use Amazon or Google smart speakers?  If Sonos is simply targeting customers like you describe who are happy and have a couple devices, good luck to them with that market segment. Amazon and Google sell speakers with “good enough” audio that integrate with Alexa and music services quite well. They’re MUCH cheaper and are dominating and expanding the market Sonos used to own*. Apple sells HomePod which sounds comparable or better than Sonos and has a network that simply works and extends Bluetooth to HomeKit devices that use that protocol. None of them screw up your network by design that I’m aware of.

To be fair, if you are the owner of a very small network at home, Sonos probably works fine.  This is likely if you don’t have a managed network that uses anything like spanning tree protocols because you only have one switch/hub/router. However, for those of us with large networks at home, dozen(s) of Sonos devices, or a commercial establishment, they basically use a broken network implementation and tout it as a feature. 

* According to eMarketer report, some 70 percent of US smart speaker users will use an Amazon Echo in 2020, close to 2019’s 72.9 percent. By next year, that number may drop slightly to about 68.2 percent, according to the report. eMarketer says just 31.7 percent of smart speaker owners will use a Google device in 2020, and Apple’s home speaker products got lumped into the mixed “other” category, which is expected to barely crack 18 percent this year.]

 


I think the rest of us are happy already. 


This thread has provided me a lot of information that I had forgotten about related to the SONOS STP implementation. It helped me resolved a issue that just occurred when I replaced a failed managed switch and forgot to dumb down the STP path cost to the older standard.


very disappointing to see that S2 is still using the same antiquated STP implementation :confused:


Out of genuine curiosity, what does 'disable the Bridge portion of WiFi' mean?

And how is this affected by the fact that Sonos will often use direct routing rather than the STP paths anyway?


Since they haven’t yet released any specific information about S2, we don’t know yet. And if it is coming, but just not in the initial release, Sonos won’t tell us anyway, as they don’t announce software update features before they are released. 


I guess not… :(


Sad, this feels like such a missed opportunity to modernise the path costs.


As far as I’m aware, Sonos hasn’t abandoned their code base, and continues to develop it. There’s no guaranty that they’re not going to do this at a future time, only that they didn’t do it at this precise moment in time. 


I am a HEAVY user of Sonos right now.  We are looking at a new home build.  I work in IT.  I am considering abandoning Sonos over this issue.  It is pitiful this hasn’t been addressed.  It’s been a chronic problem for years.  It’s a simple fix.  It would vastly improve larger implementation setup with multi-tiered switches and larger Wi-Fi deployments.  And STP?  Support RSTP and be done with it.  Alternatively, let me disable the BRIDGE portion of WI-FI so I don’t get port blocking in the UniFi gear.  

 

Sonos STP Switch Settings


Okay - Question : If you reserve the IP address for the SONOS device - Does that help? I have just purchased a Dream machine UDM-US, US-8-60W, 2 US-Flex-Mini and 1 UniFi Switch Flex - I want to split everything off IoT, Sonos ( can put this in IoT), Work, Family - I read one post that talked about being able to turn on RSTP but turning on STP on ports connected to SONOS. Reserving IPs will not solve everything - so not say it will - It would seem to help with 45 seconds to get an IP address.