1. 本课目标#

先建立整套课程最重要的三层心智模型：

Underlay
→ 解决 VTEP 到 VTEP 怎么到达

EVPN
→ 解决 MAC / IP / ES / Prefix 在哪里

VXLAN
→ 负责真正运输 Overlay 流量

2. 为什么传统二层网络会遇到问题#

传统大型二层网络依赖 VLAN、MAC Learning、Broadcast、STP 等机制。规模小的时候简单直观，但规模增大后会遇到：

• VLAN 数量上限约 4094；
• 大二层广播域过大；
• STP 会阻塞冗余链路；
• MAC Flooding 与 Unknown Unicast 增加；
• 网络扩展与故障域控制困难。

数据中心因此逐渐演进到：

Traditional L2
    ↓
Leaf-Spine / Clos
    ↓
IP Fabric
    ↓
VXLAN Overlay
    ↓
EVPN Control Plane

3. Underlay 是什么#

Underlay 是真实的 IP 网络。

例如：

Leaf01 VTEP = 10.0.0.1
Leaf03 VTEP = 10.0.0.3

Underlay 的任务是保证：

10.0.0.1
   ↓
Spine
   ↓
10.0.0.3

可以通过 IP Routing 到达。

在 Leaf-Spine 中常使用 eBGP 构建 Underlay，并利用 ECMP 同时使用多条等价路径。

4. Overlay 是什么#

Overlay 是构建在 Underlay IP 网络上的逻辑网络。

例如：

Server01
VLAN10
   ↓
VNI10010
   ↓
VXLAN
   ↓
Remote Leaf
   ↓
VLAN10
Server02

Server 并不知道中间存在 VXLAN。

5. VXLAN 是什么#

VXLAN（Virtual eXtensible Local Area Network）使用 24-bit 的 VNI（VXLAN Network Identifier），将二层 Ethernet Frame 封装进 UDP/IP 中。

典型封装：

Outer Ethernet
Outer IP
UDP 4789
VXLAN Header
Inner Ethernet
Inner IP / Payload

例如：

Outer Src = 10.0.0.1
Outer Dst = 10.0.0.3
VNI       = 10010

Inner:
AA → BB
10.10.10.11 → 10.10.10.22

6. 为什么只有 VXLAN 还不够#

VXLAN 只是 Data Plane。

如果没有 EVPN，Remote MAC 仍然需要依赖 Flood & Learn：

MAC unknown
   ↓
Flood
   ↓
Remote VTEPs
   ↓
Data Plane Learning

规模大后会带来大量 BUM、ARP、Unknown Unicast。

7. EVPN 的作用#

EVPN 可以理解为 VXLAN Overlay 的控制平面。

例如 Leaf03 可以提前告诉 Leaf01：

MAC BB
在我这里

Remote VTEP = 10.0.0.3

于是 Leaf01 不需要靠 Flood 才知道 BB 在哪里。

8. 最终模型#

                    CONTROL PLANE

BGP Underlay
   ↓
VTEP Reachability

MP-BGP EVPN
   ↓
MAC / IP / ES Reachability


================================================


                     DATA PLANE

Server01
   ↓
Leaf01 / VTEP
   ↓
VXLAN Encapsulation
   ↓
Spine / IP Fabric
   ↓
Leaf03 / VTEP
   ↓
VXLAN Decapsulation
   ↓
Server02

9. 本课 5 个结论#

1. Underlay 负责 VTEP-to-VTEP IP Reachability。
2. VXLAN 是真正运输业务报文的 Data Plane。
3. EVPN 是 Overlay Reachability Control Plane。
4. Spine 通常只需要理解 Outer IP，不需要知道 Tenant MAC。
5. 必须始终区分 Control Plane 和 Data Plane。

本课核对来源（2026-10-02）：RFC 7348：VXLAN 与 VNI。

1. BGP 本质#

BGP 本质是在交换 Reachability Information。

可以抽象成：

NLRI
+
Path Attributes

其中：

• NLRI：告诉你“什么东西可以到达”；
• NEXT_HOP：下一跳；
• AS_PATH：经过哪些 AS；
• LOCAL_PREF / MED 等：影响路径选择。

2. Underlay BGP 交换什么#

在 Underlay 中，BGP 主要交换 IP Prefix。

例如：

10.0.0.3/32
NEXT_HOP = Spine

Leaf01 因而知道：

VTEP 10.0.0.3
怎么到达

3. MP-BGP#

MP-BGP（Multiprotocol BGP）允许同一个 BGP 协议承载不同 Address Family。

典型包括：

IPv4 Unicast
IPv6 Unicast
L2VPN EVPN

可以理解：

BGP = 运输框架
AFI/SAFI = 不同货仓
EVPN Route = 一种货物

4. EVPN BGP 交换什么#

EVPN 不再只交换 IP Prefix，而可以表达：

MAC
MAC + IP
Ethernet Segment
BUM Membership
IP Prefix

所以同样是 BGP：

Underlay BGP:
10.0.0.3/32 在哪里？

EVPN BGP:
MAC BB 在哪里？

5. 两次 Lookup#

真正发送一个 Remote MAC 时：

第一层：Overlay Lookup

MAC BB
   ↓
EVPN
   ↓
VTEP 10.0.0.3


第二层：Underlay Lookup

10.0.0.3
   ↓
IP Routing
   ↓
Spine Next-Hop

最终：

MAC
→ Remote VTEP
→ Underlay Next-Hop

6. ECMP#

Leaf-Spine 中经常存在：

Leaf01
├─ Spine01
└─ Spine02

如果两个 Next-Hop 都能到 10.0.0.3，则 Underlay 可以形成 ECMP。

ECMP 解决的是：

“到 VTEP 有几条等价 IP 路径？”

而不是：

“MAC BB 在哪个 VTEP？”

后者属于 EVPN。

7. 本课 5 个结论#

1. BGP 交换的是 Reachability，不只是 IP。
2. MP-BGP 通过 AFI/SAFI 承载多种 NLRI。
3. Underlay BGP 解决 VTEP IP Reachability。
4. EVPN BGP 解决 Overlay MAC/IP/ES Reachability。
5. 实际转发通常需要 Overlay Lookup + Underlay Lookup 两次查询。

1. 场景#

Server01
MAC AA
IP 10.10.10.11
VLAN10
   |
Leaf01
VTEP 10.0.0.1
   |
IP Fabric
   |
Leaf03
VTEP 10.0.0.3
   |
Server02
MAC BB
IP 10.10.10.22
VLAN10

映射：

VLAN10 → VNI10010

2. Server 不知道 VXLAN#

Server01 只发送普通 Ethernet Frame：

Src MAC = AA
Dst MAC = BB

Src IP = 10.10.10.11
Dst IP = 10.10.10.22

VXLAN 是 Leaf/VTEP 的工作。

3. Encapsulation#

Leaf01 将原始 Frame 作为 Inner Ethernet 保留下来，再增加：

Outer Ethernet
Outer IP
UDP
VXLAN Header

形成：

┌──────────────────────────┐
│ Outer Ethernet           │
├──────────────────────────┤
│ Outer IP                 │
│ 10.0.0.1 → 10.0.0.3     │
├──────────────────────────┤
│ UDP 4789                 │
├──────────────────────────┤
│ VXLAN VNI10010           │
├──────────────────────────┤
│ Inner Ethernet           │
│ AA → BB                  │
├──────────────────────────┤
│ Inner IP                 │
│ .11 → .22                │
└──────────────────────────┘

4. Spine 看什么#

Spine 主要看：

Outer Dst IP = 10.0.0.3

它不需要知道：

AA
BB
VLAN10
Tenant IP

5. Remote Leaf#

Leaf03 收到 Outer Dst = 10.0.0.3 的 VXLAN Packet 后：

Decapsulation
   ↓
恢复 Inner Ethernet
   ↓
MAC BB Local
   ↓
Server02

6. Outer Ethernet 会逐跳改变#

Outer IP：

10.0.0.1 → 10.0.0.3

代表 VTEP-to-VTEP。

但 Outer Ethernet 的 Source/Destination MAC 会根据每个 Underlay Hop 重写。

7. VLAN 与 VNI#

不要理解成：

VLAN Tag 必然完整穿越 Fabric

更准确：

Local VLAN10
   ↓
VNI10010
   ↓
Remote VNI10010
   ↓
Local VLAN10

8. MTU#

VXLAN 增加额外 Header，会产生 Encapsulation Overhead。

工程部署时 Underlay MTU 必须留足空间。

9. 本课 5 个结论#

1. Server 不需要理解 VXLAN。
2. VTEP 负责 Encapsulation / Decapsulation。
3. Inner Frame 保存 Tenant 信息。
4. Outer IP 负责 VTEP-to-VTEP Transport。
5. VNI 表示 Overlay Segment。

1. 问题#

假设 Underlay 已经完全正常：

Leaf01 VTEP
→ Leaf03 VTEP
OK

但是 Leaf01 不知道：

MAC BB 在哪里？

即使 VXLAN Tunnel 完全可用，也无法直接形成 Known-Unicast Forwarding。

2. 传统 Flood & Learn#

Ethernet 的传统逻辑：

收到 Frame
   ↓
学习 Src MAC
   ↓
查 Dst MAC
   ↓
Unknown?
   ↓
Flood

通过 Data Plane 观察 Source MAC，交换机逐步学习：

MAC → Port

3. VXLAN Flood & Learn#

扩展到 VXLAN 后：

Unknown MAC
   ↓
Flood to Remote VTEPs
   ↓
Remote Leaf receives traffic
   ↓
Data Plane MAC Learning

规模大时存在：

• Unknown Unicast；
• Broadcast；
• ARP；
• Multicast；
• BUM 扩散；
• MAC Learning 依赖业务数据。

4. EVPN 的改变#

EVPN 允许 Leaf 主动发布：

MAC BB
在我这里
Remote VTEP = 10.0.0.3

于是：

Data Plane Learning
      ↓
Control Plane Advertisement

Remote Leaf 不再必须等业务 Flood 才知道 MAC。

5. EVPN 不代表没有任何 BUM#

仍然可能存在：

• ARP；
• DHCP Broadcast；
• Unknown Unicast；
• Multicast。

EVPN 的价值不是把 BUM 变成 0，而是：

把大量 Remote MAC/IP Learning
从 Data Plane
迁移到 Control Plane

6. 本课核心公式#

EVPN
=
Reachability Control Plane

VXLAN
=
Packet Transport Data Plane

7. 本课 5 个结论#

1. VXLAN 本身不能告诉设备 Remote MAC 在哪里。
2. Flood & Learn 依赖 Data Plane 学习。
3. EVPN 允许 Remote MAC/IP 通过 Control Plane 发布。
4. EVPN 显著降低依赖 Unknown-Unicast Flood 的需求。
5. EVPN 并不等于完全没有 BUM。

1. EVPN Route 的本质#

EVPN Route 可以理解为：

通过 MP-BGP 发布的一类 Overlay Reachability Information。

EVPN 不只描述 IP Prefix，还需要描述：

MAC
MAC+IP
BUM Membership
Ethernet Segment
IP Prefix

所以需要不同 Route Type。

2. Route Type 总表#

3. Type-2：核心中的核心#

例如：

MAC BB
IP 10.10.10.22
VNI10010
Next-Hop 10.0.0.3

Remote Leaf 可以形成：

BB
↓
VTEP 10.0.0.3

这是 EVPN 最基础的 Remote MAC Reachability。

4. Type-3#

Type-3 IMET 主要回答：

这个 VNI 有哪些 Remote VTEP？

它和 BUM Replication 密切相关。

例如：

VNI10010
├─ 10.0.0.1
├─ 10.0.0.2
└─ 10.0.0.3

5. Type-4#

Type-4 主要用于 Ethernet Segment Discovery。

例如：

Leaf01:
I attach to ESI100

Leaf02:
I attach to ESI100

这样两个 PE 可以知道：

我们共同连接同一个 ES

6. Type-1#

Type-1 EAD 主要表达：

这个 Ethernet Segment / EVI
可以通过哪些 PE 到达

后续会参与：

• Aliasing；
• Mass Withdrawal。

7. Type-5#

Type-5 用来发布 L3 Prefix，例如：

10.20.0.0/16

通常与：

VRF
L3VNI
Symmetric IRB
Border Leaf

相关。

8. RD / RT#

EVPN Route 还涉及：

• RD（Route Distinguisher）：让 Route 唯一；
• RT（Route Target）：控制 Import / Export。

简化理解：

RD = 唯一化
RT = 谁可以导入

9. 本课 5 个结论#

1. EVPN Route Type 是为了表达不同类型的 Reachability。
2. Type-2 最核心，负责 MAC/IP。
3. Type-3 负责 BUM Membership。
4. Type-1 / Type-4 对 EVPN-MH 非常关键。
5. Type-5 主要进入 L3 Prefix / L3VNI 场景。

1. L2VNI#

L2VNI 对应一个 Layer 2 Broadcast Domain。

例如：

VLAN10 → VNI10010
VLAN20 → VNI10020

核心关注对象：

MAC

2. L3VNI#

L3VNI 对应一个 VRF / Routing Domain。

例如：

VRF RED → L3VNI50000

核心关注对象：

IP Route

3. 同网段#

Server01：

10.10.10.11/24
VLAN10

访问：

10.10.10.22/24

属于同网段，主要使用 L2VNI10010。

4. 跨网段#

Server01：

10.10.10.11
VLAN10 / VNI10010

访问 Server02：

10.20.20.22
VLAN20 / VNI10020

需要路由。

逻辑：

Server01
   ↓ 本地 Ethernet Frame，目的 MAC 为网关 MAC
VLAN10 / SVI vlan10
   ↓
Ingress Leaf：VRF RED 内路由
   ↓ 重建 Inner Ethernet Header
Inner SMAC = Ingress Leaf Router MAC
Inner DMAC = Egress Leaf Router MAC
   ↓
L3VNI50000 / VXLAN Encapsulation
   ↓
IP Fabric
   ↓
Egress Leaf：Decapsulation → VRF RED 内路由
   ↓
SVI vlan20 / VLAN20
   ↓ 本地 Ethernet Frame：源 MAC 为 vlan20 的网关 MAC，目的 MAC 为 Server02 MAC
Server02

Server 到本地 SVI 的接入段不经过 VXLAN。VLAN10 / VLAN20 分别映射 L2VNI10010 / L2VNI10020，但本例跨 Leaf 的三层隧道使用 L3VNI50000；VNI 是逻辑映射，不能把它画成服务器必经的一条本地隧道。

上述 MAC 重写针对本例的 Symmetric IRB 跨 Leaf 路由。L3VNI 中的内层以太网头使用两端 Router MAC（RMAC）；Egress RMAC 通过 EVPN Router’s MAC Extended Community 学习。跨 Fabric 的这段三层隧道无需保留原始主机以太网头，主机 IP 仍用于路由。解封装并完成出口路由后，Egress Leaf 根据本地 ARP/ND 邻接，重建通往 Server02 的以太网头。不能把这一规则套用到同网段 L2VNI 桥接转发。

5. Symmetric IRB#

IRB：Integrated Routing and Bridging。

Symmetric IRB 的“Symmetric”不是指物理路径一定相同，而是：

Ingress VTEP 和 Egress VTEP 都参与 Overlay Routing。

模型：

L2
↓
L3
↓
L3VNI
↓
L3
↓
L2

6. Anycast Gateway#

在实际 EVPN Fabric 中，Leaf 常提供统一 Anycast Gateway，使 Server 不必知道自己实际连接哪台 Leaf。

Anycast Gateway 是工程实现的重要配套，但核心课程先理解：

L2VNI = Bridge Domain
L3VNI = VRF

7. 本课 5 个结论#

1. L2VNI 对应 Layer 2 Segment。
2. L3VNI 对应 VRF / Routing Domain。
3. 跨网段业务必须进入 Routing。
4. Symmetric IRB 同时需要 L2VNI 与 L3VNI。
5. L2VNI 看 MAC，L3VNI 看 IP Route。

本课核对来源（2026-10-02）：NVIDIA 5.10：Inter-subnet Routing；RFC 9135 §5.2：Symmetric IRB 数据面。

1. Server 为什么需要双归#

如果：

Server
   |
 Leaf01

Leaf01 故障，Server 失去网络。

因此常见：

Leaf01       Leaf02
   \           /
    \         /
      Server
       bond
       LACP

2. LACP 的问题#

Server 希望把两条物理链路组成一个逻辑 LAG。

但 Leaf01、Leaf02 是两台独立设备。

传统 MLAG 的办法：

Leaf01 + Leaf02
≈
一个 Logical LACP System

3. Peerlink#

传统 MLAG 通常存在：

Leaf01 ===== Peerlink ===== Leaf02

Peerlink 用于双机协调，并在某些场景承担数据转发。

4. Pair-based Architecture#

MLAG 的核心思维：

两台 Leaf
组成一个 Pair

通常伴随：

• MLAG Domain；
• Peerlink；
• 厂商实现差异；
• 双机状态协调。

5. MLAG 不是错误技术#

MLAG 在很多双 ToR 场景成熟、简单、可靠。

但在大规模 Clos Fabric 中，如果每两个 Leaf 都形成特殊 Pair，会引入：

Pair State
Peerlink
Failure Domain
Vendor-specific logic

EVPN-MH 的目标不是“证明 MLAG 错了”，而是把 Multihoming 纳入 EVPN 的分布式控制平面。

6. 演进#

Traditional MLAG

Leaf01 ===== Leaf02
   \         /
     Server

        ↓

EVPN-MH

Leaf01     Leaf02
   \         /
     Server

No traditional MLAG peerlink

7. 本课 5 个结论#

1. MLAG 解决服务器双归和 LACP。
2. Peerlink 是传统 MLAG 的核心双机关系。
3. MLAG 是 Pair-based Architecture。
4. EVPN-MH 不是简单“删除 Peerlink”。
5. EVPN-MH 会用分布式 EVPN Control Plane 表达 Multihoming。

1. EVPN-MH#

目标：

Leaf01       Leaf02
   \           /
    \         /
      Server01
       bond0
       LACP

两条链路：

All-Active

但不依赖传统 MLAG Peerlink。

2. ES#

ES：Ethernet Segment。

在本课程场景中：

Server01 到 Leaf01 / Leaf02
这一组双归 Ethernet Attachment

构成一个 Ethernet Segment。

ES 不是 Server 本身，而是：

Multihomed Ethernet Attachment Context

3. ESI#

ESI：Ethernet Segment Identifier。

本课程把同一个 ES 的 ESI 简称为 ESI100，这是教学别名，不是设备可接受的 ESI 字符串。以下采用 Cumulus 自动生成 type-3 ESI 的方式，给这个别名一个明确示例：

ESI100（教学别名）
segment MAC = 44:38:39:ff:00:aa
local-id    = 100（十六进制 00:00:64）
实际 ESI    = 03:44:38:39:ff:00:aa:00:00:64

自动生成的格式：
03 + 6-byte segment MAC + 3-byte local-id

其中 03 是 ESI 类型，不能与 EVPN Route Type-3 混淆。同一 ES 的两台 Leaf 使用相同 segment MAC 和 local-id；不同 ES 的组合必须保证 ESI 唯一。

LACP System ID：完整标识由 System Priority（2 字节）和 System MAC（6 字节）组成。Cumulus 用 segment MAC 作为其中的 MAC 部分。同一 ES 上两台 Leaf 的下联 bond 必须使用相同 segment MAC 和相同 LACP System Priority，才能向服务器呈现一致的 LACP 对端标识；只对齐 MAC 仍不够。这里要求一致的是两台 Leaf 的标识，不要求服务器自身的 System ID 与 Leaf 相同。

Linux bonding 的 System Priority 默认值为 65535，NVIDIA 5.10 的 bond 输出示例也显示 65535；现场应在两台 Leaf 上分别用 sudo cat /proc/net/bonding/bond1 核对实际 System priority 与 System MAC address，并从服务器侧核对 Partner System ID、成员选择状态和其他 LACP/bond 参数。示例 segment MAC 取自 NVIDIA 建议的保留范围，只供实验说明，现场应按地址规划分配。

自动生成与手动填写的区别：上面的 03:... 是 segment mac-address 与 segment local-id 自动生成后的值。Cumulus 5.6 及以后，NVUE 手动配置 10-byte segment identifier 时仅接受以 00 开头的值，且不能同时配置 local-id；不要把自动生成的 03:... 直接抄入手动 identifier。

Leaf01 与 Leaf02 如果配置同一个 ESI：

Leaf01: ESI100
Leaf02: ESI100

说明：

我们连接同一个 Ethernet Segment

4. 不同标识的区别#

5. Type-4#

Type-4 Ethernet Segment Route 主要帮助连接同一个 ES 的 PE 发现彼此。

Leaf01
Type-4 ESI100
      \
       EVPN
      /
Leaf02
Type-4 ESI100

6. Type-1 / Type-2 / Type-4#

Type-4
→ 谁属于这个 ES？

Type-1
→ 这个 ES/EVI 经哪些 PE 可达？

Type-2
→ 哪个 MAC/IP 在这个 ES 上？

7. All-Active#

All-Active 不等于每一帧复制两份。

Server LACP 通常会对 Flow 做 Hash：

Flow A → Leaf01
Flow B → Leaf02

两个 PE 都可以转发业务。

8. 本课 5 个结论#

1. ES 是 Multihomed Ethernet Attachment。
2. ESI 是 ES 的标识。
3. ESI ≠ MAC ≠ VNI ≠ VTEP。
4. Type-4 主要用于 ES Peer Discovery。
5. All-Active 不等于 Active/Standby。

本课核对来源（2026-10-02）：NVIDIA 5.10：EVPN Multihoming；RFC 7432：ESI；NVIDIA 5.10：Bonding 排障；Linux bonding：System Priority。

1. 问题#

Remote Leaf03 发送 ARP Broadcast：

            Leaf03
             /  \
            /    \
        Leaf01  Leaf02
           \      /
            Server01
             ESI100

如果 Leaf01、Leaf02 都把同一份 Broadcast 向 ESI100 下发：

Server01
收到两份相同 ARP

2. DF#

DF：Designated Forwarder。

例如：

ESI100 / VLAN10

Leaf01 = DF
Leaf02 = Non-DF

则对相关 Network → ES 的 BUM：

Leaf01
  |
  v
Server01

Leaf02
  X

3. DF ≠ Active#

Non-DF 仍然可以：

• 转发 Known Unicast；
• 接收 Server Upstream Traffic；
• 参与 All-Active。

所以：

DF
≠
整台交换机 Primary

Non-DF
≠
Standby

4. 为什么 Known Unicast 不依赖 DF#

Known Unicast 通常是：

MAC AA
↓
ECMP / Aliasing
↓
Leaf01 或 Leaf02

每个 Flow 只选择一个路径，并不会像 BUM 一样天然复制多份。

5. Type-4 与 DF#

Type-4 提供：

ESI100 Members:
Leaf01
Leaf02

双方根据一致的 ES Member Set 进行 DF Election，但还必须使用一致的选举算法与参数。需区分协议基础算法和本教程的 Cumulus 实现：

• RFC 7432 §8.5 的取模算法：从 Type-4 路由的 Originating Router IP 字段取得各 PE 地址，按数值升序排序，编号从 0 开始。对于 VLAN-based service，成员数为 N、VLAN ID 为 V 时，编号 i = V mod N 的 PE 成为该 ES/VLAN 的 DF。VLAN bundle 使用该 bundle 内最小 VLAN ID。地址或成员集合变化可能改变排序与结果。
• Cumulus Linux 5.10 的 preference 算法：NVIDIA 文档说明按 Ethernet Segment 选举 DF，DF preference 较高的 VTEP 当选，默认 preference 为 32767；官方 JSON 示例的 df-algorithm 为 preference。为获得可预测的结果，可对同一 ES 的两个 Leaf 配置不同 preference，并查询实际 DF 状态。不能把“Preference 加 VLAN 取模”写成一个混合公式，也不能把 RFC 的取模流程当作 Cumulus 5.10 的默认行为。

6. DF 的粒度与 BUM 分担#

RFC 7432 的 service carving 可让同一 ES 上不同 VLAN/service 选出不同 DF；是否支持、使用哪种算法，要以具体实现为准。不能据此假设 Cumulus 5.10 会在同一 ES 上自动按 VLAN 交替选 DF。

按本课 Cumulus 5.10 的 ES preference 模型，可以在不同 ES 上设置相反的 preference，让两台 Leaf 分担不同 ES 的 BUM 交付。例如：

ESI100：Leaf01 preference 较高 → Leaf01 DF
ESI200：Leaf02 preference 较高 → Leaf02 DF

这是不同 ES 之间的分担，不改变 All-Active Known Unicast 的转发机制。

7. Type-3 与 DF#

Type-3
→ BUM 应发送到哪些 Remote VTEP

DF
→ 哪个 PE 可以把这份 BUM 交付给共享 ES

8. 本课 5 个结论#

1. DF 主要防止 Multihomed ES 收到重复 BUM。
2. DF 不等于 Active/Standby。
3. Non-DF 仍能正常转发 Known Unicast。
4. Type-4 为 DF Election 提供 ES Peer Set。
5. Type-3 与 DF 工作在不同层次。

本课核对来源（2026-10-02）：RFC 7432 §8.5：DF Election；NVIDIA 5.10：EVPN-MH / DF preference。

1. 问题#

Server01 发 Broadcast：

Server01
   ↓
Leaf01
   ↓
VXLAN Fabric
   ↓
Leaf02
   ↓
Server01

如果 Leaf02 再从同一个 ESI100 发回 Server01，就会形成 Loop / Duplicate。

2. Split Horizon 核心规则#

Ingress ES == Egress ES
        ↓
       DROP

也就是：

从某个 Ethernet Segment 进入 Fabric 的 BUM，不能经另一个 PE 再从同一个 ES 发回。

3. 与 DF 的区别#

Fabric → ES
→ DF Election

ES → Fabric → Same ES
→ Split Horizon

4. VXLAN 场景#

VXLAN Header 本身没有 ESI Label。

因此 EVPN-VXLAN 的 Split-Horizon 思维可以理解成：

Outer Source VTEP
+
EVPN 学到的 Shared ES Information

例如 Leaf02 收到：

Outer Src = 10.0.0.1

控制平面知道：

10.0.0.1 = Leaf01
Leaf01 与我共享 ESI100

于是：

不能从 ESI100 再发出去

5. Local Bias#

来自 Access Side 的 Flooded Traffic，应由 Ingress Leaf 完成本地必要复制。

简化理解：

本地该送的
→ 本地送

同一个 ES 不该绕回的
→ Peer 上过滤

6. 本课 5 个结论#

1. Split Horizon 防止 Same-ES 回环。
2. DF 与 Split Horizon 解决不同方向的问题。
3. VXLAN 没有把 ESI 直接放进 VXLAN Header。
4. Shared-ES/VTEP 关系是 VXLAN Split Horizon 的关键依据。
5. Split Horizon 最终必须变成 Data Plane Filter。

1. 问题#

Server01：

bond0
├─ NIC1 → Leaf01
└─ NIC2 → Leaf02

由于 LACP Hash，可能只有 Leaf01 收到 Src MAC AA。

于是：

Leaf01 learned AA
Leaf02 did not learn AA

如果 Remote Leaf03 只认为：

AA → Leaf01

那 Leaf02 的 All-Active 路径就被浪费。

2. Type-2#

Leaf01 发布：

MAC AA
ESI100
Next-Hop Leaf01

告诉 Remote Leaf：

AA belongs to ESI100

3. Type-1 EAD#

Leaf01：

ESI100 / VNI10010
reachable via Leaf01

Leaf02：

ESI100 / VNI10010
reachable via Leaf02

4. Remote Leaf 推导#

MAC AA
   ↓
ESI100
   ↓
+---------+---------+
|                   |
Leaf01             Leaf02

这就是 Aliasing。

5. Aliasing ≠ MAC Table Sync#

不是：

Leaf01 MAC Table
→ copy
→ Leaf02

而是 Remote PE 根据：

Type-2 + Type-1

推导多个有效 Next-Hop。

补充：Aliasing 描述的是远端 PE 根据 Type-2 与 Type-1 构建下一跳的机制。Cumulus 的 ES peers 仍可以通过 EVPN 路由同步 MAC/邻居状态；“Aliasing ≠ MAC Table Sync”并不表示 EVPN-MH 不存在任何 MAC/邻居同步。

6. Aliasing 与 ECMP#

Aliasing
→ 构造多个有效 Next-Hop

ECMP
→ 每个 Flow 选择其中一个 Next-Hop

7. Type-1 per-EVI / per-ES#

实用心智模型：

EAD-per-EVI
→ Aliasing

EAD-per-ES
→ Mass Withdrawal / Fast Convergence

8. 本课 5 个结论#

1. 一个 PE 没学到 MAC，不代表它不能到达该 ES。
2. Aliasing 的核心是 Type-2 + Type-1。
3. Aliasing 不等于 MLAG MAC Sync。
4. Aliasing 负责“建立多个有效路径”。
5. ECMP 负责“选择具体路径”。

本课核对来源（2026-10-02）：NVIDIA 5.10：EVPN Multihoming。

1. 场景#

ESI100 后面可能有：

MAC0001
MAC0002
MAC0003
...
MAC10000

正常：

每个 MAC
↓
ESI100
↓
Leaf01 + Leaf02

现在：

Leaf01 → ESI100
DOWN

但是：

Leaf01 本身还活着
BGP 还 UP
VTEP 仍可达

2. 最笨的方法#

逐条：

Withdraw MAC0001
Withdraw MAC0002
...
Withdraw MAC10000

但这些 MAC 的共同故障原因其实只有一个：

Leaf01
不再能到达 ESI100

3. Mass Withdrawal#

控制平面直接表达：

Leaf01 → ESI100
Reachability Lost

Remote Leaf 因而：

ESI100
├─ X Leaf01
└─ Leaf02

于是所有相关 MAC：

AA → Leaf02
AB → Leaf02
AC → Leaf02
...

4. Type-1#

Mass Withdrawal 的核心与 Ethernet A-D Reachability 密切相关。

实用理解：

Type-2
→ MAC 属于哪个 ES

Type-1
→ 这个 ES 经哪些 PE 可达

当 Type-1 Reachability 变化：

所有依赖这个 ES 的 MAC Path
可以一起重新计算

5. 与 Aliasing 的关系#

Aliasing
→ 正常时增加路径

Mass Withdrawal
→ 故障时删除路径

两者是一对非常漂亮的机制。

6. Access Failure 与 PE Failure#

Leaf01 → Server Down

和：

Leaf01 整机 Down

不是一回事。

前者可能：

BGP UP
VTEP UP
只有 ES Attachment Down

因此 ES-level Reachability 非常重要。

7. 本课 5 个结论#

1. Mass Withdrawal 不是简单“批量删除 Type-2”。
2. 它在 ES Reachability 层表达共同故障。
3. Type-1 EAD 是关键控制信息。
4. Access Link Failure 与 PE Failure 必须区分。
5. Aliasing 加路径，Mass Withdrawal 删路径。

1. 拓扑#

                               Spine
                         /       |       \
                    Leaf01     Leaf02    Leaf03
                 VTEP .1     VTEP .2   VTEP .3
                      \         /          |
                       \       /           |
                       Server01          Server02
                        ESI100

Server01:
MAC AA
IP 10.10.10.11

Server02:
MAC BB
IP 10.10.10.22

VLAN10
VNI10010

假设暂不考虑 ARP Suppression，以便看到完整 ARP/BUM 过程。

2. Ping 之前#

Underlay 已经知道：

10.0.0.1
10.0.0.2
10.0.0.3

如何互相到达。

EVPN 也可能已经存在：

• Type-3 VNI Membership；
• Type-4 ES Discovery；
• Type-1 EAD。

但 MAC AA / BB 可能尚未建立。

3. 第一次 Ping 先发生 ARP#

Server01 判断：

10.10.10.22
属于同一 /24

ARP Cache MISS，于是发送：

Src MAC = AA
Dst MAC = FF:FF:FF:FF:FF:FF

Who has 10.10.10.22?

LACP 假设选择 Leaf01。

4. Leaf01 学习 AA#

Leaf01：

AA
↓
Local ESI100

并向 EVPN 发布 Type-2。

Remote Leaf 可结合 Type-1 做 Aliasing：

AA
↓
ESI100
↓
Leaf01 + Leaf02

5. ARP 是 BUM#

Leaf01 根据 Type-3 / BUM Membership 复制到 Remote VTEPs。

发往 Leaf03：

Outer Src = 10.0.0.1
Outer Dst = 10.0.0.3
UDP 4789
VNI10010

Inner:
AA → Broadcast
ARP

6. Leaf02 的 Split Horizon#

Leaf02 可能也收到一份。

它知道：

Outer Src = Leaf01
Leaf01 与我共享 ESI100

所以：

不能把这份 BUM 再发回 ESI100

7. Leaf03 Decap#

恢复：

AA → Broadcast
Who has 10.10.10.22?

发给 Server02。

8. Server02 ARP Reply#

Server02：

BB → AA
10.10.10.22 is at BB

Leaf03 学习：

BB
↓
Local Server02 Port

并发布 Type-2：

BB
IP 10.10.10.22
VTEP 10.0.0.3

9. Reply 可以走 Leaf02#

Leaf03 已知道：

AA
↓
ESI100
↓
Leaf01 + Leaf02

ECMP 可以选 Leaf02。

于是：

Leaf03
↓ VXLAN
Leaf02
↓
Server01

Non-DF 也能转发 Known Unicast。

10. 真正的 ICMP Echo Request#

ARP Cache 建立后：

AA → BB
10.10.10.11 → 10.10.10.22

假设 Server LACP 选择 Leaf02：

Leaf02
查 BB
↓
VTEP 10.0.0.3
↓
VXLAN
↓
Leaf03
↓
Server02

11. Echo Reply#

Server02：

BB → AA

Leaf03 查：

AA
↓
Leaf01 + Leaf02

ECMP 假设选择 Leaf01：

Leaf03
↓
Leaf01
↓
Server01

12. 第一次 vs 第二次 Ping#

核心：

第一次 Ping
主要成本 = 发现

第二次 Ping
主要成本 = 转发

13. 本课 5 个结论#

1. 第一次 Ping 的复杂部分主要是 ARP/Discovery。
2. ARP Request 可经 Leaf01，Reply 可经 Leaf02。
3. Split Horizon 会真实参与第一次 BUM。
4. Aliasing 让返回路径可以利用另一台 Leaf。
5. 稳定状态下业务基本是 Known-Unicast VXLAN。

1. 故障分类#

Access Failure
PE Failure
Underlay Failure
Overlay Control-Plane Failure

本课有 4 类故障（Case 1–4）和 1 个设计澄清。Case 3 分为单上联失效、全部上联失效两个子场景，因此总表包含 5 个故障子场景和 1 个设计澄清，共 6 行。必须先判断故障发生在哪一层。

Case 1：Leaf01 → Server 链路断开#

Leaf01       Leaf02
   X            |
    \          /
      Server01

特点：

Leaf01 alive
VTEP alive
BGP alive

仅 ESI100 Attachment Down

Underlay 基本不变。

控制平面应撤销 Leaf01 对 ESI100 的 Reachability，使 Remote Leaf：

AA
Before:
Leaf01 + Leaf02

After:
Leaf02

核心机制：

Mass Withdrawal

Case 2：Leaf01 整机宕机#

Leaf01
  X

影响更广：

VTEP
Underlay BGP
EVPN BGP
Type-1/2/3/4

都会受到影响。

Remote Leaf 最终：

AA → Leaf02

但这里是：

PE-level Failure

不是 ES-only Failure。

Case 3：Leaf01 → Spine 链路断开#

3A：只断一条 Uplink#

Spine01 X
Spine02 |
       Leaf01

Leaf01 仍有 Fabric Reachability。

Underlay：

2 ECMP Paths
→
1 ECMP Path

EVPN-MH 不应把 Leaf01 从 ESI100 删除。

3B：所有 Uplink 都断#

Fabric
  X
  X
Leaf01
  |
Server

Leaf01 CPU 可能还活着，但已经无法进入 Fabric。

Cumulus 的 uplink tracking 在已标记的 MH uplink 全部 operational down 时，把本机 ES bonds 置为 protodown / error-disabled（接口状态中可见下联成员端口 protodown）。服务器通过链路状态或 LACP 状态变化，将通往 Leaf01 的失效成员移出可用聚合链路，再把发送流量分配到通往健康 Leaf02 的成员。这里的闭环是“交换机阻断失效下联 → 服务器排除失效成员 → 健康链路承接流量”；实际收敛时间取决于端口状态传播、服务器 bonding/LACP 检测及相关定时器，不能视为瞬时完成。必须正确标记所有承担 VXLAN 传输的上联；见第 16 课的配置核对示例。

该触发条件是上联接口状态，并不覆盖“接口仍 up、但远端 Fabric 黑洞”的所有故障；后者还需要检查 Underlay 路由与故障检测机制。

Case 4：BGP EVPN Session Down#

可能出现：

VTEP ping OK
Underlay OK
EVPN Session Down

这说明：

Underlay Healthy
≠
Overlay Healthy

如果还有冗余 EVPN Session：

RR1 Down
RR2 Up

控制平面可能仍正常。

如果所有 EVPN Paths 都失效，则 Remote Leaf 最终应移除 Leaf01 的 EVPN Reachability。

设计澄清：Leaf01 / Leaf02 没有 Peerlink#

这不是故障。

EVPN-MH 正常设计就是：

Leaf01     Leaf02
   \         /
      Server

Multihoming 依靠：

Type-1
Type-2
Type-4
DF
Split Horizon
Aliasing
Mass Withdrawal

而不是传统 MLAG Peerlink。

总表#

本课 5 个结论#

1. ES Failure 与 PE Failure 必须区分。
2. 单条 Spine Link Down 首先由 Underlay ECMP 处理。
3. VTEP 可达不代表 EVPN 正常。
4. 全 Uplink Down 与单 Uplink Down 完全不同。
5. 没有 Peerlink 是 EVPN-MH 的正常设计。

本课核对来源（2026-10-02）：NVIDIA 5.10：EVPN Multihoming / Uplink Tracking。

1. 整体架构#

NVUE / Configuration
├─ 路由配置 → FRR (bgpd / zebra) → Netlink
└─ 接口配置 → ifupdown2 (swp / bond / bridge / VXLAN / VRF)
                    ↓ 两条配置路径都作用于系统状态
              Linux Kernel
                    ↓
                 switchd
                    ↓
              Spectrum ASIC（物理交换机）

NVUE 同时生成 FRR 配置与 Linux 接口配置，通过 FRR、ifupdown2 等组件应用；它不是只配置 FRR。上图是配置和状态同步的关系，不是业务报文逐包经过的流水线。

虚拟环境边界：Cumulus VX / Air 等虚拟实验以 Linux Kernel 实现软件数据平面，没有真实 Spectrum ASIC。可以验证 BGP、EVPN、FDB、邻居与 VXLAN 转发，但不能据此验证真实 ASIC offload、硬件表项或线速性能；switchd 的硬件同步部分需要在物理交换机上核验。

核心理解：

FRR
决定“应该怎么转发”

Linux Kernel
表达“系统准备怎么转发”

switchd
同步到 Spectrum ASIC

ASIC
真正逐包转发

2. Linux 网络对象#

swp#

swp1
swp51
swp52

对应前面板物理端口。

bond#

bond1

对应 Linux LACP/LAG。

EVPN-MH 中：

bond1 + ESI
↓
Ethernet Segment

bridge#

br_default 可以理解成 Linux Kernel 中的 VLAN-aware L2 Switch。

VXLAN Device#

例如：

vxlan48

是 Linux VXLAN Netdevice。

注意：

vxlan48 ≠ VTEP IP

现代 Cumulus 支持 Single VXLAN Device，一个 VXLAN Device 可承载多个 VLAN↔VNI Mapping。

3. VLAN → VNI#

例如：

VLAN10
↓
VNI10010

Linux/Cumulus 中表现为 Bridge VLAN 与 VXLAN VNI Mapping。

4. SVI / VRF / L3VNI#

VLAN10
↓
SVI vlan10
↓
VRF RED
↓
L3VNI50000

实用理解：

L2VNI
→ Bridge Domain

L3VNI
→ VRF

5. FRR#

FRR 中两个关键角色：

bgpd
zebra

bgpd#

负责：

• BGP Neighbor；
• IPv4 Unicast；
• L2VPN EVPN；
• Best Path；
• EVPN Route Types；
• RD / RT。

zebra#

负责：

• RIB；
• Interface State；
• VRF；
• Kernel Programming；
• EVPN Data Plane Integration；
• Netlink。

6. 一条 Type-2 的生命周期#

Remote Leaf03 发送：

Type-2
MAC BB
IP 10.10.10.22
VNI10010
NH 10.0.0.3

Leaf01：

bgpd
↓
RT Import / Best Path
↓
zebra
↓
Netlink
↓
Linux FDB

最终：

BB
↓
vxlan48
↓
Remote VTEP 10.0.0.3

Linux bridge fdb 中 Remote EVPN MAC 常表现为：

extern_learn

7. switchd#

Linux Kernel 中的 Route/FDB/VXLAN 状态最终需要被 Hardware Offload。

Linux Kernel
↓
switchd
↓
Spectrum SDK
↓
Spectrum ASIC

8. ASIC#

ASIC 最终真正执行：

MAC Lookup
IP Lookup
ECMP
VXLAN Encapsulation
VXLAN Decapsulation
NHG
Filtering

正常业务 Packet 不会逐包经过 FRR。

9. Local MAC 的反方向#

Server Src MAC AA
↓
Local Access Learning
↓
Linux / zebra
↓
bgpd
↓
EVPN Type-2
↓
Remote Leafs

也就是：

Local Data Plane
→ Control Plane Advertisement

Remote Control Plane
→ Local Data Plane Programming

10. EVPN-MH 四大机制如何落硬件#

本课 5 个结论#

1. FRR 不是 Data Plane。
2. bgpd 与 zebra 职责不同。
3. EVPN Type-2 最终必须变成 FDB/Nexthop。
4. switchd 负责 Linux → ASIC 同步。
5. EVPN-MH 的协议机制最终必须变成 Forwarding State；物理交换机还要核验硬件下发表项。

本课核对来源（2026-10-02）：NVIDIA 5.10：接口配置与 ifupdown2；NVIDIA 5.10：虚拟环境。

版本说明：本课示例以 NVIDIA Cumulus Linux 5.10 官方文档为核对基线（2026-10-02），不表示所有 5.x 版本语法完全一致。先查看 /etc/os-release，并通过 sudo vtysh -c 'show version' 确认 FRR 版本。

命令执行环境：nv ...、ip ...、bridge ... 在 Linux shell 执行；FRR 查询统一写成 sudo vtysh -c 'show ...'。若已通过 sudo vtysh 进入 FRR CLI，只输入引号中的 show ... 即可。

Cumulus VX / Air 虚拟实验主要核验 Linux 软件数据平面；没有真实 Spectrum ASIC，不能按本课的硬件层要求验证 offload 或线速性能。

1. 总排障顺序#

Interface
   ↓
Bond / ESI
   ↓
Bridge / VLAN / VNI
   ↓
Underlay
   ↓
EVPN Session
   ↓
EVPN Route
   ↓
EVPN Forwarding State
   ↓
Linux FDB
   ↓
ASIC / Data Plane

2. 第一层：Interface#

nv show interface
ip -br link
ip addr

关注：

• admin / oper；
• speed；
• MTU；
• Server Downlink；
• Spine Uplink；
• Bond；
• Loopback/VTEP。

如果：

admin up
oper down

优先查：

Cable
Optics
Server NIC
Port Configuration

3. 第二层：Bond / Ethernet Segment#

nv show interface bond1
nv show evpn multihoming esi
nv show evpn vni 10010 multihoming esi

FRR：

sudo vtysh -c 'show evpn es'
sudo vtysh -c 'show evpn es-evi'

重点验证：

bond1
↓
ESI
↓
Local ES
↓
Remote ES Peer

如果 Bond 存在但 FRR 的 show evpn es 看不到 ESI，应检查全局 MH 开关、bond 的 segment MAC/local-id，以及两台 Leaf 是否表示同一个 ES。

实验配置核对示例（Cumulus 5.10）：以下是配置命令，不是只读排障命令。假设 bond1 和上联 swp51/swp52 已按实际拓扑配置；同一 ES 的两台 Leaf 使用相同 segment MAC 与 local-id。VLAN-aware bridge、EVPN BGP 与 ARP suppression 等前置配置也需要具备。

若实验环境为 5.16.x，请把下面第一条命令替换为 nv set evpn multihoming state enabled，并核对其余命令的版本适用性。

nv set evpn multihoming enable on
nv set interface bond1 evpn multihoming segment mac-address 44:38:39:ff:00:aa
nv set interface bond1 evpn multihoming segment local-id 100
nv set interface swp51 evpn multihoming uplink on
nv set interface swp52 evpn multihoming uplink on
nv config apply

这里自动生成的 ESI 是第 8 课的 03:44:38:39:ff:00:aa:00:00:64。现场将 bond 和上联口替换成实际接口，并标记所有承担 VXLAN 传输的 MH uplinks。全部已标记上联 down 时，ES bonds 应进入 protodown；同时确认服务器的 LACP system identifier 与聚合状态。

语法有版本差异：较早版本（已核对 5.4 / 5.10 文档）使用 nv set evpn multihoming enable on；较新版本至少在 5.16 官方文档中已使用 nv set evpn multihoming state enabled，5.18 文档也使用该语法。这不表示 5.16 是首次变更版本，具体以所用版本的官方文档为准。在 Spectrum A1 上启用 MH 可能重启 switchd、复位网络端口，应用前需安排相应变更窗口。

4. 第三层：Bridge / VLAN / VNI#

nv show bridge
nv show bridge domain br_default
nv show bridge domain br_default vlan-vni-map
bridge link
bridge vlan
nv show evpn vni 10010

nv show bridge 是有效的桥列表概览；检查具体 bridge 的配置时使用 nv show bridge domain br_default，检查 VLAN/VNI 映射时使用 vlan-vni-map。

要验证：

Server
↓
bond1
↓
VLAN10
↓
br_default
↓
VNI10010
↓
vxlan48

任何一层缺失，Overlay 都会异常。

5. 第四层：Underlay#

以下示例检查 Default VRF 中承载 VTEP IPv4 可达性的 IPv4 Unicast 地址族；与下一节的 L2VPN EVPN Overlay 查询分别核对。

sudo vtysh -c 'show bgp ipv4 unicast summary'

原来的 show bgp summary 是合法概览命令，显式指定 AFI/SAFI 可以让本节的观察范围更清楚。如果现场 Underlay 承载 IPv6 Unicast，使用 sudo vtysh -c 'show bgp ipv6 unicast summary'；若采用其他路由协议，则检查对应协议与路由表。选择地址族应依据实际承载的路由，不能只根据 BGP 邻居地址是否为 IPv6 link-local 判断。

Linux：

ip route get 10.0.0.3
ping -I 10.0.0.1 10.0.0.3

核心：

Remote VTEP 必须可达

记住：

VTEP Ping Success
≠
EVPN Healthy

但 VTEP 不可达时，应优先修 Underlay。

6. 第五层：EVPN Session#

sudo vtysh -c 'show bgp l2vpn evpn summary'

检查：

Neighbor
State
Uptime
PfxRcd

不要只看 Established，还要看是否真的收到 EVPN Routes。

7. 第六层：按 Route Type 查#

sudo vtysh -c 'show bgp l2vpn evpn route type ead'
sudo vtysh -c 'show bgp l2vpn evpn route type macip'
sudo vtysh -c 'show bgp l2vpn evpn route type multicast'
sudo vtysh -c 'show bgp l2vpn evpn route type es'
sudo vtysh -c 'show bgp l2vpn evpn route type prefix'

对应：

8. 第七层：EVPN Forwarding State#

sudo vtysh -c 'show evpn vni'
sudo vtysh -c 'show evpn mac vni 10010'
sudo vtysh -c 'show evpn mac vni all'
sudo vtysh -c 'show evpn es'
sudo vtysh -c 'show evpn es-evi'

NVUE：

nv show evpn vni 10010
nv show evpn vni 10010 mac
nv show evpn multihoming esi
nv show bridge domain br_default mac-table

nv show evpn vni 10010 mac 有官方出处，NVUE 命令参考注明从 5.4.0 引入；它显示 VNI 内的 EVPN MAC 状态。nv show bridge domain br_default mac-table 显示 bridge FDB，两者的观察层次不同，不能当作完全等价的替换。

9. 第八层：Linux FDB / Neighbor / Route#

bridge fdb show
ip neigh
ip route

Remote EVPN MAC 理想状态类似：

BB
dev vxlan48
dst 10.0.0.3
extern_learn

这条链最重要：

BGP EVPN RIB
↓
EVPN MAC State
↓
Linux FDB

如果在哪一层消失，故障域基本就能锁定。

10. 同一个 MAC 查三遍#

例如 BB：

BGP#

sudo vtysh -c 'show bgp l2vpn evpn route type macip'

问：

BGP 学到 BB 了吗？

EVPN Data Plane#

sudo vtysh -c 'show evpn mac vni 10010'

问：

zebra 已经形成 Remote MAC State 吗？

Linux FDB#

bridge fdb show

问：

Kernel 已经形成 BB → VTEP 吗？

11. 同一个 ESI 也查三遍#

# Linux / NVUE：bond 与 ESI
nv show interface bond1
nv show evpn multihoming esi

# FRR：EVPN ES 转发状态
sudo vtysh -c 'show evpn es'
sudo vtysh -c 'show evpn es-evi'

# FRR：BGP 学到的 ES / ES-EVI 信息
sudo vtysh -c 'show bgp l2vpn evpn es'
sudo vtysh -c 'show bgp l2vpn evpn es-evi'

验证：

Linux Bond
↓
EVPN Ethernet Segment
↓
BGP Type-1 / Type-4

12. Aliasing 排障#

现象：

Remote Leaf 只能通过 Leaf01
不能走 Leaf02

重点：

sudo vtysh -c 'show evpn es'
sudo vtysh -c 'show bgp l2vpn evpn es-evi'
sudo vtysh -c 'show bgp l2vpn evpn route type macip'
nv show evpn multihoming esi

确认：

MAC AA
↓
ESI100
↓
Leaf01 + Leaf02

是否完整。

13. Mass Withdrawal 验证#

正常：

ESI100
Leaf01 + Leaf02

断开：

Leaf01 → Server

预期 Remote Leaf：

Before:
AA → Leaf01 + Leaf02

After:
AA → Leaf02

重点观察 Type-1 / EAD Reachability 的变化。

14. 现场“10 分钟流程”#

Server 不通
   ↓
① Interface / Bond
   ↓
② ESI / ES
   ↓
③ VLAN / VNI
   ↓
④ Underlay VTEP
   ↓
⑤ EVPN Session
   ↓
⑥ Type-2 / Type-1 / Type-4
   ↓
⑦ EVPN MAC State
   ↓
⑧ Linux FDB
   ↓
⑨ MTU / VXLAN / ASIC / Server

本课 5 个结论#

1. 排障必须按层，不要随机试命令。
2. BGP RIB 和 EVPN Forwarding State 不是一回事。
3. EVPN-MH 必须同时查 MAC 和 ESI。
4. “同一个对象跨三层追踪”是最有效的方法。
5. 命令存在版本差异，必须先确认 Cumulus/FRR 版本。

本课核对来源（2026-10-02）：NVIDIA 5.10：Troubleshooting EVPN；NVUE：EVPN 查询命令；NVUE：Bridge 查询命令；NVIDIA 5.10：EVPN-MH 配置；NVIDIA 5.16：EVPN-MH 配置；NVIDIA 5.18：EVPN-MH 配置；FRR：BGP 地址族与 summary 查询。

1. 一句话模型#

Underlay
→ VTEP 怎么到达

EVPN
→ Endpoint / ES 在哪里

VXLAN
→ Packet 怎么跨 Fabric

2. VXLAN vs EVPN#

核心：

VXLAN
= How to transport

EVPN
= Where to transport

3. BGP Underlay vs BGP EVPN Overlay#

实际：

MAC BB
↓
EVPN Lookup
↓
VTEP 10.0.0.3
↓
Underlay Lookup
↓
Spine Next-Hop

4. MLAG vs EVPN-MH#

MLAG 并不是错误技术；EVPN-MH 更适合统一的 EVPN Clos Fabric。

5. EVPN Route Type 最终表#

6. EVPN-MH 四大机制#

                    EVPN-MH

BUM Duplicate
→ DF Election

Same-ES Loop
→ Split Horizon

All-Active Known Unicast
→ Aliasing

Fast Failure Convergence
→ Mass Withdrawal

7. L2VNI / L3VNI#

L2VNI
= Bridge Domain
= MAC

L3VNI
= VRF
= IP Route

Symmetric IRB：

L2
↓
Routing
↓
L3VNI
↓
Remote Routing
↓
L2

8. 最终数据流#

Server01
AA / 10.10.10.11
   |
   v
Leaf01
VTEP 10.0.0.1
   |
   | EVPN already knows:
   | BB → VTEP 10.0.0.3
   |
   | VLAN10 → VNI10010
   |
   v
VXLAN Encapsulation

Outer:
10.0.0.1 → 10.0.0.3

Inner:
AA → BB
.11 → .22

   |
   v
Spine
只看 Outer IP
   |
   v
Leaf03
Decapsulation
   |
   v
Server02
BB / 10.10.10.22

9. 每种技术到底负责什么#

10. 最终 Cumulus 架构#

NVUE
├─ FRR 配置 → bgpd / zebra → Netlink
└─ 接口配置 → ifupdown2
               ↓
Linux Kernel：swp / bond / bridge / VLAN / VXLAN / VRF / FDB / Route
               ↓ 物理交换机的硬件同步路径
             switchd
               ↓
         Spectrum ASIC
               ↓
      Wire-Speed Forwarding

NVUE 同时配置 FRR 和 Linux 接口，图示表示配置/状态关系。Cumulus VX / Air 虚拟实验的转发由 Linux 软件数据平面完成，不包含真实 Spectrum ASIC 与线速硬件验证。

11. 设计顺序#

Physical Topology
↓
Underlay
↓
Overlay Service
↓
EVPN
↓
Multihoming
↓
DF / SH / Aliasing / MW
↓
Data Plane Verification

12. 排障顺序#

Physical
↓
Bond/ESI
↓
VLAN/VNI
↓
Underlay
↓
EVPN
↓
FDB/Route
↓
ASIC/Data Plane

13. 最终 5 个结论#

1. Underlay、EVPN、VXLAN 必须永远分开理解。
2. EVPN-MH 的核心不是“没有 Peerlink”，而是分布式 Multihoming Control Plane。
3. Route Type 是不同 Reachability 的表达方式。
4. 所有 EVPN 信息最终必须变成 Data Plane State。
5. 真正理解 EVPN 的标准，是能解释一个 Frame 为什么这么走。

本课核对来源（2026-10-02）：NVIDIA 5.10：EVPN Multihoming；NVIDIA 5.10：虚拟环境。