On Tue, Dec 20, 2016 at 11:21 AM, Heiko Baums <li...@baums-on-web.de> wrote: > Am 20.12.2016 um 05:23 schrieb Andrej Rode: >> >> Yeah they make life easier. From your talk you never had a problem >> with eth<0,10> switching names after boot. Everyone who had them >> appreciates predictable network interfaces. > > Everyone who had them could learn how to write simple udev rules to > get fixed eth<0,10> names after every boot. No systemd and no > "predictable" names necessary. > > Nevertheless I'm still wondering what's so predictable at those > incomprehensible, cryptic device names anyway. And I don't want to > know that.
The predictable interface names (the systemd developers have an unfortunate knack for misnaming ) arose for a multi-NIC world where 1) the kernel's ethX name for a particular NIC can change from one boot to another 2) udev renaming NICs "ethX" can break if you rename a NIC "eth4" and the kernel later names another NIC "eth4" as it enumerates the hardware. Given the above, the udev maintainers could've implemented a policy that a NIC couldn't be renamed "ethX" but they decided no longer to default to MAC-based naming rules and came up with naming based on whether a NIC is an on-board one (enoX), a PCI Express one (ensX), a PCI one (enpXsY), etc. In doing so, they defaulted to names that are more complex than the kernel's (ethX) but you can now replace a NIC without editing a file under "/etc/udev/rules.d/".
