0

I've seen a lot of this question, with no clear and ideal answer, so I am asking it myself.

Ever since Ubuntu 18.04.3 (I think it was .3 that started it) through at least 20.04.1, I've been seeing a 2-minute delay on startup, waiting for the network to come up. IPv6 is not configured on our network, and the DHCP servers are Windows-based, with 2 replicated servers, and IP helpers on the VLANs - although my Ubuntu servers are on the same VLAN as the DHCP servers (all my VMs are on the same VLAN).

The netplan tends to get ignored, as dhcp insists on using the GUID as an identifier, even though the interface.yaml in /etc/netplan/ says to use the MAC. Further, DHCP doesn't even try to get an address until 10-15 minutes after startup, unless I mark the interface as optional. However, invoking dhclient works perfectly and immediately.

From what I've read, this delay seems to be an IPv6 addressing problem. So, I have disabled ipv6 in grub. I marked the interface as optional, and dhcp6 to false, in the netplan yaml file, and that solves the 2-minute start-up delay, but the dhcp server returns an unexpected IP, because the dhcp-identifier line from the netplan is being ignored. Instead of presenting the MAC address, Ubuntu presents the GUID.

Here is my 01-netcfg.yaml:

network:
  version: 2
  renderer: networkd
  ethernets:
    ens160:
      dhcp4: true
      dhcp6: false
      dhcp-identifier: mac
      optional: true
      link-local: [ ]

As soon as I generate and apply the netplan, I get disconnected, and get the wrong IP address. If I manually invoke sudo dhclient -r; sudo dhclient, I get the expected IPv4 address immediately.

Ergo, the only way I've been able to make the server get the correct address without delay, is to set the interface as as stated, then run a script on startup to manually run dhclient.

This seems like a rather klugey way to do things, because it seems to be going around the problem(s) rather than fixing it/them.

Can someone please tell me what is happening, and more importantly, how to fix it?

Thanks in advance!

EDIT with new information: If I let the VM just sit, it finally picks up an IP about 8.5 minutes after the login prompt. I'm guessing that is 10 minutes after the interface comes up.

Also, I read in another thread about a similar issue, that having multiple DHCP servers on the segment caused the problem for another user. We do have 2 Windows 2019 DHCP servers on this segment, doing load balancing (scope replication).

EDIT sudo netplan --debug generate outputs the following:

** (generate:3137): DEBUG: 14:26:01.499: Processing input file /etc/netplan/00-installer-config.yaml
..
** (generate:3137): DEBUG: 14:26:01.501: starting new processing pass
** (generate:3137): DEBUG: 14:26:01.501: We have some netdefs, pass them through a final round of validation
** (generate:3137): DEBUG: 14:26:01.503: ens160: setting default backend to 1
** (generate:3137): DEBUG: 14:26:01.504: Configuration is valid
** (generate:3137): DEBUG: 14:26:01.505: Generating output files..
** (generate:3137): DEBUG: 14:26:01.505: openvswitch: definition ens160 is not for us(backend 1)
** (generate:3137): DEBUG: 14:26:01.506: NetworkManager: definition ens160 is not for us(backend 1)
(generate:3137): GLib-DEBUG: 14:26:01.507: posix_spawn avoided (fd close requested)
(generate:3137): GLib-DEBUG: 14:26:01.511: posix_spawn avoided (fd close requested)

Here is the output of sudo journalctl | grep ens160

Nov 08 08:45:30 graylog systemd-networkd[846]: ens160: DHCP lease lost
Nov 08 08:45:44 graylog kernel: vmxnet3 0000:03:00.0 ens160: renamed from eth0
Nov 08 08:45:52 graylog kernel: vmxnet3 0000:03:00.0 ens160: intr type 3, mode 0, 5 vectors allocated
Nov 08 08:45:52 graylog kernel: vmxnet3 0000:03:00.0 ens160: NIC Link is Up 10000 Mbps
Nov 08 08:45:52 graylog systemd-networkd[843]: ens160: Link UP
Nov 08 08:45:52 graylog systemd-networkd[843]: ens160: Gained carrier
Nov 08 08:45:53 graylog cloud-init[851]: ci-info: | ens160 | True |     .     |     .     |   .   | 00:50:56:96:c6:b7 |
Nov 08 08:45:53 graylog cloud-init[851]: ci-info: |   2   |  multicast  |    ::   |   ens160  |   U   |
Nov 08 08:54:29 graylog systemd-networkd[843]: ens160: DHCPv4 address 10.83.1.5/24 via 10.83.1.1
Jay Duff
  • 81

2 Answers2

0

Jay, I had this problem I think it started when I switched to 18. One machine even took close to 4 minutes - at first I thought it wasn't booting at all. As you see nobody has come up with a solution that works so I stumbled on Xubuntu!! It is supposed to be a minimal version but in 2 years I haven't discovered what it is missing and it boots in 30 -45 seconds. I uses the same Ubuntu kernel. I am not an expert user but I have one system I use as a Media Player (smart TV) and another I use just for downloads. Xubuntu supports all my hardware and software for those needs. The only problem I had was the graphics support but that is also a problem with Ubuntu which was never fixed. Xubuntu 20.04.1 does fix that and plays video well. Hope that helps - Download the 20.04.1 ISO and install new if you can - that works well.

KenF
  • 1
0

From the question, and the comments...

re: "Ever since Ubuntu Server 18.04.3 through at least 20.04.1, my network has trouble getting an appropriate DHCP IP address. It also takes two minutes to start the network. I'm using netplan."

Suggested booting to a Ubuntu Live 21.10 DVD/USB and retesting.

re: "Ubuntu 21.10 seems to fix everything. I tried changing VMWare drivers, adding my stuff to the netplan to disable ipv6, using the mac as the dhcp-identifier and it all worked flawlessly! ip a shows more information under 21.10, that shows the network device being aliased (altname enps0)."

Adding "optional: true" to the .yaml file solved the long boot times.

I believe that there was something wrong in the original network settings all along, or the newer version of netplan in Ubuntu 21.10 solved the problems.

heynnema
  • 73,649