I started working for a home theater / home automation installation company a few months ago and we install a lot of Sonos. Sonos is a pretty solid product but, we still run into some strange network issues every once in a while. I was originally told that Sonos creates it's own wireless mesh that it uses to communicate from device to device. Now my background is in networking and I am from the school of thought that anytime you can hard wire a device instead of using WiFi you do it, to reserve the limited airspace for your mobile devices, that are not practical to have hard wired. The standard practice when setting up these sonos systems has been to usually have all of the Sonos Connects and or Connect Amps all centrally located in a network rack and distribute speaker wire to each room, usually using a set of in-wall or in-ceiling speakers. Now having several Sonos all wired to the network as well as creating their own wireless network is concerning due to the potential for a switch loop. I also was told that Sonos has it's own version of Spanning-tree protocol which in theory should prevent a switch loop, however, has been known to wreak havoc on some networks.
So I have been doing my own research to find out why we occasionally experience strange anomalies on the network and based on the information I have seen on the difference between a Standard Setup and a Boost setup it almost seems like it is best to have one and only one Sonos device connected via a wired connection. If you connect several Sonos via wired do they all then attempt to become the Booster, and create their own wireless Broadcast?
Question
BOOST Mode - Can you connect more then one wired Sonos device?
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.
First of all, there is chapter and verse on Sonos' use of STP here. Note the cautionary comments about mixing Sonos' STP with a backbone running RSTP.
Loops can be avoided by wiring just one Sonos unit to the network but, as you say, if you can wire more it's generally better to do so to mitigate the wireless dependency. Most network kit should deal with STP okay, provided it's enabled in managed devices. There's always the option -- unsupported officially -- of disabling the radio in selected Sonos units.
As for "they all then attempt to become the Booster, and create their own wireless Broadcast" there could be some misunderstanding. All Sonos devices will bridge the wired and wireless (SonosNet) segments. Equally all will act as wireless relays to extend the mesh. 'BOOST' is just a catchy model name.
There can of course be only one Spanning Tree root bridge. Unless a switch or router claims preference this is usually a wired Sonos device. If multiple Sonos devices are wired it's generally immaterial which is root.
Loops can be avoided by wiring just one Sonos unit to the network but, as you say, if you can wire more it's generally better to do so to mitigate the wireless dependency. Most network kit should deal with STP okay, provided it's enabled in managed devices. There's always the option -- unsupported officially -- of disabling the radio in selected Sonos units.
As for "they all then attempt to become the Booster, and create their own wireless Broadcast" there could be some misunderstanding. All Sonos devices will bridge the wired and wireless (SonosNet) segments. Equally all will act as wireless relays to extend the mesh. 'BOOST' is just a catchy model name.
There can of course be only one Spanning Tree root bridge. Unless a switch or router claims preference this is usually a wired Sonos device. If multiple Sonos devices are wired it's generally immaterial which is root.
Yes, I am aware of the ability to turn off the wireless radio in Sonos devices. That is usually what I do if there seems to be some network issues with Sonos. Sometimes it helps, sometimes not. It seems we have had issues with play bars where it didn't matter if you turned it off or not it would still be able to connect or like they would re-enable themselves. I wonder if they loose power and reboot if they detect the wired connection and so boot into boost mode and re enable the wireless radio. You bring up an interesting point about the root bridge though, I wonder if since they are all wired they aren't all trying to be the root bridge using the same default priority. I will have to test that out next time by making sure that I have a managed switch on the network and manually making sure that switch is the STP root bridge.
Disabling the radio(s) with PLAYBAR raises other issues, since it would no longer be able to talk to its bonded satellites over the dedicated 5GHz.
I wonder if they loose power and reboot if they detect the wired connection and so boot into boost mode and re enable the wireless radio.
Not if you use the 'persist' option. Since Sonos may not be too happy, I won't post the URLs. Google is your friend.
You bring up an interesting point about the root bridge though, I wonder if since they are all wired they aren't all trying to be the root bridge using the same default priority.
Even if two wired nodes have the same priority they can't have the same bridge ID, since their MACs differ. The bridge IDs are what drives the root bridge selection.
Time was when the 'FirstZP' flag -- denoting the first unit to be added to the system -- was all that governed the bridge priority. This caused problems if a user shuffled the units around, and the root ended up as some wireless node in a poor location.
Today the system is smarter. In general a wired node will always have a better (i.e. lower) bridge priority than wireless. Also a wired BOOST/BRIDGE is preferred over a wired player. The 'FirstZP' flag can still be used, but it tends not to be the dominant factor. The 'Priority' flag does however force the bridge priority, to 0x7000.
So should there only be one Sonos that has the ZP designation? I have noticed that the ZP tag would come and go on certain Sonos as viewed from the router. The network map would sometimes only show a single SonosZP or maybe a couple without the ZP. On one particular system there are 6 Sonons Connects and a Playbar and they are all currently showing their name as SonosZP
On the whole I'd say you are over-thinking some of this. Sonos units don't battle to be the root bridge. I'd say the general position is:
1. For larger systems it is good to wire at least one Sonos component, to trigger SonosNet
2. Wiring other components is generally best, and rarely causes a problem. Most modern routers, with STP enabled, will cope fine.
3. Sonos will happily sort out which component should be the SonosNet root bridge and should be left to do so.
4. If you do have problems with network storms in a particular set up, there will usually be something you can change in router/switch STP settings to cure it. Or go back to one wired device, which will work perfectly in most cases anyway.
But I'll defer to @ratty on all that.
John B summarises things well. Sonos should sort itself out in all but the most pathological of cases.
The network name has zero bearing on, well, anything really. Players will try and announce as 'SonosZP', bridges as 'SonosZB'. Ignore it.
The 'FirstZP' and 'Priority' flags relate to spanning tree tweaks found at http://x.x.x.x:1400/advconfig.htm. Before poking around in there you should know what you're doing.
The network name has zero bearing on, well, anything really. Players will try and announce as 'SonosZP', bridges as 'SonosZB'. Ignore it.
The 'FirstZP' and 'Priority' flags relate to spanning tree tweaks found at http://x.x.x.x:1400/advconfig.htm. Before poking around in there you should know what you're doing.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.