Roon crashes my network! [solved vlan multicast issue]

Support
1

This is a weird one. I signed up for the 14-day trial, and installed Roon 1.2 build 147 on my PC, Windows 10 x64 Pro. When I run Roon, my home network freezes up. The same thing happens when I install and run Roon on my MacBook Pro. After some testing, I discovered that, if I power down my Cisco SG200-26P switch, this doesn’t happen. The switch is not in the path between my PC/MacBook and my router out to the internet. It’s connected to a different port on the router, and manages my data and VoIP VLANs.

Roon is set to only look for music on the PC on which it’s installed. There are no other network devices enabled in Roon.

While Roon is running, if I power up the Cisco switch, the network freezes up again after a few minutes. It looks like a packet storm. There IS a network loop in my network, i.e. my VoIP switch is connected to the router, as is the Cisco switch, and the VoIP switch is connected to the Cisco switch directly. But those two connections are on different VLANs, If Roon is somehow broadcasting on both those VLANs, that might be causing a network loop.

So, my guess is that Roon does something to the network that causes a problem with that Cisco switch. Before I spend a ton of time with network analysis tools, can you please let me know what Roon tries to do to the network? I’m guessing that it probes it in some way, and it’s doing it every few minutes. Thanks!

2

it’s sending multicast pkts, broadcast pkts, and doing a quick scan when it starts up to find other devices (but only if you are on a /24)

it also scans things in your arp cache to determine what might have stuff needing to be discovered

it tries to be nice in doing so, but it’s still doing a lot

Can you tcpdump and let us know what’s going on?

4

Thanks for the super-quick response.

It’s definitely a loop issue. If I disconnect the link between my VoIP switch and the Cisco switch, the problem goes away. But, all of my VoIP 'phones are connected to the Cisco switch, so they stop working.

The 'phones are on VLAN 100. Everything else in on VLAN 1.

This is part of the tcpdump when the network is frozen, i.e. it’s really busy with thousands of these. AlexMain is the name of the PC running Roon.

01:42:00.170371 IP AlexMain.62026 > 239.255.90.90.9003: UDP, length 98
01:42:00.170371 IP AlexMain.63920 > 239.255.90.90.9003: UDP, length 98
01:42:00.170371 IP AlexMain.63925 > 239.255.90.90.9003: UDP, length 98
01:42:00.170371 IP AlexMain.62030 > 239.255.90.90.9003: UDP, length 98
01:42:00.170371 IP AlexMain.63924 > 239.255.90.90.9003: UDP, length 98
01:42:00.170371 IP AlexMain.63925 > 239.255.90.90.9003: UDP, length 98
01:42:00.170371 IP AlexMain.58836 > 239.255.90.90.9003: UDP, length 325
01:42:00.170371 IP AlexMain.62026 > 239.255.90.90.9003: UDP, length 98
01:42:00.170371 IP AlexMain.63920 > 239.255.90.90.9003: UDP, length 98
01:42:00.170371 IP AlexMain.62030 > 239.255.90.90.9003: UDP, length 98

5

Hmmm, I think that I fixed it. My puny human mind doesn’t understand VLANs well enough. I marked the port on the Cisco switch that’s connected to the VoIP switch as “Forbidden” for VLAN 1, and that removed the problem.

I’m still wondering why only Roon has caused this issue.

6

because we are one of the few applications that use multicast… you are basically running into a multicast storm between your vlans – my guess is your voip might do something similar.

glad you found a workaround

7

Yep, you nailed it: my network had a lurking bug with respect to multicast. My VLAN hack was to prevent having to run two physical networks – the whole point of VLANs – but I messed up on that one port. Thanks for your help!

1 Like
8

Ok. I want to give some feedback here…

I also had this problem.

Basically it is my belief Roon brought down my entire ethernet network controlled Home automated home

I had a massive broadcast storm about 3-5 days after Roon Server was installed on a Linux QNAP.

I have similar Cisco gear.

Even if it wasn’t Roon (I can only assume by the process of exclusion) what this does mean, is Roon will stay idle, switched off and unused. I simply cannot risk this happening again, because it affected security, door and light control etc etc… That means I will not be signing up. This was a major inconvenience and your software engineers need to attend to this issue urgently IMHO. It took me 2 days to get my network back. Just passing back the feedback ok? Cheers.

9

@Alex_Baker do you have network logs of this happening? Plus a network topology? We have thousands of users running fine, and there are only 1 other report of this situation, which was resolved by fixing a network vlan misconfiguration.

Clearly with a complex network setup, you can appreciate that it is impossible to debug/reproduce issues like this with as little information as you have provided.

10

No I don’t have a network log. I could look for it in my Router for you if you want… bt I’m not sure it was saved… But Roon Server was the last thing I added to my network and I saw a similar thing with Sonos years ago. They got all “cockie” and said it “wasn’t them”…well darn right it was… in the end this lead to a list of incompatible switches. Thing is in the"real" world you just have to deal with it, sort it quickly and deduct the likely candidate… One doesn’t have the luxury of sitting at a terminal running network tests when the entire network has crashed, lights and blinds and alarms and doors don’t work etc… Cheers.

11

Nope just checked. No network logs. Sorry. Ah So Roon uses mDNS right?

12

Multicast and Spanning Tree are the two reasons why I recommend that customers only use high-quality unmanaged switches on their networks. Layer 2 and 3 managed switches are great, but often times their defaults are not conducive to the way that a number of plug-and-play consumer products implement their communication. This isn’t a problem with Roon or Sonos or UPnP, but rather the fact that in a commercial environment the kind of “overly-chatty” traffic that these devices generate is rarely seen and in its default configuration a Cisco SG200 switch will pretty much implode the network trying to deal with it.

Now throw in a router with a questionable multicast implementation along with some wireless access points that simply can’t be configured and you can be royally screwed. For instance Apple’s Airport Devices don’t implement spanning tree correctly and when paired with a manged switch Sonos simply doesn’t work.

I use managed switches at home (mostly because I have them), but had to implement specific parameters on the ports used by Sonos in order to keep spanning tree from booting devices off the network. With UPnP and Roon I’ve had to make some configuration changes to enable Multicast to function correctly (specifically disabling IGMP snooping) and changing the defaults so that the two switches don’t fight over being in charge of all things multicast.

This type of granular control isn’t a big deal if you know the changes that need to be made and can do them quickly, but it does eliminate the ability to be able to plug anything in anywhere.

At the store the audio network is all unmanaged switches and aside from needing to pipe in a VLAN to handle multiple wireless networks on the same access point it’s a completely dumb network. It’s fast but more importantly it’s stable. Last count was over 25 UPnP devices, 8 Sonos, 2 Roon servers and 4 Roon endpoints.

There’s an attitude out there that managed is better (which typically follows along the bigger / more powerful is better attitude that a lot of audiophiles posses), but unless the added features are absolutely required unmanaged will be just as fast and a hell of a lot easier to deal with.

@Alex_Baker make sure that IGMP snooping and “Bridge Multicast” are disabled in your switche(s) and and you’ll also want to be sure that you’re using IP group address forwarding. If you’re using Sonos then there are some changes that need to be made in order to turn off autonegotiation of spanning tree, but this needs to be done on a port by port basis. Also check your router and/or wireless access points to see if they support IGMP snooping and turn it off.

11 Likes
13

We only use mDNS for Airplay discovery.

We also use multicast for our own discovery protocols (not entirely, but we augment with multicast).

14

Thanks for this extremely helpful post Andrew P

This information should be placed all over the Roon “how to” and Q/A.

It is simply that essential.

For without this sort of valuable information chaos can be let loose.

And let me assure you this sort of thing can cause chaos and now bring down an entire network… and now a home even…

So Roon needs to get this sort of information out there.

So where is the “how to set up your network for Roon” in three easy steps?

Thanks for providing the opportunity for feedback and thanks Roon for listening.

15

239.255.x.x - that’s multicast

Question - can an engineer change the multicast range used by roon?

239.255.100.x/24 as an example?

16

No, that wouldn’t work. All devices out there would need to be changed too

17

I have to assume that Roon realizes that those multicast administrative multicast addresses (239.255.x.x) are used by a lot of different vendors. As Roon gains popularity and grows, you’re going to encounter others using those admin addresses on the network. My company uses that address space but we have the ability to subnet out within that large prefix. Sooner or later you’ll have to re-engineer the network stack because of the multicast dependence. Not everyone has VRF instances running in the house :slight_smile:

18

I have my network running off a Cisco sg300 switch. It is a somewhat complicated setup for a house but I specifically needed a multicast aware switch to run my video over IP system ( crestron DM-NVX).

How I have it setup is I have the video stuff on its own VLAN 1 with multicast setup enabled and IGMP snooping v3 enabled on that VLAN.

The rest of the house is setup on VLAN 0 with the default settings. Most of the roon endpoints are actually on a cascaded unmanaged switch ( although some are on the Cisco switch due to needing POE.). The bridge between the two switches specially allows VLAN 0 only.

Seems to work fine.

The only issues I’ve had was with the crestron DM-NVX network not doing its multicast filtering properly ( the multicast addresses weren’t being automatically added to the filters). As soon as added those addresses manually the storm ended. The video is very demanding and takes 750Mbps per stream so two streams crashes the network of the multicast filtering isn’t correctly setup

19

Closed due to inactivity. If you are still seeing this issue, please open a new support thread.