ESXI虚拟机下OpenVSwitch与上级网络连接故障的解决

前言

一些场合,我们会需要服务器接入多个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上,做了大量无用功。

 


  请注意,本站的所有文章均要求阁下在转载时注明出处和原作者,阁下转载本站文章即表示阁下同意并遵守此规程,除非特别注明转载出处,否则文章即为其发布者所著。本站及文章作者保留文章的著作权并有权在阁下违反上述规程时予以追究。

本文链接地址: ESXI虚拟机下OpenVSwitch与上级网络连接故障的解决

发表评论

电子邮件地址不会被公开。 必填项已用*标注

*