QoS semblable au Delay Pools de Squid avec TC

Support Debian
#1

Bonjour à tous !

J’ai abandonné l’idée d’utiliser Squid pour appliquer ma QoS à cause des problèmes de certificat, je me suis donc orienté vers les outils réseaux de Linux à savoir “Traffic Control”.

La fonctionnalité Delay Pools de Squid est exactement ce que je souhaite obtenir en terme de QoS, j’aimerais donc mettre en place un système qui lui ressemble avec TC. D’ailleurs il me semble avoir lu que Squid utilise ces outils sur Linux pour le Delay Pools (savez-vous si c’est vrai ?).

J’ai donc créé un petit script bash qui utilise HTB et SFQ, le réseau que je dois gérer est de classe B donc il possède potentiellement 65533 adresses pour les clients. Dans mon script je créé autant de classes qu’il y a d’adresses à gérer, puis avec tc filter je redirige les adresses ip sur les files correspondantes.

Je me demande alors si c’est une bonne solution, et si Linux va pouvoir gérer toutes ces files sans problèmes.
Qu’en pensez-vous ?
Est-ce que c’est acceptable comme manipulation ?
Debian va-t-il supporter tout cela ? Combien de clients pourrait-il supporter ?
Est-ce que vous pensez qu’il y a plus simple ?

Merci !

EDIT : Une idée m’a traversé l’esprit, est-ce qu’il y a un mécanisme sur Linux qui permet de savoir quand un client se “connecte” ? Je pourrais ainsi gérer tout cela dynamiquement, je précise que ces clients ne sont pas dans mon sous-réseau, ils passent par d’autres équipements réseaux qui ne font pas de nating bien sur.

#2

Mon script est fonctionnel, finalement la démarche accomplie est la suivante, j’ai volontairement retirer les boucles pour bien visualiser les identifiants et à quoi ils se réfèrent, ainsi la première itération est représentée de la manière suivante :

[code]tc qdisc add dev eth1 root handle 1:0 htb default 1 # Élement racine
tc class add dev eth1 parent 1:0 classid 1:1 htb rate 64kbps # Classe par défaut pour l’élément racine

première boucle

tc class add dev eth1 parent 1:0 classid 1:10 htb rate 100mbps # Groupe d’adresses allant de 172.20.0.1 à 172.20.0.255
tc qdisc add dev eth1 parent 1:10 handle 10:0 htb default 1 # Groupe d’adresses allant de 172.20.0.1 à 172.20.0.255
tc class add dev eth1 parent 10:0 classid 10:1 htb rate 64kbps # Classe par défaut pour ce groupe d’adresse

seconde boucle

tc class add dev eth1 parent 10:0 classid 10:10 htb rate 256kbps buffer 4mb # Classe associée à chaque adresse
tc qdisc add dev eth1 parent 10:10 sfq # Algorithme SFQ

tc filter add dev eth1 parent 1:0 protocol ip prio 1 match dst 172.20.0.1 flowid 1:10
tc filter add dev eth1 parent 10:0 protocol ip prio 1 match dst 172.20.0.1 flowid 10:10[/code]

J’essai d’être clair mais ce n’est pas évident…
Je précise que je fais 2 boucles et que je ne traite pas toutes les adresses d’un coup parce qu’il ne peut pas y avoir un identifiant au dessus de 10000 (du moins Debian me crie dessus quand j’essai), du coup je divise mon réseau de classe B comme si c’était 255 sous réseau de classe C.

Est-ce que quelqu’un peut me dire si c’est une bonne solution, car cela fonctionne mais je n’en suis pas réellement convaincu, je me demande si cela consomme beaucoup de ressources.

Il faut savoir que ce code est dupliqué pour gérer le trafic en UPLOAD sur l’autre interface (eth0), dans mon cas, cela plante pour 255*255 adresses, il bloque après un peu plus de 32000 adresses parcourus avec une erreur venant directement du noyau, puis il freeze.
Si je retire l’algo SFQ, cela passe, mais bon, approcher les limites d’aussi près je ne suis pas très fan :confused:
De plus, est-ce que l’algorithme SFQ apporte une réelle différence ?