systemd-networkd: DHCP lease lost (Ubuntu 18.04)

Bug #1776013 reported by Wladimir Mutel
14
This bug affects 3 people
Affects Status Importance Assigned to Milestone
systemd (Ubuntu)
Invalid
Undecided
Unassigned

Bug Description

I have a Linux router whose external Ethernet interface is configured from ISP's DHCP server.
After its migration from Ubuntu 16.04 + ifupdown + isc-dhcp-client to Ubuntu 18.04 + netplan.io + systemd-networkd, I noticed that systemd-networkd plays overly fairly when it can not get a timely renew response from ISP's DHCP server: it honestly removes the dynamic IP from the interface and restores (often the same) IP only when ISP's DHCP server gives it a proper response again. Which causes 1..5-minute pauses in Internet availability since my ISP's DHCP server is for some reason flaky, i.e. it can become unresponsive for some periods of time. I never noticed this problem with isc-dhcp-client, and started noticing it only after migrating DHCP client role to systemd-networkd.
The question is, can I (or you) make systemd-networkd DHCP client behave more relaxedly ?
I know that most DHCP clients (isc-, pump, dhcpcd) at some stage of their development decided to implement such relaxed logic, i.e. to keep last-configured dynamic IP on the interface despite the lack of responses from DHCP server. As this is easier to implement than to make ISP staff fix their services, I would suppose there should be some knob in systemd-networkd settings. Or, at least, an idea to implement something similar in the future.

Revision history for this message
Wladimir Mutel (mwg) wrote :

ok, I installed netplan.io 0.37.1 from Ubuntu Cosmic and set 'critical: true' for my ISP connection
will check how it will be going after that.

Revision history for this message
Dimitri John Ledkov (xnox) wrote :

Yes, the critical connection is the option to use in this case.

You may also check the leases themselves in /run/systemd/netif/leases and check if the T1/T2/Lifetime are sensible, with each subsequent one higher than the prior. And if not, contact your ISP support to correct those.

Changed in systemd (Ubuntu):
status: New → Invalid
Revision history for this message
Dimitri John Ledkov (xnox) wrote :
Revision history for this message
Nagarjuna Manchineni (manchinagarjuna) wrote :

Hi All,

I know the issue is closed. However, I am observing this issue. I am on a network where the DHCP lease time out occurs every 24 hours and whenever that happens my network gets restarted. Due to this I am loosing some of my IP route entries which in turn causes failures to my application.

I have tried multiple workarounds like the one that has been suggested above (critical connection). However, none of them helped in resolving the issue. Currently I moved from Ubuntu 18.04 to Ubuntu 16.04 temporarily.

If someone who already has a solution or any pointers that could resolve this network restart issue that would be helpful to others like me.

TIA!

Revision history for this message
Wladimir Mutel (mwg) wrote :

The problem I had was not related to netplan, networkd or dhcp client of any kind.
I had both my ISP links connected to a VLAN switch DLink DGS-1100-08 and multiplexed to a single Linux router interface with different VLAN numbers.
On Linux side, vlan.NNN interfaces were configured to separate each ISP traffic by its VLAN number.
These interfaces were managed by separate DHCP clients, requesting dynamic IPs from their corresponding ISP.
Both ISPs had a policy permitting only a single MAC address to request a DHCP lease on a single customer's port.
And this was combined with the fact that for some Ethernet protocols, DLink VLAN switches of this model do not obey VLAN isolation rules.
In part, among them were DLink's own discovery & loobpack detection protocols (Ether.proto number = 0x9000, using multicast MAC addresses prefixed with CF: byte).
My both ISPs had a plenty of DLink hardware in their Ethernet segments, and my DLink switch inadvertently served as a bridge for DLink discovery packets, allowing them to fly freely between two VLANs.
Which of course was detected by each other ISP's policy as 'stray MACs' on a single customer port, and caused my real MAC to be temporarily kicked out from their valid MAC set, which subsequently caused DHCP lease loss.
What resolved by problem once and for all, was installing dual-port PCIe Gigabit Ethernet adapter into my Linux router and physically plugging my ISP links into its separate ports.
Detailed discussion can be seen at http://forums.dlink.com/index.php?topic=74704.0

Revision history for this message
Dmitriy Altuhov (altuhovsu) wrote :

To fix it with cloud-init we need to create an override-file for netplan like this:

/etc/netplan/99-critical-dhcp.yaml
network:
    version: 2
    ethernets:
        ens2:
            dhcp4: true
            critical: true

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.