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 ,拥有杜克大学工程与管理硕士学位。
审核编辑:郭婷
全部0条评论
快来发表一下你的评论吧 !