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

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.