[Dnsmasq-discuss] Network booting with stateful IPv6 addressing

Derek Higgins derekh at redhat.com
Tue Feb 28 17:10:20 GMT 2017


On 28 February 2017 at 16:43, Simon Kelley <simon at thekelleys.org.uk> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Could you post (or send to me) you complete dnsmasq configuration. I'd

Here you go
http://paste.openstack.org/show/600808/

> expect, if the IP address associated with the MAC address is in use,
> for dnsmasq to log that and use a dynamically allocated address instead.

Looking at it now, the addition of the static keyword in dhcp-range
would be preventing this happening

>
> Why not nail the IP address using the client-id of the final OS
> booted, rather thna using MAC addresses?

I've been trying to get this to work within the constraints of how
openstack neutron starts dnsmasq, when neutron starts a new instance
it doesn't know (if I understand things correctly) what the client-id
will be, so MAC would be the only way it can associate a particular VM
to a IP address.

>
>
> Cheers,
>
> Simon.
>
>
> On 28/02/17 10:07, Derek Higgins wrote:
>> On 27 February 2017 at 21:51, Simon Kelley
>> <simon at thekelleys.org.uk> wrote: I'm slightly confused as to the
>> problem here. The identity of a lease if defined by the Client-ID
>> and IAID, if those change then dnsmasq will allocate a new address.
>> That means that your boot process will go through three different
>> addresses, but should end up with a usable and stable address. It's
>> not as if there is a shortage of IPv6 addresses, you can afford a
>> couple of disposable addresses that only get used during the boot.
>>
>> What have I missed?
>>
>>> IPs are being allocated to the MAC addresses in question via a
>>> hostfile (see below), so I guess dnsmasq is attempting to
>>> allocate the same IP address mutiple times, as its the same MAC
>>> but can't because of the changing IDs.
>>
>>> This is dnsmasq as configured be openstack newtron
>>
>>> bash-4.2$ cat
>>> /var/lib/neutron/dhcp/5cf3b57b-72a3-4044-9528-1f5019e21826/host
>>> fa:16:3e:59:ef:60,host-fc00-101--2,[fc00:101::2]
>>> fa:16:3e:d8:9e:dd,host-fc00-101--3,[fc00:101::3]
>>> fa:16:3e:d2:03:61,host-fc00-101--8,[fc00:101::8],set:ccbc492d-7b5d-4f
> 9a-891c-92d66828f6dd
>>>
>>>
> fa:16:3e:69:89:d5,host-fc00-101--b,[fc00:101::b],set:ea1e2384-7ed7-4956-
> bae0-d653c86c840c
>>
>>
>>
>> Cheers,
>>
>> Simon.
>>
>>
>>
>> On 27/02/17 16:04, Derek Higgins wrote:
>>>>> I've recently been trying to use dnsmasq IPv6 to network
>>>>> boot, after a number of hurdles the last problem I've been
>>>>> having is that during the boot process (after dnsmasq
>>>>> initially hands out an IP address as part of PXE boot), it
>>>>> starts responding with "no addresses available".
>>>>>
>>>>> The problem I'm hitting is that the IAID and the ClientID in
>>>>> the dhcp request changes during the process, - the IAID being
>>>>> used in PXE generated by the OVMF UEFI firmware is a function
>>>>> including a time based seed[1] - this chain loads(in my case)
>>>>> to an iPXE image that is using a crc of the mac address to
>>>>> generate the IAID[2], - dhclient on the OS then uses the last
>>>>> 4 octets of the MAC address for the IAID[3]
>>>>>
>>>>> I have similar problems with ClientID but I havn't looked
>>>>> into them in as much detail
>>>>>
>>>>> check_address in dnsmasq/src/rfc3315.c is asserting that the
>>>>> ID's can't change, and the only way I've gotten the boot
>>>>> process to work locally is to comment out the checks in
>>>>> check_address
>>>>>
>>>>> As best I can see RFC 3315 does say that the IAID MUST
>>>>> remain consistent across restarts of the DHCP client, but
>>>>> then recognizes that "There may be no way for a client to
>>>>> maintain consistency of the IAIDs if it does not have
>>>>> non-volatile storage and the client's hardware configuration
>>>>> changes"
>>>>>
>>>>> Is there a way to allow these IDs to change? and if not
>>>>> should this check be in dnsmasq? or would a patch to
>>>>> optionally disable the check be acceptable?
>>>>>
>>>>> thanks, Derek.
>>>>>
>>>>>
>>>>> [1] -
>>>>> https://github.com/tianocore/edk2/blob/418373a1cd97abc0c0e3557f7a00
> 105
>>
>>>>>
> 291829e6f/MdeModulePkg/Library/DxeNetLib/DxeNetLib.c#L866
>>>>>
>>>>>
>> [2] -
>> https://github.com/qemu/ipxe/blob/c34d151/src/net/udp/dhcpv6.c#L97
>> 2
>>>>> [3] -
>>>>> https://source.isc.org/cgi-bin/gitweb.cgi?p=dhcp.git;a=blob;f=clien
> t/d
>>
>>>>>
> hc6.c;h=be604ac988a983b2829f76fe2bff6a5f036d8019;hb=HEAD#l1716
>>>>>
>>>>> _______________________________________________
>>>>> Dnsmasq-discuss mailing list
>>>>> Dnsmasq-discuss at lists.thekelleys.org.uk
>>>>> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>>>>>
>>>
>>>
>>>>>
> _______________________________________________
>>> Dnsmasq-discuss mailing list
>>> Dnsmasq-discuss at lists.thekelleys.org.uk
>>> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.22 (GNU/Linux)
>
> iQIcBAEBCAAGBQJYtaiXAAoJEBXN2mrhkTWiYIUP/RUa5YJQN44BI7BkwsGnwsYi
> SdeE27igfC9MVjGUcN2MgIfpqkucNX8QkG69axsaaeA6vK9ARDr+qo8myUFymfH3
> XBdwFOfxCBWWUvyocyrGgQi+JLeMwNcNal4TRLMGp2s7xXrqpy7FPhpLYgVfGnC0
> 5326U+lVBHqQ8z4JP/Hyl9COvWmhNTTzG6XmZTumoY7dcXqMGgDwezWp3qyQ8oSV
> F6FrjbN56v7Hf6QphyYmHupjN8HTnjIAl0jWrxDtYvh1YUejlZnYN1c5kpfuSzsB
> XCfSTJVwgK/ld12ysSwYAjyPtrQySjxJBvXlysVTC06NQret8wK/esz9l2UCmA3X
> 5STa8eQ5biSyVtFcmbl+uLUP4taztc6NihFQY3DTVUq37ZoNqHK47nmOY2ZsU0wm
> Xs46Gvh9bNjSVpT41lTCLg0TnLqHcqZ9cENE3cTflkIC2TumRLTqEelRT/TptxRo
> iKH97kjblK/x+DGiWor9Yyu4fl28xpJoZDGuNe2oPN9ewF5+blitpRu3Q135tbf1
> b4vseR3hDvwxN2SEyeeZn5xk2bFjZ8GNlNrpLQF2rt5gu2l0F3bzU6zX/EcGc2OG
> Y9pzs0IYk27E22nkl1SgNU1GB6jUOtDxUz8Y7celEjm9jM1JoDNlumz+tJ1ZVF0y
> zGdG+wRErpJjIk70yUvA
> =o5bq
> -----END PGP SIGNATURE-----



More information about the Dnsmasq-discuss mailing list