前言

一些场合，我们会需要服务器接入多个VLAN，特别是在虚拟化、容器这类场合。OpenVSwitch就是广为人知的一个软件交换机，支持桥接、VLAN划分等基础功能，甚至还支持诸如OpenFlow之类的高级控制功能。

 

遭遇故障

为了为以后使用开源虚拟化做准备，抽空学习了一下OpenVSwitch。软件交换机不同于硬件交换机，会有一些硬件交换机上没有或不太被提起的概念，不过只是作为二层交换使用的话，配置并不复杂。可是在测试过程中却遇到了一些问题: 虚拟机无法PING通同VLAN中的任何主机，包含网关。通过对OpenVSwitch虚拟网卡VLAN2和VLAN3进行抓包发现虚拟机中的OpenVSwitch下的虚拟网卡发出的ARP查询(ARP Request)可以到达同VLAN中的任何一台主机，被询问的主机也进行了应答，但OpenVSwitch下的虚拟网卡却不能接收到ARP应答(ARP Reply)，另外OpenVSwitch下的虚拟网卡能收同VLAN中其他主机的ARP查询，另外，对虚拟机对外的Trunk网卡ens160进行抓包发现其中包含来自VLAN2和VLAN3的带有标记的ARP查询，但同样没有收到任何应答。写下此文供类似环境下遭遇同样问题的朋友做参考。

 

故障截图

▼虚拟机中OpenVSwitch配置

▼虚拟网卡VLAN2网络配置

▼虚拟机中通过OpenVSwitch虚拟网卡VLAN2 ping 同VLAN下的192.168.2.1不通

▼虚拟机中的操作系统无法解析IP地址到MAC地址

▼对虚拟机中的OpenVSwitch虚拟网卡VLAN2进行抓包，有ARP查询无应答

▼路由器有收到来自虚拟机的ARP查询，并进行了回复

 

测试环境

关于测试环境，为了节省成本，我选择在一台安装有VMWare ESXi的虚拟化平台上安装用于安装测试OpenVSwitch的Ubuntu虚拟机。这套测试环境的网络上层是一台安装有OpenWrt的路由器，该路由器LAN区域下有2个VLAN: VLAN2和VLAN3，对应路由器地址 192.168.2.1/24 和 192.168.3.1/24。在该路由器上设置了一个Trunk接口，该接口流量标记VLAN2和VLAN3。将路由器的Trunk口与ESXi主机相连，随后在ESXi中新建一端口组并设置其VLAN ID为4095 (即VMWare VGT)，安装有OpenVSwitch的Ubuntu虚拟机对外的网卡ens160接入此端口组，此时，相当于Trunk接入了虚拟机的ens160网卡中。随后ens160接入 OpenVSwitch的br0网桥，再于br0上建立虚拟网卡 VLAN2和VLAN3，分别设置IP地址 192.168.2.191/24及 192.168.3.191/24。原本的设想是通过这2张虚拟网卡可与正常与同VLAN、同网段的计算机、虚拟机以及路由器网关通讯、并能通过VLAN2、VLAN3中的任意一张网卡访问互联网，可是遇到了上面的问题。

关于测试环境的架构，如果文字表述难以理解的话，可以参照下图

 

原因

查阅了大量文章、帖子均未解决，直至找到一篇不太显眼的邮件记录[链接]，才解决了问题。

问题原因是VMWare虚拟交换机的网桥中默认禁用了混杂模式，由于虚拟机内实际提供给操作系统做连接使用的是OpenVSwitch下的虚拟网卡VLAN2和VLAN3，两者的MAC地址均不等于虚拟机对外的网卡ens160的MAC地址。这里假设虚拟网卡VLAN2的MAC地址为22:22:22:22:22:22，虚拟网卡VLAN3的MAC地址为33:33:33:33:33:33，虚拟机对外网卡ens160的MAC地址为66:66:66:66:66:66，网关192.168.2.1的地址为DD:DD:DD:DD:DD:DD。当操作系统从虚拟网卡VLAN2向同一VLAN中的主机发送ARP查询时，会附上VLAN2网卡的MAC地址，将查询发送到组播地址中去，类似这样

[22:22:22:22:22:22 发往 FF:FF:FF:FF:FF:FF] ARP查询 谁有 192.168.2.1 的MAC地址，告诉192.168.2.191

于是192.168.2.1收到后知道192.168.2.191的MAC地址是22:22:22:22:22:22，然后向 192.168.2.191 发出回应，类似这样

[DD:DD:DD:DD:DD:DD 发往 22:22:22:22:22:22] ARP应答 192.168.2.1 的MAC地址是 DD:DD:DD:DD:DD:DD

如果 192.168.2.191收到这条应答就会知道 192.168.2.1 的MAC地址，可是问题就出现了，由于ens160到路由器之间的通路实际是串入了一个VMWare的虚拟交换机，而这个交换机默认未开启混杂模式，实际接入VMWare虚拟交换机的是ens160网卡。ens160的MAC地址66:66:66:66:66:66不等于虚拟网卡VLAN2的地址22:22:22:22:22:22，而响应消息是发送给22:22:22:22:22:22这个MAC地址的，可是VMWare虚拟交换机只知道ens160这张网卡的MAC地址，并不知道虚拟机内OpenVSwitch虚拟出的VLAN2这张网卡的MAC地址因此VMWare虚拟交换机丢弃了这条流量，应答流量自然没有流入虚拟机，那么虚拟机里的OpenVSwitch自然也就收不到应答信息，OpenVSwitch下的虚拟网卡VLAN2更不会收到应答信息，这就是故障的原因 (事实上不仅ARP,其他流量只要不是发往组播的都会被丢弃)。至于为什么在虚拟机内的虚拟网卡VLAN2上乃至对外网卡ens160上能够收到VLAN中其他主机的ARP查询是因为ARP查询是发到组播地址上的，组播类似广播不是定向数据流，因此会分发给同VLAN中的任意主机或网卡，不受混杂模式影响。

 

解决

在VMWare的虚拟交换机上开启混杂模式即可(如下图)。

 

▼ESXi开启混杂模式后虚拟机内抓包可看到ARP响应

▼ESXi开启混杂模式后虚拟机可ping同VLAN下的192.168.2.1

▼ESXi开启混杂模式后MAC地址获取正常

 

后记

其实一开始发生问题的时候，我并非没有怀疑过VMWare ESXi的虚拟交换机，当时我将那个设置了 VLAN ID:4095 的端口组接入一台Windows的虚拟机中，随后在该Windows虚拟机中打开设备管理器，将网卡的VLAN ID设置为2，得到了192.168.2.X的地址，ping得到VLAN内的所有主机；再在设备管理器中将网卡的VLAN ID设置为3，得到了192.168.3.X的地址，同样ping得到VLAN内的所有主机。这让我认为问题不在VMWare的设置上，也因此在后续的排故过程中把重心放在OpenVSwitch上，做了大量无用功。

 

---