EVPN是如何工作及如何控制平面收敛

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 ，拥有杜克大学工程与管理硕士学位。

审核编辑：郭婷