Netplan's interface naming and issues with it

October 29, 2019

Back in March, I wrote an entry about our problem with Netplan and routes on Ubuntu 18.04. In a comment on the entry, Trent Lloyd wrote a long and quite detailed reply that covered how netplan actually works here. If you use Netplan to any deep level, it is well worth reading in whole. My short and perhaps inaccurate summary is that Netplan is mostly a configuration translation layer on top of networkd, and its translation is relatively blind and brute force. This straight translation then puts limits on what alterations and matchings you can do, because of how Netplan will translate these to networkd directives and how they will work (or not work).

One of the things that this creates is a confusing interface naming problem. Suppose that you have a standardly created Netplan YAML file that looks like this:

  version: 2
  renderer: networkd
      addresses: [...]

The eno1 looks like it is an interface name, but it is actually two things at once; it is both a Netplan section name (this is my name for it; Netplan generally calls it a 'device name') and an network interface name. This section will cause Netplan to create a file /run/systemd/network/ (where eno1 is being used as a section name) that will start out with:


My original problem with routes doesn't actually require us to attach routes to an interface by name, as I thought when I wrote the entry. Instead it requires us to attach routes to a Netplan section by name, and it is just that Ubuntu creates a Netplan configuration where the two are silently the same.

(This split is also part of my confusion over what was possible with netplan wildcards. Netplan wildcards are for matching interface names, not section names. Because of how Netplan creates networkd configuration files and how networkd works, all things that are going to apply to a given interface must have the same section name, as I understand the situation.)

Trent Lloyd ends his comment (except for a parenthetical) by asking:

[...] Perhaps we should look at changing the default configurations to show a functional 'name' so that this kind of task is more obvious to the average user?

I endorse this. I think that it would make things clearer and simpler if there was a visible split in the default configuration between the section name and the interface name, so that my previous example would be:

  version: 2
  renderer: networkd
        name: eno1
      addresses: [...]

This is more verbose for a simple case, but that is the YAML bed that Netplan has decided to lie in.

This would make it possible to write generic Netplan rules that applied to your main interface regardless of what it was called, and provide silent guidance for what I now feel are the best practices for any additional interfaces you might later set up.

(Then it would be good to document the merging rules for sections, such as that you absolutely have to use 'mainif:' (or whatever) for everything that you are going to merge together and there is no wildcard matching on that level. In general the Netplan documentation suffers badly from not actually describing what is actually going on; since what is actually going on strongly affects what you can do and what will and won't work, this is a serious issue.)

Another approach would be to allow defining a Netplan level 'section alias', so your section would still be called 'eno1' but it could have the alias of 'mainif', and then any other Netplan configuration for 'mainif' would be folded in to it when Netplan wrote out the networkd configuration files that actually do things.

PS: Since Netplan has two backends, networkd and NetworkManager, your guess is as good as mine for how this would get translated in a NetworkManager based setup. This uncertainty is one of the problems of making Netplan so tightly coupled to its backend in what I will politely call an underdocumented way.

PPS: None of this changes my general opinion of Netplan, which is that I hope it goes away.

Written on 29 October 2019.
« One of XHTML's practical problems was its implications for web page generation
Chrony has been working well for us (on Linux, where we use it) »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Tue Oct 29 23:00:05 2019
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.