关于OpenStack搭建过程中的网络问题

Posted 2023-04-27

参考技术A 用两台 Linux7 服务器（双网卡）搭建OpenStack，网络拓扑表如下。

给服务器其中一块网卡配置网关，另一块不设置网关，则一块能通，另一块不能通。

最终这个问题并没有解决，但是我选择忽视问题继续搭建平台，最终成功给虚机分配200网段的浮动IP，发现获取到IP的虚机可以ping通。于是这个问题被暂时放下了。

这个问题折腾了我整整一天时间，期间试过了我能试的所有办法，对交换机的操作和各种路由的配置也更加熟练，虽然最终并没有解决，但却在这个排错的过程中，令我思考颇多。说到底这个问题就是双网卡双网关，多vlan通信问题。但变数太多，知识尚浅，无法解决，只能再继续研究网络知识了。

VCenter中嵌套openstack VM不能ping通外部网络问题解决的方法

问题描写叙述：

近期搭建了vCenter环境，并使用vCenter创建的VM搭建了一套openstack环境。在验证openstack的外网功能时。发现报文死活ping不通外网，抓包发现报文在vcenter的dvs处给丢掉了，这是很奇怪的事情。细致排查后。现vCenter居然感知报文的mac对于不受vCenter管理的VM发出的报文直接忽视。

先上图：

 

解释例如以下：

1）ESX-B016是安装了VMWare ESX的主机，受vCenter管理和控制。我使用vCenter创建一个虚拟分布式交换机（dvs01），使用ESX-B016主机的eth2作为这个交换机的上行口（可能有人会问，为什么用eth2作为上行口，这个由于eth0和eth1被别人占用了：））。ESX-B016     的eth2网卡连接到外部物理交换机switch1的g1口。然后通过交换机的g3口连接到了物理网关路由器Rrouter1上；物理网关路由器的IP为162.3.110.1。

2）使用vCenter在ESX-B016主机上创建了一个VM（虚拟机名称为OpenStack_VM），用来安装OpenStack环境，这个VM的网卡eth0连接到dvs01的port组dVPort1上；

3） 在OpenStack环境上。我创建了租户网络（net1：192.168.0.0/24）、虚拟机（user_vm），路由器（R），将net1关联到router上，并创建了网络（ext1:162.3.0.0/16）作为外部网络

4） 创建的ext外部网络是vlan类型，vlanid设置为1000。 dVPort1port组为vlan中继。同意2-4094通过，同一时候g1设置为trunk口。g2设置为access口，仅仅同意vlan 1000通过.

一起就绪后。我进入user_vm虚拟机中运行ping 162.3.110.1操作，理论上应该可以ping通网关，可是奇怪的是怎么也不通。

定位过程

好吧，仅仅能祭出抓包的利器tcpdump，首先看一下报文的传输路线：user_vm -> br-int ->R -> snat -> br-int -> br-eth0 -> eth0 -> dvs01 -> uplink口（eth2）->  g1 –> g3 -> Router1,

1） 第一步我在User_VM运行ping 162.3.110.1

2） 首先确定ping报文是否发出去了，在user_vm虚拟机的eth0上抓包。发现可以抓到通往162.3.110.1的ICMP请求报文。但没有响应；

3） 在R上抓包。也能抓到通往162.3.110.1的ICMP请求报文。但没有响应；

4） 在eth0口抓包，相同能抓到通往162.3.110.1的ICMP请求报文，但没有响应，说明报文已经从openstack_VM虚拟机中发出去了，进入了dvs01分布式交换机；

5） 分布式交换机dvs01通过上行口送给了物理交换机switch1的g1口，我在switch1上运行displaymac-address | include GE0/0/1命令，监控全部经过g1口的报文。没有发现源mac地址为snat的外网口mac的不论什么报文（这里为何是外网口的源mac。不明确的同学能够细致思考下），这说明报文没有如期送到switch1中。难道经过dvs01时凭空消失了？

 

解决的方法：

经过查资料，发现原来的确是被dvs01丢失了。这是由于port组的配置导致的，将OpenStack_VM相应的port组配置改动例如以下就可以解决这个问题：

   根本原因在于，我们使用openstack创建的snat上面的外网口对dvs01来说是不被承认的， 假设将伪传输设置为拒绝的话， ESX会将正在传输的报文mac和全部适配上有效的mac进行比对，发现有不一致的报文会进行丢弃。

这里何谓有效？肯定是ESX自己分配的mac地址是有效的，而openstack分配的mac地址ESX感知不到，也因此觉得是无效的。

附加资料：

以下是VMware官方文档对混杂模式和伪传输的描写叙述：

Promiscuous Mode（混杂模式）：

混杂模式控制虚拟机能否够查看 ESX 主机上其它节点的单播通信量。

默认情况下，此选项设置为 [Reject（拒绝）]，这意味着虚拟网络适配器在混杂模式下无法执行。在混杂模式中，虚拟网络适配器无需执行不论什么接收过滤。因此客户操作系统可接收线路上观察到的全部通信量。

虽然混杂模式能够有效跟踪网络活动，但这样的执行模式极不安全，由于不管某些数据包是否仅仅能由特定的网络适配器接收，在混杂模式中全部适配器都可訪问这类数据包。

这意味着虚拟机中的管理员或 Root 用户能够查看传输至其它客户机或主机操作系统的通信量。  

虽然最经常使用的混杂模式应当处于关闭状态，但假设正在执行网络入侵检測软件或数据包port扫描器。那么也可将虚拟交换机配置为在混杂模式中执行。

 

Forged Transmits（伪传输）：  

伪传输将影响出站通信量。默认情况下，此选项设置为 [Accept（接受）]，这意味着 ESX 主机不会将源 MAC 地址与有效 MAC 地址进行比較。假设将此选项设置为 [Reject（拒绝）]，ESX 主机会将操作系统正在传输的源 MAC 地址与其适配器的有效 MAC 地址进行比較。查看它们是否匹配。假设地址不匹配，ESX 会丢弃此数据包。客户操作系统不会检測到其虚拟网络适配器无法使用模拟的 MAC 地址发送数据包。

ESX 主机将在不论什么使用模拟地址传递数据包传输之前将其截获。因此，客户操作系统可能会假设数据包已被丢弃。