Neutron VXLAN/GRE模式中br-tun流表分析

一.前言

1. Neutron 概述

Neutron 的设计目标是实现“网络即服务”，为了达到这一目标，在设计上遵循了基于“软件定义网络”实现网络虚拟化的原则，在实现上充分利用了 Linux 系统上的各种网络相关的技术。

理解了 Linux 系统上的这些概念将有利于快速理解 Neutron 的原理和实现。

neutron中主要有br-int、br-tun和br-phy几个bridge。br-int是所有vm连的bridge，br-tun在使用tunnel的时候会用到，br-phy在使用vlan模式的时候会用到。

OpenvSwitch中 bridge 有两种模式：“normal” 和 “flow”。“normal” 模式的 bridge 同普通的L2交换机数据转发模式一样，而 “flow” 模式的 bridge 是根据其流表（flow tables） 来进行转发的。

Neutron 使用了两种 OVS bridge：br-int 和 br-tun。其中，br-int 是一个 “normal” 模式的虚拟网桥，而 br-tun 是 “flow” 模式的，它比 br-int 复杂得多。

2. Neutron涉及的网络技术

• bridge：网桥，Linux中用于表示一个能连接不同网络设备的虚拟设备，linux中传统实现的网桥类似一个hub设备，而ovs管理的网桥一般类似交换机。
• br-int：综合网桥，常用于表示实现主要内部网络功能的网桥。
• br-ex：外部网桥，通常表示负责跟外部网络通信的网桥。
• GRE：一种通过封装来实现隧道的方式。在openstack中一般是基于L3的gre，即original pkt/GRE/IP/Ethernet
• VETH：虚拟ethernet接口，通常以pair的方式出现，一端发出的网包，会被另一端接收，可以形成两个网桥之间的通道。
• qvb：neutron veth, Linux Bridge-side
• qvo：neutron veth, OVS-side
• TAP设备：模拟一个二层的网络设备，可以接受和发送二层网包。
• TUN设备：模拟一个三层的网络设备，可以接受和发送三层网包。
• iptables：Linux 上常见的实现安全策略的防火墙软件。
• Vlan：虚拟 Lan，同一个物理 Lan 下用标签实现隔离，可用标号为1-4094。
• VXLAN：一套利用 UDP 协议作为底层传输协议的 Overlay 实现。一般认为作为 VLan 技术的延伸或替代者。
• namespace：用来实现隔离的一套机制，不同 namespace 中的资源之间彼此不可见。

这里我们通过分析br-tun通道网桥来分析整个数据流向，其核心是流表。同时，以6个实验来予以分析。

3.注意

这里，我并不会给出命令的具体输出信息，并加以分析讲解，请见谅。有句古语说得很好，授人以鱼，不如授人以渔。——你需要自己去实践，结合其他知识去分析理解（这里具体是OpenvSwitch、OpenFlow）。

二. 实验

1.实验一  环境准备及初始化

1）在没有任何租户网络的情况下，网络节点上执行

# ovs-ofctl show br-tun

# ovs-vsctl show

2）查看openflow规则

# ovs-ofctl dump-flows br-tun

2.实验二  创建租户网络环境

1）通过上面的分析发现，第一阶段所有的数据包都会被丢弃，因为系统中目前还没有任何租户网络。接下来创建外部网络和租户网络环境，接着，我们执行如下命令来分析。

# neutron router-list
# ip exec qrouterXXXXXX route –n
# ip exec qrouterXXXXXX ifconfig

2）网络节点上

查看网络节点上的br-tun流表

# ovs-vsctl show
# ovs-ofctl show br-tun

3. 实验三  创建一个虚拟机

1）计算节点上，分析隧道端口（VTEP）

# ovs-vsctl show

# ovs-ofctl show br-tun

2）租户中的Linux network namespace，注意qrouter和qdhcp的MAC地址

# Neutron router-list
# ip netns
# ip netns exec qrouterXXXX ifconfig
# ip netns exec qdhcpXXXX ifconfig

3）当在计算节点上启动虚拟机时，流表情况如下

# ovs-ofctl dump-flows br-tun

4）当在计算节点上启动完虚拟机时，流表情况如下

# ovs-ofctl dump-flows br-tun

5）查看网络节点上面的流表情况

# ovs-ofctl dump-flows br-tun

6）从中，我们可以看到网络节点上同样也增加了同计算节点上类似的规则

# brctl show
# ifconfig qbrXXXXX
# ifconfig qvbXXXXX

这里，我们可以发现这些规则上的“dl_dst”目的 MAC地址是计算节点上qbr和qvb的MAC地址。

8）虚拟机启动完毕时，查看网络节点的流表情况

# ovs-ofctl dump-flows br-tun

4.实验四  虚拟机向外发送单播包

在虚拟机中，发送单播包，ping往qrouter的qg IP地址

4.1在网络节点上 

1）查看qrouter NameSpace中的qr、qg设备及其IP地址

# ip netns exec qrouterXXXXX ifconfig

2）ping 往qg的 IP地址

# ip netns exec qrouterXXXXX ssh vm_username@vm_ip
$ ifconfig –a
$ ping qg_ip

3）   查看网络节点上的流表情况

# ovs-ofctl dump-flows br-tun

4）查看虚拟机所在的宿主机，即计算节点上的流表情况

# ovs-ofctl dump-flows br-tun

4.2 虚拟机中的单播包通往router的过程

第一阶段：在虚拟机的宿主计算节点上的处理过程

# brctl show

# ovs-ofctl show br-tun 

# ovs-vsctl show

第二阶段：在网络节点上的处理过程

# brctl show

# ovs-ofctl show br-tun

# ovs-vsctl show

注意：

经过一段时间后，网络节点和计算节点上面新增的br-tun流表table=20的规则会自动消失。

5.实验五  外部向虚拟机发送数据包

小实验（1）

在网络节点上，直接通过Linux network namespace 向虚拟机发送icmp包

# ip netns exec qrouter-XXXX ping VM_ip

再来查看网络节点和计算节点上面的br-tun流表，发现并没有任何变化，现在的状态与实验四的结果是一样的。

小实验（2）

为VM虚拟机分配一个floating ip，然后在另一个计算节点上面，通过floating ip向虚拟机发送icmp数据包。

小结

实验发现，无论在哪里直接ping 虚拟机的floating ip，其效果与上面的小实验（1）几乎完全相同，各物理节点上的br-tun流表并没有发生任何变化，详细过程表述如下。

第一阶段：网络节点上的处理过程

# ovs-ofctl show br-tun 

# ovs-vsctl show

# ovs-ofctl dump-flows br-tun

第二阶段：计算节点上的处理过程

# brctl show

# ovs-ofctl show br-tun

# ovs-vsctl show

# ovs-ofctl dump-flows br-tun

6. 实验六  虚拟机与虚拟机之间发送数据包

在另一个计算节点上，创建一个虚拟机。然后在两个虚拟机之间互相ping，观察br-tun 流表变化。

小结

至此，我们的整个基于GRE/VXLAN的Neutron隧道网络的VM数据流便分析完了。