La respuesta elegida es incorrecta / incompleta. Me enfrenté a un problema similar, la respuesta elegida me ayudó, pero no lo suficiente.
Primero, el siguiente comando no es realmente necesario.
tc qdisc del dev eth0 root
Se 'eliminará' la raíz qdisc, pero inmediatamente se sustituirá por una pfifo_fast (para que no pierda la conectividad).
El segundo comando:
tc qdisc add dev eth0 root handle 1: prio
Sustituirá el qdisc pfifo_fast con el prio. Por defecto, la cola de prio tiene 3 bandas (0, 1, 2) cada una administrada por una clase (1: 1, 1: 2 y 1: 3).
Los paquetes se enviarán a una de esas bandas utilizando el campo TOS del paquete IP. Esta configuración se muestra cuando ejecuta:
tc qdisc ls
mirando los valores de 'priomap'.
Luego, agrega un qdisc netem:
tc qdisc add dev eth0 parent 1: 1 handle 2: netem delay 500ms
Con este comando, retrasará todo el tráfico que vaya a la banda 1: 1 (hasta que el filtro esté en su lugar).
Pero hay dos advertencias:
- Su tráfico puede tener un valor de TOS diferente y luego ser enviado a otra banda.
- El prio qdisc se puede configurar para que el tráfico vaya a otra banda.
Lo siguiente resolvió mi problema para no verse afectado por el netem mientras no se aplica el filtro. En lugar de los pasos anteriores, hice:
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
Esto enviará todo el tráfico por defecto a la banda 1: 3.
Luego, agregué la regla para retrasar el tráfico:
tc qdisc add dev eth0 parent 1: 1 handle 10: netem delay 100ms 10ms
Esto crea el qdisc en la banda 0, pero como todo el tráfico va a la banda 3, no me afectó.
Luego, agregué el filtro:
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
Ahora con el filtro, solo el IP / puerto elegido se verá afectado, ya que redirigimos el tráfico elegido a la banda 0.
El resto del tráfico no se ve afectado ya que continúa fluyendo hacia la banda 3.