Ethernet Port 1 (Intel Internal) is connected to the music server that is setup as dhcp.
Ethernet Port 2 (USB Ethernet Adapter) is connected to the LAN using static ip.
The router is set to deliver 10.10.10.xxx DHCP addresses. The LAN cannot see the music server.
In a non-ROCK setup (Linux Arch), it is working fine using bridged interface. Below is my ROCK network setup. Any recommendation for a fix?
Would you not need to set ETH1 to the same subnet as ETH2? Currently it’s set via DHCP but not finding a DHCP server has self-assigned and IP.
Maybe try setting up ETH1 statically so that it has an IP address in the same subnet at ETH2 with the same gateway too.
Please draw your network diagram and explain what your goal is. I can help you get there once I understand intentions.
1.There is need for dns on the second interface
2. You can not set the gateway on second interface
3. Router should be plugged into Intel port, and ethernet1 set for dhcp
4. Private network on USB (ethernet2) should set static IP on subnet for private hosts, no dhcp.
Setting gateway will route your internet traffic to 10.10.10.1, which I’m guessing doesn’t exist
I tried this. I can ping the ip but cannot get to the ROCK admin screen. It hangs up.
Edit: I take this back. I can see the IP using IP scanners but I cannot ping.
I think the WebUI only listens to request on specific interfaces? (Not sure about this)
IE: wlan and eth
Yes, I had it set to google dns (8.8.8.8)
I had the diagram below. It is currently set to router IP.
Can we have the ethernet Intel port plugged to the music server to avoid USB-to-LAN translation?
Yes, this is what it was setup.
The goal is to keep the NUC Roon Server closer to the music server and avoid the router and switch in between. I get better SQ this way***.
*** To the skeptics, pls create another thread 
Can you set static IP on your music server? You have an issue that your music server to nuc connecttion has no dhcp server… The nuc is forwarding but does not act as a dhcp server. You should set static IP everywhere
The music server is pulling ip from a DHCP server. It cannot be set as static ip at the moment (SOtM sMS-200). This is another story. I will bring it up with SOtM.
In the previous Linux Arch setup, the ethernet interfaces are bridged something like this:
Description="Bridge Connection" Interface=br0 Connection=bridge BindsToInterfaces=(enp0s20f0u3 eno1) IP=static Address=('10.10.10.190/24') Gateway=('10.10.10.1') DNS=('8.8.8.8' '8.8.4.4') SkipNoCarrier=yes
Is there any way to manually override the setup? I can see the network settings in ROCK located in \ROCK\Data\MachineSettings\network.
I think the problem at hand is that ROCK will not deliver you a DHCP address – it does not run a DHCP server.
The br0 thing you are doing actually is completely counter to the entire idea you are trying to protect against… the br0 bridger makes EVERY packet on one side end up on the other side, and vice versa.
My understanding was that you wanted to protect against all traffic/noise on one side making it into the other side.
Assuming you are ok with the fact that the NUC itself is not good at isolating EMI, the best way to do that is with 2 subnets the way I’m describing, but you need to be able to setup your SOTM device to have a static ip.
Message noted. I already invited SOtM to the discussion.
ok cool, let’s see what they say… it’s very strange to have a system that can’t have a static ip. maybe you have old firmware or they are working on it…
I was able to set static IP for SMS-200 in my router settings.
That sounds more like an IP reservation: handing out the same IP address to the SMS-200 every time, while your router is still doing DHCP. In this case, there is no DHCP server, so the IP needs to be set manually on the device.
Edit: To fast to reply… 
I wanted to do the same thing, but could get no answers other than interesting discussions about switches and cables and the lack of need to do this. I didn’t care about ROCK, just the Roon core running under Windows.
I do not endorse this setup because I’m not confident it will have a positive benefit on SQ, but here is the proper way to do what you want:
plug your NUC into the router via ethernet and just make that all work properly with DHCP – get everything working with NUC/ROCK/Roon the everything normal.
plug your ethernet adapter into the NUC, and connect that via an ethernet cable directly to the device you’d like to isolate (usually a network audio renderer).
on the NUC’s second ethernet, setup static IP set like this:
ip: 5.1.1.1
netmask: 255.255.255.0
gateway: nothing
dns: nothing
on the isolated device (the audio renderer), setup static IP like this:
ip: 5.1.1.2
netmask: 255.255.255.0
gateway: nothing
dns: nothing
This setup is better than the br0 setup because you aren’t actually linking the 2 networks – in fact, your renderer can’t even talk to the internet in the above setup, nor can it talk to your iPad, or anything else on the network EXCEPT RoonServer on the NUC. Complete IP traffic isolation.
Is there any sonic benefit in creating a virtual bridge of 2 physical Ethernet connections on the Roon Core server? I’m considering using my Mac’s Ethernet directly wired to my Roon ready device while another (Thunderbolt/Ethernet dongle) is connected to my switch (it’s wired to my Eero WAP). I know it will work, but I’m interested in if there is any benefit whatsoever in doing so.
The theoretical advantage of a bridging setup is to isolate the endpoint from electrical interference. Since the NUC in a setup like this is the middle man between two regular network segments, that is not achieved here.
Contrary to what some believe or claim to hear, there’s no poetry in networking.
Plenty of clouds though, certainly in diagrams when I did networking in my day job, retired now 
Russ
Reason I ask is from the following:
Specifically:
"yet Mark Jenkins, owner and developer of the Antipodes line of music servers, had this to say about his latest generation Roon Ready DX music server. This excerpt is taken from John Darko’s review of this latest generation DX fserver:
"A third way to plumb Roon inside the DX is to have Roon Core talk to Roon Ready directly. Think of this scenario as Roon playing out the server-client model not on a LAN but inside a single computer.
Jenkins clarifies: “They [Roon Core and Roon Ready] talk using RAAT but when they are in the same device they do not need to use the not-so-good comms layers that sit underneath RAAT when the two apps talk across a network.”
This appears to be more about software