嘿哈布爾。 我繼續 VxLAN EVPN 技術系列文章, 專為課程的啟動而編寫
在最後一部分中,我們在 Nexus 9000v 上實現了一個建立在網絡結構之上的廣播域。 然而,這並不是數據中心網絡框架內需要解決的全部任務。 今天我們將考慮以下任務 - 網絡之間或 VNI 之間的路由。
讓我提醒您,使用的是 Spine-Leaf 拓撲:
首先,我們將分析路由是如何發生的以及它有什麼特點。
為了便於理解,讓我們簡化邏輯圖並為 Host-20000 添加另一個 VNI 2。 結果是:
在這種情況下,您如何將流量從一台主機轉移到另一台主機?
有兩種選擇:
- 在所有 Leaf 交換機上保留所有 VNI 的信息,那麼所有路由都將發生在網絡中的第一個 Leaf 上;
- 使用專用 - L3 VNI
第一種方式簡單方便。 因為你只需要啟動所有Leaf交換機上的所有VNI即可。 然而,在整個 Leaf 上運行幾百或幾千個 VNI 似乎不再是一件容易的事。 因此,在工作中很少使用它。
我們將分析方法 2,它更有趣且稍微複雜一些,但在設置工廠方面提供了更大的靈活性。
讓我們將“PROD”添加到 VRF 拓撲中。 讓我們在 Leaf-10/11 對上添加接口 vlan 12,在 Leaf-20 上添加接口 VLAN 21。 VLAN 20 與 VNI 20000 關聯
vrf context PROD
rd auto ! Route Distinguisher не принципиален и можем использовать сформированный автоматически
address-family ipv4 unicast
route-target both auto ! указываем Route-target с которым будут импортироваться и экспортироваться префиксы в/из VRF
vlan 20
vn-segment 20000
interface nve 1
member vni 20000
ingress-replication protocol bgp
interface Vlan10
no shutdown
vrf member PROD
ip address 192.168.20.1/24
fabric forwarding mode anycast-gateway
為了使用 L3VNI,您需要創建一個新的 VLAN,並將其與新的 VNI 相關聯。 新的 VNI 在所有對 VLAN 10 和 20 信息感興趣的枝葉上必須相同。
vlan 99
vn-segment 99000
interface nve1
member vni 99000 associate-vrf ! Создаем L3 VNI
vrf context PROD
vni 99000 ! Привязываем L3 VNI к определенному VRF
結果,該圖將如下所示:
它還有一點要完成 - 再添加一個接口 - VRF PROD 中的接口 vlan 99
interface Vlan99
no shutdown
vrf member PROD
ip forward ! На интерфейсе не должно быть IP. Используется только для пересылки пакетов между Leaf
因此,將幀從 Host-1 傳遞到 Host-2 的邏輯如下:
- Host-1 發送的幀到達 VLAN 10 中的 Leaf,與 VNI 10000 關聯;
- Leaf檢查目標地址在哪裡,並通過第二個Leaf交換機上的L3 VNI找到它;
- 一旦找到到目標地址的路由,Leaf 就會將幀打包到具有必要的 L3VNI 99000 的標頭中 - 並將其發送到第二個 Leaf;
- 第二個Leaf交換機接收來自L3VNI 99000的數據。獲取原始幀並將其傳輸到所需的L2VNI 20000,然後傳輸到VLAN 20。
作為這項工作的結果,L3VNI 消除了在所有葉交換機上保留有關網絡上所有 VNI 的信息的需要。
因此,當我們將流量從 Host-1 發送到 Host-2 時,數據包在 VxLAN 內使用新的 VNI - 99000 進行打包:
Leaf-1 究竟如何從另一個 VNI 獲知 MAC 地址還有待觀察。 這也會在 EVPN 路由類型 2 (MAC / IP) 的幫助下發生。
下面展示了傳播關於位於另一個 VNI 中的前綴的路由的過程:
也就是說,從 VNI 20000 收到的地址有兩個 RT。
提醒一下,從 Update 收到的路由落入了 VRF 設置中指定 Route-target 的 BGP 表中(這個過程稍微複雜一些,但我們不會在本文中展開)。
RT 本身由公式構成:AS:VNI(如果使用自動模式)。
自動和手動模式下的 RT 編隊示例:
vrf context PROD
address-family ipv4 unicast
route-target import auto - автоматический режим работы
route-target export 65001:20000 - ручной режим формирования RT
因此,您可以在上面看到來自另一個 VNI 的前綴有兩個 RT 值。
其中一個 65001:99000 是一個額外的 L3 VNI。 由於此 VNI 在所有 Leaf 上都是相同的並且符合我們在 VRF 設置中的導入規則,因此前綴進入 BGP 表,從輸出中可以看出:
sh bgp l2vpn evpn
<.....>
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 10.255.1.11:32777 (L2VNI 10000)
*>l[2]:[0]:[0]:[48]:[5001.0007.0007]:[0]:[0.0.0.0]/216
10.255.1.10 100 32768 i
*>l[2]:[0]:[0]:[48]:[5001.0007.0007]:[32]:[192.168.10.10]/272
10.255.1.10 100 32768 i
*>l[3]:[0]:[32]:[10.255.1.10]/88
10.255.1.10 100 32768 i
Route Distinguisher: 10.255.1.21:32787
* i[2]:[0]:[0]:[48]:[5001.0008.0007]:[32]:[192.168.20.20]/272 ! Префикс полученный из VNI 20000
10.255.1.20 100 0 i
*>i 10.255.1.20 100 0 i
如果我們更仔細地查看收到的更新,我們可以看到這個前綴有兩個 RT:
Leaf11# sh bgp l2vpn evpn 5001.0008.0007
BGP routing table information for VRF default, address family L2VPN EVPN
Route Distinguisher: 10.255.1.21:32787
BGP routing table entry for [2]:[0]:[0]:[48]:[5001.0008.0007]:[32]:[192.168.20.2
0]/272, version 5164
Paths: (2 available, best #2)
Flags: (0x000202) (high32 00000000) on xmit-list, is not in l2rib/evpn, is not i
n HW
Path type: internal, path is valid, not best reason: Neighbor Address, no labeled nexthop
AS-Path: NONE, path sourced internal to AS
10.255.1.20 (metric 81) from 10.255.1.102 (10.255.1.102)
Origin IGP, MED not set, localpref 100, weight 0
Received label 20000 99000 ! Два label для работы VxLAN
Extcommunity: RT:65001:20000 RT:65001:99000 SOO:10.255.1.20:0 ENCAP:8 ! Два значения Route-target, на основе, которых добавили данный префикс
Router MAC:5001.0005.0007
Originator: 10.255.1.21 Cluster list: 10.255.1.102
<......>
在 Leaf-1 的路由表中,您還可以看到前綴 192.168.20.20/32:
Leaf11# sh ip route vrf PROD
192.168.10.0/24, ubest/mbest: 1/0, attached
*via 192.168.10.1, Vlan10, [0/0], 01:29:28, direct
192.168.10.1/32, ubest/mbest: 1/0, attached
*via 192.168.10.1, Vlan10, [0/0], 01:29:28, local
192.168.10.10/32, ubest/mbest: 1/0, attached
*via 192.168.10.10, Vlan10, [190/0], 01:27:22, hmm
192.168.20.20/32, ubest/mbest: 1/0 ! Адрес Host-2
*via 10.255.1.20%default, [200/0], 01:20:20, bgp-65001, internal, tag 65001 ! Доступный через Leaf-2
(evpn) segid: 99000 tunnelid: 0xaff0114 encap: VXLAN ! Через VNI 99000
注意到路由表中缺少主前綴 192.168.20.0/24 了嗎?
沒錯,他不在。 也就是說,遠程 Leafs 僅接收有關您網絡上主機的信息。 這是正確的行為。 以上,在所有的更新中,可以看到MAC/IP的內容都自帶信息。 沒有前綴可言。
這就是主機移動管理器 (HMM) 協議,它填充 ARP 表,從中進一步填充 BGP 表(我們將在本文的框架內省略此過程)。 根據從 HMM 收到的信息,形成路由類型 2 EVPN(通過 MAC / IP 傳輸)。
但是,如果需要傳遞有關前綴的信息怎麼辦?
對於此類信息,有 EVPN route-type 5 - 它允許您通過 address-family l2vpn evpn 發送前綴(撰寫本文時此類路由僅在草案版本中
傳遞前綴,需要在VRF的BGP過程中添加前綴,會被通告:
router bgp 65001
vrf PROD
address-family ipv4 unicast
redistribute direct route-map VNI20000 ! В данном случае анонсируем префиксы подключение непосредственно к Leaf в VNI 20000
route-map VNI20000 permit 10
match ip address prefix-list VNI20000_OUT ! Указываем какой использовать prefix-list
ip prefix-list VNI20000_OUT seq 5 permit 192.168.20.0/24 ! Указываем какие сети будут попадать в EVPN route-type 5
結果,更新將是:
讓我們看一下 BGP 表。 除了 EVPN 路由類型 2,3 之外,還出現了包含網絡號信息的類型 5 路由:
<......>
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 10.255.1.11:3
* i[5]:[0]:[0]:[24]:[192.168.10.0]/224
10.255.1.10 0 100 0 ?
*>i 10.255.1.10 0 100 0 ?
Route Distinguisher: 10.255.1.11:32777
* i[2]:[0]:[0]:[48]:[5001.0007.0007]:[0]:[0.0.0.0]/216
10.255.1.10 100 0 i
*>i 10.255.1.10 100 0 i
* i[2]:[0]:[0]:[48]:[5001.0007.0007]:[32]:[192.168.10.10]/272
10.255.1.10 100 0 i
*>i 10.255.1.10 100 0 i
* i[3]:[0]:[32]:[10.255.1.10]/88
10.255.1.10 100 0 i
*>i 10.255.1.10 100 0 i
Route Distinguisher: 10.255.1.12:3
*>i[5]:[0]:[0]:[24]:[192.168.10.0]/224 ! EVPN route-type 5 с номером префикса
10.255.1.10 0 100 0 ?
* i
<.......>
前綴也出現在路由表中:
Leaf21# sh ip ro vrf PROD
192.168.10.0/24, ubest/mbest: 1/0
*via 10.255.1.10%default, [200/0], 00:14:32, bgp-65001, internal, tag 65001 ! Удаленный префикс, доступный через Leaf1/2(адрес Next-hop = virtual IP между парой VPC)
(evpn) segid: 99000 tunnelid: 0xaff010a encap: VXLAN ! Префикс доступен через L3VNI 99000
192.168.10.10/32, ubest/mbest: 1/0
*via 10.255.1.10%default, [200/0], 02:33:40, bgp-65001, internal, tag 65001
(evpn) segid: 99000 tunnelid: 0xaff010a encap: VXLAN
192.168.20.0/24, ubest/mbest: 1/0, attached
*via 192.168.20.1, Vlan20, [0/0], 02:39:44, direct
192.168.20.1/32, ubest/mbest: 1/0, attached
*via 192.168.20.1, Vlan20, [0/0], 02:39:44, local
192.168.20.20/32, ubest/mbest: 1/0, attached
*via 192.168.20.20, Vlan20, [190/0], 02:35:46, hmm
VxLAN EVPN 系列文章的第二部分到此結束。 在下一部分中,我們將考慮在 VRF 之間進行路由的各種選項。
來源: www.habr.com