Gestion de bande passante MikroTik : files

Résumé La gestion de la bande passante MikroTik repose sur trois outils : les simple queues pour un plafond rapide par client, les queue tree pour la hiérarchie et la priorité, et PCQ pour le partage équitable entre de nombreux utilisateurs sans créer une file à chacun. Les queue tree s’associent aux marques mangle du pare-feu et vous donnent des garanties, des plafonds et des priorités. Ce guide montre quand utiliser chacun, les commandes RouterOS, et comment garder la même politique cohérente sur une flotte de routeurs.

Qu’est-ce que la gestion de bande passante sur MikroTik ?

La gestion de la bande passante sur MikroTik consiste à utiliser les files d’attente de RouterOS pour contrôler la part d’un lien que chaque client, sous-réseau ou classe de trafic peut consommer — en limitant les débits, en garantissant des minimums et en décidant qui cède quand le lien est saturé. RouterOS implémente les files avec un ordonnanceur Hierarchical Token Bucket (HTB), exposé à deux endroits : les simple queues, une liste ordonnée appliquée dans l’ordre, et le queue tree, une hiérarchie rattachée aux interfaces ou aux packet-mark issus du mangle du pare-feu (Documentation MikroTik — Queues).

Cette distinction détermine jusqu’où votre conception pourra monter en charge. Une simple queue répond à « plafonner ce client à 50 Mbps ». Un queue tree répond à « ce lien montant de 500 Mbps est partagé par 300 abonnés, la VoIP passe en premier, personne n’est affamé, et les gros téléchargeurs ne gâchent pas la soirée ». Tout FAI finit par avoir besoin de la seconde réponse.

Étape 1 — Limitez un client avec une simple queue

Les simple queues sont le chemin le plus court entre le problème et la solution. Ciblez une IP, un sous-réseau ou une interface, fixez le plafond, et c’est terminé :

/queue simple add name=client-101 target=10.10.0.101/32 max-limit=10M/50M

max-limit s’écrit sous la forme upload/download du point de vue du routeur. Les règles sont évaluées dans l’ordre et la première correspondance l’emporte — une règle large placée tôt avale donc silencieusement les règles spécifiques que vous ajoutez ensuite. Cet ordonnancement est la raison la plus fréquente pour laquelle une file « qui marchait » cesse de fonctionner après qu’on a ajouté une règle au-dessus (Documentation MikroTik — Queues).

Les simple queues s’associent aussi à l’authentification des abonnés : le champ rate-limit d’un profil PPPoE crée une simple queue dynamique par session, de sorte que les forfaits suivent l’utilisateur plutôt que l’IP. Notre guide du serveur PPPoE MikroTik pour les FAI couvre le volet profil.

Étape 2 — Marquez le trafic avec le mangle du pare-feu

Le queue tree ne voit ni « VoIP » ni « client 101 » ; il voit des packet-mark. Créez-les dans le mangle, en marquant d’abord la connexion puis les paquets, ce qui coûte moins cher que de réinspecter chaque paquet :

/ip firewall mangle
add chain=forward action=mark-connection new-connection-mark=voip-conn protocol=udp port=5060,10000-20000
add chain=forward action=mark-packet connection-mark=voip-conn new-packet-mark=voip-pkt passthrough=no

Gardez une taxonomie de marques réduite et stable. Les marques sont le vocabulaire que parlent vos files, et dès qu’une flotte accumule trois générations de noms de marques improvisés, plus personne ne sait quel routeur applique quelle politique. C’est là que l’audit et l’historique de configuration de MKController font la différence : consultez l’état du mangle et des files de chaque routeur, comparez-le à la politique voulue, et déployez les règles corrigées sur toute la flotte au lieu d’ouvrir trente sessions Winbox pour trouver le seul équipement qui n’a jamais reçu le changement.

Étape 3 — Construisez la hiérarchie du queue tree

Un queue tree possède un parent qui détient la capacité réelle du lien, et des enfants qui la répartissent :

/queue tree
add name=download parent=bridge-lan max-limit=500M
add name=voip parent=download packet-mark=voip-pkt limit-at=50M max-limit=100M priority=1
add name=bulk parent=download packet-mark=bulk-pkt limit-at=50M max-limit=500M priority=8

Trois champs font tout le travail. limit-at est la garantie qu’un enfant reçoit même lorsque le lien est saturé. max-limit est le plafond qu’il peut atteindre quand de la capacité est libre. priority — 1 étant la plus élevée, 8 la plus basse — décide quel enfant récupère les restes en premier, et ne s’applique qu’entre limit-at et max-limit (Documentation MikroTik — Queues). Réglez le max-limit du parent sur ce que le lien fournit réellement, pas sur ce que dit le contrat, sinon la file ne devient jamais le goulot d’étranglement et ne régule rien.

Étape 4 — Ajoutez PCQ pour le partage équitable

Le Per Connection Queue (PCQ) est la raison pour laquelle MikroTik monte en charge jusqu’à des nombres d’abonnés qui rendraient une liste de files par utilisateur ingérable. Un type de file PCQ classe le trafic selon un champ d’adresse et crée une sous-file dynamique pour chaque valeur distincte, en appliquant le même débit à chacune (Documentation MikroTik — exemple PCQ) :

/queue type
add name=pcq-down kind=pcq pcq-rate=20M pcq-classifier=dst-address
add name=pcq-up   kind=pcq pcq-rate=10M pcq-classifier=src-address

Attachez pcq-down comme queue de l’enfant qui porte le trafic de download des clients, et chaque client obtient jusqu’à 20 Mbps, alloués automatiquement. Réglez pcq-rate=0 et PCQ répartit la bande passante du parent à parts égales entre tous les actifs — la configuration classique « personne n’est affamé ». Un seul type de file remplace des centaines d’entrées écrites à la main.

La même logique d’égalisation s’applique au WiFi partagé : la limite de débit du forfait et un parent PCQ empêchent ensemble un invité de consommer tout le lien montant d’un établissement — voyez notre guide de configuration des vouchers HotSpot MikroTik pour le volet identifiants.

Étape 5 — Ajustez limit-at, max-limit, burst et priority

La plupart des QoS cassées ne tiennent pas à un mauvais outil, mais à de mauvais chiffres. Gardez la somme des limit-at de tous les enfants inférieure ou égale au max-limit du parent ; si les garanties surchargent le lien, HTB ne peut pas les honorer et les priorités cessent de se comporter comme prévu. Réservez priority=1 au trafic sensible à la latence — VoIP, jeux, DNS — et laissez les transferts en masse à 8 avec un plafond généreux.

Le burst mérite un avertissement. burst-limit, burst-threshold et burst-time permettent à un client de dépasser brièvement max-limit tant que sa moyenne reste basse — parfait pour les tests de débit, moins bon pour un lien surchargé. Mesurez avec /queue simple print stats ou les compteurs du queue tree pendant que le lien est sous charge, pas à 3 h du matin quand tout est au repos. Si lire les compteurs en heure de pointe n’est pas praticable, la vue Internet Link de MKController conserve la même image en continu — l’utilisation face à la vitesse contractuelle ; la latence en moyenne, maximum et P95 ; et le nombre d’heures que chaque lien a passées au-dessus de 90 % — pour que vous ajustiez sur l’historique, pas sur un instantané chanceux.

La capacité aussi évolue. Sur une configuration de bascule dual-WAN, le max-limit du parent que vous avez ajusté pour la fibre devient une fiction dès que le trafic bascule sur le secours LTE — prévoyez une seconde politique.

Étape 6 — Déployez la politique sur toute la flotte

Un routeur, c’est une configuration ; une centaine de routeurs, c’est une exploitation. La politique doit désormais être identique sur chaque équipement, survivre au technicien qui a « temporairement » relevé le plafond d’un client, et être récupérable quand un routeur de pylône est réinstallé via netinstall. Rien dans RouterOS ne fait cela pour vous.

MKController, si : déploiements à l’échelle de la flotte des types de file, des profils rate-limit et des règles de pare-feu ; historique de configuration, pour voir quand une limite a changé et restaurer la version précédente en un clic ; sauvegardes automatiques avant chaque changement ; et accès distant sortant sécurisé vers les routeurs derrière du CGNAT ou sur Starlink, sans IP publique ni redirection de ports — l’approche que nous décrivons dans la gestion à distance de MikroTik derrière CGNAT. Et sa supervision Internet Link surveille les liens montants que vous venez de réguler — utilisation par source face à la vitesse contractuelle, latence avec P95, et consommation franchissant les seuils de 75 % et 90 % sur jusqu’à quatre sources WAN par routeur — de sorte qu’un lien qui rampe vers la saturation apparaît sur le tableau de bord, et (couplé aux alertes Telegram) dans vos notifications, avant qu’un abonné n’appelle. Les FAI et WISP qui exploitent MikroTik à grande échelle s’en servent pour que la politique de bande passante reste une seule décision, pas une centaine.

Conseils

• Régulez sur l’interface par laquelle le trafic sort du routeur ; les files contrôlent l’egress, donc les téléchargements se régulent côté LAN et les envois côté WAN.
• Préférez un seul type de file PCQ à des centaines de simple queues dès que vous dépassez quelques dizaines d’abonnés.
• passthrough=no sur les règles mark-packet évite un parcours inutile des règles mangle restantes.
• Sauvegardez toujours avant de toucher aux files sur un routeur de bordure en production, et changez une seule variable à la fois.

Ne devinez plus où est passée votre bande passante

Les files sont ce qui sépare la vente d’un forfait de sa livraison. Les simple queues plafonnent un client, les queue tree apportent structure et priorité, PCQ rend l’équité automatique — et MKController transforme les trois en une politique que vous appliquez une fois et faites respecter partout : gestion de flotte centralisée, déploiements rate-limit et pare-feu sur chaque routeur, historique de configuration avec restauration en un clic, accès distant sans IP publique, et supervision Internet Link qui signale un lien saturant face à sa vitesse contractuelle avant vos clients.

Commencez votre essai gratuit MKController