Simulate network latency on specific port using tc

Question

I'm trying to simulate a fixed time latency on tcp packets coming from source port 7000 using the tc command on ubuntu. The commands I'm using are:

sudo tc qdisc add dev eth1 root handle 1: prio
sudo tc qdisc add dev eth1 parent 1:1 handle 2: netem delay 3000ms
sudo tc filter add dev eth1 parent 1:0 protocol ip u32 match ip sport 7000 0xffff flowid 2:1

There doesn't appear to be any delay caused by this filter, could someone please point out where I'm going wrong? Also, is there any way I can ping a port or do something equivalent to test the latency?

Thanks!

Answer 1

Try this:

sudo tc qdisc add dev eth1 root handle 1: prio priomap 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
sudo tc qdisc add dev eth1 parent 1:2 handle 20: netem delay 3000ms
sudo tc filter add dev eth1 parent 1:0 protocol ip u32 match ip sport 7000 0xffff flowid 1:2

Explanation:

• Add the all zeros priomap to prio so all regular traffic flows through a single band. By default prio assigns traffic to different band according to the DSCP value of the packet. This means that some traffic that doesn't match your filter might end up in the same class as the delayed traffic.
• Assign netem to one of the classes - 1:2
• Finally, add your filter so it assigns the flow id 1:2 to matching packets. This is probably where you went wrong. You need to assign the filter to 1:2 of the classful prio qdisc, not the classless netem.

To test this setup, I changed the filter to dport 80 instead of sport 7000, and ran wget against checkip.amazonaws.com, which took 6 seconds (3 second delay for the TCP Syn, 3 second delay for the HTTP GET):

malt@ubuntu:~$ wget -O - checkip.amazonaws.com
--2016-10-23 06:21:42--  http://checkip.amazonaws.com/
Resolving checkip.amazonaws.com (checkip.amazonaws.com)... 75.101.161.183, 54.235.71.200, 107.20.206.176, ...
Connecting to checkip.amazonaws.com (checkip.amazonaws.com)|75.101.161.183|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 10
Saving to: ‘STDOUT’

-                                   0%[                                                            ]       0  --.-KB/s               X.X.X.X
-                                 100%[===========================================================>]      10  --.-KB/s    in 0s

2016-10-23 06:21:48 (3.58 MB/s) - written to stdout [10/10]

Connections to other ports though (e.g. 443 - HTTPS, 22 - SSH, etc) were much quicker. You can also run sudo tc -s qdisc show dev eth1 to make sure that the number of packets handled by netem makes sense.