**本文作者：
中国银联电子支付研究院（电子商务与电子支付国家工程实验室）：袁航、周雍恺、祖立军
中国银联信息总中心：任明、吴一娜
中国银行数据中心：许泓**

---

一、行业发展历程与技术发展趋势

（一）行业发展历程

金融数据中心网络技术架构与行业安全、合规等特色性要求紧密结合，是金融数据中心显著区别与其他行业数据中心的关键领域，是金融数据中心建设中的核心。中国金融数据中心网络建设的历程与金融行业近三十年信息化过程密不可分，总结归纳金融数据中心网络的发展主要经历了三个阶段：

第一阶段：专网专用阶段。该阶段是采用特有的网络协议来对专用设备进行连通，如IBM的专有网络协议SNA对其大型机与中型机的支持；

第二阶段：基于IP协议，分层分区。在本阶段采用了更为开放通用的IP技术协议，不再受制于某个厂商，组网更加灵活。此外，本阶段中虽然各金融机构的网络架构跟随应用系统的发展而变化，但一般会出于应用分层及安全的要求，遵循“垂直分层、水平分区”的理念。

第三阶段：大规模共享接入。技术上更为开放，网络虚拟化与SDN等技术开始在金融行业应用。在继承安全区域保护机制下，采用“总线型、模块化”架构，中国的金融数据中心网络结构趋于一致，并且普遍采用网络虚拟化共享接入的技术方案，在新的云计算环境下能够对网络的灵活、弹性等要求进行有效应对。

（二）技术发展趋势

近年来，随着金融数据中心云化的加速，金融云作为最新的基础设施形态开始被行业认同并接纳。但在金融云环境下，传统网络技术架构受到了挑战：一方面虚拟化思想的出现，颠覆了原有的数据中心网络模型，使得传统网络技术已不足以适配云环境下产生的新场景，如虚拟机的出现要求网络颗粒度从物理机细化到了虚拟机级别；另一方面面向互联网的金融创新业务的快速发展，也会对网络的性能、弹性等特性提出更高的要求。所以未来金融数据中心网络技术必将进行变革式的创新发展，我们认为未来发展趋势主要包括以下三点：

1、面向互联网新兴业务的敏捷网络, 即未来金融云网络能够高效满足互联网方式下金融创新应用的多样化需求。一是网络资源的快速提供与开通，以支撑应用的快速投产；二是强化细粒度的网络策略管控能力，在应用需求的频繁变化的情况下，网络能够进行灵活地变更调整；三是网络可兼容多样化的资源类型接入，以融合网络方式实现虚拟机、容器、物理机不同资源的统一接入。

2、面向数据中心资源动态变化的弹性网络，即在大流量挑战下保证网络的平稳运行。一是金融云规模巨大，承载业务系统众多，要求网络必须具备足够的容量与健壮性，比如如何解决网络规模快速增长情况下存在广播风暴的风险；二、在营销活动等访问量暴增的情况下，网络能够根据应用重要性与链路情况实现对流量的智能调度，保证核心业务平稳运行；三则是在计算资源不充足的情况下，网络能够连通分布在不同物理位置的计算资源池，打破由于物理区域隔离所造成的资源容量限制。

3、面向数字化智能化运维模式的网络，即在网络运维压力暴增的情况下，能够做到先于业务发现网络问题。一方面，金融行业数据中心规模不断扩张，网络终端数量与网络模型复杂度都呈几何式增长，必须采用高效、出错率低自动化运维代替传统的手工方式；另一方面，在金融云的新常态下，网络运维模式需要形成闭环来提升自身价值，通过对流量数据的采集分析，实现对网络的问题预测、排障、优化，甚至做到对网络攻击的规避，提升整体网络的稳定性。

软件定义网络（SDN）技术通过分布式架构理念，将网络中数据平面与控制平面相分离，从而实现了网络流量的灵活控制，为核心网络及应用的创新提供了良好的平台，其与金融云网络发展趋势相契合，是实现金融云网络服务的有效支撑技术。

二、以金融云为载体的创新网络需求

（一）金融云对网络的创新需求

基于上述金融云网络的发展趋势，结合金融业务面向互联网的挑战，我们认为未来金融云网络需求可总结为高安全、高敏捷、高性能、高可用、高弹性与高可管理：

高安全，金融业务的特殊性对承载网络的第一要求即为保证数据的安全性，因此金融云网络必须具备能够抵御系统外部攻击，保证数据完备性与私密性的能力；

高敏捷，实现业务快速上线，面对应用的变化达到资源的按需变更，通过新技术应用打破因重安全而舍效率的困局，在云计算新环境下安全与高效并重；

高性能，面对秒杀等新业务场景等的极限服务能力，实现时延和带宽等关键指标的跨越式提升，同时注重资源的高效利用，用尽可能少的资源实现最大的性能服务。

高可用，网络架构持续稳定影响金融数据中心全局服务能力，网络架构需要基于稳定可靠的技术构建，使网络服务具备7*24小时业务连续性服务的能力；

高弹性，一是内部弹性强化，打破竖井式架构中网络区域成为限制资源共享的壁垒，实现网络资源池整合与灵活共享与隔离，二是外部弹性兼容，支持新老架构并存，从而使原有网络可以平滑过渡到新架构；

高可管理，一是实现管理的体系的简化，支持多品牌的融合管理，二是实现管理自动化与智能化，提供端到端的业务可视和故障快速定位、排查能力，使日常运维从大量人工维护的高工作量解放出来；

（二）金融私有云与行业云对网络需求的异同分析

虽然金融私有云与行业云本质上都承载金融业务，但是由于应用场景与服务模式上的不同，也使得金融私有云与行业云对网络的需求有所差异。在表1中，我们基于上面提出网络需求的6个维度，对金融私有云与行业云网络需求的异同进行分析。

表1 金融私有云与行业云对网络需求的异同

三、下一代金融云SDN网络的设计原则与架构规划

（一）网络设计原则

SDN技术的应用颠覆式地改变了金融数据中心网络架构，因此基于对网络发展趋势与具体需求的分析，在云环境下构建新一代的SDN网络需进行针对性的设计。据此我们提出了以下三条设计原则：

1.根据不同网络边界分层构建网络资源池
从能力层面来看，网络作为一种基础设施资源，应构建统一的云网络资源池，打破传统网络竖井式架构，提升计算、存储资源调用的灵活性；从管理与安全层面看的话，因为不同网络区域能力不同，在数据中心网络中的角色不同，所以应根据对不同网络区域分别构建资源池。

2.网络能力全部服务化实现
面向服务理念，对每层网络功能以服务、标准API接口的形式对外提供，网络系统内部以服务的形式进行自组织，从而提升对外服务能力，简化外部调用网络能力的复杂性；

3.网络资源统一编排管理
数据中心内网络二/三层连通、四/七层功能的管理界面统一视图，不同网络资源池的管理采用二级管理编排方式，即底层适配不同网络资源池管理操作、上层异构协调编排。

（二）网络架构

根据上述网络设计原则，我们规划了金融数据中心的整体网络架构如下图1所示。

图1 金融数据中心整体网络架构

首先，我们根据数据中心网络构成，将整体网络分成了三个部分，具体如下：

1.区域网络，也就是我们常说的一个云平台Region的网络，业务系统就运行在该区域内。其网络方案可分为硬件方案和软件方案。网络设备包括区域交换机、区域内控制器、负载均衡；

2.核心网，核心网就是连通各个区域的网络，主要设备包括核心交换机；

3.数据中心网络，其实称为数据中心外联网络可能更准确一些，负责数据中心与外部网络的连通，其与外部骨干网连接，主要设备包括边缘路由器。

网络分区确定后，随后就根据各个分区的能力边界构建各自的网络资源池，并对各个资源池能力进行标准的API接口化实现。

最后，在顶层设计一个统一的网络能力编排系统，将各个资源池的能力通过API对接的方式进行上收，随后根据权限配置将不同网络区域的能力下放至相应的管理员与应用系统。

四、基于ODL开源控制器的数据中心内SDN网络方案研究与实现

SDN方案分为硬件和软件两大类。硬件SDN是采用专用的硬件交换设备与控制器来实现相关的网络功能，控制器对硬件设备进行策略以及流表的下发，来实现网络相关的功能。它的优点是性能强，比较稳定，缺点是不灵活且组网成本很高。业界常见的硬件方案包括思科的ACI，华为AC、华三VCF等。

而在软件SDN的解决方案中，网络的功能是通过软件层面的Linux协议栈以及相关的虚拟交换机技术实现的。它的优点可以避免对硬件网络设备的过度依赖，同时降低了组网的成本，缺点是稳定性、性能和可扩展性不如硬件方案。常用的软件方案包括Neutron+OpenvSwitch、OpenDayLight+OpenvSwitch等。

下面对银联当前对SDN应用研究的现状进行介绍。

（一）银联SDN应用研究现状

中国银联自2014年启动软件定义网络（SDN）技术在金融云环境下的应用研究，长期跟踪SDN技术在国内外金融行业的研究进展，并积极推动SDN技术在银联生产环境的应用以及与银行金融机构的合作研究。目前，银联对SDN软硬方案的研究测试工作均已完成，两套方案全部落地生产。

银联私有生产云采用华为SDN整体硬件方案，银联生产托管云则采用Neutron+OpenvSwitch的软件SDN方案。当前实现了网络二/三层、负载均衡、防火墙等多网络资源服务，承载了近期银联与相关合作金融机构的关键应用，有效支撑了银联业务创新。

当前，银联结合当前生产现状与行业技术发展趋势，开展下一代金融SDN相关技术研究工作。目前主要针对金融数据中心区域内的软件SDN方案进行进一步研究优化，从而满足下一代金融云的网络要求。下图2中的红色范围即为本次研究工作的定位。

图2 本次研究工作定位示意图

（二）下一代金融云网络软件SDN网络方案

1.方案设计与实现思路

图3 整体方案能力设计与实现思路图

（1）首先在对方案的能力设计上，我们结合了当前金融数据中心针对软件SDN方案的需求来进行规划，主要围绕三点：

• 首先性能是软件SDN方案较硬件方案来说比较明显的短板，在性能上我们从两个层面上进行优化。一是要简化物理机内部的网流转发路径，如Neutron方案下物理机内部的网桥有三层，过多的网桥数量势必减缓对网络数据的处理速度，所以要简化；二是要优化物理机外部的网流转发路径，如Neutron方案下所有跨网段通信的流量全部要绕至专门的网络节点进行路由转发，给性能带来较大的影响。
• 然后是金融行业着重关注的稳定性上，我们也有相关的能力设计考虑。一是由于节点数量的规模快速增长所导致的广播风暴会对网络造成极大的损伤，因此本方案中将会针对该问题进行解决；二是优化网流路径，精简网流数据的处理节点，进一步减少网流转发中存在的风险点，并且打破集中式的网络瓶颈，采用分布式架构实现。
• 最后是为应对业务流量的突发式增长，方案在支撑资源的可扩展性上也有相关考虑。主要是网络能够打通跨区域的计算资源，并且做到在多租户环境下实现跨区域资源的互通。

（2）其次根据方案的能力设计，我们对方案的技术选型也进行了思考与规划，具体分为两个层次：

• 首先整体方案的技术框架我们依然选择采用基于开源技术实现。一是因为金融行业的一些特殊需求需要对相关能力进行定制化开发，而且足够快速和灵活，这就要求我们对方案具备自主可控的能力，采用商业软件是做不到的；二是如果从头进行开发将会消耗大量的时间经历，基于开源技术则会达到快速实现的目的；
• 从具体的能力技术设计上，我们会进行分布式路由、分布式ARP、跨区域互联、防火墙并联接入等具体的技术方案以满足最初的能力设计。分布式路由打破了Neutron网络集中式节点处理方式，会对网络的性能、稳定性进行优化；分布式ARP将会很大程度上抑制网络中存在的广播报文，提高网络稳定性；跨区域互联通过对接RI系统实现；防火墙并联的实现也避免了防火墙成为网络瓶颈。具体设计思路式会在下文中详细阐述。

（3）最后根据方案的能力设计与技术选型，我们整理了两点具体实现的思路。一是能力的实现方案应充分考虑当前数据中心现状，应选取可以平滑迁移和应用的方案进行实现；二是不同能力在实现的过程中相互之间会有联系或影响，比如要实现高级的跨区域通信能力，就必须对底层的分布式路由、ARP代答等能力进行修善。因此在能力实现中要对这种情况进行充分预估与判断，防止由于忽视相互之间的影响而导致能力不足或出现相关隐患。

2.整体技术框架

本次方案研究中，我们依然采用开源技术框架来进行实现。核心控制层采用开源控制器OpenDayLight（下文简称ODL），上层编排仍使用OpenStack的Neutron，Neutron与ODL之间使用ML2 plugin进行对接；底层数据层使用OpenvSwitch（下文简称OVS）进行网流转发交换，并通过OVSDB与Openflow协议与控制器对接，其中OVSDB负责对OVS进行配置，Openflow则负责实现所有的数据转发功能现。整体框架图如下。

图4 方案整体框架图

3.能力设计

（1）基于虚拟化的多租户支持

多租户虚拟化网络解决方案通过Overlay网络和SDN控制器的相互配合，可以使得逻辑网络与物理网络解耦、控制平面和转发平面分离，进而实现消除网络限制、虚机任意迁移、IP地址灵活分配的目的，从而充分满足用户随时随地接入、业务快速上线、虚机迁移及策略自动跟随的需求。

当前多租户已成为行业云的基本能力要求，但是在私有云中则会根据管理方式选择性部署。但是我们认为随着私有云规模的不断扩大，多租户也必将成为私有云的必需。一方面多租户技术允许网络资源重叠，能够缓解整体网络资源紧张的局面；另一方面多租户概念的引入将会使得不同应用之间的网络逻辑边界更加明显，在方便管理的同时也使得抽象的访问策略更加具象化，提升运维效率。

本方案中我们采用比较通用的Vxlan技术来实现多租户的能力。

（2）跨区域互联能力

传统交换网络稳定有余但灵活、高效不足。各网络分区之间计算、存储、网络、机房物理环境等资源均为独享模式，不同分区之间计算宿主机无法共享资源，虚拟机不允许在不同分区宿主机间漂移，计算资源利用率下降。为打破传统分区，本方案将会对基于多租户模式下的跨区域资源互联进行实现，提高资源利用率与应用部署灵活性。

在具体能力实现中，我们采用与银联自研的区域互联系统（以下简称RI，RI具体实现方式请见文章《中国银联与上海银行基于SDN的下一代金融云网络联合研究与应用实践》）进行对接的方案，在数据平面通过Vlan的方式与防火墙进行连通。

（3）分布式网络功能设计

云的本质是分布式计算的一种形式，采用虚拟化技术将集中的物理资源进行切割，并通过网络将资源分散给不同用户。因此，为了更好的契合云计算分布式的本质，避免集中式的网络功能成为云的瓶颈，在进行下一代金融云网络能力设计中，我们将分布式的网络功能作为必备能力。

常用的云网络功能包括网关、DHCP、ARP响应、防火墙在本方案中，防火墙的能力通过硬件实现，所以在此不对其分布式实现进行讨论；DHCP主要作用只是在虚拟机网络发生变化时，向虚拟机下发主机名和IP地址，应用场景少、涉及流量小，并非云网络瓶颈，对其进行分布式实现意义也较小。

而相反，在软件云网络方案中，网关与ARP响应两组功能也全为软件实现，属于网络基础能力，应用频繁。网关是三层通信的流量转发点，不同网络之间的流量通信都必须经过网关进行路由；而ARP响应则是获取目的MAC地址的唯一途径，是二层通信中不可或缺的流程与手段，同时也是区域内正常通信下广播流量的主要来源。因此，对网关与ARP响应进行分布式实现将会较大幅度地提升云网络的效率与稳定性。

综上所述，本方案会对网关与ARP响应能力进行分布式实现。

（4）防火墙并联方式接入

防火墙用于提供四到七层网络安全服务，实现逻辑区域之间的安全隔离。

金融云网架构模型中，可将硬件防火墙资源进行池化部署，并按需进行调度，通过云控制平台实现防火墙统一管理。除此之外，金融数据中在防火墙接入形态上采用物理并联、逻辑串联的方式，在防火墙故障的情况下仍能保证业务的正常运行，提升了业务的稳定性。在本方案中也将实现该效果。

（5）最终能力实现效果

以上能力全部实现后，最终的效果图如下所示。

图5 网络能力效果图

（三）基于OpenFlow流表的能力实现

从数据平面来看，本方案中所有的数据转发功能全部通过Openflow流表进行实现，即区域中所有的流量都由OVS依照Openflow流表来进行转发动作；而从控制平面上看，控制器只是根据方案预先制订的Openflow流表框架来实现到OVS的自动配置与下发的能力。所以，方案能力实现的关键仍在对Openflow流表的设计。

1.整体流表设计框架

OVS的网络功能主要由网桥，端口与流表等实现。一个网桥中可以包含多级流表（Table0,Table1,Table2,…），流量在转发的过程中可以在不同的Table上进行跳转，以实现不同的功能；同时一个Table可以包含多条流表（flow entry），对流表可进行优先级的控制，但是只有一条流表会对进入Table的流量起作用。

原生ODL会在平台的每台物理机上创建br-int、br-ex两个OVS 网桥，其中br-ex主要负责南北向通信，连接外部网络和br-int网桥，且只有一个Table 0，功能比较简单；而br-int则负责虚拟机的接入，并实现大部分的网络能力，包含了Table0、10、20到110共12个Table，功能较为复杂。各个Table的具体功能如下所示。

CLASSIFIER   Table0   "流量分类" 
DIRECTOR   Table10   "Director" 
ARP_RESPONDER   Table20   "分布式ARP应答" 
INBOUND_NAT   Table30   "入站流量浮动IP流量DNAT" 
EGRESS_ACL   Table40   "出口访问控制" 
LOAD_BALANCER   Table50   "分布式负载均衡" 
ROUTING   Table60   "分布式路由" 
L3_FORWARDING   Table70   "3层转发" 
L2_REWRITE   Table80   "2层重写服务" 
INGRESS_ACL   Table90   "入口访问控制" 
OUTBOUND_NAT   Table100   "访问外部网络流量的SNAT" 
L2_FORWARDING   Table110   "二层转发" 

为方便开发，本方案在流表设计中继续沿用原生ODL的流表框架与各个流表的功能设计。同时为了实现方案的设计能力，对相关Table进行能力补足与优化，具体修改的流表如下图6所示。

图6 主要流表框架图

Table 0：租户在云网分区内部与外部之间的标签转换；
Table60：防火墙物理并联逻辑串联接入实现；
Table 20、70、110：支持去Floating IP的分布式网关实现。

下文中会对每项功能具体实现的技术方案、详细流表与代码架构进行详细说明。

2.能力优化与实现

能力实现1：多租户环境下跨区域互联

做到多租户环境下的跨区域互联主要难点在与如何对存在于不同云网分区的租户流量进行标记与识别，从而保证通过核心交换网络后，云网分区可以正确将IP地址重用的多租户流量转发至正确的租户资源。

在对接RI后，所有跨区域通信流量在出区域防火墙后，即通过RI在核心交换区架起的隧道到达另一区域的防火墙。不同的租户在核心交换区对应不同的隧道，从而实现了不同区域不同租户的流量隔离。因此，我们只需关心跨区域互联时在区域内部的一些功能操作，而无需关心外部核心交换区域如何实现。具体如下图7所示。

图7 RI跨区域通信示意图

在进行跨区域通信时我们考虑的问题有两个：一是跨区域的流量通过什么方式送到防火墙；二是防火墙接收到外部区域发来的跨区域访问流量的时候，如何将该流量发送到区域内。下面我们对这两个问题进行逐一分析。

问题一：跨区域流量通过什么方式发送到防火墙

在考虑该问题的时候，又会衍生出新的子问题：1.火墙支持的接入方式是什么，是否支持隧道接入；2.防火墙的物理连接方式是什么，并联还是串联。

先看子问题1。在金融行业，对防火墙的性能和可用性有着比较高的要求，因此金融数据中心内部绝大部分仍使用硬件防火墙。而硬件防火墙往往不支持如Vxlan、GRE等一些隧道功能，所以一般还是采用Vlan的方式与防火墙连接。

子问题2提出了防火墙的物理连接方式。在能力设计的第四点已经提出，为保证业务运行的稳定性，降低网络故障瓶颈与影响范围，在金融数据中心防火墙采用并联方式接入。且为保证防火墙的性能，降低故障率，区域的外部网关不会建立在防火墙上。

既然防火墙已并联方式接入且外部网关不在防火墙上，那么区域内流量要发送到防火墙必须经过引流才能实现。具体引流方案我们会放在后面关于防火墙并联接入实现的内容中，在此不做赘述。

问题二：防火墙如何将流量发送到区域内

该问题也会产生两个子问题：

1. 防火墙如何将流量发送到区域的外部网关。该问题则是由于外部网关的分布式实现导致的，具体方案会在分布式路由实现中进行详细描述，在此不做赘述；
2. 同样是由于连接防火墙与区域内部网络方案的不同需要进行报文转换，只不过这次转换是有Vlan报文转换为Vxlan报文。

综上所述，要实现跨区域通信的影响面较广，分布式网关、防火墙接入都会有所涉及。为使功能实现更加清晰，我们在这里只对Vlan到Vxlan的报文转换的实现方式进行描述。

流表设计
br-ex Table0：

table=0,priority=2048,in_port=3,dl_Vlan=310,nw_dst=10.2.1.0/24 actions= output:1

以上流表位于br-ex Table0，接收到Vlan标签为310、目的IP地址为10.2.1.0/24的报文并转发到br-int。Vlan 310是该租户在外部网络的Vlan ID，output:1则表示从br-ex的标号为1的端口发出，该端口即是br-ex 与br-int的连接端口。

br-int Table0：

table=0,priority=2048,in_port=4,IP,dl_Vlan=310,nw_dst=10.2.1.0/24 actions=strIP_Vlan, set_field:0x28->tun_id,goto_table:20

当检测到其它区域发来的流量时，检测Vlan号和网段是否属于本区域并且对应关系一致，如果该流量的目的终端确实在本区域，卸载Vlan号，并进行Vlan到Vxlan的映射操作，并将该流量发送到下一流表中继续处理。

代码架构

添加接口：

文件：net-virt/src/main/java/org/opendaylight/netvirt/openstack/netvirt/api/ClassifierProvider.java
函数：programVlanToVxlanFlowEntry 
文件：net-virt/src/main/java/org/opendaylight/netvirt/openstack/netvirt/api/L3ForwardingProvider.java
函数：programBrexFlowEntry

流表逻辑实现：

文件：net-virt/src/main/java/org/opendaylight/netvirt/openstack/netvirt/impl/NeutronL3Adapter.java
函数：handleNeutronRouterInterfaceEvent

流表下发：

文件：net-virt-providers/src/main/java/org/opendaylight/netvirt/openstack/netvirt/providers/openflow13/services/ClassifierService.java
函数：programVlanToVxlanFlowEntry
文件：net-virt-providers/src/main/java/org/opendaylight/netvirt/openstack/netvirt/providers/openflow13/services/L3ForwardingService.java
函数：programBrexFlowEntry

能力实现2：防火墙物理并联逻辑串联接入实现

在上文的问题分析中，已经提到为什么防火墙要采用物理并联逻辑串联的接入方式，并且也提到通过引流方式进行实现。在本节中对实现具体方案和步骤进行详细描述。

首先，从引流的场景看，都有哪些南北向流量需要通过引导才能发送到防火墙。在本方案中，南北向流量可分为两种，一种是通过Floating IP被外部访问的流量，另一种是通过内网网段信息对外通信的跨区域流量。具体如下图8所示。

图8 云网区域南北向通信示意图

对第一种南北向流量，因为带有Floating IP地址，因此其默认下一跳就会被送至外部接口网关，因此不需要引流就会被传送至防火墙并发出。对第二种南北向流量，其源IP和目的IP都为内网地址，其传送的防火墙属于跨网段通信，因此需要设置路由表对其进行引流，将去往另一个区域网段的下一跳设置在防火墙与路由器的接口上，从而实现了防火墙的引流功能。

流表实现

确定需要引流的流量后，我们就要进行引流功能的流表实现。在这里需要考虑两点：第一路由器与防火墙之间是Vlan模式的网络，因此流量在通过路由器的时候应打上Vlan标签；第二每个租户有各自的防火墙接口，接口的MAC地址要进行获取。最终流表实现如下：

table=60,priority=4096,IP,tun_id=0x1e,nw_src=10.1.1.0/24,nw_dst=10.2.1.0/24,actions=set_field:f8:4a:bf:5a:2b:ea ->eth_dst,dec_ttl,mod_Vlan_vid:211,output:3

以上流表是静态路由的实现，报文目标IP地址是另一个租户的网段时，将目标mac地址改成外部网络上租户防火墙接口的mac地址，根据源IP和tun_id确认租户，设置租户对应的的Vlan id，将报文发出。

代码架构

添加接口：

文件：net-virt/src/main/java/org/opendaylight/netvirt/openstack/netvirt/api/RoutingProvider.java
函数：programStaticRoutesFlowEntry
文件：net-virt/src/main/java/org/opendaylight/netvirt/openstack/netvirt/api/GatewayMacResolver.java
函数：resolveMacAddressWithVlanTag

流表逻辑实现：

文件：net-virt/src/main/java/org/opendaylight/netvirt/openstack/netvirt/impl/NeutronL3Adapter.java
函数：handleNeutronRouterEvent

流表下发：

文件：net-virt-providers/src/main/java/org/opendaylight/netvirt/openstack/netvirt/providers/openflow13/services/RoutingService.java
函数：programStaticRoutesFlowEntry
文件：net-virt-providers/src/main/java/org/opendaylight/netvirt/openstack/netvirt/providers/openflow13/services/arp/ArpSender.java
函数：sendVlanTaggedArp
createVlanTaggedArpFrame

能力实现3：支持去Floating IP的分布式路由

原生ODL实现方式

在能力设计中，我们提出采用分布式路由的实现方式。在ODL原生方案中，也对分布式路由进行了实现，具体实现方式如下图9所示。

图9 原生ODL分布式路由实现示意图

从图9可以看出，原生ODL的分布式路由机制则在每个节点上都使能一个路由器。对于东西向的流量， 流量会直接在计算节点之间传递。对于南北向的流量，如果有Floating IP，流量就直接走计算节点；但是对于没有Floating IP的流量，依然要通过集中式的网络节点发送。

在一般场景应用中，区域的南北向流量都要经过NAT处理（即使用Floating IP）才能进行正常通信。如不进行NAT处理，区域内部的网段地址无法被外部网络识别，因此无法实现预期的数据转发。

但是在本方案中，由于存在跨区域通信的场景，为了识别租户信息，反而需要携带内部网络地址信息与其它区域进行通信。而该场景恰恰与上文中提到的无Floating IP进行南北向通信的方式相吻合。所以在原生的ODL设计中，该流量仍需要通过集中式的网络节点发送，这就与本方案的能力设计不符。

原理分析与问题提出

为了实现支持去Floating IP的分布式路由能力，我们需要对ODL原生分布式路由的设计方式进行进一步分析：为什么无Floating IP的南北向流量不能使用分布式网关方式实现？为了阐述起来更直观，我们通过下面的一个具体场景来寻找原因。

图10 分布式网关物理结构图

上图是一张分布式网关的物理结构图，由图可看出每台物理节点的OVS都具备路由的功能。图中六台虚拟机同属同一租户且分布在两个网段中，租户与外部网络的接口地址为172.16.1.100，同时为每台虚拟机都分配了相应的Floating IP。

在该环境下，当虚拟机在与external网络通信时，流量到达OVS上时，OVS中的相关表项会将数据包的源IP地址转换为唯一与该虚拟机对应的Floating IP。如v1在与外部网络通信时，从v1中出来的数据包的源IP地址还是v1的IP地址，即10.0.0.1，那么数据包到了OVS上之后，OVS根据该数据包的目的IP地址判断出这是v1与外部网络通信的流量，这时OVS中就会有相应的流表对该数据包的源IP地址字段进行转换，即将10.0.0.1转换为172.16.1.1，也就是v1的Floating IP。那么对于外部网络来说，v1的IP地址也就变为了172.16.1.1。

因为Floating IP与虚拟机之间是一一对应的，所以外部网络在进行回包的时候，就可以直接通过Floating IP找到v1所在的位置，从直接而将数据送回至v1。

如果v1没有Floating IP ，虽然它主动向外部网络发送的数据是能够送至目的端的，但是目的端的返回包是无法送至v1的。因为v1的数据包是其内网地址10.0.0.1作为源IP地址的，而其内网地址是不为外部网络所认知的，这是存在的第一个问题。不过回到我们的跨区域通信场景中，由于对接RI系统，带有内网地址的数据可通过RI建立的隧道跨过核心交换区域到达另一个云网分区的防火墙上。所以第一个问题在跨区域通信的场景中不存在，我们继续往下分析。

当数据流到达云网分区的防火墙上时，我们需要解决上文中已经提及的问题：在分布式的网关场景下，流量如何通过防火墙发送到云网区域的外部接口上？

在原生的ODL方案中，区域的外部接口并没有实现接收外部网络数据的能力，所以我们需要对此功能进行实现。

实现了数据接收能力后，仍存在另外一个问题。如图10所示，云网分区的外部接口分布在区域内的每台物理节点上，而跨区域通信的数据包的目的虚拟机只存在于一台物理节点中。当防火墙向云网区域的外部接口发送数据包时，应该将数据包发送到哪一台物理节点上呢？换句换说就是如何定位目的虚拟机的具体位置。

综合分析下来，我们得知，要实现支持去Floating IP分布式网关实现，就必须解决下面两个问题：

1. 实现区域外部接口对外来流量的数据接收能力；
2. 外部接口接收到数据后，能够将数据送达目的虚拟机。

流表实现

针对问题1，我们通过设计外部接口的ARP响应的openflow流表，实现外部接口接收外来数据的能力。具体流表如下

table=20,priority=1024,arp,arp_tpa=172.16.1.100,arp_op=1 actions=move:NXM_OF_ETH_SRC[]->NXM_OF_ETH_DST[],set_field:f8:4a:bf:5a:2b:ea->eth_src,load:0x2->NXM_OF_ARP_OP[],move:NXM_NX_ARP_SHA[]->NXM_NX_ARP_THA[],move:NXM_OF_ARP_SPA[]->NXM_OF_ARP_TPA[],load:0xf84abf5a2bea->NXM_NX_ARP_SHA[],load:0xac100164->NXM_OF_ARP_SPA[],IN_PORT

上面的流表的主要作用就是为外部接口构造了一个ARP的响应包，在接收到对外部接口的ARP请求的时候，OVS会根据该流表生成一个ARP响应包，发回给请求方。当请求方接收到该ARP响应报文后，就会将数据包发出，送至发出该响应报文的物理节点的OVS上。

为了保证路由的分布式架构，我们会在所有的物理节点上下发外部接口的ARP响应的流表。所以，在外部网络发出ARP请求后，所有物理节点都会对该请求进行响应。收到响应后，外部网络就会将数据包发出，发出后数据包就会按照物理交换机上的mac表进行转发，最终发送到平台中的某一个物理节点的OVS上。具体如下图11所示。

图11 分布式网关ARP响应示意图

针对问题2，当物理节点收到数据包后，会进一步对数据包进行分析。此时就会有两种情况：一是该虚拟机恰好在该物理节点中，此时就可以直接将数据包送到虚拟机上，相应流表如下；

table=70,priority=1024,IP,tun_id=0x5a,nw_dst=10.0.0.3 actions=set_field:fa:16:3e:99:df:47->eth_dst,goto_table:80（三层转发）
table=110, tun_id=0x5a,dl_dst=fa:16:3e:99:df:47 actions=output:23（二层转发到虚拟机，23口与是虚拟机连接的OVS的端口）

还有一种情况就是虚拟机不在该物理节点中，那么这时候就要用隧道的方式，将数据包通过Vxlan隧道发送到虚拟机所处的物理节点，然后再送到虚拟机，如图12所示。相应流表如下：

table=70,priority=1024,IP,tun_id=0x5a,nw_dst=10.0.0.3 actions=set_field:fa:16:3e:99:df:47->eth_dst,goto_table:80（三层转发）
table=110, tun_id=0x5a,dl_dst=fa:16:3e:99:df:47 actions=output:3（通过Tunnel转发到对应物理机，后面的output：3代表从3口发出，3口即为隧道的端口）

到对端物理机的OVS后：
table=110, tun_id=0x5a,dl_dst=fa:16:3e:99:df:47 actions=output:23（二层转发到虚拟机）

图12虚拟机定位示意图

整个流程统一起来，步骤如图13所示。

图13 支持去Floating IP分布式网关数据处理流程图

代码架构

添加接口:

文件：net-virt/src/main/java/org/opendaylight/netvirt/openstack/netvirt/api/ArpProvider.java
函数：programPFWProviderArpEntry
文件：net-virt/src/main/java/org/opendaylight/netvirt/openstack/netvirt/PortHandler.java
函数：doNeutronPortCreated 

流表逻辑实现

文件：net-virt/src/main/java/org/opendaylight/netvirt/openstack/netvirt/impl/DistributedArpService.java
函数：handleNeutronPortForArp

流表下发

文件：net-virt-providers/src/main/java/org/opendaylight/netvirt/openstack/netvirt/providers/openflow13/services/ArpResponderService.java
函数：programPFWProviderArpEntry
文件：net-virt-providers/src/main/java/org/opendaylight/netvirt/openstack/netvirt/providers/openflow13/services/L3ForwardingService.java
函数：programForwardingTableEntry

3.跨区域通信实现案例分析

下面我们结合一个跨区域通信的场景，举例分析跨区域虚拟机通信过程中经过的流表以及各个流表的功能。
如图14所示，两个虚拟机VM1和VM2分别在两个区域的两台主机上，VM1向VM2发送ICMP请求。

图14 跨区域通信流表作用示意图

首先VM1会发送目标IP为网关IP 10.1.1.1的ARP请求广播包，由OVS获取并发送到Table20中进行处理，起作用的流表如下：

table=20,priority=1024,arp,arp_tpa=10.1.1.1,tun_id=0x3e8,arp_op=1 actions=move:NXM_OF_ETH_SRC[]->NXM_OF_ETH_DST[],set_field:02:02:02:02:02:02->eth_src,load:0x2->NXM_OF_ARP_OP[],move:NXM_NX_ARP_SHA[]->NXM_NX_ARP_THA[],move:NXM_OF_ARP_SPA[]->NXM_OF_ARP_TPA[],load:0x020202020202->NXM_NX_ARP_SHA[],load:0x0a010101->NXM_OF_ARP_SPA[],IN_PORT

Table20匹配tun_id为1000，目标IP为10.1.1.1的ARP请求包，将报文的目标MAC设为10.1.1.3的MAC地址，将报文的源MAC和ARP_SHA改为10.1.1.1的MAC地址（从Neutron获取），将报文类型改为ARP响应，并将响应报文原路送回到发送方。

VM1拿到网关的MAC地址后，就会将ICMP报文发出，报文的源IP是10.1.1.3，目标IP是10.2.1.3，并在整个传输过程中保持不变。报文发送到OVS后，首先起作用的报文是Table60的静态路由流表，本场景的静态路由流表会匹配tun_id为1000，源地址是10.1.1.0/24，目标地址是10.2.0.0/16的流量，将目标MAC地址修改为区域防火墙的MAC地址04:04:04:04:04:04，给报文打上VLAN TAG 100，并将报文转发至br-ex。具体流表如下：

table=60, priority=4096,IP,tun_id=0x3e8,Vlan_tci=0x0000/0x1fff,nw_src=10.1.1.0/24,nw_dst=10.2.0.0/16 actions=push_Vlan:0x8100,set_field:4196->Vlan_vid,set_field:04:04:04:04:04:04 ->eth_dst,dec_ttl,output:1

br-ex接收到报文进行流表匹配后，最终会匹配到优先级最低的NORMAL流表，NORMAL action会以普通交换机的行为转发报文，也就是根据MAC地址和端口的对应关系转发，具体流表如下：

table=0, priority=0 actions=NORMAL

br-ex的NORMAL流表会将报文通过host1的eth0发送到区域防火墙上，区域防火墙的默认网关在区域核心上，流量会通过路由到达交换核心并最终送到另一个区域的防火墙。防火墙上有区域内部网络的回程路由，由于目标地址是10.2.1.3，会匹配到区域内10.2.1.0/24的回程路由，并送到下一跳172.16.2.1。防火墙会发送目标IP为172.16.2.1的ARP请求广播报文，ARP代答流表所在的主机host2会响应ARP请求，ARP代答流表如下：

table=20,priority=1024,arp,dl_Vlan=200,arp_tpa=172.16.2.1,arp_op=1 actions=move:NXM_OF_ETH_SRC[]->NXM_OF_ETH_DST[],set_field:06:06:06:06:06:06->eth_src,load:0x2->NXM_OF_ARP_OP[],move:NXM_NX_ARP_SHA[]->NXM_NX_ARP_THA[],move:NXM_OF_ARP_SPA[]->NXM_OF_ARP_TPA[],load:0x060606060606->NXM_NX_ARP_SHA[],load:0xac100201->NXM_OF_ARP_SPA[],IN_PORT

响应防火墙ARP请求后，防火墙会将IP报文发送到响应的主机host2，通过eth0网卡进入OVS，开始流表匹配。首先br-ex上的引流流表将外部区域访问本区域的流量转发到br-int，匹配VLAN ID 为200，目标IP为10.2.1.0/24的报文，转发到br-int。具体流表如下：

table=0, priority=2048,IP,dl_Vlan=200,nw_dst=10.2.1.0/24 actions=output:2

br-int收到流量后对报文进行VLAN到VXLAN的转换，匹配VLAN ID为200，目标IP为10.2.1.0/24，从br-ex发来的IP报文，去掉VLAN TAG，打上相应的VXLAN ID并交给之后的table继续处理。具体流表如下：

table=0,priority=2048,in_port=1,IP,dl_Vlan=200,nw_dst=10.2.1.0/24 actions=strIP_Vlan, set_field:0x7d0->tun_id,goto_table:20

报文不会匹配到table20到table60的处理流程，在table70匹配到三层转发流表，根据报文的VXLAN ID，目标IP地址，将报文的目标MAC地址修改为目标IP地址对应的MAC地址，并交给之后的table继续处理，具体流表如下：

table=70,priority=1024,IP,tun_id=0x7d0,nw_dst=10.2.1.3 actions=set_field:08:08:08:08:08:08 ->eth_dst,goto_table:80

报文不会匹配到table80到table100的处理流程，在table110匹配到二层转发流表，根据报文的VXLAN ID，目标MAC地址，转发到相应的虚拟机端口。如果目标MAC对应的虚拟机不在本节点，则转发到目标虚拟机所在主机的VXLAN隧道端口。具体流表如下：

table=110, tun_id=0x7d0,dl_dst=08:08:08:08:08:08 actions=output:2

至此，VM1的数据包发送至另一个区域的VM2，VM2收到数据后，会按照上述步骤将响应数据返回，跨区域通信结束。

五、原型实践与效果

（一）物理架构概述

由于是软件SDN方案，实现网络功能的模块分布在每台服务器上，复杂性也卸载到SDN控制器和每台服务器上，所以物理架构相对比较简单。下图展示了原型平台的物理架构，整体架构由两个云网区域和一个RI区域组成。RI区域由两台交换核心设备和两个区域各一台的区域核心设备组成。区域核心下联区域防火墙，防火墙下联交换机，交换机接入服务器。

图15 原型平台物理架构图

我们在中国银联的数据中心实验环境搭建了原型平台，平台由两个SDN云网分区组成，云网分区包含接入交换机，服务器，同时配备了防火墙。平台基于OpenStack、OVS、ODL、Centos等开源软件进行研发，相应软件版本情况见如表2所示。

表2 软件版本情况表

（二）管理控制平面概述

本次原型实践使用OpenStack作为云平台来管理虚拟资源的生命周期，向上提供标准API供用户使用，向下通过SDN控制器，防火墙驱动来实现对下层网络资源的抽象、隔离和调度。其中网络的控制平面使用ODL而非原生OpenStack的Neutron网络功能，ODL提供ML2和GBP的方式和OpenStack集成，本次实践使用ML2的方式。

（三）云网与云控平台集成

OpenStack需要管理我们实践环境中的二层虚拟网络，三层虚拟路由，以及防火墙，其中二层和三层的功能由ODL提供，防火墙功能由Neutron直接控制独立的防火墙实现。

ODL与OpenStack的集成需要两个平台的接口来实现。如图16所示，OpenStack的networking-odl项目提供ODL ML2 mechanism driver替代OVS driver，ODL L3 Plugin替代原生L3 agent。

图16 Neutron集成模块示意图

OpenStack Neutron的ODL ML2 Driver通过REST API将Neutron请求发送到ODL的北向接口，ODL的Neutron Northbound和Netvirt项目分别提供对应Neutron的北向接口和业务逻辑，其中MD-SAL是ODL内部的数据交互模块。南向接口OVSDB Southbound和OpenFlow Southbound Plugin分别通过OVSDB和OpenFlow协议操作OVS。

下面我们详细介绍每个模块的具体集成方式。

1.ODL与OpenStack集成

本次原型实践使用ODL的netvirt模块与OpenStack Neutron集成，需要OpenStack和ODL两个平台的接口实现。

OpenStack方面，需要在控制节点，网络节点，计算节点做以下配置的变更：

（1）控制节点
修改配置，使用ODL ML2 mechanism driver替代OVS mechanism driver；
修改配置，使用ODL L3 plugin替代原生OpenStack的L3 plugin；
配置ODL的访问路径和认证方式。

（2）网络节点
停止原生OVS agent，OVS由ODL控制；
停止原生L3 agent，三层服务由ODL提供；
DHCP服务使用OpenStack原生的DHCP agent；
metadata服务使用OpenStack原生的metadata agent。

（3）计算节点
停止原生OVS agent，OVS由ODL控制；
ODL方面，需要安装包含netvirt的feature odl-OVSdb-OpenStack并修改配置，打开ODL L3功能。

2.ODL与OVS集成

如图17所示，OVS主要由两个用户态进程OVSdb-server、OVS-vswitchd和OVS内核模块组成，其中OVSdb-server接收OVSDB协议的消息，保存bridge，port等信息到数据库，并通知OVS-vswitchd创建相应对象。OVS-vswitchd同时接收OpenFlow协议的消息，操作OVS中的流表，最终使流表在内核模块中生效。

ODL提供了OVSDB southbound和OpenFlow Southbound Plugin两种南向接口来操作OVS，其中OVSDB southbound操作OVS上的bridge，port等元素，OpenFlow Southbound Plugin操作OVS上的流表。

图17 OVS集成模块示意图

OVS集成ODL需要在所有计算节点做以下配置：

将OVS的manager设置为ODL，ODL会在OVS上创建两个bridge：br-int和br-ex，并会自动将这两个bridge的控制器设置为ODL，之后ODL就可以通过OVSDB和OpenFlow来控制OVS。

3.防火墙集成

在原型环境中我们使用Neutron FWaaS来驱动防火墙。

OpenStack为防火墙服务提供了V1.0和V2.0两种API模型， FWaaS 2.0在社区M版本中提出，现在仍在开发中，因此我们采用FWaaS 1.0 模型和防火墙设备进行集成。

防火墙服务被抽象成多种虚拟资源，分别是firewall，policy和rule。一个firewall可以关联应用到多个router，一个firewall使用一个policy，policy是rule的集合。

在原型环境中，防火墙物理上位于服务器和区域核心中间，逻辑上串联在租户虚拟路由和区域核心中间。在我们的环境中防火墙同时也承担路由器的作用，所以FWaaS除了需要驱动防火墙下发安全规则外，还需要在防火墙上配置路由，具体包括：

一条默认路由指向上层的区域核心，用于将目标是其他区域的流量送到区域核心
数条静态路由指向下层的租户虚拟路由，用于将目标是本区域的流量送到虚拟路由。
除此以外，为了支持多租户通信，创建每个防火墙实例时FWaaS驱动需要相应地在物理防火墙上创建context，创建内向流量internal和外向流量external的Vlan子接口并加入context中。

（四）整体网络架构

原型环境的整体网络架构由云网分区和RI区域组成，其物理组网方式仍为Vlan模式，两个云网分区连接到RI互联区域。

防火墙和RI区域之间通过路由控制，防火墙以下的网络由ODL下发的OpenFlow流表控制。

服务器分别连接到一个管理网络，一个通往防火墙的VLAN网络，以及一个区域内通信的VXLAN隧道网络。

虚拟机之间的网络通信大致可以分为以下三种场景：

区域内同网段虚拟机二层通信，ARP代答流表会替目标虚拟机代答ARP请求，并接收通信报文，根据目标MAC地址和VXLAN ID，通过VXLAN隧道送到指定的节点，再匹配二层转发流表送到OVS的相应端口上。

区域内不同网段虚拟机三层通信，ARP代答流表会替网关代答ARP请求，OVS接收报文，匹配流表，由路由流表模拟路由功能并将报文的目标MAC地址修改为目标虚拟机的MAC地址，根据目标MAC地址和VXLAN ID，通过VXLAN隧道送到指定的节点，再匹配二层转发流表送到OVS的相应端口上。

跨区域通信，发送出区域时，ARP代答流表会替网关代答ARP请求，OVS接收报文，匹配流表，静态路由流表会将报文的目标MAC地址修改为防火墙接口的MAC地址，给报文加上VLAN TAG，并通过VLAN网络送到防火墙。两个区域防火墙之间由路由控制。接收进区域时，ARP代答流表会响应防火墙对虚拟路由器接口地址的ARP请求。VLAN到VXLAN转换流表会卸载报文VLAN TAG并打上目标网络的VXLAN ID。如果目标虚拟机位于本节点，由二层转发流表送到虚拟机端口，如果目标虚拟机位于其他节点，由二层转发流表通过VXLAN隧道送到相应节点，再由相应节点的OVS接收。

原型环境的整体网络部署架构如图18所示：

图18 原型环境整体网络部署架构图

（五）效果展示

1.跨区域网络拓扑

原型平台基于多租户能力，创建了两个金融机构租户，两个租户的网络地址完全隔离复用，每个租户横跨基于ODL的软件SDN方案的两个云网分区资源，且共同复用所有硬件资源，通过核心交换网络进行数据互通，最终网络拓扑如图19所示。

图19 整体网络拓扑图

在此拓扑中，租户进行跨区域资源访问测试，可以相互通信，如图20所示。

图20 跨区域通信ping测结果图

2.性能测试

方案实现后，我们在万兆环境下对该方案进行了性能测试，并且与之前应用的Nuetron方案进行了对比。

（1）测试环境
硬件环境：CPU Intel E5-2630 V3； 网卡 Intel 82599；
软件环境：操作系统 Centos7.2；云平台 OpenStack L版； 测试工具 IPerf；
测试项时长：5分钟。经与10分钟测试时长比对，5分钟测试时长所得数据已足够平稳、精确，所以本次测试时长为5分钟；
测试包长：在单对虚机性能测试，测试包长的选取参考了RFC2544，分别是134、256、512、1024、1280、1456，其中134和1456是IPerf支持的最小和最大包长；在随后的极限性能测试中，采用最大包长1456进行测试。

（2）单对虚拟机性能测试数据（虚拟机配置：8c32g）
在测试中，我们首先测试了单对虚拟机的数据转发性能，在结果中挑选了部分代表性数据如表3所示。

表3 单对虚拟机性能测试数据表

结果分析：从测试数据上看，ODL方案不管是在延时上还是在带宽上相比Neutron来说都有了比较好的提升。经计算，ODL方案时延较Neutron平均降低68.8%；带宽（不含跨网段不同主机场景）平均提升39.3%。

（3）极限性能测试数据
在本项测试中，逐步增加虚拟机数量，在同网段不同主机的场景下，采用最大包长测试跨主机通信的极限性能（带宽），得到数据如下图21所示。

图21 极限性能测试数据图

测试结果：在跨物理机通信的情况下，ODL与Neutron方案的极限带宽分别为3.17G与1.93G，ODL高出Neutron 64.2%。

（4）测试结果分析
通过测试，我们发现虽然ODL方案在万兆环境下的性能依然高于Neutron方案，但整体测试数据不佳，最高带宽只能达到3.17G，仅占整体带宽的30%，不能对网络资源进行较高效率的利用。

经过分析，我们认为产生该问题的主要原因是因为硬件网卡不支持Vxlan offload功能造成的。具备Vxlan offload功能的网卡，能够识别Vxlan数据包并对包头进行相应的处理，将原本在协议栈中进行的分片、TCP分段、重组、checksum校验等操作，转移到网卡硬件中进行，降低系统CPU的消耗，提高处理性能，能够在使用Vxlan通信的情况下较大幅度的提升带宽。而本次测试中使用的Intel 82599网卡则不具备该功能，所以造成总体性能较低。

六、总结与展望

（一）工作总结

通过本次研究我们形成了许多技术积淀。首先，我们根据实际需求，设计出一整套的软件SDN解决方案，包括整体的网络架构、能力设计与流表框架，相比其它方案来说，优势如下：

1.整体完全自主可控；
2.方案按照金融需求设计，相比其它方案更能贴合金融场景下的应用；

3. 相比商业方案更加灵活、成本更低。

其次我们通过对ODL的开发，对原生的能力进行了增强与优化，掌握了软件控制器功能定制化的能力；最后，在性能测试中，对Linux环境下的网络接收性能调优也进行了相关的研究，这对于我们来说也是很好的一次技术积累。

虽然当前方案已经实现，但是在具体的实践过程中仍存在一些问题有待解决，具体如下：

1.支持去Floating IP的分布式网关功能仍不完善，目前平台内分布式的外部接口进行ARP响应会造成交换机的MAC表震荡，当平台物理节点的数量较多的时候会影响网络稳定。因此，后续我们会对该实现机制进行进一步的优化，采用定向下发ARP响应流表的方式进行功能实现；
2.本方案中只实现了通过Vlan连接物理防火墙的流表框架，其实通过Vxlan连接虚拟防火墙的流表我们也设计了出来，只不过当前应用场景较少所以没有在控制器上进行能力实现。后续随着NFV技术在金融行业的推广应用，我们也会择机对该Vxlan的连接方案进行实现；
3.万兆环境下网络性能极限测试效果不佳，具体原因已经在上文中进行了分析，后续将优化测试环境，更换具备相应能力的网卡进行进一步测试；
4.控制器的高可用性仍待加强，针对ODL控制器的高可用方案社区中也没有给出较好的方法，所以在后续工作中也希望能得到更多业内专家们的帮助与支持。

（二）展望

中国银联正积极探索软件定义网络技术在下一代金融云环境中的深化研究与应用，并已与中国银行、中国农业银行、中国工商银行、中国建设银行、中国交通银行、兴业银行、恒丰银行、上海银行等机构就SDN技术在金融行业中的应用与联合研究需求进行了紧密沟通。当前结合各单位聚焦研究点，中国银联已发起“跨数据中心多云协同资源管理技术”的联合研究课题，希望更多的银行等金融合作机构能够参与到相关的研究工作中，共同推进软件定义网络相关的金融科技联合研究与应用。

（本次工作感谢英特尔、华为、思科、复旦大学电子金融实验室、九州云等单位参与联合研究）