netplan

netplan does not clean-up IPs on UC20/kvm, when changing the renderer

Bug #1870561 reported by Alfonso Sanchez-Beato
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
netplan
Fix Released
Undecided
Unassigned

Bug Description

Somewhat networkd on UC20/kvm apparently creates a scope site IPv6 address on UC20. For instance:

2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff
    inet 10.0.2.15/24 brd 10.0.2.255 scope global dynamic ens3
       valid_lft 86399sec preferred_lft 86399sec
    inet6 fec0::5054:ff:fe12:3456/64 scope site tentative dynamic mngtmpaddr noprefixroute
       valid_lft 86400sec preferred_lft 14400sec
    inet6 fe80::5054:ff:fe12:3456/64 scope link
       valid_lft forever preferred_lft forever

The main problem is not this (although site-local addresses are deprecated), but that netplan does not clean up that address when switching the renderer to NetworkManager and then running "netplan apply".

NetworkManager is quite finicky when it takes over control of an interface: if it sees that it still has a reachable address, it creates a connection profile for the already existing addresses. So an 'ens3' connection is created with ipv4 disabled and ipv6 using the site local address, leaving the device unreachable for ipv4, because the addresses it sees are:

2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff
    inet6 fec0::5054:ff:fe12:3456/64 scope site tentative dynamic mngtmpaddr noprefixroute
       valid_lft 86400sec preferred_lft 14400sec
    inet6 fe80::5054:ff:fe12:3456/64 scope link
       valid_lft forever preferred_lft forever

And the 'netplan-ens3' connection created by netplan is not activated.

I am not sure who exactly is creating this address, but netplan should clean-up things before re-starting NetworkManager - the dhcp address is removed, but not this site-local ipv6 one.

Related branches

~slyon/netplan/+git/ubuntu:upstream/latest
Łukasz Zemczak: Pending requested
Diff: 8185 lines (+5730/-508)
45 files modified
Makefile (+3/-2)
doc/netplan.md (+298/-74)
examples/sriov.yaml (+14/-0)
examples/sriov_vlan.yaml (+18/-0)
examples/static.yaml (+2/-2)
netplan/cli/commands/apply.py (+91/-17)
netplan/cli/commands/try_command.py (+2/-2)
netplan/cli/ovs.py (+168/-0)
netplan/cli/sriov.py (+32/-18)
netplan/cli/utils.py (+32/-0)
netplan/configmanager.py (+32/-0)
src/generate.c (+14/-2)
src/networkd.c (+114/-32)
src/networkd.h (+2/-0)
src/nm.c (+109/-26)
src/openvswitch.c (+484/-0)
src/openvswitch.h (+24/-0)
src/parse.c (+763/-241)
src/parse.h (+56/-4)
src/sriov.c (+40/-0)
src/sriov.h (+21/-0)
src/util.c (+29/-0)
src/util.h (+6/-2)
src/validation.c (+155/-10)
src/validation.h (+3/-0)
tests/generator/base.py (+54/-0)
tests/generator/test_args.py (+18/-4)
tests/generator/test_bonds.py (+42/-0)
tests/generator/test_common.py (+194/-1)
tests/generator/test_errors.py (+69/-1)
tests/generator/test_ethernets.py (+23/-7)
tests/generator/test_ovs.py (+1021/-0)
tests/generator/test_routing.py (+145/-17)
tests/generator/test_tunnels.py (+477/-5)
tests/generator/test_wifis.py (+143/-0)
tests/integration/base.py (+6/-4)
tests/integration/ethernets.py (+38/-0)
tests/integration/ovs.py (+559/-0)
tests/integration/routing.py (+76/-21)
tests/integration/tunnels.py (+71/-0)
tests/test_configmanager.py (+21/-0)
tests/test_ovs.py (+129/-0)
tests/test_sriov.py (+55/-12)
tests/test_utils.py (+73/-0)
tests/validate_docs.sh (+4/-4)
Revision history for this message
Alfonso Sanchez-Beato (alfonsosanchezbeato) wrote :

I can reproduce on focal on an lxd container, with the difference of the suspicious address being of global scope:

root@focal:~# networkctl
IDX LINK TYPE OPERATIONAL SETUP
  1 lo loopback carrier unmanaged
 17 eth0 ether routable configured
root@focal:~# ip a
1: lo: ...
20: eth0@if21: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:16:3e:c1:c5:81 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 10.49.27.111/24 brd 10.49.27.255 scope global dynamic eth0
       valid_lft 3592sec preferred_lft 3592sec
    inet6 fd42:d3fd:4a50:3d0a:216:3eff:fec1:c581/64 scope global dynamic mngtmpaddr noprefixroute
       valid_lft 3600sec preferred_lft 3600sec
    inet6 fe80::216:3eff:fec1:c581/64 scope link
       valid_lft forever preferred_lft forever
root@focal:~# cat 00-default-nm-renderer.yaml
network:
  renderer: NetworkManager
root@focal:~# cp 00-default-nm-renderer.yaml /etc/netplan/
root@focal:~# netplan apply
root@focal:~# ip a
1: lo: ...
20: eth0@if21: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:16:3e:c1:c5:81 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet6 fd42:d3fd:4a50:3d0a:216:3eff:fec1:c581/64 scope global dynamic mngtmpaddr noprefixroute
       valid_lft 3555sec preferred_lft 3555sec
    inet6 fe80::216:3eff:fec1:c581/64 scope link
       valid_lft forever preferred_lft forever
root@focal:~# nmcli c
NAME UUID TYPE DEVICE
eth0 84a9fe97-3646-43b0-b790-79466e59bb02 ethernet eth0
netplan-eth0 626dd384-8b3d-3690-9511-192b2c79b3fd ethernet --

eth0 does not have an ipv4 address anymore.

Revision history for this message
Lukas Märdian (slyon) wrote :

Hi Alfonso,

I can confirm/reproduce this problem in a clean ubuntu/focal LXD container.

netplan is supposed to do some cleanup before starting up NetworkManager. It does this by executing 'nmcli device disconnect eth0' – which seems to be failing the first time it is executed after switching the renderer to NetworkManager... If I re-execute 'netplan apply' a 2nd time, the suspicious IP6 address is gone and the IP4/DHCP address is there.

Changed in netplan:
status: New → Confirmed
Revision history for this message
Lukas Märdian (slyon) wrote :

This should fix the problem we're seeing here:
https://github.com/CanonicalLtd/netplan/pull/159

Lukas Märdian (slyon)
Changed in netplan:
status: Confirmed → Fix Committed
Revision history for this message
Lukas Märdian (slyon) wrote :

fixed in 0.100

Changed in netplan:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

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