Auteur Sujet: Ubuntu server: Interface réseau qui change de nom (Lu 2736 fois)

hwti · « **Réponse #12 le:** 11 novembre 2021 à 06:25:48 »

La convention de nommage systemd : https://www.freedesktop.org/software/systemd/man/systemd.net-naming-scheme.html

Les "np0" et "np1" viennent de https://github.com/systemd/systemd/commit/4887b656c22af059d4e833de7b56544f24951184, le kernel a donc renseigné phys_port_name avec "p0" ou "p1".

A partir du kernel 5.2, il y a https://github.com/torvalds/linux/commit/af3836df9a59e7339d60c9c46729a7d9094d0582 qui construit un phys_port_name à partir du devlink_port.

Et le changement final qui a activé tout ça pour cette carte est arrivé avec le kernel 5.7 : https://github.com/torvalds/linux/commit/c6acd629eec754a9679f922d51f90e44c769b80c#diff-0da1e572ba1380c2e2ac04d8a1b05a903415d16a99cc07bcdaa1497a7c0d690aR17
Le port est déclaré avec le numéro de fonction PCI, qui est déjà utilisée pour "f0"/"f1", d'où le changement de nom avec l'information dupliquée.

Ça semble un peu bizarre, mais depuis peu le driver semble supporter des cartes qui n'ont pas la notion de fonction PCI : https://github.com/torvalds/linux/commit/1021d0645d593ea86193c5fc371e33e5b208e14d
Dans ce cas, il n'y aura probablement pas de f0/f1, et donc les np0/np1 sont importants.

Je me demande si dans systemd le numéro de fonction ne pourrait pas être ignoré quand il y a un nom de port renseigné, mais ça ne changerait pas le fait que des changements dans les drivers peuvent, potentiellement involontairement, modifier le nom des interfaces.

vivien · « **Réponse #13 le:** 04 avril 2023 à 21:19:43 »

J'ai encore eu un serveur sous Ubuntu server 20.04 où l'interface a changé de nom, mais chose nouvelle cela eu lieu suite à un reboot où le noyau n'avait pas changé (5.4.0-144-generic avant reboot et aprés reboot, le reboot était pour vérifier que Ookla serveur se lance au redémarrage du serveur, sans aucun lien avec une évolution du noyau).

La carte réseau en question :

02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06) Subsystem: Gigabyte Technology Co., Ltd Onboard Ethernet Flags: bus master, fast devsel, latency 0, IRQ 16 I/O ports at e000 [size=256] Memory at f0004000 (64-bit, prefetchable) [size=4K] Memory at f0000000 (64-bit, prefetchable) [size=16K] Capabilities: [40] Power Management version 3 Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+ Capabilities: [70] Express Endpoint, MSI 01 Capabilities: [b0] MSI-X: Enable+ Count=4 Masked- Capabilities: [d0] Vital Product Data Capabilities: [100] Advanced Error Reporting Capabilities: [140] Virtual Channel Capabilities: [160] Device Serial Number 01-00-00-00-68-4c-e0-00 Kernel driver in use: r8169 Kernel modules: r8169

Nom de l'interface réseau à l'origine : p4p1
Nom de l'interface réseau après reboot : eth0

Le changement du nom de la carte dans /etc/network/interfaces a été fait à t=8406 sec dans le dmesg ci-dessous :

Code: [Sélectionner]

$ dmesg | grep r8169
[    0.972612] r8169 0000:02:00.0: can't disable ASPM; OS doesn't have ASPM control
[    0.977987] r8169 0000:02:00.0 eth0: RTL8168evl/8111evl, 90:2b:34:61:18:d6, XID 2c9, IRQ 27
[    0.981607] r8169 0000:02:00.0 eth0: jumbo features [frames: 9200 bytes, tx checksumming: ko]
[ 8406.955660] RTL8211E Gigabit Ethernet r8169-0-200:00: attached PHY driver [RTL8211E Gigabit Ethernet] (mii_bus:phy_addr=r8169-0-200:00, irq=IGNORE)
[ 8407.152092] r8169 0000:02:00.0 eth0: Link is Down
[ 8410.104052] r8169 0000:02:00.0 eth0: Link is Up - 1Gbps/Full - flow control off

Bref, je pense que je vais forcer le nom de mes interfaces pour les serveurs qui n'utilisent pas Netplan.

vivien · « **Réponse #14 le:** 04 avril 2023 à 21:51:09 »

Pour forcer le nom de l'interface, j'ai suivi la solution proposée par Cali.

Exemple avec un serveur qui possède 3 cartes réseau :
- 2x Broadcom NetXtreme II BCM5716 1000Base-T intégrées
- 1x Intel Ethernet Controller 10-Gigabit X540-AT2 sur carte PCI-Express

Situation avant : Les interfaces se nomment respectivement eno1, eno2 et enp1s0

# dmesg | grep -e ixgbe -e bnx2 [ 1.916830] bnx2 0000:02:00.0 eth0: Broadcom NetXtreme II BCM5716 1000Base-T (C0) PCI Express found at mem c0000000, IRQ 16, node addr d0:67:e5:e9:ba:b4 [ 1.992674] bnx2 0000:02:00.1 eth1: Broadcom NetXtreme II BCM5716 1000Base-T (C0) PCI Express found at mem c2000000, IRQ 17, node addr d0:67:e5:e9:ba:b5 [ 2.067633] bnx2 0000:02:00.0 eno1: renamed from eth0 [ 2.215307] bnx2 0000:02:00.1 eno2: renamed from eth1 [ 2.445372] ixgbe: Intel(R) 10 Gigabit PCI Express Network Driver [ 2.459405] ixgbe: Copyright (c) 1999-2016 Intel Corporation. [ 2.825705] ixgbe 0000:01:00.0: Multiqueue Enabled: Rx Queue count = 8, Tx Queue count = 8 XDP Queue count = 0 [ 2.945325] ixgbe 0000:01:00.0: 32.000 Gb/s available PCIe bandwidth (5.0 GT/s PCIe x8 link) [ 3.072428] ixgbe 0000:01:00.0: MAC: 3, PHY: 0, PBA No: G54042-005 [ 3.072431] ixgbe 0000:01:00.0: a0:36:9f:31:81:5a [ 3.220244] ixgbe 0000:01:00.0: Intel(R) 10 Gigabit Network Connection [ 3.221260] ixgbe 0000:01:00.0 enp1s0: renamed from eth0 [ 17.912646] bnx2 0000:02:00.0 eno1: using MSIX [ 21.021636] bnx2 0000:02:00.0 eno1: NIC Copper Link is Up, 1000 Mbps full duplex

Je crée 3 fichiers :
/etc/systemd/network/10-eth0.link

Code: [Sélectionner]

[Match]
MACAddress=d0:67:e5:e9:ba:b4
[Link]
Name=eth0

/etc/systemd/network/10-eth1.link

Code: [Sélectionner]

[Match]
MACAddress=d0:67:e5:e9:ba:b5
[Link]
Name=eth1

/etc/systemd/network/10-eth2.link

Code: [Sélectionner]

[Match]
MACAddress=a0:36:9f:31:81:5a
[Link]
Name=eth2

Ne pas oublier de modifier le fichier /etc/network/interfaces avant de redémarrer !

Situation après : Les interfaces sont renommées deux fois pour revenir avec le nom eth0, eth1 et eth2

# dmesg | grep -e ixgbe -e bnx2 [ 1.884979] bnx2 0000:02:00.0 eth0: Broadcom NetXtreme II BCM5716 1000Base-T (C0) PCI Express found at mem c0000000, IRQ 16, node addr d0:67:e5:e9:ba:b4 [ 1.887897] bnx2 0000:02:00.1 eth1: Broadcom NetXtreme II BCM5716 1000Base-T (C0) PCI Express found at mem c2000000, IRQ 17, node addr d0:67:e5:e9:ba:b5 [ 1.892101] bnx2 0000:02:00.0 eno1: renamed from eth0 [ 2.044372] bnx2 0000:02:00.1 eno2: renamed from eth1 [ 2.410280] ixgbe: Intel(R) 10 Gigabit PCI Express Network Driver [ 2.410282] ixgbe: Copyright (c) 1999-2016 Intel Corporation. [ 2.750480] ixgbe 0000:01:00.0: Multiqueue Enabled: Rx Queue count = 8, Tx Queue count = 8 XDP Queue count = 0 [ 2.852492] ixgbe 0000:01:00.0: 32.000 Gb/s available PCIe bandwidth (5.0 GT/s PCIe x8 link) [ 2.976427] ixgbe 0000:01:00.0: MAC: 3, PHY: 0, PBA No: G54042-005 [ 3.007609] ixgbe 0000:01:00.0: a0:36:9f:31:81:5a [ 3.166265] ixgbe 0000:01:00.0: Intel(R) 10 Gigabit Network Connection [ 3.167374] ixgbe 0000:01:00.0 enp1s0: renamed from eth0 [ 13.073045] bnx2 0000:02:00.0 eth0: renamed from eno1 [ 13.202516] bnx2 0000:02:00.1 eth1: renamed from eno2 [ 13.230700] ixgbe 0000:01:00.0 eth2: renamed from enp1s0 [ 19.624093] bnx2 0000:02:00.0 eth0: using MSIX [ 22.814094] bnx2 0000:02:00.0 eth0: NIC Copper Link is Up, 1000 Mbps full duplex

Plus de risque de changement de nom à l'avnir !

JeannotPlanche · « **Réponse #15 le:** 04 avril 2023 à 22:54:57 »

J'ai vu une ou deux fois des serveurs dont les interfaces ont changé de nom après une mise à jour du BIOS ! Allez comprendre la prédictibilité de tout ce bazar.

(en plus des noms à rallonge, du style enp13s14f0)

hwti · « **Réponse #16 le:** 05 avril 2023 à 02:38:27 »

Citation de: JeannotPlanche le 04 avril 2023 à 22:54:57

J'ai vu une ou deux fois des serveurs dont les interfaces ont changé de nom après une mise à jour du BIOS ! Allez comprendre la prédictibilité de tout ce bazar. (en plus des noms à rallonge, du style enp13s14f0)

Parfois une mise à jour de BIOS change l'ordre d'énumération des ports PCIe, ce qui change les noms d'interface générés.

Citation de: vivien le 04 avril 2023 à 21:19:43

J'ai encore eu un serveur sous Ubuntu server 20.04 où l'interface a changé de nom, mais chose nouvelle cela eu lieu suite à un reboot où le noyau n'avait pas changé (5.4.0-144-generic avant reboot et aprés reboot, le reboot était pour vérifier que Ookla serveur se lance au redémarrage du serveur, sans aucun lien avec une évolution du noyau).
[...]
Nom de l'interface réseau à l'origine : p4p1
Nom de l'interface réseau après reboot : eth0

"p4p1" ce n'est pas un nom systemd, ça ressemble à biosdevname (qui existait en 18.04, mais plus en 20.04).
Si le paquet était sur la machine, et a finalement été supprimé, ça peut expliquer la perte de ce nom.
Mais il devrait y avoir le renommage systemd, à moins qu'il soit désactivé (via un net.ifnames=0 sur la ligne de commande kernel ?).

https://www.freedesktop.org/software/systemd/man/systemd.net-naming-scheme.html indique qu'on peut obtenir des informations avec "udevadm test-builtin net_id /sys/class/net/eth0".

Sinon, http://changelogs.ubuntu.com/changelogs/pool/main/s/systemd/systemd_245.4-4ubuntu3.20/changelog indique "Add support for the v247 network naming scheme, but keep v245 as default".
C'est daté de septembre, mais la mise à jour n'a été poussée dans focal-updates qu'en novembre.
Ca reste plus ancien que le kernel 5.4.0-144-generic, mais début mars systemd-245.4-4ubuntu3.20 a été poussé dans focal-security, donc si le serveur applique uniquement les mises à jour de sécurité, alors c'est à ce moment là qu'il a mis à jour systemd.
Ils ont en pratique pris https://github.com/systemd/systemd/pull/17352, qui détecte des cas où il y a un bridge PCIe dans un slot hotplug (et donc les noms générés pourraient être identiques).
Je vois un éventuel risque de bug si hotplug_slot vaut 0, il y a eu des corrections plus tard : https://github.com/systemd/systemd/pull/19237/commits/19ed9a114c et https://github.com/systemd/systemd/pull/19237/commits/c304cb0146.
Mais ça affecte ID_NET_NAME_SLOT, pas ID_NET_NAME_PATH (et sauf si "net.ifname-policy" ou NamePolicy est changé quelque part, il devrait l'utiliser si le premier n'est pas disponible).

vivien · « **Réponse #17 le:** 05 avril 2023 à 09:47:49 »

C'est un serveur installé avec Ubuntu server 15.04, en 2015. Il a depuis été mis à jour.
Cela explique la présence de biosdevname

J'ai regardé /etc/default/grub :
J'ai la ligne

Code: [Sélectionner]

GRUB_CMDLINE_LINUX=""
Pour empêcher systemd de renommer les interfaces (autre solution), il faudrait avoir

Code: [Sélectionner]

GRUB_CMDLINE_LINUX="net.ifnames=0 biosdevname=0"Ce n'est pas le cas.

Je ne sais pas ce qui bloque le renommage, d'où l'idée de forcer ça via un fichier /etc/systemd/network/10-eth0.link

hwti · « **Réponse #18 le:** 05 avril 2023 à 10:00:11 »

Mais est-ce que biosdevname est toujours installé ?
S'il est là, normalement son renommage est prioritaire sur celui de systemd.

Le comportement de systemd est configuré par :
- /lib/systemd/network/99-default.link
- d'une manière générale tout *.link dans /lib/systemd/network ou /etc/systemd/network

vivien · « **Réponse #19 le:** 05 avril 2023 à 11:59:55 »

biosdevname ne semble pas installé :
# apt list biosdevname En train de lister... Fait

Comme il n'est plus pris en charge avec Ubuntu 20.04, il a dû être supprimé comme les autres paquets obsolètes.

Fichier /lib/systemd/network/99-default.link

Code: [Sélectionner]

#  SPDX-License-Identifier: LGPL-2.1+
#
#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.

[Match]
OriginalName=*

[Link]
NamePolicy=keep kernel database onboard slot path
AlternativeNamesPolicy=database onboard slot path
MACAddressPolicy=persistent

Fichier /lib/systemd/network/80-container-host0.network

Code: [Sélectionner]

#  SPDX-License-Identifier: LGPL-2.1+
#
#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.

# This network file matches the container-side of the virtual Ethernet link
# created by systemd-nspawn's --network-veth switch. See systemd-nspawn(1) for
# details.

[Match]
Virtualization=container
Name=host0

[Network]
DHCP=yes
LinkLocalAddressing=yes
LLDP=yes
EmitLLDP=customer-bridge

[DHCP]
UseTimezone=yes

Fichier /lib/systemd/network/80-container-ve.network

Code: [Sélectionner]

#  SPDX-License-Identifier: LGPL-2.1+
#
#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.

# This network file matches the host-side of the virtual Ethernet link
# created by systemd-nspawn's --network-veth switch. See systemd-nspawn(1) for
# details.

[Match]
Name=ve-*
Driver=veth

[Network]
# Default to using a /28 prefix, giving up to 13 addresses per container.
Address=0.0.0.0/28
LinkLocalAddressing=yes
DHCPServer=yes
IPMasquerade=yes
LLDP=yes
EmitLLDP=customer-bridge

Fichier /lib/systemd/network/80-container-vz.network

Code: [Sélectionner]

#  SPDX-License-Identifier: LGPL-2.1+
#
#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.

# This network file matches the bridge interface created by systemd-nspawn's
# --network-zone= switch. See systemd-nspawn(1) for details.

[Match]
Name=vz-*
Driver=bridge

[Network]
# Default to using a /24 prefix, giving up to 253 addresses per virtual network.
Address=0.0.0.0/24
LinkLocalAddressing=yes
DHCPServer=yes
IPMasquerade=yes
LLDP=yes
EmitLLDP=customer-bridge

hwti · « **Réponse #20 le:** 05 avril 2023 à 19:04:28 »

Mais peut être que biosdevname était installé au dernier boot (celui qui avait donné p4p1).
En tout cas, avec le 99-default.link, systemd devrait faire le renommage (sauf si quelqu'un d'autre comme biosdevname l'a fait avant, c'est la policy "keep").