linux – 基于Macvlan的界面从主机ping而不是从命名空间ping

概述[编辑] 生产系统目前是混合物理和基于ESXi的系统.我们显然永远不会在预生产环境中使用virtualbox！这里使用它只是为了直接在桌面上快速缩小问题范围. 感谢meta的“暂停”解释！ [/编辑] 我的设置： >专用网络vboxnet1 10.0.7.0/24 > 1台主机,ubuntu桌面 > 1个VM,ubuntu服务器(VirtualBox) 贴图布局： >主持人：10.0.7.1 > [编辑]

生产系统目前是混合物理和基于ESXi的系统.我们显然永远不会在预生产环境中使用virtualBox！这里使用它只是为了直接在桌面上快速缩小问题范围.

感谢Meta的“暂停”解释！

[/编辑]

我的设置：

>专用网络vBoxnet1 10.0.7.0/24
> 1台主机,ubuntu桌面
> 1个VM,ubuntu服务器(VirtualBox)

贴图布局：

>主持人：10.0.7.1
> VM：10.0.7.101
> VM MAC nameSPACE：10.0.7.102

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

ip netns add mac                        # create a new nmespaceip link add link eth0 mac0 type macvlan # create a new macvlan interfaceip link set mac0 netns mac

在mac命名空间中,在VM内部：

ip link set lo upip link set mac upip 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 | | || | |                | | || | +----------------+ | || +--------------------+ |+------------------------+

什么有效：

>在主机和VM之间进行Ping
> NS和NS之间的Ping
>来自NS的dhclIEnt

什么行不通：

>在NS和VM之间Ping
>在NS和主机之间Ping

我开始疯狂的地方：

> tcpdump on host(真机)实际显示ARP请求和回复
> NS上的tcpdump显示发送到主机的ARP请求
> VM上的tcpdump使整个混乱工作(！) – >在VM上启动tcpdump时Ping开始获得答案？！？

所以,我敢打赌你渴望它,我的问题是：如何让它发挥作用？我怀疑在NS内部的macvlan上ARP有什么问题,但无法弄清楚到底是什么……

顺便说一下,我直接在VM(没有名称空间)上使用mac0接口进行了相同的表达,并且它运行良好.

解决方法 好吧,对于子孙后代,tcpdump使所有突然工作的事实应该让我走上正轨.它内部的作用是将eth0切换到混杂模式.也就是说,eth0将产生所有网络流量,而不仅仅是服务器主MAC的流量

但是,这正是macvlan的工作原理：它添加了一个新的辅助虚拟MAC地址,即“物理”(即VM)网络适配器不知道.

所以简单的解决方法是手动：ifconfig eth0 promisc

我希望它有所帮助！

总结

以上是内存溢出为你收集整理的linux – 基于Macvlan的界面从主机ping而不是从命名空间ping全部内容，希望文章能够帮你解决linux – 基于Macvlan的界面从主机ping而不是从命名空间ping所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。