netplan does not bring up anonymous bridge on boot

Bug #1736975 reported by Colin on 2017-12-07
140
This bug affects 26 people
Affects Status Importance Assigned to Milestone
netplan
Medium
Mathieu Trudel-Lapierre
netplan.io (Ubuntu)
Medium
Unassigned
Bionic
Undecided
Unassigned
nplan (Ubuntu)
Medium
Unassigned

Bug Description

[Impact]
Netplan users setting up bridges.

[Test cases]
1) Add a new bridge configuration in netplan yaml, without an IP address set:

  [...]
  bridges:
    br0:
      interfaces: [ interface ]
      dhcp4: false
      parameters:
        stp: false
        forward-delay: 0

[Regression potential]
Possible regression scenarios might be for a configured bridge not to come up / not be created or added by systemd-networkd when the network is configured; or for a bridge to be configured with addresses that should not be present (ie. dhcp when it is not enabled, or link-local address when not configured).

---

Configuring "/etc/netplan/01-netcfg.yaml" with an anonymous bridge seems to require running "ip link set dev br0 up" to bring the bridge up after boot. A bridge configured with an IP address is automatically up after boot.

This is only a problem if you want an anonymous bridge which comes up automatically after boot. For example, if you preferred to isolate host traffic from your autostarting virtual machine traffic.

Configuration that results in the bridge being down after boot:
network:
  version: 2
  renderer: networkd
  ethernets:
    enp22s2:
      dhcp4: yes
    enp22s3:
      dhcp4: no
  bridges:
    br0:
      interfaces: [enp22s3]
      dhcp4: false
      parameters:
        stp: false
        forward-delay: 0

Enabling DHCP results in a bridge that is automatically up after boot:
network:
  version: 2
  renderer: networkd
  ethernets:
    enp22s2:
      dhcp4: yes
    enp22s3:
      dhcp4: no
  bridges:
    br0:
      interfaces: [enp22s3]
      dhcp4: true
      parameters:
        stp: false
        forward-delay: 0

Setting a static IP address results in a bridge that is automatically up after boot:
network:
  version: 2
  renderer: networkd
  ethernets:
    enp22s2:
      dhcp4: yes
    enp22s3:
      dhcp4: no
  bridges:
    br0:
      interfaces: [enp22s3]
      dhcp4: false
      addresses: [192.168.1.100/24]
      parameters:
        stp: false
        forward-delay: 0

ProblemType: Bug
DistroRelease: Ubuntu 17.10
Package: nplan 0.30
ProcVersionSignature: Ubuntu 4.13.0-17.20-generic 4.13.8
Uname: Linux 4.13.0-17-generic x86_64
ApportVersion: 2.20.7-0ubuntu3.5
Architecture: amd64
Date: Thu Dec 7 11:06:25 2017
ProcEnviron:
 LANGUAGE=en_CA:en
 TERM=screen
 PATH=(custom, no user)
 LANG=en_CA.UTF-8
 SHELL=/bin/bash
SourcePackage: nplan
UpgradeStatus: No upgrade log present (probably fresh install)

Colin (colin-) wrote :
Launchpad Janitor (janitor) wrote :

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

Changed in nplan (Ubuntu):
status: New → Confirmed
ERIC ROESINGER (egr10) wrote :

This is going to be a particular nuisance for those hosting Xen farms with Ubuntu as Dom0.

Considering Ubuntu 17.10 is the only distro I found supporting a lete-enough Xen build for my purposes, “out of the box”, the two reports including mine are probably an “iceberg tip”.

I am presently seeking work-arounds to bring an interface up without triggering link-local ipv6 address assignment (which is inapporpriate for an anonymous bridge).

Nikolas Britton (nbritton) wrote :

You might be able to work around this by setting the ip to 0.0.0.0/32. However, when tested that it seem to DHCP assign an ipv6 address, which I assume is another bug.

Nikolas Britton (nbritton) wrote :

Additionally, this is still a bug in Ubuntu 18.04.

Daniel Axtens (daxtens) wrote :

I've figured out how to work around this. It's all documented at http://djanotes.blogspot.com/2018/04/anonymous-bridges-in-netplan.html.

In short, I tell systemd-networkd directly to bring up the bridge. To do this, in addition to the rest of the configuration in netplan, I create /etc/systemd/network/br0.network with the following:

[Match]
Name=br0

[Network]
LinkLocalAddressing=no
IPv6AcceptRA=no

This leads to the interface being brought up and not getting an IPv4 or IPv6 address.

In this case you may set:

 accept-ra: no

In your netplan YAML; this will at least set IPv6AcceptRA=no, which should be sufficient for the bridge to come up, and is already available in netplan 0.34.1 (in Ubuntu 18.04)

Controlling LinkLocalAddressing= will remain as a TODO.

Changed in nplan (Ubuntu):
status: Confirmed → Triaged
importance: Undecided → Medium
Cloyce D. Spradling (cloyce) wrote :

Adding "accept-ra" to the netplan YAML for the bridge is not sufficient to make the bridge come up, at least with 18.04 updated as of 19 April 2018.

Can confirm - adding accept-ra still doesn't bring up the bridge.

Nplan Version: 0.36.1

https://github.com/CanonicalLtd/netplan/tree/carrier has a potential fix now. I'll test it some more and check some corner-cases where it might break, and release with that soonish.

Changed in netplan:
status: New → In Progress
importance: Undecided → Medium
assignee: nobody → Mathieu Trudel-Lapierre (cyphermox)
Changed in netplan.io (Ubuntu):
status: New → Triaged
importance: Undecided → Medium

I an using Ubuntu Server as a KVM-host, relying on multiple anonymous bridges, and am suffering from this bug under 18.04.

For others needing a workaround: I do configure the bridges with netplan.io as usual and bring up the bridges by defining in file

/etc/systemd/network/10-netplan-brUp.network
----------------------------------------------
[Match]
Name=brLAN*
Name=brDMZ*

[Network]
LinkLocalAddressing=no
ConfigureWithoutCarrier=true
----------------------------------------------

bringing up multiple bridges following the naming scheme brLAN0, brLAN1, ... , brDMZ0, brDMZ1, ...

I do prefer this solution over some other workarounds using systemd service files or others, that I found on the net. Maybe this helps...

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package netplan.io - 0.39

---------------
netplan.io (0.39) cosmic; urgency=medium

  * New upstream release:
    - Allow link-local addresses to be configured. (LP: #1771704)
    - Forces bridges with no addresses to be brought online. (LP: #1736975)

 -- Mathieu Trudel-Lapierre <email address hidden> Mon, 16 Jul 2018 08:15:05 -0400

Changed in netplan.io (Ubuntu):
status: Triaged → Fix Released
Jim (jimbolino) wrote :

will this new version be available via bionic-updates ?
or will the fix be back-ported to 0.36.x ?

Mike Pontillo (mpontillo) wrote :

I had just filed bug #1782155, which may be a duplicate of this one.

Adding 'accept-ra: no' does not work around the issue for me.

I'm happy to test the newer version of Netplan though; is it available in a PPA pending SRU?

MelkorLord (melkorlord) wrote :

I just tested netplan 0.39 on a 18.04 VM and it does not fix the problem, the bridge is still DOWN upon creation :-(

netplan
----------------------------
network:
  version: 2
  bridges:
    br0:
      dhcp4: false
      addresses:
        - 10.10.10.254/24
      parameters:
        stp: false
        forward-delay: 0
----------------------------

which generates (netplan generate) the following files in /run/systemd/network/

10-netplan-br0.netdev
----------------------------
[NetDev]
Name=br0
Kind=bridge

[Bridge]
ForwardDelaySec=0
STP=false
----------------------------

10-netplan-br0.network
----------------------------
[Match]
Name=br0

[Network]
LinkLocalAddressing=ipv6
Address=10.10.10.254/24
ConfigureWithoutCarrier=yes
----------------------------

Now, upon "systemctl restart systemd-networkd", "ip addr" show "br0" with the correct IP address but still "DOWN"!

----------------------------
4: br0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
[...]
----------------------------

The problem is not solved!

piersh (piersh) wrote :

this is still broken in bionic.

Lyas Spiehler (lspiehler) wrote :

I am running the latest version of Ubuntu 18.04 as a KVM hypervisor with multiple bridges. My bridges are down after reboot as described in this bug. Enabling DHCP does make the bridge come up, but I only need layer 2 on the bridges and I don't want an IP. I'm assuming assigning an IP will also work around the issue. On RHEL the config would be ONBOOT=YES. How can I make this bridge come up at boot without assigning an IP address? Here is my config:

network:
  version: 2
  renderer: networkd
  ethernets:
    enp3s0f0:
      dhcp4: no
      dhcp6: no
    enp3s0f1:
      dhcp4: no
      dhcp6: no
    enp4s0f0:
      dhcp4: no
      dhcp6: no
    enp4s0f1:
      dhcp4: no
      dhcp6: no
  bonds:
    bond0:
      interfaces: [enp3s0f0, enp3s0f1, enp4s0f0, enp4s0f1]
      addresses: [ 10.2.10.221/24 ]
      gateway4: 10.2.10.1
      nameservers:
        search: [smhplus.org]
        addresses: [10.2.11.226, 10.2.11.227]
      parameters:
        mode: 802.3ad
        mii-monitor-interval: 1
  vlans:
    vlan1116:
      id: 1116
      link: bond0
  bridges:
    br1116:
      interfaces: [vlan1116]

Brian Candler (b-candler) wrote :

> How can I make this bridge come up at boot without assigning an IP address?

See the link earlier in this thread: http://djanotes.blogspot.com/2018/04/anonymous-bridges-in-netplan.html

Changed in netplan:
status: In Progress → Fix Released
description: updated

Hello Colin, or anyone else affected,

Accepted netplan.io into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/netplan.io/0.40~18.04.1 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-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. 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 netplan.io (Ubuntu Bionic):
status: New → Fix Committed
tags: added: verification-needed verification-needed-bionic
Jolrael (bas) wrote :

I have tested the package in proposed and it solved the issue; there is now a 2nd systemd file generated in /run/systemd/network called <netplan config filename>.network (same as in the workaround). The bridge is now automatically brought up, also after a reboot.

tags: added: verification-done-bionic
removed: verification-needed-bionic
Trevor Lafrank (tlafrank) wrote :

I can also confirm that the new package (from the proposed archive) now allows the bridge interface to come up at boot.

My new package (apt list netplan.io): netplan.io/bionic-proposed,now 0.40~18.04.1 amd64 [installed]

My netplan config:
network:
    version: 2
    renderer: networkd
    ethernets:
        enp3s0:
            addresses: []
            dhcp4: true
            optional: true
        enp5s0:
            addresses: []
            dhcp4: true
            optional: true
    bridges:
      br0:
        interfaces:
          - enp3s0
          - enp5s0
        dhcp4: no

This was failing prior to the installation of this package, with no other system changes in the meantime. Thanks

Łukasz Zemczak (sil2100) wrote :

Hello Colin, or anyone else affected,

Accepted netplan.io into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/netplan.io/0.40.1~18.04.1 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-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. 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.

tags: added: verification-needed-bionic
removed: verification-done-bionic

ubuntu@new-man:~$ dpkg -l netplan.io | grep ii
ii netplan.io 0.40.1~18.04.1 amd64 YAML network configuration abstraction for various backends

I have reverified this SRU using Trevor's netplan yaml. The bridge interface is correctly brought up at boot, and the right addresses are set to the right interfaces:

ubuntu@new-man:~$ ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: ens6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master mybr0 state UP mode DEFAULT group default qlen 1000
    link/ether 52:54:00:ab:37:d8 brd ff:ff:ff:ff:ff:ff 3: mybr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 4a:8c:3f:c1:41:f4 brd ff:ff:ff:ff:ff:ff

tags: added: verification-done-bionic
removed: verification-needed verification-needed-bionic
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers