Hello *,
today I would like to provide and share some information, findings and "heuristics" about working STP settings for my Sonos installation that's cabled for all (20) but one player device (PLAY:5) and two SonosNet wireless extenders (CONNECT) with structured CAT 7 home network cabeling infrastructure.
The Sonos spanning tree is absolutely stable with no STP TCN messages / no topology changes.
Each cabled player is connected to a Cisco SG300-52 managed switch that plays the role of the Root Bridge for the Sonos network. Even while the following params are derived from the SG300-52 settings, they may be adapted to switch hardware of other vendors, too.
My Sonos network works fine without any drop outs, network broadcast storms or configuration issues including a zoo of heterogenous controllers by utilizing the following settings:
Global Settings
Spanning Tree State: Enable
STP Operation State: Classic STP
BPDU Handling: Flooding
Path Cost Default Values: Short
Bridge Settings
Priority: 4096
Hello Time: 2
Max Age: 20
Forward Delay: 15
STP Interface Settings
For each network port with a Sonos player being connected with its 100 Mbit/s port type *or* any other device with a 100 Mbit/s port type connection, the following settings apply:
STP: Enable
Edge Port: Auto
Root Guard: Disable
BPDU Guard: Disable
BPDU Handling: Use Global Settings
Path Cost: User Defined 10
Priority: 128
All other network devices that don't participate in the Sonos player spanning tree *and* are not connected by a 100 Mbit/s port type may be set up like this:
STP: Enable
Edge Port: Auto
Root Guard: Disable
BPDU Guard: Disable
BPDU Handling: Use Global Settings
Path Cost: Use Default
Priority: 128
It's important that the path costs do match for *all* ports with the same network speed for both Sonos players and non Sonos devices that are connected to the managed switches / routers. As the initial IEEE 802.1D-1990 standard maps switch port interface speed to STP path costs with 10 Mbit/s to 100, port speed of 100 Mbit/s to 10 and port speed of 1 Gbit/s to 5, every managed switch port may be "tweaked" manually instead of defining "Use Default" cost settings to map these STP path costs to the corresponding switch port speed respecting the connection speed of every single linked network device.
If you apply the custom STP path cost settings as suggested above, you'll get the following modified path cost table that is based on the default mappings as chosen above with "Use Default" of IEEE 802.1D-1998 that has superseeded the IEEE 802.1D-1990 standard:
4 Mbit/s - 250
10 Mbit/s - 100
16 Mbit/s - 62
100 Mbit/s - 10 - instead of 19 (modified for Sonos STP)
1 Gbit/s - 4
2 Gbit/s - 3
10 Gbit/s - 2
Sonos utilizes the initial IEEE 802.1D-1990 standard as "Classic STP" but unfortunately most managed switches / routers today only do support the IEEE 802.1D-1998 standard as "Classic STP". This is the main reason why the IEEE 802.1D-1998 path cost tables have to be modified to match the older and superseeded IEEE 802.1D-1990 standard where both do only support 16 bit values for path costs.
Just as an observation as I'm not a network engineer in any kind it seems to me that both "STP: Enable" or "STP: Disable" *do* work for all non Sonos ports.
As I can remember of an important warning I've read in a recent technote Cisco doesn't suggest to disable the STP option on single switch ports because "non network experienced people" will probably get into trouble with various flavours of possible and very difficult to diagnose loop and broadcast storm issues quickly!
In another thread "ratty" mentioned to set "STP: Disable" and "Edge Port: Enable" to activate "Fast Forward" for all non Sonos ports but in my personal opinion this doesn't alyways work if there are network devices connected to the switch(es) with more than one physical cabeling connection utilizing port bundling or link aggregation - e.g. a NAS or additional switches are connected via LAG - or if you've set up a switch hierarchy. So at least be careful to set everything outside the Sonos spanning tree to edge ports - e.g. "Edge Port: Enable" that will enable "Fast Forward" on all other network ports.
Also IGMP snooping works fine and has to be enabled with Multicast filtering enabled, too, to lower the overall network load:
Multicast Settings
Bridge Multicast Filtering Status: Enable
VLAN ID: your ID - e.g. 1
Forwarding method for IPv4/v6: MAC Group Address
IGMP Snooping Status: Enable
Make sure that your router provides support for Multicast traffic pass through and has implemented an IGMP querier - e.g. IGMP v2 compatible. You don't have to elect an available IGMP querier by yourself. This will be done by the Multicast handling network devices (router, switches) automatically.
Concerning the Cisco SG300-52 switch hardware it's absolutely essential that you disable (and apply) the "Spanning Tree State" after you've done changes to the "STP Interface Settings" and enable (and apply) "Spanning Tree State" again, or the spanning tree won't be rebuilt and run correctly. Because of this issue I've wasted hours of hassle time to ask myself and the cisco community, why my STP settings didn't work.
Hope that helps starting to get up and running a cabled and error-free playing Sonos network.
Best regards from Germany
Matthias
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.
Matthias,
Thank you so much for posting this. I was banging my head against the wall trying to figure out why my hardwired players would not connect via ethernet. Making the STP tweaks to the Cisco SG200-50P as described below fixed everything.
Also, a big thank you to Azur at Sonos Support for pointing out this post. Yeah, back in business!
Thank you so much for posting this. I was banging my head against the wall trying to figure out why my hardwired players would not connect via ethernet. Making the STP tweaks to the Cisco SG200-50P as described below fixed everything.
Also, a big thank you to Azur at Sonos Support for pointing out this post. Yeah, back in business!
Userlevel 2
Hi,
thank you for posting this. I am currently evaluating how it works out in my network.
I did notice however that as soon as I changed the bridge priority, the switch lost knowledge of which port was the root bridge of the spanning tree, then I also notice that with this setting I was unable to set my intended device as root bridge.
Currently running this configuration and it seems to work fairly well (without a root bridge). I breifly tried to change back the Bridge priority to default value and set a unit as root, but just after about 20 minutes Spotify skipped tracks.
thank you for posting this. I am currently evaluating how it works out in my network.
I did notice however that as soon as I changed the bridge priority, the switch lost knowledge of which port was the root bridge of the spanning tree, then I also notice that with this setting I was unable to set my intended device as root bridge.
Currently running this configuration and it seems to work fairly well (without a root bridge). I breifly tried to change back the Bridge priority to default value and set a unit as root, but just after about 20 minutes Spotify skipped tracks.
Userlevel 2
Hi
You need to change the bridge id value for the switch that you want to have as root bridge so that the default calculations based on mac and the bridge id value ii the reason for what switch in the network becomes the root bridge, (Ok the cost values on the links also have some impact depending on what port it is that gets blocked)
You should have a value for this and by default that should be 32,768 and this is the deafult for all switches so that means that the MAC addr is the thing that decides.
To get around that the MAC addr is the value that decides change the bridge id value to a lower value and you should see that after a while say 5-60 seconds a bit depending on size of network and version of STP that the switch with the lover bridge id value is the root bridge.
And of course the switch that you make root bridge should of course be the one that is acting as core in the network design
HLU
You need to change the bridge id value for the switch that you want to have as root bridge so that the default calculations based on mac and the bridge id value ii the reason for what switch in the network becomes the root bridge, (Ok the cost values on the links also have some impact depending on what port it is that gets blocked)
You should have a value for this and by default that should be 32,768 and this is the deafult for all switches so that means that the MAC addr is the thing that decides.
To get around that the MAC addr is the value that decides change the bridge id value to a lower value and you should see that after a while say 5-60 seconds a bit depending on size of network and version of STP that the switch with the lover bridge id value is the root bridge.
And of course the switch that you make root bridge should of course be the one that is acting as core in the network design
HLU
Userlevel 2
Matthias,
Appreciate the info. I have a similar setup at a project of mine [SG300-28P x 1; SG300-10P x 2; collection of hardwired and wireless sonos units]. I was initially having a problem seeing one of my smaller switches and the devices behind it; tracked it to this STP issue with the Sonos.
I've since implemented most of the items you suggested [changing of STP settings]. I can now see all 3 switches and the devices behind them.
I have a question about the MultiCast settings, however. I see where I can enable it and the choice of a VLAN ID. I have 6 VLANS running on this network. VLAN 1 is my admin VLAN [and the one that my 3 switches sit on]. VLAN 5 has my Sonos units, along with a slew of other devices. Do I enable the MultiCast filtering on VLAN ID 1 or 5? I'm confused.
In addition, I have a question about the snooping settings. When I enable them by selecting the check box, do I also have to select certain VLAN boxes shown below the initial check box [e.g. vlan 1 and 5; just 5; just 1; none?]
Any help would be appreciated. Thanks.
Appreciate the info. I have a similar setup at a project of mine [SG300-28P x 1; SG300-10P x 2; collection of hardwired and wireless sonos units]. I was initially having a problem seeing one of my smaller switches and the devices behind it; tracked it to this STP issue with the Sonos.
I've since implemented most of the items you suggested [changing of STP settings]. I can now see all 3 switches and the devices behind them.
I have a question about the MultiCast settings, however. I see where I can enable it and the choice of a VLAN ID. I have 6 VLANS running on this network. VLAN 1 is my admin VLAN [and the one that my 3 switches sit on]. VLAN 5 has my Sonos units, along with a slew of other devices. Do I enable the MultiCast filtering on VLAN ID 1 or 5? I'm confused.
In addition, I have a question about the snooping settings. When I enable them by selecting the check box, do I also have to select certain VLAN boxes shown below the initial check box [e.g. vlan 1 and 5; just 5; just 1; none?]
Any help would be appreciated. Thanks.
+2
Thank you for the detailed description of how to set up managed switches with SONOS.
This seems to work fine for me as long as all the Sonos hardware is on one switch (i.e., my 2 Play:3's and sub on one switch). However, if I put the sub on my second office switch or plug up my Connect:amp to another switch in another room, the network goes down.
I've configured everything as detailed here with the STP settings. Some settings such as root guard and BDPU guard I don't have. I'm using a Linksys LGS318P in my basement, 3 LGS308P's in my living room/office/master bedroom, an LGS308 as a secondary office switch, and my printer equipment is connected via a Netgear GS105 switch.
I do not have link aggregation enabled (yet, I plan to enable it when the new DiskStation arrives).
Any thoughts?
I've configured everything as detailed here with the STP settings. Some settings such as root guard and BDPU guard I don't have. I'm using a Linksys LGS318P in my basement, 3 LGS308P's in my living room/office/master bedroom, an LGS308 as a secondary office switch, and my printer equipment is connected via a Netgear GS105 switch.
I do not have link aggregation enabled (yet, I plan to enable it when the new DiskStation arrives).
Any thoughts?
This may seem like an odd question, but do all the STP switches need to be connected directly?
Currently, my router's 4 ports have port 1 going to my LGS318P switch in the basement, 2 going to the LGS308P in the living room, 3 going to the LGS308P in my office, and 4 going to the LGS308 in my office.
The Sonos Connect:amp is connected directly to the basement switch, and the 2 Play:3's and sub are connected to the LGS308P in my office.
When I had the 2 Play:3's connected to the LGS308P and the sub connected to the LGS308, I received a network storm.
I'm beginning to wonder if I should try connecting the LGS308P's to the LGS318P switch directly to see if that helps. Will try this tonight or tomorrow. Hopefully it fixes it.
Any thoughts on what else can be done? I've assigned the office switch with the highest number of Sonos speakers connected to it as the lowest priority number (4096) so it's the root bridge and the basement switch with the second highest (3192). I may switch this so the basement is the lowest. Despite setting the office switch as the lowest, it still identifies the basement switch as the root bridge while the basement switch identifies the office switch as the root bridge.
Thanks for any help you can provide!
Currently, my router's 4 ports have port 1 going to my LGS318P switch in the basement, 2 going to the LGS308P in the living room, 3 going to the LGS308P in my office, and 4 going to the LGS308 in my office.
The Sonos Connect:amp is connected directly to the basement switch, and the 2 Play:3's and sub are connected to the LGS308P in my office.
When I had the 2 Play:3's connected to the LGS308P and the sub connected to the LGS308, I received a network storm.
I'm beginning to wonder if I should try connecting the LGS308P's to the LGS318P switch directly to see if that helps. Will try this tonight or tomorrow. Hopefully it fixes it.
Any thoughts on what else can be done? I've assigned the office switch with the highest number of Sonos speakers connected to it as the lowest priority number (4096) so it's the root bridge and the basement switch with the second highest (3192). I may switch this so the basement is the lowest. Despite setting the office switch as the lowest, it still identifies the basement switch as the root bridge while the basement switch identifies the office switch as the root bridge.
Thanks for any help you can provide!
I finally got it working!
I routed ALL traffic through the basement switch. The 2 office switches and living room switches were supplied from the basement switch. (Only the basement switch is connected to the router.)
I set the basement switch priority to 4096, office PoE to 8192, and all others to 32768. The Connect:amp is connected to the basement switch, and the office switch has the 2 Play:3's and sub.
End result is that it's working. All STP-enabled switches must connect to the root switch instead of going through a router. After many, many hours, I finally have it working. Yaaay!
I routed ALL traffic through the basement switch. The 2 office switches and living room switches were supplied from the basement switch. (Only the basement switch is connected to the router.)
I set the basement switch priority to 4096, office PoE to 8192, and all others to 32768. The Connect:amp is connected to the basement switch, and the office switch has the 2 Play:3's and sub.
End result is that it's working. All STP-enabled switches must connect to the root switch instead of going through a router. After many, many hours, I finally have it working. Yaaay!
I routed ALL traffic through the basement switch. The 2 office switches and living room switches were supplied from the basement switch. (Only the basement switch is connected to the router.)
I set the basement switch priority to 4096, office PoE to 8192, and all others to 32768. The Connect:amp is connected to the basement switch, and the office switch has the 2 Play:3's and sub.
End result is that it's working. All STP-enabled switches must connect to the root switch instead of going through a router. After many, many hours, I finally have it working. Yaaay!
I don't think that should matter in theory, but the problem with the router is that it probably isn't STP aware and may be blocking the BDPU packets, rendering your settings moot.
As you figured out, you work around that by isolating all STP devices onto only STP aware device, that way no STP traffic need to flow through your router.
Er, no. The switch with the lowest bridge priority figure (3192) would become root.
That was obviously a typo and he probably meant 8192 (0x2000) 🙂
Yea, 8192. I read somewhere they should be in increments of 4096. Not sure if that really matters or not.
My office Sonos equipment shows up as tertiary nodes in the matrix, but when I checked the port/link status the link status shows 1.
In another thread "ratty" mentioned to set "STP: Disable" and "Edge Port: Enable" to activate "Fast Forward" for all non Sonos ports but in my personal opinion this doesn't alyways work if there are network devices connected to the switch(es) with more than one physical cabeling connection utilizing port bundling or link aggregation - e.g. a NAS or additional switches are connected via LAG - or if you've set up a switch hierarchy. So at least be careful to set everything outside the Sonos spanning tree to edge ports - e.g. "Edge Port: Enable" that will enable "Fast Forward" on all other network ports.
What exactly does this do? Does it speed things up for non-Sonos components, does it speed up Sonos packets?
Currently I have STP disabled on all non-Sonos ports and Edge set to auto.
today I would like to provide and share some information, findings and "heuristics" about working STP settings for my Sonos installation that's cabled for all (20) but one player device (PLAY:5)
Thank you Matthias! This guide helped me set up my Netgear GS724Tv4 switch, and it's working well with my mostly-wired Sonos system as well.
and two SonosNet wireless extenders (CONNECT)
I thought that the CONECT is a player without an audio amplifier., and the wireless extenders are called BOOST. Are the model names different in Germany perhaps?
Userlevel 7
+21
You're correct Michael... the Connect is an audio output device intended to connect to a separate amplifier and the Boost is a SonosNet "access point" or "extender".
View real-time service status
