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

Thu Nov 7 13:30:30 UTC 2019

Hello Ante, or anyone else affected,

Accepted systemd into eoan-proposed. The package will build now and be
available at https://launchpad.net/ubuntu/+source/systemd/242-7ubuntu3.2
in a few hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.  Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested and change the tag from
verification-needed-eoan to verification-done-eoan. If it does not fix
the bug for you, please add a comment stating that, and change the tag
to verification-failed-eoan. In either case, without details of your
testing we will not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance for helping!

N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.

** Changed in: systemd (Ubuntu Eoan)
       Status: In Progress => Fix Committed

** Tags added: verification-needed verification-needed-eoan

-- 
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:
  In Progress
Status in systemd source package in Eoan:
  Fix Committed

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