基于开源SDN控制器的下一代金融云网络的研究与实践

点击上方“CSDN”，选择“置顶公众号”

关键时刻，第一时间送达！

如果没有从事过金融相关业务，你一定无法明白这个行业近些年来的变迁。以银行业为例，十年前，银行开展的业务很少，银行与用户产生关系的主要场所是在柜台，系统更新的速度也很慢。很多IT资源的交付甚至是手工完成，缺少自动化手段。

近几年，移动互联网的飞速发展，越来越多的用户通过移动或PC端进行购物、理财等金融交易。一方面，各大银行需要通过互联网手段开展更多业务借此提高用户数量与黏性；另一方面，快速攀升的业务数量和种类也对银行现有的IT系统带来了挑战，如何快速响应业务系统的变化，快速提供IT基础资源等问题成为银行业目前所面临的问题。

其实，相比较于其他行业，银行业在安全、合规等方面，已经进步了很多，银行业信息化的发展给我们的生活带来了极大的便利。然而，放大到整个金融体系，新技术正被推至科技创新、促进业务发展的地位，而云计算技术成为弥补金融技术提升整体金融业务的关键。

说起来，金融行业近三十年的信息化过程反映出的却是中国金融数据中心网络建设的历程。

金融业务趋势下，面向互联网的挑战

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

而随着近年来金融数据中心云化的加速，金融云作为最新的基础设施形态开始被行业认同并接纳。

但在金融云环境下，传统网络技术架构受到了挑战：

一方面，虚拟化思想的出现，颠覆了原有的数据中心网络模型，使得传统网络技术已不足以适配云环境下产生的新场景，如虚拟机的出现要求网络颗粒度从物理机细化到了虚拟机级别；

另一方面，面向互联网的金融创新业务的快速发展，也会对网络的性能、弹性等特性提出更高的要求。所以未来金融数据中心网络技术必将进行变革式的创新发展，其中便包括面向互联网新兴业务的敏捷网络、面向数据中心资源动态变化的弹性网络、面向数字化智能化运维模式的网络等。

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

深层次的原因：金融云对网络的创新需求

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

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

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

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

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

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

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

不过，需要指出的是，虽然金融私有云与行业云本质上都承载金融业务，但是由于应用场景与服务模式上的不同，也使得金融私有云与行业云对网络的需求有所差异。比如在安全性方面，私有云主要是外部攻击防范，而行业云中承载着不同机构的业务系统，除了外部攻击防范外，平台内部不同租户的数据安全隔离以及内部攻击防范也十分重要。

基于上述金融云行业发展历程、趋势及挑战、需求，来自中国银联电子支付研究院（电子商务与电子支付国家工程实验室）的袁航、周雍恺、祖立军，中国银联信息总中心的任明、吴一娜以及中国银行的许泓共同撰文分享了他们对于下一代金融云网络的研究与实践，并以近两万字的篇幅详细介绍了其中的研究及实践细节，CSDN 在此做扼要摘录（点击「阅读原文」可获取完整内容）：

下一代金融云SDN产品架构及解决方案

首先，来简单说说下一代金融云SDN网络的设计原则与架构规划：

（一）网络设计原则

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

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

2. 网络能力全部服务化实现

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

3. 网络资源统一编排管理

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

（二）网络架构

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

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

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

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

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

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

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

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

数据中心内SDN网络方案研究与实现

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

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

而中国银联在对 SDN 软硬方案进行研究测试后，将两套方案全部落地生产。其中，银联私有生产云采用华为SDN整体硬件方案，银联生产托管云则采用Neutron+OpenvSwitch的软件SDN方案。当前，已经实现了网络二/三层、负载均衡、防火墙等多网络资源服务，承载了近期银联与相关合作金融机构的关键应用，有效支撑了银联业务创新。

下面，具体来看方案设计与实现思路。

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

• 首先，在对方案的能力设计上，结合了当前金融数据中心针对软件 SDN 方案的需求来进行规划，主要围绕性能、稳定性、可扩展性等方面；

• 其次，根据方案的能力设计，对方案的技术选型进行了思考与规划，具体分为两个层次：采用开源技术框架实现，核心控制层采用开源控制器OpenDayLight，上层编排仍使用OpenStack的Neutron；进行分布式路由、分布式 ARP、跨区域互联、防火墙并联接入等具体技术方案；

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

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

基于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，功能较为复杂。

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

图3  主要流表框架图

2. 能力优化与实现

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

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

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

图4 RI跨区域通信示意图

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

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

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

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

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

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

原生ODL实现方式

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

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

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

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

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

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

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

上图是一张分布式网关的物理结构图，由图可看出每台物理节点的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上。具体如图8所示。

图8 分布式网关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隧道发送到虚拟机所处的物理节点，然后再送到虚拟机。相应流表如下： 

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（二层转发到虚拟机）

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

下面我们结合一个跨区域通信的场景，举例分析跨区域虚拟机通信过程中经过的流表以及各个流表的功能。

如图9所示，两个虚拟机VM1和VM2分别在两个区域的两台主机上，VM1向VM2发送ICMP请求。

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

首先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 解决方案，包括整体的网络架构、能力设计与流表框架，相比其它方案来说，优势如下：

• 整体完全自主可控；

• 方案按照金融需求设计，相比其它方案更能贴合金融场景下的应用；

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

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

虽然当前方案已经实现，但是在具体的实践过程中仍存在一些问题有待解决，比如上文所说的万兆环境下网络性能极限测试效果不佳，以及控制器的高可用性仍待加强等。

由于版面限制，文章省略了“原型实践与效果”部分，其他部分也进行了适当删减，如需要浏览完整全文，请点击「阅读原文」获取完整内容。

最后，特别感谢英特尔、华为、思科、复旦大学电子金融实验室、九州云等单位参与联合研究。