Je déteste la QoS.
En LAN party, il y a toujours deux catégories de personnes : celui qui veut un ping propre pour cliquer des têtes, et l’autre qui nous casse les ******** avec son téléchargement de 200 Go “vite fait” parce qu’il veut faire son Apex dans son coin.
C’est là que la QoS entre en scène. Son rôle n’est pas magique, mais presque : éviter qu’un gros flux bien gras vienne ruiner la partie de tout le monde.
On a donc deux outils très utiles : les queues côté IP, pour organiser qui passe en premier, et le marquage DSCP, pour mettre des petites étiquettes de priorité sur les paquets.
En gros : apprendre au réseau à comprendre qu’une game en cours mérite un peu plus de respect qu’une mise à jour Steam lancée à 21h03.
Les Queues, et non pas celles que tu penses
Bon, on va s’attaquer au sujet MikroTik, car c’est notre habitude de faire du réseau sur des patates, mais des patates de luxe.
Quand on parle de QoS sur MikroTik, il y a trois mots qui reviennent tout le temps et qui donnent immédiatement l’impression qu’il faut un doctorat en souffrance réseau : queue, queue tree et queue type. En vrai, l’idée derrière tout ça est assez simple : quand tout le monde veut passer en même temps sur le réseau, il faut éviter que ce soit le bronx.
Une queue, c’est la base. C’est une file d’attente réseau. Elle permet de dire : “toi, tu peux aller à telle vitesse”, “toi, attends un peu”, ou encore “toi, tu passes en priorité parce que tu es important”. C’est donc l’outil général pour contrôler comment la bande passante est distribuée.
La version la plus simple, c’est la simple queue. Là, pas besoin de sortir la carte d’ingénieur. Tu prends une IP, un appareil ou un sous-réseau, et tu lui mets une limite. Par exemple : “ce PC ne dépassera pas 50 Mbit/s” ou “ce VLAN a droit à 200 Mbit/s maximum”. C’est pratique, rapide, et parfait quand on veut juste empêcher Kevin de saturer Internet avec ses téléchargements douteux.
Le queue tree, lui, est un peu plus sérieux. Là, on ne gère plus juste une machine ou une IP, on organise tout le trafic en familles. En gros, on construit un arbre. En haut, tu as le gros débit total disponible. En dessous, tu découpes : le jeu, la voix, le web, les téléchargements, les mises à jour, le streaming… Chaque branche reçoit sa part, sa priorité, et son comportement. Résultat : même si quelqu’un télécharge comme un bourrin, la partie en ligne et le vocal continuent de respirer.
Dit autrement, la simple queue, c’est “je limite une personne”. Le queue tree, c’est “j’organise toute la circulation du réseau”. C’est un peu la différence entre dire à une voiture de ralentir, et installer de vrais feux, des priorités et des voies réservées dans toute la ville.
Ensuite arrive le queue type. Et là, il ne dit pas qui doit être limité, mais comment la file doit fonctionner. C’est le moteur interne de la queue. Est-ce qu’on traite les paquets dans l’ordre bêtement, façon premier arrivé premier servi ? Est-ce qu’on essaye de partager équitablement entre plusieurs utilisateurs ? Est-ce qu’on veut réduire la latence quand le lien commence à saturer ? Le queue type, c’est un peu la personnalité de la file d’attente.
En pratique ?
Sur un événement, c’est très simple. On n’a pas l’embarras du choix, nous découvrons à chaque fois un nouveau type de connexion ; que ce soit la FTTH qui a débit variable, le Starlink sous la pluie, la 5G plutôt proche du DSL, la FTTO qui couvre l’ensemble des besoins de l’événements… Il faut trouver un moyen de limiter!
En pratique, on va chercher deux choses ; classifier les besoins “realtime” des besoins “best effort”.
En général on va définir des besoins pour le streaming, la scène, les jeux en top priorité. Parfois, un peu de DSCP (qu’on verra après…) mais surtout, on n’y touche pas !
En réalité, on va s’attaquer au trafic best effort, celui qui n’est pas prioritaire mais qui peut vraiment poser problème…
Prenons un cas d’exemple simple, une LAN.
Sur un petit événement, une cinquantaine de client filaire et une vingtaine de périphérique sans fil. Nous pouvons imaginer un simple LAN, disons 10.100.0.0/16.
Pour faciliter l’allocation des périphériques, nous mettons un DHCP sur la plage 10.100.100.0-10.100.100.255, que cela corresponde à un /24.
Ce n’est pas nécessaire, mais cela simplifie la configuration des pare-feux, les périphériques nécessitant une QoS avantageuse pourront être placés manuellement en dehors.
Si nous avons un accès Internet relativement stable de 1Gbps, on va partir sur des règles assez simples ;
- pas plus de 10% de la connexion accessible par poste client,
- pas plus de 40% pour l’ensemble des postes,
- idéalement un LANCache pour tout téléchargement Windows, Jeux, capé à 50% maximum de la connexion,
- …et c’est tout!
Avec ce partitionnement, sur 1000Mbps (1Gbps), cela fait donc 400Mbps pour tous les PC du LAN vers Internet, mais pas plus de 100Mbps par PC, et 500Mbps au max pour le LANCache.
Il reste donc 10%, 100Mbps, “non utilisable” par la QoS, que l’on peut donc dédier aux clients qui en ont besoin en priorité.
Simple, une des règles d’une QoS efficace, c’est un jeu de règles sobres!
Sur MikroTik, cela donne ça :
/queue type
add kind=pcq name=custom-pcq-download pcq-classifier=dst-address pcq-rate=100M
add kind=pcq name=custom-pcq-upload pcq-classifier=src-address pcq-rate=100M
/queue tree
add max-limit=400M name=pcq-upload-wan packet-mark=pcq-up-wan parent=global queue=custom-pcq-upload
add max-limit=400M name=pcq-download-wan packet-mark=pcq-down-wan parent=global queue=custom-pcq-download
add max-limit=500M name=pcq-download-wan-lancache packet-mark=pcq-down-wan-lancache parent=global queue=custom-pcq-download
/ip firewall mangle
add action=mark-packet chain=forward dst-address-list=!LOCAL-NO-QOS new-packet-mark=pcq-up-wan out-interface-list=WAN passthrough=no src-address=10.100.100.0/24
add action=mark-packet chain=forward dst-address=10.100.100.0/24 in-interface-list=WAN new-packet-mark=pcq-down-wan passthrough=no src-address-list=!LOCAL-NO-QOS
add action=mark-packet chain=forward dst-address=10.42.0.42 in-interface-list=WAN new-packet-mark=pcq-down-wan-lancache passthrough=no src-address-list=!LOCAL-NO-QOS
/ip firewall address-list
add address=10.100.0.0/16 list=LAN
add address=10.42.0.0/16 list=SVC
add address=10.0.0.0/8 list=LOCAL
Avec évidemment, 10.42.0.42 en LANCache.
Le DSCP, une lueur d’espoir dans le réseau!
Le DSCP, c’est un peu comme une étiquette collée sur un paquet réseau pour dire : “hé, moi je suis important”. Pas “important” au sens existentiel, mais plutôt au sens : “ce serait sympa de me traiter un peu mieux que la mise à jour d’un launcher oubliée depuis 2023”.
Concrètement, DSCP veut dire Differentiated Services Code Point. Derrière ce nom de boss final de la norme réseau, l’idée est assez simple : dans l’en-tête IP, il existe un petit champ qui permet de marquer les paquets avec une certaine classe de service. En gros, on ne change pas le contenu du paquet, on lui colle juste un badge. Un peu comme en festival : VIP, presse, exposant, ou “toi tu fais la queue avec les autres”. Souvent, on va parler qu’un équipement est compatible “DiffServ”.
Ce marquage permet ensuite aux équipements réseau, routeurs, switchs, bornes Wi-Fi, firewalls, de prendre des décisions. Par exemple : mettre certains paquets dans une file plus prioritaire, leur donner moins de latence, ou éviter qu’ils se retrouvent coincés derrière un téléchargement conséquent.
C’est particulièrement utile pour les flux sensibles au délai. Une voix sur IP, un flux audio en direct, une visioconférence, ou certains trafics de jeu supportent très mal d’attendre dans la file derrière des transferts massifs. Avec DSCP, on peut dire au réseau : “ça, essaie de le faire passer avant le reste”. Le but n’est pas de rendre un paquet plus rapide par magie, mais de lui donner plus de chances de ne pas subir le chaos général.
Et c’est là qu’il faut bien insister sur un point très important : DSCP n’est pas une garantie absolue. Pas du tout. Vraiment pas.
Le DSCP, ce n’est pas un passe-droit magique du réseau. C’est plutôt une demande polie. Le paquet arrive avec son petit costume de VIP, mais chaque équipement sur le chemin reste libre de répondre :
-
“oui, je prends ça en compte”,
-
“non, je m’en fiche”,
-
ou même “tiens, je vais effacer ton marquage, ça m’amuse”.
Autrement dit, DSCP ne garantit rien à lui seul. Il ne réserve pas automatiquement de bande passante, il ne force pas Internet entier à obéir, et il ne transforme pas un réseau saturé en autoroute vide. Pour que ça serve à quelque chose, il faut que les équipements traversés soient configurés pour reconnaître ce marquage et agir en conséquence.
C’est toute la nuance : DSCP donne une information, mais ce sont les politiques QoS derrière qui décident quoi en faire. Sans configuration adaptée, le paquet marqué reste juste… un paquet marqué. C’est comme arriver à l’aéroport avec une carte “prioritaire” imprimée chez soi : techniquement, tu as un badge, mais personne n’est obligé d’y croire.
Et même dans un réseau bien configuré, il faut rester réaliste. Si le lien est totalement saturé, si le matériel intermédiaire ignore le marquage, ou si le trafic passe chez des opérateurs qui réécrivent ou suppriment les valeurs DSCP, l’effet peut être très limité. Sur un réseau local que tu contrôles, ça peut être très utile. Sur Internet de bout en bout, c’est beaucoup plus aléatoire.
Donc, l’intérêt du DSCP, ce n’est pas de promettre un miracle. Son intérêt, c’est de donner au réseau une indication de priorité pour mieux traiter certains flux quand c’est possible. C’est un outil d’organisation, pas une baguette magique. Il aide à privilégier les paquets importants, mais seulement là où quelqu’un a décidé de jouer le jeu.
Et là, on pousse le DSCP du stream au MAX (ou presque) ! 
/ip firewall mangle
add action=change-dscp chain=forward new-dscp=46 src-address=10.100.150.0/24
Conclusion
La QoS c’est vraiment pas automatique.
Cependant, elle sauve, quand la box surchauffe, l’accès Internet est douteux, les gens sont libres de faire ce qu’ils souhaitent sur les clients connectés au réseau, tant qu’elle est dosée, avec parcimonie.