ZZ:SDNLAB技術分享（一）：ODL的SFC入門和Demo

在網絡通信過程中，包含各式各樣的網絡服務功能。既可以包含傳統的像防火墻，NAT等功能，也有包含特定的網絡應用功能(Service Function)。將特定的網絡應用功能有序地組合起來，接著讓流量通過這些服務功能就構成了網絡服務鏈(Network Service Chain)。一般在數據中心環境下，往往會有網絡服務鏈（Network Service Chaining）的部署需求，使得報文在數據中心傳遞的時候，能夠經過各種各樣的服務節點，保證安全、快速、穩定的網絡服務。

1.SDN服務鏈基本概述

由于Overlay網絡的發展，使得虛擬網絡和物理網絡分離，讓數據中心的網絡控制變得更加靈活，更具有擴展性。然而，在數據中心中，還存在很多介于虛擬網絡和物理網絡之間的中間件，如防火墻，QoS，負載均衡器等。這些中間件提供了必要的業務處理功能，即Service Function。靈活、便捷、高效、安全地調配流量到Service Function上處理，形成服務鏈（Service Function Chaining），這就是SFC項目要解決的問題。服務鏈可以理解為一種業務形式。

過去也有服務鏈的概念，但傳統的網絡服務鏈往往和網絡拓撲緊密耦合、部署復雜，在服務鏈變更、擴容時，都需要改動網絡拓撲，重新進行網絡設備的配置。而云計算環境廣泛使用虛擬化技術，具有動態性、高流動性、規模易變化、多租戶等特點，傳統網絡的服務鏈無法滿足這些需求，SDN的出現讓服務鏈又煥發了生機。因此，當前再談及服務鏈時，默認指的是SDN服務鏈。

與傳統DC中配置的網絡服務鏈相比，基于SDN的SFC具有如下的優勢：

傳統的網絡服務鏈往往基于手工配置，很大程度上依賴于具體的網絡拓撲，以至于網絡設備之間的耦合性很大。而基于SDN的配置，可以動態的添加或者刪除鏈表上的服務節點，不僅方便使用，而且解耦了網絡設備之間的關聯。

在數據流量經過鏈表的過程中，SFC還支持分類器與服務，服務與服務之間的上下文信息共享。

在傳統的數據服務鏈中，數據包往往要經過過次分類，即多次解包、封包的過程。而在SFC中，這個過程大大縮減，一般只需在分類一次即可，使得整個過程更便捷、更高效。

2.基于OpenDaylight的服務鏈項目

2.1 Service Function Chaining 的架構及組件

OpenDaylight的SFC項目是整個控制器平臺內部的一個功能模塊。用戶可以通過控制器提供的北向API來使用SFC的功能，例如創建、更新或者刪除Service Chain，還可以通過配置非透明的metadata數據段用來在Service Function的節點間實現數據共享。同時，項目可以向Controller的DataStore中注冊、配置服務節點，并獲取拓撲。南向也支持Netconf，Openflow12等協議。

SFC核心組件如下：

Classification：根據初始化的（配置好的）policy匹配數據流進行封裝，然后轉入到Service Function Chain中。

Service Function(SF): 負責對收到的數據包進行特定功能的處理。作為一個邏輯上的組件，SF在具體實現的上可以是一個虛擬的元素，或者是嵌入在具體網絡設備上的某種功能。常見的SF有：防火墻(firewall)，WAN設備加速器，深層報文檢測(Deep Packet Inspection,DPI)，NAT等等。

Service Function Forwarder(SFF):主要負責Service Function Chaining上的流量轉發控制。

Service Function Chain(SFC): SFC定義了一個抽象的Service Function有序集合。經過分類后的包要依次去遍歷集合中的Service Function。比如：用戶可以配置firewall->qos->dpi三種服務來構建一條SFC。

Rendered Service Path(RSP) : 數據包實際行走的路徑。

Service Function Path(Service Function Path): SFP是一個邏輯概念，

它是介于SFC和RSP之間的一層抽象，有時候會將SFP與SFC等同。

2.2 ODL的SFC項目工作流原理

那么，SFC項目是怎么綜合起上述的組件進行工作的呢？

一種基于NSH封裝頭的機制是，使用ODL配置并下發一條Service Function Chain，每條Chain都有自己的標識。當host1發送數據包給host2，數據包首先會到分類器中進行篩選。分類出需要經過Service Function Chaining的數據包會進行封裝，并打上NSH頭。頭中包含了很多信息，包括走哪一條服務鏈，服務鏈有幾跳等。接著數據包會依次經過SFF，由SFF將數據包傳遞給SF或者下一跳的SFF，直到鏈的最后。

3.實驗

本篇文章旨在通過基本概念的介紹和一個SFC的實驗，幫助大家了解SFC是什么，在OpenDaylight中如何去配置基本的SFC。通過對SFC有個大致的了解，有興趣的同學可以繼續深入地去研究NSH，SFC架構及應用等知識。

3.1 實驗準備

系統需要是Ubuntu 14.04(Mac也可以)

Java 7

Mave 3.4

git OpenDaylight SFC項目到本地

Python3.4

Python導入包包括：requests,flask,netifaces,paramiko等

在Ubuntu14.04下搭建ODL環境參考：https://wiki.opendaylight.org/view/Install_On_Ubuntu_14.04

在Ubuntu下安裝Python3.4及所需包如下：

如果沒有Python3.4:

安裝一個Python3.4-pip安裝器

安裝flask包，其他包安裝類似，根據版本不同，安裝方法或者指令不一定與這里相同：

3.2 術語簡表：

SF : Service Function

SFF : Service Function Forwarder

SFP : Service Function Path

RSP : Rendered Service Path

ODL : OpenDaylight

SFC Agent: Service Function Chaining Agent.

3.3 基本配置和安裝：

ifconfig查看本地機器的ip，我這邊是：192.168.2.134

安裝ODL的sfc項目：git clone http://git.opendaylight.org/gerrit/sfc

樓主使用的SFC是5月份的版本：

可以git reset –-hard cd12dda6回到那個版本。

如果讀者在實驗的時候，用的是最新版本的SFC，在sfc/sfc-py/sfc/nsh/service.py腳本有很多bug，要做適當修改。這里為方便，就使用之前版本演示。

用maven構建一下項目：

Shell

mvn clean install –DskipTests

1

mvn?clean?install?–DskipTests

啟動ODL:

過一會兒，就可以用瀏覽器進入SFC的ui界面了：http://localhost:8181/sfc/index.html 用戶名和密碼都是:admin

剛開始進來都是空的，點擊System Info會有404也不要緊張，因為什么都沒有配置。另外，在ODL中創建SFC有兩種方式：第一，用北向的RESTAPI；第二，用UI來創建。本次實驗用將基于UI，這樣看起來比較直觀，方便理解。后續有興趣用REST來配置的參見SFC 101文檔。

3.4 開始實驗

3.4.1 啟動SFC Agent

SFC Agent是用Python腳本寫的一個仿真工具，位于SFC項目的sfc-py目錄下。在實驗的過程中，ODL在南向通過REST與Agent進行通信，即ODL通過REST將配置的信息下發給Agent，Agent根據這些信息，在數據平面仿真出相應的元素組件。使用Agent的好處就是在實驗中，簡化南向接口，易于實現實驗。

進入到sfc/sfc-py目錄下，打開start_agent.sh文件，修改默認的ip地址為本地主機ip:

也可以將127.0.0.1改成192.168.2.134。

啟動Agent:

根據上圖可以直到Agent運行的端口是5000。

3.4.2 創建Service Function

點擊導航欄的Service Function標簽，再點擊”Add Service Function”，填寫表格如下：

點擊Submit，在Agent端，有如下信息輸出：

表明Agent已經成功為我們創建好了SF1(firewall)。

這里有幾個地方要注意：

1.NSH頭的使用。我們這里是基于Agent的仿真實驗，沒有對分類器做配置。選True 和False都沒有關系，但是實際情況下會根據NSH頭的信息來選擇具體的路徑。具體可以研究：http://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/

2.數據平面的通信方式一定要選，這里選vxlan-gpe。要不然Agent收不到請求。

3.SFF1暫時還沒有創建，可以先填入SFF1，后面創建SFF的名字要與這里一致。

3.4.3 創建SFF

在導航菜單中點擊Service Function Forwarder，點擊”Add Service Function Forwarder”，填寫表單信息如下：

右下角的SFF dictionary“Remove”掉，后面的版本也沒有這個directory了。如下圖：

submit以后,在Agent端，SFF創建成功信息打印如下：

3.4.4 目前拓撲和工作流

3.4.5 創建Service Function Chain

在導航欄點擊Service Function Chain標簽：

點擊創建Service Function Chain

填入名字“Chain-1”,提交

將”firewall”的SF拖拽到右邊的Chain-1中

保存一下，點擊deploy，生成一條Service Function Path，命名為“Chain-1-Path-1”,這樣就創建好了Service Function Paht。

3.4.6 創建Rendered Function Path

導航欄中點擊”Service Function Paths” ,將會看到我們剛創建的SFP。

根據SFP，點擊上圖按鈕，可以生成一條RSP。如果勾上了”Symmetric path”就會另外生成一條對稱反向的RSP。

成功以后，記住RSP的兩個重要屬性“Path-ID”為63，“starting-index”為255。

這個時候我們可以看到Agent里面打印的消息：

通過從SFC 的創建到SFP，再到RSP的創建，是一個由抽象到具體的過程。從應用的角度來理解，SFC是對Service Function的一層抽象，這里的SFP是具體化每個Service Function到其對應的配置的SF(SF1)，而RSP的生成代表包具體穿過的路徑將是怎樣的。

3.4.7 發送數據包

我們將發送數據包來遍歷這條簡單的SFC，“Path-ID”為63，“starting-index”為255。打開sfc/sfc-py/sfc/目錄，運行如下命令：

Shell

python3.4 sff_client.py --remote-sff-ip 192.168.2.134 --remote-sff-port 4789 --sfp-id 63 --sfp-index 255

1

python3.4?sff_client.py?--remote-sff-ip?192.168.2.134?--remote-sff-port?4789?--sfp-id?63?--sfp-index?255

Agent獲取結果如下：

從上圖可以看到客戶端（Client192.168.2.134:4790）發送包到SFF，SFF然后再將包發送給SF進行處理。SF處理完再轉回給SFF，SFF再尋找下一跳，如果沒找到，判斷為鏈表末尾。

3.4.8 實驗總結

以上我們簡單的演示了一個SFC的使用實驗，只包含了一個SFF和SF。通過在ODL中使用北向UI接口配置SF的信息，配置SFF的信息并關聯相應的SF下發給Agent。在這個過程里，我們還可以刪除，修改這些節點信息，充分體現了基于SDN的服務鏈的靈活性、拓撲獨立性。

用戶需要配置服務鏈的時候，只需要通過控制器的北向接口自由組合節點成有序序列。然后使用的時候，生成一條數據包路徑，并下發即可。同時，用戶也可以配置多條服務鏈。

注意，在不修改原始python腳本的情況下，在南向使用Agent可以創建多SF掛到一個SFF上，但只能創建一個SFF。

4.參考文檔及后續閱讀

網絡服務鏈ppt：

http://wenku.baidu.com/link?url=kiiof5kXtwNnNM9xGDF6VboASaKnKw48Cz6fxW92JMgyTqsbR5c1CsWLzQp4idt6d-zDjiihHt6MsBeURiJt0kSD8DHyTcrnl6eSIan5Xay

本實驗基于SFC 101文檔，具體英文原版參見：

https://drive.google.com/file/d/0BzS_qWNqsnQbUnEzU3BqVzdueTQ/view?usp=sharing

SFC架構:

http://datatracker.ietf.org/doc/draft-ietf-sfc-architecture/

SFC ppt:

https://wiki.opendaylight.org/view/Service_Function_Chaining:Presentations

http://network.51cto.com/art/201312/425928.htm

相關資料：http://packetpushers.net/service-chaining/

Q&A

Q：服務鏈與業務編排的區別是什么？

A：這里的SFC也是一種業務形式，我認為這里服務鏈應該是業務編排的子集。

Q：補充一下問題，如果SF不支持NSH，那么SF設備的回包，SFF設備如何判斷它屬于哪條鏈呢？問這個問題主要是因為我們公司正在做這塊的解決方案，我還沒有搞清楚怎么和傳統的設備進行配合。其實整個SDN領域里面都存在和傳統設備配合這種頭疼的問題。

A：這個要看具體classify的policy了。基于nsh的數據平面識別rsp是看classifier打的path-id，識別與sf無關。但是對于基于nsh的sfc，sf只需要在處理完以后，將nsh的index字段減1,將數據包回傳給sff就可以了。如果你要是新設備和老設備一起，是不是可以考慮l2，用mac來實現？詳細見參考資料service function chain.pdf/p18。

Q：各個SF節點間數據共享？如何實現的，謝謝

A：基于nsh的數據之間共享是通過metadata字段來共享的。

Q:個人比較習慣看數據包，能不能展示一下NSH的數據包呢，現在看NSH的文檔只能看協議字段，感謝。

A：nsh數據包，看rfc。實現可以看sfc/sfc-py下源碼。

Q：同上，還有ODL控制器控制器流量經過SF是用OpenFlow流表嗎，流表是怎么匹配NSH頭？謝謝~

A：openflow13也是sfc的l2另一種實現方式，這個可以不需要配置nah。詳細見參考資料service function chain.pdf/p18。這種我沒有實現過，不好意思。

Q:控制器怎么知道各個sf的具體掛在哪個交換機的哪個端口上，是由誰告訴他的？包括物理的sf（此時掛在物理交換機上）和虛機方式的sf（此時掛在虛擬交換機上，并且可能是sf虛機是動態創建出來的）分別怎么知道的？

A：在odl配置的時候會指定sf的data plane。

Q：sf 設備可以是物理設備吧？

A：sf是一個邏輯上的概念。

Q：如果SF是NAT設備怎么辦？傳統的NAT設備可以正常識別到NSH的頭么？還有，nat之后的包地址端口都有可能發生變化，ODL是怎樣重新識別的？

A：odl只負責控制平面，跟具體功能無關。nsh頭是附加在報文上的，在最后要remove掉的。

Q：問個小白問題，上面提到的支持南向各種協議，特意提出了openflow12，現在of13支持嗎?

A：源代碼里面寫的是op12，不過坑也很多。

Q：我記得SFF最后一條是發回給classifier 應該不會自己去nsh吧？

A：這個我看到過在最后一個sff去掉nsh的。

Q：我記得是傳給classifier或者proxy解,以前看odl的sff發的過包。你有時間看下也幫我確認下。可能我看錯了。

A：之前在做的時候，一般也設計sff只負責轉發。但是rfc中也提到過可以由最后一個sff來去除封裝。

Q：最后一個問題多SFF你做過test么？這個總是SP SI conflict，一直沒做成過。

A:多SFF，可以起多個agent，每個agent負責一個sff。不過代碼可能要調試一下。

網絡 Linux

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。