Answered

Let me choose how Sonos measures path cost to match that of other participants in the Spanning Tree Algorithm (e.g. eero)

  • 27 August 2018
  • 7 replies
  • 608 views
R
Userlevel 2
Badge
I have recently added an eero Pro Wifi System to my network to improve my wifi performance and replace my ISP router. Unfortunately, there are some Spanning Tree path cost issues between my switch, eero and Sonos devices that I can not resolve.

My existing network topology consists of a single core switch with a link to the internet router and multiple links to access switches which are distributed across the rooms in my house. Devices that can be are all wired to these access switches.

Some of these wired devices are Sonos Zone Players. Sonos supports its own wireless mesh system so that owners only have to wire in one such device and all the others will be reached wirelessly through that one. However, I have wired all but one of my Sonos devices because wiring is faster and more reliable than wireless.

This Sonos wireless infrastructure supports standard Layer 2 bridging with the switches they are connected to. This introduces loops in my network which must be addressed with a cooperative Spanning Tree Algorithm that runs across all of the switches and Sonos devices. This algorithm produces a logical tree (with no loops) that is used to determine the cheapest path between all devices.

To support the evaluation of the Spanning Tree, path cost needs to be taken into account. Unfortunately, the Sonos devices have a different way of measuring cost (802.1D-1998) than my switches (802.1W-200). The only way that I can resolve this is to force my switches to use the same "currency" as the Sonos devices. This works well.

https://en.wikipedia.org/wiki/Spanning_Tree_Protocol

One of the three units in the eero Pro Wifi system replaced my ISP router and is wired to my core switch. The other two were strategically placed about my house and hard wired into access switches.

Unfortunately, apparently, eero also uses a different path cost "currency" (802.1W-200?) than the Sonos devices. This is evidenced by me removing the 1 Gbit/s link (path cost 4) between my core switch and an access switch (with both an eero (path cost 4) and a Sonos device (path cost 19)) and noting that the Spanning Tree Algorithm determines the next lower cost path is through the Sonos wireless mesh instead of eero. From this choice, I must assume that path costs are measured higher in the eero mesh than the Sonos mesh.

To fix this Spanning Tree issue, I need all participants in the algorithm to use the same path cost "currency". While I am afforded a choice on my switches, I have no such choice on my eero or Sonos devices.

On Sonos, please give me this choice.
icon

Best answer by ratty 27 August 2018, 20:12

View original
This topic has been closed for further comments. You can use the search bar to find a similar topic, or create a new one by clicking Create Topic at the top of the page.

7 replies

ratty
I understand the point, but you evidently had a network which worked okay using 802.1D 'Classic' STP -- even with the Eero units -- until you removed the trunk connection between core and access switches, yes? Why would you want to dispense with that? Even if SonosNet wasn't the cheapest path you'd still be relying on the Eero wireless mesh for backhaul, which seems strange if you have an Ethernet cable available.

As for having Sonos effectively replace the STP stack with RSTP I'd be amazed if they were to consider it. Theirs is a heavily customised/tuned version of STP, designed to take into account variable wireless conditions. The potential for regression is huge. The standard advice when dealing with a meshed wireless system such as Eero is simply to wire just one Sonos unit and leave SonosNet to do its thing.
R
Userlevel 2
Badge
Yes, I have a "working" solution. No, I would not want to dispense with my wired trunks between my core and access switches. I only removed a wired trunk between my core and an access switch to expose this problem. That is, the participants in the Spanning Tree Algorithm do not measure path costs in the same way. This, generally, is a problem. This, specifically, when everything in my system is healthy, is not a problem. It becomes a problem when a trunk link fails. Recovery from such failures is what the Spanning Tree Algorithm is supposed to handle. While my system will recover, it does not do so optimally because it thinks the Sonos wireless links are cheaper than the Eero wireless links. This is only because they measure costs differently. I suppose, with other network topologies, the consequences of this problem could be much worse.

I don't see a regression problem if this were made a non-default choice. I would choose to make it while others would retain their default, existing, implementation.

Having gone through a lot of trouble to wire my house, I bristle at advice not to use it. Wired is much better than wireless.
ratty
The regression danger I mentioned was to the overall stability of the software and the performance of the system, which has been tweaked and optimised over the years. The selection of which wireless topology to use can be finely judged when there are multiple possibilities -- for example the choice between single- and multi-hop for a root path where signal strengths are borderline.

I really can't see Sonos finding any business case for performing major surgery in that part of the code, in order to cater for what is bound to be a tiny minority of the customer base.

If you're that concerned about wired Sonos units bridging your Eero mesh trunks in a fail-over situation, then disable their radios. Although not officially supported the technique is evidently frequently used by installers. Google for the instructions. In your case you could leave just one such radio enabled, to provide a connection for the sole wireless unit.
Airgetlam
And it looks like fairly soon (based on the coverage of the new Amp on The Verge), Sonos will actually allow you the option of disabling the radios.
Bruce
R
Userlevel 2
Badge
> regression, stability, excuses, excuses, ...
Sonos does not live in a vacuum. Sonos should play well with others or others will just play without them. Others have been playing by different Spanning Tree rules for longer than Sonos has been in business. I don't know why Sonos thinks that it can write the rules and expect its users to stand still against the tide of general purpose (and conflicting!) wifi mesh systems. Sonos will do us and itself a favor by keeping up with industry standards. It doesn't matter what Sonos does in its own cloud but at the edges it has to talk Spanning Tree. It would be best if it used the same dialect that others do -- if not by default then by user choice. At least give us the choice. I am tired of working around Sonos problems. This is a Sonos problem and Sonos should fix it.
ratty
I'm sure that if Sonos thought there was an issue which affected their business in any significant way they'd have 'fixed' it long ago.
R
Userlevel 2
Badge
I don't disagree and I don't mean to take this out on you. Workarounds are a great thing to know to temporarily work around a problem. Thank you.

That does not excuse Sonos from fixing a problem that I (and the whole network industry) have had with their system for as long as I have had it (eight years) and longer. Like you, however, I am not surprised Sonos ignores it as I have seen them ignore many things. I continue to shake my head.

You should not need to be a network engineer, or employ one, to set up a wireless network with a wired backhaul.

https://www.google.com/search?q=wired+backhaul
Terms & ConditionsCookie settings