作者： Umberto Manferdini 譯者：TF編譯組

上一篇文章中，我配置了最簡單的服務鏈。現在，是時候瞭解路由實際上是如何實現的了。

我們的拓撲結構是這樣一條簡單的服務鏈：

讓我們看一下路由表。

從“分離的” VN 開始：沒有策略，沒有服務鏈。

在本例項中，路由表僅包含該虛擬網路的地址。

接下來，應用策略，但不新增任何服務例項：

現在，左側網路還包括來自右側網路的路由：

在這背後是什麼？Route Target ！

為了解更多資訊，我將在控制節點上使用Introspect 並瀏覽路由表（模組為 bgp_peer ，然後使用 ShowRoute family 請求）。

建立虛擬網路後，會自動為其分配R oute Target 。即使沒有配置R oute Target ，仍然有一個VN 。這種 R oute Target 的值高於800 萬，因此很容易識別。

指定左側VN 為 target:64520:8000059

指定右側VN 為 target:64520:8000060

一旦我們應用網路策略，允許這兩個VN 之間進行通訊， Tungsten Fabric 就會自動調整匯入R oute Target 策略。

左側VN 現在會匯入“ 8000060 ”，這意味著它將匯入右側 VN 的路由：

右側 VN 的更新方式類似，不過它將匯入 RT “ 8000059 ”，即左側 VN RT ：

到最後，網路策略看起來似乎只是利用Route Target執行洩漏。

那麼，為什麼在建立虛擬網路時，我們要花時間在網路策略上，而不僅僅是配置適當的Route Target ，然後匯入 Route Target 策略就好了？

我們知道，網路策略允許建立L4 規則。透過網路策略，可以決定允許 TCP 通訊，以及阻止 UDP 通訊。這就是重點，我們可以建立服務鏈。

開始吧！最後一步，服務鏈：

檢視左側VN匯入 Route Target政策：

這很有趣……我們知道還有兩個虛擬網路：

–左側，原始 VN 出來

–左側服務，一個輔助 VN “對映”到了服務例項

左側VN 匯出 RT “ 8000059 ”，而左側服務則匯出 RT “ 8000061 ”。這兩個 VN 相互匯入 RT 。這意味著它們之間有洩漏！

來看一下右側的情況：

我們看到了類似的東西：右側和右側服務相互匯入 RT 。

沒有服務例項，左側VN 將匯入右側 VN ，反之亦然。現在，此機制僅限於左側和左側服務（或右側和右側服務）。那麼，從右到左的路由如何到達？

看起來，RT 洩漏並不簡單。

在這種情況下，我們必須談論路由重新分配。這意味著 Tungsten Fabric 將重新分配路由。仔細考慮一下，這是有道理的。

假如沒有服務例項，可以按原樣從右向左複製路由，反之亦然。

另一方面，在服務例項起作用的情況下，當一條路由從右側“洩露”到左側時，下一跳必須更新，因為它必須指向服務例項 vmi 。

那麼這是如何工作的呢？讓我們看看右側VN 路由： 192.168.20.3/32 。

跟以往一樣，該路由有兩個副本：XMPP 和 BGP 。

檢視這些路由更多的詳細資訊：

這裡要注意的是，該路由具有一個輔助表，是的，它是右側服務！這裡右側到右側服務的洩露，是由於我們之前看到的匯入Route Target 策略。可以看到， BGP 路由（第二個）匯出 RT “ 8000060 ”，而該 RT 是由右側服務匯入的。

現在，我們轉到左側服務路由表：

仍然有兩條路由，但XMPP 的那一條已被服務鏈的那一條所取代。

此路由將左側VN 作為輔助表：

下圖表示了路由的傳播：

當流量從左向右移動時，會發生以下情況：

回程流量利用了現有流量。

是不是有點複雜？可能是的……但是考慮一下，我們為建立這條鏈實際配置了什麼，很明顯 Tungsten Fabric 是如何隱藏了所有的複雜性！

下一次，我將開始研究高階服務例項的設定。

---

細說TF服務鏈——

Tungsten Fabric 架構解析系列文章 ——

細說TF服務鏈丨服務鏈後臺的路由實現

作者： Umberto Manferdini 譯者：TF編譯組

一文講透什麼是服務鏈（多圖）

手把手教你配置服務鏈

相關文章