问题15--新建虚机IP无法ping通

问题描述：新建虚机IP无法ping通

解：1、用ip -4 a查看虚机内部，没有IP，查看对应计算节点neutron-dhcp-agent没有启用，环境中neutron是和思科对接，不用所有节点都启用dhcp服务。

2、登录api节点查看neutron dhcp-agent-list-hosting-net $net_id，发现对应的计算节点dhcp没有开启，将其开启。

3、将虚机迁移到启动dhcp的计算节点，在虚机用dhclient可以获取到IP，但还是无法ping通，同时虚机内部无法ping通网关。虚机在交换机中的tor已经有配置

4、将虚机迁移到虚机IP正常的节点，发现正常，正常的节点中dhcp服务没有重启；

5、期间还出现过，创建完虚机，subnet网段中对应的网关无法ping通，经常是交换机的问题，把配置铲掉，重新创建；

排除思路：

dhcp工作过程

dhcp-server是作为一个通过运行在网络节点上一个namespace qdhcp-$NetId 中的dnsmasq进程实现的，dhcp实现高可用，每个network会分别在两个网络节点上创建qdhcp-$NetId namespace并在其中创建dnsmasq进程，两个dnsmasq之间进程是同步的，理论上任何一个回复vm的BOOTP请求，并且虚拟机收到了，都能过获取到IP。

虚拟机首先发送BOOTP广播discover，请求中包涵自己的mac等信息；dnsmasq收到广播之后查询本地纪录，有则回复offer，然后虚拟机继续广播一条 request，dnsmasq 回复 ack。

通过vnc登入到虚拟机，查看网卡配置，一定要首先确认虚拟机中存在对应的网卡并且是up的，即可以通过 ifconfig看到这个网卡，如本例中的eth0，如果没看到网卡，可能是虚拟机创建或虚拟网卡挂载有问题；

分别去起了这个网络dhcp的网络节点上检查。通过 neutron dhcp-agent-list-hosting-net $net_id 来查询 dhcp namespace 在哪里

ps aux | grep neutron-dhcp-agent

ip netns | grep $NetId

ps aux | grep $NetId

 以上命令均有输出说明 dhcp agent 正常，否则可以尝试重启 dhcp agent 观察日志重新检查

ip netns exec qdhcp-$NetId ip addr

发现网络节点A上是好的，然后去网络节点B上做相同的检查namespace，如果有namespace，并且其中有ip，那么我们可以在其中一个网络节点的namespace中ping另一个的namepsace中的IP，如果能通，说明网络节点之间联通没有问题，否则表明网络节点的SDN网卡或网络节点上ovs配置或流表有问题。

ip netns exec qdhcp-$NETID ip addr

ip netns exec qdhcp-$NETID ping $AnotherDHCPIP

这里检查发现网络节点上的dhcp服务和通信都是正常的，基本可以排除网络节点的问题。否则，可以用以下方法检查网络节点。

如果没通呢？可以这样检查，在 dhcp namespace ping 广播地址，广播地址来自于 ip netns exec qdhcp-*** ip a  ,  ip netns exec qdhcp-*** ping <ip> -b

与此同时抓包，如果是基础网络或其他 vlan 网络，现在 ovsbr3 上抓 tcpdump -eni ovsbr3 icmp：

通过上图可以看到有 vlan 标签，这个应该和网络的属性是一致的 neutron net-show $net_id中的segmentation_id

如果 vlan id 不一致，或没打上，可以试着重启 ovs agent。

如果有包（这是大多数情况），那么需要看下物理的情况了，先看 ovsbr3 连着哪个接口 ovs-vsctl list-ports ovsbr3

如果除了 phy-ovsbr3 之外没有了，正确的是还有bond0；那说明实施时存在问题

如果有的话上这个口抓包 tcpdump -eni $interface icmp

下面再到 网络节点B上 （根据前边看 dhcp-agent-list-hosting-net 的结果），抓 bond0 （看前边 ovs-vsctl list-ports ovsbr3 的结果了）的包：

tcpdump -eni $interface icmp

如果抓不到和 网络节点A 上看到的一样的报文的话，说明交换机配置有问题，并没有允许这个 vlan

首先找到虚拟机在那个计算节点，然后找到虚拟机的虚拟网卡，也就是挂载到这个虚拟机上的port

nova show $VmId    

neutron port-list --device-id=VmId

找到port和对应的计算节点之后，我们就去对应的计算节点上查找问题。

登陆到计算节点之后，首先检查该节点上是否起了neutron-openvswitch-agent进程，如果有则继续以下过程；如果没有，尝试先启动

通过vnc登陆到对应的虚拟机，手动发起dhcp请求：

dhclient -d eth0

通过dhclient的输出来看，vm已经广播了BOOTP请求，但是没收到回复。此时，进入最后的解决办法：抓包。

如果出现以下输出，表明vm发送的BOOTP请求得到dhcp-server的回复，虚拟机获取到IP，可以通过ifconfig 来检查

注意：

1. 抓包的时候一定要确定vm是在发送dhcp请求；如果不确定，请再重现执行一次`dhclient -d eth0`

2. 抓包之前已定要确定按照之前的步骤确定网络节点通信问题，并且dnsmasq和neutron-dhcp-agent 进程正常

根据之前的拓普图，先检查是否有port对应的tap/qvb/qbr/qvo设备，这些虚拟设备的前三位表明类型，后面11为是port的前11位：c2b9e92e-1e75-47da-b450-896581c30943

在计算节点的tap, qvb, qvo和eht3( 基础网络)/eth3.1124(私有网络) （根据 ovs-vsctl show 看 br-tun 上的 local-ip 所在网卡为私有网络网卡和 osvbr3 上网卡为基础网络网卡来判断）上抓包，抓包的顺序可以采用，自底向上的方法，也可以采用自顶向下的方法。以自底向上为例讲解抓包方法。

eth3/eth3.1124

先从计算节点物理网卡开始，私有网络(vxlan)则在eth3.1124，基础网络(vlan)则在eth3，过滤虚拟机的mac。本例中是vxlan网络，所以要在eth3.1124上检查。同时要去之前确定的两个网络节点上的任意一个上 eth3/eth3.1124 同步抓包

如果是vxlan, 直接用grep过滤mac地址

tcpdump -eni eth3.1124 | grep "00:00:22"

如果是vlan，可以用ether host 过滤mac地址

tcpdump -eni eth3 ether host <mac>

0.计算节点的物理网卡抓到了request，网络节点没抓到request。这种情况说明链路可能有问题：

0.1 如果是vlan网络，我们需要知道这个vlan id是多少，看计算节点和网络节点的接入交换机上有没有允许这个vlan；检查ovsbr3上的网卡是否为正确的网卡，如果是bond，检查bond是否是up的

0.2 如果是 vxlan网络，我们首先要检查一下走vxlan网络的那个子接口（如eth3.1124）有没有配正确的ip，有没有配重复的IP和路由，计算节点和网络节点的介入交换机有没有放行走vxlan隧道这个vlan（例如vlan 1124）

路由问题可以通过 ip r get x.x.x.x 来检查：

1. 计算节点和网络节点都抓到了request，但是没有reply。由于我们之前已经确定网络没有问题，所以此时还是出现没获取到IP的问题，可以先试试重启 dhcp-agent，观察日志是否有报错。检查虚拟网络设备桥接关系是否正常，br-int 和 ovsbr3 上是否有流表，如果不正常或无法确定可以尝试重启 openvswitch 和 openvswitch-agent

2. 计算节点和网络节点都抓到了request, 网络节点抓到了reply, 但是计算节点没抓到。初步判断为核心交换机上策略路由配置或链路有问题.

3. 计算节点和网络节点都抓到request和reply, 但是虚拟机还是没获取到IP。出现这种情况表明回包已经到达计算节点，但是被计算节点上的ovs或iptables丢弃，导致回包没到达虚拟机，需要依次继续在计算节点上的qvo, qvb和tap上抓包分析，继续以下内容

3.1 在计算节点qvo设备上抓包。如果网卡eth3/eth3.1124上抓到request和reply，但是qvo设备上只有request，没有reply。出现这种情况表明回包被计算节点上的ovsbr3/br-tun 或br-int丢弃了，请联系网络组检查该计算节点ovsbr3/br-tun 和br-int上相关流表，并说明情况；如果抓到了request和reply，虚拟机还是没获取到IP，需要进一步排查qbr的问题，则继续看3.2

3.2 由于qbr是Linux Bridge设备，安全组作用在其上。我们倾向于在虚拟网卡设备上抓包，而非网桥上抓包，这样更能反映问题。所以跳过qbr设备，直接去tap设备上抓包观察。如果tap设备上抓到request但是没有抓到reply,则表明回报在qbr附近被丢弃，请联系网络组检查宿主机上这个端口的安全组类似iptables规则，并说明情况；

如果tap设备上抓到request和reply，但是虚拟机还没有获取到IP，请VNC登陆虚拟机，查看网卡配置文件，是否为dhcp模式。根据情况，如果想要通过dhcp获取IP地址，则改为dhcp；若想要静态设置IP，则改为static，并配置IP, gateway和 route