Partager la bande passante et prioriser le trafic en time réel via HTB, quel scénario fonctionne mieux?

J'aimerais append une sorte de gestion du trafic à notre ligne Internet. Après avoir lu beaucoup de documentation, je pense que HFSC est trop compliqué pour moi (je ne comprends pas toutes les courbes, je crains que je ne le ferai jamais bien), CBQ n'est pas recommandé et, en principe, HTB est la façon de aller pour la plupart des gens.

Notre réseau interne dispose de trois «segments» et je voudrais partager la bande passante de manière plus ou less égale entre ceux (au less au début). En outre, je dois prioriser le trafic selon au less trois types de trafic (trafic en time réel, trafic standard et trafic en vrac). Le partage de bande passante n'est pas aussi important que le fait que le trafic en time réel doit toujours être traité comme un trafic premium chaque fois que cela est possible, mais bien sûr, aucune autre class de trafic ne peut affamer.

La question est, ce qui a plus de sens et garantit également un meilleur débit en time réel:

  1. Création d'une class par segment, chacune ayant le même taux (la priorité ne concerne pas les classs qui ne sont pas des feuilles selon le développeur HTB) et chacune de ces classs comporte trois sous-classs (feuilles) pour les 3 niveaux de priorité (avec des priorités différentes et des taux différents).

  2. Ayant une class par niveau de priorité en haut, chacune ayant un taux différent (encore une priorité ne sera pas importante) et chacune ayant 3 sous-classs, une par segment, alors que les 3 dans la class en time réel ont le plus haut prio, le plus bas prio dans la masse class, etc.

Je vais essayer de rendre cela plus clair avec l'image d'art ASCII suivante:

Case 1: root --+--> Segment A | +--> High Prio | +--> Normal Prio | +--> Low Prio | +--> Segment B | +--> High Prio | +--> Normal Prio | +--> Low Prio | +--> Segment C +--> High Prio +--> Normal Prio +--> Low Prio Case 2: root --+--> High Prio | +--> Segment A | +--> Segment B | +--> Segment C | +--> Normal Prio | +--> Segment A | +--> Segment B | +--> Segment C | +--> Low Prio +--> Segment A +--> Segment B +--> Segment C 

Cas 1 Il semble que la plupart des gens le fassent, mais à less que je ne lis pas correctement les détails de mise en œuvre de HTB, le cas 2 peut offrir une meilleure hiérarchisation.

Le manuel HTB indique que, si une class a frappé son taux, elle peut emprunter auprès de son parent et, lors de son emprunt, les classs ayant une priorité élevée obtiennent toujours la bande passante offerte en premier. Cependant, il dit aussi que les classs ayant une bande passante disponible sur un niveau inférieur de l'tree sont toujours préférées à ceux qui sont sur un niveau d'tree plus élevé, quelle que soit la priorité .

Supposons la situation suivante: le segment C n'émettra pas de trafic. Le segment A ne transmet que le trafic en time réel aussi vite qu'il le peut (assez pour saturer le lien seul) et le segment B n'envoie que du trafic en vrac aussi rapidement qu'il le peut (encore une fois, il suffit de saturer le lien complet seul). Que se passera-t-il?

Cas 1:
Segment A-> High Prio et Segment B-> Low Prio ont tous deux des packages à envoyer, car A-> High Prio a la priorité la plus élevée, il sera toujours programmé d'abord, jusqu'à ce qu'il frappe son taux. Maintenant, il essaie d'emprunter à partir du segment A, mais comme le segment A est à un niveau supérieur et que le segment B-> Low Prio n'a pas encore atteint son taux, cette class est maintenant desservie en premier, jusqu'à ce qu'elle frappe aussi le taux et que l'on veut emprunter Segment B. Une fois que les deux ont frappé leurs taux, les deux sont sur le même niveau à nouveau et maintenant le segment A-> High Prio va reprendre, jusqu'à ce qu'il frappe le taux du segment A. Maintenant, il essaie d'emprunter à la racine (qui a beaucoup de trafic de secours, car le segment C n'utilise pas son trafic garanti), mais encore, il faut attendre que le segment B-> Low Prio atteigne également le niveau de racine. Une fois que cela se produit, la priorité est prise en count à nouveau et cette fois, le segment A-> High Prio obtiendra toute la bande passante restante du segment C.

Cas 2:
High Prio-> Segment A et Low Prio-> Segment B ont tous deux des packages à envoyer, encore High Prio-> Segment A va gagner car il a la plus haute priorité. Une fois qu'il frappe son taux, il tente d'emprunter à High Prio, qui a une bande passante de rechange, mais étant à un niveau supérieur, il faut attendre à Low Prio-> Segment B pour bash son taux. Une fois que les deux ont frappé leur taux et les deux doivent emprunter, High Prio-> Segment A gagnera à nouveau jusqu'à ce qu'il atteigne le taux de la class High Prio. Une fois que cela se produit, il essaie d'emprunter à la racine, qui a de nouveau de la largeur de bande à gauche (toute la bande passante de Normal Prio n'est pas utilisée pour le moment), mais il faut attendre jusqu'à ce que Low Prio-> Segment B touche la limite de vitesse de la Low Prio et essaie aussi d'emprunter à la racine. Enfin, les deux classs tentent d'emprunter auprès de la racine, la priorité est prise en count, et High Prio-> Segment A obtient toute la bande passante de la racine restée.

Les deux cas semblent sous-optimaux, de sorte que le trafic en time réel doit parfois attendre le trafic en vrac, bien qu'il y ait beaucoup de bande passante, il pourrait emprunter. Cependant, dans le cas 2, il semble que le trafic en time réel doit attendre less que dans le cas 1, car il suffit d'attendre que le taux de trafic en vrac soit atteint, ce qui est probablement inférieur au taux d'un segment entier (et dans le cas 1 c'est le taux qu'il faut attendre). Ou est-ce que je me trompe totalement ici?

J'ai pensé à des configurations encore plus simples, en utilisant un qdisc de priorité. Mais les files d'attente prioritaires ont le gros problème qu'elles causent la famine si elles ne sont pas limitées. La famine n'est pas acceptable. Bien sûr, on peut mettre un TBF (Token Bucket Filter) dans chaque class de priorité pour limiter le taux et ainsi éviter la famine, mais lorsque cela se produit, une seule class de priorité ne peut plus saturer le lien, même si toutes les autres classs prioritaires sont vides, le TBF empêchera que cela ne se produise. Et cela est également sous-optimal, car pourquoi une class ne recevrait-elle pas 100% de la bande passante de la ligne si aucune autre class n'en avait besoin pour l'instant?

Des commentaires ou des idées concernant cette configuration? Il semble si difficile à utiliser en utilisant les qdisc standard de tc. En tant que programmeur, c'était une tâche si simple si je pouvais simplement écrire mon propre planificateur (ce que je ne suis pas autorisé à faire).

One Solution collect form web for “Partager la bande passante et prioriser le trafic en time réel via HTB, quel scénario fonctionne mieux?”

Si je comprends bien htb, alors le taux est "garanti". Cela signifie que vous avez des idées sur le taux de trafic en time réel. Seulement si ce taux est dépassé, il empruntera. Si plusieurs classs veulent emprunter, le prio devrait être rentré. Les taux garantis devraient augmenter la limite physique. Sinon, c'est trop marrant.

IMHO, Case A ne fonctionnera jamais vraiment car vous devez avoir la priorité ou la limitation des taux au niveau racine. Les priorités / taux dans les différents segments ne se connaissent pas et seront traités de manière égale.

Ce que vous voulez probablement, c'est: Mettez le "taux" pour prio bas et normal à 0 ou près de lui et ajoutez "plafond" pour le rest de la bande passante, pour un prix élevé, vous garantissez un taux de 100% de la physique.

  • Les transferts par FTP ralentissent entre 2 servers
  • Debian7 et tc qdisc problème: RTNETLINK répond: Aucun file ou directory
  • Comment faire la mise en forme du trafic dans Linux par les invités de xen?
  • Dépannage d'iptables et configuration pour supprimer la priorité des connections à long terme
  • Quels sont les bons programmes qui peuvent être utilisés pour limiter le trafic sur un server?
  • Comment partager la bande passante équitablement entre 16 users sur un routeur PFSense multi-WAN
  • Réduction de la bande passante à l'aide de qdiscs tc
  • Filtres de hachage TC - suppression de règle unique
  • FreeBSD Traffic Shaping
  • Comment puis-je évaluer la forme de la limite / forme du package / trafic sur Solaris
  • Linux TC / Policy Routing tools
  • Les astuces du serveur de linux et windows, tels que ubuntu, centos, apache, nginx, debian et des sujets de rĂ©seau.