Netplan apply doesn't remove non specified VLAN's

Bug #1791253 reported by gtp
20
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Netplan
New
Undecided
Unassigned

Bug Description

[FACTS]
When Netplan applies a configuration with some VLANs defined but previously there are some other VLANs, the old VLANs aren't deleted.

You need to put down and up the linked interface to purge the non configured old VLANs.

A restart of systemd-networkd doesn't works.

[EXAMPLE]
1) Define some VLANs in "/etc/netplan/50-cloud-init.yaml":

network:
  ethernets:
    enp0s3:
      addresses:
      - 192.168.57.10/26
      gateway4: 192.168.57.3
    enp0s8:
      addresses:
      - 192.168.58.9/24
  renderer: networkd
  version: 2
  vlans:
    vlan20:
      addresses:
      - 192.168.0.9/22
      id: 20
      link: enp0s8
    vlan70:
      addresses:
      - 192.168.48.9/24
      id: 70
      link: enp0s8
    vlan71:
      addresses:
      - 192.168.16.9/22
      id: 71
      link: enp0s8

2) Execute "netplan apply" to take the changes affect. You can see configured with "ip a" command the new VLANs (Vlan20, vlan70 and vlan71).

3) Now, remove from "/etc/netplan/50-cloud-init.yaml" the VLANs vlan70 and vlan71:

network:
  ethernets:
    enp0s3:
      addresses:
      - 192.168.57.10/26
      gateway4: 192.168.57.3
    enp0s8:
      addresses:
      - 192.168.58.9/24
  renderer: networkd
  version: 2
  vlans:
    vlan20:
      addresses:
      - 192.168.0.9/22
      id: 20
      link: enp0s8

4) Execute "netplan apply" to take the changes affect.
5) Observe with "ip a" command that there are still the VLANs 70 and 71 defined
6) If you restart systemd network service with command "service systemd-networkd restart" they're are still defined.

[WORKAROUND]
You can execute the following commands to take effect the changes:

1) "ip link set dev enp0s8 down"
2) "netplan apply"
3) wait a few seconds (I don't know why but it's important!)
4) "ip link set dev enp0s8 up"

Tags: netplan seg vlan
Revision history for this message
Mario Splivalo (mariosplivalo) wrote :

This is not related just to vlans, it's general configuration that doesn't get applied.

This is my netplan configuration, inside a LXD container:

network:
  version: 2
  ethernets:
    eth0:
      dhcp4: false
      addresses:
        - "10.4.10.110/16"
      gateway4: 10.4.0.1

And this is the output of "ip a":
root@bio-netplan:/etc/netplan# ip -c a
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
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
31: eth0@if32: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:16:3e:9d:59:68 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 10.4.10.110/16 brd 10.4.255.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::216:3eff:fe9d:5968/64 scope link
       valid_lft forever preferred_lft forever

Now I want to change the ip from 10.4.10.110 to 10.4.10.220:

# sed -i "s/10.4.10.110/10.4.10.220/" 51-cloud-init.yaml

Now I run 'netplan apply'. That yields nothing (no error). But when I check my eth0 configuration I see that there are two IPs configured:

root@bio-netplan:/etc/netplan# ip -c a
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
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
31: eth0@if32: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:16:3e:9d:59:68 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 10.4.10.110/16 brd 10.4.255.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet 10.4.10.220/16 brd 10.4.255.255 scope global secondary eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::216:3eff:fe9d:5968/64 scope link
       valid_lft forever preferred_lft forever
root@bio-netplan:/etc/netplan#

Doing the workaround by original poster 'fixes' the configuration:

root@bio-netplan:/etc/netplan# ip link set dev eth0 down
root@bio-netplan:/etc/netplan# ip link set dev eth0 up
root@bio-netplan:/etc/netplan# ip -c a
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
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
31: eth0@if32: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:16:3e:9d:59:68 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 10.4.10.220/16 brd 10.4.255.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::216:3eff:fe9d:5968/64 scope link tentative
       valid_lft forever preferred_lft forever
root@bio-netplan:/etc/netplan#

I did not have to wait few seconds between down/up though.

tags: added: seg
Revision history for this message
logwatch (logwatch) wrote :

Hello.
I make error in vlan intarface name.
vlans:
    enp1s01.100: #error here
            id: 100
            link: enp1s0
            addresses: [ 10.15.1.1/29 ]
    enp1s0.110:
            id: 110
            link: enp1s0
            addresses: [ 10.15.1.11/29 ]
    enp1s0.120:
            id: 120
            link: enp1s0
            addresses: [ 10.15.1.21/29 ]
Than edit config and try to netplan generate & netplan apply, but nothing change.
DEBUG:Skipping non-physical interface: enp1s01.100

To up working configuration i find issue:

ip link delete enp1s01.100
netplan apply

Mb you need make some instrument to clear intarfaces and run new from config file.

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.