课程（6 节，按顺序学）

第 1 课 · 传统树形架构错在哪

入门 · 约 10 分钟

本课目标：先搞清楚 spine-leaf 是来解决什么问题的 —— 不然它的两条铁律看着莫名其妙。

传统三层：core / aggregation / access

这是数据中心用了十几年的架构，服务器接 access，access 上行到 aggregation，aggregation 上行到 core。

它是照着南北向流量（用户从外网访问服务器）设计的：
流量从外面进来，一层层往下走到服务器，再一层层回去。
在那个年代这没问题 —— 服务器之间基本不通信。

★ 问题一：东西向流量把它压垮了

★ 变化发生在业务架构上，不在网络上。

虚拟化、微服务、分布式存储、大数据、AI 训练 ——这些东西的共同特征是服务器之间要疯狂通信（东西向流量）。

而树形架构处理东西向流量的方式是「绕上去再绕下来」：
· 同一台 access 下 → 1 跳
· 跨 access、同汇聚 → 3 跳
· 跨汇聚，要经过核心 → 5 跳

★★ 致命的不是「5 跳比 1 跳慢」，而是延迟取决于服务器插在哪个机架。
在虚拟机可以随时迁移的年代，这是不可接受的：
同一个应用的两个实例，今天延迟很低、明天被调度走延迟翻几倍，而应用层完全不知道发生了什么。

★★ 问题二：STP 把一半带宽阻塞掉了

冗余是必须的 —— 每台 access 都双上行到两台 agg。
但那样就成环了，二层网络不能有环（广播风暴），所以必须跑 STP 破环。

★ STP 破环的方式是「阻塞」 —— 它把冗余链路关掉，只留一条转发。
那条被阻塞的链路：灯是亮的、光模块在跑、但不转发任何流量。

换成数字更直观：access 声明了 2×40G = 80G 上行，
STP 阻塞一条之后实际只有 40G 能用 →
收敛比从账面的 6:1 变成实际的 12:1，直接翻倍。

你为那条不转发的链路付了钱。

动手：把这两个问题看一遍

去架构对比页（默认已经加载了传统树形）：

① 看画布上红色虚线的链路 —— 那些就是被 STP 阻塞的，买了不能用
② 用路径查询试三对：Access1→Access2（3 跳）、Access1→Access3（5 跳）—— 跳数真的不一样
③ 看收敛比那栏：账面 6:1、实际 12:1

然后切到「标准 fabric」对比：那边所有链路都在转发，而且任意两台不同机架的服务器永远 3 跳。

实验重点

• 树形架构是照着南北向流量设计的，东西向流量把它压垮了
• ★ 致命的不是慢，是延迟取决于服务器插在哪 —— 虚机能迁移的年代不可接受
• ★★ STP 用「阻塞」破环 → 一半上行买了不能用，收敛比直接翻倍
• 扩容要动核心，而核心是最贵最难停机的设备

第 2 课 · Spine-Leaf 的两条铁律

入门 · 约 10 分钟

本课目标：整个架构就两条规则。理解它们为什么是铁律，比记住它们重要。

两条铁律

① 每台 leaf 连到每一台 spine。
② spine 之间不互连，leaf 之间也不互连。

就这两条。剩下的性质全是从它们推出来的。

★ 推论一：任意两台服务器恒定 3 跳

从两条铁律出发，两台不同机架的服务器之间只可能有一种路径形状：

Leaf → Spine → Leaf

· leaf 之间不互连 → 不能横着走
· spine 之间不互连 → 不会出现「上去两次」

★★ 所以不管 fabric 有多大（4 台 leaf 还是 400 台），跳数永远是 3。
延迟可预测 —— 这是这个架构最值钱的属性，分布式系统对延迟抖动比对绝对延迟敏感得多。

⚠️ 反过来看就明白铁律二为什么不能破：spine 一互连，就会出现 leaf→spine→spine→leaf 的 4 跳路径，恒定性就没了。

★ 推论二：上行端口数 = spine 台数

铁律一说「每台 leaf 连到每台 spine」，那么：

leaf 的上行端口数，必须等于 spine 的台数。

这不是巧合，是硬约束。它带来一个很实用的结论：
★ 在 spine-leaf 里，「加 spine」和「加上行带宽」是同一件事。

反过来，leaf 上有几个空闲上行端口，就决定了最多还能加几台 spine。买 leaf 的时候就得想好这件事。

★ 推论三：spine 端口数 = fabric 的容量上限

spine 上不接服务器，所有端口都用来接 leaf。所以：

一台 spine 有多少端口，整个 fabric 最多就有多少台 leaf。

比如 32 端口的 spine → 最多 32 台 leaf → 如果每台 leaf 有 48 个下行口，最多接 1536 台服务器。

★ 想突破这个上限，就要上 super-spine（多级 Clos） ——在 spine 上面再加一层，把多个 fabric（pod）连起来。这是超大规模数据中心的标准做法。

动手：数一下链路

去收敛比与扩容页，看下面那张画布（标准 fabric：4 spine × 6 leaf）：

① 数链路数：应该是 4 × 6 = 24 条 —— 全连接，一条不漏
② 找找有没有 spine 之间或 leaf 之间的链路 —— 应该一条都没有
③ 然后从左上角切到「违反两条铁律的接线」场景，看它报什么问题

★ 顺手试试「有 leaf 没连齐 spine」那个场景：那台 leaf 上行少一条，收敛比立刻从 3:1 变成 4:1 ——它成了整个 fabric 的短板，而症状是「只有这个机架偶发丢包」。

实验重点

• ★ 两条铁律：每台 leaf 连每台 spine；spine 之间、leaf 之间都不互连
• ★★ 推论：任意两台不同机架的服务器恒定 3 跳，延迟可预测
• 推论：leaf 上行端口数 = spine 台数 → 加 spine 就是加带宽
• 推论：spine 端口数 = 最多几台 leaf → 决定 fabric 的容量上限

第 3 课 · ★ 超额订阅比（本模块核心）

进阶 · 约 16 分钟

本课目标：数据中心设计里最实用的一个数字。它一句话决定这个 fabric 能不能上线。

怎么算

超额订阅比 = leaf 的下行总带宽 ÷ 上行总带宽

拿现网最常见的配置算一遍：

下行：48 × 25G  = 1200G   （接服务器）
上行： 4 × 100G =  400G   （接 spine）
比值：1200 ÷ 400 = 3:1

含义是：如果这个机架的 48 台服务器同时打满网卡，上行只能承载其中 1/3。

为什么允许超额订阅

听起来像设计缺陷，其实是故意的，而且合理：

★ 依据是一个统计事实：服务器不会同时打满网卡。
而且大部分流量是机架内部消化的（同一个应用的实例往往放在一起）。

所以超额订阅的本质是用统计复用换成本 —— 和电话网络、宽带接入是同一个道理。
做到 1:1 无阻塞当然最安全，但上行端口和 spine 数量都要翻几倍，通用业务这么花钱是浪费。

★ 各档位分别适合什么业务

1:1    无阻塞     HPC / AI 训练 / 分布式存储
≤ 3:1  健康       ★ 通用服务器区的主流取值
≤ 6:1  可接受     Web / 应用服务器区，但要盯监控
> 6:1  有风险     只在确定东西向流量小的时候
≥ 10:1 不可接受   ★ 这不是设计，是事故等待发生

★★ 为什么 AI / HPC 必须 1:1：那些任务的东西向流量又大又同步（所有节点同时交换梯度），一旦某条链路拥塞，最慢的那个节点会拖住整批任务 —— 统计复用的假设不成立了。

★ 而 ≥ 10:1 最难查的地方在于症状：不是「一直慢」，而是随机的、间歇性的延迟抖动和丢包。
运维会先怀疑应用、怀疑服务器网卡，最后才想到是 fabric 收敛比。

★ 理论比 vs 真实比：按哪个规划

机架里现在只插了 24 台服务器，那当前的真实比值只有 1.5:1，很健康。
但端口插满（48 台）之后就是 3:1。

★★ 设计必须按理论比（满配）来。
因为服务器是会加的 —— 按当前真实比规划，等机架插满就超了，而那时候要改的是布线和上行端口，代价大得多。

页面上两个数字都会显示，注意区分。

动手：算一遍，再看失控的样子

去超额订阅与扩容页：

① 看标准 fabric 每台 leaf 的比值 —— 应该是 3:1，健康
② 切到「收敛比失控（15:1）」场景 —— 48×25G 下行只配了 2×40G 上行，看健康度怎么判红
③ 再切到「无阻塞 fabric」—— 看 1:1 的代价（8 台 spine、上行 400G）

★ 最后回到标准 fabric，把某台 leaf 的一条上行改成 down，看它的实际比值立刻从 3:1 变成 4:1 —— 木桶效应。

实验重点

• ★ 超额订阅比 = 下行总带宽 ÷ 上行总带宽
• 它是故意的：用统计复用换成本
• ★ ≤3:1 通用业务主流；1:1 给 AI/HPC；≥10:1 不可接受
• ★★ 设计按理论比（满配）算，不能按当前真实比
• 看最差的那台 leaf，不看平均 —— 木桶效应

第 4 课 · ★★ 加 spine 还是加 leaf

进阶 · 约 12 分钟

本课目标：这个模块最实用的一课。两者正交，搞混了钱就白花。

★★ 两件正交的事

缺带宽（比值太高）  →  加 spine
缺容量（端口插满）  →  加 leaf

加 spine 发生了什么：每台 leaf 多一个上行 →
上行总带宽变大 → 比值变小。服务器容量不变。

加 leaf 发生了什么：多一个机架 →
能接更多服务器。比值完全不变。

★★★ 「加 leaf 不改善收敛比」—— 最反直觉的一条

很多人的直觉是「设备加多了就不挤了」。错。

新加的 leaf 上下行配比和老的一样（48×25G 下行、4×100G 上行），所以它自己的比值也是 3:1。

★ 结果是：你只是让更多服务器平摊同一个拥塞比，而不是让原来的拥塞缓解了。

反过来说，如果当前比值已经很糟（比如 15:1），先加 leaf 只会让受影响的服务器更多 ——
必须先加 spine 把比值压下来。

★ 第三个选项常常最划算：上行升速

不加任何设备，把上行从 100G 换成 400G：
端口数不变（还是 4 个），但上行带宽从 400G 变成 1600G →
比值从 3:1 变成 0.75:1。

★ 为什么常常最划算：省掉了新 spine 的机位、电力、和端口占用。
而且 40G→100G 这一档常常只要换光模块 —— QSFP 笼子是通用的。

⚠️ 前提是 leaf 和 spine 两端都支持那个速率。

动手：把三个方案的数字并排看

去超额订阅与扩容页，右边有个「扩容方案对比」表，四行并排：当前 / 加 1 台 spine / 加 1 台 leaf / 上行升速。

★★ 重点看「加 1 台 leaf」那一行的比值列 —— 它和当前方案完全一样。这一眼比看十遍文字有用。

然后真的点「加一台 spine」按钮，看：
· 链路数从 24 变成 30（新 spine 连到每台 leaf）
· 每台 leaf 上行从 400G 变成 500G
· 比值从 3:1 变成 2.4:1

★ 扩到 spine 端口用完怎么办

spine 有 32 个端口 → 最多 32 台 leaf。插满之后想再扩，只有两条路：

① 换端口更多的 spine —— 简单，但要换设备
② 上 super-spine（多级 Clos） —— 在 spine 上面再加一层，把多个 fabric（pod）连起来

★ 超大规模数据中心走的是第二条：一个 pod 就是一套 spine-leaf，pod 之间靠 super-spine 互连。
代价是跨 pod 变成 5 跳（leaf→spine→super-spine→spine→leaf）——所以设计上会尽量把互相通信的业务放在同一个 pod 内。

实验重点

• ★★ 加 spine 治拥塞（比值变小），加 leaf 治容量（比值不变）
• ★★★ 加 leaf 不会改善收敛比 —— 只是让更多服务器平摊同一个比值
• ★ 上行升速常常最划算：不加设备、可能只换光模块
• spine 端口用完 → 换 spine 或上 super-spine（跨 pod 变 5 跳）

第 5 课 · ★★ ECMP 和大象流

排障 · 约 14 分钟

本课目标：spine-leaf 的全部带宽优势都建立在 ECMP 上。而它唯一真正的痛点也在这。

ECMP 取代了 STP

树形架构用 STP 破环（阻塞一半链路）；
spine-leaf 用 L3 + ECMP —— 所有链路同时转发。

★ 这是它能把带宽全用上的根本原因，也是它必须是 L3 fabric 的原因：ECMP 是三层的能力，二层做不到（二层只能靠 STP 或者 MC-LAG 这类补丁）。

★ 最讽刺的一种错误：买了 4 台 spine，只有 1 台在干活

ECMP 不是自动生效的，尤其是 eBGP underlay：

★ BGP 默认只选一条最优路径。
maximum-paths 不配，就等于没有 ECMP → 多条上行里只有一条转发。

而且 eBGP 还有第二个坑：它默认按 AS_PATH 严格比较，不同 AS 号的等价路径不会被采纳 →
通常还要 bestpath as-path multipath-relax。

⚠️ 这个错误的症状很温和：网络是通的、监控是绿的，只是带宽只有设计的 1/4，而且你不去查根本不会发现。

★★ 大象流：ECMP 唯一真正的痛点

ECMP 是按流哈希的（五元组：源/目的 IP + 源/目的端口 + 协议）。

★ 而一条 TCP 连接的五元组是固定的 →
这条流一辈子只走一条上行，永远用不到别的链路。

所以两台服务器之间做大文件传输（备份、数据同步、模型 checkpoint），只能跑到 1/4 的上行带宽 —— 哪怕 fabric 总带宽空着一大半。

★★ 这不是配置错误，是 ECMP 的工作原理决定的。
而且它会造成很奇怪的现象：某条链路打满在丢包，别的链路利用率 5% ——「总带宽够，但流量走不过去」，这话很难跟业务方解释。

三条真实的应对办法

① 应用层拆多连接 —— 最有效，而且不依赖网络设备。
　分布式存储（Ceph、HDFS）普遍这么做：一个传输任务开 8 个 TCP 连接，五元组不同 → 哈希到不同链路。

② Flowlet / 动态负载均衡 —— 芯片级方案。把大流切成片段（利用 TCP 天然的突发间隙），不同片段走不同链路。
　各家叫法不同：DLB、Adaptive Routing、Conga。
　⚠️ 代价是报文可能乱序，开之前要确认业务能接受。

③ 把上行速率提上去 —— 单条链路够粗，一条大流也跑得下。简单但花钱。

动手：把大象流跑出来

去 ECMP 与流量分担页：

① 先跑 50 条普通流、0 条大象流 —— 分担挺均匀
② 再跑 10 条普通流 + 3 条大象流 —— ★ 看不均衡度飙到 100% 以上，某条链路打满而另一条只有 5%
③ 把哈希模式换成 Flowlet，同样的流再跑一次 —— 不均衡度掉回个位数

★ 顺手切到「买了 4 台 spine 只有 1 台干活」那个场景，看等价路径数怎么从 4 变成 1。

实验重点

• ★ ECMP 取代 STP，所有链路同时转发 —— 这要求 fabric 是 L3 的
• ★★ eBGP 默认只选一条路径！maximum-paths 不配等于没有 ECMP
• ★★★ 大象流：一条 TCP 连接的五元组固定 → 只走一条链路
• 症状很怪：某条链路打满丢包，别的链路 5% —— 「总带宽够但走不过去」
• 解法：应用层拆多连接（最有效）/ Flowlet（会乱序）/ 上行升速

第 6 课 · 为什么还要 VXLAN + EVPN

进阶 · 约 12 分钟

本课目标：fabric 是纯 L3 的，可虚机迁移需要 L2 可达 —— 这个矛盾怎么解。

★ 矛盾在哪

前面说了：spine-leaf 必须是 L3 fabric，因为 ECMP 是三层的能力。

可业务有个硬需求：虚拟机迁移的时候 IP 不能变。
而 IP 不变就意味着迁移前后必须在同一个二层域里 ——
也就是说业务需要 L2 可达。

★★ 一个纯 L3 的网络，要给业务提供 L2 —— 这就是 overlay 存在的理由。

VXLAN：把二层帧塞进 UDP 包里

做法很直接：把整个以太网帧当成数据，塞进一个 UDP 报文（目的端口 4789），在 L3 网络上正常路由过去，到对端再拆出来。

外层：IP（leaf A → leaf B）+ UDP(4789) + VXLAN 头
内层：原始的以太网帧（虚机 A → 虚机 B）

· 封装/解封装在 leaf 上做，这个角色叫 VTEP
· spine 完全不知道 VXLAN 的存在 —— 它只看外层 IP 做 ECMP
★ 这一点很重要：spine 保持简单，所有复杂度收敛在 leaf 上
· VNI（24 bit）取代 VLAN ID → 从 4096 个扩展到 1600 万个

★ EVPN：VXLAN 的控制平面

光有 VXLAN 只解决了「怎么封装」，还有个问题：
leaf A 怎么知道某个 MAC 在 leaf B 后面？

早期方案是组播泛洪（用组播学 MAC）—— 能用但很脏：依赖组播、泛洪流量大、规模上不去。

★ EVPN 的做法是：用 BGP 来分发 MAC 地址。
（BGP 的一种新地址族，叫 EVPN NLRI）

好处：
· 不用组播了，靠 BGP 精确通告
· 能通告 MAC + IP 的绑定 → 可以做 ARP 抑制（本地代答，不泛洪）
· 支持多归属（一台服务器接两台 leaf，ESI 标识）

★ 顺带说一句：这就是为什么 fabric 的 underlay 也用 BGP ——一套协议既做 underlay 又做 overlay，运维只学一样东西。

★ 现网的标准组合

underlay：eBGP（每台设备一个私有 AS）+ ECMP
overlay ：VXLAN 数据平面 + EVPN 控制平面

为什么 underlay 用 eBGP 而不是 OSPF / IS-IS（RFC 7938）：
· AS_PATH 天然防环，路径长度直接反映跳数
· 策略控制粒度细 —— 想让某台 leaf 停止转发，一条 policy 就行
· 行为可预测，没有「一条链路抖动触发全网 SPF 重算」
· 配置高度模板化，适合自动化生成 ——在几百台设备的规模下这一点是决定性的

★ 可以对照本产品的 eBGP 模块看：那里学的 AS_PATH、选路规则、maximum-paths，在这里全都用得上。

动手：看配置长什么样

去真机配置页，看 leaf 的配置分成三段：

① underlay：接口 IP + eBGP + maximum-paths
② overlay：VXLAN VTEP + EVPN 地址族
③ 业务：VNI 和 VLAN 的映射

★ 重点看 spine 的配置有多短 —— 它只做 underlay，不碰 VXLAN、不碰业务。所有复杂度都在 leaf 上。

实验重点

• ★ 矛盾：fabric 必须 L3（为了 ECMP），业务需要 L2（为了虚机迁移）
• VXLAN：把二层帧塞进 UDP(4789)。VTEP 在 leaf 上，spine 完全不感知
• VNI 24 bit → 1600 万个，取代 VLAN 的 4096
• ★ EVPN：用 BGP 分发 MAC，取代组播泛洪；顺带支持 ARP 抑制和多归属
• ★ 现网标准组合：eBGP underlay + VXLAN/EVPN overlay（RFC 7938）