Proxmox VE improper interfaces naming

M

markfree

Member
Jan 18, 2022
22
12
23
I have a Proxmox node with 3x RJ-45 connectors and 2x SFP+ connectors.
It is losing L2 connectivity. I then have to physically reboot the node several times before it connects again.

Below is the output from the ip command:

Code: 
[root@pvez ~]# ip -br link
lo               UNKNOWN        00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP>
eth0             DOWN           00:f0:cb:ef:e3:94 <BROADCAST,MULTICAST>
eth2             UP             00:f0:cb:ef:e3:95 <BROADCAST,MULTICAST,UP,LOWER_UP>
eth3             DOWN           00:f0:cb:ef:e3:96 <BROADCAST,MULTICAST>
sfp1             DOWN           00:02:c9:9b:77:88 <BROADCAST,MULTICAST>
spf2             DOWN           00:02:c9:9b:77:89 <BROADCAST,MULTICAST>
wlo1             DOWN           40:ec:99:cf:7c:a9 <BROADCAST,MULTICAST>
vmbr0            UP             00:f0:cb:ef:e3:95 <BROADCAST,MULTICAST,UP,LOWER_UP>
vmbr0.12@vmbr0   UP             00:f0:cb:ef:e3:95 <BROADCAST,MULTICAST,UP,LOWER_UP>
(...)

Here is the main interface configuration file created by the Proxmox GUI.

Code: 
[root@pvez ~]# cat /etc/network/interfaces
auto lo
iface lo inet loopback
iface eth0 inet manual
iface eth2 inet manual
iface eth3 inet manual
iface sfp1 inet manual
iface spf2 inet manual
iface wlo1 inet manual
auto vmbr0
iface vmbr0 inet manual
    bridge-ports eth2
    bridge-stp off
    bridge-fd 0
    bridge-vlan-aware yes
    bridge-vids 2-4094
#L2 Bridge
iface wl1 inet manual
auto vmbr0.12
iface vmbr0.12 inet static
    address 10.12.11.10/24
    gateway 10.12.11.1
#VLAN 12 PVEz
iface vmbr0.12 inet6 static
    address fd01:10:12:11::10/64
    gateway fd01:10:12:11::1
source /etc/network/interfaces.d/*

Below are kernel messages related to interfaces after a successful boot:

Code: 
[root@pvez ~]# dmesg | grep -E 'renamed|eth|sfp|igc|mlx4'
[    1.400419] igc 0000:01:00.0: PTM enabled, 4ns granularity
[    1.411998] mlx4_core: Mellanox ConnectX core driver v4.0-0
[    1.412024] mlx4_core: Initializing 0000:05:00.0
[    1.449073] igc 0000:01:00.0 (unnamed net_device) (uninitialized): PHC added
[    1.474386] igc 0000:01:00.0: 4.000 Gb/s available PCIe bandwidth (5.0 GT/s PCIe x1 link)
[    1.474395] igc 0000:01:00.0 eth0: MAC: 00:f0:cb:ef:e3:94
[    1.474655] igc 0000:02:00.0: PTM enabled, 4ns granularity
[    1.522341] igc 0000:02:00.0 (unnamed net_device) (uninitialized): PHC added
[    1.548310] igc 0000:02:00.0: 4.000 Gb/s available PCIe bandwidth (5.0 GT/s PCIe x1 link)
[    1.548315] igc 0000:02:00.0 eth1: MAC: 00:f0:cb:ef:e3:95
[    1.548488] igc 0000:03:00.0: PTM enabled, 4ns granularity
[    1.595111] igc 0000:03:00.0 (unnamed net_device) (uninitialized): PHC added
[    1.619975] igc 0000:03:00.0: 4.000 Gb/s available PCIe bandwidth (5.0 GT/s PCIe x1 link)
[    1.619980] igc 0000:03:00.0 eth2: MAC: 00:f0:cb:ef:e3:96
[    1.850836] igc 0000:03:00.0 eth3: renamed from eth2
[    8.854350] mlx4_core 0000:05:00.0: DMFS high rate steer mode is: disabled performance optimized steering
[    8.854685] mlx4_core 0000:05:00.0: 31.504 Gb/s available PCIe bandwidth, limited by 8.0 GT/s PCIe x4 link at 0000:00:1c.4 (capable of 63.008 Gb/s with 8.0 GT/s PCIe x8 link)
[    8.905490] mlx4_en: Mellanox ConnectX HCA Ethernet driver v4.0-0
[    8.905731] mlx4_en 0000:05:00.0: Activating port:1
[    8.908262] mlx4_en: 0000:05:00.0: Port 1: Using 4 TX rings
[    8.908268] mlx4_en: 0000:05:00.0: Port 1: Using 4 RX rings
[    8.908662] mlx4_en: 0000:05:00.0: Port 1: Initializing port
[    8.909160] mlx4_en 0000:05:00.0: registered PHC clock
[    8.909353] mlx4_en 0000:05:00.0: Activating port:2
[    8.909776] mlx4_en: 0000:05:00.0: Port 2: Using 4 TX rings
[    8.909780] mlx4_en: 0000:05:00.0: Port 2: Using 4 RX rings
[    8.910000] mlx4_en: 0000:05:00.0: Port 2: Initializing port
[    8.928308] <mlx4_ib> mlx4_ib_probe: mlx4_ib: Mellanox ConnectX InfiniBand driver v4.0-0
[    8.928795] <mlx4_ib> mlx4_ib_probe: counter index 2 for port 1 allocated 1
[    8.928797] <mlx4_ib> mlx4_ib_probe: counter index 3 for port 2 allocated 1
[    8.936820] mlx4_core 0000:05:00.0 sfp1: renamed from eth2
[    8.936951] mlx4_core 0000:05:00.0 spf2: renamed from eth4
[   10.050474] igc 0000:02:00.0 eth2: renamed from eth1
[   10.064984] systemd[1]: eth0: systemd-udevd failed to process the device, ignoring: File exists
[   11.704282] iwlwifi 0000:00:14.3 wlo1: renamed from wlan0
[   12.698681] vmbr0: port 1(eth2) entered blocking state
[   12.698688] vmbr0: port 1(eth2) entered disabled state
[   12.698707] igc 0000:02:00.0 eth2: entered allmulticast mode
[   12.698777] igc 0000:02:00.0 eth2: entered promiscuous mode
[   16.203037] igc 0000:02:00.0 eth2: NIC Link is Up 2500 Mbps Full Duplex, Flow Control: RX
[   16.203168] vmbr0: port 1(eth2) entered blocking state
[   16.203171] vmbr0: port 1(eth2) entered forwarding state
[   26.463046] fwbr1121i0: port 2(veth1121i0) entered blocking state
[   26.463053] fwbr1121i0: port 2(veth1121i0) entered disabled state
[   26.463068] veth1121i0: entered allmulticast mode
[   26.463119] veth1121i0: entered promiscuous mode
[   26.504586] eth0: renamed from vethzlAw0l
[   27.244874] fwbr1121i0: port 2(veth1121i0) entered blocking state
[   27.244883] fwbr1121i0: port 2(veth1121i0) entered forwarding state
[   32.208652] fwbr1131i0: port 2(veth1131i0) entered blocking state
[   32.208659] fwbr1131i0: port 2(veth1131i0) entered disabled state
[   32.208673] veth1131i0: entered allmulticast mode
[   32.208722] veth1131i0: entered promiscuous mode
[   32.248985] eth0: renamed from vethXMZCGS
[   33.004968] fwbr1131i0: port 2(veth1131i0) entered blocking state
[   33.004975] fwbr1131i0: port 2(veth1131i0) entered forwarding state
[   36.187092] fwbr1132i0: port 2(veth1132i0) entered blocking state
[   36.187101] fwbr1132i0: port 2(veth1132i0) entered disabled state
[   36.187121] veth1132i0: entered allmulticast mode
[   36.187177] veth1132i0: entered promiscuous mode
[   36.233513] eth0: renamed from veth2REjb8
[   37.179160] fwbr1132i0: port 2(veth1132i0) entered blocking state
[   37.179170] fwbr1132i0: port 2(veth1132i0) entered forwarding state
[   40.553455] fwbr1133i0: port 2(veth1133i0) entered blocking state
[   40.553462] fwbr1133i0: port 2(veth1133i0) entered disabled state
[   40.553478] veth1133i0: entered allmulticast mode
[   40.553532] veth1133i0: entered promiscuous mode
[   40.590729] fwbr1141i0: port 2(veth1141i0) entered blocking state
[   40.590737] fwbr1141i0: port 2(veth1141i0) entered disabled state
[   40.590755] veth1141i0: entered allmulticast mode
[   40.590808] veth1141i0: entered promiscuous mode
[   40.596866] eth0: renamed from vethl3OtPZ
[   40.634248] eth0: renamed from vethsJjCI2
[   41.517490] fwbr1133i0: port 2(veth1133i0) entered blocking state
[   41.517498] fwbr1133i0: port 2(veth1133i0) entered forwarding state
[   41.535864] fwbr1141i0: port 2(veth1141i0) entered blocking state
[   41.535871] fwbr1141i0: port 2(veth1141i0) entered forwarding state

The Udev service display these messages:

Code: 
[root@pvez ~]# systemctl status systemd-udevd
● systemd-udevd.service - Rule-based Manager for Device Events and Files
     Loaded: loaded (/usr/lib/systemd/system/systemd-udevd.service; static)
    Drop-In: /usr/lib/systemd/system/systemd-udevd.service.d
             └─syscall-architecture.conf
     Active: active (running) since Tue 2026-01-20 16:30:09 -03; 52min ago
 Invocation: 32e1c916d5e34fe59501943fb2f23d08
TriggeredBy: ● systemd-udevd-control.socket
             ● systemd-udevd-kernel.socket
       Docs: man:systemd-udevd.service(8)
             man:udev(7)
   Main PID: 337 (systemd-udevd)
     Status: "Processing with 24 children at max"
      Tasks: 1
     Memory: 50.4M (peak: 64.2M)
        CPU: 3.474s
     CGroup: /system.slice/systemd-udevd.service
             └─udev
               └─337 /usr/lib/systemd/systemd-udevd

Jan 20 16:30:10 pvez (udev-worker)[339]: lo: Invalid network interface name, ignoring:
Jan 20 16:30:10 pvez (udev-worker)[341]: eth0: Failed to rename network interface 2 from 'eth0' to 'eth1': File exists
Jan 20 16:30:10 pvez (udev-worker)[341]: eth0: Failed to process device, ignoring: File exists
Jan 20 16:30:12 pvez (udev-worker)[349]: vmbr0.12: Failed to rename network interface 9 from 'vmbr0.12' to 'eth2': File exists
Jan 20 16:30:12 pvez (udev-worker)[349]: vmbr0.12: Failed to process device, ignoring: File exists
Notice: journal has been rotated since unit was started, output may be incomplete.

The system has no udev rules set on /etc/udev/rules.d/. The only one that exists is null.

Code: 
[root@pvez ~]# ls -lah /etc/udev/rules.d/
lrwxrwxrwx 1 root root    9 Jan  1 21:34 60-bridge-network-interface.rules -> /dev/null

After a long search, I found that Proxmox uses SystemD's versioned naming scheme for network device names.
SystemD seems to have pinned the interface names.

Code: 
[root@pvez ~]# ll /etc/systemd/network/
-rw-r--r-- 1 root root   55 Jan  1 21:51 10-eth1.link
-rw-r--r-- 1 root root   55 Jan  1 21:51 10-eth2.link
-rw-r--r-- 1 root root   55 Jan  1 21:51 10-eth3.link
-rw-r--r-- 1 root root   55 Jan  1 21:51 10-sfp1.link
-rw-r--r-- 1 root root   55 Jan  1 21:51 10-spf2.link

These are improper names, but I don't get why.
I tried to rename the interfaces in these files, but it keep loosing connectivity.
I prefer the interfaces use predictable names instead of "ethX".
How do I recreate the interfaces with the proper predictable names?
 
Last edited:
The error messages in the systemd-udev daemon indicate issues with renaming and there is a fair chance, that the .link files are not correct.

For getting predictable names again you can just delete these .link files. After a reboot the network interfaces have predictable names again. Might be helpful to update the /etc/network/interfaces file to use the current altnames of the interfaces before reboot.
 
  • Like
Reactions: markfree
I tried removing the link files and updating the "interfaces" file, but the interface names remain "ethX". Oddly, the SFP2 interface is named "spf2".

Code: 
lo               UNKNOWN        00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP>
eth1             DOWN           00:f0:cb:ef:e3:94 <BROADCAST,MULTICAST>
eth2             DOWN           00:f0:cb:ef:e3:95 <NO-CARRIER,BROADCAST,MULTICAST,UP>
eth3             DOWN           00:f0:cb:ef:e3:96 <BROADCAST,MULTICAST>
sfp1             DOWN           00:02:c9:9b:77:88 <BROADCAST,MULTICAST>
spf2             DOWN           00:02:c9:9b:77:89 <BROADCAST,MULTICAST>
wlo1             DOWN           40:ec:99:cf:7c:a9 <BROADCAST,MULTICAST>
vmbr0            DOWN           00:f0:cb:ef:e3:95 <NO-CARRIER,BROADCAST,MULTICAST,UP>
vmbr0.12@vmbr0   LOWERLAYERDOWN 00:f0:cb:ef:e3:95 <NO-CARRIER,BROADCAST,MULTICAST,UP>

Code: 
auto lo
iface lo inet loopback
iface eth1 inet manual
iface eth2 inet manual
iface eth3 inet manual
(...)
auto vmbr0
iface vmbr0 inet manual
    bridge-ports eth2

Then, I changed the interface sequence from the set above to 0, 2, 3, and it connected this time for a few minutes. Then, disconnected again.

Code: 
auto lo
iface lo inet loopback
iface eth0 inet manual
iface eth2 inet manual
iface eth3 inet manual
(...)
auto vmbr0
iface vmbr0 inet manual
    bridge-ports eth2

From what I understand, the interface names are set by this rule:

Code: 
[root@pvez ~]# cat /lib/udev/rules.d/80-net-setup-link.rules
# do not edit this file, it will be overwritten on update
SUBSYSTEM!="net", GOTO="net_setup_link_end"
IMPORT{builtin}="path_id"
ACTION=="remove", GOTO="net_setup_link_end"
IMPORT{builtin}="net_setup_link"
NAME=="", ENV{ID_NET_NAME}!="", NAME="$env{ID_NET_NAME}"
LABEL="net_setup_link_end"

However, it seems that the system keeps renaming the interfaces, though I don't get how.
 
Last edited:
After looking into the device tree, I think the proper naming scheme should be as follows:

Code: 
[root@pvez ~]# udevadm info -t | grep -E 'ID_NET_NAME_PATH='
│   ┆ E: ID_NET_NAME_PATH=wlp0s20f3
│ │ │ ┆ E: ID_NET_NAME_PATH=enp1s0  # eth1
│ │ │ ┆ E: ID_NET_NAME_PATH=enp2s0  # eth2
│ │ │ ┆ E: ID_NET_NAME_PATH=enp3s0  # eth3
│ │ │ ┆ E: ID_NET_NAME_PATH=enp5s0  # sfp1
│ │ │ ┆ E: ID_NET_NAME_PATH=enp5s0d1  # sfp2

In the same device tree, I found the ID_NET_LINK_FILE parameter which points to the SystemD /usr/local/lib/systemd/network/ path.

There it was... other persistent naming files

Code: 
[root@pvez ~]# ll /usr/local/lib/systemd/network/
-rw-r--r-- 1 root root  100 Jan  1 21:33 50-pmx-eth1.link
-rw-r--r-- 1 root root  100 Jan  1 21:33 50-pmx-eth2.link
-rw-r--r-- 1 root root  100 Jan  1 21:33 50-pmx-eth3.link
-rw-r--r-- 1 root root  100 Jan  1 21:33 50-pmx-sfp1.link
-rw-r--r-- 1 root root  100 Jan  1 21:33 50-pmx-spf2.link
-rw-r--r-- 1 root root   99 Jan  1 21:33 50-pmx-wl1.link

The Proxmox Installer set these files. I believe I set these names when I first installed Proxmox.

I removed them and renamed the interfaces.

Code: 
[root@pvez ~]# cat /etc/network/interfaces
auto lo
iface lo inet loopback
iface enp1s0 inet manual
iface enp2s0 inet manual
iface enp3s0 inet manual
iface enp5s0 inet manual
iface enp5s0d1 inet manual
iface wlp0s20f3 inet manual
(...)
auto vmbr0
iface vmbr0 inet manual
    bridge-ports enp2s0
(...)

Rebooted the system, crossed my fingers, and it connected!
Now, let's hope it stays connected.
 
  • Like
Reactions: _gabriel
I'm still confused as to why it wasn't working before.
Despite the "spf2" interface, the SystemD interface names were not incorrect.
:rolleyes:
 
Hi,

could you share the contents of the files in /usr/local/lib/systemd/network/?

Please note that using eth* are highly discouraged, as these mimick the built-in naming of the kernel and thus might conflict.
You can try other names (e.g. etherN instead of ethN) and see if that error still occurs.
 
As shown above, the /usr/local/lib/systemd/network/ directory contained the .link files, which I removed. Now the directory is empty. With this, I expected the interfaces to use "predictable names".

The device tree shows that the interfaces are now set to the default link file.

Code: 
[root@pvez ~]# udevadm info -t | grep 'ID_NET_LINK_FILE'
│   ┆ E: ID_NET_LINK_FILE=/usr/lib/systemd/network/99-default.link
│   ┆ E: ID_NET_LINK_FILE_DROPINS=/usr/lib/systemd/network/99-default.link.d/proxmox-mac-address-policy.conf

It was only after I removed them that the node stopped disconnecting... for a while.
Unfortunately, my relief was short-lived, as the node disconnected again today.
I managed to save some data before rebooting.

The "interfaces" file remains the same.

Code: 
auto lo
iface lo inet loopback
iface enp1s0 inet manual
iface enp2s0 inet manual
iface enp3s0 inet manual
iface enp5s0 inet manual
iface enp5s0d1 inet manual
iface wlp0s20f3 inet manual
auto vmbr0
iface vmbr0 inet manual
    bridge-ports enp2s0
(...)

The kernal messages show that the link was down ("eth" naming).

Code: 
[67071.498338] igc 0000:02:00.0 eth2: NIC Link is Down
[67071.498504] vmbr0: port 1(eth2) entered disabled state
[67293.997593] nfs: server 192.168.8.10 not responding, still trying
[67298.029371] nfs: server 192.168.8.10 not responding, timed out

I also noticed that the interface names remain "ethX" when displaying the "Ip links", as if they were not updated.

Code: 
[root@pvez ~]# cat ip_link
lo               UNKNOWN        00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP>
eth1             DOWN           00:f0:cb:ef:e3:94 <BROADCAST,MULTICAST>
eth2             DOWN           00:f0:cb:ef:e3:95 <NO-CARRIER,BROADCAST,MULTICAST,UP>
eth3             DOWN           00:f0:cb:ef:e3:96 <BROADCAST,MULTICAST>
sfp1             DOWN           00:02:c9:9b:77:88 <BROADCAST,MULTICAST>
spf2             DOWN           00:02:c9:9b:77:89 <BROADCAST,MULTICAST>
wlo1             DOWN           40:ec:99:cf:7c:a9 <BROADCAST,MULTICAST>
vmbr0            UP             00:f0:cb:ef:e3:95 <BROADCAST,MULTICAST,UP,LOWER_UP>
vmbr0.12@vmbr0   UP             00:f0:cb:ef:e3:95 <BROADCAST,MULTICAST,UP,LOWER_UP>
 
I am wondering about the posted kernel log messages. Did you reboot the server after removing the .link files?
Because it still reports about vmbr0 using eth2 as port, which wouldn't be the case if the server was restarted and the posted /etc/network/interfaces would be used.
 
I did reboot the node.
Yes, I suppose it should respect the "predictable names", but it does not...

After rebooting, the node connected again, but the interface names were different this time.

Code: 
[root@pvez ~]# ip -br link
lo               UNKNOWN        00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP>
enp1s0           DOWN           00:f0:cb:ef:e3:94 <BROADCAST,MULTICAST>
enp2s0           UP             00:f0:cb:ef:e3:95 <BROADCAST,MULTICAST,UP,LOWER_UP>
eth3             DOWN           00:f0:cb:ef:e3:96 <BROADCAST,MULTICAST>
sfp1             DOWN           00:02:c9:9b:77:88 <BROADCAST,MULTICAST>
spf2             DOWN           00:02:c9:9b:77:89 <BROADCAST,MULTICAST>
wlo1             DOWN           40:ec:99:cf:7c:a9 <BROADCAST,MULTICAST>
vmbr0            UP             00:f0:cb:ef:e3:95 <BROADCAST,MULTICAST,UP,LOWER_UP>
vmbr0.12@vmbr0   UP             00:f0:cb:ef:e3:95 <BROADCAST,MULTICAST,UP,LOWER_UP>

Besides the default ones, there are no more '.link' files.

Code: 
[root@pvez ~]# find / -name '*.link'
/usr/lib/systemd/network/80-vm-vt.link
/usr/lib/systemd/network/80-container-ve.link
/usr/lib/systemd/network/80-6rd-tunnel.link
/usr/lib/systemd/network/80-container-vz.link
/usr/lib/systemd/network/73-usb-net-by-mac.link
/usr/lib/systemd/network/80-container-vb.link
/usr/lib/systemd/network/99-default.link

Interface enp2s0 is the one physically connected, but I don't get why the third interface was named "eth3".
 
Have a look at the initramfs with lsinitramfs /boot/initrd.img-$(uname -r) | grep -E '\.link|\.rules'
Maybe there are some configs conserved. If yes, just run update-initramfs -u and reboot.
 
I ran `lsinitram`, which showed some interface `.link` files.

Code: 
usr/lib/systemd/network/50-pmx-eth1.link
usr/lib/systemd/network/50-pmx-eth2.link
usr/lib/systemd/network/50-pmx-eth3.link
usr/lib/systemd/network/50-pmx-sfp1.link
usr/lib/systemd/network/50-pmx-spf2.link
usr/lib/systemd/network/50-pmx-wl1.link
usr/lib/systemd/network/73-usb-net-by-mac.link
usr/lib/systemd/network/80-6rd-tunnel.link
usr/lib/systemd/network/80-container-vb.link
usr/lib/systemd/network/80-container-ve.link
usr/lib/systemd/network/80-container-vz.link
usr/lib/systemd/network/80-vm-vt.link
usr/lib/systemd/network/99-default.link
usr/lib/systemd/network/99-default.link.d
usr/lib/systemd/network/99-default.link.d/proxmox-mac-address-policy.conf
usr/lib/udev/rules.d/50-firmware.rules
usr/lib/udev/rules.d/50-udev-default.rules
usr/lib/udev/rules.d/55-dm.rules
usr/lib/udev/rules.d/56-lvm.rules
usr/lib/udev/rules.d/60-block.rules
usr/lib/udev/rules.d/60-persistent-storage-dm.rules
usr/lib/udev/rules.d/60-persistent-storage.rules
usr/lib/udev/rules.d/60-zvol.rules
usr/lib/udev/rules.d/64-btrfs-dm.rules
usr/lib/udev/rules.d/64-btrfs.rules
usr/lib/udev/rules.d/69-lvm.rules
usr/lib/udev/rules.d/69-vdev.rules
usr/lib/udev/rules.d/71-seat.rules
usr/lib/udev/rules.d/73-special-net-names.rules
usr/lib/udev/rules.d/75-net-description.rules
usr/lib/udev/rules.d/80-drivers.rules
usr/lib/udev/rules.d/80-net-setup-link.rules
usr/lib/udev/rules.d/95-dm-notify.rules

Since I removed these files previously, I updated initram, and they were no longer listed.

Code: 
usr/lib/systemd/network/73-usb-net-by-mac.link
usr/lib/systemd/network/80-6rd-tunnel.link
usr/lib/systemd/network/80-container-vb.link
usr/lib/systemd/network/80-container-ve.link
usr/lib/systemd/network/80-container-vz.link
usr/lib/systemd/network/80-vm-vt.link
usr/lib/systemd/network/99-default.link
usr/lib/systemd/network/99-default.link.d
usr/lib/systemd/network/99-default.link.d/proxmox-mac-address-policy.conf
usr/lib/udev/rules.d/50-firmware.rules
usr/lib/udev/rules.d/50-udev-default.rules
usr/lib/udev/rules.d/55-dm.rules
usr/lib/udev/rules.d/56-lvm.rules
usr/lib/udev/rules.d/60-block.rules
usr/lib/udev/rules.d/60-persistent-storage-dm.rules
usr/lib/udev/rules.d/60-persistent-storage.rules
usr/lib/udev/rules.d/60-zvol.rules
usr/lib/udev/rules.d/64-btrfs-dm.rules
usr/lib/udev/rules.d/64-btrfs.rules
usr/lib/udev/rules.d/69-lvm.rules
usr/lib/udev/rules.d/69-vdev.rules
usr/lib/udev/rules.d/71-seat.rules
usr/lib/udev/rules.d/73-special-net-names.rules
usr/lib/udev/rules.d/75-net-description.rules
usr/lib/udev/rules.d/80-drivers.rules
usr/lib/udev/rules.d/80-net-setup-link.rules
usr/lib/udev/rules.d/95-dm-notify.rules

After rebooting the device, it did not connect. I had to reboot several times before it finally connected.
This fluctuation bothers me so much.

At least Interfaces are now named appropriately.

Code: 
[root@pvez ~]# ip -br link
lo               UNKNOWN        00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP>
enp1s0           DOWN           00:f0:cb:ef:e3:94 <BROADCAST,MULTICAST>
enp2s0           UP             00:f0:cb:ef:e3:95 <BROADCAST,MULTICAST,UP,LOWER_UP>
enp3s0           DOWN           00:f0:cb:ef:e3:96 <BROADCAST,MULTICAST>
enp5s0           DOWN           00:02:c9:9b:77:88 <BROADCAST,MULTICAST>
enp5s0d1         DOWN           00:02:c9:9b:77:89 <BROADCAST,MULTICAST>
wlo1             DOWN           40:ec:99:cf:7c:a9 <BROADCAST,MULTICAST>
vmbr0            UP             00:f0:cb:ef:e3:95 <BROADCAST,MULTICAST,UP,LOWER_UP>
vmbr0.12@vmbr0   UP             00:f0:cb:ef:e3:95 <BROADCAST,MULTICAST,UP,LOWER_UP>
 
Last edited:
In the first post you wrote
It is losing L2 connectivity.
Click to expand...
How did you identify it is L2?
Quite often it is a bad cable or switch port or similar.

Have you checked the logs of the boot process, when the network connection wasn't successful, e. g. by journalctl -b -1 -k | grep -iE "enp|wlo|link|carrier|down|up|mlx|error|fail" for retrieving logs of last boot (-1)?
 
The kernal messages only display a "link down" warning.

Code: 
[16566.169750] systemd-journald[604]: Vacuuming done, freed 4.4M of archived journals from /var/log/journal/463dba48c4ee48a4baa4f6b6091e99d9.
[19797.409554] igc 0000:02:00.0 enp2s0: NIC Link is Down
[19797.409678] vmbr0: port 1(enp2s0) entered disabled state
[19801.174658] igc 0000:02:00.0 enp2s0: NIC Link is Up 2500 Mbps Full Duplex, Flow Control: RX
[19801.174716] vmbr0: port 1(enp2s0) entered blocking state
[19801.174722] vmbr0: port 1(enp2s0) entered forwarding state
[19801.176423] igc 0000:02:00.0 enp2s0: NIC Link is Down
[19802.189564] vmbr0: port 1(enp2s0) entered disabled state
[19993.228067] nfs: server 192.168.8.10 not responding, still trying
[20002.443937] nfs: server 192.168.8.10 not responding, timed out
(...)

The Journalctl messages are all over the place.
Although the date is correct,

Code: 
[root@pvez ~]# date
Fri Jan 23 04:40:39 PM -03 2026

The Journal messages have different dates.

Code: 
[root@pvez ~]# journalctl --list-boots
IDX BOOT ID                          FIRST ENTRY                 LAST ENTRY                 
 -5 280ce605a4a3449eb4556008285fe663 Thu 2026-01-01 21:36:15 -03 Thu 2026-01-01 21:51:45 -03
 -4 660bbcb89a14474da54a5da5a7168d23 Fri 2026-01-23 16:28:37 -03 Fri 2026-01-23 16:33:20 -03
 -3 8efd91b42fe94950a690ba14c01fc5ed Thu 2026-01-08 21:00:01 -03 Fri 2026-01-09 18:17:33 -03
 -2 a510de60303546919e270936d531714a Sat 2026-01-10 18:00:01 -03 Tue 2026-01-13 06:00:01 -03
 -1 606f01b4098b4190940bb6b328226965 Tue 2026-01-13 18:00:01 -03 Tue 2026-01-13 21:10:08 -03
  0 8a80e95c8c154f779e139143476aaf32 Wed 2026-01-14 15:00:01 -03 Thu 2026-01-15 22:24:23 -03

Last boot (full) messages:

Code: 
[root@pvez ~]# journalctl -b -1 -k
Jan 10 18:27:03 pvez kernel: vmbr0: the hash_elasticity option has been deprecated and is always 16
Jan 10 18:33:24 pvez kernel: vmbr0: the hash_elasticity option has been deprecated and is always 16
Jan 10 18:42:03 pvez kernel: vmbr0: the hash_elasticity option has been deprecated and is always 16
Jan 11 23:29:02 pvez kernel: kauditd_printk_skb: 110 callbacks suppressed
Jan 11 23:29:08 pvez kernel: kauditd_printk_skb: 585 callbacks suppressed

Today's (full) messages:

Code: 
[root@pvez ~]# journalctl -k --since=today 
Jan 23 16:28:37 pvez kernel: device-mapper: core: CONFIG_IMA_DISABLE_HTABLE is disabled. Duplicate IMA measurements will not be recorded in the IMA log.
Jan 23 16:28:37 pvez kernel: ENERGY_PERF_BIAS: Set to 'normal', was 'performance'
Jan 23 16:28:37 pvez kernel: i801_smbus 0000:00:1f.4: SMBus is busy, can't use it!
Jan 23 16:28:37 pvez kernel: nvme nvme0: missing or invalid SUBNQN field.
Jan 23 16:28:37 pvez kernel: mlx4_en: 0000:05:00.0: Port 1: Using 4 TX rings
Jan 23 16:28:37 pvez kernel: mlx4_en: 0000:05:00.0: Port 1: Using 4 RX rings
Jan 23 16:28:37 pvez kernel: mlx4_en: 0000:05:00.0: Port 1: Initializing port
Jan 23 16:28:37 pvez kernel: mlx4_en: 0000:05:00.0: Port 2: Using 4 TX rings
Jan 23 16:28:37 pvez kernel: mlx4_en: 0000:05:00.0: Port 2: Using 4 RX rings
Jan 23 16:28:37 pvez kernel: mlx4_en: 0000:05:00.0: Port 2: Initializing port
Jan 23 16:28:37 pvez kernel: spl: loading out-of-tree module taints kernel.
Jan 23 16:28:37 pvez kernel: zfs: module license 'CDDL' taints kernel.
Jan 23 16:28:37 pvez kernel: Disabling lock debugging due to kernel taint
Jan 23 16:28:37 pvez kernel: zfs: module license taints kernel.
Jan 23 16:28:37 pvez kernel: faux_driver regulatory: Direct firmware load for regulatory.db failed with error -2
Jan 23 16:28:37 pvez kernel: spi-nor spi0.0: supply vcc not found, using dummy regulator
Jan 23 16:28:37 pvez kernel: Bluetooth: hci0: HCI LE Coded PHY feature bit is set, but its usage is not supported.
Jan 23 16:28:37 pvez kernel: nvme nvme0: using unchecked data buffer
Jan 23 16:28:37 pvez kernel: NOTICE: Automounting of tracing to debugfs is deprecated and will be removed in 2030
Jan 23 16:33:18 pvez kernel: kauditd_printk_skb: 117 callbacks suppressed

I suppose it could be a cable issue, but I already swapped cables and switch ports.
The weird thing is how random the disconnects are, and it only reconnects if I reboot a few times.

There was just one thing I haven't tried yet: swapping the patch panel connector.
I swapped it now.
Let's see if it disconnects.
 
Nothing specific in there, might be a driver issue, though.
You could try something like this and test if it helps. The first should disable energy saving modes and the second disables hardware offloading.
ethtool --set-eee enp2s0 eee off
ethtool -K enp2s0 tso off gso off
 
  • Like
Reactions: markfree
Ultimately, I think it all came down to a cabling issue. Well.. not really a cable, though, but rather the patch panel coupler.

After replacing it, there have been no more disconnections for about two days.
If it happens to disconnect again, I'll try disabling energy savings and hardware offloading.
Thanks a lot for all the insights!
 
  • Like
Reactions: fba
You must log in or register to reply here.
Top Bottom
Back