Home Archives Categories Tags

修改 OpenStack 中的 Mac 对 VM 的影响

发布时间: 更新时间: 总字数:4320 阅读时间:9m 作者: 分享

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

准备阶段

  1. 开启OS的iptables

    [root@xiexianbin-cn ~]# systemctl enable iptables.service
    [root@xiexianbin-cn ~]# systemctl start iptables.service
    
  2. 安装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
    
  3. 熟悉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)

完毕。

最新评论
加载中...