Renommer ses interfaces réseau pour isoler les usages

Tue, 27 May 2025 00:00:00 +0000

La gestion des interfaces réseau sur Linux, notamment dans des environnements virtualisés ou à haute disponibilité, nécessite une identification claire et persistante des interfaces physiques. Cet article explique pourquoi et comment automatiser le renommage des interfaces réseau à l’aide d’Ansible et de règles udev, afin de garantir une administration simplifiée et fiable.

Pourquoi renommer les interfaces réseau ?

Pour faciliter l’administration de nos machines, nous avons pris la décision de renommer les interfaces dites “prédictibles” des distributions Linux modernes. Pourquoi et comment ? Me direz-vous…

Le contexte

En effet, à la place de enoX ou enpXsX, nous préférons utiliser des noms liés à l’usage de ces interfaces.

Sur nos serveurs qui fondent l’infrastructure du Cloud du Coeur (exemple : hyperviseurs OpenStack, noeuds réseau, etc), nous avons 4 interfaces physiques connectées pour la redondance.

Interface physique	Vitesse	Usage	Nom souhaité
2x RJ45 on-board	1 Gbps	Management	mgt0, mgt1
2x QSFP (cartes dédiées)	100 Gbps	Production	prd0, prd1

Pour schématiser les interfaces d’un point de vue physique :

Pour schématiser les interfaces d’un point de vue virtuel :

Quels sont les avantages ?

Clarté et maintenance facilitée : Les noms mgtX et prdX permettent d’identifier immédiatement à quel usage correspond chaque interface physique.
Gestion simplifiée des bonds : En regroupant les interfaces selon leur rôle, on peut facilement configurer et monitorer les bonds réseau dédiés à la gestion ou à la production.
Simplification en cas de remplacement d’une carte : Il suffira de remplacer l’adresse MAC côté udev et la nouvelle interface récupèrera le même nom que l’ancienne et réintégrera automatiquement le bon agrégat.

Passons à la technique

Prérequis

Accès root sur les machines cibles
Ansible installé sur la machine de contrôle
Facts Ansible collectés (gather_facts: yes)

Comment appliquer (de manière automatisée) ?

Voici un bout de code ansible, outil utilisé chez nous pour le déploiement de configuration sur nos machines.

---
- name: Rename network interfaces persistently using udev rules
 hosts: all
 become: true
 vars:
 udev_rules_file: /etc/udev/rules.d/10-network-interfaces.rules
 reboot_after: true
 disable_predictable_naming: true

 tasks:
 - name: Filter physical interfaces (exclude loopback, docker, veth, bridge, bond, virbr)
 set_fact:
 physical_ifaces: >-
 {{
 ansible_interfaces
 | reject('match', '^lo$')
 | reject('match', '^docker.*')
 | reject('match', '^veth.*')
 | reject('match', '^br.*')
 | reject('match', '^bond.*')
 | reject('match', '^virbr.*')
 | list
 }}

 - name: Collect MAC and speed data for each physical interface
 set_fact:
 iface_data: >-
 {{
 iface_data | default([]) + [{
 "name": item,
 "mac": hostvars[inventory_hostname]['ansible_' + item]['macaddress'] | default(''),
 "speed": hostvars[inventory_hostname]['ansible_' + item]['speed'] | default(0)
 }]
 }}
 loop: "{{ physical_ifaces }}"
 when: hostvars[inventory_hostname]['ansible_' + item] is defined and
 hostvars[inventory_hostname]['ansible_' + item]['macaddress'] is defined

 - name: Separate 1G (MGT) and 10G+ (PRD) interfaces
 set_fact:
 mgt_ifaces: "{{ iface_data | selectattr('speed', '==', 1000) | list }}"
 prd_ifaces: "{{ iface_data | selectattr('speed', '>=', 100000) | list }}"

 - name: Debug classified physical interfaces
 debug:
 msg:
 - "MGT interfaces (1G): {{ mgt_ifaces }}"
 - "PRD interfaces (100G+): {{ prd_ifaces }}"

 - name: Generate udev rules content
 set_fact:
 udev_rules: |
 {% for iface in mgt_ifaces %}
 SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="{{ iface.mac }}", NAME="mgt{{ loop.index0 }}"
 {% endfor %}
 {% for iface in prd_ifaces %}
 SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="{{ iface.mac }}", NAME="prd{{ loop.index0 }}"
 {% endfor %}

 - name: Show generated udev rules
 debug:
 var: udev_rules

 - name: Write udev rules to file
 copy:
 dest: "{{ udev_rules_file }}"
 content: "{{ udev_rules }}"
 owner: root
 group: root
 mode: '0644'

 - name: Disable predictable interface names (optional)
 file:
 path: /etc/udev/rules.d/80-net-setup-link.rules
 state: link
 src: /dev/null
 when: disable_predictable_naming

 - name: Reboot system if required
 reboot:
 msg: "Reboot required after applying udev rules"
 reboot_timeout: 300
 when: reboot_after and udev_rules | length > 0

👉🏼

Stockez le contenu dans un fichier yaml qui pourrait se nommer rename-interfaces.yml par exemple.

Application

Pour appliquer le playbook :

ansible-playbook -i hosts rename-interfaces.yml

Vérification

Après redémarrage, vérifiez que les interfaces portent bien les nouveaux noms :

ip link show
# ou
ls /sys/class/net

Vous devriez voir apparaître les interfaces mgt0, mgt1, prd0, prd1.

Rollback

Pour revenir en arrière, il suffit de supprimer le fichier de règles udev :

rm /etc/udev/rules.d/10-network-interfaces.rules
reboot

Liens complémentaires

Grâce à cette méthode, la gestion des interfaces réseau devient plus claire, plus fiable et plus facilement automatisable, même lors de changements matériels. Bien sûr cette méthode est très utile dans notre contexte où toutes les machines qui constituent le “Cloud du Coeur” (dans l’underlay) sont identiques.

Lancement du blog technique

Thu, 22 May 2025 00:00:00 +0000

Nous sommes fiers d’annoncer le lancement de notre blog technique dédié au projet du Cloud du Coeur !

À travers ce blog, nous souhaitons partager avec la communauté technique francophone nos retours d’expérience, nos avancées et nos réflexions autour de l’infrastructure, d’OpenStack, de Kubernetes, du réseau, de l’automatisation et de tous les sujets qui font vivre notre plateforme.

Notre objectif : rendre nos choix techniques transparents, valoriser le travail collaboratif, et permettre à d’autres associations ou collectifs de s’inspirer de notre démarche pour bâtir des infrastructures ouvertes, résilientes et responsables.

Nous publierons régulièrement des articles courts ou longs, des tutoriels, des retours d’incidents (post-mortems), et des astuces issues de notre quotidien.

Merci à toutes celles et ceux qui nous suivent, et bienvenue sur ce nouvel espace d’échange et de partage !

L’équipe du Cloud du Coeur.

Cloud du Coeur - Documentation – Blog technique