一種基于SDN的服務鏈識別技術

文/石鴻偉 黃鳳芝

（1.網絡通信與安全紫金山試驗室未來網絡研究中心 江蘇省南京市 211111）

（2.河南工業大學電氣工程學院 河南省鄭州市 450001）

（3.南京鐵道職業技術學院機車車輛學院 江蘇省南京市 210031）

1 概述

近幾年來，隨著全球一體化的經濟發展，AR/VR、4K/8K等新興業務不斷涌現，對底層網絡基礎設施資源的承載能力要求越來越高，其快速部署、按需定制、靈活編排、高可靠性以及高利用率成為主要需求。而云計算的出現，充分利用計算虛擬化，網絡虛擬化，存儲虛擬化等相關技術，可以為租戶提供便捷的、靈活的、穩定的、按需的資源能力[1]。租戶可以基于其業務負載情況，快速發放和回收虛擬資源，同時租戶申請的虛擬資源可以靈活在運行狀態下從一臺服務器遷移到另外一臺服務器。

軟件定義網絡(Software Defined Network，SDN)是近幾年來興起并熱門的技術，主要的技術理念是控制面和轉發面分離，將原先傳統網絡的分布式控制，抽象出來作為控制平面，并使用SDN控制器集中控制全網設備，降低網絡的復雜程度，網絡設備只負責單純的數據轉發，實現了網絡流量的靈活控制，實現對網絡資源靈活的按需調配[2]。

隨著云計算的規模不斷擴大，企業租戶日益增多，租戶申請的虛擬機也隨著業務的擴展不斷增加，差異化的業務種類也隨之上升，底層網絡上各種特征的數據流量不斷復雜多樣化。通過云計算技術和SDN技術的相結合，可以很好的解決底層網絡拓撲變化頻率高，業務種類多流量變化大，全局敏捷感應等問題，滿足企業用戶多樣化、定制化的需求[3]。

但同時也帶來了另外的問題。

（1）在基于SDN/NFV技術的虛擬網絡中，虛擬網絡功能(Virtual Network Function，VNF)設備，雖然具有靈活性、敏捷性的優勢，加快新業務部署的速度，同時也可以為企業用戶降低CAPEX(Capital Expenditures)支出[4]。但是無論從轉發性能還是穩定性方面，都跟專用硬件設備有很大差距[5]。

（2）在傳統網絡中，已有的專用硬件設備，不支持虛擬化技術，不支持SDN技術，且無法納管到云計算虛擬網絡中，無法實現虛擬網絡和專用硬件設備統一編排管理，也就無法滿足專用硬件設備的按需調度，按需編排的業務需求。

如何將這些高性能、高可靠性的專用硬件設備接入到不斷擴大的云計算虛擬網絡中，成為當前亟需解決的難題。

本文在此方面進行了深入研究，依托擴展通信協議的研究方法，提出一種新型的服務鏈識別機制。通常在Openstack&SDN的網絡環境下，會采用VXLAN協議作為虛擬化網絡Overlay技術[6]。因此，本文通過研究擴展VXLAN網絡通信協議，實現虛擬網絡和專用硬件設備間的融合通信。具有支持多租戶的業務編排能力，為租戶提供靈活和可靠的安全防護能力。

2 設計思想

圖1：NSH封裝格式

為了滿足業務的定制化需求，提供安全、穩定、敏捷的網絡服務，業務數據報文在網絡中進行轉發，通常會依據業務需求經過多種多樣的業務節點(Service Node)。這些業務節點包括防火墻(FireWall，FW)、負載均衡(Load Balance，LB)、入侵檢測系統(Intrusion Detection System，IDS)、入侵防御系統(Intrusion Prevention System，IPS)等。通常情況下，網絡數據流量需要按照業務邏輯要求的既定順序，依次流經這些業務節點，才能實現所需要的安全服務能力，從而形成 SDN定義的Overlay虛擬網絡中的服務鏈(Service Function Chaining，SFC)[7][8]。

基于SDN Overlay技術的服務鏈，每條服務鏈都具有唯一的標識，業務數據報文在轉發過程中，需要攜帶這些特征，需要對應的字段來記錄這些特征。包括業務數據報文屬于哪條服務鏈，當前業務數據報文在服務鏈中的跳數等。

網絡服務頭(Network Service Header，NSH)是專門為服務鏈設計的封裝格式[9]，并且在開源SDN控制器OpenDaylight的SFC項目中采用。其封裝格式如圖1所示。

NSH報文頭包含三部分信息：

（1）NSH基本頭信息（32bits）；

（2）服務路徑信息（32bits）；

其中，

Service Path Identifier(SPI):表示一個服務鏈標識符（32bits）。

Service Index (SI):表示一個服務鏈上Service Function的位置（8 bits）。

（3）Metadata信息（可選的）。

由于NSH是對以太報文進行了字段擴展，可以攜帶更多的業務信息，完成更加復雜的業務處理。并且其帶有Protocol Type字段，因此可以承載于VXLAN、GRE等多種Overlay封裝中。

但是，由于NSH方案是對標準以太封裝進行字段擴展，所以需要硬件網絡設備的芯片支持這種擴展，而新型芯片推出和擴展并非易事，需要推動芯片相關的整個產業鏈的認同和真正的實際需求，才有可能大規模的生產，從而降低芯片乃至整個網絡架構的成本。短期看，支持NSH的芯片尚無法大規模投產應用。

鑒于目前硬件轉發設備（交換機、路由器等）普遍都采用支持VXLAN協議的芯片，本文設計一種新型的服務鏈識別機制，借鑒數據結構中的聯合體思想，在Overlay網絡中，復用VXLAN協議中的VNI字段，而不是單純的字段擴展方式，擴展VXLAN網絡通信協議。借助物理SDN交換機作為接入設備，將專用硬件設備（防火墻、負載均衡等）接入虛擬網絡。

圖2：網絡組網示意圖

圖3：擴展的VXLAN協議報文圖

圖4：VXLAN報文和VLAN報文映射關系圖

本方案可以支持識別不同的服務鏈，在服務鏈的每一跳之間轉發業務數據報文時，對數據報文外層的VXLAN報文頭進行重新編解碼，實現對業務數據報文的識別以及指導轉發，從而實現虛擬網絡和硬件專用設備協同控制以及編排管理。

3 設計方法

3.1 接入方式

為了能夠將專用硬件設備（防火墻、IPS）接入虛擬網絡，本文采用通過物理SDN交換機作為接入設備，進行組網接入，如圖2所示。

構造一個服務鏈編排試驗場景，由虛擬機1向虛擬機2及虛擬機3的發送數據流。按照服務鏈業務需求，數據報文將依次經過已定義的防火墻，IPS設備。在計算節點A OVS、計算節點B OVS和物理SDN交換機之間是由SDN控制器構建的VXLAN隧道，提供跨物理節點的二、三層通信及租戶隔離等虛擬網絡能力。

3.2 服務鏈標識

3.2.1 SDN交換機之間鏈路

計算節點A OVS交換機，計算節點B OVS交換機以及物理SDN交換機通過SDN控制器兩兩之間通過VXLAN隧道構建Overlay網絡。

圖5：業務邏輯處理流程圖

圖6：軟件系統架構圖

本文通過擴展VXLAN協議中VNI字段進行服務鏈的標識。VNI總長度24位，擴展方式如下：

設置高6位作為 SFC TTL，服務鏈的跳數，當一個服務鏈多次進入一個主機下的不同服務點時，可以通過匹配 SFC TTL確定是第幾次進入該服務節點。最大可以支持64跳。

設置低18位作為 SFC Segment ID，記錄服務鏈編號，用于唯一確定一個服務鏈。最大可以支持262144條業務服務鏈。如圖3所示。

3.2.2 物理SDN交換機與專用硬件設備之間鏈路

由于物理SDN交換機與所接入的防火墻和IPS之間不構建VXLAN隧道，兩者之間是通過原始數據報文進行傳遞，數據報文經過物理SDN交換機處理后，剝掉VXLAN報文頭，VNI信息丟失，轉發給專用硬件設備處理，當專用硬件設備處理完成后，將數據包送回給物理SDN交換機時，在物理SDN交換機上，如何識別該數據包屬于哪條服務鏈，如何重新填充VNI信息，封裝VXLAN報文頭，是一個重要問題。

本文中，采用VNI和VLAN ID做Mapping映射的機制進行解決。在物理SDN交換機剝掉VXLAN報文頭，根據VNI的信息重新為數據報文打上VLAN ID，送到專用硬件設備進行處理，處理完成后，攜帶相同的VLAN ID送回給物理SDN交換機，物理SDN交換機根據VLAN ID信息還原VNI信息，SFC TTL減1，SFC Segment ID保持不變，重新封裝VXLAN報文頭，在服務鏈中繼續轉發。如圖4所示。

3.3 業務邏輯處理流程

完整的業務邏輯處理流程如圖5所示。

在步驟01、步驟02，SDN控制器接收創建服務鏈請求，計算并下發服務鏈轉發表項至各SDN交換機。

在步驟03、步驟04，計算節點A OVS接受來自虛擬機1的請求數據流，根據匹配流表項判斷數據包是否屬于服務鏈并處于該服務鏈的第一跳，若數據包不屬于服務鏈，則執行步驟06，按照正常轉發流程進行數據轉發，若數據包屬于服務鏈，則執行步驟05，封裝該數據包至VXLAN隧道，并修改VNI為服務鏈專有VNI，發送至物理SDN交換機。

在步驟07，物理SDN交換機接收到轉發過來的數據包，并根據轉發表項識別數據包如步驟08、步驟10。若數據包來自VXLAN隧道，且VNI為當前服務鏈ID，則執行步驟09，解封裝VXLAN數據包，并為之添加VLAN報文頭，修改VLAN ID為防火墻使用VLAN，并轉發至防火墻。若數據包來自防火墻過濾之后的VLAN數據，則執行步驟13，根據端口和VLAN識別該數據包所屬服務鏈，若下一跳需轉發至IPS設備，修改VLAN為IPS設備使用VLAN，轉發至IPS設備。若數據包來自IPS設備過濾后的VLAN數據，則執行步驟11，根據端口和VLAN識別該數據包所屬服務鏈，若為當前服務鏈最后一跳，則封裝至VXLAN隧道，修改VNI為目的虛擬機2、虛擬機3所屬租戶網絡VNI，并發送至虛擬機2、虛擬機3所在計算節點B OVS上。

在步驟14，物理SDN交換機接收數據包，按照正常轉發流程處理數據包。

4 仿真平臺實現

按照以上設計原理及方案進行了軟件系統實現，完成試驗仿真平臺。軟件系統架構如圖6所示。

4.1 應用層

前端采用Vue框架以及后端采用SprintBoot框架設計實現，提供友好的人機交互界面。

數據采集：通過對虛擬機和物理機的安全、服務、狀態、資源等信息進行監控，采集虛擬機的相關數據。

數據分析：對采集到的數據進行智能分析處理，將分析結果采用可視化的圖形界面進行展示。

流量統計：負責對虛擬機和SDN交換機進行流量統計。

流量清洗：對數據流量進行實時監控，及時發現包括攻擊在內的異常流量。在不影響正常業務的前提下，清洗掉異常流量。

故障檢測：監控虛擬機的健康狀態，當監控到主節點不可用時，及時將流量切換到備節點。

負載分擔：監控虛擬機的性能，當系統超負荷時，動態生成新實例，實現負荷分擔。

VPN功能：支持通過VPN讓外網用戶接入虛擬網絡。

QoS功能：通過QoS限速和優先級功能，保證網絡的高效運行。

4.2 管理控制層

云平臺管理采用基于開源軟件Openstack設計實現，提供計算資源、存儲資源的虛擬化能力。

SDN控制器采用基于開源軟件OpenDaylight設計實現，提供網絡資源的虛擬化能力以及業務編排能力。

編排配置：負責管理網絡編排服務的相關配置，包括VNF配置、PNF配置、VNFFG配置和NS配置。

圖7：試驗流量示意圖

編排管理：分為基礎網絡編排和網絡服務編排，通過給用戶提供可視化的界面，完成網絡拓撲的構建和網絡業務鏈的自定義編排。

生命周期管理：負責VNF和終端的生命周期管理。

業務策略管理：通過對虛擬機的監控，實現VNF主備和動態伸縮的業務策略。

用戶管理：對管理員和普通用戶不同角色的權限管理。

系統管理：包括配額管理、規格管理和鏡像管理，屬于網絡編排服務的基礎配置。

云平臺管理：通過對云平臺的管理，完成虛擬機的創建，為網絡編排業務提供基礎設施。

ODL控制器管理：通過ODL控制器下發流表，實現面向業務流的自動化編排。

SDN交換機管理：通過SDN交換機，實現與網絡中間設備的交互。

網絡中間設備管理：通過添加網絡中間設備，實現網絡編排服務的虛實結合功能。

4.3 基礎設施層

服務器采用通用X86服務器。物理SDN交換機采用盛科V580交換機。防火墻、IPS分別采用X86服務器結合pfSense以及Snort模擬實現。

5 實驗驗證及分析

應用試驗仿真平臺，構建2臺虛擬機以及1臺物理防火墻試驗場景，進行服務鏈編排功能驗證。

試驗目標為，試驗用戶按照需求構建網絡拓撲，創建服務鏈，并下發到轉發設備上，在經過服務鏈編排后，同一子網內的虛擬機vm1到vm2的流量經過硬件防火墻進行清洗過濾，實現防火墻對流量的策略控制。如圖7所示。

首先，試驗用戶通過光纖將硬件防火墻接入到物理SDN交換機上，并在試驗仿真平臺上，拖拽網絡元素，包括子網、虛擬機以及防火墻網元，構建網絡拓撲。按照試驗需求，指定服務鏈，進行業務編排，創建試驗。如圖8所示。

然后，進行試驗驗證。

當防火墻規則設置為允許時，通過平臺系統登錄vm1，執行 ping vm2操作，會看到vm1可以ping通vm2。如圖9所示。

當防火墻規則設置為禁止時，通過平臺系統登錄vm1，執行 ping vm2操作，會看到vm1不可以ping通vm2。如圖10所示。

試驗證明，在將硬件防火墻接入到虛擬網絡后，通過業務編排，指定服務鏈，利用新型服務鏈識別機制，業務數據報文是可以按照指定的服務鏈需求，經過了硬件防火墻，執行對應的防火墻策略控制，滿足試驗的需求。

6 結束語

本文借助擴展通信協議的研究方法，基于主流的VXLAN網絡協議進行擴展，提出了一種新型的服務鏈識別機制，并設計研發試驗仿真平臺，對底層的虛擬網絡和硬件防火墻進行試驗驗證。通過在仿真平臺上構建自定義拓撲、按需指定服務鏈、以及防火墻策略控制?？梢院苤庇^的看到轉發面業務流量完全按照指定服務鏈的要求進行轉發，硬件防火墻的安全策略也同時生效。最終實現了虛擬網絡和專用硬件設備之間的融合通信?？梢詾樽鈶艟W絡提供靈活可靠的安全防護能力，滿足新興的業務需求。

圖8：試驗詳情頁面

圖9：VM1可以ping通界面

圖10：VM1禁止ping通界面