Trunk informatique - Comment transporter vos VLAN sans erreur ?

Le trunk informatique correspond à une liaison réseau capable de transporter plusieurs VLAN sur un seul lien physique, sans mélanger leurs flux. C’est une brique discrète, mais elle change tout dès qu’on doit relier des commutateurs, un routeur ou une plateforme de virtualisation tout en gardant la segmentation logique. Dans cet article, j’explique comment fonctionne cette technique, quand elle est utile, où se trouvent les pièges et comment je la mets en place proprement.

Ce qu’est un trunk réseau et ce qu’il ne fait pas

Un trunk est une liaison qui transporte plusieurs réseaux logiques, le plus souvent des VLAN, sur un seul support physique. Autrement dit, au lieu de tirer un câble par segment, on fait passer plusieurs flux distincts dans la même infrastructure, tout en gardant chaque VLAN séparé au niveau logique.

Le point important, et c’est là qu’il y a souvent confusion, c’est que le trunk ne fusionne pas les domaines de broadcast. Il les fait coexister sur le même lien, mais chaque trame reste associée à son VLAN. En pratique, cela permet de relier des commutateurs entre eux, de raccorder un routeur à plusieurs sous-réseaux, ou d’alimenter un hyperviseur qui héberge plusieurs machines virtuelles dans des VLAN différents.

Juniper documente d’ailleurs que l’encapsulation 802.1Q permet de canaliser une interface Ethernet en plusieurs interfaces logiques, ce qui résume bien l’intérêt du mécanisme. Je trouve cette formulation très juste: on n’augmente pas la magie du réseau, on organise mieux le transport. Et c’est précisément cette organisation qui mérite d’être comprise avant de regarder le marquage des trames.

Comment fonctionne l’encapsulation 802.1Q

Le trunk s’appuie le plus souvent sur la norme IEEE 802.1Q. Le principe est simple: lorsqu’une trame traverse une liaison trunk, elle reçoit une balise qui indique à quel VLAN elle appartient. Cette balise ajoute 4 octets à la trame et permet au commutateur ou à l’équipement voisin de la remettre dans le bon contexte à l’arrivée.

Sur certaines plateformes, on peut gérer jusqu’à 4095 VLAN distincts, même si la limite pratique dépend du matériel et du système d’exploitation réseau. Ce chiffre n’est pas là pour impressionner; il rappelle surtout que le modèle est conçu pour des environnements où la segmentation doit rester fine, même quand le nombre de réseaux logiques devient élevé.

Le rôle du VLAN natif

Sur une liaison 802.1Q, une partie du trafic peut sortir sans balise: c’est le cas du VLAN natif. Ce détail est crucial, parce qu’un mauvais alignement du VLAN natif entre les deux extrémités provoque des symptômes bizarres, souvent intermittents, qui font perdre du temps au dépannage.

Cisco rappelle explicitement que le VLAN natif d’un trunk 802.1Q doit être identique aux deux extrémités de la liaison. En pratique, je considère ce point comme non négociable: si le natif n’est pas aligné, il faut corriger avant de chercher des causes plus exotiques. C’est souvent le genre de défaut qui ne casse pas tout, mais qui dégrade juste assez pour rendre l’incident agaçant.

Une fois ce mécanisme clarifié, la vraie question devient simple: dans quels scénarios le trunk apporte-t-il un bénéfice réel, et pas seulement une complexité de plus ?

Dans quels cas le trunk est utile

• Entre deux commutateurs pour propager plusieurs VLAN sans multiplier les ports physiques.
• Entre un commutateur et un routeur dans une architecture de type router-on-a-stick, quand un seul lien porte plusieurs sous-réseaux à router.
• Entre un switch et un hyperviseur pour alimenter des machines virtuelles appartenant à des VLAN différents.
• Pour des réseaux voix et données quand il faut garder les flux séparés tout en partageant la même infrastructure.
• Pour des environnements invités ou d’administration où la segmentation doit rester stricte sans tirer de câble supplémentaire.

Je vois souvent le trunk comme un outil de densification intelligente du réseau: il évite d’ajouter du cuivre là où le besoin est surtout logique. Cela dit, il ne faut pas lui demander plus que ce qu’il sait faire. Si la vraie contrainte est la bande passante agrégée, ce n’est pas le trunk VLAN qui résout le problème à lui seul. C’est là qu’il faut distinguer clairement les mécanismes suivants.

Ne pas confondre trunk, port access et agrégation de liens

Les trois notions sont souvent mélangées dans les discussions techniques, alors qu’elles répondent à des besoins différents. Pour éviter les contresens, je les compare toujours sur trois axes: ce qui passe, à quoi ça sert, et ce que l’on risque de mal interpréter.

Le point pratique à retenir est le suivant: on peut très bien faire cohabiter un trunk et une agrégation de liens. Juniper comme Cisco documentent ce type d’usage, parce qu’un bundle physique peut transporter un lien logique VLAN. Dit autrement, l’un traite la question du nombre de VLAN, l’autre la question du nombre de liens. Ce n’est pas la même couche de problème.

Comment configurer un trunk proprement

Quand je mets un trunk en place, je procède toujours dans le même ordre. Cela évite les configurations "qui marchent presque" et les corrections à l’aveugle.

1. Je définis le besoin réel. Je liste les VLAN qui doivent vraiment traverser la liaison, sans ajouter ceux qui ne servent à rien.
2. Je fixe le mode trunk des deux côtés. Je m’assure que les deux interfaces parlent le même langage, en particulier 802.1Q.
3. Je verrouille le VLAN natif. Je vérifie qu’il est identique à chaque extrémité et qu’il est clairement documenté.
4. Je limite les VLAN autorisés. Je n’ouvre pas tout par défaut; je laisse passer uniquement ce qui est nécessaire.
5. Je teste avec un VLAN de production et un VLAN de contrôle. Cela permet de repérer rapidement un oubli de balise, de filtrage ou de routage.

Lire aussi : Trunk SIP - Comment réussir votre migration vers la téléphonie IP ?

Les vérifications que je fais systématiquement

• Le VLAN natif est identique des deux côtés.
• La liste des VLAN autorisés est symétrique ou volontairement différente, mais jamais par accident.
• Le port voisin n’est pas resté en mode access.
• Les machines en amont et en aval utilisent bien les bons tags ou le bon sous-réseau.
• La liaison est tracée dans la documentation réseau, surtout si elle sert plusieurs services critiques.

Cette méthode paraît simple, mais elle réduit énormément les erreurs de configuration. Et comme souvent en réseau, la simplicité n’est pas de la naïveté: c’est une façon d’enlever de la variabilité avant d’aller chercher les vraies causes d’un incident.

Les erreurs qui provoquent les pannes les plus frustrantes

Les problèmes de trunk sont rarement spectaculaires. Ils sont surtout trompeurs, parce que le lien semble vivant alors qu’une partie des flux se perd ou arrive dans le mauvais VLAN.

• VLAN natif différent entre les deux extrémités: les trames non taguées tombent dans un mauvais contexte et le comportement devient incohérent.
• VLAN absent de la liste autorisée: le trafic existe quelque part dans le réseau, mais il n’est tout simplement pas transporté sur ce lien.
• Port access au lieu de trunk: Cisco documente qu’un port access rejette les trames taguées qui ne correspondent pas à son VLAN d’accès, ce qui explique bien des "ça ne passe pas" après branchement.
• Attente irréaliste sur le débit: le trunk ne compense pas une liaison trop petite, il la mutualise seulement.
• Confusion avec l’agrégation de liens: ajouter des câbles sans aligner la logique VLAN crée souvent plus de problèmes que de capacité utile.

Dans les audits que je mène, la première vérification utile n’est presque jamais "le matériel est-il en panne ?". Je commence par vérifier le mode de port, le VLAN natif et la liste des VLAN autorisés. Très souvent, l’incident est déjà visible à ce niveau. Ce réflexe m’amène naturellement à la dernière question, la plus utile à long terme: qu’est-ce qu’il faut standardiser avant de généraliser ce type de liaison ?

Ce que je standardise avant un passage en production

Si je devais résumer ma façon de travailler, je dirais que je standardise trois choses avant d’ouvrir un trunk à l’échelle d’un réseau d’entreprise: le périmètre des VLAN, le traitement du VLAN natif et la traçabilité. Sans ces trois éléments, le lien fonctionne peut-être, mais il devient difficile à maintenir dès qu’un deuxième ou un troisième changement arrive.

Je préfère aussi garder une règle simple: un trunk doit transporter le minimum de VLAN nécessaire, pas "tout ce qui pourrait servir un jour". Cette discipline améliore la lisibilité du réseau, limite les erreurs de propagation et rend le diagnostic beaucoup plus rapide quand quelque chose casse. En pratique, c’est souvent là que se joue la différence entre un réseau simplement opérationnel et un réseau réellement maîtrisé.