Wrong IP address from DHCP client on Ubuntu 18.04
Solution 1
The cause of the problem is that the built-in network config of Ubuntu 18.04 no longer uses the NIC Mac address as the default id for DHCP requests.
The traditional (and I believe "sensible") behavior can be restored by adding dhcp-identifier: mac
to the configuration in the /etc/netplan/xxx.yaml (cloud-init) file as follows:
network:
renderer: networkd
version: 2
ethernets:
nicdevicename:
dhcp4: true
dhcp-identifier: mac
Where "nicdevicename" is the name of your network device
Use
sudo netplan apply
to try the new configuration. If you get any errors, please note that precise indentation is very important in .yaml files..
Solution 2
Denying the lease won't work. There's no way networkd could know why it's being denied, so it won't just magically switch to a different ID type if you do so. You have to do that manually.
If your systemd version is recent enough and if you have direct control over the config files written out by cloud-init, you can tell systemd-networkd to send a MAC-address-based client ID via the *.network
file:
[DHCP]
ClientIdentifier=mac
But if you know that systemd-networkd will always be used, you can just assign the correct lease to client ID 032e827c00020000ab11d0fc617dced58a43
, because that's what systemd-networkd will always send for that machine. (It generates the ID based on /etc/machine-id
.)
Mos DHCP clients, including dhclient, supply a client-ID field of type '01' (MAC-based). Another common type is '00' (domain name). However, by default, systemd-networkd supplies an "opaque" client-ID that was generated from the contents of /etc/machine-id.
According to the DHCP protocol, leases are chosen by client ID first (as long as the client supplies a "client ID" option, which may or may not be MAC-based), then by the MAC address only if the client didn't send an ID.
So when you're configuring a reservation, all good DHCP servers will allow you to enter either the client ID or the MAC address. If you enter just the MAC address, then I suppose that a type-'01' (MAC-based) client ID is automatically implied. There may be a checkbox named "Ignore client ID", which is convenient for you but technically violates the DHCP spec.
(For example, I have two Wi-Fi adapters with different MACs, but I've configured the OS to send the same client ID no matter which adapter is connected. This way I get the same address via both.)
Solution 3
On vSphere it has been noted that, if a template contain the machine-id then any VMs cloned from the template get same ip as DHCP use the machine-id not the MAC address. Solution is to remove the machine-id from the file /etc/machine-id in the template so new machine-id generated during the cloning.
echo -n > /etc/machine-id
Related videos on Youtube
NoMad
Updated on September 18, 2022Comments
-
NoMad over 1 year
I'm experiencing a weird issue where my Ubuntu 18.04 (server) box gets issued a wrong IP address during boot from the DHCP server. Running dhclient after boot on the interface results in the right IP being added to the interface.
The DHCP Server is a Windows box where a reservation was manually configured using the MAC address shown by
ip addr
in ubuntu (without colons):5: eno4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 00:26:b9:82:44:27 brd ff:ff:ff:ff:ff:ff inet 10.10.11.162/23 brd 10.10.11.255 scope global dynamic eno4 valid_lft 689861sec preferred_lft 689861sec inet6 fe80::226:b9ff:fe82:4427/64 scope link valid_lft forever preferred_lft forever
My
50-courtin-networking.cfg
(cloud-init cfg)network: version: 2 ethernets: bcm: match: name: eno* dhcp4: true dhcp6: false
Journalctl entries for DHCP:
#journalctl | grep -Ei 'dhcp'` Jul 12 10:10:56 skprov2 systemd-networkd[1160]: eno1: DHCP lease lost Jul 12 10:10:57 skprov2 systemd-networkd[1160]: eno4: DHCP lease lost Jul 12 10:11:00 skprov2 systemd-networkd[1160]: eno1: DHCPv4 address 10.10.11.157/23 via 10.10.10.254 Jul 12 10:11:02 skprov2 systemd-networkd[1160]: eno4: DHCPv4 address 10.10.11.162/23 via 10.10.10.254
Manually calling dhclient after login (verbose):
# dhclient -v eno4 Internet Systems Consortium DHCP Client 4.3.5 Copyright 2004-2016 Internet Systems Consortium. All rights reserved. For info, please visit https://www.isc.org/software/dhcp/ Listening on LPF/eno4/00:26:b9:82:44:27 Sending on LPF/eno4/00:26:b9:82:44:27 Sending on Socket/fallback DHCPREQUEST of 10.10.10.40 on eno4 to 255.255.255.255 port 67 (xid=0x4cb8a62d) DHCPACK of 10.10.10.40 from 10.10.10.10 bound to 10.10.10.40 -- renewal in 294538 seconds.
10.10.10.10
is the correct DHCP server, and10.10.10.40
is the IP configured on it. On the Windows DHCP, the wrong lease (.162) shows a long "Unique ID" that does not contain any MAC address present on the ubuntu box:032e827c00020000ab11d0fc617dced58a43
What's the right way to avoid this? Deny leases for the long UID? Where does that UID come from in the first place? The NIC is onboard in a Dell PowerEdge R710 server.
-
NoMad almost 6 yearsSo it was networkd after all... I didn't know networkd doesn't use the MAC address by default and thought maybe this is an ID generated by some Dell Firmware before actually booting for system management (or something). I'm in the process of testing a reservation for that GUID now.
-
user1686 almost 6 yearsOn that note, Dell iDRAC certainly might be doing DHCP, but it has its own MAC address separate from the actual server. (It also boots up as soon as you connect the power, even if the entire server is shut down.)
-
NoMad almost 6 yearsiDRAC currently is (and was) disabled. The ubuntu box now gets the right IP with the reservation for that GUID, but after
systemctl restart systemd-networkd
none of the interfaces are rechable by ping. networkd seems to screw up routes... -
anneb over 5 yearsWhy would the people behind networkd decide to drop using the MAC address as the default ID? Using /etc/machine-id sounds like a bad idea for machines with more than one NIC and for cloned instances? Can anyone point to the rationale behind this decision?
-
user1686 over 5 years@anneb: I don't know the rationale. But for cloned instances, just as /etc/ssh/ssh_keys are supposed to be reset after clone, so is the machine-id. (Afaik, systemd is even able to pick up the virtual machine ID from KVM/HyperV/etc.) Networkd's DHCPv4 client ID is generated similarly to DHCPv6 DUIDs, and has the interface ID hashed into it for multi-interface systems.
-
anneb over 5 years@grawity: Thanks for the elaboration! Unfortunately VMWare clones do not automatigically renew /etc/machine-id (nor /etc/ssh/ssh_keys), but (virtual hardware) MAC adddresses are renewed. If the interface ID is hashed into the DHCP request, I do not get the advantage of using /etc/machineid at all. If using only /etc/machineid, it would at least make the ip address independent of the NIC. If it still depends on the NIC, why use /etc/machineid at all?
-
NoMad over 5 yearsNice one. BTW it's documented in the official netplan docs/reference: netplan.io/reference
-
Mehrad Mahmoudian about 5 yearsFor those who might have different problem than the question: On my work place computer the ethernet was working on and off lately. I was getting proper IP (checked with
ip addr
), cable was working, I could ping some computers in the network but no route to outside, no one could ping me. The MAC was correctly registered in the DHCP white list and was not banned by any means and yet no way out. This answer solved my problem. -
gatopeich about 5 yearsThanks, do you know when did this start happening? My 18.04 LTS suddenly came up with a different address on April 30th, after months static...
-
matson kepson over 4 yearsthis is such WTF
-
dthor over 4 years"no longer uses the NIC Mac address as the default id". So what is the default now?
-
anneb over 4 yearsThe default is an RFC4361 client-id (stored in a file). The idea is that the device will present itself with the same id to the network, even if the network hardware is changed. Nice idea, but in my opinion this should be optional behaviour, since the mac id was (and hence should remain) the default.
-
Gregory Suvalian about 4 yearsHow this is supposed to be working with
cloning
of VMs? Every VM will get the same IP as result -
Andrew Savinykh over 3 years
-
Admin almost 2 years"Sensible" is a kind way to put it into words. I just lost hours because of this **** so please forgive my urge for a more appropriated expletive.