基于OpenDayLight的SDN网络转发机制研究

网络
SDN无疑是当前网络业界最热门的研究课题之一,SDN体现了控制和转发相分离的原则,为网络和业务的创新带来了蓬勃的生机和活力。本文通过构建OpenDayLight控制器与Mininet交换模拟器相结合的测试环境,研究了SDN环境下二/三层网络交换的转发机制和特性,并对SDN在网络中的应用提出了设想。

 SDN无疑是当前网络业界最热门的研究课题之一,SDN体现了控制和转发相分离的原则,为网络和业务的创新带来了蓬勃的生机和活力。本文通过构建OpenDayLight控制器与Mininet交换模拟器相结合的测试环境,研究了SDN环境下二/三层网络交换的转发机制和特性,并对SDN在网络中的应用提出了设想。

一.SDN实验环境的选择和建立

软件定义网络(Software Defined Network, SDN)最早由斯坦福大学clean slate研究组提出。SDN的核心是控制与承载相分离,实现网络开放,使流量可以被灵活控制,从而为上层的业务和应用提供更优化的服务。SDN的概念提出后,迅速得到了各方面的响应,在IT界、网络届掀起了一股热潮。2010年,开放网络基金会ONF成立,ONF致力于开发OpenFlow协议,以规范控制器与交换机之间南向接口标准化,目前最新发布的版本为1.4。

在控制器方面,借鉴在IT和互联网上的成功经验,开源成为一股不可抵挡的趋势。NOX,POX,Floodlight等均采用公开源代码的形式,任何人都可以学习SDN,只要有相应的IT编程能力,都可以为SDN的控制器的完善做出贡献。各大设备厂商也正视SDN的挑战,2013年4月IBM、Cisco、微软、NEC、Juniper、BigSwitch(后退出)等多家IT巨头合作启动了OpenDayLight项目。OpenDayLight采用JAVA开发,是一套开源的SDN框架。其初期版本已经发布,本次实验使用的就是这个版本。该版本支持简单转发应用(Simple Forwarding),可以支持二/三层转发。

光有控制器还不能构成完整SDN网,但当前硬件SDN交换机还很少,也很难找到。幸好有Mininet推出了基于软件模拟的交换机。Mininet项目也是开源的软件,通过Mininet,在一台Linux主机内可以构造并模拟多台SDN交换机和终端。使用Python脚本,使用者还可以配置较为复杂的SDN网络拓扑结构。同时Mininet还配备了WireShark抓包软件,方便SDN开发者和学习者进行开发和研究。

二.OpenDayLight SDN二/三层转发机制分析

1)创建和启动SDN网络拓扑结构

在测试中我们创建了如下的网络拓扑结构,1台OpenDayLight控制器(简称Controller,版本为0.1版),2台交换机(SW),每台SW分别连接2台主机(Host),一共4台主机,这些主机分属于2个不同的网段,交换机与控制器之间采用OpenFlow协议(简称OF)。拓扑结构如图所示:


图1:测试拓扑结构

首先在测试机(Windows XP系统)上安装和运行OpenDayliht(具体可参考https://wiki.opendaylight.org/view/OpenDaylight_Controller:Installation),然后在VirtualBox[4]中载入Mininet虚拟机映像并运行(具体可参考http://mininet.org/download/)。测试网络的拓扑结构由Python脚本生成,可将配置文件保存于虚拟机/mnt/shared目录下的topo2_2.py文件内:

启动测试环境,使用以下命令生成测试拓扑结构: sudo mn –custom /mnt/shared/topo2_2.py –topo mytopo,–controller=remote ip=192.168.56.1。

通过启动抓包软件WireShark可以看到SW向Controller的注册过程。在注册过程中,Controller会要求SW提供OpenFlow版本号,设备连接的端口等状态等信息。如图所示:SW1将自己所连接的4个端口情况上报给Controller(其中包括与Controller相连的端口),同样SW2也会上报自己的状态。

图2:SW通过OF:Stats Relay向Controller上报自身的状态和接口

当SW 设备完成设备注册后,Controller将进行网络拓扑结构的发现或更新。当网络中有一台新的SW接入后,Controller通过OF Packet Out 指令要求SW1在其所有端口上发出LLDP(Link Layer Discovery Protocol,EEE802.1ab)链路探测包。LLDP的源MAC为Controller分配,这里为00:00:00:00:00:01(对每一个交换机,Controller都会分配一个这样的MAC作为SW标识),LLDP目的MAC地址为组播地址。相邻的SW2将接收到LLDP,SW2由于无法识别这条流,会将OF协议再发到Controller上。通过LLDP的发送和接收,Controller可计算出交换机之间的拓扑关系,网络的拓扑关系可作为转发流表生成和实现网络可视化的基础。(注:与交换机SW相邻的主机也会收到LLDP,但并不会处理)


图3:基于LLDP探测的网络拓扑发现与计算

2)SDN网络二转发机制

生成网络拓扑后,还要在Controller上为每一个三层网段设置一个网关地址(即使是二层转发也必须设置),然后将交换机的接口与三层网关相关联。这里将SW1的2号(连接h1)和SW3的2号口(连接h2)分别与网关10.0.0.254关联,将SW1的3号(连接h3)和SW3的3号口(连接h4)分别与网关20.0.0.254关联。这一过程好比在SDN内划分了不的三层网段,并将设备物理接口与三层对应,类似为以太网划分VLAN和增加三层虚接口的过程。

图4:在OpenDayLight Web界面将交换机的端口与三层网关相关联

然后对各个Host的主机IP地址、子网掩码和默认网关进行逐一设置,在Mininet提示符mininet>下如下设置:

接着让Host1 PING Host2,输入h1 ping h2,同时使用抓包软件可得到如下的过程:


图5:OpenDayLight SDN二层转发机制图解

在SDN网络中,处于末端的主机Host并不会知道其连接的网络是SDN,某台主机要发送数据包到另一台主机,仍然需要进行IP到MAC地址的ARP解析。但SDN的处理机制与普通二层以太交换机洪泛+MAC地址学习机制存在却存在很大的差异,其过程如下:

当源主机h1(10.0.0.1)发出ARP解析h2(10.0.0.2)后,交换机SW1并不知道如何转发该包,因此将其通过OF消息发送到Controller处理。

Controller发现这个ARP消息是h1(10,0,0.1)发出,它也同时得到了h1的位置信息(OF包中会指出是哪个交换机的哪个端口发出了数据包)。此时Controller可以计算网络拓扑,得到全网各节点到10.0.0.1的转发路径,并将转发流表通过OF Flow Modify消息推送到每一台交换机上。

由于收到了ARP,Controller会要求每一台SW所对应10.0.0.0/8网段的非SW互联端口(只有这些端口是连接主机或传统网络的)发出ARP来请求10.0.0.2的MAC地址。这里Controller并不是简单的将收到ARP原封不动的发出,而是将源IP改为10.0.0.254,也就是前面我们在Controller上配置的网关IP地址,然后发出。

只有h3(10.0.0.2)才会响应ARP,它将ARP Response发送到SW2。SW2也不知道如何处理,因此将ARP封装在OF协议中发送到Controller。Controller发现这是ARP响应,而之前正是10.0.0.1发送的ARP请求,因此它会将该ARP通过OF协议发到SW1,同时指示SW1将其送出的端口(也就是h1对应的端口)。SW1执行这一操作。

Controller在收到h3的ARP后也得知了10.0.0.2的位置,它根据网络拓扑计算,可以得到全网到达10.0.0.2的转发路径,并将流表通过OF Flow Modify消息推送到每一台交换机上。

h1 收到ARP Response后完成ARP解析过程,然后它构造ICMG PING Request数据包,其中源和目MAC分别为h1和h2的MAC,源和目IP分别为h1和h2的IP。由于SW1和SW2都已经成功的装载了到h2(10.0.0.2)的流表,因此该数据包将被顺利发送到h2。

h2发现是ICMP PING Request,源是h1,但是此时它尚未有h1的MAC,于是还要进行一次ARP解析,SW2再次将ARP发送Controller,Controller已经得知h1的MAC,可直接响应,并通过OF向SW2返回ARP结果和所需要送出的端口(h2接入的端口)。

h2学到ARP后,即可构造ICMP Response包,发送到SW2,SW2根据h1目的地址匹配转发表将其转发到SW1,SW1根据h1目的地址匹配转发表将其发送到h1对应的端口。h1到h2的双向通道至此完全打通。

3)SDN网络三层转发机制

在分析完二层转发机制后,我们重新启动拓扑结构,回到初始状态(交换机上无任何流表),测试一下SDN如何实现两个不同网段主机之间的转发。输入h1 ping h4,同时使用WireShark抓包,可发现如下结果:

对于三层转发,主机首先判断目的IP与自己不在同一网段内,因此要将数据包发向默认网关,在此之前它必须解析网关的MAC。h1发出 ARP,请求网关10.0.0.254的MAC。SW1不知道如何处理,将其通过OF协议发送到Controller。

Controller上配置了网关地址10.0.0.254,它即以自己的MAC地址回应ARP,并指示SW1将ARP响应发送到与h1相连的接口。同时Controller也知道了h1的存在,通过路径计算,得到每一台交换机去往10.0.0.1的路径,并通过OF Flow Modify将流表推送到每一台交换机上。

主机h1收到网关的ARP,它构造ICMP PING Request数据包,其中源和目MAC分别为h1和网关10.0.0.254的MAC,源和目IP分别为h1和h4的IP,此包发向SW1。

SW1上并没有到达20.0.0.2的流表,因此将缓存这个数据包。同时SW1则也会将该包通过OF协议发送到Controller,Controlller发现该包是要去向20.0.0.2,而此目的主机位置未知。因此Controller会要求每一台SW的对应20.0.0.0/8网段的非SW互联端口发出ARP来请求20.0.0.2的MAC地址,其中ARP的源IP为20.0.0.0/8的网关地址20.0.0.254。

只有h4(20.0.0.2)才会响应ARP,它将ARP Response发送到SW2。SW2不知道如何处理,因此将ARP封装在OF协议中发送到Controller。Controller接到这个ARP响应,也同时得到了h4的位置是处于SW2的某一端口之下。Controller通过路径计算,得到每一台交换机去往20.0.0.2的流表,并通过OF Flow Modify消息推流表到每一台交换机上。

SW1在装载流表后可向正确的接口上转发之前缓存的ICMP数据包,当然SW2也可顺利转发。SW2还会该ICMP包的目的MAC地址修改为h4的MAC,以确保主机正确接收(之前Controller下发的目的地址10.0.0.1流表中已指出这个操作)。

图6:对20.0.0.2目的地址的流表下发

注:对与主机相邻的交换机SW不仅要指该主机所对应流的出端口,还需要对目的MAC地址进行改写以匹配主机MAC,因此下发的流表内有2个动作(Action),对于二层转发亦然

此时h4会收到ICMP Request,它发现是不同网段主机发出的ICMP请求,因此仍要通过ARP解析出自己的默认网关。此请求发送到SW2后仍要通过OF协议转发到Controller,Controller用自己的MAC进行响应,然后通过OF协议发往SW2,并最终发送到h4。

主机h4收到ARP后可构造ICMP PING Response,其中源和目MAC分别为h4和网关20.0.0.254的MAC,源和目IP分别为h4和h1的IP。此包发向SW2,然后经过SW1,同样SW1在将其转发到目的端口前会将目的MAC地址修改为h1的MAC。之后h1和h4之间的通道被完全打通。


图7:OpenDayLight SDN三层转发机制图解

当网络的所有主机都完成一次的通信后,SDN控制器就感知了所有网络节点的状态。通过控制器提供的界面,可以看到网络的可视化视图(http://192.168.56.1:8080),与我们之前给出的网络拓扑完全一致!

图8:SDN的网络拓扑,由OpenDayLight SDN控制界面绘出

让我们观察一下各交换机上的流表,可见每个交换机装载了正确的流表。随后SW将定期向Controller汇报流的状态,如匹配流的数量,转发的字节数量、生存时间等。这些流和它们的状态在OpenDayLight的控制台上都可以看到:

SDN内网络交换机的转发流表

4)特殊网络结构下SDN的转发能力分析

在传统的以太网中,是不能存在环路的,即使有环路,网络设备也将通过生成树协议Spanning Tree进行屏蔽。OpenDayLight控制器具有网络拓扑的发现功能,在其算法中也能避免环路的产生(使用的是最短路径优先算法,但在测试中仍无法支持等价路径负载均衡)。

如图在测试中构建了5台交换机(SW1-SW5)和5台主机(h1-h5),连成环形拓扑。通过测试表明,主机之间流量转发正常,并没有广播风暴和环路出现,查看各交换机的流表,均显示到目的地址采用的是最短路径。


图9:OpenDayLight SDN支持有环路的二层网络拓扑结构

此外,OpenDayLight控制下的SDN网络还可支持以静态路由方式与外部网络互通,但由于本次测试是基于软件交换机的模拟,因此无法测试该功能。

三、总结

基于对OpenDayLight控制下SDN网络转发行为分析可以看到:

OpenDayLight的简单转发功能以整网的拓扑结构为基础,Controller通过处理主机之间、主机与网关之间的ARP报文来获得每一台主机的位置,并采用最短路径优先算法计算到达目的主机的流表,并下发到网络内的各个交换机上。

在OpenDayLight的简单转发功能中,流仅仅基于目的IP地址进行配,而不是所有的5元组字段以及优先级字段(当然也可以选择5元组),这点更贴近传统三层设备,可以大大减小了流表的规模,更为贴近实际生产环境。

OpenDayLight不仅可以支持二层转发还可支持三层转发,避免了环路和广播风暴,优于目前其它类型开源SDN控制器所能提供的转发功能。

OpenDayLight实现了控制和承载相分离,网络上已经没有二/三层设备之分,网络充分扁平化。因此在同一SDN内,理论上可以在允许的地址范围内为主机分配任意可用的IP地址。这种做法解除了主机位置与IP网段物理位置的紧耦合(有点类似LISP,Location-ID Separation Protocol),避免了IP地址段的碎片不能得到利用的尴尬。同时交换机与交换机之间也无需配置大量互联IP地址,又节约了地址空间。

OpenDayLight支持与外部非SDN网络的二/三层互通。

综上所述,OpenDayLight的基本版已经实现了传统二/三层交换机的基本转发功能,并支持任意网络拓扑和最优路径转发,达到了实用阶段。2013年年底,OpenDayLight的完整版本将发布,届时将提供更好的多租户支持(Tenant),更好的网络可视化(Network Virtualization)能力,实现LISP、BGP、Firewall等网络应用,成为一款控制能力足以与传统网络设备匹敌的SDN控制器。

未来网络软件化的趋势将不可阻挡,SDN将在支持数据中心虚拟化、城域网二/三层转发和VPN、网络安全和流量清洗方面大放异彩。

责任编辑:林琳 来源: SDNAP
相关推荐

2015-12-07 17:07:36

SDN网络流量

2015-06-23 11:01:52

云计算资源池软件定义网络

2013-04-10 09:43:38

网络巨头OpenDaylighSDN

2013-04-10 16:04:22

SDNOpenFlowOpenDayligh

2014-02-09 09:53:37

2013-05-06 09:26:40

标准组织OpenDaylighSDN

2013-12-11 13:18:32

SDN软件定义网络OpenDayligh

2014-06-19 09:42:04

开源SDNOpenDayligh

2013-10-08 10:13:41

SDNOpenDayligh

2013-04-25 10:42:44

2013-09-22 09:39:16

SDN控制器SDN软件定义网络

2013-05-13 10:35:37

思科IBM微软

2015-03-31 16:45:22

2020-04-08 10:02:40

SDNOpenFlowOpenDayligh

2012-12-31 09:49:44

SDN软件定义网络

2013-04-19 11:00:02

SDNLTEHaul移动回传网络

2014-02-27 09:47:03

三层网络转发网络拓扑

2017-12-22 23:12:44

SDNIBN基于意图的网络

2014-06-27 14:49:41

SDN

2015-09-17 14:54:07

SDNNFV网络架构
点赞
收藏

51CTO技术栈公众号