[Dnsmasq-discuss] Dynamic-range clients don't get the same IP address when rebooted

[John Groves (jgroves)]

I'm a long-time dnsmasq user, but first-time poster. I can't imagine that this hasn't been discussed before, but I wasn't able to come up with search terms to find it.

This arises because we are creating and destroying VMs like crazy for automated software testing. The VMs are using dynamic-range addresses, and every time a VM is rebooted it gets a new address, even if there is a valid existing lease. And we see leases for the same mac address accumulating in the leases file, like this:

1466722310 52:54:00:51:e7:ad 10.114.5.186 localhost ff:00:51:e7:ad:00:01:00:01:1e:fe:ec:44:52:54:00:51:e7:ad
1466722212 52:54:00:51:e7:ad 10.114.5.185 * ff:00:51:e7:ad:00:01:00:01:1e:fe:eb:e2:52:54:00:51:e7:ad
1466719093 52:54:00:51:e7:ad 10.114.5.184 * ff:00:51:e7:ad:00:01:00:01:1e:fe:df:b3:52:54:00:51:e7:ad
1466718818 52:54:00:6f:8c:2a 10.114.5.227 * ff:00:6f:8c:2a:00:01:00:01:1e:fe:de:9f:52:54:00:6f:8c:2a
1466715993 52:54:00:4a:54:e7 10.114.5.179 * ff:00:4a:54:e7:00:01:00:01:1e:fe:d3:96:52:54:00:4a:54:e7

Is there a way to coax dnsmasq to give out an address matching the still-valid lease, if any?

FYI the VMs are mostly Fedora 2[234] and RHEL7

The changing addresses are a challenge for our test automation...

Thanks,
John Groves

[Simon Kelley]

Post by John Groves (jgroves)
I'm a long-time dnsmasq user, but first-time poster. I can't
imagine that this hasn't been discussed before, but I wasn't able
to come up with search terms to find it.
This arises because we are creating and destroying VMs like crazy
for automated software testing. The VMs are using dynamic-range
addresses, and every time a VM is rebooted it gets a new address,
even if there is a valid existing lease. And we see leases for the
1466722310 52:54:00:51:e7:ad 10.114.5.186 localhost
ff:00:51:e7:ad:00:01:00:01:1e:fe:ec:44:52:54:00:51:e7:ad 1466722212
52:54:00:51:e7:ad 10.114.5.185 *
ff:00:51:e7:ad:00:01:00:01:1e:fe:eb:e2:52:54:00:51:e7:ad 1466719093
52:54:00:51:e7:ad 10.114.5.184 *
ff:00:51:e7:ad:00:01:00:01:1e:fe:df:b3:52:54:00:51:e7:ad 1466718818
52:54:00:6f:8c:2a 10.114.5.227 *
ff:00:6f:8c:2a:00:01:00:01:1e:fe:de:9f:52:54:00:6f:8c:2a 1466715993
52:54:00:4a:54:e7 10.114.5.179 *
ff:00:4a:54:e7:00:01:00:01:1e:fe:d3:96:52:54:00:4a:54:e7
Is there a way to coax dnsmasq to give out an address matching the
still-valid lease, if any?
FYI the VMs are mostly Fedora 2[234] and RHEL7
The changing addresses are a challenge for our test automation...
Thanks, John Groves

If the DHCP provides a client-id, that's used to identify the client
in preference to the MAC address. The client-id is the last field on
each line of the lease-file, and we can see the client-ids for each
lease associated with a single MAC address are different in a couple
of bytes. These bytes are probably generated from the system time.

To fix this, build your VMs to not provide a client-id, or one
completely determined by the MAC address. You can also configure
dnsmasq to ignore the client-id with something like


dhcp-host=52:54:00:*:*:*,id:*

Cheers,

Simon.

[John Groves (jgroves)]

Many thanks Simon! I automated setting the client-id to the mac address and it's doing "the right thing"

Cheers,
John

-----Original Message-----
From: Dnsmasq-discuss [mailto:dnsmasq-discuss-***@thekelleys.org.uk] On Behalf Of Simon Kelley
Sent: Thursday, June 23, 2016 4:47 PM
To: dnsmasq-***@thekelleys.org.uk
Subject: Re: [Dnsmasq-discuss] Dynamic-range clients don't get the same IP address when rebooted

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Post by John Groves (jgroves)
I'm a long-time dnsmasq user, but first-time poster. I can't imagine
that this hasn't been discussed before, but I wasn't able to come up
with search terms to find it.
This arises because we are creating and destroying VMs like crazy for
automated software testing. The VMs are using dynamic-range
addresses, and every time a VM is rebooted it gets a new address, even
if there is a valid existing lease. And we see leases for the same
1466722310 52:54:00:51:e7:ad 10.114.5.186 localhost
ff:00:51:e7:ad:00:01:00:01:1e:fe:ec:44:52:54:00:51:e7:ad 1466722212
52:54:00:51:e7:ad 10.114.5.185 *
ff:00:51:e7:ad:00:01:00:01:1e:fe:eb:e2:52:54:00:51:e7:ad 1466719093
52:54:00:51:e7:ad 10.114.5.184 *
ff:00:51:e7:ad:00:01:00:01:1e:fe:df:b3:52:54:00:51:e7:ad 1466718818
52:54:00:6f:8c:2a 10.114.5.227 *
ff:00:6f:8c:2a:00:01:00:01:1e:fe:de:9f:52:54:00:6f:8c:2a 1466715993
52:54:00:4a:54:e7 10.114.5.179 *
ff:00:4a:54:e7:00:01:00:01:1e:fe:d3:96:52:54:00:4a:54:e7
Is there a way to coax dnsmasq to give out an address matching the
still-valid lease, if any?
FYI the VMs are mostly Fedora 2[234] and RHEL7
The changing addresses are a challenge for our test automation...
Thanks, John Groves

If the DHCP provides a client-id, that's used to identify the client in preference to the MAC address. The client-id is the last field on each line of the lease-file, and we can see the client-ids for each lease associated with a single MAC address are different in a couple of bytes. These bytes are probably generated from the system time.

To fix this, build your VMs to not provide a client-id, or one completely determined by the MAC address. You can also configure dnsmasq to ignore the client-id with something like


dhcp-host=52:54:00:*:*:*,id:*

Cheers,

Simon.