vlan usage requires an intermediate step

Bug #1738058 reported by Mathieu Trudel-Lapierre
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
nplan (Ubuntu)
Won't Fix
Undecided
Unassigned
systemd (Ubuntu)
Invalid
Undecided
Dimitri John Ledkov

Bug Description

If I try to apply vlans directly:

network:
  version: 2
  renderer: networkd
  ethernets:
    eth0: {}
  vlans:
    vlan1:
      id: 1
      link: eth0
      addresses: [ 192.168.0.10/23 ]
    vlan10:
      id: 10
      link: eth0
      addresses: [ 10.0.0.5/24 ]

The vlan devices never come up, they are left in degraded state by networkd. If I define an address for eth0, then eth0 and all of the vlans will have the same address. Needless to say, this doesn't work.

If I use an intermediary device instead, such as a bond:

network:
  version: 2
  renderer: networkd
  ethernets:
    eth0: {}
  bonds:
    vmaster:
      interfaces: [ eth0 ]
  vlans:
    vlan1:
      id: 1
      link: vmaster
      addresses: [ 192.168.0.10/23 ]
    vlan10:
      id: 10
      link: vmaster
      addresses: [ 10.0.0.5/24 ]

Then the vlans are correctly applied and brought up by systemd.

I think this is either a systemd bug or a netplan bug; it's possible we don't generate the config quite in the way that systemd expects it (even though it looks straightforward enough).

Revision history for this message
Dimitri John Ledkov (xnox) wrote :

That sounds like a bug.

I have only previously used vlans on top of bonds.

Changed in systemd (Ubuntu):
assignee: nobody → Dimitri John Ledkov (xnox)
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in nplan (Ubuntu):
status: New → Confirmed
Changed in systemd (Ubuntu):
status: New → Confirmed
Revision history for this message
Dan Streetman (ddstreet) wrote :

please reopen if this is still an issue

Changed in systemd (Ubuntu):
status: Confirmed → Invalid
Revision history for this message
Lukas Märdian (slyon) wrote :

This seems to be working nowadays. I cannot reproduce using the config provided in the description:

$ netplan apply
$ ip 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
2: vlan10@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:16:3e:f5:92:b3 brd ff:ff:ff:ff:ff:ff
    inet 10.0.0.5/24 brd 10.0.0.255 scope global vlan10
       valid_lft forever preferred_lft forever
    inet6 fe80::216:3eff:fef5:92b3/64 scope link tentative
       valid_lft forever preferred_lft forever
3: vlan1@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:16:3e:f5:92:b3 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.10/23 brd 192.168.1.255 scope global vlan1
       valid_lft forever preferred_lft forever
    inet6 fe80::216:3eff:fef5:92b3/64 scope link tentative
       valid_lft forever preferred_lft forever
84: eth0@if85: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:16:3e:f5:92:b3 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet6 fe80::216:3eff:fef5:92b3/64 scope link
       valid_lft forever preferred_lft forever
$ networkctl
IDX LINK TYPE OPERATIONAL SETUP
  1 lo loopback carrier unmanaged
  2 vlan10 vlan routable configured
  3 vlan1 vlan routable configured
 84 eth0 ether routable configured

4 links listed.

Please re-open if this is still an issue.

Changed in nplan (Ubuntu):
status: Confirmed → Won't Fix
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.