[Bug 1979951] Re: 127.0.0.1/::1 removed from loopback interface if you configure extra IPs on lo (r104 regression/behaviour change)

[Nick Rosbrook]

I have verified the fix on jammy using systemd 249.11-0ubuntu3.6 from
jammy-proposed:

root at jammy:~# apt-cache policy systemd
systemd:
  Installed: 249.11-0ubuntu3.6
  Candidate: 249.11-0ubuntu3.6
  Version table:
 *** 249.11-0ubuntu3.6 500
        500 http://archive.ubuntu.com/ubuntu jammy-proposed/main amd64 Packages
        100 /var/lib/dpkg/status
     249.11-0ubuntu3.4 500
        500 http://archive.ubuntu.com/ubuntu jammy-updates/main amd64 Packages
     249.11-0ubuntu3 500
        500 http://archive.ubuntu.com/ubuntu jammy/main amd64 Packages
root at jammy:~# cat /etc/netplan/10-lxc.yaml 
network:
  version: 2
  ethernets:
    eth0:
      dhcp4: true
      dhcp-identifier: mac
    lo:
      addresses: ["10.10.10.17/24","10.10.10.19/24"]
root at jammy:~# netplan apply
root at jammy:~# ip addr show dev lo
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet 10.10.10.17/24 brd 10.10.10.255 scope global lo
       valid_lft forever preferred_lft forever
    inet 10.10.10.19/24 brd 10.10.10.255 scope global secondary lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
root at jammy:~# netplan apply
root at jammy:~# ip addr show dev lo
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet 10.10.10.17/24 brd 10.10.10.255 scope global lo
       valid_lft forever preferred_lft forever
    inet 10.10.10.19/24 brd 10.10.10.255 scope global secondary lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever


** Tags removed: verification-needed verification-needed-jammy
** Tags added: verification-done verification-done-jammy

-- 
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/1979951

Title:
  127.0.0.1/::1 removed from loopback interface if you configure extra
  IPs on lo (r104 regression/behaviour change)

Status in netplan.io package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  Fix Released
Status in netplan.io source package in Focal:
  New
Status in systemd source package in Focal:
  Fix Committed
Status in netplan.io source package in Jammy:
  New
Status in systemd source package in Jammy:
  Fix Committed

Bug description:
  [Impact]

  Users who wish to configure additional addresses on lo may
  inadvertently remove the 127.0.0.1/8 address from the interface. And,
  because this only happens on the second invocation of `netplan apply`,
  it can create confusing breakages for users. Although this is not a
  recommended configuration, it was previously supported and the current
  behavior is a regression.

  [Test Plan]

  * Configure additional addresses on the lo interface. I am testing in
  a LXD container, so I added the following to /etc/netplan/10-lxc.yaml
  under `ethernets:`

      lo:
        addresses: ["10.10.10.17/24","10.10.10.19/24"]

  * Apply the config, and then inspect the lo interface's addresses:

   $ netplan apply
   $ ip addr show dev lo

  * Observe that the 127.0.0.1/8 address is still present. Now, run the
  same commands again:

   $ netplan apply
   $ ip addr show dev lo

  * On an affected system, observe that the 127.0.0.1/8 address is now
  gone. On a patched system, the address should still be present.

  [Where problems could occur]

  The patch removes cases where systemd-networkd will drop foreign
  addresses from a managed link. If problems were to occur, it would be
  related to the addresses configured on a managed link.

  [Original Description]

  If you configure the loopback interface using netplan without listing
  the standard loopback addresses (127.0.0.1 / ::1) that are auto-
  configured on boot then they are removed by netplan in r104+ but were
  not in r103.

  Confusingly this only happens the second time "netplan apply" is
  invoked and not the first time.

  There is some argument this is not a valid configuration, however
  - It worked on r103 and broke in the r104 SRU for 20.04 and breaks on upgrade
  - Since it only occurs on the second "netplan apply" it is likely people will accidentally create a configuration that on first verification works but breaks later
  - Adding addresses to a loopback or dummy interface is a common need
  - There is no dummy interface support in Netplan
  - Removing the loopback IP doesn't immediately cause obvious breakage in an SSH session but causes all sorts of hard to diagnose issues with applications

  Thus I consider this a high priority regression because of the
  multiple ways this can break a system at an unexpected/unrelated time
  to when the original change was made.

  As a workaround you can add 127.0.0.1/::1 to the file and this seems
  to generally work and product almost the same configuration with the
  exception that "brd 127.255.255.255" is added to the "ip addr" output
  compared to the auto-created configuration. All of the different
  routing tables seem otherwise the tame.

  = Test Case =
  (1) Add IP configuration for lo to /etc/netplan/lo.yaml

  lo:
    match:
      name: lo
    addresses:
    - 10.10.10.17/24
    - 10.10.10.19/24

  (2) Run "netplan apply" and observe the "ip addr show dev lo" output. Expected: 127.0.0.1/::1 are still there.
  (3) Run "netplan apply" a second time and observe the "ip addr show dev lo" output. Expected: 127.0.0.1/::1 are now removed.
  (4) Repeat the same test under netplan r103. Expected: 127.0.0.1/::1 are still there in both cases.

  = Observations =

  I found this change of behaviour happens only in r104. It is suspected
  but not clear that this is due to the configuraiton diffing behaviour
  introduced in r104. It's not clear to me why it doesn't happen on the
  first "netplan apply".

  I also found a recent upstream systemd commit to prevent networkd removing 127.0.0.1/::1 which solves this issue on r104 as well. It's possible this is a better fix to backport to solve this:
  https://github.com/systemd/systemd/commit/b69bfa43052586cd6894c32d7d3d447195539ec5

  Reverting to r103 *or* running a newer systemd with that patch
  resolves the issue on 20.04 and 22.04 in my testing.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/netplan.io/+bug/1979951/+subscriptions