公司有个测试云平台的虚拟機密码初始化出现了问题根据之前的经验可能跟问题一样,没想到花费了将近一天的时间才将问题解决，发现最终是跟neutron 分布式虚拟路由有關这里记录一下。
- 查看相关日志没有找到有关报错信息，而且奇怪的是网络节点对应的neutron-ns-metadata-proxy-xxxxxxxxx.log都没有处理请求的日志说明请求可能没有走到这里。
- 只能按照请求的处理步骤一步步排查首先确定虚拟机所在的网络是有路由器相连的，所以metadata请求是走的路由器的namespace相关知识参考,网络节点对应路由器的namespace中一切正常，9697 端口的重定向以及监听9697端口的neutron-metadata-ns-proxy进程也正常。没办法在该路由器的namespace中对应端口抓包试试，虛拟机中发送169.254.169.254却一点反应没有，断定请求压根就没有走到该路由器的namespace只能返回去虚拟机实例中抓包试试，使用traceroute命令发现请求是发到对應网关的而对应网关就应该在路由器的namespace中啊，到这里基本就蒙逼了
- 在经过一番徒劳无功的试错后，终于找到了一点线索我在查看neutron agent状態的时候，发现neutron-l3-agent不只是在网络节点计算节点也存在neutron-l3-agent，立马想到neutron-l3-agent会在本地计算节点也创建虚拟路由器所以获取metadata的请求就发送到本地计算節点的路由器 neutron-metadata-agent的时候出现了问题。本能的想是不是配置错误导致的查看l3-agent的配置文件时发现有个配置项：agent_mode = dvr ，赶紧搜了一下终于找到了进叺的正确姿势。
在没有使用dvr时我们的整体架构大致是这样的：
计算节点只需要安装L2 Agent就可以，而使用dvr模式后：
计算节点除了L2 Agent外还要安装L3 Agent以及Metadata Agent。也就是说通过使用dvr，计算节点也有了网络节点的三层转发和NAT功能起到了分流的作用。
|
|
照着这张图梳理一遍以下几种情况的网络走向：
- 不同子网但有虚拟路由连接的instance东西向网络
刚开始类似之后在本地router namespace进行路由选擇，并通过br-int,br-tun进入对应虚拟机的计算节点（该部分工作由ovs 的openflow完成同时还完成了snat），到了 目标计算节点上依次被 br-tun，br-int 处理直到通过 tap 设备进叺另一instance。
关于详细描述以及实验可以参考,以及
本篇文章由采用进行许可,转载请注明。
