Cant set up 'empty bridge' with IP-addresses configure

[Sander Smeenk]

I want to set up 'empty' bridges. They don't hold any interfaces, but do have IPs bound to them.
This does not work:

  bridges:
    virbr0:
      dhcp4: no
      dhcp6: no
      accept-ra: no
      interfaces: [ ] # leaving this out give same result
      addresses: [10.255.255.1/24, "2001:db8:123:4:567:89a:bcd:ef/64"]
    virlan0:
      dhcp4: no
      dhcp6: no
      accept-ra: no
      interfaces: [ ] # leaving this out give same result
      addresses: [10.33.41.1/24]

Result is the two bridge interfaces are created, but IP configuration is not applied. The bridge interfaces are 'state DOWN' in 'ip addr show' output. The 'networkctl' tool lists these devices as 'configuring:

IDX LINK TYPE OPERATIONAL SETUP
  4 virlan0 ether no-carrier configuring
  5 virbr0 ether no-carrier configuring

[Sophie Schumann (sharkynoms)]

I also encountered this and haven't found a workaround as of yet.

  bridges:
    virbr0:
      #interfaces: []
      optional: true
      dhcp4: no
      dhcp6: no
      parameters:
        stp: false
        forward-delay: 0
      addresses:
        - 10.5.0.1/24

results in an no-carrier/*configuring* bridge.

[MelkorLord (melkorlord)]

I found some *kind* of workaround as it does not involve netplan directly. In the generated *.network file add "ConfigureWithoutCarrier=true" in the "[Network]" section.

At least now, networkd will assign the IP address to the interface-less bridge.

You'll still have to bring the bridge interface UP manually as I haven't found a way to automate this via networkd nor via netplan.

My personal opinion: It's a bit sad but after a lot of fiddling, I find netplan is nowhere near production quality nor ready. It seems to follow the current trend of put-everything-in-the-cloud where instances need only a very basic configuration 99.99% of the time just to be network reachable. Seeing the various bug reports as well as fiddling around with it show it lacks support for *a* *lot* of common/usual *real* *world* network scenarios, as opposed to those cloud-freaks idea of what the world is! I hope it'll improve but forcing netplan in a LTS release which such a lack of features wasn't the best idea IMHO.

[Daniel Axtens (daxtens)]

A fix for this landed in git 10 days ago: https://github.com/CanonicalLtd/netplan/commit/978e20f902f6b92a46dc6e0050e2172e834e4617

It should be available now in Cosmic; I don't know if it is being backported to Bionic. I don't do backports so your best bet might be asking on #netplan on freenode.

[Drew Freiberger (afreiberger)]

I had an interesting experience in Bionic with netplan. setting
bridges:
  br0:
    interfaces: []
    addresses: [10.0.0.x/29]
before the "ethernets" section resulted in every interface on the host getting assigned this address and brought state-UP though physical-links were down.

[Ewen McNeill (ewen)]

I ran into this issue (on Ubuntu 18.04 LTS / Bionic) yesterday. I have some bridges for virtual machines to connect to, which have IPv4/IPv6 addresses associated with them, and some services that listen only on those addresses (just for the VMs benefit), so I need the bridges to start earlier than, eg, libvirt bridges. But since traffic from those VMs is *routed* not bridged to the outside world, there's no relevant physical interface to bridge them to.

I see (in https://bugs.launchpad.net/netplan/+bug/1773997/comments/3) there was a fix committed to the very next Ubuntu release (Cosmic; 18.10), almost a year ago. But it looks like it never got backported to 18.04 / Bionic.

Since 18.04 is a LTS release, and people will be running into this for years, and the fix (https://github.com/CanonicalLtd/netplan/commit/978e20f902f6b92a46dc6e0050e2172e834e4617) looks pretty small (almost all of the commit is new tests), I'd really appreciate seeing the fix backported to 18.04 LTS / Bionic as well.

Ewen

PS: My eventual work around was to add some VLANs on a spare external interface *and* arrange for that spare interface to be cabled to something that could provide it with ethernet carrier. Just so everything could start up in the right order. Which is an ugly physical kludge to work around netplan (in 18.04 LTS) being unable to bring up any kind of "just an IP, inside the box" interface.

[Aleksey Zvyagintsev (azvyagintsev)]

@daxtens any chance to backport it for bionic? it's kinda pity bug for LTS release...

[Mathieu Trudel-Lapierre (cyphermox)]

It should already be in Bionic; 0.97 is what is available in all releases at this moment, so if it's not working, either we didn't quite get the fix right, or your setup is slightly different, enough to make the fix not work for you.

Could you please share your config so we can have a look and try to reproduce the issue?

[Ewen McNeill (ewen)]

Ubuntu 18.04 LTS, config with work around (and eno2 physically patched to something providing Ethernet carrier):

-=- cut here -=-
network:
    ethernets:
        eno1:
            addresses:
                - [IPv4]
                - [IPv6]
            gateway4: [IPv4]
            gateway6: [IPv6]
            accept-ra: false
            nameservers:
                search:
                    - [domain]
                addresses:
                    - [IPv6]
                    - [IPv4]
                    - [IPv4]
        eno2:
            dhcp4: false
    vlans:
      eno2.2:
          id: 2
          link: eno2
          optional: true
      eno2.203:
          id: 203
          link: eno2
          optional: true
    bridges:
        br-sv:
            interfaces: [eno2.2]
            addresses:
                - [IPv4]
                - [IPv6]
        br-dmz:
            interfaces: [eno2.203]
            addresses:
                - [IPv4]
                - [IPv6]
    renderer: networkd
    version: 2
-=- cut here -=-

If I remove the "vlans" section, remove the "eno2" interface, and remove the "interfaces: [eno2.NNN]" bits from the bridges, then there was a very long delay (minutes) before the system booted, and the bridge interfaces didn't start early enough for other services that bound to those IP addresses to start.

And yes, I do seem to have 0.97 installed (now). I haven't retested recently (the host is in colo, without OOB access, and I don't want to lose access to it). But given 0.97 apparently went into 18.04 in early May, and I'd installed all updates before putting the system into colo, I believe I would have had 0.97 installed by then.

-=- cut here -=-
ewen@naosr620:~$ dpkg -l | grep netplan
ii netplan.io 0.97-0ubuntu1~18.04.1 amd64 YAML network configuration abstraction for various backends
ewen@naosr620:~$
-=- cut here -=-

Ewen

[Launchpad Janitor (janitor)]

[Expired for netplan because there has been no activity for 60 days.]