10
2
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, and 10.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.
Nice one. BTW it's documented in the official netplan docs/reference: https://netplan.io/reference
– NoMad – 2018-10-29T09:24:33.523For 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. – Mehrad Mahmoudian – 2019-04-23T09:42:34.810Thanks, 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... – gatopeich – 2019-05-01T12:32:16.127
1this is such WTF – matson kepson – 2019-10-30T11:17:23.210
"no longer uses the NIC Mac address as the default id". So what is the default now? – dthor – 2020-01-07T21:57:01.007
The 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. – anneb – 2020-01-08T04:50:08.780
How this is supposed to be working with
cloning
of VMs? Every VM will get the same IP as result – Gregory Suvalian – 2020-02-23T19:59:19.473