如何在SDN GW上彙總虛擬機器路由
技術標籤：Tungsten Fabric中文社群SDN開源tungstenfabric
在Tungsten Fabric中，每個虛擬網路都不過是vRouter上的一個VRF。這使得vRouter在經典的L3v*n場景中看起來像是一個PE節點。
每個虛擬網路都被分配了一個CIDR，例如10.10.10.0/24。vRouter有一個/32的路由指向連線到虛擬網路的每個虛擬機器。
通過在虛擬網路上配置一個route-target，這些路由可以被通告到SDN GW。
這是一個PE-PE互動。那麼這意味著什麼？
SDN GW將接收這些路由，並將其儲存在bgp.l3v*n.0表中。如果SDN GW有另一個MP-BGP會話，例如朝向骨幹（backbone）路由反射器，那麼這些路由將被髮送到RR，並有可能到達網路中的任何其它遠端PE。
由於通常Tungsten Fabric和SDN GW位於不同的自治系統中，我們處理的是一個經典的Inter-AS option B方案：來自TF的路由會按原樣傳送到骨幹網。
這樣很好，為了將目的地為虛擬機器的流量傳送到虛擬機器執行的確切計算節點，需要擁有/32的路由。想象一下，只有一個/24的網路指向一個隨機的計算節點的情況。端到端流量無論如何都會工作，但平均而言，由於虛擬機器可能不在通用/24路由指向的計算節點上執行，需要額外的流量跳數。這將產生不必要的東西向流量。在SDN GW上擁有/32路由可以避免這種情況。
如果我們進一步將這些路由匯出到遠端PE，那麼遠端PE也知道正確的目的地來發送資料包。這一切都很好對嗎？是，也不是。
想象一下，一個大規模的TF叢集，有許多虛擬機器和許多虛擬網路“暴露”在SDN GW上。這將意味著大量的/32在骨幹網上旅行。這是可擴充套件的嗎？也許不能！
另外，所有屬於叢集上配置的虛擬網路的虛擬機器都位於同一個SDN GW的背後，所以擁有所有這些/32路由可能會被視為冗餘資訊：重要的是到達SDN GW，而SDN GW是唯一需要知道/32細節的。
其實，這並不完全正確。假設我們的VN有CIDR 10.10.10.0/24。遠端PE將向SDN GW傳送屬於10.10.10.0/24的任何IP的流量，即使不存在具有該特定IP的虛擬機器……所以，是的，有一些缺點，但還是可以接受的。
那麼應該如何實現呢？需要SDN GW知道/32，但只通告相應的網路方面（例如/24）的路由。
這可以通過在SDN GW上配置一個VRF來實現。
該VRF將從Tungsten Fabric匯入路由，匹配正確的路由目標。
set routing-instances s1 instance-type vrf
set routing-instances s1 route-distinguisher 2.2.2.100:1
set routing-instances s1 vrf-import s1-imp
set routing-instances s1 vrf-export s1-exp
set policy-options policy-statement s1-imp term contrail from protocol bgp
set policy-options policy-statement s1-imp term contrail from community s1-vn
set policy-options policy-statement s1-imp term contrail then accept
set policy-options community s1-vn members target:64520:100
這將導致/32路由被匯入到VRF路由表中。
[email protected]# run show route table s1.inet.0 10.10.10/24
s1.inet.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.10.10.10/32 *[BGP/170] 00:47:58, localpref 100, from 1.1.1.100
AS path: 64520 64500 I, validation-state: unverified
> via gr-0/0/10.0, Push 299856
10.10.10.11/32 *[BGP/170] 00:47:58, localpref 100, from 1.1.1.100
AS path: 64520 64500 I, validation-state: unverified
> via gr-0/0/10.0, Push 299856
10.10.10.12/32 *[BGP/170] 00:47:58, localpref 100, from 1.1.1.100
AS path: 64520 64500 I, validation-state: unverified
> via gr-0/0/10.0, Push 299856
下一跳是MPLSoGRE隧道，朝向Tungsten Fabric方向。
現在，我們在VRF上配置一個聚合路由：
set routing-instances s1 routing-options aggregate route 10.10.10.0/24 discard
最後，需要將該聚合路由朝向路由反射器釋出通告。這是通過vrf-export策略完成的：
set policy-options policy-statement s1-exp term agg from protocol aggregate
set policy-options policy-statement s1-exp term agg then community add s1-vn
set policy-options policy-statement s1-exp term agg then accept
set policy-options policy-statement s1-exp then reject
因此，我們現在向骨幹網通告的是聚合路由：
[email protected]# run show route advertising-protocol bgp 3.3.3.3 10.10.10.0/24 exact
s1.inet.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
* 10.10.10.0/24 Self 100 64520 64500 I
這樣就夠了嗎？還不夠！
我們來檢視一下所有的通告路由：
[email protected]# run show route advertising-protocol bgp 3.3.3.3 10.10.10/24
s1.inet.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
* 10.10.10.0/24 Self 100 64520 64500 I
bgp.l3v*n.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
1.1.1.100:1:10.10.10.10/32
* Self 100 64520 64500 I
1.1.1.100:1:10.10.10.11/32
* Self 100 64520 64500 I
1.1.1.100:1:10.10.10.12/32
* Self 100 64520 64500 I
2.2.2.100:1:10.10.10.0/24
* Self 100 64520 64500 I
我們也在通告/32路由。為什麼會這樣？細節決定成敗。請記住，這是一個Inter-AS option B的方案，我們收到的/32路由是來自另一個PE，而不是來自CE，它們是作為MP-BGP路由接收的，而不是標準的BGP。
Vrf-export策略只適用於從CE協議（bgp、bfd、isis、static等）學到的路由。因此，vrf-export策略對/32路由沒有任何影響！我們不能在vrf-export策略中停止它們，不能在VRF級別上阻止它們。
至少有兩種方法來解決這個問題。
第一個辦法是在SDN GW和Tungsten Fabric之間的BGP會話上配置一個匯入策略。這個匯入策略只是根據route target匹配/32路由，並將no-advertise community新增其中：
[email protected]# show policy-options policy-statement imp-contrail | display set
set policy-options policy-statement imp-contrail term a1-32 from community s1-vn
set policy-options policy-statement imp-contrail term a1-32 from route-filter 0.0.0.0/0 prefix-length-range /32-/32
set policy-options policy-statement imp-contrail term a1-32 then community add no-advertise
set policy-options policy-statement imp-contrail term a1-32 then accept
[edit]
[email protected]# show protocols bgp group contrail import | display set
set protocols bgp group contrail import imp-contrail
現在的結果是預期的結果：
[email protected]# run show route advertising-protocol bgp 3.3.3.3 10.10.10/24
s1.inet.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
* 10.10.10.0/24 Self 100 64520 64500 I
bgp.l3v*n.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
2.2.2.100:1:10.10.10.0/24
* Self 100 64520 64500 I
另一種解決辦法是：
[email protected]# show policy-options policy-statement rr | display set
set policy-options policy-statement rr term s1-32 from community s1-vn
set policy-options policy-statement rr term s1-32 from route-filter 0.0.0.0/0 prefix-length-range /32-/32
set policy-options policy-statement rr term s1-32 then reject
[edit]
[email protected]# show protocols bgp group rr export | display set
set protocols bgp group rr export rr
這次我們是在SDN GW和RR之間的BGP會話上配置一個匯出策略。我們只是根據route target拒絕/32路由。
兩種解決方案得到的結果是一樣的，選哪個由你決定。
作者：Umberto Manferdini 譯者：TF編譯組
原文連結：https://iosonounrouter.wordpress.com/2020/05/15/summarizingvm-routes-at-the-sdn-gw/