EVPN 有魔力嗎?阿瑟 C 克拉克說 ,任何足夠先進的技術都無法與魔法區分開來。在這個前提下,從傳統的第 2 層環境遷移到由 EVPN 驅動的 VXLAN ,有很多相同的 hocus-pocus 感覺。
為了幫助解開這個魔法的神秘面紗,我的目標是幫助 EVPN 的新用戶理解 EVPN 是如何工作的以及控制平面是如何收斂的。在這篇文章中,我將重點介紹基本的第 2 層( L2 )構建塊,然后逐步擴展到第 3 層( L3 )連接和控制平面。
我使用參考拓撲作為電纜計劃和基礎來建立你對交通流的理解。該基礎設施嘗試使用分布式網關揭開對稱模式 EVPN 環境的神秘面紗。 所有配置都使用生產就緒自動化進行標準化,并在公開可用的 cumulus_ansible_modules GitLab repo 中鏈接。
接下來,在云中構建自己的 積云,并部署以下劇本:
~$ git clone https://gitlab.com/cumulus-consulting/goldenturtle/cumulus_ansible_modules.git Cloning into 'cumulus_ansible_modules'... remote: Enumerating objects: 822, done. remote: Counting objects: 100% (822/822), done. remote: Compressing objects: 100% (374/374), done. remote: Total 4777 (delta 416), reused 714 (delta 340), pack-reused 3955 Receiving objects: 100% (4777/4777), 4.64 MiB | 22.64 MiB/s, done. Resolving deltas: 100% (2121/2121), done. ~$ ~$ cd cumulus_ansible_modules/ ~/cumulus_ansible_modules$ ansible-playbook -i inventories/evpn_symmetric/host playbooks/deploy.yml
EVPN 消息類型
與任何好的協議一樣, EVPN 有一個與對等方交換信息的強大過程: 消息類型。如果您已經知道 OSPF 和 LSA 消息,那么您可以認為 EVPN 消息類型類似。每種 EVPN 消息類型都可以攜帶關于 EVPN 業務流的不同類型的信息。
大約有五種不同的消息類型。在本文中,我將重點介紹目前最流行的兩種類型: type2mac 和 type2mac / IP 信息。
深入研究 EVPN 消息類型:類型 2
最容易理解的 EVPN 消息是類型 2 。如前所述,類型 2 路由包含 MAC 和 MAC / IP 映射。首先,檢查工作中的 2 型入口。為此,您可以驗證從 leaf01 到 server01 的基本連接。
首先,查看網橋表以確保交換機的 MAC 地址正確映射到服務器的正確端口。
獲取 Server01 MAC 地址:
cumulus@server01:~$ ip address show ... 5: uplink:mtu 9000 qdisc noqueue state UP group default qlen 1000 link/ether 44:38:39:00:00:32 brd ff:ff:ff:ff:ff:ff inet 10.1.10.101/24 scope global uplink valid_lft forever preferred_lft forever inet6 fe80::4638:39ff:fe00:32/64 scope link valid_lft forever preferred_lft forever
查看 Leaf01 的網橋表,確保 MAC 地址映射到您期望的端口。與 LLDP 交叉引用:
cumulus@server01:~$ ip address show ... 5: uplink:mtu 9000 qdisc noqueue state UP group default qlen 1000 link/ether 44:38:39:00:00:32 brd ff:ff:ff:ff:ff:ff inet 10.1.10.101/24 scope global uplink valid_lft forever preferred_lft forever inet6 fe80::4638:39ff:fe00:32/64 scope link valid_lft forever preferred_lft forever Look at Leaf01’s bridge table to make sure the MAC address is mapped to the port that you expect. Cross reference it with LLDP: cumulus@leaf01:mgmt:~$ net show bridge macs VLAN Master Interface MAC TunnelDest State Flags LastSeen -------- ------ --------- ----------------- ---------- --------- ------------------ -------- ... 10 bridge bond1 46:38:39:00:00:32 <1 sec ? ? cumulus@leaf01:mgmt:~$ net show lldp ? LocalPort? Speed? Mode??? RemoteHost?????? ???? RemotePort ---------? -----? ----------? -------------------? ----------------- eth0?? ??? 1G ? Mgmt??? ?? oob-mgmt-switch? ???? swp10 swp1 1G BondMember server01.simulation 44:38:39:00:00:32 swp2 1G BondMember server02 44:38:39:00:00:34 swp3 1G BondMember server03 44:38:39:00:00:36 swp49 1G BondMember leaf02 swp49 swp50 1G BondMember leaf02 swp50 swp51 1G Default spine01 swp1 swp52 1G Default spine02 swp1 swp53 1G Default spine03 swp1 swp54 1G Default spine04 swp1 Checking the ARP table, you can validate that the MAC and IP addresses are mapped correctly. cumulus@leaf01:mgmt:~$ net show neighbor Neighbor MAC Interface AF STATE ------------------------- ----------------- ------------- ---- --------- ... 10.1.10.101 44:38:39:00:00:32 vlan10 IPv4 REACHABLE ...
現在您已經檢查了基礎知識,開始研究如何將其引入 EVPN 。驗證配置的本地 VNI :
cumulus@leaf01:mgmt:~$ net show evpn vni VNI Type VxLAN IF # MACs # ARPs # Remote VTEPs Tenant VRF 20 L2 vni20 9 2 1 RED 30 L2 vni30 10 2 1 BLUE 10 L2 vni10 11 4 1 RED 4001 L3 vniRED 2 2 n/a RED 4002 L3 vniBLUE 1 1 n/a BLUE
因為您驗證了 server01 是按照網橋 mac 表映射到 vlan10 的,所以現在您可以檢查 IP 鄰居條目是否被拉入 EVPN 緩存。此緩存描述了與環境中其他 EVPN 揚聲器交換的信息。
cumulus@leaf01:mgmt:~$ net show evpn arp-cache vni 10
Number of ARPs (local and remote) known for this VNI: 4
Flags: I=local-inactive, P=peer-active, X=peer-proxy
Neighbor Type Flags State MAC Remote ES/VTEP Seq #'s
...
10.1.10.101 local active 44:38:39:00:00:32 0/0
10.1.10.104 remote active 44:38:39:00:00:3e 10.0.1.34
這是你目前掌握的情況。 L2 連接工作正常,因為 L2 網橋表和 L3 鄰居表在 leaf01 上本地填充。接下來,您驗證了 mac 和 IP 信息是否通過 EVPN ARP 緩存被正確地拉入 EVPN 。
使用這些信息,您可以檢查 RD 和 RT 映射,以便了解有關完整 VNI 廣告的更多信息。
RD 是一種路由識別器。它用于消除不同 vni 中 EVPN 路由的歧義,因為它們可能具有相同的 MAC 或 IP 地址。
RTs 是路由目標。它們用于描述路由的 VPN 成員身份,特別是哪些 VRF 正在導出和導入基礎結構中的不同路由。
cumulus@leaf01:mgmt:~$ net show bgp l2vpn evpn vni Advertise Gateway Macip: Disabled Advertise SVI Macip: Disabled Advertise All VNI flag: Enabled BUM flooding: Head-end replication Number of L2 VNIs: 3 Number of L3 VNIs: 2 Flags: * - Kernel VNI Type RD Import RT Export RT Tenant VRF * 20 L2 10.10.10.1:2 65101:20 65101:20 RED * 30 L2 10.10.10.1:4 65101:30 65101:30 BLUE * 10 L2 10.10.10.1:3 65101:10 65101:10 RED * 4001 L3 10.10.10.1:5 65101:4001 65101:4001 RED * 4002 L3 10.10.10.1:6 65101:4002 65101:4002 BLUE
因為本地 l2vni 具有 rd10 . 255 . 255 . 11 : 2 ,所以 RD 本質上是該節點交換的所有路由的標識符。在結構中的其他位置查找時,您可以使用該信息查看 leaf01 所公布的所有路由。
cumulus@leaf01:mgmt:~$ net show bgp l2vpn evpn route rd 10.10.10.1:3 EVPN type-1 prefix: [1]:[ESI]:[EthTag]:[IPlen]:[VTEP-IP] EVPN type-2 prefix: [2]:[EthTag]:[MAClen]:[MAC] EVPN type-3 prefix: [3]:[EthTag]:[IPlen]:[OrigIP] EVPN type-4 prefix: [4]:[ESI]:[IPlen]:[OrigIP] EVPN type-5 prefix: [5]:[EthTag]:[IPlen]:[IP] BGP routing table entry for 10.10.10.1:3:UNK prefix Paths: (1 available, best #1) Advertised to non peer-group peers: leaf02(peerlink.4094) spine01(swp51) spine02(swp52) spine03(swp53) spine04(swp54) Route [2]:[0]:[48]:[44:38:39:00:00:32] VNI 10/4001 Local 10.0.1.12 from 0.0.0.0 (10.10.10.1) Origin IGP, weight 32768, valid, sourced, local, bestpath-from-AS Local, best (First path received) Extended Community: ET:8 RT:65101:10 RT:65101:4001 Rmac:44:38:39:be:ef:aa Last update: Tue May 18 11:41:45 2021 BGP routing table entry for 10.10.10.1:3:UNK prefix Paths: (1 available, best #1) Advertised to non peer-group peers: leaf02(peerlink.4094) spine01(swp51) spine02(swp52) spine03(swp53) spine04(swp54) Route [2]:[0]:[48]:[44:38:39:00:00:32]:[32]:[10.1.10.101] VNI 10/4001 Local 10.0.1.12 from 0.0.0.0 (10.10.10.1) Origin IGP, weight 32768, valid, sourced, local, bestpath-from-AS Local, best (First path received) Extended Community: ET:8 RT:65101:10 RT:65101:4001 Rmac:44:38:39:be:ef:aa Last update: Tue May 18 11:44:38 2021 .... Displayed 8 prefixes (8 paths) with this RD
這是一條重要的信息。類型 2 路線可以采取兩種不同的形式。在本例中,您將分別發送以下兩種類型:
類型 2 MAC 路由: 它只包含一個 48 字節的 MAC 條目。這個條目直接從橋表中拉入,并且只包含 L2 信息。只要在網橋表中學習到一個 MAC 地址,該 MAC 地址就會作為 2 型 MAC 路由拉入 EVPN 。
類型 2 MAC / IP 路由: 這些條目從 ARP 表拉入 EVPN 。讀這個條目,第一部分包括 MAC 地址,第二部分是 IP 地址和掩碼的映射。 IP 地址的掩碼是 a / 32 。由于這是從 ARP 表中提取的,所以所有 EVPN 路由都作為主機路由被提取。
BGP routing table entry for 10.10.10.1:3:UNK prefix ... Route [2]:[0]:[48]:[44:38:39:00:00:32] VNI 10/4001 … BGP routing table entry for 10.10.10.1:3:UNK prefix ... Route [2]:[0]:[48]:[44:38:39:00:00:32]:[32]:[10.1.10.101] VNI 10/4001 ...
使用此信息,您可以驗證 server01 的/ 32 主機路由在 leaf03 的路由表中是否為純 L3 路由,并指向 L3VNI 。
cumulus@leaf01:mgmt:~$ net show route vrf RED
show ip route vrf RED
======================
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
F - PBR, f - OpenFabric,
> - selected route, * - FIB route, q - queued, r - rejected, b - backup
t - trapped, o - offload failure
VRF RED:
K>* 0.0.0.0/0 [255/8192] unreachable (ICMP unreachable), 00:18:17
C * 10.1.10.0/24 [0/1024] is directly connected, vlan10-v0, 00:18:17
C>* 10.1.10.0/24 is directly connected, vlan10, 00:18:17
B>* 10.1.10.104/32 [20/0] via 10.0.1.34, vlan4001 onlink, weight 1, 00:18:05
C * 10.1.20.0/24 [0/1024] is directly connected, vlan20-v0, 00:18:17
C>* 10.1.20.0/24 is directly connected, vlan20, 00:18:17
B>* 10.1.30.0/24 [20/0] via 10.0.1.255, vlan4001 onlink, weight 1, 00:18:04
花點時間分析這個輸出。 Server01 的 Leaf01 中的 neighbor 條目一直作為/ 32 主機路由到達 Leaf03 ,其中下一個躍點是 Leaf01 ,但通過 L3VNI 。
要驗證 L2 VNI 和 L3 VNI 之間的連接是否成功完成,請檢查 L3 VNI :
cumulus@leaf01:mgmt:~$ net show evpn vni 4001 VNI: 4001 Type: L3 Tenant VRF: RED Local Vtep Ip: 10.0.1.12 Vxlan-Intf: vniRED SVI-If: vlan4001 State: Up VNI Filter: none System MAC: 44:38:39:be:ef:aa Router MAC: 44:38:39:be:ef:aa L2 VNIs: 10 20
在這個輸出中, 4001 的 L3 VNI 映射到 VRF RED ,您在 net show evpn vni 10 的輸出中驗證了它。使用這個,您還可以看到 VNI 10 通過 VLAN 4001 映射到 VRF 4001 。您看到的所有輸出都表明您有一個完整的 EVPN Type 2 VXLAN 基礎設施。
概括
給你。從頭到尾,您都看到了 EVPN 如何為基于類型 2 的路由工作。具體來說,我討論了不同的 EVPN 消息類型以及控制平面如何在 L2 擴展環境中聚合。這不是巫術,只是好技術。
關于作者
Rama Darbha 是 NVIDIA 網絡組的解決方案架構主管,主要負責數據中心、 NetDevOps 和以太網交換。他熱衷于幫助客戶和合作伙伴通過開放的網絡策略,充分利用他們的人工智能和計算工作負載。 RAMA 有一個活躍的 CCONP 2019 :: 19 和 CCIE × 22804 ,擁有杜克大學工程與管理碩士學位。
審核編輯:郭婷
-
以太網
+關注
關注
40文章
5376瀏覽量
171115 -
NVIDIA
+關注
關注
14文章
4940瀏覽量
102816
發布評論請先 登錄
相關推薦
評論