[QoS] tc

3 réponses
Avatar
JKB
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 :

RATE_ETH1=1200kbit
MAX_ETH1=1500kbit
RATE_ETH2=3000kbit
MAX_ETH2=3500kbit
RATE_TAP1=3000kbit

# 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

# Discrimination des paquets
tc qdisc add dev eth1 parent 1:10 handle 1:110 pfifo limit 5
tc qdisc add dev eth1 parent 1:20 handle 1:120 pfifo limit 5
tc qdisc add dev eth1 parent 1:40 handle 1:140 pfifo limit 5
tc qdisc add dev eth1 parent 1:60 handle 1:160 pfifo limit 5
tc qdisc add dev eth1 parent 1:100 sfq perturb 10

tc filter add dev eth1 protocol ip parent 1:0 prio 1 \
handle 10 fw flowid 1:10
tc filter add dev eth1 protocol ip parent 1:0 prio 1 \
handle 20 fw flowid 1:20
tc filter add dev eth1 protocol ip parent 1:0 prio 1 \
handle 40 fw flowid 1:40
tc filter add dev eth1 protocol ip parent 1:0 prio 1 \
handle 60 fw flowid 1:60

# Même chose sur eth2
tc qdisc add dev eth2 root handle 2:0 htb default 200
tc class add dev eth2 parent 2:0 classid 2:1 htb \
rate $RATE_ETH2 ceil $MAX_ETH2
tc class add dev eth2 parent 2:1 classid 2:10 htb \
rate 10kbit ceil $RATE_ETH2
tc class add dev eth2 parent 2:1 classid 2:20 htb \
rate 20kbit ceil $RATE_ETH2
tc class add dev eth2 parent 2:1 classid 2:30 htb \
rate 100kbit ceil 512kbit
tc class add dev eth2 parent 2:1 classid 2:40 htb \
rate 50kbit ceil $RATE_ETH2
tc class add dev eth2 parent 2:1 classid 2:50 htb \
rate 128kbit ceil $RATE_ETH2
tc class add dev eth2 parent 2:1 classid 2:200 htb \
rate 100kbit ceil $RATE_ETH2

# Discrimination des paquets
tc qdisc add dev eth2 parent 2:10 handle 2:210 pfifo limit 5
tc qdisc add dev eth2 parent 2:20 handle 2:220 pfifo limit 5
tc qdisc add dev eth2 parent 2:30 handle 2:230 pfifo limit 5
tc qdisc add dev eth2 parent 2:40 handle 2:240 pfifo limit 5
tc qdisc add dev eth2 parent 2:50 handle 2:250 pfifo limit 5
tc qdisc add dev eth2 parent 2:200 sfq perturb 10

tc filter add dev eth2 protocol ip parent 2:0 prio 1 \
handle 10 fw flowid 2:10
tc filter add dev eth2 protocol ip parent 2:0 prio 1 \
handle 20 fw flowid 2:20
tc filter add dev eth2 protocol ip parent 2:0 prio 1 \
handle 30 fw flowid 2:30
tc filter add dev eth2 protocol ip parent 2:0 prio 1 \
handle 40 fw flowid 2:40
tc filter add dev eth2 protocol ip parent 2:0 prio 1 \
handle 50 fw flowid 2:50

# 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 qdisc add dev tap1 parent 3:60 handle 3:360 pfifo limit 5
tc qdisc add dev tap1 parent 3:300 sfq perturb 10

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

3 réponses

Avatar
Denis Corbin
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 qdisc add dev tap1 parent 3:60 handle 3:360 pfifo limit 5
tc qdisc add dev tap1 parent 3:300 sfq perturb 10

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

Avatar
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 qdisc add dev tap1 parent 3:60 handle 3:360 pfifo limit 5
tc qdisc add dev tap1 parent 3:300 sfq perturb 10

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
Avatar
JKB
Le Wed, 6 May 2015 10:13:16 +0000 (UTC),
JKB écrivait :
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 qdisc add dev tap1 parent 3:60 handle 3:360 pfifo limit 5
tc qdisc add dev tap1 parent 3:300 sfq perturb 10

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