本文主要介绍了如何分析Neutron下的VM网络数据流，并结合这些方法如何去进行网络分析和故障解决。限于篇幅、环境，这里并未提及Flow Table、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的ip netns等命令。
至于，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/
# nova list
2）执行nova show $VM_UUID，查看VM所在的openstack compute node信息和instance name。
# nova show $VM_UUID
3）查看VM在哪个计算节点上。
# nova-manage vm list | grep vm-name
4）执行virsh list 查看VM状态，执行virsh dumpxml instance-XXXX查找文件中关于“Bridge”信息，查找tap的ID和网桥 qbrXXXX。
# virsh dumpxml 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实现安全组（Secur Group）而增加的设备。
eth0对应的tapc08d85da-69，桥接到的网桥为qbrc08d85da-69。
5）执行brctl show查看网桥qbr上的接口信息，找到tap设备和qvbXXXX接口。
备注：由于这些网桥均由Linux Kernel创建，所以使用brctl命令
# brctl show
qbrc08d85da-698000.3a04f8f4bda2noqvbc08d85da-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类型。
# lshw -class network|more
7）查看qvb接口的对端peer_ifindex:number。
# ethtool -S qvbc08d85da-69
NIC statistics:
peer_ifindex: 15
8）找到peer_ifindex:number对应的接口qvoXXX。
# ip link | grep 15:
15: qvoc08d85da-69: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master ovs-system state UP mode DEFAULT qlen 1000
link/ether 4e:99:15:01:1b:07 brd ff:ff:ff:ff:ff:ff
qvbXXX和qvoXXX是一对veth设备，成对出现的。可以根据ethtool -S 查看对端的number，并且根据ip link|number：查看到对应的veth设备名称（即qvo）。
qvb是quamtum veth bridge
qvo是quamtum veth open vswitch
qvoXXX设备连接到了Open vSwitch设备的br-int集成网桥上
9）通过Open vSwitch 中的命令ovs-vsctl port-to-br qvoXXX查看qvoXXX设备所属的bridge。
# ovs-vsctl port-to-br qvoc08d85da-69
br-int
10）查看所有的网桥
# ovs-vsctl list-br
bond-br
br-int
11）查看OVS Bridge上面有哪些端口
# ovs-vsctl list-ports br-int
int-bond-br
qvo077eac35-ed
qvo1ee66407-69
qvo40816622-cf
qvo849c4847-1e
qvoace90c57-d3
qvob0b730ab-79
qvob32e78ae-7f
qvoc08d85da-69
qvodec9ff3a-92
qvoe2028755-37
qvofb9c19ea-6a
tap52a2315f-19
tap63754766-e1
# ovs-vsctl list-ports bond-br
eth3
phy-bond-br
br-int和phy-bond-br端口是用来连接Open Vswitch设备的br-int和bond-br
（即br-ethX）网桥。另外，VLAN ID的转换是发生在br-int和bond-br网桥的端口br-int和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）。
# ethtool -S br-int
# ip link | grep number
13）查看phy-bond-br连接到的虚拟外部网桥。
# ovs-vsctl port-to-br phy-bond-br
bond-br
14）查看外部网桥bond-br（即br-ethX桥）上的端口：
# ovs-vsctl list-ports bond-br
eth3
phy-bond-br
关于本例子中的bond-br外部网桥和物理网口ethX的关系是：VM数据包要到外部物理网络中，必须依靠真正的物理网卡。
这种关联，需要通过手动方式创建，这里是：
# ovs-vsctl add-port bond-br eth3。
2. 小结
基于上述数据通信流程，这样整个VM的数据链路便完全打通了。从VM的端口到qvoXXX接口的信息及网桥和端口的连接情况，再结合tcpdump 命令查看网络流量和OVS OpenFlow协议能够清楚的掌握和梳理Neutron网络的连接架构，作为网络分析的依据，为故障排除提供坚实的基础。
个人简介
徐超：任职于九州云信息科技有限公司（上海），从事OpenStack相关工作。个人倾向于研究CI-CT-CD-CD。
注：
本文源自OpenStack中国社区与云头条、ZDNet\Solidot、CSDN、51CTO、infoQ、科技茱比莉、特大号、IDC圈等Top合作媒体联合举办的“我要直播奥斯汀”（http://www.openstack.cn/?p=4396）活动
保护期（2016.1.19-2016.1.26）内非合作媒体不得转载，媒体合作请联系： editor@openstack.cn
关注OpenStack 奥斯汀峰会，请关注关注我要直播奥斯汀”！
热门专题
