Atom feed of this document
  

 网络故障排查

 浮动IP不可达

假如你通过浮动IP地址无法访问你的实例:

  • 检查默认的安全组是允许ICMP (ping) 和SSH (端口 22)的,然后就可以访问实例了:

    $ nova secgroup-list-rules default
    +-------------+-----------+---------+-----------+--------------+
    | IP Protocol | From Port | To Port |  IP Range | Source Group |
    +-------------+-----------+---------+-----------+--------------+
    | icmp        | -1        | -1      | 0.0.0.0/0 |              |
    | tcp         | 22        | 22      | 0.0.0.0/0 |              |
    +-------------+-----------+---------+-----------+--------------+
  • 检查运行nova-network的节点上的iptables已经添加了NAT的规则:

    # iptables -L -nv -t nat
    -A nova-network-PREROUTING -d 68.99.26.170/32 -j DNAT --to-destination 10.0.0.3
    -A nova-network-floating-snat -s 10.0.0.3/32 -j SNAT --to-source 68.99.26.170
  • 检查公网地址(此例中是68.99.26.170 )已经添加到公共的网卡。当使用命令ip addr 时可以看到其出现在列表中:

    $ ip addr
    2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether xx:xx:xx:17:4b:c2 brd ff:ff:ff:ff:ff:ff
    inet 13.22.194.80/24 brd 13.22.194.255 scope global eth0
    inet 68.99.26.170/32 scope global eth0
    inet6 fe80::82b:2bf:fe1:4b2/64 scope link
    valid_lft forever preferred_lft forever
    [注意]注意

    路由的配置是不允许在相同的服务器上将公有IP ssh给实例的。

  • 如果包被路由到计算主机上的到达的接口,那么使用 tcpdump 来认证。如果包到达计算主机但连接失败了,问题可能是包被逆向路径过滤丢弃了。尝试在到达接口上禁用逆向路径过滤。例如,如果到达接口是 eth2,请执行:

    # sysctl -w net.ipv4.conf.ETH2.rp_filter=0

    如果解决了此问题,将下面这几行内容添加到文件/etc/sysctl.conf 以使变更为永久生效:

    net.ipv4.conf.rp_filter=0

 临时禁用防火墙

为了能够调试网络的问题对访问虚拟机有所帮助,在 /etc/nova/nova.conf中设置下面的属性来禁用防火墙:

firewall_driver=nova.virt.firewall.NoopFirewallDriver

我们强烈建议在网络问题解决后将此行删除,从而重新启用防火墙。

 从实例到nova-network服务丢包(VLANManager 模式)

如果你可以SSH到你的实例,但是网络特别的慢,又或者是你发现了其他比平时慢很多的操作(例如sudo),那么就是连接到实例的网络发生了丢包现象。

丢包可能是和网桥相关的Linux网络配置有关。比较确定的是在VLAN网卡(例如, vlan100)和对应的运行nova-network主机上的网桥(例如, br100) 之间的包被丢弃的情况。

检查是否出现此问题的一个办法是打开三个终端然后运行下面的命令:

  1. 在第一个终端,在运行nova-network的主机上执行,在VLAN的网卡使用tcpdump 来监控DNS相关的流量(UDP,端口53)。以root用户运行:

    # tcpdump -K -p -i vlan100 -v -vv udp port 53
  2. 在第二个终端,也是在运行nova-network主机上执行,使用tcpdump来监控网桥接口的DNS相关流量。以root运行:

    # tcpdump -K -p -i br100 -v -vv udp port 53
  3. 在第三个终端,SSH登录到实例,然后使用nslookup命令来生成DNS的请求:

    $ nslookup www.google.com

    表现可能时好时坏,所以尝试多次运行 nslookup。如果网络配置是正确的,命令每次都会立即返回,如果是错误的配置,命令会在返回之前有几秒钟的挂起。

  4. 如果命令nslookup有时候会挂起,而且在第一个终端上还能看到网络包的出现,但并不是在秒内,所以可能的问题在于网络设置了过滤。尝试关闭过滤,以root运行下面的命令:

    # sysctl -w net.bridge.bridge-nf-call-arptables=0
    # sysctl -w net.bridge.bridge-nf-call-iptables=0
    # sysctl -w net.bridge.bridge-nf-call-ip6tables=0

    如果解决了此问题,将下面这几行内容添加到文件/etc/sysctl.conf 以使变更为永久生效:

    net.bridge.bridge-nf-call-arptables=0
    net.bridge.bridge-nf-call-iptables=0
    net.bridge.bridge-nf-call-ip6tables=0

 KVM:网络开始时远行良好,不久失效

基于KVM hypervisor运行Ubuntu 12.04的实例有时会在运行正常一段时间后突然网络失去连接。尝试加载内核模块vhost_net来修复此问题(请参阅 bug #997978)。此内核模块也会改进KVM的网络性能。要加载此内核模块:

# modprobe vhost_net
[注意]注意

加载模块对正在运行的实例没有影响。

Questions? Discuss on ask.openstack.org
Found an error? Report a bug against this page


loading table of contents...