Simulate network latency on a specific port using tc

Question

I am trying to simulate a fixed time delay on tcp packets coming from source port 7000 using the tc command on ubuntu. The commands I use 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 

It seems that there was no delay caused by this filter, can someone please indicate where I am mistaken? Also, is there a way I can ping a port or do something equivalent to check for delay?

Thanks!

Answer 1

Try the following:

 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 added all priomap zeros to prio so that all normal traffic prio through one lane
  • by default prio assigns traffic for different ranges according to the value of the DSCP packet
  • This means that some traffic that does not match your filter may end up in the same class as pending traffic.
• Then I assigned netem to one of the classes - 1:2
• Finally, I added your filter so that it assigns corresponding packets to the stream identifier 1:2
  • You are likely to be mistaken.
  • You need to assign a 1:2 classical prio qdisc filter, not a classless netem.

To test it, I changed the filter to d port 80 instead of s port 7000, and connecting to checkip.amazonaws.com took me 6 seconds (3 second delay for TCP Syn, 3 second delay for 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 XXXX - 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 (e.g. 443 - HTTPS, 22 - SSH, etc.) were much faster. You can also run sudo tc -s qdisc show dev eth1 to make sure the number of packets processed by netem makes sense.