基于开源SDN控制器的下一代金融云网络方案.docx

基于开源SDN控制器的下一代金融云网络方案 目 录基于开源SDN控制器的下一代金融云网络方案1一、行业发展历程与技术发展趋势3（一）行业发展历程3（二）技术发展趋势3二、以金融云为载体的创新网络需求4（一）金融云对网络的创新需求4（二）金融私有云与行业云对网络需求的异同分析5三、下一代金融云SDN网络的设计原则与架构规划6（一）网络设计原则6（二）网络架构7四、基于ODL开源控制器的数据中心内SDN网络方案研究与实现8（一）银联SDN应用研究现状8（二）下一代金融云网络软件SDN网络方案93.能力设计11（三）基于OpenFlow流表的能力实现13五、原型实践与效果29（一）物理架构概述29（二）管理控制平面概述30（三）云网与云控平台集成30（四）整体网络架构33（五）效果展示34六、总结与展望37（一）工作总结37（二）展望38本文介绍了下一代金融云SDN网络的设计原则与架构规划，和基于ODL开源控制器的数据中心内SDN网络方案研究与实现。一、行业发展历程与技术发展趋势（一）行业发展历程金融数据中心网络技术架构与行业安全、合规等特色性要求紧密结合，是金融数据中心显著区别与其他行业数据中心的关键领域，是金融数据中心建设中的核心。中国金融数据中心网络建设的历程与金融行业近三十年信息化过程密不可分，总结归纳金融数据中心网络的发展主要经历了三个阶段：第一阶段：专网专用阶段。该阶段是采用特有的网络协议来对专用设备进行连通，如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 DirectorARP_RESPONDER Table20 分布式ARP应答INBOUND_NAT Table30 入站流量浮动IP流量DNATEGRESS_ACL Table40 出口访问控制LOAD_BALANCER Table50 分布式负载均衡ROUTING Table60 分布式路由L3_FORWARDING Table70 3层转发L2_REWRITE Table80 2层重写服务INGRESS_ACL Table90 入口访问控制OUTBOUND_NAT Table100 访问外部网络流量的SNATL2_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函数：sendVlanTaggedArpcreateVlanTaggedArpFrame能力实现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,priori