Ip address discrepency

Sheldon, yes this is best practice for networking. Servers, NAS, printers, scanners, and anything that has IP dependencies should be static, and everything else DHCP. The router should have a DHCP reservation and I usually reserve 1-50 for a home network. I make an exception to the static or DHCP rule when I am first setting up a network or adding a group of devices to a network. In those cases, I use static for the new devices until I convince myself that the configuration is stable (again so that I can keep track of the locations and simplify the network configuration). The last thing I want to happen is an IP change during the shakedown period and static is stable. But I guess this is all personal and individual preference, using DHCP or static when done right is a matter of what one is comfortable with. I wonder if we old system engineers could help out the other members who are trying to set up networks or build Roon Cores? I would think it very intimidating.

Your methodology on static vs dynamic addresses is not wrong but it is old. I would not share this advice as “right” going forward. DHCP is used for a lot more than address assignment in networks and you lose that when you go static. Additionally, things get really messy if your network is static and you’ve come to a point where IPv6 needs to be deployed. Having robust assignment and discovery infrastructure makes that a lot easier. The “right” way, or goal, of any modern network is central management of workstations. That starts with address assignment. I can literally sit at my workstation and move endpoints from one VLAN to another. They take on a new address, dns server, time server, and DNS of that workstations hostname is updated. I can even push routes and SMTP servers for devices that use e-mail for notifications.

Anyway, as I said, what you have set-up is not wrong but it is a methodology that doesn’t fit within a “central management” philosophy. Of course, you need a robust DHCP server that lets you configure these additional options and a DNS server that can follow / track the updates. I just wanted to voice that no, actually, the way you have it set-up is not current best practice; it was a best practice. In fact, I’d even go as far to say that the “best practice” in static addressing is that only the DNS (or discovery) infrastructure should be static. Everything else can scale in / out dynamically. Even most of the “routers” and “firewalls” in modern networks are virtualized and have addresses assigned dynamically. It’s become a strange world.

A multinational with thousands of workstations has a need to push out images, and configure resources on the fly, Most of us have simple home networks, one router with an access point, or if lucky a mesh network. Many of us do not have the money or need to have DNS servers, email servers, enterprise-level managed switches, or even hardware firewalls. You are right in that the state of the art is well advanced from mom and pop networks. But, there are a lot of people out here with fewer resources who just want to hear good music with what they have. I’ll shut up now, and I apologize if I offended you.

1 Like

I’m betting that even now and increasingly into the future home user based firewalls will be increasingly popular and in the longer term absolutely needed for anyone with a home network.

1 Like

The point still stands above, that Roon live at an intersection of music and computers. Everybody is here because of the love of music, but not everybody is good at computer issues. So I would think that much of the support from Roon folks and here on the forum would be helping people get the networking side working well so Roon works well.

Sheldon

1 Like

You make good points. Ultimately, if it works its configured right. No offense taken here.

I configure my router’s DHCP server to reserve IP addresses corresponding to device MAC addresses. This is what I do with all my fixed devices, e.g., NAS, Roon Server, Roon endpoints, printer, etc, and it essentially simulates static IP addresses.