neutron 虚机网络无法访问外网

admin · 发表于 2018-11-9 11:11:10

为了解决这个问题，我们需要了解L3 agent（L3代理）的工作原理。其主要职责是允许L3连接和路由，也提供NAT，并使用命名空间进行网络隔离。通常它将被安装在网络节点上，也是提供访问外部网络的代理。

官网教程创建一个虚拟机中写了如何创建 provider network 和 self-service network。在self-service netwrok中，创建的网络有一个内部IP和一个外部IP。创建self-service network时，需要有一个provider network，并创建一个路由，把self-service network的子网作为路由的一个接口，再把路由连接到provider网络上。这时运行以下命令，可以看到provider网络的两个网关：
$ neutron router-port-list router

如上图，其中 172.16.1.1 是self-service network的内部网关，是无法从外部ping通的，203.0.113.102 是外部网关，可以从外部ping通。如上所说，在创建self-service network时，会通过建立一个路由把该网络和一个provider network连接以保证self-service network可以访问外部网络。
在self-service network中创建虚拟机，需要给虚拟机分配一个浮动IP，如果我们想ping通虚拟机，应当使用这个浮动IP。
上文的ping通private IP笔者略有疑惑，可能指的是从虚拟机内部ping 类似 172.16.1.1 的内部网关，也可能是从外部ping虚拟机绑定的浮动IP。
接下来，从路由器命名空间尝试使用浮动IP来ping 虚拟机：
$ sudo ip netns exec qrouter-xxx-xxx-xxx ping <vm_floating_ip>
笔者注：上面命令的命名空间可以用如下指令获得：
$ ip netns
用如下指令可以得到所有虚拟机的IP：
$ openstack server list
这可能是个愚蠢的检查，因为浮动IP总是处于路由器命名空间内，但至少它会告诉我们情况有多糟糕。
你还应该检查网桥配置问题。用下面的命令检查它：
$ ovs-vsctl show
别忘了检查L3 agent的log文件：
$ sudo grep -E -i "error|trace" /var/log/neutron/l3-agent.log
用以下命令看虚拟机是否得到了IP：
$ ip a
从虚拟机里ping网关看是否能到达：
$ route -n
$ ping <default_gateway_ip>
问题三: 虚拟机无法访问元数据服务器元数据服务器是为虚拟机提供元数据的服务。数据可以是ssh密钥，ip地址，主机名。
元数据代理负责将来自虚拟机的请求代理到元数据服务器或 nova。有两种方法来配置它：

路由网络 - 当你有一个连接到路由器的网络
非路由网络 - 当你有没有连接到路由器的网络，所以它是隔离的。) z7 y: I6 J+ q+ {1 G

我们来看看路由网络的工作流：

routed_networks_metadata.png

注意：metdata代理由L3代理生成，并监听请求。当来自虚拟机的请求到达元数据代理时，它将一些信息添加到虚拟机和路由器id的头部IP中，并将其转发给元数据代理。
现在让我们更仔细地看看其他配置 - 隔离网络：

isolated_network_metadata.png

注意：为了隔离网络能工作，必须在dhcp配置文件中进行配置：
enable_isolated_metadata = True
笔者注：在以下文件中配置：
/etc/neutron/dhcp_agent.ini
我们还使用DHCP的 option 121，在向DHCP请求IP地址时向虚拟机注入路由。所以元数据代理是到达元数据服务器的下一个跃点。
Debug步骤首先查看metadata agent是否正常运行：
$ neutron agent-list
在metadata agent 那行应当看到alive下面的微笑。
接着，检查metadata proxy是否正常。请记住，它是由L3代理在路由器（或dhcp）命名空间中产生的，所以您应该检查它是否在命名空间的进程表中：
$ sudo ip netns exec qrouter-xxx-xxx-xxx ps -ef | grep metadata-proxy
问题会反映在metadata的log文件中，所以前去检查：
$ sudo grep -E -i "error|trace" /var/log/neutron/metadata-agent.log /var/log/neutron/neutron-ns-metadata-proxy-xxx-xxx-xxx.log
检查是否可以通过路由/DHCP到达元数据服务器：
$ sudo ip netns exec qrouter-xxx-xxx-xxx ping <metadata-server_IP>
检查创建虚拟机的镜像是否支持 option 121。如果不支持，那么虚拟机可能无法得到路由并且到达元数据服务器。
如果所有都尝试了还没有发现问题，试着使用 tcpdump 来解决问题。
问题四: VIF plugging timeout为了理解为什么会遇到timeout问题，我们需要介绍L2代理。
L2代理在计算主机上运行，其主要职责是配置节点上的本地交换机并连接新设备，它通过RPC与neutron服务器通信，还负责提供使用iptables和ip集合的安全组规则。
让我们更详细地看看VIF如何工作：

vif_plugging.png

当Nova发送allocate_network请求时，它将超时设置为5分钟。如果Nova在5分钟内没有得到Neutron的回复，你会得到VIF plugging timeout。
debug步骤检查日志。L2代理，neutron和nova日志可以帮助查找问题，在计算节点上输入：
$ sudo grep -E -i "error|trace" /var/log/nova/nova-compute.log /var/log/neutron/openvswitch-agent.log
在控制节点上：
$ sudo grep -E -i "error|trace" /var/log/neutron/server.log
如果系统加载缓慢，或者你正在执行压力测试，则可能需要调整/etc/nova/nova.conf文件中的服务器配置：

尝试增加 vif_plugging_timeout 以提供更多的时间来插入接口
尝试增加 rpc_thread_pool_size 和 rpc_conn_pool_size 以使处理速度更快( \! X4 P7 E* L, J9 L$ V

一些好用的工具让我们回顾一下在对neutron进行debug过程中用到的工具。
ip aip addr（ip a只是一个快捷方式）对于检查你的机器/命名空间中的设备非常有用。它允许你获取设备名称、查看设备是否启动、获取IP地址、MTU以及其他一些网络参数。
route -n它会显示路由表。通过路由表，你可以知道你的数据包在流出时将采用哪个路径。
iptables -L查看节点上存在哪些防火墙规则。如果你的数据包突然消失或没有到达最终目的地，防火墙的某些规则可能是原因。
arp查看主机上的arp表。利用它可以查看你的节点能不能找到其他节点的地址。
tcpdump在这篇文章中多次提到过。这是一个很棒的数据包追踪工具，容易安装，也容易使用。我将在另一篇文章中介绍它，因为有很多方法可以使用，最好花时间专门学习。对于最基本的使用，只需运行：
$ tcpdump -i <device_name>
ip netns查看namespace。为了列出你所在节点可用的namespaces，可以使用：
$ ip netns list
你可以使用 ip netns exec 查看更多。例如，要在命名空间中显示路由表，请使用：
$ ip netns exec qrouter-xxx-xxx-xxx route -n
OpenVSwich如果你在部署中使用openvswitch，则有几个用于调试和故障排除的工具：
ovs-vsctl show —— 显示机器上网桥的配置
ovs-ofctl show —— 显示数据路径
ovs-ofctl dump-flows —— 转储安装在机器上的所有流
ovs-ofctl dump-flows br-tun —— 转储br-tun上的所有流
ovs-ofctl dump-flows br-tun table = 21 —— 在特定表中转储br-tun上的所有流
LinuxBridge对于linux网桥，请使用以下命令：
brctl show  —— 显示机器上网桥的配置
brctl show <bridge name>  —— 显示特定网桥的配置
补充再介绍一些你可能想要熟悉的几个重要的网络设备。
我们从TAP设备开始。TAP设备是一个虚拟网络接口，用于连接由虚拟机管理程序（KVM，Xen等）实现的虚拟机实例。流量到达TAP设备，由虚拟机实例接收。要记住TAP设备通常是流量的起点，可以从TAP设备开始跟踪流量。
要查看TAP设备，只需运行：
$ ip a | grep -i tab
更多关于TAP设备的信息，可以在这里  找到。
TAP设备使用Linux bridge进行桥接。通常Linux桥名以qbr开头，这是qunaum bridge的简写（qunaum是neutron以前的名字）。你可以使用brctl列出系统上的linux bridge。
$ brctl show
你会在输出中看到TAP接口和qvb接口。
qvb（Quantum veth bridge）和另一end - qvo（Quantum veth openvswitch）构成一个虚拟以太网对（Virtual Ethernet Pair）。它用来连接Linux桥和OVS桥。可以把它们想象成一条管道，任何在一个设备上进入的东西都应该从这个设备上离开。
如果你列出集成桥上的端口，你将看到其中一个端口是qvo，它将你连接到Linude Bridge。
路由器和DHCP设备直连到br-int。在列出DHCP命名空间中的接口或列出集成网桥上的端口时，可以看到TAP设备条目。
$ ip netns exec qdhcp-<network_id> ip address
$ ovs-vsctl list-ports br-int
笔者总结在了解了neutron的基础概念，通过一些图表知道了数据流的走向后，对于我们debug最有用的还是查看log。Openstack的log都处于 /var/log 目录下，我们通过查看、解决log里的问题，并重启相应网络服务，基本可以解决问题。
笔者翻译这篇博客的过程中，对Openstack的neutron模块有了更深的了解，也利用博客里梳理的思路解决了实验室Openstack环境遇到的问题，以后会多多学习这类博客，看到好的博客会争取翻译过来。

		自动登录	找回密码
密码			注册

neutron 虚机网络无法访问外网

浏览过的版块