Différences entre versions de « QoS »

De Cliss XXI
Sauter à la navigation Sauter à la recherche
imported>SylvainBeucler
imported>SylvainBeucler
 
Ligne 27 : Ligne 27 :
  
 
* La première action est de limiter le traffic pour créer le goulot d'étranglement à notre niveau. On utilise une discipline HTB plutôt qu'un TBF car le HTB peut contenir des classes, donc on a besoin pour continuer le traitement.
 
* La première action est de limiter le traffic pour créer le goulot d'étranglement à notre niveau. On utilise une discipline HTB plutôt qu'un TBF car le HTB peut contenir des classes, donc on a besoin pour continuer le traitement.
* On crée une unique classe qui contient la file d'attente PRIO qui oriente le traffic sur 3 files d'attente en fonction du TOS. À nouveau, on utilise PRIO plutôt que pfifo_fast car PRIO peut contenir des classes.
+
* On crée une unique classe qui contient la file d'attente PRIO qui oriente le traffic sur 3 files d'attente en fonction du TOS. pfifo_fast, qui fait la même chose, ne peut pas être directement utilisé: il est apparemment limité à un rôle de discipline par défaut (<code>qdisc 'pfifo_fast' does not support option parsing</code>). On doit donc utiliser PRIO, qui par ailleurs permet d'utiliser des classes.
 
* 3 classes, une par file d'attente, sont automatiquement crée dans PRIO. Pour chacune, on configure une discipline SFQ. La documentation recommande de changer la méthode de ''hashing'' des sessions TCP-UDP/IP toutes les 10 secondes.
 
* 3 classes, une par file d'attente, sont automatiquement crée dans PRIO. Pour chacune, on configure une discipline SFQ. La documentation recommande de changer la méthode de ''hashing'' des sessions TCP-UDP/IP toutes les 10 secondes.
  

Version actuelle datée du 6 octobre 2009 à 17:03

Principe général

On travaille principalement sur les données émises, par sur les données reçues (dont on ne peut pas contrôler l'ordre d'arrivée).

Gérer le TOS

Pour gérer les TOS (type of service), et donner priorité aux connexions intéractives telles que les sessions SSH, il faut créer un goulot d'étranglement au niveau de notre routeur. On peut ainsi gérer les files d'attente des paquets IP à notre niveau plutôt que de laisser le FAI (mal) le faire.

La première étape est de mesurer le débit ascendant. Ensuite on peut créer le goulot d'étranglement légèrement en dessous et appliquer des règles de priorités qui gèrent le TOS:

# Nettoyage
tc qdisc del dev eth-inet root

# Limitation à 120 kbit/s
tc qdisc add dev eth-inet root handle 1: htb default 1
tc class add dev eth-inet parent 1: classid 1:1 htb rate 120kbit
# Utilisation de la règle d'attente PRIO qui gère le TOS
tc qdisc add dev eth-inet parent 1:1 handle 10: prio

On peut également utiliser des files d'attente SFQ (stochastic fairness queuing, mise en file d'attente stochastiquement équitable) pour éviter qu'une connexion gourmande puisse prendre l'ascendant sur les autres:

tc qdisc add dev eth-inet parent 10:1 sfq perturb 10
tc qdisc add dev eth-inet parent 10:2 sfq perturb 10
tc qdisc add dev eth-inet parent 10:3 sfq perturb 10
  • La première action est de limiter le traffic pour créer le goulot d'étranglement à notre niveau. On utilise une discipline HTB plutôt qu'un TBF car le HTB peut contenir des classes, donc on a besoin pour continuer le traitement.
  • On crée une unique classe qui contient la file d'attente PRIO qui oriente le traffic sur 3 files d'attente en fonction du TOS. pfifo_fast, qui fait la même chose, ne peut pas être directement utilisé: il est apparemment limité à un rôle de discipline par défaut (qdisc 'pfifo_fast' does not support option parsing). On doit donc utiliser PRIO, qui par ailleurs permet d'utiliser des classes.
  • 3 classes, une par file d'attente, sont automatiquement crée dans PRIO. Pour chacune, on configure une discipline SFQ. La documentation recommande de changer la méthode de hashing des sessions TCP-UDP/IP toutes les 10 secondes.

Liens