来自主机但不来自名称空间的基于Macvlan的接口ping

[编辑]

生产系统当前是基于物理和ESXi的混合系统。显然，即使在预生产环境中，我们也绝对不会使用virtualbox！它仅在此处用于直接在我的桌面上快速缩小问题范围。

感谢您对meta的“保留”的解释！

[/编辑]

我的设置：

1. 专用网络vboxnet110.0.7.0/24
2. 1个主机，ubuntu桌面
3. 1个VM，Ubuntu服务器（VirtualBox）

地址布局：

1. 主机：10.7.0.1
2. 虚拟机：10.0.7.101
3. VM MAC名称空间：10.0.7.102

在上VM，我运行了以下命令：

ip netns add mac                        # create a new nmespace
ip link add link eth0 mac0 type macvlan # create a new macvlan interface
ip link set mac0 netns mac

在mac名称空间中，在VM内部：

ip link set lo up
ip link set mac up
ip addr add 10.0.7.102/24 dev mac0

这样，我们基本上可以得出以下结论：（例如Inception？）

+------------------------+
| Host: 10.0.7.1         |
|                        |
| +--------------------+ |
| | VM: 10.0.7.101     | |
| |                    | |
| | +----------------+ | |
| | | NS: 10.0.7.102 | | |
| | |                | | |
| | +----------------+ | |
| +--------------------+ |
+------------------------+

什么有效：

• 平之间Host和VM
• 平之间NS和NS
• dhclient来自 NS

什么不起作用：

• 平之间NS和VM
• 平之间NS和Host

我开始发疯的地方：

• host（在真实计算机上）的tcpdump 实际上显示了ARP请求和答复
• tcpdump on NS显示发送到主机的ARP请求
• tcpdump on VM使整个混乱工作（！）->在VM上启动tcpdump时，ping开始获取答案了！

所以，我敢打赌，您渴望它，我的问题是：我该如何使其工作？我怀疑NS内macvlan上的ARP出了点问题，但无法弄清楚到底是什么...

顺便说一句，我对mac0直接在VM上的接口（没有名称空间）进行了相同的实验，并且可以完美地工作。

好了，因此，对于后代来说，tcpdump使所有突然的工作正常的事实应该使我步入正轨。它在内部所做的是切换eth0到混杂模式。也就是说，eth0将产生所有的网络流量，而不仅仅是与服务器主MAC

但是，这恰好是这样macvlan工作的：它添加了一个新的辅助虚拟MAC地址，“物理”（即VM）网络适配器不知道该地址。

因此，简单的解决方法是手动： ifconfig eth0 promisc

希望对您有所帮助！