☰

同一命名空间中的 veth 设备没有 ICMP 响应

tag-icon • tag-icon networking veth
同一命名空间中的 veth 设备没有 ICMP 响应

我在 Ubuntu 16.04 中创建了一个 veth 设备对，如下所示：

$ sudo ip link add veth1 type veth peer name veth2
$ sudo ip link set dev veth1 up
$ sudo ip link set dev veth2 up
$ sudo ip address add 10.0.10.50/24 dev veth1
$ sudo ip address add 10.0.10.51/24 dev veth2

veth 设备对位于同一命名空间中。我正在尝试测试从一台 veth 设备到另一台设备的 ping 操作。所以我尝试如下 ping：

$ ping -I veth1 10.0.10.51
PING 10.0.10.51 (10.0.10.51) from 10.0.10.50 veth1: 56(84) bytes of data.
From 10.0.10.50 icmp_seq=1 Destination Host Unreachable
From 10.0.10.50 icmp_seq=2 Destination Host Unreachable
From 10.0.10.50 icmp_seq=3 Destination Host Unreachable

当我检查 veth2 的wireshark跟踪时，ARP请求没有得到任何响应（veth1也观察到类似的跟踪）：

 Broadcast  ARP 42  Who has 10.0.10.51? Tell 10.0.10.50

我想问为什么 veth2 与 veth1 处于同一命名空间时无法响应 ICMP 请求？

更新：如果我按如下方式尝试 ping，则会收到 ICMP 响应，但wireshark 没有显示 veth1 和 veth2 设备的跟踪信息。

 $ ping -I 10.0.10.50 10.0.10.51
 PING 10.0.10.51 (10.0.10.51) from 10.0.10.50 : 56(84) bytes of data.
 64 bytes from 10.0.10.51: icmp_seq=1 ttl=64 time=0.016 ms
 64 bytes from 10.0.10.51: icmp_seq=2 ttl=64 time=0.022 ms

有人可以解释一下两次 ping 测试结果的差异吗？

答案1

部分答案：

对于第二种变体，执行 a tcpdump -ni lo（或使用 Wireshark），您将看到通信发生在环回接口上。这是因为内核注意到这两个地址都是本地地址，因此使用环回接口，无论这些地址分配给哪个接口。

对于第一个变体，我不太确定为什么广播没有得到答复，但一般来说，内核会将从一个接口发出并出现在另一个接口上的通信视为路由错误，并抑制它。广播可能会通过，因为它是广播。

通过相当大的努力，您可以对其进行调整以允许回旋镖平，但这通常不是特别有用。

虚拟 eth 对只有在使用它们连接不同的网络命名空间时才有意义。按照您设置它们的方式，它们就像在同一 LAN 网段上拥有两个不同的物理以太网卡一样无用。

相关内容