[convention] de nommage des interfaces réseaux

Discussions autour des problématiques d'administration système
Post Reply
jeanmarc
Posts: 102
Joined: Sun Mar 22, 2020 5:28 pm
Location: Essonne

[convention] de nommage des interfaces réseaux

Post by jeanmarc »

Bonjour,
Ce post pour évoquer le sujet de nommage des interfaces réseaux sous Linux.
En effet, mon parc d’équipements ayant quelque peu augmenté sur un sous système puisque .....

Code: Select all

ansible@thinkpad-410:~$ host -l TLD.jml |wc -l
1107
ansible@thinkpad-410:~$ 
J'ai été confronté à définir des règles de nommage interfaces, ceci bien entendu afin que les templates Ansibles puissent générer toutes les configurations possibles.
Je vous propose donc de partager les règles que j'ai utilisé jusqu'ici avec une tentative de justification pour chaque règle.
Il convient dans un premier temps de décrire la manière dont les flux réseaux sont organisés via quelques règles simples....

R1_flux: adm tous les flux d'admin (protocole SSH (donc Ansible)) sont sur une interface dédiée
R2_flux: ntp tous les flux temporels (ntp, sntp, ..). On cherche ici a apporter un élément de QOS afin de supprimer les désagréables erreurs en compilant du style : skew factor detected !), permettant de fait de mettre simplement en œuvre du 802.1P
R3_flux: srv tous les flux de services: Il s'agit ici de définir tous les services (hors ntp), par exemple : NFS, Apache, DNS, DHCP
R4_flux: usr tous les flux qui restent, donc à priori c'est simplement la defaut gateway (à expliquer avec le PBR !)

A partir de ces points, les conventions de nommage des interfaces sont assez simples dans ma logique du moment ...
et-xxx: interface Ethernet physique (802.3)
br-xxx: bridge réseau de niveau 2 (802.1p et 802.1q)
st-xxx: interface wireless de type STA (Station)
ap-xxx: interface wireless de type AP (Access Point)
ms-xxx: interface wireless de type Mess ( avec routage associé !)
mn-xxx: interface wireless type monitoring
ve-xxx: interface Ethernet de type Veth pour connexion entre l'hyperviseur et les VE/VM (Virtual Element / Virtual Machines)
e-xxx: interface Ethernet de type Veth pour connexion local à l'hyperviseur

Merci de faire vivre et de proposer des éléments d'améliorations afin que je puisse faire vivre cette liste ....
Last edited by jeanmarc on Thu Apr 08, 2021 4:42 pm, edited 2 times in total.
Cordialement
-W.-
Posts: 101
Joined: Sun Mar 22, 2020 5:26 pm
Location: Allier

Re: [convention] de nommage des interfaces réseaux

Post by -W.- »

Bonjour et merci à toi Jean-Marc pour lancer les discussions sur les conventions de nommage que nous nous appliquons et souhaitons partager et pourquoi améliorer pour couvrir un maximum de cas.

Je vais livrer mes commentaires au fil de l'eau. Je propose que ceux qui seront acceptés soient réintégrés dans le message d'origine qui lui évoluera donc pour refléter l'état courant de la convention. Les futures réponses pourront alors soit être une discussion sur d'autres remarques ou simplement pour dire par exemple que c'est intégré dans la nouvelle convention ou qu'elle est mise à jour.

Let's go :)

Je ne modifie pas le sens du texte initial et m’appuie dessus. Je ne le répète donc pas mais vous propose de le présenter ainsi en introduisant au passage les premières propositions.

jeanmarc wrote: Wed Apr 07, 2021 6:24 pm Bonjour,
Ce post pour évoquer le sujet de nommage des interfaces réseaux sous Linux.
En effet, mon parc d’équipements ayant quelque peu augmenté sur un sous système puisque .....

Code: Select all

ansible@thinkpad-410:~$ host -l TLD.jml |wc -l
1107
ansible@thinkpad-410:~$ 
J'ai été confronté à définir des règles de nommage interfaces, ceci bien entendu afin que les templates Ansible puissent générer toutes les configurations possible.
Je vous propose donc de rappeler les règles que j'ai utilisé jusqu'ici avec une tentative de justification pour chaque règle. Il convient dans un premier temps de décrire la manière dont les flux réseaux sont organisé via quelques règles simples....

Le nom d'une interface réseau est composé de trois champ séparés par le signe moins AKA le tiret du six :P, et doit respecter la règle suivante disant que la longueur maximale du nom est de 11 caractères, 8+3; merci qui :?: :lol:
  • Premier champ sur 2 caractères : le type d'interface
  • Deuxième champ sur 3 caractères: les contraintes liées au flux (en termes de sécurité et/ou de QoS)
  • Troisième champ sur 4 caractères: la nature fonctionnelle du flux (ou service transporté par le flux)
Soit 2 + 3 + 4 et 2 séparateurs le compte est bon, cela fait bien 11 caractères.

Je vous propose maintenant une identification des valeurs possibles pour les différents champs

Le type d'interface
  • br : bridge
  • if : interface physique
  • ve : Interface ethernet virtuelle de type veth pour les connexions entre l'hyperviseur et les VE/VM qu'il héberge (Virtual Element / Virtual Machaines)
    interface Ethernet de type Veth pour connexion entre l'hyperviseur et les VE/VM (Virtual Element / Virtual Machines)
Les contraintes liées au flux
  • adm : flux d'administration SSH (cas des accès administrateur et des opérations réalisées par Ansible au travers de SSH)
  • mc : flux multicast
  • qos : flux soumis à une QoS (tels que NTP, flux vidéo ou toute mise en œuvre du 802.1P et solutions permettant d'éviter les problèmes de type skew factor detected)
  • rt : flux temps réel
  • srv : flux des services proposés par un serveur
  • usr : flux applicatifs utilisateur : tous les flux qui restent, donc à priori c'est simplement la default gateway (à expliquer avec le PBR)
Le service fourni via l'interface
  • http : flux des applications basées sur les technologies Web
  • smtp : flux de messagerie

Exemples de noms obtenus en appliquant cette convention
  • if-usr-all : interface par défaut de la machine
  • if-adm-all : interface d'administration d'une machine
  • if-qos-ntp : interface servant à synchroniser l'heure des machines via NTP (mode client ou serveur)
  • if-srv-http : interface de flux d'un serveur web (le client utilise son interface par défaut pour le consulter)
  • if-srv-imap : interface de service d'un serveur mail IMAP (le client utilise son interface par défaut pour le consulter)
  • if-srv-mail : interface de service d'un serveur mail si les flux SMTP et IMAP ne sont pas séparés
  • xxx : interface de service d'un serveur dédiée à la streaming réplication entre deux serveurs SQL (postgresql par exemple)
  • xxx : interface de service d'un serveur SQL (MariaDB ou Postgresql par exemple)
  • xxx : interface de lecture de flux vidéo RTSP sur un client
  • xxx : interface de diffusion de flux en streaming multicast sur un serveur
  • xxx : interface de backup des données d'une machine (client ou serveur)
Merci pour les premières critiques et suite demain ;)

Ceci reste aussi à uniformiser demain :idea:
st-xxx: interface wireless de type STA (Station)
ap-xxx: interface wireless de type AP (Access Point)
ms-xxx: interface wireless de type Mess ( avec routage associé !)
mn-xxx: interface wireless type monitoring

TODO décrire ce que deviennent les interface standards eth0 et et faire le lien avec le rôle de udev

@+W.
Post Reply