解密BGPaaS代理是如何工作的

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

BGPaaS是允許虛擬機器與Tungsten Fabric（ 注：原文為Contrail，本文以功能一致的Tungsten Fabric替換）進行BGP對話的一個功能。

請記住，Tungsten Fabric虛擬網路是存在於計算節點上的VRF。這些計算節點就像我們熟知的PE。同樣，VM也可以被視為CE。在這種情況下，BGPaaS帶來的BGP會話，就像我們在經典VPN中所具有的PE-CE協議一樣。

使用BGPaaS的VM最多可以有2個鄰居：VN閘道器（通常為.1）或VN服務地址（通常為.2）。

假設我有一個屬於192.168.100.0/24的VM，其vmi（虛擬埠）地址是192.168.100.3。在這種情況下，如果在該埠上配置了BGPaaS，則VM可以建立2個BGP會話：一個指向192.168.100.1，另一個指向192.168.100.2。

即使BGP鄰居地址是vRouter上的（“分散式”）IP，也不會在vRouter級別實現BGP邏輯。

Tungsten Fabric與Junos裝置沒有太大不同。例如，在MX中，控制平面和轉發平面完全分離：路由引擎實現路由協議，而PFE實現轉發功能。

同樣，在Tungsten Fabric中，vRouter代表轉發平面。控制平面位於Tungsten Fabric控制節點內。

因此，BGPaaS會話必須以某種方式到達控制節點。這可以透過讓vRouter將任何BGPaaS會話代理到控制節點來實現。 端到端的BGP會話是在VM和控制節點之間執行的。

在POC環境中，我們可能只有一個控制節點，因此所有BGPaaS會話都將被代理到該節點。

另一方面，在實際設定中，為了實現HA，我們將有3個控制節點。建立BGPaaS時，vRouter將使用雜湊函式來確定會話必須代理到哪個控制節點。

這也意味著即使vRouter沒有任何問題，控制節點故障也將導致BGP會話中斷。

這也是為什麼要建議，同時建立指向VN閘道器（gateway）和VN服務（service）地址的會話。這樣，一個會話（到.1）將被代理到一個控制節點（例如control1），而另一個會話（到.2）將被代理到另一個控制節點（例如control2），從而使服務能夠抵禦控制節點的故障。

實際上的過程，比這要複雜一些。最佳解決方案需要一個稱為控制節點區域（control node zone）的額外物件，但這不在本討論的範圍之內。

由於vRouter充當了代理角色，這意味著它將把端到端BGP會話分為兩個會話：

– 一個在VM和vRouter之間

– 一個在vRouter和控制節點之間

為了端到端監視並解決出現的任何問題，將這兩個會話連結起來就變得很重要。

透過introspect可以很容易地實現這一點。

必須針對正確的計算節點執行“BgpAsAServiceSandeshReq”請求。這提供了在該計算節點上配置的BGPaaS物件的列表。

在返回的資訊中，我們可以輕鬆地使用“Vm Nat Source Port”；在這種情況下為50027。

此外，虛擬機器埠地址為192.168.135.11。

這足以將vm-vrouter會話對映到vrouter-control_node會話。

一旦知道了這些資訊，就可以輕鬆地驗證BGP資料包是否端到端流動。

我們可以透過在vRouter容器中使用vRouter cli實用程式“vifdump”，來檢查在vrouter-vm會話上流動的資料包：

1.(vrouter-agent)[root@cpt3-dpdk /]$ vifdump -i vif0/6 port 179 and host 192.168.135.2  
2.vif0/6      PMD: tap5e37b408-81 NH: 80  
3.tcpdump: verbose output suppressed, use -v or -vv for full protocol decode  
4.listening on mon6, link-type EN10MB (Ethernet), capture size 262144 bytes  
5.09:47:15.762169 IP 192.168.135.2.bgp > 192.168.135.11.11133: Flags [P.], seq 2026783022:2026783041, ack 1247350197, win 210, options [nop,nop,TS val 918606763 ecr 607079479], length 19: BGP  
6.09:47:15.784239 IP 192.168.135.2.bgp > 192.168.135.11.11133: Flags [.], ack 20, win 210, options [nop,nop,TS val 918606785 ecr 607082480], length 0  
7.09:47:15.784246 IP 192.168.135.11.11133 > 192.168.135.2.bgp: Flags [P.], seq 1:20, ack 19, win 8326, options [nop,nop,TS val 607082480 ecr 918606763], length 19: BGP

接下來，我們執行相同的操作，但是是在計算節點物理介面vif0/0上執行。

在這裡，我們可以捕獲流量，並透過之前確定的“Vm Nat Source Port”對其進行過濾。

如果我們透過Wireshark分析捕獲的流量，那麼可以發現很多東西：

端點正在交換KEEPALIVE訊息，表明會話狀態良好。

這裡關鍵的細節是IP端點：

– 163.162.83.233是計算節點的vhost0地址；

– 163.162.83.204是控制節點的地址。BGP被代理到了這個控制節點！

從Tungsten Fabric的角度來看，這使我們可以再次使用introspect來驗證端到端BGPaaS會話工作正常。

這次，我們對從wireshark抓包中識別出的控制節點執行自省請求。我們選擇“bgp_peer”模組並請求“ShowBgpNeighborSummaryReq”。

幸運的是，會話狀態已建立。

一切正常！這下沒什麼神秘的東西了~