Build 1202 broke my local setup (unsupported, multi-VLAN config)

Tinkering
1

Roon Core Machine

Linux VM (Linux roon 5.10.0-20-amd64 #1 SMP Debian 5.10.158-2 (2022-12-13) x86_64 GNU/Linux)

Networking Gear & Setup Details

UniFi ethernet network with multiple local VLANs (this is fundamental to and unavoidable for my home setup). 10Gbit connectivity between buildings.

172.28.10.x - Servers/Shared
172.28.20.x - Main House
172.28.40.x - Guest House
172.28.50.x - Workshop/Garage

There is no multicast DNS configured between these networks currently.

There are no firewall rules blocking traffic between the VLANs currently, all network segments are routable between each other.

Connected Audio Devices

macOS and iOS audio zones on ethernet and WiFi 6/6E.

Number of Tracks in Library

~18,000

Description of Issue

I’ve been running a multi-VLAN local network with Roon for several years, up to and including the most recent ARC/2.0 builds. I set up my Roon Core to have an interface in each of the 4 relevant local VLANs on my network. This has been working for me just great, although I recognize it’s an unsupported configuration.

Specifically with the 1202 build Roon no longer works with my setup. Roon clients can connect successfully to the Roon core, but every 5 seconds or so the Roon client freaks out, re-connects to the core, and bounces me back to the Home Screen in the Client.

In previous builds, the Roon clients would only see the IP address of the core in the single, specific VLAN/network that the client was connected to. For instance, if I was connected to the “172.28.50.x” WiFi, only the Core interface in that network would be detected by relevant clients. So the clients would only ever see one of the core IP addresses at any given time, depending on which network the client is/was connected to.

With build 1202, now clients can apparently see all of the Core servers IP addresses and reset/reconnect to any one of those IPs every 5 seconds or so. If I “log out” of the client, the core selection screen behaves similarly. It just cycles randomly between the different IPs every few seconds.

I tried re-configuring the core to have just a single IP, but Roon clients still refuse to connect to an IP that’s not in the same network segment/VLAN, even though that IP does appear in the core discovery screen.

This is fatal to my ability to use Roon locally. I can’t make all the buildings on my property a single network segment (because it creates an overwhelming amount of mDNS traffic and breaks all sorts of other devices like Apple TVs where I definitely do not want peer discovery finding devices that are in different buildings).

Was this an intentional or unavoidable change in build 1202, or is this a regression/bug? If this is the new normal it’s probably going to be the end of Roon for me.

Any help or insight? Again, this changed specifically in build 1202, which appears to have re-worked a lot of how network/core discovery functions. I assume this was to enhance ARC and I understand how that would be the more important consideration for Roon developers.

I don’t think it’s a factor, but my setup is not ARC compatible and I don’t have working ARC and do not (and have no ability to) listen to Roon when I’m off site and not at home. My ISP is using CGNAT and no inbound network services work for me. I can’t just set up to work in my main house and rely on ARC in my other buildings. ARC is a non-starter for me entirely because my ISP is so terrible.

Just hoping for some ideas on how I can make this work again, assuming the changes in build 1202 are here to stay. I fully recognize this is an unsupported configuration and the answer may simply be that Roon is not interested in users in my situation. I’ll be disappointed if that’s the case, because I love Roon and have loved using it, but I simply can’t migrate to a single network segment for my home, it would break too many other things just to make Roon Core happy.

2

Here you can see the client behavior when Roon Core has multiple local IPs (15 second screen capture):

As you can see, every few seconds the Roon client freaks out and resets, connecting to another core IP at random. This is new behavior for build 1202.

Audio and playback only seem to function if the randomly-chosen IP is the one in my local network (matching the IP/subnet of the client device). Although I’ve only got a few seconds to play anything before it resets again, so it’s hard to test or experiment.

3

David, I too have had issues with intermittent connectivity with build 1202… Running Unifi, Network is on version 7.3.83… running two VLANs that Roon has access to… I do have my core server IP fixed… didn’t look to see if the IP was changing as yours was… had to roll the Roon core back to build 1193, everything settled down and seem to be okay at this point…

4

I tried using firewall rules to fix the glitch, but it didn’t help.

I have a theory…

I think the Roon Core is trying to send its local, private IP address to the Roon ARC servers and then that local IP is being provided to ARC clients. The client is then using that IP to decide if it’s able to connect locally to the Roon Core or if it has to use the ARC tunneling or whatever.

If the Core has multiple local IPs, it’s just randomly grabbing one of them every 5 seconds or so and sending it which results in undefined client and/or remote behavior.

5

Curious, when I was having issues with immediate crashes, I set the ARC listening port to zero (since you cannot disable ARC)… this seemed to elevate for a bit but then the issue returned. you might be on to something… I did update (actually installed on another server are repointed end-points to it) to an early access build 1208, seems to be stable… maybe try that??

6

Hi David,

I noticed almost identical behavior recently, the difference is that the symptoms for me manifested in ARC being unavailable at times. I posted a feature request to have some control over the IP address that ARC uses but I now believe that your symptoms and mine are closely related.

Also, I want to mention that I don’t think that this issue should be classified as unsupported and I also question whether “Tinkering” is the right area for this. Is there somewhere where RoonLabs state that multiple interfaces renders your installation unsupported? I use RoonOS for my core and that is totally locked down, I consider that if I can configure RoonOS to do something (multiple interfaces as an example) that it should be fully supported and also not considered Tinkering. This is a feature and specific configuration that has been made available to us by RoonLabs.

1 Like
8

I think you’re right that the two issues are fundamentally the same problem, although I was seeing this interfere with local clients and not with ARC. I’m unable to run ARC here at my location.

Reminds me of a similar problem I had when I had dual stack IPv6+IPv4 on my Roon Core, and ARC was trying to use my IPv6 address for NAT piercing.

https://community.roonlabs.com/t/arc-needs-native-ipv6-support-resolved/204542/9

I can only assume they’ve fixed that one already by filtering out IPv6, but I’m not able to test that any more.

9

Not sure they have as they normally just recommend to turn off ipv6 support on your router.

10

I removed the default gateway from the NIC that is on the secondary network. In my case I don’t need to route that traffic anyway so it is all good. Initially things look promising, its been about 12 hours now and the primary NIC has been stable and ARC is behaving itself.

11

This topic was automatically closed 45 days after the last reply. New replies are no longer allowed.