Proxmox using eth-naming + alt-names in network interfaces

[jsterr]

Hello Proxmox,

im currently facing some systems (that have 2 onboard nics) that get alt-names defined by proxmox system and I dont know why. Usually those systems get enp195s0f0 and enp195s0f1 but for some weired issue (I dont know) they only get those names as alt-names:



Any reason why the interface-names differ so enp159s0f0 gets eth0 and the second interface enp195s0f1 gets eno1. Does someone have a tip?

Latest Proxmox ISO 7.1.2 from website.

Edit: This happens also on Supermicro X12 Boards with Intel CPU. My system is a rs500a-e10-rs12u (amd epyc 7002) Both systems use igb driver. Has there been a change that explains this? Any kernel changes regarding udev handling devices?

Edit2: Also happens on H12SSL-CT that has not igb but bnxt_en

2: eno1np0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master vmbr0 state UP group default qlen 1000
link/ether 3c:ec:ef:72:e4:e0 brd ff:ff:ff:ff:ff:ff
altname enp71s0f0np0
3: eno2np1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 3c:ec:ef:72:e4:e1 brd ff:ff:ff:ff:ff:ff
altname enp71s0f1np1

Edit3: I also have a system that had eth0 on installer and after rebooting it got eth3 as a name. (eth0 not visible anymore in ip a


Greetings
Jonas

 

[jsterr]

is there something like persistent netrules? That server got different nic-naming after installation-wizard. This seems like a bug.

 

[aaron]

To rule out that the PCI addressing is changing in the meantime, can you compare the output of lspci during installation and afterwards?

If you start the installer in debug mode, and on the second shell run
lspci | grep Ethernet

And then once the system booted after the successful installation, once more.
I assume that the PCI address will stay the same, but definitely something we should confirm.

 

[jsterr]

To rule out that the PCI addressing is changing in the meantime, can you compare the output of lspci during installation and afterwards?

If you start the installer in debug mode, and on the second shell run
lspci | grep Ethernet

And then once the system booted after the successful installation, once more.
I assume that the PCI address will stay the same, but definitely something we should confirm.

Thanks for the hint, I did that but on a already installed system (it changes on every reboot):

Before reboot:

root@pve-03:~# lspci -vvv | grep 'Intel Corporation I210'
01:00.0 Ethernet controller: Intel Corporation I210 Gigabit Network Connection (rev 03)
02:00.0 Ethernet controller: Intel Corporation I210 Gigabit Network Connection (rev 03)

root@pve-03:~# ip a
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 3c:ec:ef:7b:92:26 brd ff:ff:ff:ff:ff:ff
    altname enp1s0
    inet 10.2.2.226/24 scope global eno1
       valid_lft forever preferred_lft forever
    inet6 fe80::3eec:efff:fe7b:9226/64 scope link
       valid_lft forever preferred_lft forever
4: eth2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 3c:ec:ef:7b:92:27 brd ff:ff:ff:ff:ff:ff
    altname enp2s0

-------------------------------------------------------------

After reboot (eth2 -> eth3)

root@pve-03:~# lspci -vvv | grep 'Intel Corporation I210'
01:00.0 Ethernet controller: Intel Corporation I210 Gigabit Network Connection (rev 03)
02:00.0 Ethernet controller: Intel Corporation I210 Gigabit Network Connection (rev 03)

root@pve-03:~# ip a

2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 3c:ec:ef:7b:92:26 brd ff:ff:ff:ff:ff:ff
    altname enp1s0
    inet 10.2.2.226/24 scope global eno1
       valid_lft forever preferred_lft forever
    inet6 fe80::3eec:efff:fe7b:9226/64 scope link
       valid_lft forever preferred_lft forever
5: eth3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 3c:ec:ef:7b:92:27 brd ff:ff:ff:ff:ff:ff
    altname enp2s0

 

[wefinet]

Jonas and I have been able to fix this issue by applying X12SPL-F BIOS update 1.1c.
Details can be found here (in German):
https://www.thomas-krenn.com/de/wik...roxmox_VE_7_ethX_statt_enoX_NICs_mit_BIOS_1.1

 

[aaron]

Pesky BIOS bugs

Thx for the writeup.