Netplan's interface naming and issues with it
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:
network: version: 2 renderer: networkd ethernets: eno1: 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/10-netplan-eno1.network (where eno1 is
being used as a section name) that will start out with:
[Match] Name=eno1
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:
network: version: 2 renderer: networkd ethernets: mainif: match: 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.
|
|