I wanted to post a few clarifications regarding SONOS and Spanning Tree Protocol that have been raised in this thread.
SONOS ZonePlayers use 802.1D Spanning Tree (STP) for loop prevention between wired ZonePlayers and the wireless SonosNet Mesh Network. The Spanning Tree running on ZonePlayers is compliant with IEEE 802.1D and can inter-operate with other IEEE 802.1D and IEEE 802.1w compliant devices. Note: IEEE 802.1w is an updated version of the Spanning Tree protocol called Rapid Spanning Tree. The two types of STP protocols are compatible and 802.1w should revert to inter-operate with 802.1D devices (such as Sonos). Therefore, 802.1w Ethernet switches will work with Sonos ZonePlayers.
SONOS ZonePlayers CAN be connected to Ethernet switches that do NOT support Spanning Tree as long as the Ethernet switches do not interfere with the STP BPDU packets transmitted between ZonePlayers. This is typically never the case and these switches pass the BPDU packets like any other packet.
If the Ethernet switches that Sonos ZonePlayers are wired to DOES support Spanning Tree, the Spanning Tree on those switches must be configured properly. Ethernet switches that support Spanning Tree typically have their STP settings disabled. This also typically means that these switches will block/discard the BPDUs coming from the ZonePlayers. When the ZonePlayers are not able to see BPDUs, they cannot detect there is a shared transmission medium between the Zones and this will typically result in loops in the network. The solution to allow the use of these switches with Sonos is to enable and configure the Spanning Tree on the Ethernet switches. The configuration settings on each switch are different and the appropriate documentation for those products should be consulted. Note: Some switches have a setting that is called Pass BPDUs or equivalent. This setting when present allows the BPDUs between the ZonePlayers to pass freely through the switch without actually enabling STP on the the switch. Typically, setting this function also works, but again please review the switches product documentation.
A good guideline for Ethernet switches is if the switch says it supports Spanning Tree, either 802.1D or 802.1w, then its configuration settings and user documentation should be examined before wiring multiple ZonePlayers to the switch. If the switch does not state it supports Spanning Tree, 802.1D, or 802.1w, it will probably work fine with Sonos.
SONOS ZonePlayers do NOT require a connection to the same Ethernet switch. Different ZonePlayers can be connected to different Ethernet switches which are in turn connected to each other. The only requirement is that Sonos ZonePlayers must be able to actively participate in 802.1D Spanning Tree and not have BPDU transmission blocked between them. There is no Sonos limitation that prevents wiring multiple ZonePlayers to multiple Ethernet switches.
IEEE 802.1D has a recommended bridge span limitation of 7 bridges. This means that the total number of connected bridges from one end of the network to the other should not exceed 7 bridges. This typically only comes into play when daisy chaining Sonos ZonePlayers together by wiring one ZonePlayer to the next. In this case, the guidelines is when daisy chaining ZonePlayers, do not exceed 7 ZonePlayers wired together. If wiring multiple ZonePlayer to a single Ethernet switch, typically the number of spans will only be 3 or 4 (I.e. much less than 7). Except in the daisy-chain configuration, this limit of 7 bridges/7 ZonePlayers, is rarely ever hit.
A number of comments have used the term router and switch interchangeably in regards to this topic. Sonos ZonePlayers in the same HouseHold MUST be connected to the same routed network. A Spanning Tree cannot span two or more routed networks. In addition all Sonos ZonePlayers and Controllers must be on the same routed IP network in order to properly communicate and function. Typically, two or more routed networks are not seen in the household environment except by accident (Example. A carrier provides a new router in a network that already had a router and the original router was not removed).
Hopefully this information has clarified a number of items and not added additional confusion.
Regards, Todd
Page 1 / 3
Hi,
for everyone running a network with multiple STP-capable core switches, e. g. HP Procurve, it might be interesting to know, that Sonos has not implemented path costs of links according to the current standard 802.1t, but still uses 802.1D.
Current switches use path costs of 200,000 for an 100B-T interfaces, whereas Sonos still uses 10 (for a full-duplex 100B-T)
http://en.wikipedia.org/wiki/Spanning_tree_protocol#Data_rate_and_STP_path_cost
Everyone affected will have Sonos zone players use a Sonos wireless cascade to the elected root switch, even if the core switches have a Gigabit-Link (at current 802.1t path costs of 20,000)! This leads to a cascaded load over possibly weak wireless links.
Workaround:
Manually configure trunk connections between core switches at path cost 10. If done so, the Sonos zoneplayers will use the nearest wired connection!
Wish list:
Sonos is encouraged to use the current standard 802.1t for path cost to avoid problems with switch trunks in current standard configurations.
for everyone running a network with multiple STP-capable core switches, e. g. HP Procurve, it might be interesting to know, that Sonos has not implemented path costs of links according to the current standard 802.1t, but still uses 802.1D.
Current switches use path costs of 200,000 for an 100B-T interfaces, whereas Sonos still uses 10 (for a full-duplex 100B-T)
http://en.wikipedia.org/wiki/Spanning_tree_protocol#Data_rate_and_STP_path_cost
Everyone affected will have Sonos zone players use a Sonos wireless cascade to the elected root switch, even if the core switches have a Gigabit-Link (at current 802.1t path costs of 20,000)! This leads to a cascaded load over possibly weak wireless links.
Workaround:
Manually configure trunk connections between core switches at path cost 10. If done so, the Sonos zoneplayers will use the nearest wired connection!
Wish list:
Sonos is encouraged to use the current standard 802.1t for path cost to avoid problems with switch trunks in current standard configurations.
so on my 5 devices
3 will be only ethernet
1 will be ethernet and wireless
1 will be wireless only
Is that correct ?
This is correct.
And I fixed it because your Sonos players are not connecting to your ORANGE WiFi. They are connecting to each other directly.
One really great feature that Sonos could add to the product is an advanced mode where the installer/user can specify which network interface each player is going to use, and that setting would override any automatic interface algorithm and would override any route based on path cost, and also disable any STP negotiation. Sometimes the "smart" part of the product may not be as "smart" as you'd like it to be, and the human knows better.
Sorry for resurrecting an old thread, but these ancient path costs used by Sonos has resulted in me having to disable WiFi on the new CONNECT I just added to my system (like I've had to do on other Sonos units). Without doing so, the Sonos desperately wants to use the crappy wireless link (minimum 60% duty cycle on all 2.4Ghz channels due to urban density) to the nearest neighbor instead of the wired Ethernet available to it. And since my topology is root switch distribution switch Sonos, it's not a simple matter to fudge the port cost on the distribution switch, since the cost of the link from root to distribution still dwarfs the cost Sonos applies to the wireless interference. (Sonos is showing 802.1W costs received from its wired neighbor (which does RSPT) and not even trying to scale that down to 802.1D much less the ancient 802.1D values it is using.)
Basically, I have one wired Sonos device with WiFi enabled to feed the one wireless PLAY:3 unit I have and then the rest of the wired devices I've had to disable WiFi because of the broken STP costs. The current STP costs are used by pretty much all switches at this point, and have been for years. Sonos really needs to get with the times on this one. And it won't cause backwards compatibility issues, since the modern costs are higher than the ancient STP costs Sonos uses. And since Sonos requires all devices to be on the same firmware level, they'd calculate equally as they do today, even if you had a really old wired switch topology in between them using the lower costs.
Basically, I have one wired Sonos device with WiFi enabled to feed the one wireless PLAY:3 unit I have and then the rest of the wired devices I've had to disable WiFi because of the broken STP costs. The current STP costs are used by pretty much all switches at this point, and have been for years. Sonos really needs to get with the times on this one. And it won't cause backwards compatibility issues, since the modern costs are higher than the ancient STP costs Sonos uses. And since Sonos requires all devices to be on the same firmware level, they'd calculate equally as they do today, even if you had a really old wired switch topology in between them using the lower costs.
I never touch the STP on my switch in the living room. Maybe a litltle tweak in the RSTP could help.
Here my config.
PC ROOM
Netgear WRND3700 Router
Netgear ReadyNAS Pro Business (NAS)
A direct CAT6E (50 feet) cable go directly in port 1 of the GS108T switch in the living room.
Switch
Port 1 : Ethernet cable
Port 2: Sonos ZP90
Port 3: Netgear EVA9150 (MM player for HD)
Port 4: Xbox 360
Port 5: Blu-Ray
Port 6: HD TV
Here my settings for the RSTP
Bridge Priority: 32768 (default)
Bridge Max age: 20 (default)
Bridge hello time: 2 (default)
Bridge forward delay: 15 (default)
Port configuration
Port 1 (Direct ethernet cable)
Path cost : 1
Priority : 0
Edge : Yes
P2P Force: Yes
State: Forward
Port 2 (Sonos ZP90)
Path cost : 10
Priority : 128
Edge : No
P2P Force: Yes
State : Forward
Port 3 (EVA 9150 multimedia player)
Path cost : 3
Priority : 16
Edge : No
P2P Force: Yes
Port 4 (Xbox 360)
Path cost : 5
Priority : 32
Edge : No
P2P Force: Yes
Port 5 (BD player)
Path cost : 64
Priority : 160
Edge : No
P2P Force: Yes
Port 6 (HD TV)
Path cost : 64
Priority : 160
Edge : No
P2P Force: Yes
Is this configuration OK for the STP ?
Here my config.
PC ROOM
Netgear WRND3700 Router
Netgear ReadyNAS Pro Business (NAS)
A direct CAT6E (50 feet) cable go directly in port 1 of the GS108T switch in the living room.
Switch
Port 1 : Ethernet cable
Port 2: Sonos ZP90
Port 3: Netgear EVA9150 (MM player for HD)
Port 4: Xbox 360
Port 5: Blu-Ray
Port 6: HD TV
Here my settings for the RSTP
Bridge Priority: 32768 (default)
Bridge Max age: 20 (default)
Bridge hello time: 2 (default)
Bridge forward delay: 15 (default)
Port configuration
Port 1 (Direct ethernet cable)
Path cost : 1
Priority : 0
Edge : Yes
P2P Force: Yes
State: Forward
Port 2 (Sonos ZP90)
Path cost : 10
Priority : 128
Edge : No
P2P Force: Yes
State : Forward
Port 3 (EVA 9150 multimedia player)
Path cost : 3
Priority : 16
Edge : No
P2P Force: Yes
Port 4 (Xbox 360)
Path cost : 5
Priority : 32
Edge : No
P2P Force: Yes
Port 5 (BD player)
Path cost : 64
Priority : 160
Edge : No
P2P Force: Yes
Port 6 (HD TV)
Path cost : 64
Priority : 160
Edge : No
P2P Force: Yes
Is this configuration OK for the STP ?
I have not experienced any issues with the EG008W.
Hi,
I'm trying to confirm if my wired network could be compatible with this STP issue.
I'm wondering about installing this switch (Linksys EG008W). But according to its specifications there is no metion about the specific protocol you mentioned.
Its datasheet says:
Key Features
8 RJ-45 10/100/1000Mbps auto-sensing half/full duplex switched ports
All ports suppport auto MDI/MDI-X cable detection
Fully compliant with IEEE 802.3, 802.3u, 802.3x, 802.3ab
Non head-of-line blocking architecture
Full-duplex IEEE 802.3x flow control and half-duplex backpressure with intelligent port-based congestion detection and broadcast rate control
This IEEE compliant is compatible with sonos STP requirements?
Thanks
I'm trying to confirm if my wired network could be compatible with this STP issue.
I'm wondering about installing this switch (Linksys EG008W). But according to its specifications there is no metion about the specific protocol you mentioned.
Its datasheet says:
Key Features
8 RJ-45 10/100/1000Mbps auto-sensing half/full duplex switched ports
All ports suppport auto MDI/MDI-X cable detection
Fully compliant with IEEE 802.3, 802.3u, 802.3x, 802.3ab
Non head-of-line blocking architecture
Full-duplex IEEE 802.3x flow control and half-duplex backpressure with intelligent port-based congestion detection and broadcast rate control
This IEEE compliant is compatible with sonos STP requirements?
Thanks
Rougu,
Please don't take this the wrong way, I am still waiting for clarification, but this statement I feel does not provide the full requirements:
By trunk connections, do you mean between cascaded switches and/or link aggregation?
On the Cisco switches I am configuring the port that connects to the next switch is not configurable, it defaults to a path cost of 0.
I think the post is lacking the statement that each port on the switch that is wired to a Sonos ZP also needs a path cost of 150 or less to avoid the SonosNet connecting to a near by ZP as well as the wired connection. Is this correct? If so, please include in your post, would be helpful for the novices :)
Thanks.
Please don't take this the wrong way, I am still waiting for clarification, but this statement I feel does not provide the full requirements:
Workaround:
Manually configure trunk connections between core switches at path cost 10. If done so, the Sonos zoneplayers will use the nearest wired connection!
By trunk connections, do you mean between cascaded switches and/or link aggregation?
On the Cisco switches I am configuring the port that connects to the next switch is not configurable, it defaults to a path cost of 0.
I think the post is lacking the statement that each port on the switch that is wired to a Sonos ZP also needs a path cost of 150 or less to avoid the SonosNet connecting to a near by ZP as well as the wired connection. Is this correct? If so, please include in your post, would be helpful for the novices :)
Thanks.
I copied this out of another thread, since it contains some really useful information on how to set up your switches for Sonos to work correctly on a switched network.
More information on spanning tree protocol:
http://en.wikipedia.org/wiki/Spanning_tree_protocol
If you don't understand what this all says, and you have problems with Sonos on a network with switches: Call support, they are there to help you.
More information on spanning tree protocol:
http://en.wikipedia.org/wiki/Spanning_tree_protocol
If you don't understand what this all says, and you have problems with Sonos on a network with switches: Call support, they are there to help you.
Found this in another thread:
I called Sons support today. I had purchased a new ZoneBridge to help coverage in my house.
I set the ZoneBridge as the wired main hub. As I added th ZP back one by one, all was great except for one ZP80. The network kept setting the ZP80 as the rootbridge, which negated the new Bridge.
The procedure Sonos walked me through:
1. HTTP to the rootbridge you want to remove and root. http://#.#.#.#:1400/advconfig.htm
2. Set the "FirstZP:" field to disabled
Click SUBMIT
3 Now HTTP to the Zone Player you want to be Root. http://#.#.#.#:1400/advconfig.htm
4. 2. Set the "FirstZP:" field to enabled
Click SUBMIT
5. Also be sure to reboot both of the units after they have been been properly configured using the power cable, or by attaching /reboot to the ZP url.
If you ever see more than one 'Root Bridge' in the network matrix, be sure to turn one of the zones root bridge setting off. Also be sure to reboot both of the units after they have been been properly configured using the power cable, or by attaching /reboot to the zp url.
I did it in about 2 minutes and it worked perfectly. Now all my Tunnels are Green
I set the ZoneBridge as the wired main hub. As I added th ZP back one by one, all was great except for one ZP80. The network kept setting the ZP80 as the rootbridge, which negated the new Bridge.
The procedure Sonos walked me through:
1. HTTP to the rootbridge you want to remove and root. http://#.#.#.#:1400/advconfig.htm
2. Set the "FirstZP:" field to disabled
Click SUBMIT
3 Now HTTP to the Zone Player you want to be Root. http://#.#.#.#:1400/advconfig.htm
4. 2. Set the "FirstZP:" field to enabled
Click SUBMIT
5. Also be sure to reboot both of the units after they have been been properly configured using the power cable, or by attaching /reboot to the ZP url.
If you ever see more than one 'Root Bridge' in the network matrix, be sure to turn one of the zones root bridge setting off. Also be sure to reboot both of the units after they have been been properly configured using the power cable, or by attaching /reboot to the zp url.
I did it in about 2 minutes and it worked perfectly. Now all my Tunnels are Green
Workaround:
Manually configure trunk connections between core switches at path cost 10. If done so, the Sonos zoneplayers will use the nearest wired connection!
+1 for the workaround. Linksys (Cisco) SLM2008 switches also appear to use 802.1t for path costs. Manually setting 802.1d path costs results in the network using wired links in preference to wireless. Also had to lower the bridge priority (to 0) on one of the switches to ensure that my Zone Players weren't being elected root bridge.
Wish list:
Sonos is encouraged to use the current standard 802.1t for path cost to avoid problems with switch trunks in current standard configurations.
+1 for the wish list although I'd propose that Sonos make this configurable.
I have described my zones in a post above to Mike V.
I have 5 zones :
4 on ethernet
1 on wifi with no possibility to put it on ethernet.
If I disable the wifi on the 4 players connected to ethernet the last one will not be able to get the home wifi ?
I have 5 zones :
4 on ethernet
1 on wifi with no possibility to put it on ethernet.
If I disable the wifi on the 4 players connected to ethernet the last one will not be able to get the home wifi ?
No, you misunderstood my original response then. You disable WiFi on all but one of the wired nodes. Use the network matrix in :1400/support/review to determine which wired node has the strongest wireless signal to the one wireless node Leave WiFi enabled on that device and disable it on all the other wired devices.
ok but if I want to let the wifi on only one I need to do it on the one not ethernet connected
I have just commissioned a Ubiquiti UniFi UC-CK Hybrid Cloud Key Controller and the first of several UAP-AC-PRO wireless access points. Very impressed, love the Controller software's visibility into my WLAN status, and would aspire to migrate towards a 100% Ubiquiti network solution. That means adding a Gateway (USG or USG-PRO-4) and a Switch. In my case, a US-24-250W model would be good enough. Its PoE+ would provide power for the UAPs, the Cloud Key Controller, and a possible future IP camera. Fans are apparently quite noisy, what say you metamatt?
But like metamatt, I realise that my extensive Sonos (8 zones now, with another unboxed PLAY:1 to add later) is likely to encounter STP issues. For now I have a new Cisco RV325 Router and an SG110-16HP Switch to wire in. Don't anticipate any STP issues arising, as all the wired Sonos ZPs and SUBs will be on the Router's integral "dumb" switch ports. Sonso Support say this will be fine. However I will be monitoring this thread with interest to see if a UniFi workaround emerges!
Might ask Ubiquiti Support exactly what the CLI tweak does. If it simply turns off active STP and enables BPDU flooding instead, I am advised by my friend that this should be OK. The tweak means getting into the switch using ssh, or Secure Socket Shell, a Unix-based command line technique. Not for the faint-hearted I suspect!
But like metamatt, I realise that my extensive Sonos (8 zones now, with another unboxed PLAY:1 to add later) is likely to encounter STP issues. For now I have a new Cisco RV325 Router and an SG110-16HP Switch to wire in. Don't anticipate any STP issues arising, as all the wired Sonos ZPs and SUBs will be on the Router's integral "dumb" switch ports. Sonso Support say this will be fine. However I will be monitoring this thread with interest to see if a UniFi workaround emerges!
Might ask Ubiquiti Support exactly what the CLI tweak does. If it simply turns off active STP and enables BPDU flooding instead, I am advised by my friend that this should be OK. The tweak means getting into the switch using ssh, or Secure Socket Shell, a Unix-based command line technique. Not for the faint-hearted I suspect!
No, you need ONE Sonos device with both Ethernet and WiFi enabled. The WiFi-only device, of course, needs WiFi enabled. All the other Ethernet-connected devices need WiFi disabled.
ok I get it
so on my 5 devices
3 will be only ethernet
1 will be ethernet and wifi
1 will be wifi only
Is that correct ?
so on my 5 devices
3 will be only ethernet
1 will be ethernet and wifi
1 will be wifi only
Is that correct ?
The confusion here is using the term "WiFi" when it really should be "wireless"... SonosNet wireless is not WiFi.
Your Play:1 is not connected to your ORANGE WiFi. It's connected to one of your wired Sonos players. If you disable wireless on all of your wired zones, then the Play:1 is out there on its own. Because you have Sonos zones that are wired to your network, the one wireless zone cannot connect to your ORANGE WiFi network. It will need to connect to another Sonos player. This is why you leave one wired Sonos player with its wireless connection enabled.
The confusion here is using the term "WiFi" when it really should be "wireless"... SonosNet wireless is not WiFi.
Your Play:1 is not connected to your ORANGE WiFi. It's connected to one of your wired Sonos players. If you disable wireless on all of your wired zones, then the Play:1 is out there on its own. Because you have Sonos zones that are wired to your network, the one wireless zone cannot connect to your ORANGE WiFi network. It will need to connect to another Sonos player. This is why you leave one wired Sonos player with its wireless connection enabled.
gotcha !
so it is not possibile to have only one Sonos player with no ethernet connexion available?
Great news It has solved my problem.
The Matrix was very help full and I was lucky that the 2 players connected on the sonosnet wifi are close.
The Matrix is all green !!!
Love from PARIS to all of you !
The Matrix was very help full and I was lucky that the 2 players connected on the sonosnet wifi are close.
The Matrix is all green !!!
Love from PARIS to all of you !
I have a Playbar (with sub & surrounds) and a Connect. Attaching the Playbar and the Connect to a Linksys GS308 (unmanaged) switch results in STP flapping, leading to audio stutter every couple of minutes. At these times I see (via /status/dmesg) the Connect flips between blocking and forwarding on ath0 (its wireless interface) whilst the playbar reports TCNs on both ath0 and eth0.
So the switch is not blocking STP BPDUs. And they show up in tcpdump off another port - in particular I can see both the Playbar and the Connect taking turns to spit topology change notifications at each other. It's not a pretty sight.
Disabling wireless on the Connect solves the problem, eliminates stutter, and leaves the Playbar as the root bridge.
So the switch is not blocking STP BPDUs. And they show up in tcpdump off another port - in particular I can see both the Playbar and the Connect taking turns to spit topology change notifications at each other. It's not a pretty sight.
Disabling wireless on the Connect solves the problem, eliminates stutter, and leaves the Playbar as the root bridge.
A bad connection could account for the unstable topology. The wired CONNECT should never use anything but the switch as its root path. I would run continuous ping tests to PLAYBAR and CONNECT, and look for packet loss and/or excessive times.
A bad connection could account for the unstable topology. The wired CONNECT should never use anything but the switch as its root path. I would run continuous ping tests to PLAYBAR and CONNECT, and look for packet loss and/or excessive times.
The wiring and switch are fast and stable. Ping floods, large file transfers, streaming 4K video, all no problem. Zero packetloss and low latency even on a long-running ping -f -s 1500.
This workaround is fine, just unsupported.
I am suspicious of Sonos's layer 2 behaviours, but I don't have the time to debug their STP interactions.
I had serious instability problems using a TP-Link switch ( TL-SL3428). What seem to have brought some stability is to increase the Max Learned MAC for the port(s) that have a wired LAN connection to the switch. In the switch web page go to 'switching' -> Port, Port Security tab and increase the max count. I found error messages in the log file indicating that the max no of mac entries was reached in the table for the port connected to the sonos.
If you have a wireless node ( I have a apple time capsule that I use the wireless node from) , increase the max for the port connected to that too.
I wish Sonos would spend a bit more time in qualifying a few major network switch vendors with their STP function and summarise STP config info in a decent white paper.
If you have a wireless node ( I have a apple time capsule that I use the wireless node from) , increase the max for the port connected to that too.
I wish Sonos would spend a bit more time in qualifying a few major network switch vendors with their STP function and summarise STP config info in a decent white paper.
Hi Ratty. Sorry for delayed reply, I didn't receive email notifications of replies.
Anyway, yes it's a ZP120 but I swapped this around for a Connect:Amp and after support altered the STP settings the unit dropped off the network. Only this one dropped off, no others. So both a ZP120 and a Connect:Amp dropped off in the same location so likely interference but baffling as to why the Beam, which is only around 10ft away has no problems. Must be very localised but I can't think of what it would be. The affected unit is under a kitchen unit behind the wooden plinth. Nothing else there and this has been it's location for nearly 10 years. Very odd.
Support certainly caused me huge headaches by fiddling with the switch settings. They were convinced it was related to STP.
Anyway, yes it's a ZP120 but I swapped this around for a Connect:Amp and after support altered the STP settings the unit dropped off the network. Only this one dropped off, no others. So both a ZP120 and a Connect:Amp dropped off in the same location so likely interference but baffling as to why the Beam, which is only around 10ft away has no problems. Must be very localised but I can't think of what it would be. The affected unit is under a kitchen unit behind the wooden plinth. Nothing else there and this has been it's location for nearly 10 years. Very odd.
Support certainly caused me huge headaches by fiddling with the switch settings. They were convinced it was related to STP.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.