Help needed tuning spanning tree - Ethernet port become blocked in switch

  • 15 January 2017
  • 6 replies
  • 6084 views

Userlevel 2
Badge
I've run into a situation where a Connect AMP prefer a weak SonosNet connection over using wired Ethernet.

I have 4 permanently and 1 occasionally powered Sonos units:
a) Connect (wired Ethernet)
b) Play 5
c) Play 1
d) Connect AMP (wired Ethernet)
e) Connect (wired Ethernet, WiFi OFF, unit is occasionally powered)

Sonos Network Matrix (units a to e, left to right on the X-axis):



The SonosNet is "green" between unit a) and b). Unit c) has "yellow" connection with b). Initially when adding unit e) I had problems with network loops and found out that my root switch ate all RSTP BPDUs. Later I enabled RSTP in the root switch and the RSTP protocol started to work and prevent loops, but anyhow I chose to deactivate WiFi in unit e) since it has a wired connection and is located in the basement and surrounded by thick concrete walls.

Today I added unit d), but to my surprise it caused the switch port where it is connected to enter "Blocked" mode and instead chose an "Orange" SonosNet connection with unit a).

Why is unit d) preferring a weak SonosNet connection when it could use wired Ethernet to connect to unit a) and the others?


I had expected the "STP split" to occur between a-b and c-d

The wired Ethernet network consists of a number of UniFi switches with default RSTP settings active. I've read that Sonos uses an older set of path costs than modern switches do. Is that the reason why unit d) is ignoring a perfect wired connection and selecting a weak SonosNet connection?

Or is SonosNet unable to have more than one wired connection? I've read that others have succeeded - unfortunately, I'm not sure I can edit the path costs in my Unifi gear.

I could of course turn off WiFi in unit d) as I did with unit e), but unit c) has better connection with unit d) than any of the others and I suppose it could enjoy a bit better connection if it started to use the wired connection of d) to reach a) instead of jumping over b).

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.

6 replies

Userlevel 2
Badge
I just realized my typo; unit d) is not "electing" SonosNet, its left to it since the switch blocked the port.

How can the Spanning Tree be tuned to prefer wired connections instead of wireless?
Userlevel 2
Badge
After some reading on various forums I found a way to reconfigure my UniFi switches to use the ancient STP path costs used by Sonos.

UniFi ports at 1000 (intra switch) were set with cost 4
UniFi ports at 100 (connecting Sonos) were set with cost 19

ssh admin@unifiswitch
# telnet 127.0.0.1
(UBNT)> enable
(UBNT)# config
(UBNT) (Config)# interface 0/2
(UBNT) (Interface 0/2)# spanning-tree cost 4

The above settings in UniFi need to be saved into json configuration files in the controller, or else they will be reset at next restart or provisioning.

With this, all my wired Sonos devices make use of the wired connection, additionally I get an all green Sonos Network Matrix since unit c) now can use an adjacent wired uplink instead of jumping via unit b).

As far as I can tell there is no way to save custom settings in a json file for Ubiquity Unifi switches, so flyvert's suggested tweak will be lost every time the switch reboots.

However a feature request has been submitted to Ubiquiti for persistent GUI settable per-port RSTP path costs... if you'd like it to be implemented then add a Kudo (like) to https://community.ubnt.com/t5/UniFi-Routing-Switching-Feature/Spanning-tree-port-cost-UI-control/idi-p/1832715
I am running five Unifi switches with 22 Sonos speakers at home without issues or custom configurations. Yes, you have to run STP NOT RSTP and set your priority correctly. Start with the switch that is your root bridge at 4096 and add 4096 to each downstream switch, this is working great for me without issues.

As far as I can tell there is no way to save custom settings in a json file for Ubiquity Unifi switches, so flyvert's suggested tweak will be lost every time the switch reboots.

However a feature request has been submitted to Ubiquiti for persistent GUI settable per-port RSTP path costs... if you'd like it to be implemented then add a Kudo (like) to https://community.ubnt.com/t5/UniFi-Routing-Switching-Feature/Spanning-tree-port-cost-UI-control/idi-p/1832715
I am running five Unifi switches with 22 Sonos speakers at home without issues or custom configurations. Yes, you have to run STP NOT RSTP and set your priority correctly. Start with the switch that is your root bridge at 4096 and add 4096 to each downstream switch, this is working great for me without issues.

That will work great as long as you don't mind some of your switches maybe being linked together via Sonos wifi rather than the physical cables between your switches. My setup STP blocks the Gb uplink port and uses the lower cost route via the Sonos wifi network to link back to my core switch. Not ideal

In my setup I have set my core switch to have an STP value of 0, making that the root switch, and left my other edge switches on RSTP with a value of 20480. Ideally I'd like to set the edge switches to also use STP but it's working and I'm leaving it alone!
Thanks for the posting... You helped me with a much simpler problem I was having. I have 2 Connect:Amps that were both wired and working fine. The wired connection was daisy chained via the hub built into the Connects. I rearranged my network for better performance monitoring and decided to plug both Connect:Amps into separate switch ports instead of daisy chaining. When I was finished with all my other network tweaks, the Sonos App couldn't see either anymore so I went through a setup cycle with one... Weirdly, when I reset one, the other one was suddenly visible, prior to configuration. When the rest Connect:Amp finished configurations, both became invisible again. I tried resting both and they were briefly visible until the last stage of configuration, then disappeared. (but both indicator lights showing their were OK)

Based on your analysis, I decided to go back to daisy chaining and magically, everything worked without any new changes ! Suspect your issue also hit me...