DHCP Pool exhausted - but not really exhausted - bug ?

[silviub]

Hello,

I have a DHCP server set on ether1, with a pool of 7 IP addresses:

/ip dhcp-server
add address-pool=pool0 interface=ether1 lease-time=1d name=dhcp-k8s-test

Pool0 looks like this:

/ip pool
add name=pool0 ranges=192.168.71.141-192.168.71.147

This means that IPs from .141 to .147 should be assigned:

141, 142, 143, 144, 145, 146, 147

: 7 IPs.
My leases look like:

/ip dhcp-server lease
add address=192.168.71.141 client-id=ff:2b:94:34:c1:0:2:0:0:ab:11:b8:2b:19:d3:51:43:1c:40 mac-address=00:50:56:AA:E1:FC server=dhcp-k8s-test
add address=192.168.71.142 client-id=ff:2b:94:34:c1:0:2:0:0:ab:11:51:41:4c:64:a1:84:3:b9 mac-address=00:50:56:AA:B2:90 server=dhcp-k8s-test
add address=192.168.71.143 client-id=ff:2b:94:34:c1:0:2:0:0:ab:11:93:ca:38:6:ea:56:41:b3 mac-address=00:50:56:AA:AF:1D server=dhcp-k8s-test
add address=192.168.71.144 client-id=ff:2b:94:34:c1:0:2:0:0:ab:11:59:cd:a2:7f:92:e8:26:fb mac-address=00:50:56:AA:CE:95 server=dhcp-k8s-test
add address=192.168.71.145 client-id=ff:2b:94:34:c1:0:2:0:0:ab:11:e0:4f:ab:e:56:9a:ba:1c mac-address=00:50:56:AA:D6:C1 server=dhcp-k8s-test
add address=192.168.71.146 client-id=ff:2b:94:34:c1:0:2:0:0:ab:11:53:db:fe:ae:65:5f:7f:61 mac-address=00:50:56:AA:DB:46 server=dhcp-k8s-test

Why do I get the following errors:

/log/print
2025-05-20 08:56:06 dhcp,error dhcp-k8s-test: failed to give out IP address: pool <pool0> is empty
 2025-05-20 08:56:14 dhcp,error dhcp-k8s-test: failed to give out IP address: pool <pool0> is empty
 2025-05-20 08:56:26 dhcp,error dhcp-k8s-test: failed to give out IP address: pool <pool0> is empty
 2025-05-20 08:56:34 dhcp,error dhcp-k8s-test: failed to give out IP address: pool <pool0> is empty
 2025-05-20 08:56:41 dhcp,error dhcp-k8s-test: failed to give out IP address: pool <pool0> is empty
 2025-05-20 08:56:52 dhcp,error dhcp-k8s-test: failed to give out IP address: pool <pool0> is empty

I don’t have any dynamically assigned IPs, as it can be seen from the lease list. I only have 6 devices. Still, DHCP says that the pool is empty.
Also, if I go via WinBox to IP → Pool → Pool0, I can see

Total: 7
Used: 7

Where’s the 7th IP?

Thank you!

[lurker888]

Hello and welcome,

Your dhcp server lease list looks suspiciously like it was created with the “export” command. The export doesn’t contain dynamic entries - it is only meant to capture the actual configuration, not print the current state.

Try the following command:
/ip/dhcp-server/lease/print

I have a suspicion that a dynamic entry will be revealed. If this doesn’t help,
/ip/pool/used/print
should give you an account of where the addresses in the pool are allocated.

Assuming this is correct, in general it’s best to allocate a wider than strictly necessary ip pool, simply because the lease entries are only cleared (and the address returned to the pool) once the lease time expires. Add to this that many devices tend to use randomized MAC addresses, so it’s entirely possible to exhaust a pool that would seem otherwise fine. If you don’t have some specific reason for being stingy with addresses, allocate a larger than strictly necessary pool. Anyway, dynamic leases can be removed easily enough.

Or you might have found a bug

[silviub]

Hello and thank you for the reply!

You are right, I used export, but also used the UI and I can tell there’s no dynamic entry:

/ip/dhcp-server/lease/print 
Columns: ADDRESS, MAC-ADDRESS, HOST-NAME, SERVER, STATUS
# ADDRESS         MAC-ADDRESS        HOST-NAME              SERVER         STATU
0 192.168.71.142  00:50:56:AA:B2:90  cs-node-1              dhcp-k8s-test  bound
1 192.168.71.143  00:50:56:AA:AF:1D  cs-node-2              dhcp-k8s-test  bound
2 192.168.71.144  00:50:56:AA:CE:95  cs-node-3              dhcp-k8s-test  bound
3 192.168.71.145  00:50:56:AA:D6:C1  cs-agent-1             dhcp-k8s-test  bound
4 192.168.71.146  00:50:56:AA:DB:46  cs-agent-2             dhcp-k8s-test  bound
5 192.168.71.141  00:50:56:AA:E1:FC  php-session-sync-test  dhcp-k8s-test  bound

Indeed, the ip pool used command shows the used IPs (including the .147 IP), but since it’s not in the leases, shouldn’t it be free?

/ip/pool/used/print 
Columns: POOL, ADDRESS, OWNER, INFO
POOL   ADDRESS         OWNER  INFO             
pool0  192.168.71.141  DHCP   00:50:56:AA:E1:FC
pool0  192.168.71.142  DHCP   00:50:56:AA:B2:90
pool0  192.168.71.143  DHCP   00:50:56:AA:AF:1D
pool0  192.168.71.144  DHCP   00:50:56:AA:CE:95
pool0  192.168.71.145  DHCP   00:50:56:AA:D6:C1
pool0  192.168.71.146  DHCP   00:50:56:AA:DB:46
pool0  192.168.71.147  DHCP   00:50:56:AA:B2:90

I mean, that mac existed at some point, but it’s offline for days (lease time = 1d, while the machine is offline for 5-7 days already).

I know that it’s best to provide a larger pool but as the name of the DHCP server says, this is a test k8s cluster, and I just wanted a quick IP assignation, without having to SSH into the machines and set the IP manually, so I just started the machines and made the leases static.

Back to it, why is there an entry in the IP Pool but not in DHCP Leases?

[NathanA]

As lurker888 says, can’t speak to whether there’s a bug or not unless we can see the pool ‘used’ list, and a proper ‘print’ from the leases instead of an ‘export’. But aside from that, you don’t need for static leases to fall within a pool. In fact, if you intend for all of your leases to be static, you don’t even need a pool at all! It’s clear that 100% static leases isn’t your goal, but you can certainly move the 6 static leases that you do have outside of the range covered by your pool.

EDIT: I see your latest response and mine happened simultaneously, heh. One thing I’m noticing is that one of the MACs appears twice, the one ending in 90 that occupies both .142 and .147. I’m wondering if it is possible that it was originally allocated .147, then you converted that dynamic allocation into a static one, and renumbered it to .142 during or afterward? If so, agreed, that should have freed .147. Perhaps the bug, though, is triggered by converting a dynamic entry to static while also changing it to a different address that is also covered by the pool.

[silviub]

As lurker888 says, can’t speak to whether there’s a bug or not unless we can see the pool ‘used’ list, and a proper ‘print’ from the leases instead of an ‘export’. But aside from that, you don’t need for static leases to fall within a pool. In fact, if you intend for all of your leases to be static, you don’t even need a pool at all! It’s clear that 100% static leases isn’t your goal, but you can certainly move the 6 static leases that you do have outside of the range covered by your pool.

See above
As for the leases, since I’m lazy, and this is a test, I started the VMs, the leases were created and just set them as static.

The question still stands: why is the IP used in IP Pools, but not in DHCP (as a lease)?

From my point of view, it HAS to be a lease in order to have it marked as used, unless I’m missing something. Am I?

[NathanA]

See above

LOL, I just edited my post above.

We are too fast for each other, heh.

[silviub]

See above

LOL, I just edited my post above.

We are too fast for each other, heh.

I love this forum!
And yes, you are right, the assignment was dynamic initially, but I don’t remember changing the IP (might have though). So, a bug then? Converting a dynamic lease into a static one, and changing the assigned IP doesn’t free the IP Pool IP that was originally assigned? If so, I’ll open a bug on the bug tracker.

[lurker888]

I love the forum too.

But to the point. It’s a strange behavior for sure. Maybe it really is a bug.

I did a quick test both with converting to static and adding a new static entry with the same mac. I couldn’t reproduce the behavior. Maybe I didn’t do the exact steps that I would assume you took or it may be due to the version I’m running (7.19beta6) and was fixed in the interim.

Anyway, an interesting point for sure. And actually I’m not totally certain what the proper behavior would be. (Having an address occupied for several days is probably not, though having the address reserved for lease-time would actually make some sense.)

Try to create a reproduceable test case.

[NathanA]

Try to create a reproduceable test case.

^^^^ This.

It’s a waste of time to file a bug that you cannot figure out the exact steps to reproduce.

Heck, I file bugs that I painstakingly take hours to compose, with complete minimum viable configs, that are 100% reproducible, and I’m STILL told by support they can’t reproduce.

It is clear that the behavior described here is not normal. It’s also not exactly clear how to get there from here. If all of the leases were to be purged, would it happen again?

How about, if you were to reboot the router while it’s in this condition, does that phantom used address in the pool get freed up?

[silviub]

Try to create a reproduceable test case.

^^^^ This.

It’s a waste of time to file a bug that you cannot figure out the exact steps to reproduce.

Heck, I file bugs that I painstakingly take hours to compose, with complete minimum viable configs, that are 100% reproducible, and I’m STILL told by support they can’t reproduce.

It is clear that the behavior described here is not normal. It’s also not exactly clear how to get there from here. If all of the leases were to be purged, would it happen again?

How about, if you were to reboot the router while it’s in this condition, does that phantom used address in the pool get freed up?

I’m trying to reproduce it. Rebooting the router didn’t clean the doubled MAC from the used IPs but you know what did? Removing a totally unrelated lease (the 192.168.71.141 lease). I ran

/ip/dhcp-server/lease/remove 6

and the duplicated MAC disappeared from the Used IPs.

Hopefully I’ll be able to replicate it, and then I’ll open a bug. Thank you, at least I know I’m not crazy )