为什么环回上的 tc-netem 也会影响其他接口?

为什么环回上的 tc-netem 也会影响其他接口?

我正在尝试修改我的服务器的网络行为,以模拟外部/WAN 连接行为(不管什么意思)。

完成后tc qdisc add dev lo root netem delay 100ms,我可以成功地为来自(和到?)的所有流量添加 100ms 延迟127.0.0.1。例如ping 127.0.0.1将有 200ms 的响应时间。

但是,这也会影响我到其他接口的流量。例如,我有当前服务器上eth1IP地址的接口。如果我这样做,它也会有 100 毫秒的延迟(导致 200 毫秒的响应时间)。192.168.0.1Aping 192.168.0.1

我对这种行为感到困惑。我本以为lo与 无关eth1,但事实似乎并非如此。

我认为这意味着 Linux 内核自动识别192.168.0.1本地地址,并将所有流量(最初到eth1)重新路由到lo

如果是这样,有没有办法禁用这种行为?


背景:

我想模拟外部网络即使服务器上的进程A想要相互通信(当然,通过给定本地地址和端口上的 TCP/IP)也是如此。本质上我想添加延迟eth1,但这超出了这个问题(请参阅我的其他问题)。

我的服务器运行的是 Ubuntu 18.04,但我相信这并不重要。

答案1

不,它不会影响其他接口。但所涉及的路由使得从服务器到自身的任何访问都保持在本地,并且使用lo(环回)接口,无论 IP 地址分配到哪个接口。所以lo受到影响tc ... netem

您可以使用以下命令验证这一点ip route get,该命令将为您的情况提供与此类似的内容:

$ ip route get 192.168.0.1
local 192.168.0.1 dev lo table local src 192.168.0.1 uid 1000 
    cache <local> 

正如你所看到的接口被使用。

没有理由禁用此行为。如果您以某种方式设法将数据包发送到 192.168.0.1,eth1猜猜看:您不会在发送数据包的接口上接收到该数据包,因此该数据包将会丢失。您可以进一步想象整个复杂的设置,包括配置插入的交换机端口eth1以将其收到的流量发送回其发射器,但迟早这将违背实验的初衷,并且实验将不再按预期进行。

为了在处理网络时进行正确的测试,应该始终将本地测试和远程测试分开。如果没有可用的远程系统,则可以使用具有自己独立的完整网络堆栈的其他网络命名空间来模拟。下面是一个示例(不会受到 OP 的影响tc ... netem)。

作为根用户:

ip netns add remote
ip link add name vethtest up type veth peer netns remote name veth0
ip address add 192.0.2.1/24 dev vethtest
ip -n remote link set dev veth0 up
ip -n remote address add 192.0.2.2/24 dev veth0
ip netns exec remote ping 192.0.2.1

有多种方法可以重用原始接口,但这需要对配置进行一些破坏。

相关内容