作者:Umberto Manferdini 譯者:TF編譯組
如果你看過任何有關Tungsten Fabric
(附注:原文為Contrail,在本系列文章中,Tungsten Fabric的功能與Contrail一致,文中出現Contrail之處均以Tungsten Fabric替換)
的演示,可能都會碰到“服務鏈(service chain)”這個熱詞。現在,是時候對這個功能好好動手研究一番了。
那么什么是服務鏈?
簡而言之,就是使流量在兩個虛擬網絡之間流動的過程中,經過一項或多項“服務”。
讓我們舉個例子吧!這里有2個虛擬網絡:pippo和pluto。我們希望這兩個網絡互相通信。在Tungsten Fabric中,只需在兩個虛擬網絡上配置相同的RT(route target)即可實現(虛擬網絡是vrfs,還記得嗎?)。
(附注:Route target 即RT,在Tungsten Fabric用來作為路由的標記,也是MPLS中常用的路由更新標記。)
還有一個選擇,我們可以構建一個網絡策略,同時適用于兩個網絡,就是“允許這些虛擬網絡之間的任何流量”。而在幕后,Tungsten Fabric仍然依賴于路由route target(隱藏和自動生成目標)。
這看起來是正確的,但從根本上是錯誤的!使用網絡策略,使我們可以指定在虛擬網絡之間移動時,流量必須通過的一個或多個服務實例。這是第一種方法無法做到的。而這就是服務鏈!
(附注:此處作者希望表達的是,盡管結果相同,但是實現的內容不一樣,第一種same RT實現的內容,是不同的網絡之間的路由屬性相同,意味著可以相互泄露和打通,而第二個則不是。)
如前所述,服務鏈可以包括一項或多項服務。這意味著從pippo到pluto的流量可以穿越防火墻,也同時穿越(一個接一個)防火墻和DPI。
乍一看,有人會說:“好,很酷!但我也可以通過路由做同樣的事情……”。沒錯,但這里真正重要的是——易于部署。Tungsten Fabric負責所有事務,并自動配置所有需要的路由。你只需要告訴Tungsten Fabric自己的意圖即可:“允許這些網絡進行通話,并使流量通過這些服務實例”。我們正處于基于意圖的時代,不是嗎?
當然,這還不是故事的全部。Tungsten Fabric在表中引入了其它功能,例如運行狀況檢查(health checks),以提供高可用性和擴展能力。此外,網絡策略本身也可以用于基于L4的規則拒絕/允許流量。
首先,我們需要兩個虛擬網絡。無需對它們配置任何route target。
接下來,我們在它們之間配置一個網絡策略,允許所有流量通過:
此時,兩個網絡可以互相通信!
是時候轉向服務鏈了。
首先,我們創建一個虛擬機,該虛擬機將成為我們服務實例的一部分。這是兩個虛擬網絡(VNF)之間的流量將遍歷的虛擬機!
例如,該虛擬機可以是防火墻。
該VM必須在Openstack中創建;
就像通過Nova創建的任何其它VM一樣。

成都創新互聯專注于網站建設|網頁維護|優化|托管以及網絡推廣,積累了大量的網站設計與制作經驗,為許多企業提供了網站定制設計服務,案例作品覆蓋被動防護網等行業。能根據企業所處的行業與銷售的產品,結合品牌形象的塑造,量身策劃品質網站。
接下來,回到Tungsten Fabric!我們創建一個名為服務模板(service template)的對象:
顧名思義,服務模板是對服務的描述。
下面五個參數是必須要配置的:
版本(version),必須為v2
虛擬化類型(virtualization type),除非你打算使用物理網絡功能(PNF),否則必須為虛擬機
服務類型(service type),可以是防火墻或分析器,我們使用第一個。
服務模式(service mode),可以是transparent(bump in the wire),in-network(最常見),in-network-nat(使用nat時的特殊用例)
接口列表,通常我們定義兩個接口:左和右
由于這是模板,因此可以多次用于不同VM的配置。例如,Juniper防火墻服務實例和第三方供應商防火墻服務實例都可以用服務模板進行部署。重要的是,在這兩種情況下,在OpenStack中創建的虛擬機都有兩個接口,可以將它們映射到服務模板中定義的接口(左和右)上。
接下來,我們創建服務實例。在服務實例對象中可以配置很多東西。這里,我們將專注于使鏈條正常工作的最小配置。
服務實例引用服務模板。
一旦指定了此引用,就可以將服務模板(左和右)中定義的
接口映射到實際的虛擬網絡。
例如,在這種情況下,我們向左映射到fourcade,向右映射到wierer。
現在,我們引入一個關鍵對象:端口元組(port tuple)。它是引用虛擬機接口的元組。如前所述,充當防火墻的實際VM不是由Tungsten Fabric定義的,而是像OpenStack中的任何其它VM一樣所創建的。但是,我們需要將該虛擬機“鏈接”到我們的服務實例。這是通過端口元組實現的。“鏈接”在虛擬機接口(vmi)級別執行。
在這種情況下,端口元組將包含兩個元素,一個用于服務模板中定義的每個接口(左和右)。此外,我們將服務模板接口映射到虛擬網絡(向左映射到fourcade,向右映射到wierer)。
現在,讓我們看一下虛擬機。它有3個端口:eth0連接到我們不關心的虛擬網絡,eth2連接到fourcade,eth3連接到wierer。下一步是什么?很明顯!端口元組將包括eth2和eth3。這就是我們告訴Tungsten Fabric在遍歷服務實例時流量應該流向何處的方式。
沒有什么能阻止我們讓單個服務實例擁有多個端口元組……
ECMP怎么辦?
active/backup如何處理?
…有主意嗎?
我們稍后會處理。
現在,讓我們先聚焦這個用例。我們現在到哪兒了?來自fourcade網絡中的VM的流量,要發往更wierer網絡中的一個IP地址。流量需要從fourcade到wierer。這個通信在網絡策略中是允許的。由于網絡策略告訴從fourcade到wierer的流量必須經過服務實例,因此數據包被發送到VM eth2端口,并將從eth3端口進入wierer網絡。

由于Tungsten Fabric是基于流的,因此可以保證對稱性和粘性!
在下篇文章中,我們將看到一個真實的例子。這將使我們看到創建一條服務鏈有多么容易,以及Tungsten Fabric如何掩蓋了所有的復雜性!
原文鏈接:
https://iosonounrouter.wordpress.com/2020/06/09/whats-a-service-chain/
Tungsten Fabric 架構解析
系
列文章
——
第一篇:
TF主要特點和用例
第二篇:
TF怎么運作
第三篇:詳解vRouter體系結構
第四篇:
TF的服務鏈
第五篇:
vRouter的部署選項
第六篇:
TF如何收集、分析、部署?
第七篇:
TF如何編排
第八篇:
TF支持API一覽
第九篇:
TF如何連接到物理網絡
第十篇:
TF基于應用程序的安全策略
網站標題:細說TF服務鏈丨一文講透什么是服務鏈(多圖)
URL地址:
http://www.xueling.net.cn/article/jpeepj.html