Proposal: enable stateless persistant network interface names

[Marco d'Itri]

On May 08, Martin Pitt <mpitt at debian.org> wrote:

> I propose to retire [mac], i. e. drop
> /lib/udev/rules.d/75-persistent-net-generator.rules and enable
> [ifnames] by default.
I see a large enough consensus about switching by default to ifnames, 
and I believe that the few people who want MAC-based names for USB 
interfaces can easily set NamePolicy=mac or write a custom rule.

I am not sure that we really need to retire 75-persistent-net-generator 
right now: the annoying part to maintain is the kernel patch which we 
will need anyway for at least a couple of releases, and once we make it 
use em* or eno* instead of eth* then it should be robust.
It is trivial to make it opt-in by setting something like net.ifnames=0 
(or even a different and specific value), and we can revisit this 
decision when we will be closer to the release.

> 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).
Actually it requires us to keep maintaining the 
Revert-udev-network-device-renaming patch as long as there will be 
systems with a 70-persistent-net.rules file renaming eth* to eth*.


I believe that firmware-based device names work well enough in practice 
since RHEL 7 uses them by default: I tend to trust a market-based 
approach to maintenability more than anecdote from a very selected 
population like the debian-devel@ subscribers.
This is the relevant documentation, which I strongly recommend everybody 
interested in this issue to read:

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/ch-Consistent_Network_Device_Naming.html
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/sec-Understanding_the_Device_Renaming_Procedure.html
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/sec-Understanding_the_Predictable_Network_Interface_Device_Names.html
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/sec-Consistent_Network_Device_Naming_Using_biosdevname.html

Maybe biosdevname would be nice to have, but:
- somebody needs to actually maintain it in Debian
- by default it only works on Dell systems
- it is not loved by the udev/systemd upstream maintainers
- it does not seem to me to provide any benefit over the firmware-based 
  names since in practice both would use by default an interface index 
  in the common case

So I do not think that we need to care about it.

An obvious downside is longer names for devices which do not provide 
ID_NET_NAME_ONBOARD: e.g. the WiFi card in my Dell laptop does 
not (wlp2s0), but the Ethernet port does (eno1).
It will be even worse when not even ID_NET_NAME_PATH is defined (e.g. on 
my Allwinner-based ARM computer), which means that interfaces will get 
a mac-based name like enx028909xxxxxx.
But if somebody cares about the aesthetic value of network interface 
names then they can probably write a custom udev rule to rename them,
or keep using 75-persistent-net-generator if we can keep it around.

(I believe that it would be a good idea for the ARM porters to have 
a look at which values are exported by their network drivers, because 
probably nobody else is going to work on this any time soon.)

FWIW, I did a quick survey of my hardware:
- HP G8: OK
- HP G8 + add-on Intel card: OK (but obviously no index)
- HP G8 + FlexFabric: OK
- HP Gen9 + FlexFabric: stupid but will work (the SMBIOS indexes start 
  from 49 instead of 1!)
- Cisco UCS: OK
- IBM BladeCenter + Emulex CNA: very broken (only eth0 has an index!
  I only checked biosdevname but it should not matter)
- IBM Flex + Emulex CNA: broken like the BladeCenter
- Some Intel-based Supermicro: OK

(If any of the HP people here can find out who is responsible to fix 
the Gen9 BIOS then I can have my HP account manager make a business case 
for it. Submitting a support case would be time consuming for me and 
unnecessarily cruel for the support people...)

-- 
ciao,
Marco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 648 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20150511/655c7292/attachment-0002.sig>