昨天我们的测试人员提了个bug，具体操作是这样的：
1. 新建VM（通过DHCP分配IP）
2. 绑定公网IP，通过公网IP，ssh登录之后，删除该VM。
3. 再新建VM，手动分配IP，IP使用步骤1中的内网IP。
4. 再绑定公网IP后，ssh验证，无法连接。
随后进行了复现：
虚拟机的ip和mac地址：
192.168.10.2 fa:16:3e:33:8e:7c
删除虚拟机后，重新创建，获取到的mac地址：
fa:16:3e:be:1a:3e
在虚拟机内ping网关IP，发现ping不通。
在虚拟机所在的tap设备上，tcpdump分析，发现有icmp request和reply。
但这只是一种假象，随即对抓包分析：
发现请求的mac地址和回复的mac地址不一致：
图1：
虚拟机发送请求时，源mac是新的mac地址
图2：
回复时，目的mac是旧的mac地址
因此，数据包无法进入虚拟机，在虚拟机里面ping无显示。
因此，数据包无法进入虚拟机，在虚拟机里面ping无显示。
之后检查网络节点和计算节点的arp表，发现一切正常。
把问题定位到qrouter的命名空间中，查看命名空间的arp表，发现关于192.168.10.2，维护的还是之前的arp表。
# ip netns exec qrouter-9b4da896-6baf-4e56-b368-85b25591908a arp -a
? (192.168.1.254) at 78:2b:cb:6b:9c:9a [ether] on qg-7356347e-91
? (10.20.30.2) at fa:16:3e:bc:b1:3d [ether] on qr-760f5ff8-3a
? (10.20.30.28) at fa:16:3e:0e:88:49 [ether] on qr-760f5ff8-3a
? (192.168.10.2) at fa:16:3e:33:8e:7c [ether] on qr-b82a5c08-87
在命名空间执行arp -d命令，删除这条arp表后，ok。
这个就是由于Linux系统中维护的arp表项和qrouter命令空间中arp表不一致造成2层不通。
原因大致清楚了，l2 pop driver在更新arp表的时候，只会发送rpc消息到linux bridge agent，l3 namespace里并不会接收到这种消息。
大概想了2种办法：
1.调整ip neighbor内核参数base_reachable_time，修改arp老化时间，但是在/proc/sys/net/ipv4/neigh目录下看到的只是和qr对应的tap设备，这个办法基本上没法改。
2.在create port的时候，给l3发送notification。dhcp是这么干的，但是这个时候，并不能获取router的id，怎么发送消息呢？
解决 两不愁三保障 突出问题座谈会|解决neutron中不同命名空间的mac地址冲突
http://m.bbyears.com/zhufuduanxin/71812.html
推荐访问:解决方案 解决问题 解决方案模板 解决形式主义突出问题为基层减负 解决问题的能力 解决方案工程师