Option to select Sonos node as Spanning Tree root bridge

  • 9 February 2010
  • 64 replies
  • 22563 views

As the title suggests, it would be useful to be able to explicitly select which Sonos device is elected as 'root bridge'. This would permit the user more control over which 'tunnels' through the wireless mesh the Sonos nodes choose to communicate with one another, with the aim of addressing dropout or network instability problems.

Whilst use of an STP-capable external switch does allow some control over root bridge selection by making *it* the root, even this may not result in the ideal topology of active 'tunnels'. Indeed what constitutes the best topology can sometimes change, for example when relaying uncompressed Line-In sources between adjacent ZonePlayers which would otherwise be at the extremities of the Spanning Tree.

The Sonos system apparently manipulates bridge priorities internally so as to steer root bridge election, thus over-riding the default selection of lowest MAC address. It's understood that the first node to be registered is appointed root and retains that role unless it's removed from the system. Sonos Support can evidently change the selection of root bridge by accessing the system remotely, so this request is in essence for the exposure of that facility to the user. Factory resetting the system and re-registering everything, starting with the desired new 'root', is a painful alternative.

It could be argued that offering this facility strays too far from the "it just works" philosophy, but those with more complex networks may be using managed STP-capable switches and already dealing with such concepts. The option could be presented to the user under 'advanced settings' with a relatively simple rubric regarding its possible effect. Lacking a visible depiction of the resulting Spanning Tree state would mean an element of trial-and-error for the normal user (assuming no access to the diagnostics), but then so does the selection of wireless channels at present.

64 replies

Userlevel 2
Badge
What ratty said

The mesh signal in my house is poor due to the house construction and I have zones at each end. It would suit my setup more if I were able to change these (now I understand it more) to suit my use at that specific time.
Userlevel 2
Again I second this request. If what ratty says about root node selection is true then my setup is already sub-optimal. Networks change (especially as we get more zones ;)) so It would be good to be able to modify these settings without support intervention.
If what ratty says about root node selection is true ...
My assumptions are reinforced by this post from buzz. I've never been able to budge my root bridge selection simply by powering down/up different nodes.

Anyway, whichever way the root is initially appointed, the request to be able to reassign it to a different node still stands.
Userlevel 2
I think you guys have far to much time on your hands.
Badge +1
Based on these discussions I thought I would find out what was the root hub in my network. Interestingly the root hub turns out to be a Netgear Wireless access Point.


(I didn't even know it was running STP)




Just thoughts I'd add my observation.
I think you guys have far to much time on your hands.
What a useless comment. Just like your other contribution to this forum.
Userlevel 2
As the title suggests, it would be useful to be able to explicitly select which Sonos device is elected as 'root bridge'.


Seconded yet again.


It could be argued that offering this facility strays too far from the "it just works" philosophy, but those with more complex networks may be using managed STP-capable switches and already dealing with such concepts.


I think that the number of STP threads in this forum over the years demonstrates that the Sonos doesn't just work for everyone.

As you say, complex networks sometimes require complex solutions. Whilst I can understand the desire to hide baffling options from users who don't and likely never will need them, I don't agree with the policy of not having them available via some circuitous route for those who do.

Using the first registered ZP as the STP root bridge probably works well in a lot of cases, as many users will install their first ZP in a central location. However, a central physical location in the home doesn't necessarily mean a central location on the network.

People and devices aren't static, either. I've moved house since buying my first few ZPs. The one that is elevated to root bridge status is inside the ceiling of my bathroom. I don't even know where it was located in the old house.

I had a quite a few drop-out issues until I realised what my ZPs, all of which are wired, were up to. I expected them to communicate directly across the network, because they were all wired to it, not to elect one of their brethren to be the spokesperson for the rest.

I fixed my woes by making my core switch the STP root bridge, but as you say, it's essentially a Sonos issue and that's where the configuration should be done.

More and more home networks are evolving into quite complex beasts and too much consumer grade hardware fails to take this into account, instead bending over backwards to appear to offer the holy grail of zero configuration.

That's great. I understand the marketing and the support concerns at play here, but users who buy into the system on that basis and then find that their own environment does require some unusual configuration are going to feel very frustrated if they can't perform it and therefore have to live with a suboptimal set-up.
Userlevel 2
My assumptions are reinforced by this post from buzz. I've never been able to budge my root bridge selection simply by powering down/up different nodes.

Anyway, whichever way the root is initially appointed, the request to be able to reassign it to a different node still stands.


I checked my configuration last night and the root node is indeed the first zone I bought and registered, even though it is not central in my configuration now.
Userlevel 2
Not only to much time on your hands, but clearly some of you take yourselves far to seriously
Userlevel 2
clearly some of you take yourselves far to seriously

I can see why you wouldn't make that mistake.
A person who posts nothing but uselees drivel is now telling people they have "far too much time on their hands?"

Next thing you know, he'll call us all "loosers." :rolleyes:

I think that the number of STP threads in this forum over the years demonstrates that the Sonos doesn't just work for everyone.


I'm tempted to agree. When I've raised this in the past I have had mumblings that I may be overstating the importance of STP compatibility in LAN switches used with Sonos. The problem is that STP is not always "plug'n'play" and when it's almost impossible to predict when it will work seamlessly and when it will be a pita. When it doesn't work it's useful to be able to influence it by tweaking priorities.

I've always encouraged people to do this via configuration on the switch.

My main concern with tweaking it on Sonos is that it is a very technical thing, and can easily do more harm than good. The way Sonos handles STP within the mesh is rather unique and is even more complex than standard STP.

People like to tweak and will do so where they are allowed to, even if they don't have a clue what it is they are tweaking or, often, whether it is needed. One of the biggest strengths of Sonos is also often what generates the most criticisms: it does just tend to work. That doesn't satisfy those whose "tweak gland" is overdeveloped.

If there is this capability on Sonos then I don't think hiding it in a menu with a disclaimer is enough to prevent "clueless noobs" from having a play and screwing up their system

As you say, complex networks sometimes require complex solutions. Whilst I can understand the desire to hide baffling options from users who don't and likely never will need them, I don't agree with the policy of not having them available via some circuitous route for those who do.

I'm not against this capability being available for those that know what they are doing, but I'm totally against it being available by any route, circuitous or otherwise, for those that don't (which is probably 99.9% of users) for the reasons I mention above. If it was available it almost needs enabling on a case-by-case basis on production of a suitable qualification or reference (e.g. CCNA or above). Yes this is probably ridiculous, but I struggle to think of a non-ridiculous way to keep this out of the tinkering hands of the vast majority of users who shouldn't be allowed near this capability.

I strongly suspect that the number of support calls generated by people who messed with this setting and broke their network either because they misdiagnosed the problem, or because they thought it may be able to somehow optimise their network, or just because they wondered what it did could outnumber the number of support calls by people who are having problems that would be fixed by making this change.

If this is the case, then it makes more sense even for advanced users to contact support if they need this setting tweaked (assuming Sonos support can actually tweak it for them somehow.

I fixed my woes by making my core switch the STP root bridge, but as you say, it's essentially a Sonos issue and that's where the configuration should be done.

I would argue the other way. The logical place for the root bridge in most networks is the core switch.

More and more home networks are evolving into quite complex beasts and too much consumer grade hardware fails to take this into account, instead bending over backwards to appear to offer the holy grail of zero configuration.

That's great. I understand the marketing and the support concerns at play here, but users who buy into the system on that basis and then find that their own environment does require some unusual configuration are going to feel very frustrated if they can't perform it and therefore have to live with a suboptimal set-up.


I agree, but this is where I think this facility should be available via support, who probably have the experience and diagnostic tools to make sensible choices as to where the change should be made. I would love to know the actual figures, but I suspect that the number of people who are actually having problems with STP is pretty low (maybe 1%). Of those, some sort of simple change to the network can probably fix maybe 80% of the problems. Of the 0.2% still having problems which need specific tweaks to the Sonos STP, maybe 1% are qualified/sensible enough to do this without causing more problems (seriously, this is heavyweight networking stuff, and indiscriminately changing STP priorities on a network of meshed LAN switches is a great way to screw up your network).

The reasons I'm in favour of doing it on the LAN switch are:

1. It easier to do as a single change normally re-roots the whole network

2. The "core" LAN switch is normally the best place for the root bridge to be

3. It's obvious where to change it. Most people only have a small number of LAN switches, and it's normally relatively clear which is the most "core" of them. It's not unknown for people to have a dozen or more Sonos zones and it's absolutely non-obvious to most people (and I include myself, and I have 20 years of carrier networking experience) which zoneplayer to start tweaking.

Cheers,

Keith
I think you guys have far to much time on your hands.

Actually I'm gonna play Devil's Advocate and defend this comment because I think there's a valid point there.

If you refer to my previous post you'll see I'm against giving this capability to any one except the most advanced users. I think in the wrong hands (which is probably 99.99% of users) it could be disasterous.

I think the number of users who are able to diagnose and redesign their network sensibly such that they could use this capability meaningfully is extremely small. I am probably one of those people.

For my own point of view, it would be a waste of my time doing this. I would be far better off calling up support, handing over diagnostics, and getting them to make the required changes. However, I am a techy and I would probably do it "for fun" if I had the time.

And that leads back to the poster's comment: I don't have too much time on my hands, and I can't really afford to spend the time I have messing with this sort of thing unnecessarily. If I did have more time, I probably would. That doesn't make it the right thing to do.

Cheers,

Keith
Thanks Keith for the excellent points.

What's been suggested is simply to exert some control over the dogmatic process by which the Sonos root is assigned to the first-registered node, and stays that way irrespective of the re-arrangement of Sonos boxes, house moves and so on. I can't imagine that offering the option to reassign the "first node registered" status can be any more dangerous to the condition of the mesh than the current state of affairs, which can result in a random location of the root.

The core (or only) switch in a house may be located towards one end of the house, with the most centrally located Sonos node connected wirelessly. For an STP-capable switch to take control and cause active tunnels to fan out from the central node, it would presumably have to be cabled - not always easy - or resort to a deprecated solution such as EoP.
Userlevel 2
Not losers, but some of you are very self important to be so upset by an idle comment made in jest.

I clearly have no place among such exulted company and so shall remove my self, to enjoy my Sonos for the purpose it was made, to play music and not to make me feel better about myself.
"exulted"? I think we've been insulted again, but I'm not sure.
Userlevel 2
No you have not. I would refer you to the OED for clarification.
You may want to consult the OED yourself:

ex·ult (ĭg-zŭlt')
intr.v. ex·ult·ed, ex·ult·ing, ex·ults

To rejoice greatly; be jubilant or triumphant.

Obsolete To leap upward, especially for joy.



ex⋅alt⋅ed  /ɪgˈzɔltɪd/
Pronunciation [ig-zawl-tid]

–adjective
1. raised or elevated, as in rank or character; of high station: an exalted personage.
2. noble or elevated; lofty: an exalted style of writing.
Userlevel 2


The core (or only) switch in a house may be located towards one end of the house, with the most centrally located Sonos node connected wirelessly. For an STP-capable switch to take control and cause active tunnels to fan out from the central node, it would presumably have to be cabled - not always easy - or resort to a deprecated solution such as EoP.


I would like to come back to the origin of this topic and second this option since I am experiencing occasional drop outs.

Network Matrix shows that the root bridge really is the first connected ZP. This explains why the drop outs still occur although I placed a ZB in the center of the apartment - I presume this ZB (which is cabled to my switch) should be the root bridge.

Now I am wondering if should replace my switch for a manageable one. A question for the experts: would it help to have a switch as root bridge with only one ZB cabled and all the others wireless or should all ZPs be wired?

Cheers
esc
Userlevel 2
My system of two ZPs and a CR100 occasionaly has severe dropouts for minutes up to one or two hours. I did not see an improvement after having wired both ZPs. The use of a ZB did not make things better either.

Now I resetted my whole system to factory settings and changed my 'first' ZP. I wired this one. The other one is connected via sonosnet. I suppose the situation is better now...

I think it could be helpful if the user can change the 'root bridge' in a more simple way than resetting the whole system. Up to now you only can change wifi channel, buy a ZB or wire your system. But the latter was not a solution for my situation...
Turbotulpe,

Consider the possibility that you have some transient RF interference.

I suggest that you work with SONOS support. Send a diagnostic while the system is working normally and note the confirmation number, then wait until the system misbehaves and submit a second diagnostic while the system is misbehaving and note the confirmation number. Follow up with an email giving both confirmation numbers. Basic networking issues and RF interference leave clear trails in the diagnostics.
Userlevel 2
I did that even several times... up to now they couldn't help me ... Sometimes there are severe interferences, I Can see them in the diagnostic protocol and they can, too. I also send wifi analysis reports ... But wiring didn't improve my special situation, I do not have network problems like double IP... network loops etc....


I tried everything I myself could influence... Sonos support does not know a solution for me...
Turbotulpe,

If you do not have any loops, how would being able to tinker with STP help?
Userlevel 2
Now, I don't think, it would help. But I excluded loops during my search of the reason for my dropouts. However I think changing the root bridge may influence the stability of sonosnet. I'm afraid that I have no influence on the situation because the interferences may occur from my neighborhood, wifi-networks, radio waves etc.. Unfortunately simply wiring the ZPs is not always an appropriate workaround, because the ZPs remain open for controllers and are therefore susceptible for any form of electromagnetic waves in the 2,4 GHz range... There is no shield against this situation... and the sonos guys cannot solve each situation.

But when listening classical music thats a rather annoying situation...

Sorry for my English...
Network Matrix shows that the root bridge really is the first connected ZP. This explains why the drop outs still occur although I placed a ZB in the center of the apartment - I presume this ZB (which is cabled to my switch) should be the root bridge.
If the root bridge ZP is off to one side of the apartment, then the chances are that the active tunnels are:
1/ from the root ZP to the central ZB
2/ from the root ZP direct to other ZPs which are within range of the root
3/ from the root ZP indirectly via the ZB (or alternatively via a directly connected ZP) to any other ZPs which are out of range of the root

You may be experiencing a flapping of the topology between some non-root ZPs connecting directly to the root (as 2 above) and connecting indirectly (as 3). On the face of it, having the option to make the ZB root would mitigate your dropout problems.

Now I am wondering if should replace my switch for a manageable one. A question for the experts: would it help to have a switch as root bridge with only one ZB cabled and all the others wireless or should all ZPs be wired?
I wouldn't lay claim to expert status. However if you used a managed switch and set its bridge priority correctly, I assume it would assume root status. Since it's wired to the ZB then all wireless connections should fan out from the central node as you desire.

Reply