3

I am setting up a virtual network using macvlans and I have connected traffic-control tc to each of them. I set the delay for each as 90ms. But on ping I get the time of 0.02 seconds. Why is tc not working on macvlan?

I am using the following commands:

tc qdisc add dev m1 root netem delay 90ms
tc qdisc add dev m2 root netem delay 90ms

and then ping from ip of m1 to ip of m2. m1 and m2 are macvlans.

1 Answers1

2

Your issue is related to how routing is done, not to tc, netem or macvlan.

When reaching from an IP address belonging to the host an other IP address belonging to the host, the route uses the lo (loopback) interface, by consulting the local routing table (hidden, try ip route show table local) and never uses the actual interfaces where the IP addresses were assigned to.

You can verify this by asking to the kernel the route it will choose. For example if the addresses on m1 and m2 were 192.0.2.2/24 and 192.0.2.3/24:

# ip route get from 192.0.2.2 to 192.0.2.3
local 192.0.2.3 from 192.0.2.2 dev lo table local uid 0 
    cache <local> 

If you need to do tests with those interfaces, then you need an other system with its own routing stack to test them with. This system could be a real host, a VM, a container or simply using an (or multiple) additional(s) network namespace(s), like you probably started doing.

In my hypothetical case above, if 192.0.2.1 was in m1's LAN (and the m2 interface was kept down to avoid possible unrelated ARP issues), ping 192.0.2.1 would show the delay, because m1 would be used:

# ip route get from 192.0.2.2 192.0.2.1
192.0.2.1 from 192.0.2.2 dev m1 uid 0 
    cache 

The very first ping would usually take twice the delay penalty because there's also an ARP request done before to resolve the IP link, which gets also delayed.

A.B
  • 31,762
  • 2
  • 62
  • 101