[Bug 1831787] Re: Bogus routes after DHCP lease change

[Dan Streetman]

as disco is EOL next week, marking this won't fix for disco.

** Changed in: systemd (Ubuntu Disco)
       Status: In Progress => Won't Fix

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1831787

Title:
  Bogus routes after DHCP lease change

Status in netplan:
  Invalid
Status in systemd:
  Unknown
Status in systemd package in Ubuntu:
  In Progress
Status in systemd source package in Bionic:
  In Progress
Status in systemd source package in Disco:
  Won't Fix
Status in systemd source package in Eoan:
  Fix Released

Bug description:
  [impact]

  networkd does not remove old route(s) after DHCP address change

  [test case]

  on a system using networkd, that is connected to a network where you
  can control the addresses that the DHCP server provides, setup system
  with networkd to get address via DHCP, e.g.

  [Match]
  Name=ens3

  [Network]
  DHCP=ipv4

  
  (re)start networkd or reboot, so the system gets an ipv4 DHCP address, and corresponding route to the gateway.

  
  Then on the dhcp server, change the subnet to a different subnet.  On the client, once its renews its DHCP address, the server will provide a new address in the new subnet, and the client will add a new default route to the new gateway address.  However, the old default route to the old gateway address isn't removed.

  Note this also happens without changing the entire subnet, but is more
  subtle as shown in the original description.

  [regression potential]

  this affects how networkd handles routes, so has the potential to
  leave a system with partial or incorrect networking, or no networking
  at all.  Any regression would most likely occur during networkd
  (re)start or during renewal of a DHCP lease, or when an interface is
  brought up.

  [other info]

  original description:
  ---

  
  Netplan config:

  network:
    version: 2
    renderer: networkd
    ethernets:
      eno4:
        dhcp4: no
      eno1np0:
        dhcp4: no
        addresses:
          - 172.16.0.2/24
    bridges:
      br0:
        dhcp4: yes
        interfaces:
          - eno4

  On initial boot, machine got 10.0.15.109 IP address:

  May 03 13:09:41 ceph2 systemd-networkd[29349]: br0: Configured
  May 03 13:09:41 ceph2 systemd-networkd[29349]: br0: DHCPv4 address 10.0.15.109/23 via 10.0.15.253

  At one point, DHCP server reserver this IP address and client
  eventually picked up new IP address:

  May 03 15:01:12 ceph2 systemd-networkd[1137]: br0: DHCPv4 address
  10.0.15.128/23 via 10.0.15.253

  This resulted in IP addresses:

  # ip -o a
  1: lo    inet 127.0.0.1/8 scope host lo\       valid_lft forever preferred_lft forever
  1: lo    inet6 ::1/128 scope host \       valid_lft forever preferred_lft forever
  2: eno1np0    inet 172.16.0.2/24 brd 172.16.0.255 scope global eno1np0\       valid_lft forever preferred_lft forever
  2: eno1np0    inet6 fe80::b226:28ff:fe53:56be/64 scope link \       valid_lft forever preferred_lft forever
  6: br0    inet 10.0.15.128/23 brd 10.0.15.255 scope global dynamic br0\       valid_lft 503sec preferred_lft 503sec
  6: br0    inet6 fe80::b8d7:5eff:fe6b:62a/64 scope link \       valid_lft forever preferred_lft forever

  So far, everything is fine. But, the routes on the machine are bogus:

  # ip r
  default via 10.0.15.253 dev br0 proto dhcp src 10.0.15.109 metric 100
  default via 10.0.15.253 dev br0 proto dhcp src 10.0.15.128 metric 100
  10.0.14.0/23 dev br0 proto kernel scope link src 10.0.15.128
  10.0.15.253 dev br0 proto dhcp scope link src 10.0.15.109 metric 100
  10.0.15.253 dev br0 proto dhcp scope link src 10.0.15.128 metric 100
  172.16.0.0/24 dev eno1np0 proto kernel scope link src 172.16.0.2

  routes with src 10.0.15.109 should have been removed when lease was
  renewed. I'm not sure if this is a bug in netplan or systemd. This is
  18.04, systemd 37-3ubuntu10.21, netplan 0.40.1~18.04.4.

To manage notifications about this bug go to:
https://bugs.launchpad.net/netplan/+bug/1831787/+subscriptions