Page MenuHomeVyOS Platform

support for Predictable Network Interface Names


Add support for

This is not trivial tasks since some code relies on regex searches like eth*
All such code should be identified and refactored


Difficulty level
Easy (less than an hour)
Why the issue appeared?
Design mistake

Event Timeline

syncer created this task.Mar 14 2017, 9:32 PM
afics added a subscriber: afics.Mar 15 2017, 8:19 AM
syncer assigned this task to UnicronNL.Mar 20 2017, 7:34 PM
syncer added a subscriber: UnicronNL.

@UnicronNL it seems we need to update systemd to 220 or higher to get this working
also, for now we can just disable it before we prepare environment.
But still will be possible to enable it on case by case basis

We had some preliminary discuss with @dmbaturin about how to deal with this
and came across an idea that we can use link files to rename devices in correct order via link files
Once we refactor old scripts that rely on old naming scheme(e,g, ethX) we can switch fully to predictable names

pasik added a subscriber: pasik.Oct 27 2017, 10:03 PM
syncer changed the subtype of this task from "Task" to "Feature Request".Oct 18 2018, 5:47 AM
syncer changed the edit policy from "Task Author" to "Custom Policy".Oct 21 2018, 6:41 PM
syncer set Version to -.

While I agree that our scripts should be less dependent on interface names, I'm not sure if we should support so called "predictable" interface names, since for the users they are anything but predictable. Definitely not in 1.2.0

@dmbaturinI think you misunderstand the concept of this task
this also includes interfaces naming according to their placement,
and we already have it and used before with link files.
Idea is to prevent random assignment of eth0-ethX names
without link files nic port order always different even on devices with the same hardware (we already saw that in various occasions
Idea is to provide a mechanism that will allow defining an order of nic ports, like before was possible with hw-id (which not works anymore)

Just ran into this with 1.2 RC9. eth0 and eth2 swapped devices, presumably due to differences in the timing of device init in the new kernel version, meaning DHCPd ran on the WAN interface, which the upstream won’t appreciate. Having proper static device naming would have prevented this.

This is probably too major a change for 1.2, but should definitely be considered for 1.3.

yun added a subscriber: yun.Apr 23 2019, 8:13 PM

on any equipment with many interfaces, you would expect "port 0" to be "eth0", etc. As vendors are likely to give incremental mac addresses to their interfaces, could the hardware mac address be used at boot to order the interfaces? adding new interfaces may cause a re-numbering but it would give stability on if the hardware does not change.