Debian 13 : un nouveau nom d’interface a coupé le réseau — noms stables qui survivent aux redémarrages (cas #67)

À quoi ressemble une rupture de nommage d’interface

Le mode de panne est obstinément constant : le système démarre correctement, mais votre pile réseau est configurée pour un nom qui ne correspond plus à un périphérique réel. L’unité est « up » mais inaccessible, ou accessible seulement sur un réseau de secours, ou via un accès hors-bande uniquement.

Symptômes typiques sur Debian 13

• Hôte distant inaccessible après redémarrage, alors que la console affiche un prompt de connexion normal.
• Erreurs des services réseau comme « Cannot find device » ou « Unknown interface » provenant d’ifupdown, systemd-networkd ou NetworkManager.
• Le lien est physiquement actif (le commutateur indique un lien), mais aucune adresse IP n’est configurée.
• Routes manquantes : la route par défaut n’est pas définie parce que l’interface prévue n’a jamais monté.
• Dispositifs Bonding/VLAN/bridge manquants : si le nom de l’interface de base change, toutes les interfaces empilées cassent aussi.

Les problèmes de nommage d’interface sont le genre de bug qui vous fait douter de la réalité. Votre fichier de configuration est correct. Le câble est OK. Le switch est OK. Le serveur est OK. Il parle juste à un autre substantif.

Blague #1 : les noms d’interface « prévisibles » sont comme des règles de firewall « temporaires » — prévisibles seulement si vous ne changez jamais rien.

Faits et contexte historique (pourquoi ça se répète)

Le nommage des interfaces est un de ces sujets Linux où les comportements par défaut ont changé plusieurs fois, et chaque changement était « pour le mieux » d’une manière qui irrite toujours les opérateurs.

1. Linux utilisait auparavant eth0, eth1, … selon l’ordre de découverte, qui peut varier quand les pilotes se chargent dans un ordre différent ou que le matériel change.
2. Systemd a introduit les « noms d’interfaces réseau prévisibles » pour éviter la roulette eth0, en basant les noms sur la topologie firmware/PCI (ex. enp3s0).
3. Debian a adopté le nommage prévisible il y a des années, mais le résultat réel dépend des tables du firmware, des réglages du BIOS, et de si des règles udev ou des fichiers .link contrecarrent les valeurs par défaut.
4. Il existe plusieurs schémas de nommage : par chemin PCI (enpXsY), par index onboard (eno1), par slot (ens1), par MAC (enx...), et l’ancienne énumération classique du noyau (eth0).
5. Les images cloud utilisent souvent le matching par MAC car la « même » NIC virtuelle peut présenter des adresses PCI différentes selon la version de l’hyperviseur et le type de machine.
6. Les mises à jour de firmware peuvent modifier les informations SMBIOS/ACPI, ce qui altère subtilement le système de nommage qu’administre systemd.
7. Initramfs compte : si vous avez besoin du réseau en early boot (root iSCSI, root NFS, déverrouillage distant), des changements de nommage peuvent casser avant que l’espace utilisateur ait une chance de récupérer.
8. Les conteneurs compliquent le debug : vous pouvez voir eth0 dans un namespace alors que l’hôte a renommé la vraie NIC sous vos outils d’automatisation.
9. Les NICs en bond et les bridges amplifient la portée des dégâts : un seul renommage peut casser les esclaves de bond, les sous-interfaces VLAN, les bridges, les règles de pare-feu, la supervision, et les hypothèses des outils de configuration.

Playbook de diagnostic rapide (vérifier 1/2/3)

Ceci est la séquence « arrêtez de deviner ». Elle est optimisée pour le cas courant : le serveur est démarré, mais le réseau n’a pas été configuré parce que le nom de la NIC a changé.

Premier : confirmez que le système voit une NIC et comment elle s’appelle maintenant

• Exécutez ip -br link et ip -br addr pour lister les interfaces et celles qui ont des adresses.
• Vérifiez networkctl list si vous utilisez systemd-networkd.
• Cherchez une « nouvelle » enp*/eno*/ens* ayant l’adresse MAC attendue.

Second : confirmez ce que votre configuration réseau attend

• ifupdown : grep -R "iface" /etc/network/interfaces*
• systemd-networkd : ls /etc/systemd/network et inspectez *.network
• NetworkManager : nmcli con show et regardez connection.interface-name

Troisième : prouvez le mapping (MAC ↔ nom d’interface) et décidez de l’identifiant stable

• Utilisez ip link ou udevadm info pour faire le lien entre MAC et chemin PCI.
• Choisissez une approche : fichiers .link systemd par MAC, ou appariement par chemin PCI, ou désactiver le nommage prévisible (rarement la meilleure), selon votre environnement.

Une fois que vous pouvez répondre « quel est le nom de la NIC maintenant ? » et « qu’attend la config ? », le reste n’est que mécanique.

Tâches pratiques : commandes, sorties et décisions (12+)

Ce sont des vérifications de niveau production. Chacune indique ce que la sortie signifie et quelle décision prendre ensuite. Exécutez-les sur console si la machine est bloquée. Si vous avez encore SSH, faites-les quand même — les renommages d’interface ont tendance à revenir lors du prochain redémarrage, pas durant l’incident en cours.

Task 1: List interfaces quickly and see their operational state

cr0x@server:~$ ip -br link
lo               UNKNOWN        00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP>
enp4s0           DOWN           3c:fd:fe:aa:bb:cc <BROADCAST,MULTICAST>
enp5s0           UP             3c:fd:fe:11:22:33 <BROADCAST,MULTICAST,UP,LOWER_UP>

Signification : enp5s0 a le carrier et est up. enp4s0 existe mais est down (soit non connecté, soit administrativement down).

Décision : Concentrez-vous sur enp5s0 comme NIC primaire probable. Ensuite, confirmez si elle a l’IP attendue.

Task 2: Check which interfaces actually have IP addresses

cr0x@server:~$ ip -br addr
lo               UNKNOWN        127.0.0.1/8 ::1/128
enp4s0           DOWN
enp5s0           UP             192.0.2.10/24 2001:db8:10::10/64

Signification : Le réseau est configuré sur enp5s0. Si vous l’attendiez sur enp4s0 ou enp3s0, votre config est désynchronisée.

Décision : Si vous êtes toujours hors ligne, le problème peut venir des routes, du pare-feu, des VLANs ou de la passerelle incorrecte — pas seulement du nommage. Vérifiez le routage ensuite.

Task 3: Validate routing (default route is the usual missing piece)

cr0x@server:~$ ip route
default via 192.0.2.1 dev enp5s0
192.0.2.0/24 dev enp5s0 proto kernel scope link src 192.0.2.10

Signification : La route par défaut existe via enp5s0. Si vous ne voyez pas de ligne default, votre configuration réseau ne s’est pas appliquée ou DHCP n’a pas tourné.

Décision : Si la route par défaut manque, vérifiez les logs et la configuration du gestionnaire réseau (ifupdown/networkd/NM). Si elle existe, testez la connectivité (ARP, reachabilité de la passerelle).

Task 4: Identify what your configuration thinks the interface is named (ifupdown)

cr0x@server:~$ grep -R "iface " /etc/network/interfaces /etc/network/interfaces.d 2>/dev/null
/etc/network/interfaces:iface enp3s0 inet static
/etc/network/interfaces:iface enp3s0 inet6 static

Signification : Votre configuration attend enp3s0, mais le noyau/systemd expose actuellement enp5s0. Ce décalage seul peut vous laisser hors ligne.

Décision : Soit mettez à jour la config vers le nouveau nom (rapide mais fragile), soit imposez un nommage stable pour que le nom attendu revienne à chaque démarrage (préféré). Ne faites pas « juste éditer » dans des flottes à moins d’aimer répéter le travail.

Task 5: For systemd-networkd, list link status and what networkd thinks

cr0x@server:~$ networkctl list
IDX LINK   TYPE     OPERATIONAL SETUP
  1 lo     loopback carrier     unmanaged
  2 enp5s0 ether    routable    configured
  3 enp4s0 ether    no-carrier  unmanaged

Signification : networkd a configuré enp5s0. Si l’interface prévue est « unmanaged », vos règles de matching l’ont manquée (souvent à cause d’un renommage).

Décision : Inspectez les fichiers .network pour Name= ou MACAddress= et planifiez un identifiant stable.

Task 6: For NetworkManager, check which connection is bound to which interface

cr0x@server:~$ nmcli -f NAME,DEVICE,TYPE,STATE con show --active
NAME            DEVICE  TYPE      STATE
prod-uplink     enp5s0  ethernet  activated

Signification : Un profil de connexion nommé prod-uplink est actif sur enp5s0. Si rien n’est actif, NM peut attendre un nom d’interface spécifique.

Décision : Vérifiez nmcli con show prod-uplink pour connection.interface-name. S’il est défini sur l’ancien nom, corrigez-le ou utilisez un nommage stable.

Task 7: Map MAC addresses to interface names (the anchor of sanity)

cr0x@server:~$ ip -br link | awk '{print $1, $3}'
lo 00:00:00:00:00:00
enp4s0 3c:fd:fe:aa:bb:cc
enp5s0 3c:fd:fe:11:22:33

Signification : Vous pouvez maintenant faire correspondre l’adresse MAC de votre inventaire/port de switch/politique de sécurité au nom de périphérique Linux.

Décision : Si votre automation connaît les MAC de façon fiable, faites le matching sur MAC (systemd .link ou règles de networkd). Si les MAC changent (certains clouds), préférez d’autres attributs stables.

Task 8: Get the “ID_NET_NAME_*” hints systemd/udev computed

cr0x@server:~$ udevadm test-builtin net_id /sys/class/net/enp5s0 2>/dev/null | grep ID_NET_NAME
ID_NET_NAME_MAC=enx3cfdfe112233
ID_NET_NAME_PATH=enp5s0
ID_NET_NAME_SLOT=ens3

Signification : udev a calculé plusieurs noms candidats. Le nom actuel est enp5s0 (basé sur le chemin), mais il a aussi une suggestion par slot ens3 et par MAC enx....

Décision : Choisissez ce qui est le plus stable dans votre environnement. Les serveurs physiques se débrouillent souvent bien avec des noms basés sur le slot ou l’onboard. Les VMs peuvent mieux faire avec le MAC ou un appariement explicite.

Task 9: See the PCI path and driver for the NIC (helps explain renames)

cr0x@server:~$ lspci -nnk | grep -A3 -i ethernet
03:00.0 Ethernet controller [0200]: Intel Corporation I210 Gigabit Network Connection [8086:1533]
	Subsystem: Intel Corporation Device [8086:0001]
	Kernel driver in use: igb
	Kernel modules: igb

Signification : L’adresse PCI 03:00.0 est la NIC uplink. Si le firmware/BIOS réordonne les bus ou présente une topologie différente, les noms basés sur le chemin peuvent changer.

Décision : Si la topologie PCI est sujette à changement (certains serveurs avec réglages de bifurcation, bascule SR-IOV, ou cartes additionnelles), ne comptez pas uniquement sur enpXsY. Envisagez un nommage par slot ou par MAC.

Task 10: Confirm whether predictable naming is enabled via kernel cmdline

cr0x@server:~$ cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-6.12.0-1-amd64 root=UUID=8b1d... ro quiet

Signification : Aucun override net.ifnames=0 ou biosdevname=0 n’est présent. Le nommage prévisible est actif (normal sur Debian).

Décision : Ne vous précipitez pas pour désactiver le nommage prévisible globalement. C’est un dernier recours. Préférez un nommage explicite via des fichiers .link ou des règles de matching.

Task 11: Spot naming-related logs around boot

cr0x@server:~$ journalctl -b -u systemd-udevd --no-pager | grep -E "renamed|ID_NET_NAME|link_config"
Dec 30 10:12:01 server systemd-udevd[322]: enp3s0: Interface name change detected, renamed to enp5s0

Signification : udev a enregistré explicitement un renommage de l’ancien vers le nouveau. C’est votre preuve évidente.

Décision : Mettez en place un nommage stable pour éviter que les références de config deviennent obsolètes. Cherchez aussi des règles udev ou des fichiers .link personnalisés qui pourraient entrer en conflit.

Task 12: Check for existing systemd .link files that might override names

cr0x@server:~$ ls -1 /etc/systemd/network/*.link 2>/dev/null
/etc/systemd/network/10-uplink.link

Signification : Vous avez déjà un override. Il peut être erroné, périmé ou en conflit avec les valeurs par défaut de la distribution.

Décision : Inspectez-le attentivement. S’il matche trop largement (ex. match par pilote seulement), il peut renommer la mauvaise NIC après des changements matériels.

Task 13: Inspect a .link file and verify it matches only the intended interface

cr0x@server:~$ sed -n '1,120p' /etc/systemd/network/10-uplink.link
[Match]
MACAddress=3c:fd:fe:11:22:33

[Link]
Name=uplink0

Signification : C’est le bon type d’override : match sur un MAC unique et attribution d’un nom lisible.

Décision : Si le MAC est correct, cela survivra aux redémarrages et aux réarrangements PCI. Si le MAC change (clonage VM, remplacement de NIC), mettez à jour ce fichier et reconstruisez les dépendances d’early-boot si nécessaire.

Task 14: Apply naming changes safely (restart udev and replug is not always enough)

cr0x@server:~$ sudo udevadm control --reload
cr0x@server:~$ sudo udevadm trigger -c add -s net

Signification : Recharge les règles udev et déclenche les périphériques net. Les renommages peuvent ou non s’appliquer à chaud ; systemd est prudent concernant le renommage des interfaces actives.

Décision : Planifiez une fenêtre de redémarrage contrôlée après la mise en place du nommage stable. Pour les systèmes distants, assurez-vous d’avoir un accès hors-bande ou une connexion de secours d’abord.

Task 15: Validate link and negotiation (because sometimes it’s not naming)

cr0x@server:~$ sudo ethtool enp5s0 | egrep "Link detected|Speed|Duplex"
Speed: 1000Mb/s
Duplex: Full
Link detected: yes

Signification : Le lien physique est bon. Si le lien est down, le renommage peut être un leurre et votre « nouvelle NIC » est celle débranchée.

Décision : Si le lien est down, vérifiez le port de commutateur/VLAN/patch et confirmez que vous liez le bon MAC au bon port.

Causes profondes : comment Debian 13 obtient un « nouveau » nom de NIC

Debian 13 ne s’est pas réveillé et n’a pas choisi le chaos. Les noms d’interface sont calculés à partir des informations que l’OS reçoit du noyau, du firmware et des règles udev. Quand l’une de ces entrées change, le nom peut changer. Voici les déclencheurs courants que j’ai observés en environnement réel.

1) La topologie PCI a changé (matériel réel ou « matériel virtuel »)

Les noms basés sur le chemin comme enp5s0 encodent le bus/device/function PCI. Si la numérotation des bus change, le nom change. Causes possibles : mises à jour BIOS, activation/désactivation de SR-IOV, modification des réglages de bifurcation PCIe, ajout/suppression de cartes, ou même déplacement d’une NIC vers un autre slot.

2) Le firmware a commencé à rapporter différemment les indices slot/onboard

Les noms tels que eno1 (onboard) et ens1 (slot) reposent sur des indices fournis par le firmware. Quand les tables firmware changent, le nom « prévisible » de Linux devient prévisiblement différent.

3) Un nouveau noyau/driver a modifié le timing d’énumération

C’est l’ancien problème eth0 sous une nouvelle forme. Même avec le nommage prévisible activé, il y a des cas limites où le système retombe sur d’autres heuristiques si l’information de nommage préférée n’est pas disponible assez tôt.

4) Règles udev ou fichiers .link systemd en conflit

Une équipe ajoute une règle large (« renomme toutes les NIC Intel en lan0 »), une autre équipe en ajoute une différente, et maintenant celle qui s’exécute la dernière gagne. Pas forcément malveillant : juste de la configuration distribuée.

5) Clonage de VM et changements d’adresse MAC

Le nommage par MAC est stable seulement si le MAC est stable. Clonez une VM, régénérez les MAC, et vos noms enx... soigneusement épinglés deviennent neufs. cloud-init et les outils d’hyperviseur essaient souvent d’aider, parfois avec succès.

6) Réseau en early-boot (initramfs) utilisant une vue de nommage différente

Si le système a besoin du réseau dans l’initramfs (déverrouillage distant, root iSCSI), vous pouvez avoir des échecs avant que le système de fichiers racine soit monté. Corriger le nommage uniquement dans /etc peut ne pas suffire si l’initramfs attend encore l’ancien nom.

Une citation pour rester honnête, paraphrasant une idée de John Allspaw : La fiabilité vient de comment les systèmes se comportent réellement sous changement, pas de comment nous aimerions qu’ils se comportent sur les diagrammes.

Stratégies de nommage stable qui survivent aux redémarrages

Vous avez trois approches générales. Deux sont bonnes. Une est tentante. Choisissez selon l’environnement, pas selon votre humeur.

Stratégie A (recommandée) : fichiers systemd .link renommant par MAC (ou autres propriétés uniques)

C’est la manière la plus directe d’affirmer : « l’interface avec ce MAC s’appelle uplink0 ». C’est explicite, relisible et survit aux redémarrages. Sur des hôtes physiques où les MAC ne changent pas, c’est ennuyeux dans le meilleur sens.

Créer un fichier .link :

cr0x@server:~$ sudo tee /etc/systemd/network/10-uplink.link >/dev/null <<'EOF'
[Match]
MACAddress=3c:fd:fe:11:22:33

[Link]
Name=uplink0
EOF

Ce que cela signifie : systemd-udevd renommer­a l’interface correspondant à ce MAC en uplink0 pendant l’initialisation du périphérique.

Décision : Utilisez ceci si le MAC est stable et unique. Ne match‑ez pas uniquement par pilote ou vendeur sauf si vous aimez les surprises imprévisibles.

Puis ajustez votre config réseau pour utiliser uplink0 :

• ifupdown : changez iface enp3s0 en iface uplink0
• systemd-networkd : [Match] Name=uplink0
• NetworkManager : définissez connection.interface-name uplink0 ou liez par MAC

Stratégie B (souvent la meilleure pour systemd-networkd) : matcher dans .network par MAC et éviter le renommage

Si le nom attribué par le noyau ne vous importe pas, ne le renommez pas — contentez-vous de le matcher. Cela réduit les surprises de renommage et évite les cas limites où le renommage interfère avec d’autres services.

Exemple de config networkd matchant par MAC :

cr0x@server:~$ sudo tee /etc/systemd/network/10-uplink.network >/dev/null <<'EOF'
[Match]
MACAddress=3c:fd:fe:11:22:33

[Network]
Address=192.0.2.10/24
Gateway=192.0.2.1
DNS=192.0.2.53
EOF

Ce que cela signifie : Que l’interface s’appelle enp5s0 aujourd’hui ou enp2s0 après le prochain BIOS, networkd la configurera quand même.

Décision : Préférez ceci pour des flottes où vous n’avez pas besoin de noms lisibles par l’humain, juste d’un comportement cohérent.

Stratégie C (dernier recours) : désactiver le nommage prévisible et revenir à eth0

Vous pouvez forcer les anciens noms via des paramètres noyau. Utile pour compatibilité dans des environnements legacy très contraints, mais c’est une régression dans la plupart des flottes modernes. L’ordre de découverte peut toujours changer. Vous rejouez la roulette « quelle NIC est eth0 aujourd’hui ? »

Paramètres tentants : ajouter net.ifnames=0 biosdevname=0 à GRUB.

cr0x@server:~$ sudo sed -i 's/GRUB_CMDLINE_LINUX="/GRUB_CMDLINE_LINUX="net.ifnames=0 biosdevname=0 /' /etc/default/grub
cr0x@server:~$ sudo update-grub
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.12.0-1-amd64
done

Ce que cela signifie : Vous demandez au noyau/udev d’arrêter d’utiliser des noms prévisibles. Les interfaces seront probablement eth0, eth1.

Décision : Faites-le uniquement si vous avez un environnement contrôlé et pouvez vérifier la stabilité de l’énumération — ou si vous achetez du temps pour migrer hors des configs basées sur le nom.

Ce que je recommande réellement

Pour les serveurs physiques : utilisez le renommage .link par MAC pour obtenir des noms signifiants comme uplink0, storage0, oob0. Vous me remercierez lors d’incidents.

Pour les VMs et le cloud : utilisez le matching par MAC dans votre gestionnaire réseau (ou l’intégration cloud-init) et évitez de sur-ajuster sur la topologie PCI que l’hyperviseur peut modifier.

Blague #2 : Si vous nommez les interfaces d’après leur chemin PCI, souvenez-vous que le chemin change plus vite que la personne en astreinte.

Trois mini-récits d’entreprise depuis le terrain

Mini-récit 1 : La panne causée par une mauvaise hypothèse

Ils avaient une configuration propre : hôtes Debian, quelques NIC, VLANs pour front-end et back-end, et une convention bienveillante que « le port de gauche est toujours enp3s0 ». Ce n’était pas consigné, mais traité comme une loi de la physique.

Puis une mise à jour firmware a été déployée sur un lot de serveurs. Elle n’a pas changé les pilotes. Elle n’a pas changé l’OS. Elle a changé la façon dont le BIOS décrivait la topologie PCI. Au redémarrage, le « port de gauche » est devenu enp4s0. Le gestionnaire de configuration continuait d’écrire /etc/network/interfaces pour enp3s0.

La moitié des serveurs sont revenus sans uplink. L’autre moitié est revenue « bien », ce qui est le pire type d’échec partiel car cela convainc la direction que c’est un cas isolé.

Le postmortem a trouvé la vraie panne : ils supposaient que les noms d’interface étaient assez stables pour être traités comme des étiquettes de ports physiques. Mais Linux ne regarde pas vos doigts sur le panneau arrière ; il regarde les métadonnées du firmware. La correction a été simple : matcher la configuration réseau par MAC, et pour les humains renommer en uplink0 via .link. La partie difficile fut d’admettre que l’hypothèse était le bug.

Mini-récit 2 : L’optimisation qui s’est retournée contre eux

Une autre organisation en avait marre des noms d’interface « moches ». Ils voulaient tout standardiser : lan0, lan1, stor0. Objectif raisonnable. L’exécution a posé problème.

Ils ont écrit une règle udev matchant par pilote et vendor PCI. Quelque chose comme « toute NIC Intel devient lan0 sauf si déjà prise ». Ça marchait en labo. Ça marchait sur quelques serveurs. Puis un renouvellement matériel a apporté des cartes dual‑port avec le même pilote. Soudain les deux ports correspondaient à la même règle.

Au démarrage, le « gagnant » de lan0 variait selon le timing d’énumération. Leur config réseau s’appliquait à la NIC qui avait pris le nom en premier. Certains serveurs ont démarré avec front-end et stockage interchangés. Ce n’est pas « down » ; c’est « up dangereusement ».

Ils ont retiré la règle udev et l’ont remplacée par des fichiers .link systemd matchant par MAC, un fichier par interface, versionnés dans leur repo de config. Moins ingénieux. Plus correct. Aussi nettement moins stressant lors des audits.

Mini-récit 3 : La pratique ennuyeuse qui a sauvé la mise

Celle-ci est presque décevante. Une équipe plateforme avait une règle : chaque build de serveur incluait une cartographie enregistrée des MAC des NIC vers leur rôle (« uplink », « storage », « cluster »), stockée avec les données de provisioning de la machine. Elle était mise à jour lors des remplacements de NIC. Pas d’actions héroïques. Juste une tenue de livres ennuyeuse.

Quand les upgrades Debian 13 ont commencé, une poignée d’hôtes sont revenus avec des interfaces renommées à cause d’un changement de réglage BIOS sur un sous‑ensemble de machines. La supervision a déclenché : « host unreachable ». L’astreinte a utilisé la console hors‑bande, a lancé ip -br link, et a immédiatement apparié les MAC aux rôles connus.

Ils n’ont pas deviné. Ils n’ont pas changé de câbles. Ils n’ont pas réécrit les configs aveuglément. Ils ont appliqué le correctif standard : régénérer les fichiers .link depuis l’inventaire, redémarrer une fois, confirmer la route et la passerelle, fermer l’incident.

La leçon n’est pas glamour : le nommage stable est moitié solution technique, moitié hygiène opérationnelle. Si vous ne savez pas quel MAC correspond à quoi, vous faites de l’archéologie pendant une panne.

Erreurs courantes (symptôme → cause → correction)

1) « Après le redémarrage, SSH est mort, mais la console accepte la connexion. »

Cause racine : la configuration réseau référence un nom d’interface obsolète (enp3s0) qui n’existe plus.

Correction : identifiez le nom d’interface actuel via ip -br link, puis implémentez un nommage stable (systemd .link ou matching par MAC) et mettez à jour la config réseau en conséquence.

2) « Le nom de la NIC a changé, donc on a édité la config. Il a changé à nouveau après la mise à jour. »

Cause racine : dépendre de noms basés sur la topologie dans un environnement où la topologie PCI n’est pas stable (VMs, changements de firmware, cartes additionnelles).

Correction : arrêtez de courir après les noms. Match par MAC dans votre gestionnaire réseau, ou renommez par MAC vers un nom de rôle.

3) « Bond0 ne monte pas ; les logs montrent qu’il ne peut pas esclaver l’interface. »

Cause racine : les noms des esclaves du bond ont changé ; la config du bond référence d’anciens esclaves.

Correction : match des esclaves de bond par MAC (là où c’est supporté) ou imposez des noms d’esclaves stables via .link. Puis mettez à jour la configuration du bond avec ces noms stables.

4) « Interface VLAN manquante : enp3s0.100 n’existe pas. »

Cause racine : l’interface de base a été renommée ; la sous-interface VLAN dépend du nom de base.

Correction : stabilisez le nom de base (ou utilisez un bridge/bond stable comme parent VLAN), puis recréez les VLANs.

5) « NetworkManager dit la connexion activée, mais elle est sur la mauvaise NIC. »

Cause racine : le profil de connexion n’est pas lié à l’interface ou est trop lâche ; NM a choisi un autre périphérique après le renommage.

Correction : définissez connection.interface-name ou liez par MAC dans le profil de connexion ; vérifiez avec nmcli.

6) « On a créé une règle udev pour renommer les NIC ; maintenant les noms se mélangent parfois. »

Cause racine : critères de matching trop larges (pilote/vendeur) et ordre non déterministe des renommages.

Correction : utilisez un matching par MAC ou par chemin stable par interface ; préférez les fichiers .link systemd aux règles udev custom sauf raison forte.

7) « L’interface est nommée correctement, mais elle n’obtient toujours pas d’IP. »

Cause racine : vous avez corrigé le nommage mais oublié le gestionnaire : conflit ifupdown vs networkd vs NetworkManager, ou le mauvais service est activé.

Correction : choisissez un gestionnaire réseau, désactivez les autres, et assurez-vous que le bon gère le périphérique.

8) « Tout fonctionnait jusqu’à ce qu’on active SR-IOV ; ensuite les noms ont changé. »

Cause racine : SR-IOV change la façon dont les fonctions sont exposées ; l’adressage PCI et le nommage netdev peuvent basculer.

Correction : utilisez le matching par MAC ou un nommage basé sur le slot ; documentez l’activation de SR-IOV comme un changement à risque pour le nommage.

Listes de contrôle / plan étape par étape

Checklist A : Récupérer un hôte Debian 13 bloqué après un renommage de NIC

1. Obtenez un accès console (IPMI/iDRAC/ILO, console hyperviseur, ou local).
2. Exécutez ip -br link et ip -br addr. Identifiez le nouveau nom d’interface et le MAC.
3. Confirmez le MAC attendu depuis l’inventaire ou la sécurité du port de switch (si disponible).
4. Vérifiez quel gestionnaire réseau est en charge :
   • ifupdown : cat /etc/network/interfaces
   • networkd : networkctl list
   • NetworkManager : nmcli con show --active
5. Appliquez un correctif de nommage stable :
   • Préférez un fichier .link renommant par MAC vers uplink0, ou
   • Match par MAC dans la config du gestionnaire réseau (pas de renommage).
6. Mettez à jour les configs dépendantes : bonds, bridges, VLANs, règles de pare-feu qui référencent les anciens noms.
7. Rechargez les configs quand c’est sûr ; sinon planifiez un redémarrage.
8. Avant le redémarrage, vérifiez que vous avez toujours un accès hors-bande et un plan de rollback.
9. Redémarrez une fois. Confirmez :
   • ip -br addr montre l’IP correcte sur l’interface prévue
   • ip route contient la route par défaut
   • Le ping vers la passerelle fonctionne

Checklist B : Prévenir cela dans une flotte (le plan « jamais plus »)

1. Choisissez votre ancre de stabilité selon l’environnement :
   • Physique : MAC ou nom basé sur le slot ; évitez le path-based quand le firmware change souvent.
   • VM/cloud : matching par MAC (souvent), ou identifiants stables spécifiques au provider si les MAC sont recyclés.
2. Standardisez des noms de rôle : uplink0, storage0, cluster0. Évitez la nostalgie eth0.
3. Conservez les mappings MAC↔rôle dans vos données de provisioning. Tenez-les à jour lors des remplacements de NIC.
4. Déployez des fichiers systemd .link (ou des règles de matching du gestionnaire) via la gestion de configuration.
5. Ajoutez une étape CI/validation : si les noms d’interface dans la config n’existent pas sur la classe d’hôte, échouez le build/deploy.
6. Pendant les changements de BIOS/firmware, traitez « le nommage d’interface peut changer » comme un risque réel et testez un hôte canari de bout en bout.
7. Exigez un accès hors-bande pour tout hôte qui peut se mettre hors ligne (surtout stockage, hyperviseurs, routeurs).

Checklist C : Après avoir corrigé le nommage, vérifiez que vous n’avez pas cassé le reste de la pile réseau

1. Lien : ethtool uplink0 montre Link detected: yes.
2. Adressage : ip -br addr montre les IPv4/IPv6 attendues.
3. Routage : ip route contient la route par défaut sur l’interface prévue.
4. ARP/neigh : ip neigh show dev uplink0 contient une entrée de passerelle atteignable après ping.
5. DNS : resolvectl status (ou vérifiez /etc/resolv.conf) correspond aux attentes.
6. Pare-feu : si vous utilisez des règles liées aux interfaces, confirmez qu’elles référencent le nouveau nom stable.
7. Dépendances : bonds/bridges/VLANs sont up (ip -d link est votre ami).

FAQ

1) Pourquoi Debian 13 a-t-il renommé mon interface alors que rien n’a changé ?

Quelque chose a changé. Ça peut être les tables du firmware, la numérotation PCI, un comportement noyau/driver, ou l’évaluation des règles udev/systemd. « Rien n’a changé » veut souvent dire « rien que j’aie changé volontairement ». Vérifiez journalctl pour les événements de renommage et comparez la topologie PCI avec lspci.

2) Dois-je désactiver les noms d’interface réseau prévisibles ?

Pas en premier recours. Les désactiver peut réintroduire des problèmes d’ordre d’énumération. Utilisez plutôt des fichiers systemd .link ou le matching par MAC. Ne désactivez que si la compatibilité l’exige et que vous pouvez valider la stabilité.

3) Le matching par MAC est-il toujours sûr ?

Sur les serveurs physiques, généralement oui. Sur des VMs clonées, parfois non. Si les adresses MAC changent via clonage, redeploy ou comportement du provider, vous avez besoin d’une automation qui met à jour les mappings — ou d’un sélecteur stable différent.

4) Qu’est‑ce qui est mieux : renommer via .link ou matcher par MAC dans networkd ?

Renommer vous donne des noms humains stables et aide avec les règles de pare-feu et les tableaux de bord. Matcher par MAC évite les cas limites du renommage et conserve le nom choisi par le noyau. Si beaucoup d’outils référencent des noms d’interface, renommez vers des noms de rôle. Si vous voulez juste que le réseau soit configuré correctement, le matching par MAC est propre.

5) Un fichier .link prend-il effet immédiatement ?

Parfois, mais ne comptez pas dessus. Le renommage d’interfaces actives est volontairement restreint. En pratique vous implémentez le fichier, rechargez udev, et planifiez un redémarrage pour être certain.

6) Comment cela interagit‑il avec les bonds et les bridges ?

Ces dispositifs référencent souvent des noms d’esclaves. Si les noms des esclaves changent, les bonds ne s’assemblent pas ; si le nom du bond change, bridges et VLANs échouent. Stabilisez d’abord les interfaces physiques de bas niveau, puis reconstruisez la pile au-dessus.

7) Quid d’initramfs et du réseau en early boot ?

Si vous dépendez d’un réseau précoce (déverrouillage distant, root iSCSI), assurez-vous que le nommage/matching est disponible dans l’initramfs aussi. Sinon, la machine peut échouer avant d’atteindre l’espace utilisateur normal. Cela signifie généralement mettre à jour l’initramfs après votre changement de nommage.

8) Nous utilisons des règles de pare-feu liées aux noms d’interface. Que faire ?

Cessez de lier des règles à des noms volatiles. Soit renommez les interfaces en noms de rôle stables (uplink0), soit liez le filtrage à des zones/adresses/marks selon le cas. Si vous devez utiliser des noms, rendez‑les stables via .link.

9) Puis-je choisir un nom comme eth0 via .link ?

Vous pouvez, mais ce n’est probablement pas souhaitable. Les noms basés sur les rôles sont plus clairs en incident et évitent la confusion avec des attentes legacy. Si une appli legacy exige eth0, renommez délibérément et documentez‑le.

10) Quel est le correctif le plus rapide et sûr en cas de panne ?

Match le bon NIC par MAC et remontez le réseau avec le gestionnaire que vous utilisez déjà. Si votre config est basée sur le nom, une édition rapide vers le nouveau nom restaure la connectivité — puis suivez avec un correctif de nommage stable pour éviter de répéter l’incident au prochain redémarrage.

Conclusion : prochains pas réalisables aujourd’hui

Si Debian 13 a renommé votre interface et cassé le réseau, la leçon n’est pas « Debian est instable ». La leçon est « les noms d’interface sont des données dérivées ». Les données dérivées changent quand les entrées changent.

Faites ceci ensuite :

1. Choisissez une stratégie d’identité stable : matching MAC pour la plupart des cas ; nommage basé sur le slot quand le firmware est fiable ; évitez le path-based dans les topologies instables.
2. Implémentez la stabilité explicitement : fichiers systemd .link pour renommer en noms de rôle, ou matching par MAC dans votre gestionnaire réseau.
3. Corrigez la chaîne de dépendances : bonds, VLANs, bridges, règles de pare-feu, contrôles de monitoring — tout ce qui référençait l’ancien nom.
4. Consignez le mapping : MAC ↔ rôle ↔ port du switch. Ce n’est pas glamour, mais ça termine les incidents rapidement.
5. Redémarrez une fois à vos conditions : vérifiez le lien, l’IP, les routes et la reachabilité. Puis passez à autre chose.

Les pannes réseau causées par des renommages d’interface sont évitables. L’astuce est de traiter le nommage comme une configuration, pas comme une surprise découverte.