yahoo-eng-team team mailing list archive

[Harald Jensås <hjensas@xxxxxxxxxx>]

Public bug reported:

Neuton currently only support configuring the DHCP agent with static
/fixed-address allocations. The DHCP client id (the client MAC address
in neutron's case) is mapped to a specific IP address in the dhcp server
configuration. No range of addresses are made available for clients
without a pre-allocated fixed-address.

When network booting on IPv6 this become an issue, the DHCPv6
specification which mandetes use of the DHCP Unique Identifier (DUID)
and Identity Association Identifier (IAID) to identify a lease. When
network booting, an instance will move trough a minimum of two DHCP
clients, and these rareley end up using identical DUID's and IAID's.

The combination of static/fixed-address allocations in the DHCP server
and the changeing DUID/IAID of the clients causes the second DHCP client
request to get a ``no address available`` reply from the server, and
thus the network boot process errors.

NOTE:
  In some cases just the UEFI PXE6 end up doing two cycles
  of DHCPv6 S.A.R.R (Solicit, Advertise, Request, Reply)
  with different IAID's. Because some UEFI firwmare use's a
  non-RFC compliant random generator for the IAID see bug:
    https://bugzilla.tianocore.org/show_bug.cgi?id=1518.

  While this is a bug in UEFI firmware, it's a common enough
  implementation that is used by various hardware vendors
  that it makes sense to workaround the issue where possible.


This RFE is for adding the possibility to make a subnet with dynamic
allocation pool(s).

This would solve the network booting issue with changing IAID's
described above. A new lease with a new address will be offered during
each step of network booting.

For example an instance deployment via Openstack Baremetal service
(ironic) would typically include three DHCP clients during provisioning:
UEFI firmware, iPXE, ironic-python-agent ramdisk. So a toatal of 3
leases would be consumed to complete the provisioning.

If this RFE is implemented, the dhcp server (dnsmasq) would configure
the dhcp-range for a dynamic subnet (or dynamic allocation pool of a
subnet) without the ``mode`` set to ``static``. To ensure that the dhcp
server only provide a dynamic allocation for the desired ports the
``ignore`` option is used in a ``dhcp-host`` entry with a wildcard ``*``
host (``dhcp-host="*",ignore``). Ports that require dynamic addressing
would get a ``dhcp-host`` entry with ``dhcp-host=<MAC_ADDRESS>``
(whithout the ``ignore``) so that these specific ports get addresses
from the dynamic allocation pool.

** Affects: neutron
     Importance: Undecided
         Status: New


** Tags: rfe

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1855854

Title:
  [RFE] Dynamic DHCP allocation pool

Status in neutron:
  New

Bug description:
  Neuton currently only support configuring the DHCP agent with static
  /fixed-address allocations. The DHCP client id (the client MAC address
  in neutron's case) is mapped to a specific IP address in the dhcp
  server configuration. No range of addresses are made available for
  clients without a pre-allocated fixed-address.

  When network booting on IPv6 this become an issue, the DHCPv6
  specification which mandetes use of the DHCP Unique Identifier (DUID)
  and Identity Association Identifier (IAID) to identify a lease. When
  network booting, an instance will move trough a minimum of two DHCP
  clients, and these rareley end up using identical DUID's and IAID's.

  The combination of static/fixed-address allocations in the DHCP server
  and the changeing DUID/IAID of the clients causes the second DHCP
  client request to get a ``no address available`` reply from the
  server, and thus the network boot process errors.

  NOTE:
    In some cases just the UEFI PXE6 end up doing two cycles
    of DHCPv6 S.A.R.R (Solicit, Advertise, Request, Reply)
    with different IAID's. Because some UEFI firwmare use's a
    non-RFC compliant random generator for the IAID see bug:
      https://bugzilla.tianocore.org/show_bug.cgi?id=1518.

    While this is a bug in UEFI firmware, it's a common enough
    implementation that is used by various hardware vendors
    that it makes sense to workaround the issue where possible.


  This RFE is for adding the possibility to make a subnet with dynamic
  allocation pool(s).

  This would solve the network booting issue with changing IAID's
  described above. A new lease with a new address will be offered during
  each step of network booting.

  For example an instance deployment via Openstack Baremetal service
  (ironic) would typically include three DHCP clients during
  provisioning: UEFI firmware, iPXE, ironic-python-agent ramdisk. So a
  toatal of 3 leases would be consumed to complete the provisioning.

  If this RFE is implemented, the dhcp server (dnsmasq) would configure
  the dhcp-range for a dynamic subnet (or dynamic allocation pool of a
  subnet) without the ``mode`` set to ``static``. To ensure that the
  dhcp server only provide a dynamic allocation for the desired ports
  the ``ignore`` option is used in a ``dhcp-host`` entry with a wildcard
  ``*`` host (``dhcp-host="*",ignore``). Ports that require dynamic
  addressing would get a ``dhcp-host`` entry with ``dhcp-
  host=<MAC_ADDRESS>`` (whithout the ``ignore``) so that these specific
  ports get addresses from the dynamic allocation pool.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1855854/+subscriptions