Spanning Tree issues on TP-Link/Omada after replacing downstream/edge switch.

My first question would be what provides your normal WiFi throughout the house and is it a mesh system, i.e. more than one unit? Second would be does it work well? 

I looked into this when I got a managed/smart switch. Didn't take me long to return the switch and hook my Sonos back to my dumb ones. I'm sure there are more technical solutions but I wanted music, not frustration.

I use UniFi managed switches without issue but the best practice applies to other manufacturers, use either WiFi or wired never mix the two in a household. If wired disable WiFi on all Sonos devices. 
 

You could try disabling WiFi on just the two wired Sonos devices and hopefully this will stop the STP loop.

The reason I asked if your existing non-Sonos WiFi is good or not is because the version of STP Sonos use on Sonosnet is very old and not very easy to get going with other more modern devices. It’s very easy for it all to get confused. Any modern mesh WiFi system (even if you only use one unit) will not play nicely with Sonos unless your managed switch can translate between old and new STP implementations. Cisco can do this for example. However… it’s a ball ache to be frank. The simplest solution is to abandon Sonosnet and then STP does not matter. If you have a managed switch, the best thing to do here is to disable STP on the ports Sonos devices are on if it lets you. 

Then configure Sonos to just use your main WiFi which these days is way more robust than when Sonosnet was a good idea. 

The other thing on a managed switch that you need to get right is multicast or IGMP. It’s probably best to have your WiFi or the router that provides NAT to run the IGMP querier process, but your managed switches should deploy IGMP snooping. This allows the switch to look at IGMP requests so it can only send packets to ports with interested devices and not flood the whole network with multicast packets. Get this wrong and speakers will fall out of groups or not join and drop audio… 

To disable Sonosnet, power off all Sonos devices then power on and connect the ethernet connected devices one at a time and go into the settings in the iOS app to disable WiFi. Then do the next one. The big caveat here is if you have a soundbar, you cannot disable WiFi if you use a Sub or surround speakers as the soundbar needs WiFi to communicate with them, so to not get Sonosnet you can’t wire in any soundbar that supports Sonosnet. When you then turn on the WiFi only devices, as there is no Sonosnet available they use the main WiFi. 

The reason I asked if your existing non-Sonos WiFi is good or not is because the version of STP Sonos use on Sonosnet is very old and not very easy to get going with other more modern devices.

I read that somewhere, but I thought I read the plain “STP” setting was the old version. But maybe that explains why SonosNet isn’t split between the two ethernet-connected speakers.

I don’t have mesh wifi, I have hard-wired APs. The SonosNet is on a separate channel from my APs, so it has not been a big issue.

but your managed switches should deploy IGMP snooping. 

I need to research that more. TP-Link support suggested enabling IGMP, but I’ve toggled it both ways and I see no difference.

Then configure Sonos to just use your main WiFi which these days is way more robust than when Sonosnet was a good idea. 

That’s probably the right approach. My 2.4G band is pretty quite, which is what Sonos uses (for wifi, too, not just SonosNet?) Just a bit of a pain to plug in each speaker -- sure wish there was more ethernet in the walls!

And there’s no reason some speakers can’t still be hard-wried in that case, correct?

Now I have to decide if it would be smart to create a separate Sonos VLAN -- and what all I’d break doing that...

Just to satisfy my curiosity, if everything was configured correctly (and I had the right version of STP on my network equipment), would SonosNet split between two more more hard-wired speakers? Is that what the “STP state” in the Sonos matrix was supposed to indicate?

Thanks.

“Plain” STP comes in two different types, short and long cost path values. Sonosnet uses the very old short values which will cause problems with anything expecting long ones. Some switches allow you to customise etc. but like I say, I think your time is best spent getting your normal WiFi running well and getting rid of Sonosnet. 

Unless all your kit is really old, things like Play:3’s, Play:1’s, One’s etc. can run on 5GHz, not just 2.4. 

Although people often recommend either plug all or plug none, you can mix & match, you just have to follow the sequence I posted to make sure you don’t accidentally create Sonosnet. New Era Sonos speakers don’t support Sonosnet at all. 

A separate VLAN with Sonosnet may cause you all sorts of headaches. In this scenario you may have to route multicast between VLAN’s, which can be complicated. Or if you try and keep them fully independent, your switch will need to provide the IGMP querier function for the Sonos VLAN and not interfere with that function on your main WiFi which is used by quite a few things these days like smart TV’s and even Philips Hue. 

I looked at VLANs and decided they were more frustration than I wanted to deal with.

For me just using one of the other LAN ports on my router was far simpler, just move an Ethernet wire or two. Moved the Access Point, NAS and my (back then) wired Sonos to it. Then went back and started moving other things that were not happy crossing LANs. Looked at the final result and realized I'd accomplished nothing by all this and went back to a single LAN.

​@Ian_S: Although people often recommend either plug all or plug none, you can mix & match, you just have to follow the sequence I posted to make sure you don’t accidentally create Sonosnet.

It’s surprisingly hard to find info on NOT creating SonsNet when connecting to ethernet, yet still leave the device’s wifi enabled. Is that at all not possible?

Does not sound like it:

To disable Sonosnet, power off all Sonos devices then power on and connect the ethernet connected devices one at a time and go into the settings in the iOS app to disable WiFi. Then do the next one. The big caveat here is if you have a soundbar, you cannot disable WiFi if you use a Sub or surround speakers as the soundbar needs WiFi to communicate with them, so to not get Sonosnet you can’t wire in any soundbar that supports Sonosnet. When you then turn on the WiFi only devices, as there is no Sonosnet available they use the main WiFi. 

I don’t have ethernet cable available everywhere, so I have to use home wifi or SonosNet.

And unfortunately, I have a Soundbar with a Sub and two surrounds, which requires wifi to be enabled, in a place where home wifi is not the best. But, there’s ethernet available at the Soundbar.

So, if I plug in the Soundbar to ethernet, and all my other speakers have Wifi enabled, that will cause other speakers in range of the Soundbar to switch over to SonosNet.

It’s very odd that is not possible to disable SonosNet as it’s very common to have devices that can be connected to either (like a laptop).

I do have a number of Play:1 (and Sonos One’s) connected in stereo pairs. From my understanding, unlike the Playbar, stereo pairs do not use 5GHz to talk directly to each other. That is, for those, if one is connected to ethernet just disable its wifi.

There is no control other than the horribly mislabeled "disable wifi" available so your choice is:

1. Internal radio on

2. Internal radio off

Many requests for more flexibility on enabling Sonosnet but the Sonos plan seems to be focused on Wi-Fi setups for the majority of users while keeping the ability to connect to Ethernet (without Sonosnet) as an extra cost option on the newest gear.

Fix the WiFi? If it was me, I would unplug all Sonos and setup in Wireless Mode, and where you have an ethernet connection and poor WiFi (eg in your example above) plug an AP in. If you have poor WiFi, then your controller(s) will struggle, even if your wired SonosNet is working after juggling with STP configuration. In Sonos Wireless Mode, you will free up an additional 2.4GHz channel used by SonosNet and use for your new AP.

Yep, I just ordered another AP for that location.

And really, the normal music traffic on the 2.5GHz wifi is not very significant and not a reason for hard-wiring, and even if my Soundbar was on ethernet, the home theater is via an optical link to the Soundbar and it would still have the 5GHz traffic to its satellites.

Thanks all for hitting me over the head with a hammer enough time to solve this w/o having to bitch too much about Sonos not having a simple toggle in their app to disable SonosNet...

Always worth complaining, not worth holding your breath for, as Sonos has a lot of other priorities that the developers need to spend time on.

Still be nice to see.

Even just a wording change to that toggle would help.

Thinking this through a bit, I think your switches are doing what you would expect. As the ES205GP is a dumb switch it can’t be configured to block, so to prevent the network loop you have created, STP blocks on the managed switch as you have made it the STP root bridge, and therefore ‘in charge’. If you replace the dumb switch with an STP capable managed switch then I expect the shortest path would get used, however the Sonosnet part could make some poor decisions. Don’t ignore the STP setting Sonos recommend to use ‘short’ cost values.

I think you’re assuming that you can split the load of Sonosnet between two wired nodes but that is not possible as that is by definition a network loop which STP is trying to prevent.. Having a pair of Sonos devices wired provides Sonosnet itself with some resilience should the connected node fail/reboot. The latter is quite likely in the event of a firmware update where everything gets rebooted in a random order. The blocked port will not send data frames to the Sonos device. That device will be getting its data over Sonosnet unless the other wired device goes offline. After a firmware update I would expect your network to settle back into the same config as once the device connected to the managed switch completes its reboot, STP will realise there’s a loop and block the port again. 

Sonosnet doesn’t just handle Sonos traffic as I seem to recall you could plug other non-Sonos devices into ports on older equipment that had multiple ports. So it has to respect STP rules. 

However, Sonosnet is old technology which is not very efficient at doing what it needs as it’s using WiFi tech that is not ideal. See here:

https://cyberraiden.wordpress.com/2025/03/19/understanding-and-configuring-wifi-network-multicast-rate/

The implication being that larger Sonos installs will start to benefit more from going to WiFi 6 capable devices if you can and ignoring Sonosnet. So:

https://support.sonos.com/en-gb/article/supported-wifi-modes-and-security-standards-for-sonos-products

Time to upgrade to Era’s and Ultra;s :) Or ditch Sonosnet and then STP only matters between switches and multiple wireless AP’s … 

It is certainly possible to wire multiple Sonos devices and have SonosNet actively use the available wired connections. There are plenty examples in this forum where users have posted pics of their network matrix evidencing multiple wired connections.

Would like to understand that from an STP perspective then…. 

That is exactly what the matrix shows, ie forwarding or blocking the network path.

Before consumer level mesh networks were generally available, I would wire other devices to a SONOS network port. It was not a very fast connection. Maybe it could approach 30Mbps if conditions were perfect. 7-10Mbps was more typical (shared with the SONOS music), but in the days of slow ADSL Internet connections this was fine. The best part of this scheme was that no configuration was required -- simply plug and play. (Unless, of course a managed switch was used, but these were less common in consumer land back then.) 

​@Ian_S: Thinking this through a bit, I think your switches are doing what you would expect. As the ES205GP is a dumb switch it can’t be configured to block, so to prevent the network loop you have created, STP blocks on the managed switch as you have made it the STP root bridge, and therefore ‘in charge’. If you replace the dumb switch with an STP capable managed switch then I expect the shortest path would get used, however the Sonosnet part could make some poor decisions. Don’t ignore the STP setting Sonos recommend to use ‘short’ cost values.

We are getting way off (topic) into networking (tbh which is what I’m more curious about), and moving away from SonosNet seems to be THE answer. But always nice to understand how it all works...

I was curious also about the dumb switch in the mix. I do have another managed SG2009 switch and I’ll swap out the dumb switch for testing just to see what happens. Since the Sonos Matrix shows some devices are STP blocking and some forwarding, I’m really curious if the loop will get blocked in SonosNet and thus split SonosNet between the two ethernet connected speakers. (Maybe Sonos STP is incompatible with my Omada/TP-Link STP, too.)

Note, that there still is a managed switch upstream (the root) from the dumb switch that could have decided to block, but STP decided the “shortest” path was through the dumb switch.

From my basic understanding of STP, the configurable part of the cost value (the port priority setting) may not really come into play -- it’s kind of way down the list (last?) of building the root path cost. It’s more the link cost, although I’m not sure how that works with Sonos devices in a mesh. Are they acting as switches? That STP state blocking/forwarding in the matrix makes me think they are acting as switches. But if that is the case (and they effectively block the loop, then my 2 switch ports connected to speakers should (eventually) not block.

Too bad I can’t see the calculated root cost for all the SonosNet “ports”.

​@64busman - Do the managed switches show any values for STP path costs at all? If you see big numbers then there could be a mismatch between Omada/Sonos causing the wrong paths to get blocked? 

I think Sonos uses the lower values but many newer switches use the right… or a variation of. 

I can't develop a lot of enthusiasm here, STP is 1990s tech and has been obsolete since 2001 or so for new hardware.

No option for S1 systems but seeing newer protocols in S2 would be very nice.

Well, it works.

I replaced the ES205G with an SG2008P. I configured every port (upstream, or downstream to a Sonos speaker) exactly the same with STP priority 128, not that I think it matters. Assigned the root switch a CIST Priority of  zero, and the two downstream switches 4096 (below the 32768 as noted in Best Practices doc in my first post).

I wonder how hard it would be to generate a network map from the matrix.

$ python3 sonos_discover.py
Kitchen. State: PLAYING
  Title: The Times They Are A-Changin'
  Album: The Times They Are A-Changin'
  Artist: Bob Dylan
  Uri: x-sonos-spotify:spotify:track:52vA3CYKZqZVdQnzRrdZt6?sid=12&flags=8232&sn=21
   Guest Room vol:40 192.168.0.35 Channel:RF:
   Guest Room vol:40 192.168.0.38 Channel:LF:
   Back Bedroom vol:46 192.168.0.24 Channel:RF:
   Back Bedroom vol:46 192.168.0.7 Channel:LF:
   Bar vol:56 192.168.0.34 Channel:None:
   Family Room vol:47 192.168.0.49 Channel:SW: Subwoofer Satellite
   Family Room vol:47 192.168.0.29 Channel:LR: Satellite
   Family Room vol:47 192.168.0.145 Channel:LF,RF: Sound bar
   Family Room vol:47 192.168.0.27 Channel:RR: Satellite
   Kitchen vol:41 192.168.0.30 Channel:RF:
  *Kitchen vol:41 192.168.0.23 Channel:LF:
   Living Room vol:43 192.168.0.39 Channel:LF:
   Living Room vol:43 192.168.0.10 Channel:RF:
   Sub Mini vol:43 192.168.0.40 Channel:SW: Subwoofer

Now time to convert it all to wifi….

Thanks everyone.

I think that the Bar is struggling a little. Are there any nearby devices that you could move?

Are you saying that because of the high OFDM level? The “Bar” is hard-wired to ethernet, so it’s fine.

SonosNet is on channel 1. That “Bar” (which is as Sonos Amp) is in the same room with an Access Point, so maybe that’s causing the high reading. That said, the AP is on Channel 6 and there’s very little 2.4GHz traffic on it.

Here’s the Bar’s interfaces showing it’s hard-wired connection and the Sonos devices it is connected to.

(BTW, anyone know if there’s a way to get this data from the devices in a more easily parsable way from a script?)

running /usr/sbin/brctl showstp br0br0 bridge id		9000.5caafde71e0e designated root	0000.3460f9c49f82 root port		   2			path cost		20010 max age		  20.00			bridge max age		   6.00 hello time		   2.00			bridge hello time	   1.00 forward delay		  15.00			bridge forward delay	   4.00 ageing time		  60.00			gc interval		   0.00 hello timer		   0.00			tcn timer		   0.00 topology change timer	   0.00			gc timer		   3.11 flags			eth0 (1) port id		8001			state			disabled designated root	8000.5caafde71e0e	path cost		  10 designated bridge	8000.5caafde71e0e	message age timer	   0.00 designated port	8001			forward delay timer	   0.00 designated cost	   0			hold timer		   0.00 flags			eth1 (2) port id		8002			state			forwarding designated root	0000.3460f9c49f82	path cost		  10 designated bridge	1000.503dd1651537	message age timer	  18.11 designated port	8007			forward delay timer	   0.00 designated cost	20000			hold timer		   0.00 flags			ath0 (3) - tunnel to 78:28:CA:A6:3C:F9 (remote STP state = forwarding, direct = 3) port id		8003			state			forwarding designated root	0000.3460f9c49f82	path cost		 202 designated bridge	9000.5caafde71e0e	message age timer	   0.00 designated port	8003			forward delay timer	   0.00 designated cost	20010			hold timer		   0.66 flags			ath0 (4) - tunnel to 94:9F:3E:17:36:C3 (remote STP state = blocking, direct = 3) port id		8004			state			forwarding designated root	0000.3460f9c49f82	path cost		 250 designated bridge	9000.5caafde71e0e	message age timer	   0.00 designated port	8004			forward delay timer	   0.00 designated cost	20010			hold timer		   0.66 flags			ath0 (5) - tunnel to F0:F6:C1:8A:0B:BB (remote STP state = forwarding, direct = 3) port id		8005			state			forwarding designated root	0000.3460f9c49f82	path cost		 250 designated bridge	9000.5caafde71e0e	message age timer	   0.00 designated port	8005			forward delay timer	   0.00 designated cost	20010			hold timer		   0.66 flags			ath0 (6) - tunnel to 94:9F:3E:66:16:27 (remote STP state = blocking, direct = 1) port id		8006			state			forwarding designated root	0000.3460f9c49f82	path cost		 226 designated bridge	9000.5caafde71e0e	message age timer	   0.00 designated port	8006			forward delay timer	   0.00 designated cost	20010			hold timer		   0.66 flags			ath0 (7) - tunnel to F0:F6:C1:8B:C2:21 (remote STP state = forwarding, direct = 3) port id		8007			state			forwarding designated root	0000.3460f9c49f82	path cost		 235 designated bridge	9000.5caafde71e0e	message age timer	   0.00 designated port	8007			forward delay timer	   0.00 designated cost	20010			hold timer		   0.66 flags			ath0 (8) - tunnel to 94:9F:3E:8D:3D:97 (remote STP state = blocking, direct = 3) port id		8008			state			forwarding designated root	0000.3460f9c49f82	path cost		 269 designated bridge	9000.5caafde71e0e	message age timer	   0.00 designated port	8008			forward delay timer	   0.00 designated cost	20010			hold timer		   0.66 flags			ath0 (9) - tunnel to F0:F6:C1:06:18:CF (remote STP state = forwarding, direct = 3) port id		8009			state			forwarding designated root	0000.3460f9c49f82	path cost		 202 designated bridge	9000.5caafde71e0e	message age timer	   0.00 designated port	8009			forward delay timer	   0.00 designated cost	20010			hold timer		   0.66 flags			ath0 (10) - tunnel to 94:9F:3E:F4:E2:9B (remote STP state = blocking, direct = 3) port id		800a			state			forwarding designated root	0000.3460f9c49f82	path cost		 254 designated bridge	9000.5caafde71e0e	message age timer	   0.00 designated port	800a			forward delay timer	   0.00 designated cost	20010			hold timer		   0.66 flags			ath0 (11) - tunnel to 78:28:CA:A7:8E:29 (remote STP state = blocking, direct = 3) port id		800b			state			forwarding designated root	0000.3460f9c49f82	path cost		 259 designated bridge	9000.5caafde71e0e	message age timer	   0.00 designated port	800b			forward delay timer	   0.00 designated cost	20010			hold timer		   0.66 flags			ath0 (12) - tunnel to 94:9F:3E:8D:3E:21 (remote STP state = blocking, direct = 3) port id		800c			state			forwarding designated root	0000.3460f9c49f82	path cost		 719 designated bridge	9000.5caafde71e0e	message age timer	   0.00 designated port	800c			forward delay timer	   0.00 designated cost	20010			hold timer		   0.66 flags