Netplan ignores Interfaces without IP Addresses

Bug #1763608 reported by Johannes Krude on 2018-04-13
This bug affects 19 people
Affects Status Importance Assigned to Milestone

Bug Description

The "manual" method in /etc/network/interfaces resulted in an interface being brought up, but not having an IP address assigned.

When configuring an Interface without an IP Address, netplan ignores the interface instead of bringing it up.

  version: 2
  renderer: networkd
    eth1: {}

Expected result from `netplan apply`: eth1 is brought up.
Actual result: eth1 is still down.

Similarly `netplan generate` does not generate any file in /run/systemd/network for eth1.

Indeed; but this is meant to be that way -- there is no usefulness in having a network device listed in the file without any configuration, as you can always just do "ip link set $device up" to bring it up.

If there is no configuration, the device is left alone, as it should be.

If you must have an interface brought up but with no addresses, you may wish to also set:

dhcp4: off
dhcp6: off

These should force netplan to write out extra systemd configuration to disable DHCP, the new files present for systemd may help bringing up the interface.

affects: nplan (Ubuntu) → netplan
Jean-Daniel Dupas (xooloo) wrote :

"there is no usefulness in having a network device listed in the file without any configuration, as you can always just do "ip link set $device up" to bring it up"

Following this argument, there is no usefulness having netplan at all as you can always configure an interface using ip command line tool.

The main point of such configuration tool is to automate network configuration at boot time. And sometime, a system need to have its interfaces up to run properly, even if they are not configured (OpenVSwitch for instance).

I tried the following config, but it had no effect. Using false instead
of off had also no effect. Using true, resulted in netplan generating a
systemd config.

  version: 2
  renderer: networkd
      dhcp4: off
      dhcp6: off

klockren (jonas-almroth) wrote :

There are in fact many cases where you want an interface brought up without having to apply an IP address.

* A virtual machine host where VM:s are connected to an interface but the host itself should not reside on that network.

* VPN gateways bridging the external interface with an internal interface where the internal interface doesn't need to have an IP address on that network.

* Network sniffers

Not sure if just anyone is allowed to mark a bug as duplicate, but this looks to be the same as bug #1728134:

I also second klockren's comments. The virtual machine case is exactly the situation I am in.

Rami Lehti (ramilehti) wrote :

A workaround is to set a local ipv6 address on the interface.

Currently that is the only way to get the interface up.

Mateusz Pawlowski (teluka) wrote :

@cyphermox: "there is no usefulness in having a network device listed in the file without any configuration, as you can always just do "ip link set $device up" to bring it up"

What about bridges used by LXC/LXD containers ?

You need to have them in UP state to provide connectivity to the containers.

Current workaround is to set local ipv6 address like @ramilehti said.

      - fe80::10/128

Konrad Cempura (kcem) wrote :

I am very disappointed about quality of this software.

Why this is in stable?!
Old solution works fine and it has all features.

Brian Candler (b-candler) wrote :

The case specific to bridging is at #1736975

This links to a workaround at

Andreas Merk (amerk) wrote :

For example kolla/openstack requires running interface without an configuration. It attaches it's open-switch bridges in a later startup process.

Mark Goddard (mgoddard) wrote :

I don't think this is a kolla bug. Marking invalid for kolla.

Changed in kolla:
status: New → Invalid
Slawek Kaplonski (slaweq) wrote :

Can You explain how it's related to Neutron? I don't know about anything like "Netplan" to be used in Neutron.

Andreas Merk (amerk) wrote :

In a general OpenStack installation, especially rolled out via kolla-ansible or openstack-ansible we require network interfaces which are up and without any further configuration. The deployment tools then connect either open-vswitch or linux-bridge to these interfaces. open-vswitch is not making sure that the physical interface is in later process. An example can be shown, if required.
So this is affecting kolla-ansible.

Slawek Kaplonski (slaweq) wrote :

@Andreas, sorry but I still don't understand how it affects neutron. Maybe You can give some more detailed example to explain that.

Regardless of the application stack, it is simply not acceptable a NIC manager that does not allow to have an interface up with not ip configured. This is basically makes the interface usable just at layer 3, how about having something working on the date lync?!?

Tim Bishop (tdb) wrote :

The version of in bionic-proposed appears to resolve this problem for me.

Hi Tim,

which version are you using?

Tim Bishop (tdb) wrote :

ii 0.40.1~18.04.2 amd64 YAML network configuration abstraction for various backends

iain MacDonnell (imacdonn) wrote :

Just ran into this when installing devstack on Ubuntu 18. I configured netplan with:

      id: 818
      link: eno1

When I apply'ed this, it created the link, but did not bring it up.

eno1.818 is referenced in the devstack configuration the "PUBLIC_INTERFACE". It gets plumbed into Open vSwitch to provide neutron a link to the outside world. Neutron expects that this interface already exists and is "up".

The equivalent for Ubuntu 16, which did work:

auto eno1.818
iface eno1.818 inet manual
    vlan-raw-device eno1

Derek DeMoss (derekd) wrote :

I'm in a similar boat as Mateusz Pawlowski (teluka).
We've got a few different VLANs that we bridge off of to give various LXDs access to different things. Specifically: LXD inter-container communication/general colo network access, LXD DB hosts, and or DMZ access.

Especially for the DMZ VLAN, we have a strong desire to prevent any communication between the host and the outside world.. So obviously an IP on the host for the DMZ bridge would be a poor choice.

Why was Netplan deployed in an LTS while missing features? Especially static networking-related features which I'd suspect are used much more often in LTS releases (because servers).

Lessen learned, don't use any Ubuntu products before LTS .3 release

This breaks 802.1q subinterfaces. I use docker libnetwork macvlan subinterfaces. On every reboot the physical interface doesn't come up and containers lose external connectivity.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers