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

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.

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.

According to documentation — https://wiki.vyos.net/wiki/Troubleshooting — specifying the hw-id of an interface should be tell udev (or similar) to ensure that the interface with the MAC-address specified gets the name of e.g. eth0.

However, this is not working for me.

configure
edit interfaces
show ethernet

 ethernet eth0 {
     address 10.4.0.59/22
     description "- (fe3 @ wap7.d.faelix.net)"
     duplex auto
     hw-id e4:11:5b:ac:2e:f8
     policy {
     }
     smp-affinity auto
     speed auto
 }

It has set the MAC address of eth0:

ip link show dev eth0
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode D
EFAULT group default qlen 1000
    link/ether e4:11:5b:ac:2e:f8 brd ff:ff:ff:ff:ff:ff
    alias - (fe3 @ wap7.d.faelix.net)

However, it has done that to a different interface than the one I intend "eth0" to refer to:

[email protected]:~$ ethtool -P eth0
Permanent address: a0:36:9f:1d:68:10
[email protected]:~$ ethtool -P eth1
Permanent address: e4:11:5b:ac:2e:f8
[email protected]:~$ ethtool -P eth2
Permanent address: e4:11:5b:ac:2e:f9
[email protected]:~$ ethtool -P eth3
Permanent address: a0:36:9f:1d:68:11
[email protected]:~$ ethtool -P eth4
Permanent address: a0:36:9f:1d:68:12
[email protected]:~$ ethtool -P eth5
Permanent address: a0:36:9f:1d:68:13
[email protected]:~$ ethtool -P eth6
Permanent address: a0:48:1c:b0:2b:00
[email protected]:~$ ethtool -P eth7
Permanent address: a0:48:1c:b0:2b:04

To give some information about the hardware in this box:

• eth1+eth2 are onboard adaptors
• eth0+eth3+eth4+eth5 is a 4x1G Intel add-in NIC
• eth6+eth7 is a 2x10G add-in NIC

Three reboots ago, this box came up "as expected" with eth0+eth1 representing the onboard, then eth2-5, then eth6-7. That was when running 1.3-rolling-202002290910.

Two reboots ago, it came up wrong, as per the above, also while running 1.3-rolling-202002290910.

The most recent reboot, 1.3-rolling-202008270118, is still wrong but in the same way.

Is hw-id actually doing anything, or is the interface renaming during boot still broken? I observed both recent reboots said that it took 120 seconds for the interfaces to "settle" (I presume this is the ifrename step, and presumably 120 seconds represents failure to complete correctly?).

Is this problem solved at present?

Neither does VyOS have predicable interface names, nor does it behave as per VyOS' documentation.

It's completely broken, IMHO.

We look forward to the solution of this problem

I tested this in LAB and it seems works properly. Changing interface name for eth1 and eth2

vyos@vyos# delete interfaces ethernet eth1 hw-id 
[edit]
vyos@vyos# delete interfaces ethernet eth2 hw-id 
[edit]
vyos@vyos# set interfaces ethernet eth1 hw-id 50:01:00:02:00:02
[edit]
vyos@vyos# set interfaces ethernet eth2 hw-id 50:01:00:02:00:01
[edit]
vyos@vyos# commit
[edit]
vyos@vyos# save 
Saving configuration to '/config/config.boot'...
Done
[edit]
vyos@vyos# run reboot now

After reboot

vyos@vyos:~$ sudo ethtool -P eth1
Permanent address: 50:01:00:02:00:02
vyos@vyos:~$ sudo ethtool -P eth2
Permanent address: 50:01:00:02:00:01

@maznu , can you provide next:

show configuration commands | match hw-id
sudo cat /run/udev/log/vyatta-net-name.coldplug

As per @Dmitry's suggestions, I did exactly the above. Upon reboot it did not look promising:

[  138.373656] vyos-router[842]: Waiting for NICs to settle down: settled in 121 sec. failed!

A while later, having managed to get in via IPMI:

[email protected]:~$ show configuration commands | match hw-id
set interfaces ethernet eth0 hw-id 'e4:11:5b:ac:2e:f8'
set interfaces ethernet eth1 hw-id 'e4:11:5b:ac:2e:f9'
set interfaces ethernet eth2 hw-id 'a0:36:9f:1d:68:10'
set interfaces ethernet eth3 hw-id 'a0:36:9f:1d:68:11'
set interfaces ethernet eth4 hw-id 'a0:36:9f:1d:68:12'
set interfaces ethernet eth5 hw-id 'a0:36:9f:1d:68:13'
set interfaces ethernet eth6 hw-id 'a0:48:1c:b0:2b:04'
set interfaces ethernet eth7 hw-id 'a0:48:1c:b0:2b:00'

And those did match the permanent addresses of the interface. Now to try deploying a real configuration.

Thank you, @Dmitry.

The bad behavior of udev/systemd was a topic of an interesting twitter thread...

Whitequark

@maznu but it seems really odd behavior, I mean message settled in 121 sec. failed!
121 sec - equal to 121 interfaces when the router is first booted. But if in config already present hw-id, it should be faster then 0 sec.
Will be interesting to reproduce this in our lab. Also will be helpful if you provide sudo dmesg output.

@Dmitry in various reboots and real-config-tests we've seen it settle in a few seconds, and we've seen it do 121 failed again today:

[  139.944186] vyos-router[847]: Waiting for NICs to settle down: settled in 120 sec. failed!

Will do some more investigating here and let you know what's in a "working" and what's in a "broken" dmesg.