Re: [Dnsmasq-discuss] Network booting with stateful IPv6 addressing
On 01/03/17 15:27, Derek Higgins wrote: > On 28 February 2017 at 18:24, Simon Kelley wrote: > > > On 28/02/17 17:10, Derek Higgins wrote: On 28 February 2017 at 16:43, Simon Kelley wrote: 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 > > Indeed. That explains that effect. 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. > > Sigh. This has always been a problem, and it's got worse, not better, > in the move to IPv6. > > For DHCPv4, where MAC addresses are pretty much compulsory, there's a > hack where client is allowed to either present or not a client-id, as > long as the MAC address is identical. (It's not allowed to present two > different client-ids, however.) > > For DHCPv6, it's difficult to rely on the MAC address, since it's only > made available at all by using nasty ARP-snooping hacks. Plus the MAC > address to client-id function is less well defined. Then we have the > problem that provisioning systems know about MAC addresses, but not > client-ids. > > The only possible solution I can come up with is to add filtering of > dhcp-host lines by tag. You could thereby arrange that the dhcp-host > line only applied to the final OS boot, and the earlier steps could be > left to get dynamically allocated addresses. That would require a > way to set a tag on the final (OS) dhcp request, but that's almost > certainly possible; you're halfway there with the ipxe6 tag. > >> I'll take a look into getting this to work in the env I'm using. > >> I'd imagine this is a common enough case, is there a argument here to >> add a dnsmasq flag to allow the IDs to change? If so I'd be happy to >> work on a patch. > > Allowing the IDs to change is a bad idea, since in DHCPv6 they are the only thing that identifies a client. If you lease an address to a CLID/IAID combo, then you can't lease it to another CLID/IAID until that lease has expired. The same applies to DHCPv4, but in some cases, because MAC addresses are much more strongly associated with clients in DHCPv4 land, you can get away with it, as I explained. The solution I'm proposing is to allow dhcp-host to be conditional on a tag that can be set only when the final OS boots, so that the intermediate boot stages can dynamically allocated addresses and the leases for those just expire. The trick is to find a way of distinguishing the PXE/bootloader DHCP requests from the OS ones, using dhcp-match and/or tag-if to do the inspection and logic. As you have the test harness there, that would be a useful thing to look at. The patch to dnsmasq to allow dhcp-host to be conditional on a tag is trivial. Cheers, Simon. > > Cheers, > > Simon. > > > Cheers, Simon. On 28/02/17 10:07, Derek Higgins wrote: >>> On 27 February 2017 at 21:51, Simon Kelley >>> 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-495 > 6- > bae0-d653c86c840c >>> >>> >>> >>> Cheers, >>> >>>
Re: [Dnsmasq-discuss] Network booting with stateful IPv6 addressing
On 28 February 2017 at 18:24, Simon Kelley wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > > > On 28/02/17 17:10, Derek Higgins wrote: >> On 28 February 2017 at 16:43, Simon Kelley >> wrote: 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 > > Indeed. That explains that effect. >> >> >> 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. >> >> > > Sigh. This has always been a problem, and it's got worse, not better, > in the move to IPv6. > > For DHCPv4, where MAC addresses are pretty much compulsory, there's a > hack where client is allowed to either present or not a client-id, as > long as the MAC address is identical. (It's not allowed to present two > different client-ids, however.) > > For DHCPv6, it's difficult to rely on the MAC address, since it's only > made available at all by using nasty ARP-snooping hacks. Plus the MAC > address to client-id function is less well defined. Then we have the > problem that provisioning systems know about MAC addresses, but not > client-ids. > > The only possible solution I can come up with is to add filtering of > dhcp-host lines by tag. You could thereby arrange that the dhcp-host > line only applied to the final OS boot, and the earlier steps could be > left to get dynamically allocated addresses. That would require a > way to set a tag on the final (OS) dhcp request, but that's almost > certainly possible; you're halfway there with the ipxe6 tag. I'll take a look into getting this to work in the env I'm using. I'd imagine this is a common enough case, is there a argument here to add a dnsmasq flag to allow the IDs to change? If so I'd be happy to work on a patch. > > Cheers, > > Simon. > > > >> Cheers, >> >> Simon. >> >> >> On 28/02/17 10:07, Derek Higgins wrote: > On 27 February 2017 at 21:51, Simon Kelley > 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-495 > 6- >> >> > 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 on
Re: [Dnsmasq-discuss] Network booting with stateful IPv6 addressing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 28/02/17 17:10, Derek Higgins wrote: > On 28 February 2017 at 16:43, Simon Kelley > wrote: 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 Indeed. That explains that effect. > > > 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. > > Sigh. This has always been a problem, and it's got worse, not better, in the move to IPv6. For DHCPv4, where MAC addresses are pretty much compulsory, there's a hack where client is allowed to either present or not a client-id, as long as the MAC address is identical. (It's not allowed to present two different client-ids, however.) For DHCPv6, it's difficult to rely on the MAC address, since it's only made available at all by using nasty ARP-snooping hacks. Plus the MAC address to client-id function is less well defined. Then we have the problem that provisioning systems know about MAC addresses, but not client-ids. The only possible solution I can come up with is to add filtering of dhcp-host lines by tag. You could thereby arrange that the dhcp-host line only applied to the final OS boot, and the earlier steps could be left to get dynamically allocated addresses. That would require a way to set a tag on the final (OS) dhcp request, but that's almost certainly possible; you're halfway there with the ipxe6 tag. Cheers, Simon. > Cheers, > > Simon. > > > On 28/02/17 10:07, Derek Higgins wrote: On 27 February 2017 at 21:51, Simon Kelley 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-495 6- > > 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 st
Re: [Dnsmasq-discuss] Network booting with stateful IPv6 addressing
On 28 February 2017 at 16:43, Simon Kelley 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 >> 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 > XBdwFOfxCBWWUvyocyrGg
Re: [Dnsmasq-discuss] Network booting with stateful IPv6 addressing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Could you post (or send to me) you complete dnsmasq configuration. I'd 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. Why not nail the IP address using the client-id of the final OS booted, rather thna using MAC addresses? Cheers, Simon. On 28/02/17 10:07, Derek Higgins wrote: > On 27 February 2017 at 21:51, Simon Kelley > 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-
Re: [Dnsmasq-discuss] Network booting with stateful IPv6 addressing
On 27 February 2017 at 21:51, Simon Kelley wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > 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-4f9a-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/418373a1cd97abc0c0e3557f7a00105 > 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=client/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 >> > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.22 (GNU/Linux) > > iQIcBAEBCAAGBQJYtJ9GAAoJEBXN2mrhkTWiXAwP/RZ+BE+gchcHXwz/wsGmz2gV > QyHEop+9EZU2FPDBycp0bSBsPeM02Z5ZRfuVslqk/mPZke1WDFqp88Xo5m2wTi09 > SIPhk8P8ONAgYcxWy8SYUTPzYWFxTx6R7xyjZaM/gUbBYlzqvCf4KFNDrHsIw9eg > M+5M/pSvLHdA2ELAl1OaGgdC8UWgRIRKoBriSkcl17FwmT7UeLzWVB64NOxYxxGl > pxLjqZVOymfuY5XbjN6DMs431Z/sGIwsY8SBRWU8y1Sm++/Gb55JEYydu1+KXEyW > gx9yrdMH43D6uHp8g+o0C+xTWtoddJx93CwOHLeSRughe24f13Z3xsKbUQRycZRa > UJPKOHSmkO38e6tbGqAMDFtsmoXwXRBElYls32TcS1ai/YzSvkcapKYZh6oiX83Z > fo4+Iklyb87Dft5gj9TsBdr4A1C7Hf9W+A8FR8XL6V05/KT5Z9OS7UTH5vqGM+l/ > 1bYQsHk7rnNwGrSUyI+QJDLfhjibwwlYs0IeTPhUqexSwRXDiRd0uLH1ZhmLHBRm > 8T81sV4S7NErqp3daUdXJdK6GFSp7i8jDMHZujo9Wju9x7fGl2ROVW6oJqQX+lN2 > v05zFaXePJR+78gEKVEQP38QNDYnKct8dVHRvoSb+B6pjAWuTM2HgsF0y+x0phNv > JQQXY6kIaOIsjEDROC7q > =oMah > -END PGP SIGNATURE- > > ___ > 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
Re: [Dnsmasq-discuss] Network booting with stateful IPv6 addressing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 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? 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/418373a1cd97abc0c0e3557f7a00105 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=client/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 > -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBCAAGBQJYtJ9GAAoJEBXN2mrhkTWiXAwP/RZ+BE+gchcHXwz/wsGmz2gV QyHEop+9EZU2FPDBycp0bSBsPeM02Z5ZRfuVslqk/mPZke1WDFqp88Xo5m2wTi09 SIPhk8P8ONAgYcxWy8SYUTPzYWFxTx6R7xyjZaM/gUbBYlzqvCf4KFNDrHsIw9eg M+5M/pSvLHdA2ELAl1OaGgdC8UWgRIRKoBriSkcl17FwmT7UeLzWVB64NOxYxxGl pxLjqZVOymfuY5XbjN6DMs431Z/sGIwsY8SBRWU8y1Sm++/Gb55JEYydu1+KXEyW gx9yrdMH43D6uHp8g+o0C+xTWtoddJx93CwOHLeSRughe24f13Z3xsKbUQRycZRa UJPKOHSmkO38e6tbGqAMDFtsmoXwXRBElYls32TcS1ai/YzSvkcapKYZh6oiX83Z fo4+Iklyb87Dft5gj9TsBdr4A1C7Hf9W+A8FR8XL6V05/KT5Z9OS7UTH5vqGM+l/ 1bYQsHk7rnNwGrSUyI+QJDLfhjibwwlYs0IeTPhUqexSwRXDiRd0uLH1ZhmLHBRm 8T81sV4S7NErqp3daUdXJdK6GFSp7i8jDMHZujo9Wju9x7fGl2ROVW6oJqQX+lN2 v05zFaXePJR+78gEKVEQP38QNDYnKct8dVHRvoSb+B6pjAWuTM2HgsF0y+x0phNv JQQXY6kIaOIsjEDROC7q =oMah -END PGP SIGNATURE- ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
