Solution 1 :
La réponse choisie est incorrecte/incomplète. J'ai rencontré un problème similaire, la réponse choisie m'a aidé, mais pas assez.
Tout d'abord, la commande suivante n'est pas vraiment nécessaire.
tc qdisc dev racine eth0
Il 'supprimera' le gestionnaire de mise en file d'attente racine, mais sera immédiatement remplacé par un gestionnaire pfifo_fast (afin que vous ne perdiez pas la connectivité).
La deuxième commande :
tc qdisc add dev eth0 root handle 1 :prio
Remplacera le qdisc pfifo_fast par le prio one. Par défaut, la file d'attente a 3 bandes (0, 1, 2) gérées chacune par une classe (1:1, 1:2 et 1:3).
Les paquets seront envoyés à l'une de ces bandes en utilisant le champ TOS du package IP. Cette configuration s'affiche lorsque vous exécutez :
tc qdisc ls
en regardant les valeurs 'priomap'.
Ensuite, vous ajoutez un qdisc netem :
tc qdisc add dev eth0 parent 1:1 handle 2 :délai netem 500 ms
Avec cette commande, vous retardez tout le trafic allant vers la bande 1:1 (jusqu'à ce que le filtre soit en place).
Mais il y a deux mises en garde :
- Votre trafic peut avoir une valeur TOS différente et être ensuite envoyé vers une autre bande.
- Le qdisc prio peut être configuré pour que le trafic passe sur une autre bande.
Ce qui suit a résolu mon problème pour ne pas être affecté par le netem tant que le filtre n'est pas appliqué. Au lieu des étapes ci-dessus, j'ai fait :
tc qdisc add dev eth0 root handle 1:prio priomap 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
Cela enverra tout le trafic par défaut sur la bande 1:3.
Ensuite, j'ai ajouté la règle pour retarder le trafic :
tc qdisc add dev eth0 parent 1:1 handle 10 :netem delay 100ms 10ms
Cela crée le qdisc dans la bande 0, mais comme tout le trafic passe sur la bande 3, cela ne m'a pas affecté.
Ensuite, j'ai ajouté le filtre :
tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip dst 10.0.0.1/32 match ip dport 80 0xffff flowid 1:1
Maintenant avec le filtre, seul l'IP/port choisi sera affecté, puisque nous redirigeons le trafic choisi vers la bande 0.
Tout le reste du trafic n'est pas affecté puisqu'il continue d'être acheminé vers la bande 3.
Solution 2 :
Ok, j'ai résolu mon propre problème. Il s'avère que si vous exécutez les 3 premières lignes ci-dessus (celles "tc qdisc"), cela retardera tous les paquets car il n'y a pas encore de filtres. La 4ème ligne le modifie pour ne retarder que les paquets provenant de cette adresse IP unique. Des lignes de filtre supplémentaires peuvent être ajoutées pour ajouter des adresses IP supplémentaires à la liste "différée". Donc :ne créez pas de ligne "netem delay" sans qu'un filtre ne pointe dessus.