该篇文章主要介绍了如何分析Neutron下的VM网络数据流,并结合这些方法如何去进行网络分析和故障解决.
一．前言
该篇文章主要介绍了如何分析Neutron下的VM网络数据流，并结合这些方法如何去进行网络分析和故障解决。限于篇幅、环境，这里并未提及FlowTable、br-tun等。我们将在下次见面。
众所周知，OpenStack Neutron的高度复杂性和抽象性，让众多学习和使用者望而生畏，不知所云。尽管如此，但我们不能选择逃避。
其实，暂且抛开具体细节不谈，从全局和宏观上理解Neutron的整个运行流程，也是不复杂、抽象的。
无非就是将传统的物理硬件设备（如网线、网卡、服务器、交换机、路由器等）按照TCP/IP的四个层次架构（数据链路层、网络层、传输层、应用层），通过软件编程的方式，予以全部虚拟化、软件化和抽象化。
其虚拟实现的1层到3层（TCP/IP）整个流程是：
一层的服务器及其VM（由Linux Kernel创建的qbr、tap/tun、veth、iptables这些设备分别实现相应功能）→二层的网络设备（由OpenvSwitch、dnsmasq创建的qvo、br-int、br-tun、br-ex、qrouter、qdhcp等设备分别实现相应功能）→再到，三层的传输程序（由patch-int/patch-tun等分别实现相应的功能）。
在Neutron虚拟网络中，除了Neutron本身命令外，还包括了Linux Bridge的brctl命令；OpenvSwitch的ovs-vsctl、ovs-ofctl命令和L3的NameSpace的ipnetns等命令。
至于，DVR、NFV、SDN等这些和Neutron挂钩的高大上名词，也无非是借鉴了传统的网络架构，予以虚拟化和创新罢了。最后，怎么去具体实现，那就是架构设计和软件编码的事儿了。
下面，我们将以实践且非常实用的方法来走进Neutron的虚拟网络世界中，化抽象为形象。
二．OpenStack Neutron网络连接测试
OpenStack Neutron网络连接测试，说到底是VM的网络连接测试，即与外网的网络连接情况、网络诊断和故障排错等。方法如下：
注意
由于执行的命令输出信息太多，这里予以了省略，但并不影响理解和学习。在必要处，会给出信息。
实验环境如下：
Host Server/VM：CentOS 7
OpenStack Juno Neutron：VLAN模式
Provider Network：Vlan 102、网段 172.16.102.0/24、网关172.16.102.254
VM IP：172.16.102.5
需要注意的是，在vlan模式下，vlan tag的转换是在br-int和br-ethx两个网桥上进行。即br-int负责从int-br-ethX过来的包（带外部vlan）转换为内部vlan，而br-ethx负责从phy-br-ethx过来的包（带内部vlan）转化为外部的vlan。
同时，在VLAN模式下，没有br-tun通道网桥。
我们将根据下面这张图的流程（VM数据到外网），予以分析：
1.计算存储节点上
1）执行nova list 查看VM对应的名称和VM_UUID。
VM默认存放于路径：/var/lib/nova/instances/
| 1 | # nova list |
2）执行nova show $VM_UUID，查看VM所在的openstack compute node信息和instance name。
Shell| 1 | # nova show $VM_UUID |
3）查看VM在哪个计算节点上。
Shell| 1 | # nova-manage vm list | grepvm-name |
4）执行virsh list 查看VM状态，执行virshdumpxml instance-XXXX查找文件中关于“Bridge”信息，查找tap的ID和网桥qbrXXXX。
Shell| 123456789 | # virshdumpxml instance-00000052 </controller><interface type='bridge'><mac address='fa:16:3e:3e:da:f1'/><source bridge='qbrc08d85da-69'/> #OVS实现安全组的网桥<target dev='tapc08d85da-69'/>#虚拟网卡设备<model type='virtio'/> #虚拟网卡驱动<alias name='net0'/>#虚拟网卡别名<address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> |
这里，我们结合一张官网的图，来予以剖析。
从图中，我们可以知道：
eth0连接的目的设备是：tapc08d85da-69，别名为net0。TAP设备桥接到网桥qbrXX上（都由Linux kernel创建）。qbr设备是因为不能在TAP设备上配置iptables实现安全组（SecurGroup）而增加的设备。
eth0对应的tapc08d85da-69，桥接到的网桥为qbrc08d85da-69。
5）执行brctl show查看网桥qbr上的接口信息，找到tap设备和qvbXXXX接口。
备注：由于这些网桥均由Linux Kernel创建，所以使用brctl命令
| 123 | # brctl showqbrc08d85da-69 8000.3a04f8f4bda2 no qvbc08d85da-69 tapc08d85da-69 |
这里，可以看到网桥qbrc08d85da-69，上面有接口qvbc08d85da-69和tapc08d85da-69。
这里出现的qvbXXX和qvoXXX是一对veth pair devices，是一对虚拟的网卡设备或虚拟的网线，用来连接Linux bridge网桥和Open vSwitch设备。名字的涵义是q-quantum、v-veth、b-bridge；o-open、vswitch（quantum年代的遗留）。
6）查看qvb设备的驱动是否是veth类型。
Shell| 1 | # lshw -class network|more |
7）查看qvb接口的对端peer_ifindex:number。
Shell| 123 | # ethtool -S qvbc08d85da-69NIC statistics:peer_ifindex: 15 |
8）找到peer_ifindex:number对应的接口qvoXXX。
Shell| 123 | # ip link | grep 15:15: qvoc08d85da-69: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP>mtu 1500 qdiscpfifo_fast master ovs-system state UP mode DEFAULT qlen 1000link/ether 4e:99:15:01:1b:07 brdff:ff:ff:ff:ff:ff |
qvbXXX和qvoXXX是一对veth设备，成对出现的。可以根据ethtool -S 查看对端的number，并且根据iplink|number：查看到对应的veth设备名称（即qvo）。
qvb是quamtumveth bridge
qvo是quamtumveth open vswitch
qvoXXX设备连接到了Open vSwitch设备的br-int集成网桥上
9）通过Open vSwitch中的命令ovs-vsctl port-to-brqvoXXX查看qvoXXX设备所属的bridge。
Shell| 12 | # ovs-vsctl port-to-br qvoc08d85da-69br-int |
10）查看所有的网桥
Shell| 123 | # ovs-vsctl list-brbond-brbr-int |
11）查看OVS Bridge上面有哪些端口
Shell| 12345678910111213141516171819 | # ovs-vsctl list-ports br-intint-bond-brqvo077eac35-edqvo1ee66407-69qvo40816622-cfqvo849c4847-1eqvoace90c57-d3qvob0b730ab-79qvob32e78ae-7fqvoc08d85da-69qvodec9ff3a-92qvoe2028755-37qvofb9c19ea-6atap52a2315f-19tap63754766-e1 # ovs-vsctl list-ports bond-breth3phy-bond-br |
int-bond-br和phy-bond-br端口是用来连接Open Vswitch设备的br-int和bond-br（即br-ethX）网桥。另外，VLAN ID的转换是发生在br-int和bond-br网桥的端口int-bond-br和phy-bond-br上面的。
从br-int进来的数据包，其VLAN ID 会被转换为内部的VLAN ID。同理，从网络出去的数据包，经过phy-bond-br，VLAN ID会将内部VLAN ID 转化为外部VLAN ID。
12）通过ethtool -S 命令查看br-int的对端设备number；并通过ip link |grep number查看br-int的对端设备（即phy-bond-br）。
Shell| 123 | # ethtool -S br-int # ip link | grepnumber |
13）查看phy-bond-br连接到的虚拟外部网桥。
Shell| 12 | # ovs-vsctl port-to-brphy-bond-brbond-br |
14）查看外部网桥bond-br（即br-ethX桥）上的端口：
Shell| 123 | # ovs-vsctl list-ports bond-breth3phy-bond-br |
关于本例子中的bond-br外部网桥和物理网口ethX的关系是：VM数据包要到外部物理网络中，必须依靠真正的物理网卡。
这种关联，需要通过手动方式创建，这里是：
| 1 | # ovs-vsctl add-port bond-br eth3。 |
小结
基于上述数据通信流程，这样整个VM的数据链路便完全打通了。从VM的端口到qvoXXX接口的信息及网桥和端口的连接情况，再结合tcpdump命令查看网络流量和OVS OpenFlow协议能够清楚的掌握和梳理Neutron网络的连接架构，作为网络分析的依据，为故障排除提供坚实的基础。
图片来源：
1：http://yeasy.gitbooks.io/openstack_understand_neutron/content/vlan_mode/index.html
2：https://github.com/openstack/neutron/blob/master/doc/source/devref/images/under-the-hood-scenario-1-ovs-compute.png
作者简介：徐超：2015——至今，从事OpenStack相关工作。个人倾向于研究OpenStack、SDN和Docker。
声明： 此文观点不代表本站立场；转载须要保留原文链接；版权疑问请联系我们。
