QoS réseau qui fonctionne vraiment (sans deviner les priorités)

Le QoS n’est pas une « priorité », c’est un contrat

Le véritable QoS est un contrat entre des flux concurrents et un goulet d’étranglement. Il dit : « Quand il y a contention, ces classes obtiennent au moins X, au plus Y, et les flux sensibles à la latence ne se noient pas derrière les transferts massifs. » C’est tout. Le reste, c’est du marketing.

La plupart des échecs de QoS proviennent d’une des trois erreurs suivantes :

• Vous avez façonné au mauvais endroit. Vous ne pouvez pas résoudre une congestion au cœur en « priorisant » des paquets à la périphérie si la vraie file d’attente se trouve dans une box d’un fournisseur en amont que vous ne contrôlez pas.
• Vous avez deviné les priorités. « Le stockage est important » n’est pas une définition de classe. C’est un sentiment. Les sentiments ne survivent pas aux micro‑pics.
• Vous avez fait confiance à des marquages que vous ne devriez pas. Si des points d’extrémité non fiables peuvent marquer EF, ils le feront. Parfois par accident. Parfois « parce que le fournisseur nous l’a dit ».

Un bon QoS est ennuyeux : c’est de la mesure plus du contrôle de débit plus de la justice. Ce n’est pas un arc‑en‑ciel de valeurs DSCP collées sur tout ce qui a déjà perdu un paquet.

Une idée paraphrasée d’une personne qui a construit beaucoup de systèmes fiables : l’espoir n’est pas une stratégie. — attribuée à Gordon R. Dickson, souvent répétée en ingénierie.

Blague #1 : Les plans QoS basés sur « ce qui est important » ressemblent aux organigrammes—beaux jusqu’à ce que vous essayiez de faire transiter le trafic à travers eux.

Faits intéressants et courte histoire (pour arrêter de la répéter)

Un peu de contexte aide, car la mise en réseau réinvente sans cesse les mêmes erreurs avec de nouveaux acronymes.

1. IntServ/RSVP est arrivé en premier, et il a surtout perdu. La vision des années 1990 était des réservations par flux sur tout le réseau. Cela n’a pas évolué opérationnellement, et DiffServ a gagné en étant plus simple et « assez bon ».
2. DiffServ a été conçu pour des agrégats. DSCP n’était pas destiné à ce que chaque appli se déclare importante ; il visait à ce que des domaines réseau classifient et traitent le trafic en lots.
3. Le bufferbloat a été largement reconnu à la fin des années 2000. Les tampons profonds dans le matériel grand public donnaient de bonnes performances en débit dans les benchs pendant que la latence explosait en usage réel.
4. RED a essayé tôt d’éviter l’accumulation de files. Random Early Detection précède la popularité des AQM modernes ; il était puissant mais délicat, d’où sa rareté.
5. FQ‑CoDel a été un tournant pratique. Il a marié équité (fileting par flux) et AQM (CoDel) sans nécessiter de réglages magiques par lien.
6. Le réétiquetage DSCP est courant sur le terrain. De nombreux FAI blanchissent ou remappent DSCP aux points de peering ; les hypothèses QoS meurent souvent au premier saut externe.
7. Ethernet a ses propres bits de priorité. 802.1p PCP peut fonctionner à l’intérieur d’un LAN, mais ce n’est pas la même chose que DSCP IP, et les erreurs de mappage sont une cause classique d’incident.
8. Les files « prioritaires » peuvent affamer les autres. La priorité stricte a toujours été une arme lourde ; elle n’est sûre qu’avec du policing ou des plafonds.
9. Le QoS Wi‑Fi n’est pas le QoS filaire. La priorisation 802.11e/WMM aide, mais la contention d’airtime, l’adaptation de débit et les retransmissions dominent souvent l’expérience utilisateur.

Un modèle mental qui survit en production

1) Trouvez le goulet, puis contrôlez la file à ce goulet

Le QoS n’a de sens que là où les paquets font la file. C’est généralement au lien le plus étroit (liaison montante vers l’ISP, circuit WAN, tunnel inter‑AZ, tête VPN, airtime Wi‑Fi). Si vous ne contrôlez pas la file à cet endroit, vous négociez avec la physique.

Façonner en dessous du débit réel du lien est l’astuce clé. Si votre WAN est de 1 Gbps mais que le policer du fournisseur intervient à 940 Mbps, façonnez à 900–920 Mbps pour que votre file se constitue (où vous pouvez planifier équitablement) plutôt que la leur (où vous ne le pouvez pas).

2) Séparez « sensible à la latence » et « bulk », mais n’inventez pas dix classes

La plupart des organisations ont besoin de trois à cinq classes, pas de douze :

• Temps réel interactif : voix, média de conférence vidéo, peut‑être certaines télémétries de type jeu. Budget de gigue faible.
• Interactif : SSH, RDP, petites requêtes API, DNS. La faible latence importe plus que la bande passante.
• Par défaut : la plupart du trafic web et des services.
• Bulk : sauvegardes, réplication, pulls d’artefacts, grosses exportations.
• Scavenger (optionnel) : choses que vous voulez terminer un jour mais jamais au détriment des humains.

Si vous ne pouvez pas exprimer une classe par une phrase de politique (« au moins X, au plus Y, objectif de latence Z »), ne la créez pas. Vous ne dessinez pas un plan de métro. Vous empêchez des bagarres à une seule porte.

3) Frontières de confiance : les endpoints mentent, même sans le vouloir

Le marquage peut être fait aux endpoints, mais l’application doit se faire à une frontière que vous contrôlez : switch ToR, vSwitch de l’hôte, routeur edge, passerelle WAN. Le réseau doit traiter les marquages d’endpoint comme des indices sauf si l’endpoint est géré et audité.

4) L’équité n’est pas optionnelle

Un flux éléphant peut gâcher votre journée sans utiliser beaucoup de bande passante en moyenne. Les micro‑pics et l’accumulation de files créent des sauts de latence qui ressemblent à une « lenteur aléatoire ». Le fair queueing (FQ) isole les flux pour éviter qu’un transfert bulk ne s’installe devant tout le monde comme un camion bloquant un pont à une voie.

5) Le QoS est une boucle de rétroaction : mesurer, appliquer, vérifier, répéter

Si vous ne regardez pas les drops, les marques ECN, le délai de file et l’utilisation des classes, vous pratiquez la danse interprétative avec les en‑têtes de paquets.

Roue de diagnostic rapide

Voici la version « le pager hurle ». L’objectif est d’identifier si vous avez un problème de capacité, un problème de file, un problème de classification ou un problème de chemin en moins de 15 minutes.

Première étape : confirmer le symptôme et localiser le périmètre

1. Est‑ce la latence, la perte ou le débit ? Demandez une métrique concrète : RTT p95, % de perte de paquets, goodput Mbps. « Lent » n’est pas une métrique.
2. Est‑ce un site, un VLAN, un VPN, un ISP, un hôte ? Réduisez vite le rayon d’impact.
3. Est‑ce lié à la charge ? Si cela corrèle avec les fenêtres de sauvegarde ou les déploiements, vous avez déjà une classe suspecte.

Deuxième étape : trouver le lien goulet et vérifier si la file est locale ou en amont

1. Vérifiez l’utilisation et les erreurs d’interface sur l’egress suspecté.
2. Vérifiez les statistiques de discipline de file (drops/overlimits) là où vous façonnez.
3. Comparez le débit mesuré au débit contracté. Si vous atteignez un policer du fournisseur, vous verrez des pertes sans drops locaux à moins de façonner en dessous.

Troisième étape : valider la classification et les frontières de confiance

1. Capturez un petit échantillon et confirmez que DSCP/PCP sont bien ceux attendus.
2. Vérifiez que les équipements sur le chemin conservent les marquages. Un switch « serviable » peut tout réécrire en best‑effort.
3. Confirmez que votre ordonnanceur n’affame pas en priorité stricte le trafic par défaut.

Quatrième étape : décidez quel levier tirer

• Si la file est en amont : façonnez plus bas pour que votre file se constitue localement.
• Si la file est locale et que la latence spike : activez FQ + AQM (fq_codel/cake) sur l’egress affecté.
• Si le mauvais trafic est dans la mauvaise classe : corrigez la classification à la frontière (iptables/nftables, politique de switch, ou politique CNI kube).
• Si vous manquez simplement de capacité : le QoS peut trier, pas créer de la bande passante. Achetez/augmentez ou réduisez la charge.

Où le QoS fonctionne réellement (et où c’est du théâtre)

Le seul endroit où l’ordonnancement compte : la file egress

Le QoS fonctionne mieux en egress parce que c’est là que l’appareil contrôle le timing d’émission. Le QoS ingress concerne surtout le policing (drop) ou le remarking. Vous ne pouvez pas « retarder » des paquets entrants déjà arrivés ; vous ne pouvez que les dropper ou compter sur l’amont pour ralentir.

Meilleurs endroits pour appliquer

• Routeur edge Internet/WAN : votre dernière chance avant le fournisseur. Façonnez ici. Mettez la « file intelligente » ici.
• Passerelle VPN : le chiffrement cache les ports L4 ; la classification doit se faire avant encapsulation (ou basée sur les en‑têtes internes si pris en charge).
• Hyperviseur/hôte : l’équité par VM et par pod empêche un locataire de devenir l’aspirateur du bureau.
• Contrôleur/AP Wi‑Fi : l’équité d’airtime et le mapping WMM peuvent importer plus que la pureté DSCP.

Endroits où les gens essaient, et où ça foire habituellement

• Switches cœur quand le goulet est un circuit WAN. Vous priorisez dans un trou noir. La file est ailleurs.
• Middleboxes aléatoires avec un comportement tampon inconnu. Si vous ne pouvez pas observer le délai de file, vous réglez à l’aveugle.
• Options « priorité » côté application sans enforcement réseau. Félicitations, vous avez posé une étiquette.

Blague #2 : Les files en priorité stricte sont comme une pizza gratuite à une revue d’incident—quelqu’un en prend toujours trop et le reste de la salle devient amer.

Classification sans deviner : marquer moins, faire confiance moins

Commencez par « par défaut » et « bulk », puis gagnez le droit au « temps réel »

La stratégie QoS la plus sûre n’est pas d’anticiper quelles applis sont « importantes ». C’est de séparer le trafic par comportement et potentiel de nuisance :

• Bulk est identifiable : transferts longue durée, haut BDP, sauvegardes, réplication, pulls d’images de conteneur, sync de stockage objet. Peut être retardé.
• Interactif est petit et rafaleux : DNS, SSH, appels API. Il a besoin d’une faible latence de file, pas d’une énorme bande passante.
• Temps réel est sensible à la gigue : flux média voix/vidéo. Il a besoin à la fois d’un faible délai et d’une perte bornée.

Remarquez ce qui manque : « trafic PDG ». Ne faites pas ça.

Stratégie DSCP : choisissez un petit vocabulaire

En pratique, un petit ensemble DSCP est robuste entre équipements :

• CS0 pour le défaut (best effort)
• AF21/AF31 pour l’interactif (choisissez‑en une et tenez‑vous‑y)
• EF pour le média temps réel (à utiliser parcimonieusement, policer)
• CS1 pour scavenger/bulk‑faible (parfois appelé « moins que best effort »)

Si votre équipe réseau a déjà un plan DSCP, ne faites pas de freestyle. Alignez‑vous et documentez la frontière de confiance : où les marques sont acceptées, où elles sont réécrites et où elles sont ignorées.

Schémas de frontière de confiance qui tiennent dans le temps

• LAN d’entreprise : faites confiance aux DSCP des endpoints voix/vidéo gérés ; réétiquetez tout le reste aux accès/ToR.
• Data center : marquez au bord des workloads (host/vSwitch) basé sur l’identité cgroup/pod ; ne faites pas confiance aux VMs invitées.
• Cloud hybride : supposez que DSCP sera blanchi à une certaine frontière ; faites respecter l’équité avec shaping + FQ quoi qu’il arrive.

Policing : le prix de la priorité stricte

Si vous avez une file en priorité stricte (pour la voix, par exemple), vous devez la policer ou la plafonner. Sinon, un flux bulk mal marqué peut tout affamer. C’est ainsi que naissent les incidents « le QoS a empiré les choses ».

Shaping et files d’attente : choisissez le bon outil

Shaping vs policing

• Shaping retarde les paquets pour respecter un débit. Il réduit les pertes, améliore la prévisibilité et fait bien se comporter TCP. Il nécessite du buffer et ajoute un peu de latence, mais une latence contrôlée vaut mieux qu’une latence aléatoire.
• Policing droppe les paquets excédant un débit. C’est simple et dur. Utilisez‑le pour faire respecter des limites (surtout sur les classes prioritaires), pas pour « gérer » le trafic normal.

Disciplines de file qui comptent sur Linux

Sur Linux, votre boîte à outils par défaut ressemble à ceci :

• fq_codel : excellent choix par défaut pour contrôler la latence sur des liens typiques ; idéal pour « rendre le réseau normal ».
• cake : excellent tout‑en‑un pour shaping + équité + gestion diffserv ; très populaire aux bordures. Pas toujours disponible dans les kernels d’entreprise, mais quand il l’est, c’est un cadeau.
• HTB : shaping classful avec débits/ceilings explicites ; stable opérationnellement si vous gardez le nombre de classes raisonnable.
• TBF : simple token bucket ; suffisant pour du shaping mono‑débit mais pas pour l’équité multi‑classe.

Ce que je recommande pour la plupart des bordures de production

• Si vous pouvez utiliser cake : façonnez à ~90–95% du débit réel et utilisez diffserv4 ou diffserv8 selon votre modèle de classes.
• Si vous ne pouvez pas : utilisez HTB pour shaping + garanties de classe, et placez fq_codel (ou fq) sous chaque classe pour l’équité.

Pourquoi « priorité » n’est pas le défaut approprié

La priorité stricte convient pour une petite classe temps réel policée. Ce n’est pas un bouton « accélère ceci ». Si vous mettez tout en haute priorité, vous avez réinventé le best‑effort, mais avec plus d’étapes et des modes de défaillance pires.

Note spécifique stockage : la réplication est du bulk, mais c’est aussi un risque d’alerte

Le trafic de réplication est typiquement du bulk et tolère la latence, mais il peut créer des incidents secondaires quand il sature un lien et provoque des timeouts ailleurs. Traitez‑le comme du bulk avec un débit minimal raisonnable et un plafond maximal. Vous voulez qu’il soit fiable, pas dominant.

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

Voici les tâches que vous exécutez réellement pendant la conception, le déploiement et le débogage. Chacune inclut ce que signifie la sortie et la décision à en tirer.

Task 1: Confirm link speed/duplex and spot autonegotiation pain

cr0x@server:~$ sudo ethtool eth0
Settings for eth0:
	Supported ports: [ TP ]
	Supported link modes:   1000baseT/Full
	                        10000baseT/Full
	Supported pause frame use: Symmetric
	Supports auto-negotiation: Yes
	Advertised link modes:  10000baseT/Full
	Advertised auto-negotiation: Yes
	Speed: 10000Mb/s
	Duplex: Full
	Auto-negotiation: on
	Link detected: yes

Signification : Si vous voyez 100Mb/s ou Half duplex, votre « problème QoS » est en réalité un problème physique/ de négociation de lien.

Décision : Corrigez la vitesse/duplex d’abord. Le QoS ne peut pas sauver un lien half‑duplex des collisions et des déchirures.

Task 2: Check interface errors and drops (driver/NIC/path issues)

cr0x@server:~$ ip -s link show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff
    RX:  bytes packets errors dropped  missed   mcast
      987654321  123456      0     234       0    1234
    TX:  bytes packets errors dropped carrier collsns
      876543210  234567      0      12       0       0

Signification : Les drops RX peuvent indiquer une congestion en amont ou l’incapacité de l’hôte à traiter les paquets. Les drops TX indiquent souvent des drops de qdisc ou une pression sur le ring buffer.

Décision : Si des erreurs/carrier existent, corrigez le matériel/driver. Si les drops corrèlent avec la charge, passez aux stats de file et au shaping.

Task 3: Identify the current qdisc and whether you already have FQ/AQM

cr0x@server:~$ tc -s qdisc show dev eth0
qdisc mq 0: root
qdisc fq_codel 8012: parent :12 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn
 Sent 123456789 bytes 234567 pkt (dropped 123, overlimits 0 requeues 10)
 backlog 0b 0p requeues 10
  maxpacket 1514 drop_overlimit 123 new_flow_count 456 ecn_mark 789

Signification : Vous avez fq_codel actif. Les drops indiquent la pression de file ; les marques ECN montrent que l’AQM signale la congestion sans drop (si les endpoints le supportent).

Décision : Si vous voyez pfifo_fast ou pas d’AQM et que vous avez des pics de latence, activer fq_codel/cake sur le goulet est un levier à fort impact.

Task 4: Measure queueing delay symptoms quickly with ping under load

cr0x@server:~$ ping -c 20 -i 0.2 10.0.0.1
PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data.
64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=0.42 ms
64 bytes from 10.0.0.1: icmp_seq=2 ttl=64 time=0.39 ms
64 bytes from 10.0.0.1: icmp_seq=3 ttl=64 time=35.12 ms
64 bytes from 10.0.0.1: icmp_seq=4 ttl=64 time=42.77 ms

--- 10.0.0.1 ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 3805ms
rtt min/avg/max/mdev = 0.36/6.88/42.77/13.10 ms

Signification : Le RTT max monte à des dizaines de ms alors que le min reste sous‑ms : accumulation de file (bufferbloat) classique pendant la contention.

Décision : Ajoutez shaping + AQM au goulet egress. Ne « priorisez » pas au hasard ; réglez la file.

Task 5: Check route/path changes (because not all latency is congestion)

cr0x@server:~$ ip route get 8.8.8.8
8.8.8.8 via 192.0.2.1 dev eth0 src 192.0.2.10 uid 0
    cache

Signification : Confirme quelle passerelle et interface sont en jeu.

Décision : Si le trafic « lent » utilise une interface/tunnel différent de ce que vous supposiez, votre politique QoS est peut‑être appliquée sur le mauvais egress.

Task 6: Verify DSCP markings in real traffic (don’t trust configs)

cr0x@server:~$ sudo tcpdump -i eth0 -vv -c 5 'udp and (port 5060 or portrange 16384-32767)'
tcpdump: listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:00:01.123456 IP (tos 0xb8, ttl 64, id 1234, offset 0, flags [DF], proto UDP (17), length 214) 192.0.2.50.40000 > 192.0.2.60.20000: UDP, length 172
12:00:01.123789 IP (tos 0x00, ttl 64, id 1235, offset 0, flags [DF], proto UDP (17), length 214) 192.0.2.51.40002 > 192.0.2.60.20002: UDP, length 172

Signification : Un flux est EF (tos 0xb8), un autre est CS0 (tos 0x00). Vos endpoints sont incohérents ou la politique réécrit.

Décision : Décidez d’appliquer le marquage à la frontière (recommandé) et si vous faites confiance aux marquages endpoints pour ces sources.

Task 7: Check whether the host is rewriting DSCP (or not)

cr0x@server:~$ sysctl net.ipv4.tcp_ecn net.ipv4.conf.all.rp_filter
net.ipv4.tcp_ecn = 2
net.ipv4.conf.all.rp_filter = 1

Signification : ECN est activé (2 = activer et essayer), rp_filter est strict (1). rp_filter strict peut casser le routage asymétrique et causer des drops « aléatoires ».

Décision : Si vous faites du policy‑based routing, du multi‑homing ou certains tunnels, envisagez d’assouplir rp_filter et validez le comportement DSCP de bout en bout.

Task 8: Inspect iptables mangle rules for marking (legacy but common)

cr0x@server:~$ sudo iptables -t mangle -S
-P PREROUTING ACCEPT
-P OUTPUT ACCEPT
-A OUTPUT -p udp --dport 53 -j DSCP --set-dscp-class AF21
-A OUTPUT -p tcp --dport 22 -j DSCP --set-dscp-class AF21
-A OUTPUT -p tcp --dport 873 -j DSCP --set-dscp-class CS1

Signification : DNS/SSH marqués interactive ; rsync marqué scavenger. C’est basé sur le comportement et sensé.

Décision : Gardez‑le petit. Évitez des listes de ports gigantesques. Si les applis changent de ports (bonjour, QUIC), vous perdrez la classification de toute façon.

Task 9: Inspect nftables for marking (the modern default)

cr0x@server:~$ sudo nft list ruleset
table inet mangle {
  chain output {
    type route hook output priority mangle; policy accept;
    udp dport 53 ip dscp set af21
    tcp dport { 22, 443 } ip dscp set af21
    tcp dport 2049 ip dscp set cs1
  }
}

Signification : La chaîne output marque le trafic par port ; NFS (2049) est placé en CS1 ici (questionnable sauf si vous le voulez vraiment scavenger).

Décision : Remettez en question les hypothèses. Le trafic de stockage peut nécessiter un partage minimum, pas le statut scavenger, selon vos modes de défaillance.

Task 10: Validate shaping is actually active and at the right rate

cr0x@server:~$ sudo tc qdisc show dev eth0
qdisc htb 1: root refcnt 2 r2q 10 default 30 direct_packets_stat 0 direct_qlen 1000
qdisc fq_codel 10: parent 1:10 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn
qdisc fq_codel 20: parent 1:20 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn
qdisc fq_codel 30: parent 1:30 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn

Signification : Racine HTB avec trois classes, fq_codel dans chacune. C’est une base solide.

Décision : Vérifiez maintenant les débits/ceilings des classes et que le trafic par défaut va bien dans la classe prévue.

Task 11: Read HTB class stats to see who is winning and who is starving

cr0x@server:~$ sudo tc -s class show dev eth0
class htb 1:10 root rate 50Mbit ceil 200Mbit burst 15Kb cburst 15Kb
 Sent 98765432 bytes 123456 pkt (dropped 0, overlimits 0 requeues 0)
class htb 1:20 root rate 200Mbit ceil 900Mbit burst 15Kb cburst 15Kb
 Sent 876543210 bytes 234567 pkt (dropped 0, overlimits 0 requeues 0)
class htb 1:30 root rate 50Mbit ceil 900Mbit burst 15Kb cburst 15Kb
 Sent 4567890123 bytes 3456789 pkt (dropped 4321, overlimits 9876 requeues 123)

Signification : La classe 1:30 (probablement bulk/par défaut selon le mapping) atteint des overlimits et des drops, indiquant qu’elle est contrainte et fait la file. Les autres vont bien.

Décision : Si 1:30 est bulk, c’est bien. Si c’est en réalité le trafic par défaut utilisateur, vous avez mal classé et vous punissez la mauvaise chose.

Task 12: Check conntrack and see if a “small number of flows” dominate

cr0x@server:~$ sudo conntrack -S
cpu=0 found=123456 invalid=12 ignore=0 insert=34567 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=123

Signification : Pas une métrique QoS directe, mais des pics invalid/insert_failed peuvent indiquer une surcharge hôte provoquant des drops qui ressemblent à des « problèmes QoS réseau ».

Décision : Si conntrack est stressé, corrigez cela (tuning, offload, capacité) avant de blâmer les disciplines de file.

Task 13: Confirm NIC queueing and multiqueue behavior

cr0x@server:~$ sudo ethtool -l eth0
Channel parameters for eth0:
Pre-set maximums:
RX:		0
TX:		0
Other:		0
Combined:	8
Current hardware settings:
RX:		0
TX:		0
Other:		0
Combined:	8

Signification : 8 canaux combinés suggèrent du multi‑queue ; la configuration du qdisc doit tenir compte de mq. Certains setups de shaping n’affectent qu’une file à moins d’être appliqués correctement.

Décision : Si vous façonnez, assurez‑vous de le faire à la racine (ou utilisez une stratégie IFB/ingress si nécessaire). Un shaping mal appliqué est un échec silencieux.

Task 14: Find the “real” egress in a host with VLANs/bonds

cr0x@server:~$ ip -d link show bond0
5: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 52:54:00:aa:bb:cc brd ff:ff:ff:ff:ff:ff
    bond mode 802.3ad miimon 100 updelay 0 downdelay 0

Signification : Interface bondée. Si vous attachez le qdisc au mauvais niveau (bond vs sous‑interface VLAN vs physique), les résultats varient.

Décision : Appliquez le QoS à l’interface qui fait réellement la file. Souvent c’est le bond ou le membre physique selon le driver et les offloads.

Task 15: Confirm whether GRO/GSO/TSO offloads are masking queue behavior

cr0x@server:~$ sudo ethtool -k eth0 | egrep 'gro|gso|tso'
tcp-segmentation-offload: on
generic-segmentation-offload: on
generic-receive-offload: on

Signification : Les offloads peuvent réduire la CPU et modifier la découpe des paquets ; le shaping et la classification basés sur les tailles de paquets peuvent se comporter différemment.

Décision : Laissez généralement les offloads activés pour les serveurs, mais si vous déboguez un comportement qdisc étrange, testez en les basculant (prudemment) dans une fenêtre de maintenance.

Task 16: Prove that a device in the path is bleaching DSCP

cr0x@server:~$ sudo tcpdump -i eth0 -vv -c 3 'icmp and host 198.51.100.10'
tcpdump: listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:05:00.000001 IP (tos 0x88, ttl 64, id 7000, offset 0, flags [DF], proto ICMP (1), length 84) 192.0.2.10 > 198.51.100.10: ICMP echo request, id 1, seq 1, length 64
12:05:00.010001 IP (tos 0x00, ttl 51, id 8000, offset 0, flags [none], proto ICMP (1), length 84) 198.51.100.10 > 192.0.2.10: ICMP echo reply, id 1, seq 1, length 64

Signification : Vous avez envoyé avec tos 0x88 (combinaison DSCP/ECN) ; la réponse est CS0. Pas définitif seul, mais si vous capturez aussi côté distant et voyez la réinitialisation DSCP, quelque chose réécrit.

Décision : Ne comptez plus sur DSCP au‑delà de cette frontière. Utilisez shaping/équité qui ne dépendent pas de marquages préservés.

Trois mini‑histoires d’entreprise issues des tranchées du QoS

Mini‑histoire 1 : L’incident causé par une mauvaise hypothèse

Une fintech de taille moyenne avait un « VLAN voix » et une croyance de longue date : les paquets voix sont sacrés. Ils ont déployé un nouveau client softphone et un nouveau modèle de switch dans le même trimestre. Le client marquait les médias en EF, signalant « expedited forwarding ». Les switches étaient configurés pour faire confiance au DSCP sur les ports d’accès parce que c’est ce que faisaient les vieux téléphones.

Puis une équipe non liée a déployé un agent de télémétrie haut débit qui, par défaut fournisseur, marquait aussi ses flux UDP en EF. Personne n’a remarqué car tout fonctionnait à faible charge, et les dashboards de la plateforme de télémétrie semblaient « en temps réel ».

Un lundi matin, un backlog de télémétrie a provoqué un trafic soutenu marqué EF. Les switches de distribution avaient des files en priorité stricte pour EF sans policing—parce que la voix « n’utilise jamais tant de bande ». Cette hypothèse était vraie pour les postes fixes. Elle était fausse pour des logiciels sur des hôtes généraux.

Le résultat a été chirurgical : les appels vocaux semblaient corrects, la télémétrie passait, et tout le reste dégradait. Le DNS ralentissait. Les appels API faisaient des timeouts. Le support a accusé le pare‑feu, l’équipe pare‑feu a accusé l’ISP, et l’ISP a demandé des captures que personne n’a su interpréter sous pression.

La correction a été ennuyeuse et immédiate : ne plus faire confiance au DSCP sur les ports d’accès généraux, ne remark EF que pour les endpoints voix authentifiés, et policer EF à un pourcentage max par port. La voix est restée propre, la télémétrie a continué de fonctionner, et le trafic par défaut a cessé d’étouffer.

Mini‑histoire 2 : L’optimisation qui a mal tourné

Une entreprise de retail avait un WAN privé entre plusieurs sites et une fenêtre de sauvegarde nocturne. Les sauvegardes bouffaient la bande, alors l’équipe réseau a créé une classe bulk et l’a fortement plafonnée. Bonne intention : protéger le trafic métier le jour. Ils l’ont déployée partout, y compris sur les uplinks du data center.

Les sauvegardes ont ralenti, comme prévu. Puis quelques jours plus tard, une réplication de base de données a commencé à prendre du retard. Pas suffisamment pour alerter immédiatement, mais assez pour décaler la réplication. Un test de bascule a eu lieu cette semaine‑là et il a pris plus de temps que souhaité.

Ce qui s’est passé : la réplication et les sauvegardes partageaient des ports et des patterns que le classifieur ne distinguait pas. Le « cap bulk » s’appliquait à plus que les sauvegardes. Le système n’a pas cassé bruyamment ; il s’est dégradé silencieusement. C’est le pire.

Ils ont tenté de « corriger » en créant plus de classes : une pour les backups, une pour la réplication, une pour les métadonnées de stockage, une pour tout le reste. Ça a empiré car la précision du classifieur a chuté et la politique est devenue incompréhensible. Un mois plus tard, personne ne savait dans quelle classe un flux donné appartenait, donc personne ne pouvait prédire le comportement en contention.

La vraie correction : réduire le nombre de classes, classifier la réplication par identité d’endpoint (serveurs de backup vs nœuds de réplication), et donner à la réplication un partage minimum avec un plafond raisonnable. Aussi : façonner aux bordures WAN, pas sur des uplinks de data center aléatoires où la congestion n’était pas le goulet.

Mini‑histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une société SaaS faisait tourner des clusters Kubernetes multi‑tenant avec des incidents « noisy neighbor ». Dès le départ, ils ont adopté une règle plate : pas de DSCP contrôlé par le tenant. Tout l’e‑gress des pods était remarké au nœud selon le namespace et un petit ensemble d’étiquettes de service. Ils ont documenté le mapping et l’ont fait valider en revue de code.

Ils ont aussi façonné l’egress internet sur chaque gateway NAT de cluster légèrement en dessous du policer connu du fournisseur. Sous ce shaping, ils utilisaient fq_codel pour l’équité et gardaient exactement quatre classes : realtime (rare), interactif, défaut, bulk. Bulk avait un plafond, interactif une petite garantie, et realtime était strictement policé.

Un jour, un tenant a poussé une fonctionnalité « export de données » qui a saturé l’egress. Le support a vu un pic de latence UI et a craint un incident. Mais les graphiques racontaient clairement l’histoire : l’utilisation de la classe bulk plafonnait à son ceiling, l’interactif restait stable, et le défaut ne chutait que légèrement.

L’on‑call n’a pas inventé de nouvelles priorités. Il a dit au tenant, honnêtement : « Votre job est en classe bulk, il est plafonné par conception et finira en N heures. » Puis ils ont aidé le tenant à planifier les exports et ont proposé un niveau supérieur avec des ceilings bulk plus élevés. Pas de crise, pas de changement de politique à minuit, pas de mystère.

C’est à ça que ressemble un « QoS qui fonctionne » : une politique que vous pouvez expliquer à un ingénieur fatigué à 3 h du matin, avec de l’instrumentation confirmant que la politique fait ce que vous vouliez.

Erreurs courantes : symptôme → cause racine → correction

1) « Le QoS est activé mais la latence spike encore lors des uploads »

Symptôme : la latence p95 monte quand quelqu’un sature l’uplink ; perte de paquets apparente au bord ISP ; le device local montre peu de drops.

Cause racine : La file est en amont (policer du fournisseur / modem câble / CPE non géré). Vous ne contrôlez pas la file goulet.

Correction : Façonnez l’egress en dessous du débit réellement appliqué (souvent 90–95%). Utilisez cake ou HTB+fq_codel pour que votre appareil possède la file.

2) « On a mis tout en haute priorité et maintenant rien ne marche »

Symptôme : le trafic par défaut est affamé ; timeouts aléatoires ; la voix va bien ; le lien n’est pas plein selon la surveillance.

Cause racine : File en priorité stricte non policée ; trafic mal marqué la submerge et affame les autres files.

Correction : Policer/plafonner la classe priorité stricte. Réduire qui peut marquer EF. Envisagez WRR/DRR au lieu de priorité stricte sauf pour un petit temps réel.

3) « Après activation du QoS, le débit a chuté de 30% »

Symptôme : transferts bulk plus lents que prévu même avec lien vide ; CPU du routeur/hôte augmenté.

Cause racine : débit de shaping trop bas, ou qdisc (cake/fq_codel) trop lourd pour le matériel, ou interactions offload.

Correction : Validez le débit réel du lien ; ajustez le shaper ; assurez‑vous de la capacité matérielle ; envisagez de déplacer le shaping sur une box capable ; gardez les règles simples.

4) « Seules certaines applis reçoivent le traitement prévu »

Symptôme : même service se comporte différemment selon hôtes/sous‑réseaux ; captures montrent DSCP inconsistants.

Cause racine : plusieurs points de marquage (endpoints + firewall + switch) réécrivent DSCP ; frontière de confiance incohérente.

Correction : Choisissez une autorité de marquage par frontière. Documentez‑la. Faites appliquer : ou vous faites confiance aux endpoints gérés, ou vous remarkez à l’entrée de votre domaine.

5) « Le QoS marche sur filaire mais les utilisateurs Wi‑Fi se plaignent toujours »

Symptôme : appels filaires ok ; appels Wi‑Fi saccadés ; pertes augmentent avec plus de clients.

Cause racine : La contention d’airtime et les retransmissions dominent ; mapping WMM incorrect ou non appliqué ; tampons AP gonflés.

Correction : Ajustez le Wi‑Fi séparément : activez WMM, vérifiez le mapping DSCP→AC, réduisez le bufferbloat sur le bord WLAN, préférez 5/6 GHz, gérez la densité de clients.

6) « On a marqué le trafic mais les switches l’ignorent »

Symptôme : DSCP présent mais aucun changement de comportement ; compteurs QoS du switch immobiles.

Cause racine : confiance DSCP désactivée sur les ports, ou mapping DSCP→queue non configuré, ou limitations hardware.

Correction : Confirmez que le QoS est activé globalement ; configurez la frontière de confiance ; mappez DSCP/PCP vers les files ; vérifiez avec compteurs et test de congestion.

7) « Le trafic interactif lag encore sous charge bulk »

Symptôme : SSH saccade pendant les backups ; l’utilisation globale n’est pas saturée.

Cause racine : Pas d’équité au goulet (pfifo), ou interactif est dans la même file que le bulk, ou la classe n’a pas de partage minimum.

Correction : Utilisez fq_codel/cake ; assurez‑vous que la classe interactive a au moins un petit débit garanti ; vérifiez la classification par capture de paquets.

Checklists / plan étape par étape

Étape par étape : implémenter un QoS que vous pouvez défendre en revue

1. Identifiez les liens goulet. Egress internet, circuits WAN, tunnels VPN, uplinks contrôleur Wi‑Fi. Si vous ne savez pas, mesurez l’utilisation et la latence sous charge.
2. Décidez votre modèle de classes (3–5 classes). Rédigez une phrase de politique pour chacune : part minimale, plafond max, et pourquoi.
3. Définissez les frontières de confiance. Où DSCP/PCP est fiable ; où il est écrasé ; où il est ignoré.
4. Choisissez mécanisme d’ordonnancement/shaping par frontière. Cake si disponible ; sinon HTB+fq_codel. Ne mélangez pas d’ordonnanceurs exotiques sauf si vous pouvez observer et rollback.
5. Définissez le débit de shaping en dessous du débit appliqué. Commencez à 90–95% du débit soutenu mesuré ; ajustez après vérification.
6. Policiez les classes priorité stricte. EF obtient un plafond. Toujours. Sinon vous écrivez un incident dans votre config.
7. Implémentez la classification en un seul endroit. Préférez le nœud/ToR/edge plutôt que l’application. Gardez les règles courtes et basées sur l’identité quand possible.
8. Instrumentez. Suivez l’utilisation des classes, les drops, les marques ECN, la backlog de file et les SLOs de latence utilisateur.
9. Testez sous contention contrôlée. Générez une charge bulk ; vérifiez que interactif/temps réel restent stables ; capturez pour confirmer marquages et mappings.
10. Documentez le « pourquoi ». Incluez des exemples : « Sauvegardes sont CS1, plafonnées à X, planifiées hors heures. » Le vous futur oubliera. Le vous présent démissionnera.
11. Déployez progressivement. Un site/lien à la fois. Gardez une commande de rollback prête.
12. Faites un game day. Saturer intentionnellement ; confirmez que le système échoue de façon gracieuse et prédictible.

Checklist : ce qu’il faut capturer pendant un incident QoS

• Stats d’interface (octets, drops, erreurs) sur l’egress suspect.
• Stats qdisc (drops, overlimits, marques ECN, backlog).
• Échantillons de latence (min/avg/max) en idle et sous charge.
• Capture de paquets montrant DSCP/PCP pour au moins un flux affecté.
• Vérification de chemin (route, état tunnel, NAT gateway utilisée).
• Historique des changements : quoi a été déployé/modifié dans les dernières 24 heures.

FAQ

1) Dois‑je prioriser les ACK TCP ?

Parfois. Sur des liens très asymétriques (petite uplink, grosse downlink), prioriser les ACK peut améliorer le débit en aval et réduire les blocages. Mais ne devinez pas : confirmez d’abord que la saturation de l’uplink cause l’effondrement en aval. Si vous utilisez cake, il gère déjà beaucoup de ces cas.

2) DSCP suffit‑il, ou ai‑je besoin de shaping ?

DSCP seul est une demande. Le shaping est l’exécution. Si vous ne contrôlez pas la file goulet, DSCP n’est que des vibes. Utilisez DSCP pour classifier dans votre domaine, mais supposez qu’il peut être blanchi en dehors.

3) Pourquoi ne pas tout mettre en « AF41 » et basta ?

Parce que la contention existe toujours. Si tout est premium, rien ne l’est. Pire, vous perdez la capacité à mettre en quarantaine le trafic bulk, qui est le principal gain pour l’expérience utilisateur.

4) Le QoS peut‑il corriger des pertes de paquets dues à un câble ou des optiques défectueux ?

Non. Ce n’est pas de la congestion ; c’est de la physique, du matériel ou une mauvaise configuration. Réparez les couches 1/2 d’abord. Le QoS ne gère que la contention sur un lien fonctionnel.

5) Combien de classes dois‑je exécuter ?

Trois à cinq pour la plupart des organisations. Plus de classes augmentent le risque opérationnel : mauvaise classification, famine inattendue, et politiques qu’on ne comprend pas pendant les incidents.

6) Où marquer le trafic dans Kubernetes ?

À la frontière du nœud (host network) basé sur namespace/identité du workload, pas à l’intérieur des pods. Les pods sont trop faciles à mal configurer, et les clusters multi‑tenant exigent une frontière de confiance stricte.

7) L’ECN remplace‑t‑il le QoS ?

Non. L’ECN aide les endpoints à réagir à la congestion sans drops, mais il ne définit pas qui obtient de la bande pendant la contention. ECN + FQ/AQM est excellent ; ECN seul n’alloue pas équitablement entre types de trafic.

8) Quel est le changement le plus simple pour « améliorer aujourd’hui » ?

Activez fq_codel (ou cake) sur le vrai goulet egress et façonnez légèrement en dessous du débit appliqué. Cela réduit souvent drastiquement les pics de latence sans classification élaborée.

9) La réplication stockage doit‑elle être « haute priorité » ?

Rarement. La réplication a besoin de fiabilité et d’un partage minimal, pas d’une priorité stricte. Si vous la priorisez au‑dessus du trafic interactif, vous optimisez pour le mauvais type de disponibilité.

10) Comment prouver que le QoS fonctionne ?

Reproduisez la contention et montrez : (a) les compteurs de classe évoluent comme prévu, (b) la latence interactive reste stable, (c) le bulk met plus de temps mais se termine, (d) les drops/délai de file sont contrôlés par votre shaper et non en amont.

Conclusion : actions à faire cette semaine

Si votre stratégie QoS est « augmenter la priorité », vous êtes à un flux mal marqué d’un incident étrange et chronophage. L’alternative n’est pas compliquée, juste disciplinée : contrôlez la file goulet, gardez peu de classes, appliquez des frontières de confiance et mesurez ce que votre ordonnanceur fait réellement.

Prochaines actions pratiques :

1. Choisissez un goulet connu (egress internet ou bord WAN) et implémentez du shaping à 90–95% du débit soutenu observé.
2. Activez fq_codel ou cake sur cet egress et capturez les stats qdisc avant/après sous charge.
3. Définissez un plan DSCP minimal (CS0, un AF pour interactif, EF pour petit realtime policé, CS1 pour scavenger) et documentez où vous lui faites confiance.
4. Effectuez un test de saturation contrôlé et prouvez que la latence interactive reste raisonnable.
5. Rédigez le plan de rollback. Pas parce que vous allez échouer, mais pour pouvoir dormir.

Faites cela, et le QoS redeviendra ce qu’il aurait dû être dès le départ : un comportement prévisible en cas de contention, pas une planche de Ouija réseau.