现象：
openstack中创建的vpc网络中，虚拟机不能dhcp到IP地址，抓包分析如下：
这是openstack控制节点的网络相关信息，问题是： vxlan-60中一个虚机想要通过dhcp获取IP地址，现在dhcp的数据包可以通过eth0到达brqce4d2a54-44，抓包可以验证 ：
|
1 |
tcpdump -i brqce4d2a54-44 udp and port 8472 #可以看到数据包 |
但是vxlan-60上却抓不到dhcp数据包：
|
1 |
tcpdump -i vxlan-60 -nn #看不到数据包 |
我觉得，到达了 brqce4d2a54-44 的vxlan数据包，如果vxlan id是60就直接转给vxlan-60 就是了，还可能被哪里的规则给拦截？问题都定位了这地步了，应该问题就出现在openstack-controller身上吧？不应该和其它机器有关系吧？（我不断祭出bridge fdb、brctl、ip等工具，浪费了有半天的时间）
后来，在我都试图想重启openstack-controller的时候，我决定分别在两个compute上创建两个机器，如果两个机器之间能够通信，则说明openstack-controller 的问题，否则，就不是openstack-controller的问题； 测试发现，两个机器不能通信，我才把重点放在了compute节点；
compute节点网络架构：
话说，这个网络和官方指导架构或者书本上指导的架构都不一样； 正常来讲，把bond0 添加到 /etc/neutron/plugins/ml2/linuxbridge_agent.ini 中就可以了，也不会出现今天的问题，因为最初是这样的，我测试vpc功能都是OK的；
加入我把bond0给了neutron，则neutron会将bond0的IP转移给brqce4d2a54-44 ， 由于机器有限，我需要在这些compute节点上起ceph node，ceph node也通过虚拟机提供存储服务（如上图的vnet0），如果让vnet0桥接到brqce4d2a54-44 上，总感觉不大好，于是，便有了上述的网络架构；
既然 /etc/neutron/plugins/ml2/linuxbridge_agent.ini 里面配置成了veth_neutron ,那么 /etc/neutron/plugins/ml2/linuxbridge_agent.ini 里面的 local_ip 也应该修改为 veth_neutron 的IP，不是吗？（当然不是，错就错在这儿了），于是我就这么改了
因为vxlan-60 的 dev 是brqce4d2a54-44 ，数据只有先到达brqce4d2a54-44 才可能进入vxlan-60 ；
我发现，进入的vxlan数据包首先是要走到bond0的，然后走到br0，我期望能通过veth_br0 到 veth_neutron ， 再到 brqce4d2a54-44 ，然后再到vxlan-60， 然而，实际情况是，vxlan数据包根本不进入veth_br0； 我猜测，很可能内核已经在分析vxlan数据包了，该给谁给谁，没人要就丢掉呗； 然而，vxlan-60是base在brqce4d2a54-44 上的，没有base在br0上； 如果让vxlan-60 base在br0上是不是就可以了呢？
关于vxlan-60 base在哪个设备是通过/etc/neutron/plugins/ml2/linuxbridge_agent.ini 里面的local_ip 来决定的，和 physical_interface_mappings 是不必相同的。
修改后，重启 neutron-linuxbridge-agent.service , 重新创建vpc， 问题解决。
思考：
为什么vxlan的目的IP是brqce4d2a54-44， 而实际却不能真正落到brqce4d2a54-44 上？