On 28 February 2017 at 16:43, Simon Kelley <si...@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 >> <si...@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@lists.thekelleys.org.uk >>>>> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss >>>>> >>> >>> >>>>> > _______________________________________________ >>> Dnsmasq-discuss mailing list >>> Dnsmasq-discuss@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----- _______________________________________________ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
