基于开源SDN控制器的下一代金融云网络的研究与实践
本文作者：
中國銀聯電子支付研究院（電子商務與電子支付國家工程實驗室）：袁航、周雍愷、祖立軍
中國銀聯信息總中心：任明、吳一娜
中國銀行：許泓
一、行業發展歷程與技術發展趨勢
（一）行業發展歷程
金融數據中心網絡技術架構與行業安全、合規等特色性要求緊密結合，是金融數據中心顯著區別與其他行業數據中心的關鍵領域，是金融數據中心建設中的核心。中國金融數據中心網絡建設的歷程與金融行業近三十年信息化過程密不可分，總結歸納金融數據中心網絡的發展主要經歷了三個階段：
第一階段：專網專用階段。該階段是采用特有的網絡協議來對專用設備進行連通，如IBM的專有網絡協議SNA對其大型機與中型機的支持；
第二階段：基于IP協議，分層分區。在本階段采用了更為開放通用的IP技術協議，不再受制于某個廠商，組網更加靈活。此外，本階段中雖然各金融機構的網絡架構跟隨應用系統的發展而變化，但一般會出于應用分層及安全的要求，遵循“垂直分層、水平分區”的理念。
第三階段：大規模共享接入。技術上更為開放，網絡虛擬化與SDN等技術開始在金融行業應用。在繼承安全區域保護機制下，采用“總線型、模塊化”架構，中國的金融數據中心網絡結構趨于一致，并且普遍采用網絡虛擬化共享接入的技術方案，對新的云計算環境下對網絡的靈活、彈性等要求進行有效應對。
（二）技術發展趨勢
近年來，隨著金融數據中心云化的加速，金融云作為最新的基礎設施形態開始被行業認同并接納。但在金融云環境下，傳統網絡技術架構受到了挑戰：一方面虛擬化思想的出現，顛覆了原有的數據中心網絡模型，使得傳統網絡技術已不足以適配云環境下產生的新場景，如虛擬機的出現要求網絡顆粒度從物理機細化到了虛擬機級別；另一方面面向互聯網的金融創新業務的快速發展，也會對網絡的性能、彈性等特性提出更高的要求。所以未來金融數據中心網絡技術必將進行變革式的創新發展，我們認為未來發展趨勢主要包括以下三點：
1、面向互聯網新興業務的敏捷網絡, 即未來金融云網絡能夠高效滿足互聯網方式下金融創新應用的多樣化需求。一是網絡資源的快速提供與開通，以支撐應用的快速投產；二是強化細粒度的網絡策略管控能力，在應用需求的頻繁變化的情況下，網絡能夠進行靈活地變更調整；三是網絡可兼容多樣化的資源類型接入，以融合網絡方式實現虛擬機、容器、物理機不同資源的統一接入。
2、面向數據中心資源動態變化的彈性網絡，即在大流量挑戰下保證網絡的平穩運行。一是金融云規模巨大，承載業務系統眾多，要求網絡必須具備足夠的容量與健壯性，比如如何解決網絡規?？焖僭鲩L情況下存在廣播風暴的風險；二、在營銷活動等訪問量暴增的情況下，網絡能夠根據應用重要性與鏈路情況實現對流量的智能調度，保證核心業務平穩運行；三則是在計算資源不充足的情況下，網絡能夠連通分布在不同物理位置的計算資源池，打破由于物理區域隔離所造成的資源容量限制。
3、面向數字化智能化運維模式的網絡，即在網絡運維壓力暴增的情況下，能夠做到先于業務發現網絡問題。一方面，金融行業數據中心規模不斷擴張，網絡終端數量與網絡模型復雜度都呈幾何式增長，必須采用高效、出錯率低自動化運維代替傳統的手工方式；另一方面，在金融云的新常態下，網絡運維模式需要形成閉環來提升自身價值，通過對流量數據的采集分析，實現對網絡的問題預測、排障、優化，甚至做到對網絡攻擊的規避，提升整體網絡的穩定性。
軟件定義網絡（SDN）技術通過分布式架構理念，將網絡中數據平面與控制平面相分離，從而實現了網絡流量的靈活控制，為核心網絡及應用的創新提供了良好的平臺，其與金融云網絡發展趨勢相契合，是實現金融云網絡服務的有效支撐技術。
二、以金融云為載體的創新網絡需求
（一）金融云對網絡的創新需求
基于上述金融云網絡的發展趨勢，結合金融業務面向互聯網的挑戰，我們認為未來金融云網絡需求可總結為高安全、高敏捷、高性能、高可用、高彈性與高可管理：
高安全，金融業務的特殊性對承載網絡的第一要求即為保證數據的安全性，因此金融云網絡必須具備能夠抵御系統外部攻擊，保證數據完備性與私密性的能力；
高敏捷，實現業務快速上線，面對應用的變化達到資源的按需變更，通過新技術應用打破因重安全而舍效率的困局，在云計算新環境下安全與高效并重；
高性能，面對秒殺等新業務場景等的極限服務能力，實現時延和帶寬等關鍵指標的跨越式提升，同時注重資源的高效利用，用盡可能少的資源實現最大的性能服務。
高可用，網絡架構持續穩定影響金融數據中心全局服務能力，網絡架構需要基于穩定可靠的技術構建，使網絡服務具備7*24小時業務連續性服務的能力；
高彈性，一是內部彈性強化，打破豎井式架構中網絡區域成為限制資源共享的壁壘，實現網絡資源池整合與靈活共享與隔離，二是外部彈性兼容，支持新老架構并存，從而使原有網絡可以平滑過渡到新架構；
高可管理，一是實現管理的體系的簡化，支持多品牌的融合管理，二是實現管理自動化與智能化，提供端到端的業務可視和故障快速定位、排查能力，使日常運維從大量人工維護的高工作量解放出來；
（二）金融私有云與行業云對網絡需求的異同分析
雖然金融私有云與行業云本質上都承載金融業務，但是由于應用場景與服務模式上的不同，也使得金融私有云與行業云對網絡的需求有所差異。在表1中，我們基于上面提出網絡需求的6個維度，對金融私有云與行業云網絡需求的異同進行分析。
三、下一代金融云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提出了防火墻的物理連接方式。在能力設計的第四點已經提出，為保證業務運行的穩定性，降低網絡故障瓶頸與影響范圍，在金融數據中心防火墻采用并聯方式接入。且為保證防火墻的性能，降低故障率，區域的外部網關不會建立在防火墻上。
既然防火墻已并聯方式接入且外部網關不在防火墻上，那么區域內流量要發送到防火墻必須經過引流才能實現。具體引流方案我們會放在后面關于防火墻并聯接入實現的內容中，在此不做贅述。
問題二：防火墻如何將流量發送到區域內
該問題也會產生兩個子問題：
綜上所述，要實現跨區域通信的影響面較廣，分布式網關、防火墻接入都會有所涉及。為使功能實現更加清晰，我們在這里只對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
流表邏輯實現
文件：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 單對虛擬機性能測試數據表（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技術在金融行業中的應用與聯合研究需求進行了緊密溝通。當前結合各單位聚焦研究點，中國銀聯已發起“跨數據中心多云協同資源管理技術”的聯合研究課題，希望更多的銀行等金融合作機構能夠參與到相關的研究工作中，共同推進軟件定義網絡相關的金融科技聯合研究與應用。
（本次工作感謝英特爾、華為、思科、復旦大學電子金融實驗室、九州云等單位參與聯合研究）
總結
以上是生活随笔為你收集整理的基于开源SDN控制器的下一代金融云网络的研究与实践的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 高中函数知识点太多记不住？一张思维导图教
- 下一篇： 计算机添加桌面小插件,如何在电脑桌面添加