# 10 : ICMP
# 20 : domain
# 30 : 3128
# 40 : ssh
# 50 : openvpn/udp vers legendre.public
# 60 : VoIP
# Création de la racine sur eth1. La classe par défaut est
# 1:100.
tc qdisc add dev eth1 root handle 1:0 htb default 100
# Limitation du débit sur le lien eth1
tc class add dev eth1 parent 1:0 classid 1:1 htb \
rate $RATE_ETH1 ceil $MAX_ETH1
# Création des différentes classes
tc class add dev eth1 parent 1:1 classid 1:10 htb \
rate 10kbit ceil $RATE_ETH1
tc class add dev eth1 parent 1:1 classid 1:20 htb \
rate 20kbit ceil $RATE_ETH1
tc class add dev eth1 parent 1:1 classid 1:40 htb \
rate 50kbit ceil $RATE_ETH1
tc class add dev eth1 parent 1:1 classid 1:60 htb \
rate 64kbit ceil 128kbit
tc class add dev eth1 parent 1:1 classid 1:100 htb \
rate 100kbit ceil $RATE_ETH1
tc filter add dev tap1 protocol ip parent 3:0 prio 1 \
handle 60 fw flowid 3:60
# Pas de QoS sur IPv6 pour l'instant
;;
J'ai naturellement vérifié que les paquets étaient bien taggués.
Pour information :
*mangle
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
#
#===============================================================================
# Règles pour la QoS
#===============================================================================
#
[0:0] -A POSTROUTING -p icmp -j MARK --set-mark 10
[0:0] -A POSTROUTING -p udp --sport domain -j MARK --set-mark 20
[0:0] -A POSTROUTING -p udp --dport domain -j MARK --set-mark 20
[0:0] -A POSTROUTING -p tcp --sport domain -j MARK --set-mark 20
[0:0] -A POSTROUTING -p tcp --dport domain -j MARK --set-mark 20
[0:0] -A POSTROUTING -p udp --sport ntp -j MARK --set-mark 20
[0:0] -A POSTROUTING -p udp --dport ntp -j MARK --set-mark 20
[0:0] -A POSTROUTING -p tcp --sport ntp -j MARK --set-mark 20
[0:0] -A POSTROUTING -p tcp --dport ntp -j MARK --set-mark 20
[0:0] -A POSTROUTING -p tcp --sport 3128 -o eth2 -j MARK --set-mark 30
[0:0] -A POSTROUTING -p tcp --sport ssh -o eth1 -j MARK --set-mark 40
[0:0] -A POSTROUTING -p tcp --sport ssh -o eth2 -j MARK --set-mark 40
[0:0] -A POSTROUTING -p udp -d legendre.public.systella.fr --sport
openvpn -o eth2 -j MARK --set-mark 50
[0:0] -A POSTROUTING -d gwvoip.ext.nerim.net -j MARK --set-mark 60
[0:0] -A POSTROUTING -s gwvoip.ext.nerim.net -j MARK --set-mark 60
[0:0] -A POSTROUTING -d 79.170.216.8 -j MARK --set-mark 60
[0:0] -A POSTROUTING -s 79.170.216.8 -j MARK --set-mark 60
[0:0] -A POSTROUTING -d 79.170.216.14 -j MARK --set-mark 60
[0:0] -A POSTROUTING -s 79.170.216.14 -j MARK --set-mark 60
COMMIT
Les règles sur eth1 et eth2 fonctionnement parfaitement. En
revanche, lorsque je fais un sftp sur tap1, le débit est réduit à
128 kbit. Un simple tc qdisc delete dev tap1 root me permet
d'atteindre le débit maximal de la ligne, à savoir 3 Mbit. Je
regarde depuis ce matin les lignes correspondant à tap1 sans voir
l'erreur qui doit être grosse comme une maison. A priori, je
déclarer une règle par défaut 3:300 qui réserve 100kbit et qui peut
aller au débit maximal autorisé et là-dedans, je réserve 64 kbit
(jusqu'à 128 kbit) pour une traffic de VoIP. Rien de bien compliqué.
Une idée ?
Bien cordialement,
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr
tc filter add dev tap1 protocol ip parent 3:0 prio 1 handle 60 fw flowid 3:60
Sous la classe racine (3:0), tu as défini 3 classes: - la classe 3:300 qui est la classe par défaut, - la classe 3:60 qui reçoit le trafic défini par le la directive "tc filter" et est limitée à 128kbit/s - et la classe 3:1 qui ne reçoit rien (aucune directive tc filter")
Ton trafic sftp arrive probablement dans la classe 3:60 qui a une directive ceiling à 128kbit ... débit que tu ne pourras pas dépasser.
tu peux utiliser la commande suivante pour voir ce qui va où:
tc -s class show dev tap1
Il te manque à mon avis un filtre pour faire aboutir le trafic sftp dans la file 3:1, par ailleurs, il te manque peut-être aussi une file d'attente pour celle même classe 3:1, question d'homogénéité avec les deux autres sous-classes.
# Pas de QoS sur IPv6 pour l'instant
Le 04/05/2015 10:58, JKB a écrit :
Bonjour à tous,
Petit problème de QoS qui me fait sécher lamentablement.
Considérons la configuration suivante :
eth0-LAN
eth1-WAN (route par défaut)
eth2-WAN/VPN (tap0 et tap1)
Je cherche à mettre de la QoS sur tout ce beau monde. J'ai donc
écrit le script suivant :
[...]
# QoS sur le VPN tap1
tc qdisc add dev tap1 root handle 3:0 htb default 300
tc class add dev tap1 parent 3:0 classid 3:1 htb
rate 128kbit ceil $RATE_TAP1
tc class add dev tap1 parent 3:1 classid 3:60 htb
rate 64kbit ceil 128kbit
tc class add dev tap1 parent 3:1 classid 3:300 htb
rate 100kbit ceil $RATE_TAP1
tc filter add dev tap1 protocol ip parent 3:0 prio 1
handle 60 fw flowid 3:60
Sous la classe racine (3:0), tu as défini 3 classes:
- la classe 3:300 qui est la classe par défaut,
- la classe 3:60 qui reçoit le trafic défini par le la directive "tc
filter" et est limitée à 128kbit/s
- et la classe 3:1 qui ne reçoit rien (aucune directive tc filter")
Ton trafic sftp arrive probablement dans la classe 3:60 qui a une
directive ceiling à 128kbit ... débit que tu ne pourras pas dépasser.
tu peux utiliser la commande suivante pour voir ce qui va où:
tc -s class show dev tap1
Il te manque à mon avis un filtre pour faire aboutir le trafic sftp dans
la file 3:1, par ailleurs, il te manque peut-être aussi une file
d'attente pour celle même classe 3:1, question d'homogénéité avec les
deux autres sous-classes.
tc filter add dev tap1 protocol ip parent 3:0 prio 1 handle 60 fw flowid 3:60
Sous la classe racine (3:0), tu as défini 3 classes: - la classe 3:300 qui est la classe par défaut, - la classe 3:60 qui reçoit le trafic défini par le la directive "tc filter" et est limitée à 128kbit/s - et la classe 3:1 qui ne reçoit rien (aucune directive tc filter")
Ton trafic sftp arrive probablement dans la classe 3:60 qui a une directive ceiling à 128kbit ... débit que tu ne pourras pas dépasser.
tu peux utiliser la commande suivante pour voir ce qui va où:
tc -s class show dev tap1
Il te manque à mon avis un filtre pour faire aboutir le trafic sftp dans la file 3:1, par ailleurs, il te manque peut-être aussi une file d'attente pour celle même classe 3:1, question d'homogénéité avec les deux autres sous-classes.
# Pas de QoS sur IPv6 pour l'instant
JKB
Le Tue, 05 May 2015 21:28:33 +0200, Denis Corbin écrivait :
Le 04/05/2015 10:58, JKB a écrit :
Bonjour à tous,
Petit problème de QoS qui me fait sécher lamentablement.
Considérons la configuration suivante :
eth0-LAN eth1-WAN (route par défaut) eth2-WAN/VPN (tap0 et tap1)
Je cherche à mettre de la QoS sur tout ce beau monde. J'ai donc écrit le script suivant :
[...]
# QoS sur le VPN tap1 tc qdisc add dev tap1 root handle 3:0 htb default 300 tc class add dev tap1 parent 3:0 classid 3:1 htb rate 128kbit ceil $RATE_TAP1 tc class add dev tap1 parent 3:1 classid 3:60 htb rate 64kbit ceil 128kbit tc class add dev tap1 parent 3:1 classid 3:300 htb rate 100kbit ceil $RATE_TAP1
tc filter add dev tap1 protocol ip parent 3:0 prio 1 handle 60 fw flowid 3:60
Sous la classe racine (3:0), tu as défini 3 classes: - la classe 3:300 qui est la classe par défaut, - la classe 3:60 qui reçoit le trafic défini par le la directive "tc filter" et est limitée à 128kbit/s - et la classe 3:1 qui ne reçoit rien (aucune directive tc filter")
Ton trafic sftp arrive probablement dans la classe 3:60 qui a une directive ceiling à 128kbit ... débit que tu ne pourras pas dépasser.
Eh bien non, d'où mon interrogation. Les seuls paquets qui sont taggués 60 sont :
[0:0] -A POSTROUTING -d gwvoip.ext.nerim.net -j MARK --set-mark 60 [0:0] -A POSTROUTING -s gwvoip.ext.nerim.net -j MARK --set-mark 60 [0:0] -A POSTROUTING -d 79.170.216.8 -j MARK --set-mark 60 [0:0] -A POSTROUTING -s 79.170.216.8 -j MARK --set-mark 60 [0:0] -A POSTROUTING -d 79.170.216.14 -j MARK --set-mark 60 [0:0] -A POSTROUTING -s 79.170.216.14 -j MARK --set-mark 60
Ces serveurs sont des serveurs VoIP.
Le trafic sftp devrait aller gentiment dans la classe par défaut (3:300) et donc occuper le maximum de la bande passante.
tu peux utiliser la commande suivante pour voir ce qui va où:
tc -s class show dev tap1
Il te manque à mon avis un filtre pour faire aboutir le trafic sftp dans la file 3:1, par ailleurs, il te manque peut-être aussi une file d'attente pour celle même classe 3:1, question d'homogénéité avec les deux autres sous-classes.
En fait, je ne veux pas que la classe 3:1 récupère du trafic mais serve juste de support à 3:60 et 3:300. Ce que je ne comprends pas, c'est pourquoi le trafic qui n'est pas taggué n'aterrit pas dans la classe par défaut. Cela fonctionne parfaitement pour eth1 et eth2...
tc filter add dev tap1 protocol ip parent 3:0 prio 1
handle 60 fw flowid 3:60
Sous la classe racine (3:0), tu as défini 3 classes:
- la classe 3:300 qui est la classe par défaut,
- la classe 3:60 qui reçoit le trafic défini par le la directive "tc
filter" et est limitée à 128kbit/s
- et la classe 3:1 qui ne reçoit rien (aucune directive tc filter")
Ton trafic sftp arrive probablement dans la classe 3:60 qui a une
directive ceiling à 128kbit ... débit que tu ne pourras pas dépasser.
Eh bien non, d'où mon interrogation. Les seuls paquets qui sont
taggués 60 sont :
[0:0] -A POSTROUTING -d gwvoip.ext.nerim.net -j MARK --set-mark 60
[0:0] -A POSTROUTING -s gwvoip.ext.nerim.net -j MARK --set-mark 60
[0:0] -A POSTROUTING -d 79.170.216.8 -j MARK --set-mark 60
[0:0] -A POSTROUTING -s 79.170.216.8 -j MARK --set-mark 60
[0:0] -A POSTROUTING -d 79.170.216.14 -j MARK --set-mark 60
[0:0] -A POSTROUTING -s 79.170.216.14 -j MARK --set-mark 60
Ces serveurs sont des serveurs VoIP.
Le trafic sftp devrait aller gentiment dans la classe par défaut
(3:300) et donc occuper le maximum de la bande passante.
tu peux utiliser la commande suivante pour voir ce qui va où:
tc -s class show dev tap1
Il te manque à mon avis un filtre pour faire aboutir le trafic sftp dans
la file 3:1, par ailleurs, il te manque peut-être aussi une file
d'attente pour celle même classe 3:1, question d'homogénéité avec les
deux autres sous-classes.
En fait, je ne veux pas que la classe 3:1 récupère du trafic mais
serve juste de support à 3:60 et 3:300. Ce que je ne comprends pas,
c'est pourquoi le trafic qui n'est pas taggué n'aterrit pas dans la
classe par défaut. Cela fonctionne parfaitement pour eth1 et eth2...
Cordialement,
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr
tc filter add dev tap1 protocol ip parent 3:0 prio 1 handle 60 fw flowid 3:60
Sous la classe racine (3:0), tu as défini 3 classes: - la classe 3:300 qui est la classe par défaut, - la classe 3:60 qui reçoit le trafic défini par le la directive "tc filter" et est limitée à 128kbit/s - et la classe 3:1 qui ne reçoit rien (aucune directive tc filter")
Ton trafic sftp arrive probablement dans la classe 3:60 qui a une directive ceiling à 128kbit ... débit que tu ne pourras pas dépasser.
Eh bien non, d'où mon interrogation. Les seuls paquets qui sont taggués 60 sont :
[0:0] -A POSTROUTING -d gwvoip.ext.nerim.net -j MARK --set-mark 60 [0:0] -A POSTROUTING -s gwvoip.ext.nerim.net -j MARK --set-mark 60 [0:0] -A POSTROUTING -d 79.170.216.8 -j MARK --set-mark 60 [0:0] -A POSTROUTING -s 79.170.216.8 -j MARK --set-mark 60 [0:0] -A POSTROUTING -d 79.170.216.14 -j MARK --set-mark 60 [0:0] -A POSTROUTING -s 79.170.216.14 -j MARK --set-mark 60
Ces serveurs sont des serveurs VoIP.
Le trafic sftp devrait aller gentiment dans la classe par défaut (3:300) et donc occuper le maximum de la bande passante.
tu peux utiliser la commande suivante pour voir ce qui va où:
tc -s class show dev tap1
Il te manque à mon avis un filtre pour faire aboutir le trafic sftp dans la file 3:1, par ailleurs, il te manque peut-être aussi une file d'attente pour celle même classe 3:1, question d'homogénéité avec les deux autres sous-classes.
En fait, je ne veux pas que la classe 3:1 récupère du trafic mais serve juste de support à 3:60 et 3:300. Ce que je ne comprends pas, c'est pourquoi le trafic qui n'est pas taggué n'aterrit pas dans la classe par défaut. Cela fonctionne parfaitement pour eth1 et eth2...
tc filter add dev tap1 protocol ip parent 3:0 prio 1 handle 60 fw flowid 3:60
Sous la classe racine (3:0), tu as défini 3 classes: - la classe 3:300 qui est la classe par défaut, - la classe 3:60 qui reçoit le trafic défini par le la directive "tc filter" et est limitée à 128kbit/s - et la classe 3:1 qui ne reçoit rien (aucune directive tc filter")
Ton trafic sftp arrive probablement dans la classe 3:60 qui a une directive ceiling à 128kbit ... débit que tu ne pourras pas dépasser.
Eh bien non, d'où mon interrogation. Les seuls paquets qui sont taggués 60 sont :
[0:0] -A POSTROUTING -d gwvoip.ext.nerim.net -j MARK --set-mark 60 [0:0] -A POSTROUTING -s gwvoip.ext.nerim.net -j MARK --set-mark 60 [0:0] -A POSTROUTING -d 79.170.216.8 -j MARK --set-mark 60 [0:0] -A POSTROUTING -s 79.170.216.8 -j MARK --set-mark 60 [0:0] -A POSTROUTING -d 79.170.216.14 -j MARK --set-mark 60 [0:0] -A POSTROUTING -s 79.170.216.14 -j MARK --set-mark 60
Ces serveurs sont des serveurs VoIP.
Le trafic sftp devrait aller gentiment dans la classe par défaut (3:300) et donc occuper le maximum de la bande passante.
tu peux utiliser la commande suivante pour voir ce qui va où:
tc -s class show dev tap1
Il te manque à mon avis un filtre pour faire aboutir le trafic sftp dans la file 3:1, par ailleurs, il te manque peut-être aussi une file d'attente pour celle même classe 3:1, question d'homogénéité avec les deux autres sous-classes.
En fait, je ne veux pas que la classe 3:1 récupère du trafic mais serve juste de support à 3:60 et 3:300. Ce que je ne comprends pas, c'est pourquoi le trafic qui n'est pas taggué n'aterrit pas dans la classe par défaut. Cela fonctionne parfaitement pour eth1 et eth2...
Aucun autre avis ? Je viens de reprendre les choses dans tous les sens, je ne vois pas pourquoi tc fonctionne comme cela sur un VPN...
tc filter add dev tap1 protocol ip parent 3:0 prio 1
handle 60 fw flowid 3:60
Sous la classe racine (3:0), tu as défini 3 classes:
- la classe 3:300 qui est la classe par défaut,
- la classe 3:60 qui reçoit le trafic défini par le la directive "tc
filter" et est limitée à 128kbit/s
- et la classe 3:1 qui ne reçoit rien (aucune directive tc filter")
Ton trafic sftp arrive probablement dans la classe 3:60 qui a une
directive ceiling à 128kbit ... débit que tu ne pourras pas dépasser.
Eh bien non, d'où mon interrogation. Les seuls paquets qui sont
taggués 60 sont :
[0:0] -A POSTROUTING -d gwvoip.ext.nerim.net -j MARK --set-mark 60
[0:0] -A POSTROUTING -s gwvoip.ext.nerim.net -j MARK --set-mark 60
[0:0] -A POSTROUTING -d 79.170.216.8 -j MARK --set-mark 60
[0:0] -A POSTROUTING -s 79.170.216.8 -j MARK --set-mark 60
[0:0] -A POSTROUTING -d 79.170.216.14 -j MARK --set-mark 60
[0:0] -A POSTROUTING -s 79.170.216.14 -j MARK --set-mark 60
Ces serveurs sont des serveurs VoIP.
Le trafic sftp devrait aller gentiment dans la classe par défaut
(3:300) et donc occuper le maximum de la bande passante.
tu peux utiliser la commande suivante pour voir ce qui va où:
tc -s class show dev tap1
Il te manque à mon avis un filtre pour faire aboutir le trafic sftp dans
la file 3:1, par ailleurs, il te manque peut-être aussi une file
d'attente pour celle même classe 3:1, question d'homogénéité avec les
deux autres sous-classes.
En fait, je ne veux pas que la classe 3:1 récupère du trafic mais
serve juste de support à 3:60 et 3:300. Ce que je ne comprends pas,
c'est pourquoi le trafic qui n'est pas taggué n'aterrit pas dans la
classe par défaut. Cela fonctionne parfaitement pour eth1 et eth2...
Aucun autre avis ? Je viens de reprendre les choses dans tous les
sens, je ne vois pas pourquoi tc fonctionne comme cela sur un VPN...
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr
tc filter add dev tap1 protocol ip parent 3:0 prio 1 handle 60 fw flowid 3:60
Sous la classe racine (3:0), tu as défini 3 classes: - la classe 3:300 qui est la classe par défaut, - la classe 3:60 qui reçoit le trafic défini par le la directive "tc filter" et est limitée à 128kbit/s - et la classe 3:1 qui ne reçoit rien (aucune directive tc filter")
Ton trafic sftp arrive probablement dans la classe 3:60 qui a une directive ceiling à 128kbit ... débit que tu ne pourras pas dépasser.
Eh bien non, d'où mon interrogation. Les seuls paquets qui sont taggués 60 sont :
[0:0] -A POSTROUTING -d gwvoip.ext.nerim.net -j MARK --set-mark 60 [0:0] -A POSTROUTING -s gwvoip.ext.nerim.net -j MARK --set-mark 60 [0:0] -A POSTROUTING -d 79.170.216.8 -j MARK --set-mark 60 [0:0] -A POSTROUTING -s 79.170.216.8 -j MARK --set-mark 60 [0:0] -A POSTROUTING -d 79.170.216.14 -j MARK --set-mark 60 [0:0] -A POSTROUTING -s 79.170.216.14 -j MARK --set-mark 60
Ces serveurs sont des serveurs VoIP.
Le trafic sftp devrait aller gentiment dans la classe par défaut (3:300) et donc occuper le maximum de la bande passante.
tu peux utiliser la commande suivante pour voir ce qui va où:
tc -s class show dev tap1
Il te manque à mon avis un filtre pour faire aboutir le trafic sftp dans la file 3:1, par ailleurs, il te manque peut-être aussi une file d'attente pour celle même classe 3:1, question d'homogénéité avec les deux autres sous-classes.
En fait, je ne veux pas que la classe 3:1 récupère du trafic mais serve juste de support à 3:60 et 3:300. Ce que je ne comprends pas, c'est pourquoi le trafic qui n'est pas taggué n'aterrit pas dans la classe par défaut. Cela fonctionne parfaitement pour eth1 et eth2...
Aucun autre avis ? Je viens de reprendre les choses dans tous les sens, je ne vois pas pourquoi tc fonctionne comme cela sur un VPN...