Static IP vs. Reserved IP in devices...?

Wondering if there is any advantage or disadvantage to either method.

  1. Define IP address at the device…
  • or -
  1. Assign a reserved IP for the device’s MAC address at the router.

I’ve been doing #2 only and it seems to ensure that my devices all adopt the correct address lease when firing up.

Any thoughts?

I guess it’s a matter of personal taste. In general I have a mix of both, depending on the type of device:

  1. Manual configuration for devices with screens and keyboards. This allows me to fix the address locally if I messed something up with the network.
  2. DHCP for devices where the IP itself is required to apply a different configuration. For example a Wifi-enabled Tasmota-switch. Setting a manual IP here (possibly along with a different Wifi + VLAN -> subnet) can become problematic if something isn’t working as expected.

I tend to prefer manual configuration over DHCP, just to be less dependent on a working DHCP daemon.

1 Like

The first things that come to mind:

  1. Define IP address at the device…

Apart from specific edge cases (rotating MAC address, network controllers…), very small networks, or networks without routers, I can’t see much benefits to this. Any changes to the network will require you to update each device, one by one. The risk for misconfigurations is high (typo in the IP, gateway, subnet mask, assigning the same IP to different devices, changing the subnet before updating all devices). Loosing network access to devices will most likely require you to connect directly and physically to them to fix the issue. On a network with a number of devices, this is long, tedious, painful.

The biggest drawback I can see to this method is that it doesn’t scale and it’s not suitable for the ever changing nature of a lot of networks.

The most interesting advantage I can see to this method is that devices might be able to talk to each other if/when the DHCP server goes down (ie, through a switch that is still up). But you might never notice the DHCP server went down if your devices don’t talk to the world beyond the router, which is a big minus.

The other advantage is to be able to quickly add a temporary device to a network [that you own of course :wink:]

  1. Assign a reserved IP for the device’s MAC address at the router.

I mostly see advantages to this solution:

  • Easier network planning (spreadsheet listing Networks, VLANs, SSIDs, IPs…),
  • Centralized management (vs connecting to each device one after the other),
  • Easier implementation and higher protection against misconfigurations,
  • Also, many devices won’t let you connect to them to configure a static IP address, so it needs to be done at the router.
  • Finally, this is, oh, so scalable and maintainable. Think of hundreds or thousands of devices being configured remotely by the network (for example by pushing a config file to the router that was generated by a script, how delightful :star_struck:)
  • Cherry on the cake, this can be done remotely, from outside the premises if the network is configured to support it.

That could be a downside though. I would assome the typical user here has a fairly standard router/modem combo from the ISP, or maybe something slightly better bought off the shelf. When this device gets replaced for whatever reason, the DHCP-configured devices will be a temporary problem that requires time to fix. Statically configured devices on the other hand will just keep on working.
And I doubt IPv6 (where I see DHCP as the only practical option) will see much adoption in private networks in the near future.

I’m using Ubiquiti Unifi as my network infrastructure except for my router, which is pfSense.

@arretx was there a specific use case that prompted the initial question?

Yes.

I was wondering if the MAC address for a given Proxmox VM was randomly assigned any time the host was re-booted, as that would cause a problem if the static IP was dependent upon that MAC address.

this question returns from time to time. I guess Internet it full of articles about it.

As rule of thumb:
static ip should be configured for devices for which it is crucial:

  • for example servers have it defined this way because nobody wants to lost them in case of dhcp failure. note that devices with ip leased from dhcp check for new lease in about half of lease time. if this procedure and subsequent attempts fail, device might fall back to its default address.
  • battery powered wifi devices, because dhcp communication extends connection time, draining more battery
  • devices which are expected to conmunicate to each other through intermediate network nodes. it makes possible them to work even if the rest of infrastructure is down.

it’s all about minimalization of dependentoes and therefore risk of outage. on the other side of coin is msnageability.
Someone might ask how many times I encountered dhcp (centeal server downtime). I can ask: how often you reorganize your home network to appreciate benefits of reserved addresses.
As you can see there is no one single answer. I have all my Shelly devices set to static ip. In case of need I can write script which change those settings using API exposed by those devices
you have decide on your own. :wink:

1 Like

I’m not familiar with Proxmox but from what I gathered it seems like you can manually assign a MAC address to a specific VM and it would persist accross host reboots.

My HA installation is in a docker container. The container is exposed to the network via macvlan. At first I wondered: will the MAC address of the container change when it will be recreated? Not a VM, but I totally understand the dilemna… I adopted the mixed approach and set a fixed IP in the container configuration. The choice of method is a matter of use case and compromise :upside_down_face:

I use both; most routers have a soft or hard limit on how many devices you can register on the LAN so whenever possible, I hard code it into the device.

My current method is to change the assignable IP range on my router so all IPs I plan to reserve or hard code are not assignable (2 to 199), split up those into ranges of specific device types, and assign all my devices into those by type. It’s also a good way to watch for guests or intruders on my wifi; they will always show up as 200 or above. Yes, I do keep a spreadsheet.

When using hard coding, the first thing I have to do after getting a new router or a reset is to change the assignable IP range so devices with a hard IP are able to connect immediately, but that’s really the only disadvantage and is taken care of in about five seconds during initial setup. IP Reservation can a lot longer, and I usually do that after I’ve finalized all other needed router configurations, and every time you upgrade your router or need to reset, you gotta do it all again.

It does take a while to configure, but it’s worth the time and effort, and you only have to do it again when you upgrade or reset. I maybe reset every six months at most, but in between, all my devices have an IP that never changes. THat makes doing a lot of things in HA (and on my home server) including running webservers, using Plex, connecting remotely, or just not having to look up the IP address on the router because I know it or can just check my spreadsheet, etc. I’m honestly not sure how people how don’t use fixed addresses or reservations manage.

@arretx I have a similar setup as you do. Well, currently one Ubiquiti device and a bunch of old legacy ddwrt access points with pfSense driving all network functionality. Both @danielperna84 and @maxym covers the basis of both options. As stated, both options complement each other. As @maxym mentioned, things that needs to be up should not rely on dhcp. I have pfSense running in VM so all servers and core components are static. IoT devices are usually MAC reserved as I find it easier to add the MAC when deploying the device, then simply powering it on. I don’t have any IoT devices on my network which is considered core that needs to be up before pfSense.

Another recommendation is create separate VLANs (zones) on your network, with trusted and untrusted zones. This will increase the security of your network.

There’s already a lot of good advice here so I’ll just add that some cheaper routers have a low limit on the number of DHCP reservations (get a good quality router). My own router also flushes tables and reboots whenever I make a DHCP change.

If it was mentioned before, my apologies. Some of the add-ons for HA might complain if you don’t have a true static IP set for the HA server. I think AdGuard is one example. I’ve been using the latter method described by the OP (set by router) and haven’t had issues, but I don’t think I use any of the add-ons in question.