Skip to main content
Contributor I
April 5, 2020
Answered

How to make SonosNet stop carrying lan traffic

Is it possible to disable the feature of sonosnet that carries non-sonos traffic to an ethernet device connected to a remote speaker? I'll try to explain my setup:

In my office, I have my primary router/internet gateway, various computer equipment, and a sonos Play 1, all connected via ethernet. I also have an ethernet cable that runs from the office to the living room, which is on the opposite side of the house.

I have several other sonos speakers around the house, connected to the other speakers using SonosNet.

In the living room, I have an ethernet switch (connected to the cable from the office) that connects to several devices, including a Sonos Connect, and a second wifi router running in 5GHz-only access point mode.

I was experiencing significant latency/poor connectivity on my laptop when connected to the living room access point, and I couldn't figure out why until my wife unplugged the sonos speaker in the office (thinking it wasn't important), which disabled the Sonos in the entire house, and also disconnected the living room AP and other equipment connected to it from the network. The wired connection between the office and living room was still connected, but it seems it wasn't being used in favor of routing traffic over SonosNet (which went down when the office speaker was unplugged).

The obvious solution is to disconnect the Sonos Connect from the ethernet network, relying only on the speaker in the office to connect SonosNet to the rest of the network. The complicating factor is that I'm doing various small electrical work around the house, and frequently shut off power to various rooms. The router is on a UPS and unaffected, but I'd like the Sonos speakers around the house to keep working when _either_ the speaker in the living room or the speaker in the office have power.

Is there anything I can configure in SonosNet to tell it that there are two nodes with upstream network connectivity, so that it will failover from one to the other? If I put some sort of "smarter" networking device in the living room, like a managed switch or a router, can I accomplish the same thing that way?

I'm a software engineer by trade, and a linux buff, so solutions like editing config files or manually making API calls are easy for me.

 

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.
ratty
rattyAnswer
April 5, 2020

Wiring multiple Sonos devices is, in general, to be recommended since it improves SonosNet coverage and resilience. 

Sonos uses STP (Spanning Tree Protocol) to determine topology and avoid network loops. If the wired path between such devices blocks STP this can result in a loop going uncorrected. Broadcast storms eventually bring down the network.

In this instance the wired path -- which should always be preferred -- is apparently being bypassed wirelessly by SonosNet. Unless there’s a simple wiring fault this is probably due to another STP problem: higher path cost on the wired path compared to the wireless path. The wired path therefore loses out and is blocked. Typically this higher path cost is caused by switches using RSTP (Rapid Spanning Tree Protocol) instead of the classic STP.

If we had a complete description of the network topology, together with make/model of devices, we may be able to advise further.

18 replies

mbbushAuthor
Contributor I
April 14, 2020

Yes, the living room shows a root path cost of 10. I put the full `showstp` output for each speaker below. The office shows a root path cost of 0.

 

I read a little bit more about how switches work. Both of my switches are “store and forward” types, but they seem to have a very small amount of ram. From what I could tell, each has only 128 kB (which one of them disingenuously refers to as 1 million bits of ram). The 8-port D-link switch has a 4k mac address table, and the 4-port rosewill has an 8k mac address table.

 

I was impressed at how quickly the network reconfigured itself to promote the office to root bridge after I reconnected it. It only took a few seconds, basically just as long as it took me to sit down at my desk and bring up the topology page. Here’s the new matrix:
 

 

 Living room:

running /usr/sbin/brctl showstp br0
br0
bridge id 9000.949f3eb49574
designated root 9000.7828ca26de68
root port 1 path cost 10
max age 6.00 bridge max age 6.00
hello time 1.00 bridge hello time 1.00
forward delay 4.00 bridge forward delay 4.00
ageing time 60.00 gc interval 0.00
hello timer 0.00 tcn timer 0.00
topology change timer 0.00 gc timer 2.03
flags


eth0 (1)
port id 8001 state forwarding
designated root 9000.7828ca26de68 path cost 10
designated bridge 9000.7828ca26de68 message age timer 5.79
designated port 8001 forward delay timer 0.00
designated cost 0 hold timer 0.00
flags

ath0 (2) - tunnel to 94:9F:3E:53:20:E3 (remote STP state = blocking, direct = 3)
port id 8002 state forwarding
designated root 9000.7828ca26de68 path cost 283
designated bridge 9000.949f3eb49574 message age timer 0.00
designated port 8002 forward delay timer 0.00
designated cost 10 hold timer 0.13
flags CONFIG_PENDING

ath0 (3) - tunnel to 78:28:CA:26:DE:69 (remote STP state = forwarding, direct = 1)
port id 8003 state blocking
designated root 9000.7828ca26de68 path cost 307
designated bridge 9000.7828ca26de68 message age timer 5.79
designated port 8005 forward delay timer 0.00
designated cost 0 hold timer 0.00
flags

ath0 (4) - tunnel to 78:28:CA:9C:8E:45 (remote STP state = forwarding, direct = 3)
port id 8004 state forwarding
designated root 9000.7828ca26de68 path cost 245
designated bridge 9000.949f3eb49574 message age timer 0.00
designated port 8004 forward delay timer 0.00
designated cost 10 hold timer 0.13
flags CONFIG_PENDING

ath0 (5) - tunnel to 94:9F:3E:09:A7:BF (remote STP state = blocking, direct = 3)
port id 8005 state forwarding
designated root 9000.7828ca26de68 path cost 321
designated bridge 9000.949f3eb49574 message age timer 0.00
designated port 8005 forward delay timer 0.00
designated cost 10 hold timer 0.13
flags CONFIG_PENDING

ath0 (6) - tunnel to 5C:AA:FD:7A:27:83 (remote STP state = blocking, direct = 0)
port id 8006 state forwarding
designated root 9000.7828ca26de68 path cost 719
designated bridge 9000.949f3eb49574 message age timer 0.00
designated port 8006 forward delay timer 0.00
designated cost 10 hold timer 0.13
flags CONFIG_PENDING

Bedroom:

running /usr/sbin/brctl showstp br0
br0
bridge id 9800.5caafd7a2782
designated root 9000.7828ca26de68
root port 5 path cost 211
max age 6.00 bridge max age 6.00
hello time 1.00 bridge hello time 1.00
forward delay 4.00 bridge forward delay 4.00
ageing time 60.00 gc interval 0.00
hello timer 0.00 tcn timer 0.00
topology change timer 0.00 gc timer 3.83
flags


eth0 (1)
port id 8001 state disabled
designated root 8000.5caafd7a2782 path cost 10
designated bridge 8000.5caafd7a2782 message age timer 0.00
designated port 8001 forward delay timer 0.00
designated cost 0 hold timer 0.00
flags

ath0 (2) - tunnel to 78:28:CA:9C:8E:45 (remote STP state = blocking, direct = 3)
port id 8002 state forwarding
designated root 9000.7828ca26de68 path cost 321
designated bridge 9800.5caafd7a2782 message age timer 0.00
designated port 8002 forward delay timer 0.00
designated cost 211 hold timer 0.17
flags

ath0 (3) - tunnel to 94:9F:3E:09:A7:BF (remote STP state = blocking, direct = 3)
port id 8003 state forwarding
designated root 9000.7828ca26de68 path cost 254
designated bridge 9800.5caafd7a2782 message age timer 0.00
designated port 8003 forward delay timer 0.00
designated cost 211 hold timer 0.17
flags

ath0 (4) - tunnel to 94:9F:3E:B4:95:75 (remote STP state = forwarding, direct = 0)
port id 8004 state blocking
designated root 9000.7828ca26de68 path cost 719
designated bridge 9000.949f3eb49574 message age timer 5.19
designated port 8006 forward delay timer 0.00
designated cost 10 hold timer 0.00
flags

ath0 (5) - tunnel to 78:28:CA:26:DE:69 (remote STP state = forwarding, direct = 1)
port id 8005 state forwarding
designated root 9000.7828ca26de68 path cost 211
designated bridge 9000.7828ca26de68 message age timer 5.19
designated port 8004 forward delay timer 0.00
designated cost 0 hold timer 0.00
flags

ath0 (6) - tunnel to 94:9F:3E:53:20:E3 (remote STP state = forwarding, direct = 3)
port id 8006 state blocking
designated root 9000.7828ca26de68 path cost 245
designated bridge 9800.949f3e5320e2 message age timer 5.19
designated port 8006 forward delay timer 0.00
designated cost 202 hold timer 0.00
flags

Purple room:

running /usr/sbin/brctl showstp br0
br0
bridge id 9800.7828ca9c8e44
designated root 9000.7828ca26de68
root port 4 path cost 255
max age 6.00 bridge max age 6.00
hello time 1.00 bridge hello time 1.00
forward delay 4.00 bridge forward delay 4.00
ageing time 60.00 gc interval 0.00
hello timer 0.00 tcn timer 0.00
topology change timer 0.00 gc timer 0.56
flags


eth0 (1)
port id 8001 state disabled
designated root 8000.7828ca9c8e44 path cost 10
designated bridge 8000.7828ca9c8e44 message age timer 0.00
designated port 8001 forward delay timer 0.00
designated cost 0 hold timer 0.00
flags

ath0 (2) - tunnel to 94:9F:3E:09:A7:BF (remote STP state = forwarding, direct = 3)
port id 8002 state blocking
designated root 9000.7828ca26de68 path cost 278
designated bridge 9800.949f3e09a7be message age timer 4.99
designated port 8003 forward delay timer 0.00
designated cost 240 hold timer 0.00
flags

ath0 (3) - tunnel to 78:28:CA:26:DE:69 (remote STP state = forwarding, direct = 1)
port id 8003 state blocking
designated root 9000.7828ca26de68 path cost 288
designated bridge 9000.7828ca26de68 message age timer 5.98
designated port 8006 forward delay timer 0.00
designated cost 0 hold timer 0.00
flags

ath0 (4) - tunnel to 94:9F:3E:B4:95:75 (remote STP state = forwarding, direct = 1)
port id 8004 state forwarding
designated root 9000.7828ca26de68 path cost 245
designated bridge 9000.949f3eb49574 message age timer 4.99
designated port 8004 forward delay timer 0.00
designated cost 10 hold timer 0.00
flags

ath0 (5) - tunnel to 94:9F:3E:53:20:E3 (remote STP state = forwarding, direct = 3)
port id 8005 state blocking
designated root 9000.7828ca26de68 path cost 302
designated bridge 9800.949f3e5320e2 message age timer 4.99
designated port 8003 forward delay timer 0.00
designated cost 202 hold timer 0.00
flags

ath0 (6) - tunnel to 5C:AA:FD:7A:27:83 (remote STP state = forwarding, direct = 3)
port id 8006 state blocking
designated root 9000.7828ca26de68 path cost 321
designated bridge 9800.5caafd7a2782 message age timer 5.98
designated port 8002 forward delay timer 0.00
designated cost 211 hold timer 0.00
flags

Office:
 

running /usr/sbin/brctl showstp br0
br0
bridge id 9000.7828ca26de68
designated root 9000.7828ca26de68
root port 0 path cost 0
max age 6.00 bridge max age 6.00
hello time 1.00 bridge hello time 1.00
forward delay 4.00 bridge forward delay 4.00
ageing time 60.00 gc interval 0.00
hello timer 0.59 tcn timer 0.00
topology change timer 0.00 gc timer 3.37
flags


eth0 (1)
port id 8001 state forwarding
designated root 9000.7828ca26de68 path cost 10
designated bridge 9000.7828ca26de68 message age timer 0.00
designated port 8001 forward delay timer 0.00
designated cost 0 hold timer 0.58
flags

ath0 (2) - tunnel to 94:9F:3E:09:A7:BF (remote STP state = forwarding, direct = 3)
port id 8002 state forwarding
designated root 9000.7828ca26de68 path cost 240
designated bridge 9000.7828ca26de68 message age timer 0.00
designated port 8002 forward delay timer 0.00
designated cost 0 hold timer 0.58
flags CONFIG_PENDING

ath0 (3) - tunnel to 94:9F:3E:53:20:E3 (remote STP state = forwarding, direct = 3)
port id 8003 state forwarding
designated root 9000.7828ca26de68 path cost 202
designated bridge 9000.7828ca26de68 message age timer 0.00
designated port 8003 forward delay timer 0.00
designated cost 0 hold timer 0.58
flags CONFIG_PENDING

ath0 (4) - tunnel to 5C:AA:FD:7A:27:83 (remote STP state = forwarding, direct = 3)
port id 8004 state forwarding
designated root 9000.7828ca26de68 path cost 211
designated bridge 9000.7828ca26de68 message age timer 0.00
designated port 8004 forward delay timer 0.00
designated cost 0 hold timer 0.58
flags CONFIG_PENDING

ath0 (5) - tunnel to 94:9F:3E:B4:95:75 (remote STP state = blocking, direct = 1)
port id 8005 state forwarding
designated root 9000.7828ca26de68 path cost 307
designated bridge 9000.7828ca26de68 message age timer 0.00
designated port 8005 forward delay timer 0.00
designated cost 0 hold timer 0.58
flags

ath0 (6) - tunnel to 78:28:CA:9C:8E:45 (remote STP state = blocking, direct = 3)
port id 8006 state forwarding
designated root 9000.7828ca26de68 path cost 288
designated bridge 9000.7828ca26de68 message age timer 0.00
designated port 8006 forward delay timer 0.00
designated cost 0 hold timer 0.58
flags

Caleb’s room:
 

running /usr/sbin/brctl showstp br0
br0
bridge id 9800.949f3e09a7be
designated root 9000.7828ca26de68
root port 2 path cost 240
max age 6.00 bridge max age 6.00
hello time 1.00 bridge hello time 1.00
forward delay 4.00 bridge forward delay 4.00
ageing time 60.00 gc interval 0.00
hello timer 0.00 tcn timer 0.00
topology change timer 0.00 gc timer 0.14
flags


eth0 (1)
port id 8001 state disabled
designated root 8000.949f3e09a7be path cost 10
designated bridge 8000.949f3e09a7be message age timer 0.00
designated port 8001 forward delay timer 0.00
designated cost 0 hold timer 0.00
flags

ath0 (2) - tunnel to 78:28:CA:26:DE:69 (remote STP state = forwarding, direct = 1)
port id 8002 state forwarding
designated root 9000.7828ca26de68 path cost 240
designated bridge 9000.7828ca26de68 message age timer 5.42
designated port 8002 forward delay timer 0.00
designated cost 0 hold timer 0.00
flags

ath0 (3) - tunnel to 78:28:CA:9C:8E:45 (remote STP state = blocking, direct = 3)
port id 8003 state forwarding
designated root 9000.7828ca26de68 path cost 278
designated bridge 9800.949f3e09a7be message age timer 0.00
designated port 8003 forward delay timer 0.00
designated cost 240 hold timer 0.86
flags

ath0 (4) - tunnel to 94:9F:3E:B4:95:75 (remote STP state = forwarding, direct = 1)
port id 8004 state blocking
designated root 9000.7828ca26de68 path cost 321
designated bridge 9000.949f3eb49574 message age timer 5.42
designated port 8005 forward delay timer 0.00
designated cost 10 hold timer 0.00
flags

ath0 (5) - tunnel to 94:9F:3E:53:20:E3 (remote STP state = forwarding, direct = 3)
port id 8005 state blocking
designated root 9000.7828ca26de68 path cost 235
designated bridge 9800.949f3e5320e2 message age timer 4.41
designated port 8002 forward delay timer 0.00
designated cost 202 hold timer 0.00
flags

ath0 (6) - tunnel to 5C:AA:FD:7A:27:83 (remote STP state = forwarding, direct = 3)
port id 8006 state blocking
designated root 9000.7828ca26de68 path cost 254
designated bridge 9800.5caafd7a2782 message age timer 5.40
designated port 8003 forward delay timer 0.00
designated cost 211 hold timer 0.00
flags

Play room:
 

running /usr/sbin/brctl showstp br0
br0
bridge id 9800.949f3e5320e2
designated root 9000.7828ca26de68
root port 5 path cost 202
max age 6.00 bridge max age 6.00
hello time 1.00 bridge hello time 1.00
forward delay 4.00 bridge forward delay 4.00
ageing time 60.00 gc interval 0.00
hello timer 0.00 tcn timer 0.00
topology change timer 0.00 gc timer 3.68
flags


eth0 (1)
port id 8001 state disabled
designated root 8000.949f3e5320e2 path cost 10
designated bridge 8000.949f3e5320e2 message age timer 0.00
designated port 8001 forward delay timer 0.00
designated cost 0 hold timer 0.00
flags

ath0 (2) - tunnel to 94:9F:3E:09:A7:BF (remote STP state = blocking, direct = 3)
port id 8002 state forwarding
designated root 9000.7828ca26de68 path cost 235
designated bridge 9800.949f3e5320e2 message age timer 0.00
designated port 8002 forward delay timer 0.00
designated cost 202 hold timer 0.91
flags

ath0 (3) - tunnel to 78:28:CA:9C:8E:45 (remote STP state = blocking, direct = 3)
port id 8003 state forwarding
designated root 9000.7828ca26de68 path cost 302
designated bridge 9800.949f3e5320e2 message age timer 0.00
designated port 8003 forward delay timer 0.00
designated cost 202 hold timer 0.91
flags

ath0 (4) - tunnel to 94:9F:3E:B4:95:75 (remote STP state = forwarding, direct = 1)
port id 8004 state blocking
designated root 9000.7828ca26de68 path cost 283
designated bridge 9000.949f3eb49574 message age timer 5.23
designated port 8002 forward delay timer 0.00
designated cost 10 hold timer 0.00
flags

ath0 (5) - tunnel to 78:28:CA:26:DE:69 (remote STP state = forwarding, direct = 1)
port id 8005 state forwarding
designated root 9000.7828ca26de68 path cost 202
designated bridge 9000.7828ca26de68 message age timer 5.22
designated port 8003 forward delay timer 0.00
designated cost 0 hold timer 0.00
flags

ath0 (6) - tunnel to 5C:AA:FD:7A:27:83 (remote STP state = blocking, direct = 3)
port id 8006 state forwarding
designated root 9000.7828ca26de68 path cost 245
designated bridge 9800.949f3e5320e2 message age timer 0.00
designated port 8006 forward delay timer 0.00
designated cost 202 hold timer 0.91
flags

 

ratty
April 15, 2020

Yes, the living room shows a root path cost of 10. I put the full `showstp` output for each speaker below. The office shows a root path cost of 0.

That’s as it should be.

I suggest that the next time you think that SonosNet is bypassing your wired connection you check the matrix and /status/showstp again.

I wonder if the Ethernet cable to the living room is flaky. You can also check the switch port LEDs at either end of the cable run.

I was impressed at how quickly the network reconfigured itself to promote the office to root bridge after I reconnected it. It only took a few seconds, basically just as long as it took me to sit down at my desk and bring up the topology page. 

The topology is monitored regularly -- once per second in fact -- and if an active link should break, or a newly available link appear, an alternative topology would be calculated within very short order. Often a music stream would be re-routed without any interruption to playback.

mbbushAuthor
Contributor I
April 15, 2020

I’m thinking maybe I’ll write a monitoring script that hits the status url on a schedule. How would I identify an abnormal result?

ratty
April 16, 2020

I’m thinking maybe I’ll write a monitoring script that hits the status url on a schedule. How would I identify an abnormal result?

If the living room player’s wired connection failed then its root port would change from 1, and its root path cost would jump into 3 figures. Just use a regexp to get the root port number.

 

mbbushAuthor
Contributor I
April 22, 2020

I switched over to the other ethernet cable a couple days ago, and haven’t had any issues since then. I’ll continue to monitor. 

 

Does it seem reasonable that this sort of issue (broadcast storm caused by a failure of STP to disable the right ports, as I understand it) to be caused by a wiring issue in the ethernet cable linking the two devices? I terminated the ends myself into female jacks, and while I thought (at the time) I did a pretty good job, I’m no professional.

ratty
April 22, 2020

I switched over to the other ethernet cable a couple days ago, and haven’t had any issues since then. I’ll continue to monitor. 

 

Does it seem reasonable that this sort of issue (broadcast storm caused by a failure of STP to disable the right ports, as I understand it) to be caused by a wiring issue in the ethernet cable linking the two devices? I terminated the ends myself into female jacks, and while I thought (at the time) I did a pretty good job, I’m no professional.

There are storms of different kinds.

A traditional broadcast storm could be triggered by an undetected network loop, such as when STP is unable to do its job properly because its BPDUs (Bridge Protocol Data Units) are being blocked. Broadcast packets, say from an ARP request (to resolve an IP to a MAC address), would then circulate indefinitely. Usually these bring the network down repeatedly and very rapidly. Such storms can however be spasmodic if a wireless connection that completes the loop is marginal, and flicks in and out. I don’t think you suffered from a broadcast storm.

What I suspect you might have had is an intermittent flood of TCN (Topology Change Notification) packets. When a link makes or breaks -- as would have been the case with a dodgy wire connection -- it triggers the ends to say “something’s changed here” and TCNs ripple though the network as the topology is recomputed. Doing this frequently could gum up the network. Hopefully you’ve now seen the back of such disruptions by switching to a different cable.

mbbushAuthor
Contributor I
May 14, 2020

I’ve tried several things in the past three weeks, with no real success, but I think I have a new lead.

 

Switching to the other ethernet cable didn’t make a difference. That either means the problem isn’t a bad cable, the problem is caused by something I did to both cables while running them under the house, the problem is in the way I wired both ethernet jacks, or the problem is in the brand-new patch cables on either end of the jacks. I think the most likely is that the problem isn’t a bad cable.

 

One additional symptom that has happened every time I’ve had a storm is that my linux desktop has become non-responsive. Additionally, when I have a storm, I unplug both switches for a couple minutes, then plug them back in, and the storm resumes. Today I did that, and then switched off the desktop and the storm immediately stopped.

All of this points to the problem being somewhere in the networking stack on my desktop. I’ve been considering blowing away the entire OS and upgrading anyways, so maybe I’ll do that sooner rather than later.

ratty
May 14, 2020

If you’re familiar with Wireshark you might want to give that a try. When I’ve had the odd storm it’s sometimes helped determine the packet source and type.