# 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...
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
Le Tue, 05 May 2015 21:28:33 +0200,
Denis Corbin <news@edrusb.is-a-geek.org> é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...
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...
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
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 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
Le Wed, 6 May 2015 10:13:16 +0000 (UTC),
JKB <jkb@koenigsberg.invalid> écrivait :
Le Tue, 05 May 2015 21:28:33 +0200,
Denis Corbin <news@edrusb.is-a-geek.org> é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...
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...
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