SDN网络转发机制研究和应用场景分析

胡晓宇中国电信股份有限公司上海分公司网络操作维护中心



SDN网络转发机制研究和应用场景分析

胡晓宇
中国电信股份有限公司上海分公司网络操作维护中心

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

关键字：SDN OpenDayLight Mininet 二/三层交换

1　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），可以支持二/ 三层转发，而目前其它开源控制器仅见有支持二层 转发的能力。可见OpenDaylight已经开始领先。

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

2　基于Opendaylight的SDN网络转发机制分析

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

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

首先在测试机（Windows XP系统）上运行run.bat 批处理文件启动OpenDayLight，然后在VirtualBox中载入Mininet虚拟机映像并运行。测试网络的拓扑结构由Python脚本生成，文件保存于虚拟机 /mnt/shared目录下的topo2_2.py文件内：

from mininet.topo

import Topo class MyTopo（Topo）：

“Simple topology example.”

def __init__（self）：

“Create custom topo.”

# Initialize topology

Topo.__init__（self）

# Add hosts and switches

Host1 = self.addHost（‘h1’）

Host2 = self.addHost（‘h2’）

Host3 = self.addHost（‘h3’）

Host4 = self.addHost（‘h4’）

Switch1 = self.addSwitch（‘s1’）

Switch2 = self.addSwitch（‘s2’）

# Add links

self.addLink（Switch1，Switch2 ）

self.addLink（Switch1，Host1 ）

self.addLink（Switch2，Host2 ）

self.addLink（Switch1，Host3 ）

self.addLink（Switch2，Host4 ）

topos =｛‘mytopo’： （lambda： MyTopo（））｝

启动测试环境，使用以下命令生成测试拓扑结构：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也会上报自己的状态。

当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，但并不会处理）

2.2SDN网络二转发机制

生成网络拓扑后，还要在Controller上为每一个三层网段设置一个网关地址（即使是二层转发也必须设置），然后将交换机的接口与三层网关相关联。这里将SW1的2号（连接h1）和SW3的2号口（连接h2）分别与网关10.0.0.254关联，将SW1的3号（连接h3）和 SW3的3号口（连接h4）分别与网关20.0.0.254关联。这一过程好比在SDN内划分了不的三层网段，并将设备物理接口与三层对应，类似为以太网划分 VLAN和增加三层虚接口的过程。然后对各个Host的主机IP地址、子网掩码和默 认网关进行逐一设置。在Mininet提示符mininet>下如下设置：

h1 ifconfig h1-eth0 10.0.0.1 netmask 255.0.0.0

h2 ifconfig h2-eth0 10.0.0.2 netmask 255.0.0.0

h3 ifconfig h3-eth0 20.0.0.1 netmask 255.0.0.0

h4 ifconfig h4-eth0 20.0.0.2 netmask 255.0.0.0

h1 route add default gw 10.0.0.254

h2 route add default gw 10.0.0.254

h3 route add default gw 20.0.0.254

h4 route add default gw 20.0.0.254

接着让Host1 PING Host2，输入h1 ping h2。

在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地址，然后发出。

只有h2（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在收到h2的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都已经成功的装载了到h1（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的双向通道至此完全打通。

2.3SDN网络三层转发机制

在分析完二层转发机制后，我们重新启动拓扑结构，回到初始状态（交换机上无任何流表），测试一下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的SW2地址，其中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包的目的地址修改为h4的，以确保主机正确接收（之前Controller下发的目的地址 10.0.0.1流表中已指出这个操作）。

注：对与主机相邻的交换机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之间的通道被完全打通。

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

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

3　SDN应用于电信运营商网络的场景初探

电信的传统运营模式下，网络一旦建成便很难做更改和调整。在业务开通和优化阶段，要对海量的节点一一做配置，工作量大。SDN网络能实现对全网的统一管理和配置，灵活组网，随时响应新特性升级和新业务开通，而且由于SDN网络的自动化部署和运维故障诊断，减少了网络的人工干预，也降低了网络的出错率和维护费用，这也将直接影响到用户体验和感知。我们从两个案例分析SDN如何解决目前电信网络所遇到的问题，分别是二层环路问题和智能管道问题。

3.1SDN应用于电信接入网二层环路检测和避免

传统网络中如果存在网络环路，会致使广播在交换机之间不断恶性循环产生广播风暴，在PON接入网维护中我们常常遇到这样的问题，环路查错需要大量时间，使大量用户的业务受到波及而中断。传统以太网对二层网络环路的解决办法主要可以采用STP协议，STP通过阻断冗余链路来消除网络中的环路，在活动路径发生故障时，便激活冗余链路，恢复网络的连通性。但是STP协议的问题是网络中大量端口处于闭塞状态，网络利用率低下，且收敛速度慢。

SDN基于网络拓扑结构感知和流表下发的转发方式可以解决环路问题，通过模拟发现，网络中的主机都能实现与其它主机之间的双向通信，并没有受到环路影响。通过观察交换机和控制器的流表，发现它们均采用最短路径达到目标主机，因此网络中没有任何一条线路处于闭塞状态，既避免了环路，又提升了网络的利用效率。

3.2SDN应用于电信流量调度和智能管道

在传统IP网络中，转发路径是路由器之间通过运行各类路由协议，如RIPOSPFIS-ISBGP等路由协议，功能都是计算从源到目的最短路径。在转发时网络上的路由器都会将网络流量发送到最短路径所对应的网络接口，基于最短路径优先的传统IP网络的缺点在于无法对网络的流量实施控制，最短的路径上可能集中了大量的网络流量，部分链路可能极其繁忙，而其它链路可能得不到充分的利用，这在电信网络运营商中十分普遍。而SDN的出现解决了这个问题，GOOGLE采用 SDN进行流量工程计算，其网络利用率从原先传统 IP方式的40%提升到了接近100%，此举大大降低了广域网的运营成本。我们通过调用SDN提供的API 接口实现了与GOOGLE类似的对流量控制模拟。

1）在正常情况下，10.0.0.6-10.0.0.7根据最 短路径优先的原则进行转发；

2）sw1和sw5流量拥塞，控制器可感知流量变化；通过调用API，向控制器下发策略，使 10.0.0.6到10.0.0.7的流量走长路径，即 sw1-sw2-sw3-sw4-sw5，从而避开拥塞路径；

3）sw1和sw5流量恢复正常，控制器可感知变化；通过调用API，向控制器下发策略，撤销策略，使10.0.0.6-10.0.0.7的流量仍走回最短路径，即 sw1-sw5 我们可交换机的转发行为进行控制，比如S2进 行流表编程。需要下发两条流表，一为从主机 h6（10.0.0.6）到主机h7（10.0.0.7），流的出接口为 S2的第2个接口；而另一条为反方向从h7到h6，流 的出接口为S2的第1个接口。

根据计算可以得到h6与h7路径上的所有交换机上的转发流表，将这些流报分别存于相关文件内，当需要时，就可以通过脚本下发到SDN控制器上，并触发流更新，使网络在h6-h7之间的生成一条新的转发路径。

4　小结

通过对OpenDayLight控制下SDN网络转发行为 分析和应用的实验可以看到： OpenDayLight实现了控制和承载相分离，转 发以整网的拓扑结构为基础，Controller通过处理主 机之间、主机与网关之间的ARP报文来获得主机的 位置，采用最短路径优先算法计算到达目的主机的 流表并下发到网络内的各个交换机上；Open DayLight不仅支持二层转发还可支持三层转发，实 现环路避免和广播控制。

OpenDayLight控制下的SDN网络上已经没有 二/三层设备之分，网络充分扁平化。同一SDN内，理论上可以在允许的地址范围内为主机分配任意可用的IP地址。这种做法解除了主机位置与IP网段的紧耦合，避免了IP地址段的碎片不能得到利用的尴尬。同时交换机与交换机之间也无需配置大量互联 IP地址，又节约了地址空间。

OpenDayLight不仅是一款软件，同时也是一个开放的平台，一个未来网络架构的开放基础。通过调用OpenDayLight的API接口，可以对网络的流量进行感知，对转发行为进行控制，从而达到原有网络无法实现的控制能力，为运营商智能管道调控提供强大的手段。

网络软件化的趋势将不可阻挡，SDN将在支持数据中心虚拟化、运营商智能管道、网络安全方面大放异彩。

参考文献

［1］OpenFlow规范：https：//www.opennetworking.org/sdnresources/onf-specifications/openflow

［2］OpenDayLight项目：http：//wiki.opendaylight.org/

［3］Mininet项目：http：//mininet.org/

［4］Virtual Box：https：//www.virtualbox.org/

［5］《走近Google基于SDN的B4网络》：http：//www.csdn. net/article/2013-11-25/2817613