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.
Page 1 / 1
You can create a network storm with multiple sonos devices both wired and wireless on (it depends on router and how well it handles STP)
Best thing to do is either only have one Sonos device plugged in via lan
or
if want to leave other Sonos devices plugged in lan go into settings...system for that device and disable the wireless for the additional units plugged in router. That way they will only communicate via lan and not both (creating the storm).
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.
Odd things can happen. Keep an open mind.
I was once investigating a wired network that was slower than expected. I had a SONOS player, computer, NAS, and various A/V kit connected to a network switch. The computer’s Internet connection was about half the expected speed (this was an ADSL connection) After a bunch of head scratching I finally realized that the LAN connection from the rest of the house to the local switch was not working. The SONOS player had figured this out and shared its wireless connectivity with the switch. This was not a great wireless location for a Player. One normally assumes that if that LAN connection goes down, everything stops, rather than slowing down. There had been some construction and the LAN cable to the switch had been damaged.
Thanks for all the advice! This was much faster and more technically detailed than I expected; I’m impressed.
Here’s the full network topology:
In the office:
Cable modem → WAN port of Netgear R7800 running DD-WRT, which broadcasts wifi networks on both 2.4 and 5GHz.
Lan port of Netgear R7800 → D-Link GO-SW-8G unmanaged 8-port gigabit switch
The R7800 is on top of a motorized sit-stand desk, and I’ve only run two ethernet cables up and down, using the D-Link switch for everything else.
Several devices are connected to the D-Link switch, including the office Play:1, a couple desktops, and the cable to the living room. When I ran the cable to the living room I actually ran two, so there’s a backup available, or I could home-run one of the devices in the living room.
In the living room:
Cable from office → Rosewill RC-415 unmanaged 5-port gigabit switch → Sonos Connect → Amazon Fire TV (I’m using both ethernet ports on the Connect because it was easier given where the devices are physically located, but I have other options if that’s potentially problematic)
Also connected to the Rosewill switch in the living room is an Asus RT-N66U in access point mode broadcasting a 5GHz network only, with the same SSID as the one from the office. The switch is connected to one of the LAN ports and the DHCP server is disabled.
Other Sonos speakers elsewhere in the house: 1x Play:5 3x Play:1
I definitely want to keep an open mind. I know just enough about networking to know that there’s a LOT that I don’t know.
I did a little googling and found the specifications for both switches (Rosewill and D-Link) but I didn’t see any mention of STP, RSTP, or any references to 802.1 protocols.
If I were to be experiencing a “network storm”, how would I know? Is there some tool I can use to see that that’s happening?
Ratty, it’s great to hear that wiring multiple SonosNet devices is a generally-supported and recommended use case. Improving resilience is exactly what I want.
At the moment, with the Sonos Connect disconnected from ethernet, I have sub-millisecond ping times between my desktop (connected to the D-Link switch in the Office), and the Asus WAP (connected to the Rosewill switch in the Living Room), so the wired path is (at least for now) strong.
Are there any changes you can recommend I make to my setup that would improve resilience? Or other debugging steps I can do to gather more data?
Rewire the Connect. Wait a couple of minutes then go to http://IP_address_of_a_player:1400/support/review and click on Network Matrix. You can choose a hard IP from Settings/System/About My System. Take a screenshot and post it. Let’s confirm what’s happening to the topology.
I may then ask for a bit more data.
As for a network storm, you’d certainly know about it. The LAN would grind to a halt, with port LEDs going crazy.
Yesterday I had a network storm. I tried to capture the network matrix page at that time, but the lan wasn’t carrying any traffic, and the port LEDs were all blinking away at top speed. The storm happened without warning after not changing anything for about a week (both the office and living room had been plugged in the whole time). Thanks to you folks here, I knew what was going on, because those would have otherwise been confusing symptoms.
Network matrix from after the storm was resolved (with the office ethernet cable unplugged):
Office ethernet cable unplugged
Some other screenshots from different times
Living room ethernet unplugged
Both plugged in, network working fineBoth plugged in, I think the speakers were still working, but for some reason the noise level spiked. The only thing that I can think of that was different was that this screenshot was captured at nighttime.
Not seeing how to subscribe to this thread to see the outcome so I’m commenting. Fantastic read, boys. Well done.
Uh. Found it. ‘Add to favorites.’
ODFM ANI level: ‘0’ is best, ‘9’ is worst and the unit is struggling. “Inbound” and “Outbound” are indications of wireless signal strength.
I have variable wireless too. Next door is a medical facility and there is a power line running by the house. I’m suspicious that one or the other is radiating something obnoxious. I haven’t been able to identify any regular pattern, but afternoons tend to be quieter than late night. It is possible that the power company is reading meters late at night. I’ll have all red cells on the left and some times all green except for one yellow. Generally, I don’t have SONOS wireless issues.
I can’t point to any smoking gun, but the source of your interference might be closer to the Living Room and Play Room and farther from the Bedroom.
There’s nothing odd about the matrix pictures at all. The topologies are correct.
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
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.
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?
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.
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.
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.
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.
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.
