OpenStack修改IP/MAC对VM通信影响
Posted gj4990
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了OpenStack修改IP/MAC对VM通信影响相关的知识，希望对你有一定的参考价值。
本文介绍在OpenStack中修改VM的IP/MAC对VM网络通信的影响。这里主要分析VM与外部网络之间的通信。在VM之间的通信遇到问题时，也可参考本文进行分析和定位。
1. 准备阶段
1.1 开启OpenStack的网络服务
| [root@jun2 ~]# systemctl enable neutron-l3-agent [root@jun2 ~]# systemctl start neutron-l3-agent [root@jun2 ~]# systemctl enable neutron-metadata-agent [root@jun2 ~]# systemctl start neutron-metadata-agent |
1.2 开启OS的iptables
| systemctl enable iptables.service systemctl start iptables.service |
1.3 熟悉OpenStack网络通信流程
具体参考：http://docs.openstack.org/mitaka/networking-guide/deploy.html
1.4 在admin用户下创建flat网络用于VM的floating IP的分配
1.5 创建project1(租户)，且在project1下创建一个user1(用户)，且为user1设置密码。
1.6 使用user1登录dashboard，创建vlan网络用于VM的fixed IP的分配。
1.7 创建router1，使用router1连接flat网络和vlan网络。
1.8 在user1下创建VM且选择vlan网络(即VM被分配fixed ip)。
2. linuxbridge + Vlan
如上图所示，上图为linuxbridge+ Vlan的网络布局图，VM与外网之前的通信流程以VM01举例说明。
2.1 正常通信流程(不修改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回包将也按原路返回。
2. 外网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-destination10.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的情况相似。
2.2 修改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进行转发。
2. 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规则接收。从而通向外部网络。
3. 外网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。
3. OpenvSwitch + Vlan
3.1 正常通信流程(不修改VM的IP/MAC)
1. VM01 ping外网host
结果：通信正常
2. 外网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配置。
3.2 修改VM的IP/MAC的通信流程
经过测试，发现修改VM的MAC和IP对VM的通信都有影响，所以这里我们会关注对IP和MAC的两种修改情况。
3.2.1 修改VM01的内部MAC(分配一个floating IP给VM01)
1. 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 |
2. 外网host ping VM01
结果：通信阻塞
分析与解决办法同3.2.1节中的第1种场景相同。
3.2.2 修改VM01的内部IP(分配一个floating IP给VM01)
1. VM01 ping 外网host
结果：通信阻塞
分析：结合与2.2节中第3个场景以及3.2.1节中的第1种场景进行分析。
分析：这里阻塞的原因与2.2节中第3个场景的分析原因一样。
解决办法：首先采用3.1节的第2中场景的解决办法，修改security group rule，使正常情况下(VM保持OpenStack分配的IP和MAC)，外网host也能ping通VM01。然后结合2.2节中修改VM的IP/MAC的通信流程中的第3个场景的解决办法和3.2.1节中的第1种场景的解决办法进行解决。
2. 外网host ping VM01
结果：通信阻塞
分析与解决办法同3.2.2节中的第1种场景相同。
3.2.3 修改VM01的内部IP和内部MAC(分配一个floating IP给VM01)
1. VM01 ping 外网host
结果：通信阻塞
分析与解决办法同3.2.2节中的第1种场景相同。
2. 外网host ping VM01
结果：通信阻塞
分析与解决办法同3.2.2节中的第1种场景相同。
以上是关于OpenStack修改IP/MAC对VM通信影响的主要内容，如果未能解决你的问题，请参考以下文章