修改 OpenStack 中的 Mac 对 VM 的影响

发布时间： 更新时间： 总字数：4317 阅读时间：9m 作者： IP上海 分享 网址

本文介绍在OpenStack中修改VM的IP/MAC对VM网络通信的影响。这里主要分析VM与外部网络之间的通信。在VM之间的通信遇到问题时，也可参考本文进行分析和定位。

准备阶段

  1. 开启OS的iptables
[root@xiexianbin-cn ~]# systemctl enable iptables.service
[root@xiexianbin-cn ~]# systemctl start iptables.service
  1. 安装OpenStack环境，并启动如下网络服务：
[root@xiexianbin-cn ~]# systemctl enable neutron-l3-agent
[root@xiexianbin-cn ~]# systemctl start neutron-l3-agent
[root@xiexianbin-cn ~]# systemctl enable neutron-metadata-agent
[root@xiexianbin-cn ~]# systemctl start neutron-metadata-agent
  1. 熟悉OpenStack网络通信流程

具体参考

  1. 在admin用户下创建flat网络用于VM的floating IP的分配

  2. 创建project1(租户)，且在project1下创建一个user1(用户)，且为user1设置密码。

  3. 使用user1登录dashboard，创建vlan网络用于VM的fixed IP的分配。

  4. 创建router1，使用router1连接flat网络和vlan网络。

  5. 在user1下创建VM且选择vlan网络(即VM被分配fixed ip)。

linuxbridge + Vlan

如上图所示，上图为linuxbridge+ Vlan的网络布局图，VM与外网之前的通信流程以VM01举例说明。

正常通信流程(不修改VM的IP/MAC)

  1. VM01 ping外网host(不分配floating IP给VM01)

结果：通信正常

1> ICMP包从eth0下发到tap01.

2> ICMP包从tap01转发到brqxxxx。

3> brqXXXX将ICMP包转发到eth1.101(brqXXXX根据MAC与端口的绑定信息进行转发)。这里101代表vlan ID，即VM01创建时，选择的vlan网络的ID为101。

4> eth1.101转发ICMP包到实际的物理网络端口设备eth1.其中eth1.101我们可以通过Linux的vconfig命令进行创建的。

5> 到达Neutron node的eth1，直接下发给eth1.101，再到brqxxxx。

6> brqxxxx转发到tapYYY，tapYYY和linux的网络命令空间中的qr-YYY(主要用于neutron-l3-agent服务)是一对veth pair对，所以tapYYY直接将ICMP包转发给qr-YYY。

7> 根据网络命令中间中的iptables rule对ICMP包进行转发，默认情况下(未配置float IP)，所以最终的ICMP包将通过Neutron node中的neutron-l3-agent服务相关的网络命名空间中会根据iptables rule默认被转发到flat网络的网关qg-VVV。例如

-A quantum-l3-agent-snat -s 10.1.0.0/24 -j SNAT --to-source 172.24.4.227

8> 最终到tapVVV，再到brqxxxx，最后被转发到实际的连接外网的物理端口eth0。

9> ICMP包到达外网主机后，ICMP回包将也按原路返回。

  1. 外网host ping VM01(分配floating IP给VM01)

结果：通信正常

注意：外网ping VM01的fixed IP是不可能ping通的，因为他们不在同一个网段。因此这里neutron-l3-agent服务将发挥重要的作用(NAT转换)。

1> 为VM01 分配一个floating IP。

2> 查看neutron-l3-agent服务相关的网络命名空间的iptables rule。

2.1> 列出linux中的所有命令空间：ip netns

2.2> 找出以qrouter开头网络命名空间。如qrouter-afabf77d-ffe4-4ab2-a635-8ad33d58f967。

2.3> 执行如下类似命令查看iptablesrule。

ip netns exec qrouter-afabf77d-ffe4-4ab2-a635-8ad33d58f967 iptables-save

这样将会列出所有的qrouter-afabf77d-ffe4-4ab2-a635-8ad33d58f967命名空间中的iptables rule，包括filter，nat等等。

不过我们这里主要关注nat相关的规则。所以执行

ip netns exec qrouter-afabf77d-ffe4-4ab2-a635-8ad33d58f967 iptables -t nat -L --line-numbers

此时，我们会发现多了3条规则，而这三条规则中的fixed IP和floating IP正好与VM01的fixed IP和floating IP相对应。这3条规则正好是VM01所需的nat转换规则。

-Aquantum-l3-agent-OUTPUT -d 172.24.4.228/32 -j DNAT --to-destination 10.1.0.2
-A quantum-l3-agent-PREROUTING -d 172.24.4.228/32 -j DNAT --to-destination 10.1.0.2
-A quantum-l3-agent-float-snat -s 10.1.0.2/32 -j SNAT--to-source 172.24.4.228

参考http://www.tuicool.com/articles/BR3MNvR

3> 当网络host ping VM01的floating IP时，在Neutron node中的neutron-l3-agent服务相关的网络命名空间中会根据iptables rule对floating IP做DNAT转换，转换成VM01的fixed IP。然后ICMP包再进入brqxxxx。其余的流程与1中的VM01 ping外网host的情况相似。

修改VM的IP/MAC的通信流程

经过测试，发现修改VM的MAC对VM的通信没影响，所以这里我们主要关注对IP的修改情况。下面所述的前提是对VM的IP已做修改，且修改的IP网段与原来的网段相同(如10.1.0.0/24)。

注意：以下三种情况都对VM01的内部IP进行修改后测试的结果。

  1. VM01 ping外网host(不分配floating IP给VM01)

结果：通信正常

由于这里并未对VM01分配floating IP，所以最终的ICMP包将通过Neutron node中的neutron-l3-agent服务相关的网络命名空间中根据iptables rule默认被转发到flat网络的网关qg-VVV。例如

-A quantum-l3-agent-snat -s 10.1.0.0/24 -j SNAT --to-source 172.24.4.227

其余流程与2.1中的情况1相似。主要区别是在这里对VM的IP进行了修改，不过对VM的通信没有影响，因为只要网段位于10.1.0.0/24网段且没有floating IP的VM的流量都会通过172.24.4.227进行转发。

  1. VM01 ping外网host(分配floating IP给VM01)

结果：通信正常

这里为VM01分配了floating IP，此时在Neutron node中的neutron-l3-agent服务相关的网络命名空间中将会生成3条iptables的nat规则。如果修改VM01的fixed IP，则会被3条iptables的nat规则中的一条SNAT规则滤除，从而继续执行下一条规则，最终将被默认被转发到flat网络的网关qg-VVV的nat规则接收。从而通向外部网络。

  1. 外网host ping VM01(分配floating IP给VM01)

结果：通信阻塞

这是因为外网host pingVM01时，必须采用VM01的floating IP进行通信，所以在Neutron node中的neutron-l3-agent服务相关的网络命名空间中将进行DNAT转换，将VM01的floating IP(外网host ping的IP)转换为VM01的fixed IP，然后再向该fixed IP发送ping包，而由于VM01的fixed IP在VM内部被修改了，即VM的内部IP与网络命名空间中的所谓的VM01的fixed IP不同，所以会导致在内部网络中找不到该IP的VM。所以导致ping不通。

解决办法：将Neutron node中的neutron-l3-agent服务相关的网络命名空间中的3条与VM01相关的iptables rule中的DNAT规则进行修改，即修改为VM01的新的内部IP。

OpenvSwitch + Vlan

正常通信流程(不修改VM的IP/MAC)

  1. VM01 ping外网host

结果：通信正常

  1. 外网host ping VM01(分配floating IP给VM01)

结果：通信阻塞

分析：这里是由于securitygroup的iptables rule导致的。默认情况下，OpenStack默认生成的security group rule允许VM ping外部host，但不允许外部host连接到VM内部。这是OpenStack的security group的作用。可参考http://docs.openstack.org/openstack-ops/content/security_groups.html

解决办法：修改securitygroup rule，可在dashboard上直接修改或添加security group rule，也才采用neutron或nova命令进行修改或添加，不过首先需要查看配置文件中采用的哪种security_group_api，如果采用neutron的security_group_api配置，则使用neutron命令进行修改，否则采用nova命令进行修改，不过目前都采用neutron的security_group_api配置。

修改VM的IP/MAC的通信流程

经过测试，发现修改VM的MAC和IP对VM的通信都有影响，所以这里我们会关注对IP和MAC的两种修改情况。

  1. 修改VM01的内部MAC(分配一个floating IP给VM01)
  • VM01 ping 外网host

结果：通信阻塞

分析：这也是由于security group的iptables rule导致的。

解决办法：首先采用3.1节的第2中场景的解决办法，修改security group rule，使正常情况下(VM保持OpenStack分配的IP和MAC)，外网host也能ping通VM01(不修改MAC的情况下)。然后找到VM01所在的Compute Node，在该node上执行iptables –L –-line-number(注意是在linux环境上执行，不是在Neutron Node的网络命名空间上执行)查看filter类别的iptables rule，此时你会发现有VM01的内部IP和原始MAC相对应的一条iptables rule。此时你可以在它前面加一条VM01的内部IP和新MAC相对应的iptables rule，也可以修改现在的这条规则。如果不添加或不修改，最终执行下一条iptables rule是DROP。所以导致了外网host不能ping通VM01。例如，可采用以下格式添加一条VM01的内部IP和新MAC相对应的iptables rule。

iptables -I neutron-clain-name -s 192.168.1.21 -m mac --mac-source XX:XX:XX:XX:XX:XX -j RETURN
  • 外网host ping VM01

结果：通信阻塞

修改VM01的内部IP(分配一个floating IP给VM01)

  • VM01 ping 外网host

结果：通信阻塞

解决办法：首先采用3.1节的第2中场景的解决办法，修改security group rule，使正常情况下(VM保持OpenStack分配的IP和MAC)，外网host也能ping通VM01。然后结合2.2节中修改VM的IP/MAC的通信流程中的第3个场景的解决办法和3.2.1节中的第1种场景的解决办法进行解决。

  • 外网host ping VM01

结果：通信阻塞

修改VM01的内部IP和内部MAC(分配一个floating IP给VM01)

  • VM01 ping 外网host

结果：通信阻塞

分析与解决办法同修改VM01的内部IP(分配一个floating IP给VM01)。

  • 外网host ping VM01

结果：通信阻塞

分析与解决办法同修改VM01的内部IP(分配一个floating IP给VM01)。

最近更新
相关文章
最新评论
Home Archives Categories Tags Statistics
本文总阅读量 次 本站总访问量 次 本站总访客数 人