QoS dans le réseau d'entreprise : classification du trafic, mise en file d'attente et diagnostic de la gigue et des pertes

Lorsque la téléphonie VoIP craque dans une entreprise, que les vidéoconférences saccadent ou que des sessions terminal/ERP « collent », le réflexe est souvent : « augmenter la bande passante ». En pratique, ce n’est rarement toute la vérité. Ce qui fait la différence, c’est la manière dont le réseau priorise, met en buffer et abandonne le trafic sous charge. C’est précisément là que QoS im Unternehmensnetz intervient : le traitement contrôlé de flux de données distincts afin que les applications sensibles au temps restent stables malgré les goulots d’étranglement.

Cet article explique les éléments centraux de la QoS – Traffic-Classification (classification du trafic), Queueing (mécanismes de mise en file) et la démarche systématique de dépannage pour le Jitter (variation de la latence des paquets) et le Drop/Packet Loss (perte de paquets). L’accent est mis sur l’exploitation et le troubleshooting : où mesurer ? Quelles sont les erreurs typiques ? Et comment déployer la QoS de façon à pouvoir, le cas échéant, revenir en arrière en toute sécurité ?

QoS dans le réseau d’entreprise : pourquoi la QoS reste pertinente malgré une « bande passante suffisante »

La QoS devient particulièrement visible lorsqu’un goulot d’étranglement se forme quelque part. Dans les réseaux d’entreprise, les goulets d’étranglement se situent souvent à des endroits inattendus :

• WAN/Internet-Uplink : souvent le point le plus étroit, avec en plus des mécanismes opérateur et des débits souvent asymétriques.
• VPN/SD-WAN/Firewall : le chiffrement, l’inspection et l’overhead des tunnels modifient le débit et le comportement en burst.
• WLAN : l’airtime est la ressource limitée, pas les « Mbps » ; les retransmissions se comportent comme une perte et génèrent du jitter.
• Server-/Storage-Segmente : les microbursts (pics de charge très courts) peuvent provoquer le débordement des queues des switches.

Important : la QoS n’ajoute pas de bande passante. La QoS définit qui gagne en cas de rareté et quel trafic est freiné de façon contrôlée ou abandonné. Pour que la QoS ne devienne pas un risque, elle doit être mesurable, cohérente et appliquée aux vrais points de contention.

Termes qui comptent en exploitation (DiffServ, DSCP, CoS)

Dans les réseaux modernes, DiffServ (Differentiated Services) est l’approche standard : les paquets sont classifiés en périphérie et marqués ; au cœur, ils sont traités selon ces marquages. Le marquage dans les paquets IP s’appelle DSCP (Differentiated Services Code Point) et se trouve dans l’en-tête IP. Dans l’environnement Ethernet, CoS/802.1p (Class of Service, priorité dans le tag VLAN) peut être pertinent en plus – surtout entre commutateurs et au niveau des ports d’accès/téléphones.

Un objectif pragmatique est : des classes unifiées (p.ex. Voice, Video, Business-critical, Best-Effort, Bulk/Backup) et un mapping cohérent entre DSCP, CoS et les queues internes du switch, du routeur et du pare-feu. C’est précisément ce mapping qui servira de fil rouge lors du debugging.

Traffic-Classification: Wie Verkehr korrekt erkannt wird (und warum das oft scheitert)

Classification du trafic signifie : les paquets sont affectés à une classe en fonction de caractéristiques. Les caractéristiques typiques sont les IP/réseaux, les ports TCP/UDP, les protocoles, les identifiants d’application (pour les Next-Gen-Firewalls), les VLAN ou les groupes de points de terminaison. La réalité : la classification est sujette aux erreurs car elle repose sur des hypothèses.

Stratégies de classification éprouvées dans les réseaux d’entreprise

• Marquage à la périphérie (recommandé) : les terminaux ou les switches d’accès/téléphones marquent DSCP/CoS, le réseau ne fait confiance à ces marquages que dans des segments définis.
• Re-marquage à la frontière de confiance : aux points de transition (p. ex. Access->Distribution, LAN->WAN, LAN->VPN) les marquages sont vérifiés et, si nécessaire, réécrits.
• Classification par politique : si les terminaux ne marquent pas de façon fiable, les routeurs/pare-feu classifient en fonction des ports/réseaux et marquent eux‑mêmes.

Une frontière de confiance est l’endroit à partir duquel vous « croyez » les marquages. Typiquement : les téléphones IP sont dignes de confiance, les PC ne le sont pas. Sans frontière de confiance, tout client peut marquer « Voice » et obtenir une priorité — ce qui n’est pas seulement une douleur opérationnelle, mais aussi un problème de sécurité et d’abus (DoS via des classes de priorité).

Pièges typiques en matière de classification et de marquage

• DSCP se perd : les tunnels, le NAT, certains trajets d’inspection ou des appareils mal configurés remettent DSCP à zéro ou ne le copient pas dans l’en-tête externe (avec IPsec/Gre/SD-WAN).
• WLAN et DSCP : DSCP doit être mappé de manière cohérente sur WMM/802.11e, sinon la voix n’arrive pas en tant que voix sur le WLAN (priorisation airtime).
• Règles « any-any » : dans les firewalls/politiques, les classifications deviennent trop larges, si bien que trop de trafic bascule dans une classe privilégiée et la « dilue ».
• Les règles basées sur les ports sont dépassées : de nombreux services sont dynamiques (SaaS, WebRTC, QUIC/HTTP3). Le simple appariement de ports peut donner des résultats erronés.
• Overhead non pris en compte : l’encapsulation VPN réduit la bande passante utile effective ; la QoS doit s’appliquer sur la véritable sortie (echten egress), pas sur des chiffres théoriques.

Mise en file, ordonnancement et pertes : ce qui se passe réellement au goulot d’étranglement

Dès qu’une interface veut envoyer plus que ce que le lien physique peut supporter, apparaît une file d’attente. Le queueing est la gestion de ces files d’attente, le scheduling est la décision de savoir quelle file peut envoyer ensuite. Quand la file est pleine, des paquets sont supprimés : Tail Drop (classique, à la fin) ou de manière plus intelligente, p. ex. WRED (Random Early Detection), qui supprime sélectivement avant d’être « pleine » afin de stabiliser TCP.

Pour les administrateurs, important : le jitter et les pertes sont souvent des effets secondaires de la mise en tampon. Des tampons trop grands génèrent Bufferbloat : peu de pertes, mais une latence élevée et fluctuante. Des tampons trop petits provoquent des pertes précoces, ce qui peut aller pour TCP (il s’ajuste ensuite), mais impacte fortement le trafic temps réel.

La priorité n’est pas synonyme de « toujours en premier »

De nombreuses plates-formes proposent une « Priority Queue » (souvent en tant que LLQ, Low Latency Queue, ou strict priority). Cela ressemble à la solution pour la voix — et ça l’est, si c’est plafonné. Sans limite, le trafic prioritaire peut évincer le RESTe. De bonnes politiques combinent donc :

• Strict Priority pour la voix (petite part définie)
• Bande passante garantie ou équité pondérée (p. ex. WFQ) pour les applications métier importantes
• Best-Effort pour le trafic Web/bureau normal
• Scavenger/Bulk (faible) pour les sauvegardes, mises à jour, gros téléchargements

Shaping vs. Policing : le malentendu qui produit des pertes

Shaping ralentit le trafic en constituant des tampons et en libérant les paquets de manière prévisible. Policing rejette (ou re-marke) le trafic qui dépasse une limite. En pratique : sur le WAN-Egress, le shaping est souvent une base préférable, car il contrôle le goulot d’étranglement et lisse les pics de burst. Le policing est pertinent si vous devez limiter strictement (p. ex. réseau invité, certains liens partenaires) — mais il génère des pertes qui peuvent se traduire par des symptômes « sporadiquement cassés ».

Si le jitter/les pertes augmentent soudainement après une modification de la QoS, le policing est un suspect principal : le trafic temps réel réagit fortement à la perte, et TCP répond par des retransmissions et des chutes de débit.

Où la QoS doit être appliquée : le goulot d’étranglement compte, pas le schéma d’architecture

La QoS n’agit que là où du scheduling est effectué — typiquement sur l‘Egress (trafic sortant) d’une interface. En ingress, un équipement peut en général peu « ordonner », car les paquets sont déjà arrivés ; il s’agit plutôt de policing/limits de débit ou de la conservation des marquages.

Un ordre d’implémentation éprouvé pour les déploiements QoS :

1. Edge/Access : périmètre de confiance, règles de marquage, mappage Voice-VLAN/WLAN.
2. WAN-Egress : shaping sur le débit montant réel (incl. overhead), définir classes/queues.
3. VPN/SD-WAN : vérifier la conservation des DSCP et le mapping dans l’en-tête externe ; le cas échéant, refaire le marquage par policy.
4. Core/Distribution : n’ajuster que là où des micro-bursts/queue-drops mesurables apparaissent.

Particulièrement dans les environnements avec pare-feu : si le pare-feu est le goulot d’étranglement (CPU, IPS, TLS-Inspection), la QoS peut atténuer les symptômes mais pas résoudre la cause. Il faut alors inclure la planification de capacité et la revue des fonctionnalités.

Débogage du jitter et des pertes : une démarche reproductible

La source d’erreurs la plus fréquente dans les projets QoS n’est pas la théorie, mais l’absence de mesurabilité. Pour un troubleshooting propre, vous avez besoin de trois choses : cas de test clairs, points de mesure et une hypothèse par étape. Sinon, vous touchez aux politiques sans savoir si c’est mieux ou simplement différent.

Étape 1 : préciser les symptômes et vérifier le „temps réel“

« La vidéo saccade » peut signifier du jitter, de la perte, un goulet CPU sur l’endpoint, des retries WLAN ou des problèmes DNS/signaling. Définissez d’abord :

• Quelle application ? (VoIP, Teams/Zoom/WebRTC, VDI, Remote Desktop, ERP-Client)
• Quelle direction ? (upload/download, site A->B, uniquement depuis le WLAN, uniquement via VPN)
• Quand ? (uniquement aux heures de pointe, uniquement pendant les backups, uniquement lors de gros uploads)
• Quelles métriques ? latence, jitter, perte de paquets, MOS/qualité d’appel (si disponible)

Si vous disposez déjà d’un monitoring : recherchez des corrélations entre l’utilisation des interfaces, les queue-drops et les fenêtres horaires affectées. En l’absence de monitoring, déployez au minimum de façon temporaire SNMP/télémétrie en streaming pour les compteurs d’interface et de file d’attente.

Remarque pour le maillage interne : une base de monitoring propre (SNMP v3, gestion de MIB, traitement des traps) paie directement ici ; un article approfondi de votre monitoring-cluster est pertinent en complément.

Étape 2 : localiser le trajet et le goulot d’étranglement (LAN, WAN, Firewall, WLAN)

Localiser signifie : vous avez besoin d’un chemin „Ping/Probe“ et simultanément d’une charge. Sans charge contrôlée, vous verrez difficilement la QoS. Une méthode simple mais efficace consiste à effectuer un test d’upload/download parallèle (p. ex. transfert de gros fichiers) pendant que vous mesurez latence/jitter.

Sur Linux-hôtes, vous pouvez par exemple mesurer latence/jitter via ICMP ; pour des tests basés sur UDP, des outils spécialisés sont pertinents (iperf3). Si vous utilisez des commandes, documentez la cible, la direction et la durée, afin que le résultat reste comparable.

# Basis-Latenz und Jitter-Approximation über 200 Pings (ICMP)
# (ICMP ist nicht identisch zu RTP/UDP, aber ein guter Startpunkt)
ping -c 200 -i 0.2 -s 120 <ziel-ip>

# Parallel: kontrollierte Last erzeugen (TCP) – nur in abgestimmten Wartungsfenstern nutzen
# iperf3-Server auf Zielhost: iperf3 -s
iperf3 -c <ziel-ip> -t 60 -P 4

Interprétation en exploitation : si la latence augmente fortement sous charge sans qu’il y ait de pertes, le bufferbloat est probablement en cause (trop de mise en tampon / shaping mal configuré). Si la perte augmente alors que la latence reste modérée, un overflow de file d’attente ou du policing est plus probable.

Étape 3 : vérifier les marquages end-to-end (DSCP/CoS) – à plusieurs points de mesure

La QoS échoue souvent à un endroit où le DSCP « disparaît ». Vérifiez donc non seulement à l’émetteur, mais aussi avant et après les transitions critiques : contrôleur WLAN, switch d’accès, pare-feu, tunnel VPN, routeur WAN.

Avec tcpdump, vous pouvez rendre visibles les valeurs DSCP dans l’en-tête IP (le DSCP se trouve dans le champ ToS/Traffic-Class). Ce n’est pas une analyse conviviale, mais très utile pour le débogage.

# DSCP/ToS bei IPv4-Paketen beobachten (Ausgabe zeigt u. a. "tos 0x..")
# Filter beispielhaft für UDP (z. B. RTP/Media), ggf. anpassen
sudo tcpdump -ni <iface> -vvv udp and host <peer-ip>

# Für IPv6: auch hier zeigt tcpdump die Traffic Class
sudo tcpdump -ni <iface> -vvv ip6 and host <peer-ip>

Si vous constatez ici que le DSCP est correct au niveau du client, mais plus à la sortie WAN, le coupable est le plus souvent un remarquage, une politique ou un problème d’encapsulation de tunnel. Pour les tunnels IPsec, il faut aussi déterminer si le DSCP est copié dans l’en-tête externe et comment le fournisseur le traite.

Étape 4 : Relever les queue-drops, shapers et policers sur le pare-feu/edge

Dans les catégories de pare-feu, la QoS est particulièrement délicate car plusieurs fonctions interagissent : inspection stateful, NAT, VPN, IDS/IPS, TLS-Inspection, éventuellement sélection de chemin SD-WAN. Vous avez donc besoin de compteurs au niveau QoS (queue/drop), pas seulement des erreurs d’interface.

Procédure (indépendante du fabricant) :

• Compteurs d’interface : utilisation, drops/discards, erreurs.
• Compteurs QoS : par classe : enqueued, dequeued, dropped, shaped, policed.
• Compteurs système : CPU, tampon de paquets, utilisation Session/Conntrack.

Si les compteurs QoS montrent des drops, mais que les compteurs d’interface sont « propres », vous êtes probablement en train de jeter des paquets dans une étape de politique/policer au-dessus de l’interface. Inversement : des drops d’interface sans drops QoS indiquent un débordement de queue matériel, des microbursts ou une mauvaise affectation des files.

Checklist pratique : restreindre rapidement les causes de jitter/perte

La checklist suivante est construite pour vous donner, en 30–60 minutes, une orientation fiable. Tous les points ne sont pas toujours nécessaires, mais l’ordre fait généralement gagner du temps.

A. Vérifier d’abord : couche physique, duplex, erreurs, MTU

• Erreurs CRC/trame ou retransmissions ? (peut ressembler à de la perte)
• Inadéquation vitesse/duplex (aujourd’hui plus rare, mais pertinent pour convertisseurs de média/équipements anciens)
• MTU/fragmentation sur VPN : la fragmentation augmente le jitter et peut déclencher des pertes.

Pour les questions de MTU, un test « Path MTU » est utile. Exemple pour IPv4 (bit DF activé) :

# MTU testen: -M do setzt DF (Don't Fragment), -s ist Payload
# 1472 + 28 Byte IP/ICMP-Header = 1500
ping -M do -s 1472 -c 5 <ziel-ip>

# Wenn das scheitert, schrittweise reduzieren
ping -M do -s 1400 -c 5 <ziel-ip>

B. Puis vérifier : où est réellement le goulot ?

• Utilisation uplink et pics : s’agit-il de microbursts ou d’une saturation continue ?
• Débit firewall/VPN : la plateforme atteint-elle sa limite sous charge fonctionnelle ?
• WLAN : taux de retry élevé/interférences ? Utilisation de l’air élevée ?

C. Spécifique QoS : classification et frontière de confiance

• Le endpoint marque-t-il réellement (DSCP/CoS) ? Ou seule la documentation le prétend ?
• Où le DSCP est-il réécrit ou mis à 0 ?
• Quels réseaux/ports se retrouvent involontairement en « Priority » ?
• La priorité est-elle plafonnée (limite LLQ) ?

D. Queueing/Bufferbloat : latence sous charge comme indicateur

• La latence augmente fortement, la perte reste faible : tampons trop grands, vérifier shaping/queueing.
• La perte augmente tôt, la latence reste modérée : policing ou file trop petite, vérifier l’affectation des classes.

Mise en œuvre : un design QoS maintenable en exploitation

Un design QoS maintenable n’est pas celui avec le plus de classes, mais celui avec l’intention la plus claire. Pour de nombreux réseaux d’entreprise, 4–6 classes suffisent. L’essentiel est que chaque classe ait un propriétaire (équipe responsable), une définition et une mesurabilité.

Proposition pour un modèle de classes pragmatique (indépendant du fabricant)

• Voice (temps réel) : RTP/VoIP, strict priority, petit budget fixe, DSCP EF (typique).
• Vidéo/Interactif : conférences, partage d’écran ; large bande passante, mais pas de priorité stricte, DSCP selon les standards.
• Critique pour l’entreprise: VDI/Terminal, systèmes transactionnels; bande passante minimale garantie.
• Best-Effort: Web standard, Office, SaaS sans besoin temps réel.
• Bulk/Scavenger: sauvegardes, mises à jour, gros transferts; priorité la plus basse, éventuellement limitée.

Important: Définissez comment vous traitez les exceptions. Exemple: un système proche du processus peut être „critique“, mais s’il fonctionne via HTTPS vers un SaaS, il est difficile à isoler sans détection d’applications. Il vous faudra alors envisager des plages d’IP de destination, l’intégration d’un proxy ou des ID d’application SD‑WAN – ou accepter qu’il reste Best-Effort et, à la place, réduire les goulots d’étranglement.

Risques et effets secondaires: ce qui peut compromettre la QoS

• Limite de shaping incorrecte: si vous appliquez un shaping supérieur au débit réel du fournisseur, la file se formera chez le fournisseur (vous perdez le contrôle, le jitter augmente).
• Classe de priorité trop généreuse: la vidéo ou de gros flux en strict priority écrasent tout le reste.
• Asymétrie: seul l’upload est traité, le download reste incontrôlé (erreur fréquente en pratique). La QoS en téléchargement est plus difficile, mais vous pouvez par ex. planifier proprement le policing entrant et l’ingénierie du trafic sur le site ou intervenir sur le routeur WAN avec des mécanismes appropriés.
• Chiffrement/QUIC: la classification par ports devient moins fiable; les ID d’application ou le marquage côté endpoint prennent de l’importance.

Rollback- und Rückfallstrategie: QoS ändern, ohne den Betrieb zu riskieren

Les modifications de QoS ont potentiellement un „rayon d’impact“ important: une policy erronée s’applique immédiatement et à grande échelle. Prévoyez donc dès le départ une stratégie de repli.

Procédure de changement éprouvée

1. Baseline: enregistrez les mesures avant intervention (latence/jitter/perte, compteurs de file, pics d’interface) pour les périodes de charge typiques.
2. Déploiement progressif: d’abord un site pilote ou un lien WAN, puis étendre le déploiement.
3. Feature flags: la QoS-policy en tant qu’unité clairement nommée et activable/désactivable (p. ex. Policy-Map/Rule-Set). Pas „dispersée“ en vingt endroits.
4. Kill-switch: une étape définie permettant de revenir en quelques minutes au „Best-Effort“, sans impacter les autres fonctions.
5. Surveillance et alerting: seuils pour les queue-drops, latence sous charge, métriques voix. Configurez l’alerte pour qu’elle accompagne la modification et non pas des jours plus tard.

Conseil pratique: documentez non seulement „la nouvelle policy“, mais aussi quelles classes ne sont délibérément pas priorisées. Cela évite des discussions ultérieures de „scope creep“ qui alourdiraient la QoS.

Interaction avec la sécurité: ancrer proprement la QoS dans les Security-Policies

Dans le monde des pare-feu, les règles QoS sont souvent couplées aux security policies. Cela a du sens, car vous y définissez de toute façon zones, réseaux et applications. Deux risques typiques apparaissent cependant:

• Ordre des policies: une règle Allow générale „attrape“ le trafic avant qu’une attribution QoS spécifique n’intervienne.
• Chemins d’inspection: IPS/TLS-Inspection peut modifier les performances; la QoS n’aidera que si la plateforme dispose de marges suffisantes.

Pour le troubleshooting, il est utile d’examiner QoS et NAT/conntrack conjointement: si NAT/conntrack est à sa limite, vous verrez des drops qui ressemblent à des effets QoS. Un article de fond pertinent porterait sur la vérification systématique des tables NAT/PAT et des comportements stateful.

Conclusion: QoS ist weniger „Policy“, mehr Betriebssystem für Engpässe

QoS dans le réseau d’entreprise fonctionne de manière fiable lorsque trois éléments coïncident : classification précise (avec frontières de confiance), mise en file d’attente / shaping contrôlés au niveau du véritable goulet d’étranglement et mesurabilité via des compteurs et des tests reproductibles. Le jitter et les pertes ne sont pas des effets mystiques, mais le plus souvent des conséquences explicables de la mise en tampon, du policing ou de marquages perdus.

Si vous déployez ou affinez la QoS, planifiez-la comme une modification d’exploitation : avec une baseline, un pilote, des kill-switches clairs et une liste de contrôle que vous pourrez ressortir du tiroir en cas d’incident. Ainsi, la QoS cesse d’être un « sujet boîte noire » pour devenir un outil qui stabilise les services temps réel sans surprendre le RESTe du trafic.

La classification du trafic est également importante pour ce sujet. L’article replace ces aspects de manière compréhensible et montre ce qui importe dans la pratique.