I have a (Ubuntu 18.04) server with several network interfaces, and one of them is a LAN interface (call it eth1
, on server A
, with IP address 192.168.0.1
). Several servers are on the same LAN.
I would like to add latency between the transmission over that LAN. Surely I can use tc
to manage that, e.g. tc qdisc add dev eth1 root netem delay 100ms
would add 100ms delay to all packets from server A
to server B
(or C
...), and vice versa.
(I also read some other posts using different more complex tc
commands. But I'm new to tc
and do not fully understand their commands. If they are a must, please also give some explanations or pointers as I did not find a man page for tc qdisc
.)
However, if the traffic is from A
to A
itself, this delay will not apply. I'm using that IP 192.168.0.1
in my application, not 127.0.0.1
. This is not my expected behaviour -- I would like such traffic also has the 100ms delay.
I tried to use tc
on lo
interface. It works, and/but changes both using 127.0.0.1
and 192.168.0.1
(this is weird in my understanding). But I'm not fully satisfied by the performance of my application, so would like to only apply latency to those going from/to 192.168.0.1
, to rule out potential problems because of tampering 127.0.0.1
/lo
.
Is there a way to achieve my expected behaviour?
I feel this is equivalent to asking: is there a way to put traffic to a local IP address actually going through the network stack, rather than automatically/transparently re-routing it through lo
?
The latency (of the underlying connection) between different servers (i.e. without using tc
) can be ignored (or assumed to be static), if that is a concern.
I have read Force local IP traffic to an external interface and Route traffic through physical interface (and some other posts, though they are mostly unanswered).
I tried the separate network namespace method, but can not get ping 192.168.0.1
to work (though ping 192.168.0.2
works, where 192.168.0.2
is another server, e.g. B
).
For the iptables method, I do not fully understand what they did, but it seems to be specifically designed for that use case with two network interfaces and an external router, which does not fit into my case.
Surely, my application has a predictable port range. But that is something I'd like to not use, unless a generic mechanism can not be used.