netplan does not allow dhcp client identifier type to be specified

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?

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.

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.

@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.

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.

@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.

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!

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!

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.

This bug was fixed in the package nplan - 0.32~17.10.4

---------------
nplan (0.32~17.10.4) artful; urgency=medium

  * bond/bridge: Support suffixes for time-based values so things like
    "mii-monitor-interval" can support milliseconds. (LP: #1745597)
  * debian/postinst: Write breadcrumbs on disk in /etc/network/interfaces to
    denote the migration to using netplan. (LP: #1756742)
  * 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)
  * IPv6: accept-ra should default to being unset, so that the kernel default
    can be used. (LP: #1732002)
  * doc/netplan.md: Clarify the behavior for time-based values for bonds
    and bridges. (LP: #1756587)
  * critical: provide a way to set "CriticalConnection=true" on a networkd
    connection, especially for remote-fs scenarios. (LP: #1769682)
  * 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)

 -- Mathieu Trudel-Lapierre <email address hidden> Tue, 08 May 2018 11:04:30 -0400

The verification of the Stable Release Update for nplan has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

This bug was fixed in the package nplan - 0.32~16.04.5

---------------
nplan (0.32~16.04.5) xenial; urgency=medium

  * bond/bridge: Support suffixes for time-based values so things like
    "mii-monitor-interval" can support milliseconds. (LP: #1745597)
  * Do not attempt to rebind driver 'qeth'. (LP: #1756322)
  * Allow setting ClientIdentifier=mac for networkd-renderered devices
    (LP: #1738998)
  * IPv6: accept-ra should default to being unset, so that the kernel default
    can be used. (LP: #1732002)
  * doc/netplan.md: Clarify the behavior for time-based values for bonds
    and bridges. (LP: #1756587)
  * critical: provide a way to set "CriticalConnection=true" on a networkd
    connection, especially for remote-fs scenarios. (LP: #1769682)
  * 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)

 -- Mathieu Trudel-Lapierre <email address hidden> Tue, 08 May 2018 10:36:24 -0400

I know https://bugs.launchpad.net/netplan/+bug/1738998/comments/10 says the fix landed in 18.04 but I am running 18.04 and when I use Virt-Manager to Clone an existing Ubuntu VM... that new VM gets the same IP address as the original VM still.

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 18.04.2 LTS
Release: 18.04
Codename: bionic

So did it into 18.04.02 ???