I’ve got a pi-hole and some other services running on a physical Raspberry Pi connected via ether3, assigned an IP address via the “defconf” DHCP server and in the “defconf” bridge. Pi-hole needs a “static” IP address so for it, and basically everything else on the network, I did the clicky-clicky in Webfig for “Make Static” under /IP/DHCP Server/Leases. (so it’s now “Status : bound”) Cool!
Then I created a container for running a second pi-hole, with a VETH in the “defconf” bridge, so it’s assigned the .2 address in my network, outside the Pool for “defconf” DHCP — so that one’s never gonna change. Cool!
However, now I want to assign both those IP addresses to each client’s DNS via the DHCP options — and while the container’s IP is very memorable, I still have a weirdo .244 address assigned to that Raspberry Pi on ether3, and I’d like to change it to something easier, even though I’ll be assigning it via DHCP and mostly never see it. <cough OCD much? sure, but I also think I have some legit reasons I won’t go into here> Regardless, it’ll just make me happier if it’s .4 or something like that.
Yes, it’s awkward, but I believe it’s on purpose. If they let you assign an arbitrary IP as part of making the reservation static, that wouldn’t instantly change the client’s IP. Worse, there would then be a mismatch between the lease time on client and server; the server would have forgotten that it assigned .244 or whatever to the client, yet the client would go on believing it had N hours left on its lease.
In small LANs, this confusion devolves to the trivial, but on a big LAN, it might cause serious confusion and conflict.
Personally, when I need to do this, I give the RouterOS CLI command to assign the MAC a new static IP rather than go through the GUI, then do whatever DHCP release+renew procedure the client OS has. That ensures both ends understand the new rules of the game, avoiding the confusion.
I can do a lot of these with copy-paste hackery faster than GUI clicky-pokery. With practice, you can, too.
It’s not any more awkward to do it vua GUI than via CLI … open that static lease for rPI (which has .244 address set) and change the address to whatever you want it to be. The address in static lease can be outside of pool of DHCP addresses, it only has to fall into range (implicitly) defined under dchp/network section (or else those settings won’t apply making lease invalid).
Just make sure you don’t mess with client ID and MAC fields or else DHCP server won’t associate the lease with rPI any more.
In both cases (GUI and CLI) it’ll take some time before rPI will end with the new address because DHCP client has to request the change (and will get the new address during that handshake), DHCP server will not push changes. If you want any deterministicity in the process (i.e. you want the address on rPI to change “now”), then there are different ways, but the most deterministic one (and possibly with least service disruption) is to change the DHCP lease settings and then disconnect network cable in rPI for a few seconds … rPI will notice netwotk down and upon re-connection it’ll perform DHCP handshake.
Webfig has a bunch of nanny controls to prevent you from changing stuff when you probably shouldn’t. That’s good! I was always slightly afraid of making certain changes because I was afraid if possible lock-out scenarios. So this makes me feel a bit better.
After reading the previous replies and experimenting a little I was pretty sure I was going to be posting again about how it didn’t work, and the fault would have been my own because I left out some key information. However, after just biting the bullet and making the changes (via WebFig) … it all seems to be working. All I really needed to do was bang on the pi’s ‘dhcpcd’ while I was logged into the console. (because obviously when I released the lease client-side, I lost the network connection) Then I did a quick reboot to make sure. It’s behaving splendidly.
But this has created confusion from the detail I didn’t initially disclose — that the IP address I want to assign is outside of the range of the DHCP pool of addresses. But apparently when I “Make Static” the lease and then manually change its IP address that doesn’t matter. Great‽ I may try assigning some other more arbitrary addresses just to test the limits of its operation.
As I wrote in my previous post: you can set just any address in a static lease. The only constraint is that it has to have accompanying DHCP network definition.
E.g.: let’s say you have a pretty default LAN setup with DHCP pool range 192.168.88.100-192.168.88.200 and DHCP network definition with address=192.168.88.0/24 … then you can set e.g. 192.168.88.5 in static lease and DHCP server will include the settings from DHCP network setup. You can set 192.168.89.5 in static lease (and it will be sent out to matching client), but will lack the rest of settings, which are set in DHCP network setup (gateway, netmask, DNS server, etc.) making DHCP client slightly upset. But you can get pretty creative with different DHCP network settings (multiple of them, having different addresses set and carrying different other settings) combined with static leases. This way it’s possible to mimick different IP subnets using single ethernet broadcast domain (which implies use of single DHCP server). Or creating two groups of hosts in the same subnet but having different settings (e.g. different DNS servers).
As @mkx correctly explains that you pick something outside the pool…so .3 should fine in your case. But to this:
I suppose you can “try” and it may even allow you set whatever…
But importantly DHCP Server has a “Network” tab too. So the IP you use a static lease does NEED to be in one of those defined DHCP networks. DHCP server does allow “multihoming” (e.g. using multiple IP subnets on same interface/L2 segment), but to do this the subnets NEED to be added under /ip/dhcp-server/network FIRST, to be able to use an IP address in a static lease.
Essentially the /ip/dhcp-server/network provides the values to return from DHCP. So to use an IP address in a static lease, it has to match one of those ranges to get the gateway/DNS/etc.
Funnily enough, that’s actually helped me understand a lot. (did I mention : I’m a relative newb in general networking nitty gritty — I have lots of experience, but in a very weird and narrow niche) First, that’s the “tab” where I needed to go to define the (now) two DNS servers for each client, which I was going to do anyway. But based on the comment above I looked at the rest of the settings in a different light.
The “Address” defined there (for the entire network) is 192.168.88.0/24 … so I’m guessing anything I try to assign outside of that won’t work, and in particular for DHCP it would be kind of nonsensical. (doing so would throw clients into a broadcast domain such that leases couldn’t be renewed by the original server? it would be like a one-time-use DHCP server) The configuration of the Pool for assigning dynamic addresses necessarily has to be a proper subset of that network space. Since I’ve carved out a pretty large swath of the network to NOT be assigned via that pool I’m free to use any of those other addresses statically. I think I was mistakenly considering the DHCP pool to be the defining characteristic of that entity when it’s definitely not.
Thanks for jostling my brain into the right place.