第五章 OpenStack的NFV虚拟网元网络实现

在解决网络连通性时，首先分析Neutron网络，通过对NameSpace的Tcpdump抓包，分析流量的Drop的位置。分析Neutron的组件Linux bridge，在Linux bridge上存在iptables对流量的控制机制。 进而编写分析特定的生效的iptables条目的Python脚本，实现自动化删除阻碍流量的iptables。

5.1 OpenStack Neutron网络

针对网络连通性根据图中思路分析，进行Neutron网络，NameSpace，Linux bridge，iptables以及工具Tcpdump的组合分析，找到解决网络连通性的方法。

图5-1 网络连通性分析图

[8]在 Horizon上创建Neutron网络过程如下：首先管理员拿到一组公有IP地址，并且创建一个外部网络和子网。租户创建一个网络和子网。租户创建一个路由器并且连接租户子网到外部网络。

在虚拟网元在OpenStack中孵化成功之后，位于不同Subnet上的VyOS或者OpenWRT再Libvirt的XML文件中可以看到已经拿到了vNIC，在NFV虚拟网元的操作系统中进行网卡的配置后，通过OpenStack的DHCP的port可以得到相对应得IP地址。由于NFV的虚拟网元是连接OpenStack中2个及以上子网数量的，因此路由表中需要对路由转发等策略进行相应的配置。

而在NFV虚拟网元成功启动之后。不同子网的虚拟路由器之间不能相互通信。考虑到OpenStack的Neutron的Vlan Tag导致的不能用VyOS去ping通不同网段的设备。在VyOS不同的网段ping不通的结果下。分析了VyOS和OpenStack的问题、多个VyOS在Virtualbox里网络设置成“混杂”模式可以正常使用，但是在OpenStack中无法使用的情况。

分析Neutron的网络：

图5-2 虚拟网元流量分析图

图中NFV虚拟网元流量从vm01到vm02需要通过eth0，到vnet0，接着通过qbr(Linux bridge)，再经过一对虚拟接口qvb以及qvo。然后到达OpenvSwitch，从br-int经过int-br-eth，接着经过物理网络之后就向上经过同样的虚拟设备最后到达vm02。由图中可见，流量在经过eth1时进行了vlan的tag转换，因此vlan不是影响跨网段Instance连通性的障碍。

在OpenvSwitch的结构图中存在许多veth端口和Linux Bridge形式的br-int，那么在veth的成对出现的接口上，可以被视作一根“网线”。而在br-int的Linux Bridge上默认作为桥接作用（初始化的OVS）。

在OpenStack的插件中使用的是OpenvSwitch(OVS)，在流量的分析中经过了OpenvSwitch，而流量经过qvo的veth之后就进入到OpenvSwitch了，而初始化的OpenvSwitch没有配置任何的策略，可以被视作一根“网线”。

图5-3 OpenvSwitch结构图

5.2 NFV 虚拟网元的Namespace

[9]NFV虚拟网元连接不同网络之间的路由通信：在Neutron上每创建一个网络都会新建一个Network NameSpace服务，Namespace是网络隔离的一种表现形式，那么现在假设有了两个网络，也就有了两个Network NameSpace，但是这两个NameSpace是相互独立的，因为他们在不同的网络中。现在如果想打通这两个网络，我们就需要另外一个Network NameSpace——Router Network NameSpace，Router Network NameSpace可以拥有2个以上的网络接口。在传统的网络环境中，我们知道如果要和一个网络通信，只要和其网关相通就可以了。在这里也是采用这样的原理，在Neutron中我们可以使用命令将两个需要相互连通的网络加入到Router Network NameSpace中，这时Router Network NameSpace中就会出现两个网络接口连接到OVS bridge-int上，并且这两个网络接口的IP地址就是两个网络的网关。除此以外，我们需要在Router Network NameSpace中设置net.ipv4.ip_forward参数为1，这样就可以在Router Network NameSpace内部进行不同网段数据的转发，至此两个不同网络就可以打通了。

如果启动一个OpenStack的L3-agent。那么OpenStack后台是这样的命令

图5-4 OpenStack L3-agent NameSpace连接方式

如果NFV的虚拟网元（VyOS、OpenWRT）作为Instance启动，那么OpenStack后台是这样的命令，创建虚拟网元的Namespace然后去连接qrouter的Namespace。

图5-5 OpenStack NFV虚拟网元 NameSpace连接方式

那么Instance的Namespace和OpenStack L3-agent所创建的Router拥有不一样的Namespace的标示符和连接方式。

Openstack不认为作为Instance启动的VyOS给分配一个Router类型的NameSpace。因此作为Instance启动的NFV虚拟路由器和OpenStack本身的路由器的不同点主要是qrouter的Namespace是使用“qr”虚拟网络组件进行连接的，而作为Instance启动的NFV虚拟路由器的Namespace是通过Linux bridge的“qbr”进行连接的。那么总结起来，不同点就是Namespace的连接方式上，即Linux bridge的连接导致的网络通信中断。

5.3 Neutron网络流量定位

在OpenStack中可以使用Tcpdump工具进行流量的监控：

看Namespace更细节的信息：（netns即是namespace）

通过Namespace进行网络连通性检查：

流量从vm01到vm02需要通过eth0，到vnet0，接着通过qbr(Linux bridge)，再经过一对虚拟接口qvb以及qvo。然后到达OpenvSwitch，从br-int经过int-br-eth，接着经过物理网络之后就向上经过同样的虚拟设备最后到达vm02

图5-6 L3-agent NameSpace网络监测

Debug流量在哪里被Drop

找到虚拟机对应的虚拟接口：

图5-7 NFV虚拟网元NameSpace网络连接监测

在实验过程中qbr上可以监测到OSPF的hello包，由于NFV虚拟路由器中已经配置了OSPF的路由协议，因此会广播hello包。由于在实验连接vm02中qbr上收到了来自vm01的OSPF的hello。那么可以得出结论。包已经经过了连接vm01的虚拟接口，Linuxbridge形式的qbr以及经过了OpenvSwitch，从而到达了连接vm02的Linuxbridge形式的qbr。

包已经到达了连接目的cirros(vm02)的那段的qbr7b85ad99-9f。从qbr之后到vm02这段流量被Drop了，在连接vm02的qbr上可以tcpdump到包，在连接vm02的eth上却tcpdump不到任何信息。那么qbr是一个Linux bridge，经查证Linux bridge上存在iptables把流量给Drop掉了。有了这个现象就在compute节点的iptables上把两个drop的iptable删除。两个网段的NFV虚拟网元之间就可以ping通。

其中在qbr中有iptables的安全策略隐藏在Linux bridge中。这个是OpenStack的网络保护机制，为了防止恶意租户的sniffer。这个安全机制在OpenStack的security group的设置中是不能被找到的，即使把IP包都设置成Forward模式，这些不同网段的Instance之间的ICMP包或者其他类型的包还是会被Drop掉。因此可以说这个安全机制是“隐藏”的。

Openstack内部本身的Router是之间用qr接口直接连接到br-int上的，因此是绕过了qbr上的iptables策略。整个过程可以在上一节的Namespace中得到证明，所以两个连接Router的Instance能够进行通信并ping通。

5.4 隐藏的iptables安全机制

iptables的安全机制是基于Linux系统上。它可以定义多个规则，将规则串起来，就可以组成一个规则列表来实现绝对详细的访问控制。OpenStack使用iptables中的filter和NAT的状态表。[10]每个表含有一些内置链，并且还可以包含用户定义的链。每个链中可以有一个规则列表。每个规则指定对包做特定的操作，如Forward，Drop等。

nova-compute主机上的这些规则允许 VM 与nova-network主机以及其他计算主机上的VM相连接。

但是这些规则仅限于同一个OpenStack子网上连接的Instance（NFV虚拟网元），而对于同时连接多个子网的NFV虚拟路由器，OpenStack是直接Drop的。对于每个实例，它都会在此 filter 表内创建一个链及一些规则（参见图5-3）

在OpenStack中启动NFV虚拟路由器之后，Nova组件孵化了一个实例。nova-compute为每个实例创建一个链。在图中则是每个Instance实例（NFV虚拟网元）iptables所创建的链和规则。链的名称是 nova-compute-inst-1。

图5-8 实例的链和规则

在OpenStack的实例对应iptables所创建的链和规则来看有以下几个特点：
1.所有针对此实例的流量，无论是转发而来的还是从本地过程生成的，都会进入此实例的特定链。
2.所有来自该实例所在的子集的IP的流量都是允许的。
3.所有来自特定DHCP服务器的DHCP流量都是允许的。
4.所有其他流量均放弃（Drop）。

图5-9 iptables的应用

那么对于连接多个OpenStack子网的Instance（NFV虚拟网元）是对应第4点，所以所有到另一个OpenStack子网的Instance（NFV虚拟网元）的全部流量被iptables所Drop。具体表现就是两个虚拟网元之间不能进行通信。

如果把对应的iptables删除之后，虚拟网元通过整个Neutron网络的连通性便得到了解决。可以看到VyOS（或者OpenWRT、vSTC）成功地转发了包。

以下是一个可以自动寻找生效的iptables的Python脚本：
Debug到底是哪一条在生效：

图5-10 特定NFV虚拟网元的iptables的定位

5.5小结

NFV虚拟网元作为Instance孵化的同时Openstack不认为作为Instance启动的VyOS给分配一个Router类型的Namespace。其中在连接Instance的Linux Bridege中有iptables的安全策略隐藏。这个是OpenStack的网络保护机制，为了防止恶意租户的sniffer。而Openstack内部本身的Router绕过了iptables策略，使得连接到这个路由器的流量得以转发。而删除对应Drop的iptables链的规则之后，不同OpenStack子网的虚拟网元之间的网络连通性便可以得到解决。

第六章 虚拟实验室测试实现及Kilo版本更新

在解决OpenStack的虚拟和化网络连通性之后，可以对VyOS或者OpenWRT虚拟路由器网元进行RIP和OSPF等网络协议的配置，可以满足网络工程的师生们能够进行“路由与交换”的实验的需求，通过Spirent的Velocity界面的虚拟资源的编排和Spirent TestCenter Virtual（vSTC）虚拟网元组网，最后通过Spirent TestCenter的界面进行经测试打流，生成测试报告。可以满足网络工程的师生们进行“网络性能测试”实验的需求。最后的测试说明了该虚拟实验室的功能和性能已经达到了要求。

6.1 OpenStack测试方法实现

将OpenStack云平台上启动多个Intance（NFV虚拟网元），相互之间能够ping通，而且Instance在绑定Floating ip之后能够访问外网，即可以说明OpenStack云平台正常工作。

在仿真的测试过程中，可以在OpenStack搭建的云计算平台上，使用NFV虚拟网元（VyOS、OpenWRT）等虚拟的路由器进行组网，在拓扑搭建完成之后，可以配置相关的路由协议（RIP、OSPF等），实现复杂网络的连通性。在网络测试方面，利用Spirent TestCenter虚拟接口工具在拓扑的两端接入，发送流量包，对中间组网的虚拟网络设备进行功能和性能的测试。

6.2 Spirent Velocity实现接入界面

Spirent Velocity基于云计算的设计无缝地集成了Spirent TestCenter Virtual和Spirent Avalanche Virtual测试设备，Velocity通过调用OpenStack的接口，实现对OpenStack的资源编排，并且提供更高效的资源占用的方式，用户可以使用“拖拽”NFV虚拟网元的方式组件网络，并且保存已经存在的拓扑，针对每一个独立的拓扑环境设置用户所需要Reserve的时间。到时间结束之后，Velocity会自动删除拓扑中的资源，把资源返回给OpenStack资源池。而删除资源并不会影响本身所保存的拓扑。在Velocity中可以调用在OpenStack的Glance中的Spirent TestCenter Virtual（vSTC）,通过vSTC与NFV虚拟网元的联合组网，可以满足网络工程的“路由与交换”实验以及“网络性能测试”等实验课的需求。Velocity作为温州大学虚拟实验室的WEB接口，用户通过用户名和密码登录。

图6-1 学生Web界面

6.3 Spirent TestCenter测试实现

Spirent TestCenter的界面，进行流量通过NFV虚拟网元的打流测试。

图6-2 Spirent TestCenter的界面

测试是基于RFC2544协议的。RFC2544协议是RFC组织提出的用于评测网络互联设备的国际标准。吞吐量测试是被测设备在不丢包的情况下，所能转发的最大数据流量。用户以一个用户定义的恒定速度发送，然后通过二分查找算法找到一个不丢包的速率。结果是在不同的帧长下每秒的吞吐量。常见的帧长有 64，512，1024,1518字节等。流量通过VyOS的测试结果如图6-3。

图6-3 VyOS吞吐量测试报告

这样整个虚拟实验室的NFV虚拟网络的功能和性能已经满足了上述的需求。

6.4 OpenStack kilo版本的port-security

在OpenStack的kilo版本加上了ML2PortSecurityExtensionDriver，在OpenStack的NFV的虚拟网元的流量便可以相互之间进行包的通信。

在 /etc/neutron/plugins/ml2/ml2_conf.ini 添加如下配置：

在创建网络时需要加上port-security参数：
创建network：neutron net-create net2 --port-security-enabled=False

给network分配地址：neutron subnet-create net2 7.7.7.0/24 --enable-dhcp=True --name subnet2

创建port，并且把security-group disable掉：neutron port-create net2 --no-security-group

在port上启动instance：nova boot --flavor 1 --key_name oskey --image 405fb039-0df0-4c5d-aea6-7a472e5ec553 --nic port-id=92eb7fc3-6e11-487e-8d62-2ffc51a6ee00 openwrt1

port-security状态False之后，iptables则不需要删除。

第七章 总结

7.1虚拟云平台NFV实验室有效性及前景

仿真软件不能进行实验的统一管理，不能进行“网络测试分析”实验课。物理实验室网线部署和设备的部署增加了运维；物理设备价格昂贵且容易宕机需要部署虚拟环境云计算OpenStack平台，并且使用价格便宜的x86服务器支持NFV虚拟化网元（VyOS、OpenWRT），在网络测试方面需要引进测试的NFV虚拟网元（vSTC）；而云计算平台与NFV虚拟网元的结合需求的难点主要有虚拟化和网络连通性两个方面，在本文中得到了有效和解决和研究，得到了较好的阐述，在用户WEB接口方面使用了Spirent的Velocity进行资源的管理和调度。

图7-1 虚拟实验室整体架构

最后针对对整个环境进行测试，保证虚拟实验平台的可用，这样可以使得网络工程的师生们能够进行“路由与交换”的实验和进行“网络性能测试”的实验。

提供了在满足开课条件下的实验过程中的统一管理、人性化界面、虚拟化增加资源利用率、NFV虚拟网元节省成本、减少运维工作量等多方面的优势。

7.2 收获和缺陷

这半年多的学习一路走来也并不是一蹴而就。毕业设计使用的技术，很多都不了解，一开始的时候也不知道怎么做规划做设计，一股脑的部署实施，发现有错误无法继续，整个平台推倒重新开始，这样往复几次，我基本掌握整个OpenStack平台的架构和各个组件的功能。在整个过程中，如何将跨OpenStack子网的NFV虚拟网元（虚拟路由器）在OpenStack发挥作用进行了底层的详细的分析，让我对OpenStack也有了很深入的了解。在这次毕业设计中，我掌握了如何在面对新技术时应该如何去查阅资料，和利用学过的基础知识进行推导，提高了自己的学习能力。在查阅大量英文文献时候提高了自身的英文水平。在与导师进行交流的过程中，提高了自己的沟通能力。在完成毕业设计论文中，提高了自己的写作能力。

不管做什么事情总会有不足的地方。这次的毕业设计作品也还是存在一些不足之处，从整个云平台来说没有加入很好的虚拟机备份机制，没有做好OpenStack服务监控措施，NFV虚拟网元作为Neutron的Plugin更为妥当，这些都是值得我今后去学习和完善的地方。

作者简介：蒋暕青@上海宽带技术及应用工程研究中心：SDN技术实践者，大四北上思博伦实习半年，现工作地点上海

注：投稿文章仅出于传递更多信息之目的，系SDNLAB《原创文章奖励计划》的投稿文章，仅供参考，不代表证实其描述或赞同其观点，投资者据此操作，风险自担；技术问题请留言指正。