Simulate network latency on specific port using tc

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!

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

I've added the all zeros priomap to prio so all regular traffic will flow 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
I then assigned netem to one of the classes - 1:2
Finally, I added your filter, so it will assign 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 it, I changed the filter to dport 80 instead of sport 7000, and connecting to checkip.amazonaws.com took me 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.