J'essaie de savoir si la solution de QoS que j'ai intégrée à mon RaspberryPI fonctionne ou non.
J'ai découvert que la classification du trafic par port ne fonctionne pas, j'ai donc essayé de vérifier les filtres utilisés dans la solution de QoS mentionnée sur ma machine Ubuntu.
Voici mon installation factice : (eno1 est une interface Ethernet connectée au Raspberry)
# Root qdisc is prio with 3 bands
sudo tc qdisc add dev eno1 root handle 1: prio bands 3
# Band 1 - port 2323 with low rate, high packet loss probability and big delay
sudo tc qdisc add dev eno1 parent 1:1 netem rate 8kbit delay 500ms loss 0.3% 25%
sudo tc filter add dev eno1 parent 1:0 protocol ip u32 match ip dport 2323 0xffff classid 1:1
sudo tc filter add dev eno1 parent 1:0 protocol ip u32 match ip sport 2323 0xffff classid 1:1
# Band 2 qdisc is tbf and filter is outbound SMTP
sudo tc qdisc add dev eno1 parent 1:2 tbf rate 1mbit buffer 100000 latency 100s
sudo tc filter add dev eno1 parent 1:0 protocol ip u32 match ip dport 25 0xffff classid 1:2
sudo tc filter add dev eno1 parent 1:0 protocol ip u32 match ip sport 25 0xffff classid 1:2
# Band 3 qdisc is sfq and filter is anything unfiltered
sudo tc qdisc add dev eno1 parent 1:3 sfq perturb 16
sudo tc filter add dev eno1 parent 1:0 protocol ip prio 9 u32 match u8 0 0 classid 1:3J'ai limité le débit et ajouté un retard massif pour tout le trafic entrant et sortant du port 2323. Malheureusement, tous les paquets passent par la bande 3 :
hping3 192.168.2.10 -p 25 -c 5
HPING 192.168.2.10 (eno1 192.168.2.10): NO FLAGS are set, 40 headers + 0 data bytes
len=46 ip=192.168.2.10 ttl=64 DF id=0 sport=25 flags=RA seq=0 win=0 rtt=3.8 ms
len=46 ip=192.168.2.10 ttl=64 DF id=0 sport=25 flags=RA seq=1 win=0 rtt=3.7 ms
len=46 ip=192.168.2.10 ttl=64 DF id=0 sport=25 flags=RA seq=2 win=0 rtt=3.5 ms
len=46 ip=192.168.2.10 ttl=64 DF id=0 sport=25 flags=RA seq=3 win=0 rtt=3.2 ms
len=46 ip=192.168.2.10 ttl=64 DF id=0 sport=25 flags=RA seq=4 win=0 rtt=3.1 ms
--- 192.168.2.10 hping statistic ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 3.1/3.5/3.8 ms
tc -s -d qdisc show dev eno1
qdisc prio 1: root refcnt 2 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
Sent 2612 bytes 26 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
qdisc tbf 800d: parent 1:2 rate 1Mbit burst 100000b/1 mpu 0b lat 100.0s linklayer ethernet
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
qdisc netem 800c: parent 1:1 limit 1000 delay 500.0ms loss 0.3% 25% rate 8Kbit
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
qdisc sfq 800e: parent 1:3 limit 127p quantum 1514b depth 127 flows 128/1024 divisor 1024 perturb 16sec
Sent 2612 bytes 26 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0Mais si j'ajoute la règle suivante à iptables, les paquets sont correctement classés :
iptables -t mangle -A POSTROUTING -o eno1 -p tcp --dport 2323 -j CLASSIFY --set-class 1:1Je ne veux pas ajouter plus de résultats tc/hping ici, car cela rendrait ma question trop longue, mais je vois le délai de 500 ms dans les statistiques hping, et les paquets que j'envoie au port 2323 sont affichés dans les statistiques tc.
Quelqu'un pourrait-il m'indiquer où rechercher un problème ? Pourquoi le sélecteur u32 ne fonctionne-t-il pas ?
Merci d'avance.
