Bonjour,
Je souhaite mettre en place des regles qos pour ma passerelle linux en download et en upload pour eviter la surchage de ma bande passante.
Donc je suis sur une debian 8 avec deux interface réseaux :
(192.168.0.0/24 )Internet--------------eth0 (debian) eth1 ---------------- Switch AP -------------- LAN (192.168.1.0/24)
J’ai commencer a me documenter mais les doc sont pas tres claire .
Quelqu’ un pourrais t il m’aider svp ?
Bonjour,
Tu n’as pas vraiment tord de dire que la documentation sur ce sujet est problématique.
Outre des informations manquantes, elle contient parfois de grosses erreurs.
Dans un monde idéal, j’aurais pu trouver le temps de prendre l’initiative de corriger les documentations. Hélas …
Est-ce que tu peux nous montrer ce que tu as commencé à faire ? Nous décrire un peu plus précisément ce sur quoi tu butes ?
Sinon, il y a quelques bases à connaître sur la QoS :
Le “trafic policing” consiste à dégager (“drop” en anglais) des paquets d’une connexion, d’un trafic que l’on juge trop élevé. Cela influence principalement le débit d’un trafic.
Le “trafic shaping” consiste à mettre en mémoire tampon (“buffer” en anglais) des paquets d’un trafic que l’on ne peut pas envoyer immédiatement. Cela influence principalement la latence d’un trafic.
Si l’on regarde les différents types de trafic définis dans le standard IEEE 802.1p pour de la QoS au niveau d’Ethernet, on voit que certains trafic ont plus besoin d’un débit élevé alors que d’autres types ont plus besoin d’une latence faible et que d’autres types ont besoin des deux ou encore d’aucun.
Toutes les technologies de type DSL comme ADSL ou VDSL sont assez sensibles, électroniquement parlant, et subissent souvent des erreurs de transmission. Pour contrer cela existe l’entrelacement (“interleave” en anglais) et le Forward Error Correction (FEC).
Seule la combinaison des deux techniques permet de corriger les erreurs dans la transmission *DSL sans avoir à faire retransmettre les données de bout en bout.
Or, l’entrelacement nécessite d’avoir de la mémoire tampon. Et avoir de la mémoire tampon sans trafic shaping amène de gros problèmes de latence dès lors que le trafic potentiel dépasse le trafic possible. Un phénomène appelé bufferbloat en anglais.
Free.fr permet d’activer différents niveaux d’entrelacement mais ce n’est pas le sujet principal.
Si on ne connait pas le débit maximal possible, on ne peut assigner une quantité absolue de bande passante à tel type de trafic. Donc, même s’il existe un projet sous Linux permettant de s’affranchir éventuellement de cette limite, la QoS n’est effectivement applicable qu’à la condition d’avoir une garantie de débit.
En conséquence, sur les liaisons radio comme 4G et WiFi on oublie. Et sur les liens *DSL, on utilise un débit maximal égal à 85 ou 90% du débit maximal histoire de ne pas avoir à modifier manuellement les valeurs tous les quatre matins.
En émission, le trafic policing et trafic shaping sont possibles. En réception, seul le trafic policing est éventuellement utile, pour les cas où il y a une gestion de la congestion comme pour les connexions TCP.
Même une fois que l’on a mis en place des classes de trafic, il peut falloir un traitement équitable des différents flux qui se rangent dans telle ou telle classe.
Par exemple, dans la classe qui regroupe les connexions HTTP et HTTPS, que les flux de l’adresse IP X soient traités de manière équitable par rapport aux flux de l’adresse IP Y.
Sinon, on peut imaginer que les 400 connexions web de l’IP X obtiennent un débit quadruple par rapport aux 100 connexions web de l’IP Y.
Faire de la QoS nécessite plus de puissance de calcul sur le routeur. Les performances d’un routeur s’expriment en nombre maximum de Paquets routés Par Seconde (PPS). Activer de la QoS fait diminuer ce nombre.
Parfois, c’est cette valeur qui pose problème.
–
AnonymousCoward
Merci pour cette info.
Mon but est de creer des regles de priorite sur les differents services pour eviter la saturation. Voici mon projet :
Ma debian sert de passerelle sur mon reseau comme dit plus haut.
eth0 est connecte a ma box adsl 1M/21M
eth1 interface lan sur switch gigaethernet
Utiliser le qos pour faire des priorites sur les services dns icmp http https ftp etc… et le reste est utiliser les autres.
Mais le probleme c’est que selon les differents documentation je pourrais controler le upload et non le download c’est pour cela que je fait appel a vous pour vos lumieres.
Voir le point n°6 de ma première réponse.
Concernant une connexion ADSL, ce n’est pas la peine de t’occuper du débit descendant.
Pas avant d’avoir maîtrisé la QoS pour le débit montant.
Tu peux commencer avec la traduction en français de la documentation du LARTC. Choisir la version avec HTB plutôt que la version obsolète avec CBQ.
–
AnonymousCoward
Bonjour,
Suite a ta réponse je me suis documenté et j’ai mis en place un petit script le voici :
tc qdisc del dev eth0 root
tc qdisc add dev eth0 root handle 1: htb default 100
tc class add dev eth0 parent 1: classid 1:1 htb rate 100kbps ceil 100kbps
tc class add dev eth0 parent 1:1 classid 1:10 htb rate 30kbps ceil 100kbps
tc class add dev eth0 parent 1:1 classid 1:11 htb rate 10kbps ceil 100kbps
tc class add dev eth0 parent 1:1 classid 1:12 htb rate 60kbps ceil 100kbps
tc filter add dev eth0 parent 1: protocol ip prio 1 handle 10 fw classid 1:10
tc filter add dev eth0 parent 1: protocol ip prio 2 handle 11 fw classid 1:11
tc filter add dev eth0 parent 1: protocol ip prio 3 handle 12 fw classid 1:12
Le problème j’ai toujours pas de limitation du upload ou du download.
Une idée ?
Bonjour,
Si je reprends la première ligne concernant les filtres, sur ton script, tu écris cela :
tc filter add dev eth0 parent 1: protocol ip prio 1 handle 10 fw classid 1:10
Il faudrait modifier cette ligne en remplaçant classid par flowid . De même pour les 2 lignes suivantes.
tc filter add dev eth0 parent 1: protocol ip prio 1 handle 10 fw flowid 1:10
Ensuite, la première ligne du second paragraphe, tu écris default 100 , ce qui signifie que le trafic, par défaut, se retrouve dans la classe 1:100 , qui n’existe pas.
Il faudrait que cela envoie plutôt vers une classe existante telle que 1:10, 1:11 ou 1:12 .
Après, tu n’ajoutes pas de qdisc en-dessous des classes 1:10 … 1:12 alors que c’est conseillé (par exemple par le documentation du LARTC) :
tc qdisc add dev eth0 parent 1:10 handle 10: sfq perturb 10
tc qdisc add dev eth0 parent 1:11 handle 11: sfq perturb 10
tc qdisc add dev eth0 parent 1:12 handle 12: sfq perturb 10
Pour terminer, il pourrait être intéressant de voir comment tu appliques les marques 10, 11, 12 au niveau de iptables. Avec la commande :
sudo iptables --line-numbers -nvx -t mangle -L
Le débit descendant, ce n’est pas la peine d’y toucher avant que la QoS sur le débit montant ne soit pleinement maîtrisée.
–
AnonymousCoward
Salut,
J’ai pris en consideration tes remarques et j’ai corriger mes lignes.
iptables -t mangle -A POSTROUTING -o $NET_INTERFACE -p udp -m multiport --dport 53,123 -j MARK --set-mark 10
iptables -t mangle -A POSTROUTING -o $NET_INTERFACE -p tcp --dport 22 -j MARK --set-mark 11
iptables -t mangle -A POSTROUTING -o $NET_INTERFACE -p tcp -m multiport --dport 80,443,20:21,22,25,465,110,993 -j MARK --set-mark 12
tc qdisc del dev eth0 root
tc qdisc add dev eth0 root handle 1: htb default 20
tc class add dev eth0 parent 1: classid 1:1 htb rate 100kbps ceil 100kbps
tc class add dev eth0 parent 1:1 classid 1:10 htb rate 20kbps ceil 100kbps
tc class add dev eth0 parent 1:1 classid 1:11 htb rate 20kbps ceil 100kbps
tc class add dev eth0 parent 1:1 classid 1:12 htb rate 60kbps ceil 100kbps
tc class add dev eth0 parent 1:1 classid 1:20 htb rate 60kbps ceil 100kbps
tc qdisc add dev eth0 parent 1:10 handle 10: sfq perturb 10
tc qdisc add dev eth0 parent 1:11 handle 11: sfq perturb 10
tc qdisc add dev eth0 parent 1:12 handle 12: sfq perturb 10
tc filter add dev eth0 parent 1: protocol ip prio 1 handle 10 fw flowid 1:10
tc filter add dev eth0 parent 1: protocol ip prio 2 handle 11 fw flowid 1:11
tc filter add dev eth0 parent 1: protocol ip prio 3 handle 12 fw flowid 1:12