Sonos and the Spanning Tree Protocol

[Todd - Sonos]

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

[Avee]

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.

[rougu]

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/Spannin..._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.

[Avee]

Found this in another thread:

Originally Posted by Andy Urtu

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

[richdunlop]

Originally Posted by rougu

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.

Originally Posted by rougu

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.

[Memphix]

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:

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.

[sylvainp]

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 ?

[Support - Sonos]

I've actually taken some notes on the GS108T (although my notes are for the -200)

While it shouldn't necessarily require the RSTP step, it does seem to require the IGMP Snooping set to enabled.
STP
Basic
STP Configuration
Spanning Tree State: Disable
STP Operation Mode: RSTP
BPDU: Enable
Multicast
IGMP Snooping
IGMP Snooping Configuration
IGMP Snooping Status: Enabled

Let me know

[gerrad.ferrier]

Hi there,

We have had a lot of problems on many of our client sites recently.
The key to fixing these has been to set all of our managed switches with a low bridge priority.
set them to:
- switch one: 4096
- switch two: 8192
- switch three: 12288
- etc. incrementing in multiples of 4096

This will ensure that the Sonos is not the root bridge.

Mr Sonos,
Could you please set your default bridge priority to something really high?
Because Sonos MAC addresses start with 00:0E they are pretty much always the lowest MAC and will win the BRIDGE PRIORITY BATTLE by default which will lead to issues in the network because the switches will do what the Sonos tells them.

Also do we need to have IGMP snooping running for best Sonos performance? will this help to contain the multicast traffic to sonos only devices?

Is there some online training that your dealers can do that will teach us about the advanced aspects of Sonos network best practice?

Thanks.

Gerard.

[ratty]

Originally Posted by gerrad.ferrier

Could you please set your default bridge priority to something really high?

FYI the bridge priority is set at 0x9000 (36864) for all Sonos players/bridges except for the first unit to be registered, which has a priority of 0x8000 (32768).

Also do we need to have IGMP snooping running for best Sonos performance? will this help to contain the multicast traffic to sonos only devices?

I seem to recall that people had problems when IGMP snooping was enabled, as SSDP traffic wasn't being forwarded correctly.