systemd/udev Predictable Network Interface Names
The udevd service has a long history of providing predicatable names for block devices and others. For Fedora 19 we'd like to provide the same for network interfaces, following a similar naming scheme, but only as fallback if not other solution such as biosdevname is installed or the administrator manually defined network interface names via udev rules or the old network scripts.
- Name: Kay Sievers
- Email: kay at redhat dot com
- Targeted release: Fedora 19
- Last updated: 2012-01-29
- Percentage of completion: 95%
The classic naming scheme for network interfaces applied by the kernel is to simply assign names beginning with "eth0", "eth1", ... to all interfaces as they are probed by the drivers. As the driver probing is generally not predictable for modern technology this means that as soon as multiple network interfaces are available the assignment of the names "eth0", "eth1" and so on is generally not fixed anymore and it might very well happen that "eth0" on one boot ends up being "eth1" on the next. This can have serious security implications, for example in firewall rules which are coded for certain naming schemes, and which are hence very sensitive to unpredictable changing names.
Starting with v197 systemd/udev can automatically assign predictable, stable network interface names for all local Ethernet, WLAN and WWAN interfaces. This is a departure from the traditional interface naming scheme ("eth0", "eth1", "wlan0", ...), but should fix real problems.
This feature is about enabling this as default in Fedora, but only as a fallback if the user/administrator did not manually assign names to interfaces via udev rules, or via the old networking scripts, or if biosdevname is installed.
For a longer discussion about this feature see the upstream documentation.
Benefit to Fedora
Stable, predictable, reliable naming of all network interfaces by default, with on-board tools.
It's a simple udev rules file we need to enable or disable in the Fedora RPM spec.
As part of this feature we also want to remove biosdevname from comps, so that it is not installed anymore for new installations.
Optionally, if FESCO desires so we can disable the udev rules files for upgrades (but leave it enabled for new installs), in order to ensure that even on systems that lack biosdevname the network interface naming scheme does not change on upgrades. We don't particularly like a behaviour like this (i.e. where installing an RPM in version 1, and then upgrading to 2 yields a different result than just installing version 2), but we have no better idea either, so we'd like to ask FESCO to decide on this.
How To Test
If you don't have biosdevname installed and no explicit network interface configuration in /etc/sysconfig/network-scripts/, and did not install any udev rules that rename your interfaces for you, then your interfaces should now be named "eno1", "ens1", "enp2s0" or similar.
Normal users generally won't see this, as interface names are not exposed in high-level UIs (or if they are not prominently.)
On upgrades, as biosdevname previously was installed by default and anaconda usually creates an interface configuration file for the hosts' ethernet network connection most pro users/administrators won't see much of this either. That said, as the new scheme also applies to USB devices and WLAN/WWAN where biosdevname did not apply this might also affect these systems.
On new installs, pro users/administrators will see this change.
We can turn the udev rule that enables this fallback default off/or on with a simple RPM spec line.
We should direct the user to http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames and include information how the new naming scheme can be turned off or altered.
Users upgrading from previous releases may need to worry about updating ifcfg files in /etc/system/network-scripts to refer to new device names rather than old ones. However, as noted above, most upgrading users will have biosdevname installed, and so will continue to see the old names.
Other than that it should be enough to just announce availability of this feature, plus a paste from the Summary section of this feature page-