Proposal: enable stateless persistant network interface names

Fri May 8 19:37:51 BST 2015

Just my 0.02$ against using the BIOS method.

I have and Do see inconsistent bios vendor naming used from release to
release of their Firmware updates. I have had to fix HP Propliants servers
numerous time due to a firmware update changing the number and/or order of
SATA ports, PCI and other things.

So I for one dislike using bios provided info for any sort of userland
namespace mapping method due to the above issues caused.

-Joel

On 8 May 2015 at 01:59, Martin Pitt <mpitt at debian.org> wrote:

> Hello Debianists,
>
> Quick intro to the problem: The kernel generally detects network
> interfaces ("eth0", "wlan1", etc.) in an unpredictable and often
> unstable order. But in order to refer to a particular one in
> /etc/network/interfaces, firewall configs etc. you need to use a
> stable name.
>
> The general schema for this is to have an udev rule which does some
> matches to identify a particular interface, and assigns a NAME="foo"
> to it. Interfaces with an explicit NAME= property get that name, and
> others just get a kernel driver default, usually ethN, wlanN, or
> sometimes others (some wifi drivers have their own naming schemas).
>
> Over the years several solutions have appeared:
>
>  - [mac] For many many years our we have installed an udev rule
>    /lib/udev/rules.d/75-persistent-net-generator.rules which on first
>    boot creates a MAC address → current name mapping and writes
>    /etc/udev/rules.d/70-persistent-net.rules.
>
>  - [biosdevname] is a package originally written by Dell (IIRC),
>    which reads port/index/slot names from the BIOS and sets them in
>    /lib/udev/rules.d/71-biosdevname.rules.
>
>  - [ifnames] For about two years (since 197) upstream's udev has a
>    builtin persistant name generator which checks firmware/BIOS
>    provided index numbers or slot names (like biosdevname), falls back
>    to slot names (PCI numbers, etc., in the spirit of
>    /dev/disks/by-path/), and then optionally (not done by default)
>    falls back to MAC address (similar to [mac]). This happens in
>    /lib/udev/rules.d/80-net-setup-link.rules.
>
> Note that these solutions can, and do get combined: The first rule
> which sets a name wins, i. e. currently [biosdevname] beats [mac]
> beats [ifnames].
>
> Details about [mac]
> -------------------
> This is our current solution which applies to most hardware out there.
> It was an useful hack almost a decade ago, but it really shows its
> age:
>
>   * It's subject to inherent race conditions (detecting a new device
>     vs. renaming an existing one), which sometimes leads to devices
>     being called "renameX" and breaking your boot.
>
>   * It requires a writable /etc/udev/rules.d/ for persistantly storing
>     the assignment. We don't want/have that with system-image
>     (touch/snappy).
>
>   * It's incompatible with how cloud images operate, as the "physical"
>     (emulated from the VM host) devices can change between boots.
>     Hence we maintain an ever-growing blacklist in
>     75-persistent-net-generator.rules which causes bugs and pain with
>     each new cloud or virtualization provider. Recent examples:
>     LP #1437375, #1367883, #1361272, #1317776, #1274348, #1099278.
>
> Support for [mac] got dropped in upstream udev two years ago, and
> since then we have maintained it on the Debian/Ubuntu side.
>
> Details about [biosdevname]
> ---------------------------
> This is a very good approach in principle, but unfortunately most
> desktop and laptop BIOSes out there don't actually set this kind of
> information, and of course none of the non-x86 machines do. I don't
> know how pervasive it is on dedicated server hardware. So this only
> actually helps for a small minority of cases, and currently falls back
> to [mac].
>
> biosdevname isn't packaged in Debian, so it's not much of a concern in
> a Debian context. Some people might have installed the package from
> Dell or Ubuntu.
>
> Details about [ifnames]
> -----------------------
> This is a generic solution which extends the [biosdevname] idea and
> thus applies to all practical cases and all architectures. It doesn't
> need any persistant state (i. e. dynamic /etc/udev/rules.d/) and thus
> applies nicely to snappy/touch, and also avoids the race condition.
>
> The main downside is that by nature the device names are not familiar
> to current admins yet. For BIOS provided names you get e. g. ens0, for
> PCI slot names enp1s1 (ethernet) or wlp3s0 (wlan). But that's a
> necessary price to pay (biosdevname names look similar).
>
> As this hasn't been discussed yet, Debian and Ubuntu disable this by
> default. You can opt into this by booting with "net.ifnames=1" (which
> is a patch against upstream: there you disable it by booting with
> net.ifnames=0 or disabling 80-net-setup-link.rules).
>
> Proposal
> --------
> I propose to retire [mac], i. e. drop
> /lib/udev/rules.d/75-persistent-net-generator.rules and enable
> [ifnames] by default.
>
> This will provide the new stable interface names for all new
> installations, stop the different handling of server/client, work with
> system-image, and stops the woes cloud providers have with Ubuntu's
> [mac].
>
> I'm happy to ship a commented example udev rule that shows how to
> configure your own names, if you want to continue using MAC based
> schemas, or call your interfaces "internet" and "intranet" or the
> like.  This makes it easier to see how to do custom naming than having
> to start from scratch.
>
> For upgrades: As we don't know what refers to existing stable network
> names, we can't ever safely remove a generated
> /etc/udev/rules.d/70-persistent-net.rules. So when we do the above,
> names on existing installations will *not* change (as
> 70-persistent-net.rules trumps [ifnames]).
>
> So we can only let time and replacing/reinstalling machines take care
> of this. /etc/udev/rules.d/70-persistent-net.rules requires zero
> maintenance from us (it's just like the admin had manually set their
> own rules).
>
> Opinions?
>
> FTR, I also posted a similar mail to
> https://lists.ubuntu.com/archives/ubuntu-devel/2015-May/038761.html
>
> If you see this via debian-devel@, please keep CC'ing pkg-systemd@,
> I'm not subscribed to d-devel at .
>
> Thanks,
>
> Martin
>
> --
> Martin Pitt                        | http://www.piware.de
> Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20150508/33af1afa/attachment-0002.html>