netplan does not allow dhcp client identifier type to be specified

Bug #1738998 reported by Russell Jones on 2017-12-19
50
This bug affects 6 people
Affects Status Importance Assigned to Milestone
netplan
High
Mathieu Trudel-Lapierre
nplan (Ubuntu)
Undecided
Unassigned
Xenial
Undecided
Unassigned
Artful
Undecided
Unassigned

Bug Description

[Impact]
Users of Ubuntu dealing with a DHCP server based on Windows Server, Solarwinds IPAM, or possibly other DHCP server products that do no support RFC 4361.

[Test case]
-- requires a Windows Server DHCP setup, or another product without support for client identifier DUIDs.

1) Configure a reservation for the device, using the device's MAC address.
2) Configure the device for DHCP:

network:
  version: 2
  renderer: networkd
  ethernets:
    eth0:
      dhcp4: yes
      dhcp-identifier: mac

3) Run 'netplan apply'
4) Verify that 'netplan apply' completes successfully, and that the expected IP address is received as part of the reservation. It may be required to clear the DHCP server's cache of DHCP requests/responses.

[Regression potential]
These DHCP behavior changes may lead to systems not receiving the same IP as they previously did on reservations from a DHCP server; the default is not changing from using DUIDs so unchanged configurations should not be affected at all, but changes to add the new feature will likely change the IP address returned to the client from the DHCP server. Additionally, failure to parse netplan configuration or invalid DHCP behavior should be investigated as possible regressions coming from this SRU.

Triaging.

This is a feature that exists in networkd, but it doesn't look to exist for NetworkManager. It doesn't mean that it is then something we won't implement, but it raises the question of how useful it will be to people in general.

Maybe it would be just as good to simply default to using DUID for the DHCPv4 client identifier, and that seems to be the default in networkd anyway.

What option do you actually need there? Is this that using DUID for DHCPv4 breaking with whatever DHCP server you are using?

Changed in netplan:
status: New → Triaged
importance: Undecided → Wishlist

Essentially, I seem to be hitting this issue: https://fedoraproject.org/wiki/Common_F21_bugs#IP_address_discovery_via_DHCP_does_not_work I've only seen it on a few systems (user maintained Fedora and Arch installs), but it will affect a roll-out of 18.04LTS.

I also posted a question on Ask Ubuntu, https://askubuntu.com/questions/987673/how-to-get-netplan-on-17-10-server-to-work-with-a-windows-server-dhcp-server , but I think I had the wrong end of the stick at that point-- I thought it related to the Windows DHCP server. It actually seems to be something to do with router configuration (or worse, operation).

It'd be nice to get it fixed in the routers, but even if our network team can do so other sites might not be able to.

Based on the Arch docs, Network Manager does/can support this if used with dhclient. See https://wiki.archlinux.org/index.php/NetworkManager#DHCP_problems_with_dhclient

> but it raises the question of how useful it will be to people in general

It is absolutely essential to be able to use the MAC address for DHCP. Currently in netplan+systemd-networkd it doesn't appear to be possible.

I created a few Bionic VMs today using libvirtd, and they all got the same DUID -- which means DHCP gave them all the same address. Unless I'm missing something, this could be a total disaster for anyone using libvirtd & qemu.

IMO it is insanity that the default is ClientIdentifier=duid in networkd -- but it doubly insane that netplan doesn't have a way to override this for every interface by default.

Another factor to consider is that many many DHCP servers hand out pre-allocated IP addresses based on the MAC. There are probably hundreds of thousands out there that have been configured for years. They are going to be in for a nasty surprise when someone tries to use 18.04.

Using the DUID as a client identifier for DHCP is the best option in most cases; that won't change. The specifics of this are well described in RFC 4361.

However, I do understand the requirement for making it possible to use other options, this is why the bug is Triaged. Some installations will not work with the DUID, and we should provide a way for people to work around that.

@Mark, I think the issue here is that the VMs were all created via cloning, in which case /etc/machine-id would be the same, which will explain why the DUID is the same on all the systems created. This should not be an issue where VMs are installed independently. You can remove the file to have it re-created at reboot, or use 'systemd-machine-id-setup' to have it re-generated.

David Meiser (demeiser) wrote :

I have another use case for this bug: I am working on the integration of Ubuntu 18.04 LTS for our server environment. We are heavy DHCP reservation users. Our reservation system only accepts MAC, not DUID, which means we are currently effectively unable to assign addresses to Ubuntu 18.04 with NetPlan.

There's a lot of non-compliant DHCP servers that are unable to deal with using a unique identified for Client Identifier, or pre-existing configuration that has yet to be updated.

The relevant RFC is 4361 [1]; it is meant to address the issues of replacing network hardware leading to losing a lease and any related configuration.

[1] https://www.rfc-editor.org/rfc/rfc4361.txt

It would help to have a better idea what the setups are like that don't like DUID...

@David, what do you use for DHCP server? Knowing what the environment is like might help us make better recommendations for the client identifer to be used.

Changed in netplan:
assignee: nobody → Mathieu Trudel-Lapierre (cyphermox)
David Meiser (demeiser) wrote :

@Mathieu It is not the DHCP server that is the issue, it is Solarwinds IPAM that is the issue. Solarwinds IPAM is not able to setup reservations for anything other than MAC address.

purity (purity82) wrote :

Hi, I made a "duplicate of this", you can read it here,
https://bugs.launchpad.net/netplan/+bug/1759532

My problem is with the DHCP-server, well you can read my bug report for more information.

I can't really know where is should change settings for netplan to use MAC instead of the Client Identifier.

Thanks.

Changed in netplan:
status: Triaged → In Progress
importance: Wishlist → High
David Meiser (demeiser) wrote :

@Mathieu Does this look like it will be baked into 18.04 release?

It is landed in 18.04; now looking at SRU to older releases:

netplan.io (0.35) bionic; urgency=medium

  * debian/postinst: fix version check for when to write breadcrumbs.
    (LP: #1756742)
  * bonds/bridges: Support specifying time-based values with "ms" suffix when
    the value should be in milliseconds; while keeping support for the previous
    behavior of handling values are pure seconds when no suffix is present.
    (LP: #1745597)
  * IPv6: accept-ra should default to being unset, so that the kernel default
    can be used. (LP: #1732002)
  * DHCPv4: add a "dhcp-identifier: mac" field that can be set to fix interop
    with Windows Server-based DHCP servers which don't support RFC 4361.
    (LP: #1738998)
  * docs, examples: reformat comments in examples, add standalone example files
  * debian/docs, debian/netplan.io.install: install doc and examples in the
    right locations.
  * netplan try: allow users to preview/test and approve network configuration
    changes, and automatically revert if they are not accepted. (LP: #1764824)
  * networkd: don't wipe out /run/netplan on generate: we do want to keep any
    YAML configurations in that directory, we just need to remove generated
    wpasupplicant configs. (LP: #1764869)
  * debian/control: add bash-completion to Build-Depends to make sure we do
    install completion files in the right location.

Changed in netplan:
status: In Progress → Fix Released
Changed in nplan (Ubuntu):
status: New → Fix Released
description: updated
description: updated

Hello Russell, or anyone else affected,

Accepted nplan into artful-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/nplan/0.32~17.10.4 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-artful to verification-done-artful. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-artful. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in nplan (Ubuntu Artful):
status: New → Fix Committed
tags: added: verification-needed verification-needed-artful
Brian Murray (brian-murray) wrote :

Hello Russell, or anyone else affected,

Accepted nplan into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/nplan/0.32~16.04.5 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-xenial to verification-done-xenial. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-xenial. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in nplan (Ubuntu Xenial):
status: New → Fix Committed
tags: added: verification-needed-xenial

Verification-done on xenial: nplan 0.32~16.04.5
Verification-done on artful: nplan 0.32~17.10.4

Verified that adding "dhcp-identifer: mac" to the configuration at the same level as "dhcp4: true" lead to the system idenfying itself with its MAC address instead of a DUID to the DHCP server. Without the option in netplan YAML, the DHCP requests happen normally and use a unique identifier as usual.

tags: added: verification-done-artful verification-done-xenial
removed: verification-needed verification-needed-artful verification-needed-xenial
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers