第 2 周：Ethernet、IP、交换机和 ECMP 基础
对应原计划：
plans/muxi-fabric-network-learning-plan.md第 2 周。
相关工程假设：plans/muxi-fabric-probe.md的 H6 和 W3 ECMP 熵扫描。
相关结论：project/lab-workspace/reports/rounds/muxi_topology_facts_20260719_102558.md。
本章定位：作为整套手册的样板章。目标不是列网络名词，而是让你能用 Ethernet/IP/Clos/ECMP 的心智模型理解 Muxi pair matrix、rail、incast 和拓扑不可辨识性。
0. 这一周到底学什么
这一周的核心目标不是学“网络基础知识大全”，而是为了回答 Muxi fabric 探测里的一个关键问题：
当两个 GPU 节点之间通信变慢时，数据包在交换网络里到底可能走了什么路径？
我们能从端到端带宽、RTT、traceroute、IP、端口、rail 信息里推断出什么？又不能推断出什么？
这周学完之后，你应该能和 agent 讨论这些问题：
- 为什么
traceroute看不到 leaf/spine，并不代表没有经过交换机？ - 为什么两台机器互通，不等于它们物理上在同一个 leaf？
- 为什么 4 个 rail 在不同 IP 子网，不等于一定是 4 个物理独立交换平面？
- 为什么 ECMP 有多条路径，但少量大流仍然可能撞到同一条路径？
- 为什么
pair matrix有块结构，不能直接命名 leaf/spine？ - 为什么“跨组带宽减半”，不能单独证明 2:1 超分？
- 为什么“多 QP 后变快”，只能支持 ECMP 熵相关，不能直接证明 UDP 源端口进了 hash？
这一周有一个总原则：
端点看到的是行为；网络组掌握的是物理；控制面暴露的是逻辑。
三者相关，但不能互相替代。1. 先建立一张心智图
你可以先把一次跨节点通信想成这样：
GPU buffer
↓
通信库 MCCL/NCCL
↓
RNIC / HCA / xscale
↓
RoCEv2 packet
↓
服务器网卡端口
↓
leaf switch
↓
spine switch
↓
另一个 leaf switch
↓
目标服务器网卡端口
↓
目标 GPU第 2 周只关注中间这一段：
服务器网卡
↓
Ethernet / IP / UDP / RoCEv2 header
↓
leaf / spine 交换机
↓
ECMP 路径选择
↓
queue / buffer / scheduler
↓
目标网卡这里最重要的不是背字段，而是知道：
- 哪些字段用于“找到下一跳”；
- 哪些字段用于“做 ECMP hash”；
- 哪些字段用于“QoS 分类”；
- 哪些地方会排队；
- 哪些现象会让你误判拓扑。
你要一直分清三种拓扑：
逻辑拓扑：IP、subnet、route、CNI annotation、Kubernetes label
物理拓扑：host rail → switch chassis/port → leaf/spine → cable
行为拓扑：pair bandwidth、RTT、incast、rail A/B、复测稳定性Muxi 当前主要掌握的是逻辑拓扑的一部分和行为拓扑的一部分；物理拓扑的关键锚点仍缺失。
2. MAC、IP、GID：三个地址不是一回事
2.1 MAC 是什么
MAC 地址是二层地址，主要在一个二层广播域里用。
你可以粗略理解为：
MAC = 这块网卡在当前二层网络里的门牌号交换机根据 MAC 表转发 Ethernet frame：
目的 MAC 是 A → 从端口 3 发出去
目的 MAC 是 B → 从端口 7 发出去但是 MAC 不表达“跨多个三层网络怎么走”。它更像局部网络里的下一跳地址。
2.2 IP 是什么
IP 地址是三层地址，用来表达网络层位置和路由选择。
比如：
10.0.1.12/24
10.0.2.34/24如果两个地址在同一个子网，主机会认为可以直接二层到达：
同子网：
源主机 → ARP/邻居发现 → 得到目标 MAC → 直接发 Ethernet frame如果不在同一个子网，主机会发给网关：
跨子网：
源主机 → 发给默认网关 MAC → 网关/三层交换机继续路由2.3 GID 是什么
在 RoCE 语境里，GID 可以理解成 RDMA/RoCE 使用的全局地址标识。RoCEv2 通常跑在 IP/UDP 上，所以 GID 往往和 IP 地址、网卡端口、GID index 相关。
在 Muxi 计划里，当前使用 GID index 5。你不需要在第 2 周完全掌握 GID table，但要知道：GID 属于 RDMA/RoCE 端点识别，不等于普通 IP，也不等于 MAC。
你可以这样记：
MAC：本地二层下一跳怎么转发
IP：三层网络怎么寻址/路由
GID：RDMA/RoCE 端点怎么被识别它们不能混用。
2.4 小 case：为什么 IP 相同子网不等于物理同 leaf
假设有四台机器：
host A: 10.1.0.1
host B: 10.1.0.2
host C: 10.1.0.3
host D: 10.1.0.4它们都在 10.1.0.0/24。
你可能会直觉认为：
同子网 = 同一个交换机 = 路径短但这不一定对。
在数据中心里，同一个二层/三层逻辑网络可以跨多个 leaf。底层可能是：
A 接 leaf 1
B 接 leaf 1
C 接 leaf 2
D 接 leaf 2
leaf 1 和 leaf 2 通过 spine 互联所以同子网只能说明：
它们属于同一个逻辑网络 / 广播域 / overlay / routed domain不能说明：
它们接在同一台 leaf；
它们之间不经过 spine；
它们路径一定短；
它们带宽一定高。这就是为什么 Muxi 拓扑事实报告强调：四个 rail 的 IP 子网可以说明逻辑隔离，但不能证明四个物理独立交换平面。
3. L2 switch、L3 router、traceroute：为什么看不到交换机
3.1 L2 交换机怎么转发
L2 switch 看 Ethernet header：
src MAC
dst MAC
VLAN tag
EtherType它主要做：
查 MAC 表 → 决定从哪个端口发出去它不会像路由器那样减少 IP TTL。
所以如果数据包经过了很多 L2 交换机，traceroute 通常也不会显示它们。
3.2 L3 路由器怎么转发
L3 router / 三层交换机会看 IP header：
src IP
dst IP
TTL
DSCP/ECN
protocol它转发时会让 TTL 减 1。
traceroute 依赖 TTL 递增：
TTL=1 → 第一跳三层设备回 ICMP
TTL=2 → 第二跳三层设备回 ICMP
TTL=3 → 第三跳三层设备回 ICMP所以它能看到的是 L3 hop，不是所有物理交换机。
3.3 小 case：为什么 traceroute 只有 1 跳，但实际经过 leaf-spine
假设两个节点在同一个二层网络里：
host A
↓
leaf 1
↓
spine
↓
leaf 2
↓
host B如果中间交换机只做 L2 转发，IP TTL 不会减少。
那么 traceroute A → B 可能看起来像：
1 host B你不能因此说：
A 和 B 中间没有交换机你只能说：
中间没有暴露为 TTL hop 的三层设备3.4 这个结论对 Muxi 有什么用
如果你在 Muxi 里做：
traceroute nodeA_rail0_ip nodeB_rail0_ip看到路径很短，不能直接写：
nodeA 和 nodeB 物理近；
中间没有 spine；
这两个节点同 leaf。正确写法应该是：
端点可达；路径中没有暴露为 TTL hop 的三层设备；
物理 leaf/spine 信息仍需要 LLDP、配线表、交换机端口 counter 或网络组 ground truth。4. Leaf-Spine / Clos：数据中心网络为什么长这样
4.1 最小 leaf-spine
一个简单的 2 leaf × 2 spine：
spine 1 spine 2
| |
----+--------------+----
| |
leaf 1 leaf 2
/ | \ / | \
h1 h2 h3 h4 h5 h6每台服务器接一个 leaf。
leaf 之间不直接互联，跨 leaf 流量一般经过 spine：
h1 → leaf1 → spine1 或 spine2 → leaf2 → h44.2 为什么需要 spine
如果所有 leaf 之间两两互联，规模大了会爆炸。
Clos / fat-tree 的思路是：
下层 leaf 接服务器；
上层 spine 提供横向带宽；
leaf 到 spine 有多条等价路径。好处：
- 容易扩展；
- 多路径；
- 任意 leaf 到任意 leaf 路径长度相对固定；
- 可以通过增加 spine 提升横向带宽。
4.3 bisection bandwidth 是什么
你可以把集群切成左右两半：
左边 32 台机器 | 右边 32 台机器如果左边所有机器同时和右边通信，跨越这条“切割线”的总带宽就是 bisection bandwidth 关心的东西。
如果服务器总注入能力是：
64 台 × 每台 800Gb/s = 51200Gb/s但中间 spine 可承载的横向带宽只有一半，那么就有超分或横向瓶颈。
4.4 oversubscription 是什么
超分可以理解成：
下行服务器总带宽 : 上行网络总带宽例如一个 leaf：
8 个服务器端口，每个 200G
4 个上行端口，每个 200G那么：
下行总带宽 = 8 × 200G = 1600G
上行总带宽 = 4 × 200G = 800G
超分比 = 1600 : 800 = 2 : 1这意味着：
如果所有服务器都向 leaf 外部打满，leaf 上行不够。但注意，这不是说任何一对 pair 都只有一半带宽。超分是聚合层面的容量关系。
4.5 小 case：为什么“跨组带宽减半”不能直接证明 2:1 超分
假设你看到：
组内 pair: 24GB/s
跨组 pair: 12GB/s你可能想说：
跨组少一半，所以物理超分 2:1。但可能原因很多：
- ECMP 两条 flow 撞同一条 path；
- 接收端 rail 没用满；
- MCCL/QP/channel 映射不同；
- 背景流量占了某个上行；
- PFC/ECN 让发送端降速；
- 测量时同步点造成 tail rank 等待；
- 真实物理确实 2:1 超分。
所以这个现象只能说：
支持“跨组路径存在共享容量瓶颈”的假设。不能直接说：
物理超分比就是 2:1。工程计划里也明确写了这个限制：多 QP 后更快不能单独证明 UDP 源端口参与哈希，跨组带宽减半不能单独证明物理超分比是 2:1。
5. ECMP：多路径不是自动平均
5.1 ECMP 是什么
ECMP = Equal-Cost Multi-Path。
意思是：从一个交换机到目的地，有多条代价相同的下一跳。
比如：
leaf 1 到 leaf 2 可以走：
leaf1 → spine1 → leaf2
leaf1 → spine2 → leaf2
leaf1 → spine3 → leaf2
leaf1 → spine4 → leaf2这些路径在路由意义上等价。
5.2 为什么不逐 packet 随机
如果每个 packet 随机选路径，可能出现乱序：
packet 1 走 spine1，很快到
packet 2 走 spine2，排队慢
packet 3 走 spine3，很快到接收端看到：
1, 3, 2对 TCP/RDMA 这类协议会带来问题。
所以常见做法是 flow-based ECMP：
同一条 flow → hash 到同一条 path这样同一 flow 内基本不乱序。
5.3 hash 用哪些字段
具体厂商不同，但常见可能包括：
src IP
dst IP
L4 protocol
src port
dst port
IPv6 flow label
RoCE UDP source portRoCEv2 是 IP/UDP 封装，所以 UDP 端口有机会参与 hash。
但你不能默认某个字段一定参与，必须看交换机配置、厂商实现或抓包/计数器验证。
5.4 小 case：4 条大流散到 4 条 path，为什么仍然可能不均
假设有 4 条 ECMP path：
path A
path B
path C
path D也有 4 条大象流：
flow 1
flow 2
flow 3
flow 4理想情况：
flow1 → A
flow2 → B
flow3 → C
flow4 → D每条 path 一条流，很均衡。
但 hash 可能得到：
flow1 → A
flow2 → A
flow3 → C
flow4 → C这时：
A 有 2 条流
B 有 0 条流
C 有 2 条流
D 有 0 条流即使有 4 条等价路径，也只有 2 条被用了。
如果每条流都很大，就会出现：
有些路径拥塞；
有些路径空闲；
端到端带宽下降。这就是“多条等价路径不等于自动均匀”的核心。
5.5 小 case：16 条小流为什么比 4 条大流更容易均匀
还是 4 条 path。
如果只有 4 条流，随机 hash 很容易偏。
如果有 16 条流，分布可能更接近：
A: 5
B: 4
C: 3
D: 4相对均匀。
所以增加 QP / 增加 flow entropy 有时会让带宽变好。
但这只能说明：
路径选择 / flow hashing 可能参与了性能差异。不能直接说明：
UDP 源端口一定进了 hash；
物理上一定有 N 条 ECMP path；
交换机一定是 ECMP 碰撞根因。5.6 进阶：多级 ECMP 的“组合路径数”不等于有效路径数
在 Clos 里，路径可能是多级组合。
比如：
leaf → spine → leaf如果有 4 个 spine，理论上有 4 条中间路径。
但真实有效路径数还取决于：
ECMP group 里实际有几个 next-hop；
某些链路是否 down；
hash 字段是否有足够熵；
流量是否集中在少量大象流；
上游/下游是否还有其他 ECMP；
rail 是否独立；
QoS 是否把流量压到同一个 queue。所以：
物理有 N 条路径 ≠ 当前 workload 有效使用 N 条路径。这句话非常重要。
Muxi 上即使网络组告诉你：
每个 leaf 到 spine 有 8 条 uplink你仍然要问：
当前 RoCE flow 的 hash entropy 能不能打散到这些 uplink？
每个 rail 的 ECMP group 是一样的吗？
QP 数是否足够？
UDP source port 是否变化？
是否有固定 hash seed 或 polarization？
交换机是否有 per-flowlet/per-packet 机制？这就是为什么“拓扑图 + workload 行为”必须一起看。
6. Queue / Buffer / Scheduler：交换机不是透明网线
很多人会把交换机想成：
输入线 → 输出线但真实交换机会有 pipeline：
ingress port
↓
parser
↓
classifier
↓
lookup
↓
buffer
↓
queue
↓
scheduler
↓
egress port6.1 ingress queue
入口侧可能排队，尤其是多个输入同时进来，内部资源竞争。
6.2 egress queue
更常见的问题是 egress 方向：
多个 ingress port 的流量都要从同一个 egress port 出去例如：
host1 ┐
host2 ├→ leaf → target host
host3 ┘如果 target host 的出端口是 200G，而输入总量是 600G，就会在 egress queue 堆积。
6.3 shared buffer
交换机通常不是每个端口固定一块 buffer，而是有 shared buffer 池。
当多个队列同时拥塞，shared buffer 会被抢。
这会导致：
一个热点流量影响其他看似无关的流量。6.4 scheduler
如果不同优先级、不同 queue 共享一个出口，scheduler 决定谁先发。
例如：
queue 0: 普通 TCP
queue 3: RoCE
queue 6: 控制流量如果 QoS 配置不对，RoCE 可能没有得到预期优先级，或者 PFC/ECN 作用在错误队列。
这部分和第 5 周的 PFC/ECN/DCQCN 会接上。
7. 用 Muxi 现象理解这一周
Muxi 当前有几个重要事实：
- 64 节点 × 8 卡 = 512 卡。
- 每节点 4 × 200G xscale RoCEv2。
- 跨机单流和多组互不相交 pair 可以到约 23～24GB/s。
- 7→1、15→1 incast 的聚合入口约 24.2GB/s。
- 4 rail 比 1 rail 快，但没有 4 倍线性收益。
- W2 做了 2016 pair 矩阵，但没有得到稳定物理拓扑聚类。
- 最差 pair 复测恢复，固定坏 pair 被反证。
- 交换机 QoS/ECMP/PFC/ECN 没有 counter 闭环，所以不能下强结论。
这些事实怎么和第 2 周关联？
7.1 单流 23～24GB/s 说明什么
200Gb/s 物理口理论大概是：
200Gb/s ÷ 8 = 25GB/s考虑协议开销，23～24GB/s 是合理量级。
所以单流能到这个水平，说明：
至少某些端到端路径可以接近单 200G rail 的有效上限。但它不能说明：
所有 path 都健康；
多流不会拥塞；
交换机没有问题；
所有 rail 都均匀使用。7.2 incast 聚合入口约 24.2GB/s 说明什么
假设多个发送者打到同一个接收 GPU/rail：
sender1 ┐
sender2 ├→ receiver rail
sender3 ┘如果接收侧实际只有一个 200G 入口在承接，聚合上限接近 24GB/s 是合理的。
这说明：
单 GPU / 单 rail 接收入口可能是瓶颈。但它不能说明：
整个机器只有 24GB/s；
整个 fabric 只有 24GB/s；
交换机一定拥塞；
PFC 一定触发。因为整机多 rail、多 GPU 的聚合能力是另一个层级。
7.3 2016 pair matrix 为什么不能反推出 leaf/spine
拓扑事实报告总结了五个原因：
- ECMP 多路径：同一个 pair 不保证每次走同一路径；
- 对称性：Clos 里很多路径同构，带宽/时延看起来一样；
- 四 rail 并行：一个矩阵点是多 rail/多机制叠加结果；
- 缺直连锚点：没有 LLDP/交换机端口 counter，没法对齐 chassis/port；
- 复测恢复：慢 pair 不稳定，说明噪声/间歇拥塞大于稳定拓扑割。
所以 pair matrix 最多支持：
行为分组；
异常候选；
亲和关系；
共享瓶颈假设。不能直接输出：
host A 和 host B 在同一个 leaf；
host C 必经 spine X；
这个 block 就是 rack；
这个 cut 就是 2:1 超分。8. 本周最重要的辨析
8.1 逻辑拓扑 vs 物理拓扑 vs 行为拓扑
这三个必须分开。
逻辑拓扑
例如：
rail0: 10.0.0.0/24
rail1: 10.0.1.0/24
rail2: 10.0.2.0/24
rail3: 10.0.3.0/24它说明 IP / 子网 / 路由层面怎么组织。
但不保证物理独立。
物理拓扑
例如：
host17 xscale_0 → leaf-a port 21
host17 xscale_1 → leaf-b port 19
leaf-a → spine-3 port 7这需要 LLDP、配线表、交换机端口信息、网络组 ground truth。
行为拓扑
例如：
这些 host pair 带宽高；
这些 pair 在某些时段一起变慢；
这些 rail 掩码下 p50/p99 差异明显；
这个干扰 pair 会影响目标 pair。行为拓扑来自实验，但不能自动命名物理设备。
8.2 相关性 vs 干预证据 vs ground truth
相关性
A-B 慢，C-D 也慢。只能说现象一起出现。
干预证据
固定 A-B，加入 C-D 干扰后 A-B 变慢；
换成负对照 E-F 后 A-B 不变。这更支持共享瓶颈。
ground truth
交换机 counter 显示 A-B 和 C-D 同时经过 leaf-7 uplink-3，
该口 queue occupancy / ECN / drop 在实验窗口升高。这才接近机制闭环。
8.3 带宽下降不是一种机制
看到带宽下降，至少可能是：
ECMP 碰撞；
上行超分；
egress queue 拥塞；
shared buffer 被占；
PFC pause 扩散；
ECN/CNP 降速；
MCCL channel/QP 选择；
GPU↔NIC 亲和不佳；
接收端单 rail 瓶颈；
测量同步导致慢 rank 拖累；
背景流量；
间歇链路错误。所以不能从一个现象直接跳到一个机制。
9. 推荐阅读提炼
这一周原来列了四个推荐阅读：
- RFC 2992：ECMP 算法分析；
- Fat-Tree：用 commodity switch 搭可扩展数据中心网络；
- VL2：可扩展、灵活的数据中心网络；
- Jupiter Rising：Google 十年 Clos 网络和集中式控制经验。
它们不是让你“从头精读网络论文”，而是分别补四块心智模型：
RFC 2992 → ECMP 怎么把 flow 映射到 path
Fat-Tree → 为什么 leaf-spine/Clos 能提供多路径和高 bisection
VL2 → 为什么逻辑地址/服务位置可以和物理位置解耦
Jupiter → 真实大规模数据中心为什么需要拓扑 ground truth 和集中控制9.1 RFC 2992：ECMP 不是“平均分流”，而是“hash 到某个 next-hop”
这篇文档讲什么
RFC 2992 分析的是一种 ECMP next-hop 选择算法。它关心的问题是：当路由器/交换机面对多个等价 next-hop 时，怎么从 packet/flow 的 key 里算出应该走哪一条 next-hop。
文档特别讨论 hash-threshold 这类方法：先对能代表 flow 的字段做 hash，再把 hash 空间切成若干区域，每个区域对应一个 next-hop。它还关注路径集合变化时的 disruption，也就是 flow 被重新映射到其他路径的比例。
你只需要抓住的问题
ECMP 为什么不是自动平均？
为什么少量大象流会撞路径？
为什么路径集合变化会影响现有 flow？关键知识点 1：ECMP 的单位通常是 flow，不是 packet
你可以先想象交换机有 4 条等价路径：
path0, path1, path2, path3它不会对每个 packet 做：
packet1 → path0
packet2 → path1
packet3 → path2
packet4 → path3因为这样容易乱序。
更常见的是：
flow key = hash(src_ip, dst_ip, protocol, src_port, dst_port, ...)
path = hash(flow key) mod N所以一条 flow 通常固定走一条 path。
对 RoCEv2 来说，报文跑在 IP/UDP 上，因此 UDP 端口、IP 地址等字段可能影响 hash。但“可能影响”不等于“必然影响”，这个要看交换机配置和实现。
关键知识点 2：hash 空间均匀，不等于当前流量均匀
假设 hash 算法理论上均匀：
25% hash 值 → path0
25% hash 值 → path1
25% hash 值 → path2
25% hash 值 → path3这只能说明：
如果有大量独立 flow，长期看可能均匀。但如果你只有 4 条大象流：
flow A, flow B, flow C, flow D一次 hash 结果可能是：
flow A → path0
flow B → path0
flow C → path2
flow D → path2这时：
path0: 2 条大流
path1: 0 条
path2: 2 条大流
path3: 0 条所以网络有 4 条路径，但有效用了 2 条。
关键知识点 3：路径集合变化会导致 flow 重新映射
如果 next-hop 数量从 4 变成 3，或者某条链路故障，原来的 hash 区域会重分配，一部分 flow 会换路径。
这对我们有一个启发：
如果某次实验中某些交换机链路状态、ECMP group、路由表、端口状态变化了，
同样的 pair 可能不再走同样的物理路径。所以 pair matrix 不是稳定物理图，而是某个时间窗口里的行为观测。
用 Muxi case 理解
如果我们在 Muxi 上做实验：
固定 src/dst host
固定 rail
固定 message size
改变 QP 数：1 / 2 / 4 / 8然后发现：
1 QP 慢
8 QP 快这支持一个假设：
增加 flow entropy 可能改善了 ECMP path 分布。但它不能直接证明：
UDP source port 一定参与 hash；
共有 8 条 ECMP path；
慢就是 ECMP 碰撞；
交换机就是根因。因为也可能是 MCCL/RDMA 层的 QP 并发、发送队列、RNIC 调度、接收端处理发生了变化。
不能照搬的地方
RFC 2992 告诉你 ECMP 算法思想，但不告诉你当前 H3C 交换机：
实际 hash 字段是什么；
是否包含 UDP source port；
是否包含 IPv6 flow label；
是否按 inner/outer header hash；
ECMP group 里有几个 next-hop；
hash seed 是否固定；
是否存在 polarization。这些必须靠网络组配置、交换机命令、端口 bytes、抓包和实验对齐。
9.2 Fat-Tree：为什么 leaf-spine 能扩展，以及什么叫 full bisection
这篇论文讲什么
Fat-Tree 论文的背景是：传统数据中心网络往往越往上层越依赖昂贵的大交换机/路由器，而且上层带宽可能只能支持边缘总带宽的一部分。
Fat-Tree 的核心思想是用大量便宜的 commodity Ethernet switch 组织成类似 Clos/fat-tree 的结构，从而在成本可控的情况下获得高聚合带宽和多路径能力。
你只需要抓住的问题
为什么数据中心网络不是一棵简单树？
为什么要 leaf-spine/Clos？
为什么 collective 会关心 bisection？简单树的问题
假设网络是这样：
core
/ \
agg1 agg2
/ \ / \
leaf leaf leaf leaf如果越往上链路越少，就会出现：
底下服务器总带宽很大；
上层 core/agg 承载不了所有跨组流量；
跨组通信时容易超分。这对 AI collective 特别敏感，因为 AllReduce 不是少量随机请求，而是很多 rank 同步、大消息、周期性地一起通信。
Fat-Tree / Clos 的关键思想
Clos/fat-tree 想解决的是：
让横向通信有多条等价路径；
让网络 bisection bandwidth 尽可能高；
用多台便宜设备替代少数昂贵大盒子。典型结构：
spine0 spine1 spine2 spine3
| | | |
----+-----------+-----------+-----------+----
| |
leaf0 leaf1 leaf2
/ | \ / | \ / | \
h0 h1 h2 h3 h4 h5 h6 h7 h8跨 leaf 的流量可以走多个 spine。
full bisection 是什么
假设把所有服务器分成左右两半：
左半集群 | 右半集群如果左边所有服务器同时向右边通信，网络中间能不能承载这个总需求？
如果能接近承载所有服务器线速，就是高 bisection，理想情况下叫 full bisection。
对 AI 集群来说，这很重要，因为大规模 collective 很容易制造跨很多节点的同步通信。
用 Muxi case 理解
Muxi 里看到：
单跨机流可到 23～24GB/s；
7→1、15→1 incast 聚合入口约 24.2GB/s；
w512 AllReduce bus_bw 明显下降。这个组合说明：
单路径/单 rail 可以接近 200G 有效上限；
但大规模同步 collective 触发的是聚合容量、路径分布、接收入口、队列和通信库调度共同问题。所以你不能从 w512 下降直接说：
物理 fabric 是 2:1 超分。你只能把它列为候选之一：
可能有上行超分；
可能有 ECMP 碰撞；
可能有 shared buffer / queue；
可能有 PFC/ECN；
可能有 rank/channel/rail mapping 问题。9.3 VL2：逻辑位置和物理位置可以解耦
这篇论文讲什么
VL2 的目标是构建一种数据中心网络，让任意服务可以灵活放到任意服务器上，同时维持服务器之间较统一的高容量和类似 Ethernet layer-2 的语义。
你不需要深入 VL2 的所有机制，但要吸收这个观念：
数据中心网络里，逻辑地址 ≠ 物理位置。关键思想：地址可以分两层
可以把它抽象成：
Application Address：服务/主机的稳定身份
Locator Address：当前物理/拓扑位置这样服务迁移时，应用可以继续用稳定地址；底层网络通过目录/封装/映射找到真实位置。
小 case：同一个 /24 不代表同一个 rack
假设你看到：
hostA: 10.10.1.11/24
hostB: 10.10.1.12/24你可能想说：
它们在同一个子网，所以应该很近。但在现代数据中心里，可能是：
hostA 接 leaf7
hostB 接 leaf23
中间经过 spine
逻辑上仍属于同一个网络甚至有 overlay、CNI、虚拟网络、隧道、目录系统等机制，让逻辑地址和物理连接进一步解耦。
用 Muxi case 理解
Muxi 拓扑事实报告里有一个关键边界：
四个 rail 的 IP 子网可以说明逻辑隔离；
不能证明四个物理独立交换平面。这就是 VL2 给我们的直觉：不能从逻辑地址直接推出物理拓扑。
所以如果你看到：
xscale_0 在 subnet A
xscale_1 在 subnet B
xscale_2 在 subnet C
xscale_3 在 subnet D你可以说：
四个 rail 在逻辑网络上区分开了。但不能说：
它们一定接到四套完全独立的 leaf/spine fabric。要证明后者，需要：
host xscale_i → switch chassis/port 映射；
LLDP；
配线表；
交换机端口 counter；
网络组 ground truth。9.4 Jupiter Rising：大规模 Clos 真正依赖“控制”和“可观测性”
这篇论文讲什么
Jupiter Rising 总结了 Google 数据中心网络十年演进经验。它强调多级 Clos 拓扑、commodity switch silicon、集中式控制、全局配置和可观测性。
你要抓住的是：真实大规模 Clos 不是一张静态拓扑图，而是一个持续被控制、监测、扩容、维护的工程系统。
关键知识点 1：真实 Clos 是工程系统，不只是拓扑图
教科书里的 Clos 可能是：
leaf → spine → leaf但真实系统里还有：
路由策略；
集中配置；
故障域；
链路状态；
流量工程；
遥测；
交换机队列；
buffer；
ECMP group；
维护窗口；
故障隔离；
capacity planning。所以“画出一个 Clos”只是开始。
关键知识点 2：控制面知道的东西，端点通常不知道
网络控制系统可能知道：
host 接在哪个 leaf port；
哪些 spine 可用；
哪些 link down；
ECMP group 里有哪些 next-hop；
哪些端口拥塞；
哪些 queue 在 pause；
哪些路径被限速；
哪些设备在维护。但容器里的端点可能只能看到：
ip addr
ip route
ping/RTT
带宽
少量 RNIC 信息这两者信息量差非常大。
用 Muxi case 理解
Muxi 最终结论说：
QoS/ECMP 物理机制没有闭环；
需要网络侧 ground truth。这不是保守过头，而是因为没有交换机侧信息时，你缺的是关键锚点：
host rail → switch port；
switch queue occupancy；
PFC pause；
ECN mark；
CNP；
drop/retry；
CRC/FEC；
per-port bytes；
ECMP group；
hash field；
QoS mapping。没有这些，端点 pair matrix 再大也只是行为观测。
9.5 四篇阅读之间的关系
可以这样串起来：
Fat-Tree / Clos
解释：为什么数据中心网络有多级、多路径、高 bisection 设计。
RFC 2992 / ECMP
解释：多路径具体怎么选，为什么是 flow hash，为什么会不均。
VL2
解释：逻辑地址、服务位置、物理位置可以解耦，所以 IP/子网不等于物理接近。
Jupiter Rising
解释：真实大规模 Clos 需要集中控制、配置、遥测和 ground truth；端点观测不足以恢复完整物理事实。对应到 Muxi：
Muxi 现象：
w512 AllReduce 掉速；
单流可到 23~24GB/s；
incast 聚合入口约 24GB/s；
4 rail 不线性；
pair matrix 无稳定物理聚类。
用 Fat-Tree 理解：
大规模 collective 可能触发 bisection / 上行 / shared capacity 问题。
用 ECMP 理解：
少量大象流、QP/port entropy、flow hash 可能导致路径不均。
用 VL2 理解：
IP 子网和 CNI 信息只是逻辑拓扑，不能直接推出物理 leaf/spine。
用 Jupiter 理解：
要把候选机制闭环，必须要交换机侧 ground truth 和遥测。10. 进阶补充：packet spraying 和 flowlet switching
这两个不是本周必须精通，但知道名字有帮助。
10.1 packet spraying
逐 packet 分散到多条路径：
packet1 → path0
packet2 → path1
packet3 → path2优点：
更容易均匀利用多路径。缺点：
容易乱序。对 RDMA/RoCE 这种对顺序、丢包、时延很敏感的流量，不是可以随便开的东西。
10.2 flowlet switching
把一条 flow 按时间间隔切成多个 flowlet。
如果两个 burst 之间有足够大的 gap，后一个 burst 可以换路径，同时尽量避免乱序。
概念上：
flowlet 1 → path0
短暂停顿
flowlet 2 → path2这比 packet spraying 温和，但实现复杂，也要交换机/网络支持。
10.3 和 Muxi 的关系
如果我们只能控制 QP、rank permutation、rail、message size，那我们其实没有直接控制 packet spraying/flowlet switching。
所以不能把实验结果直接解释成：
交换机做了 flowlet；
交换机没做 flowlet。我们最多说：
观察结果对 flow-level ECMP entropy 敏感或不敏感。11. 本周任务设计
11.1 任务 A：画出 2 leaf × 2 spine Clos
你要能画：
spine1 spine2
| |
leaf1 leaf2
/ \ / \
h1 h2 h3 h4然后回答：
h1 到 h2：是否一定经过 spine？
h1 到 h3：可能经过哪些 spine？
如果 leaf1 到 spine1 的上行拥塞，会影响哪些 pair？
如果 ECMP hash 把 h1→h3 和 h2→h4 都放到 spine1，会怎样？期望理解：
同 leaf 通信和跨 leaf 通信路径不同；
跨 leaf 有多条等价路径；
多条路径不保证流量均匀；
局部拥塞可以表现为端到端 pair 慢。11.2 任务 B：手算 oversubscription
给一个 leaf：
下行：8 × 200G
上行：4 × 200G计算：
下行总量 = 1600G
上行总量 = 800G
超分 = 2:1再回答：
如果只有 1 台服务器向外发，能不能打满 200G？
如果 8 台服务器同时向外发，每台还能不能 200G？
如果跨组 pair 慢一半，是否一定说明这里是 2:1？期望理解：
超分是聚合瓶颈，不是单 pair 固定倍率。11.3 任务 C：ECMP balls into bins
假设：
4 条 ECMP path
4 条大流随机分配一次：
flow1 → path1
flow2 → path1
flow3 → path3
flow4 → path3结果：
path1: 2
path2: 0
path3: 2
path4: 0再试 16 条流：
path1: 5
path2: 3
path3: 4
path4: 4期望理解：
少量大象流更容易 hash 不均；
增加 flow entropy 可能改善；
但改善不能直接证明具体 hash 字段。11.4 任务 D：解释 Muxi rail 子网
只读查看：
ip addr
ip route
ip neigh你要回答：
四个 rail 是否在不同子网？
默认路由走哪里？
RoCE 数据面和控制面是否分开？
这些信息能否证明四个 rail 物理完全独立？期望理解：
IP/子网是逻辑证据；
物理独立需要 LLDP、配线表、交换机端口 counter。11.5 任务 E：解释 traceroute
如果 traceroute 看不到中间交换机，你要写：
这说明中间没有暴露为 L3 TTL hop 的设备；
不说明没有 L2 switch；
不说明没有 leaf/spine；
不说明路径短；
不说明没有 ECMP。12. 你可以怎么向 agent 提问
12.1 问题模板：判断一个结论能不能下
我观察到 A-B pair 带宽低于其他 pair。
请按“逻辑拓扑、物理拓扑、行为拓扑”三层帮我判断：
1. 这个现象支持什么？
2. 不能证明什么？
3. 需要什么额外证据才能命名 leaf/spine 或 ECMP path？12.2 问题模板：设计 ECMP 熵实验
我想验证 ECMP hash / QP entropy 是否影响 Muxi pair 带宽。
请帮我设计一个实验，要求固定端点、rail、消息大小、并发度，只改变 QP 数或 flow salt。
输出需要包含正对照、负对照、观测指标、替代解释和停止条件。12.3 问题模板：解释一个带宽矩阵
这是一个 64 节点 pair bandwidth matrix。
请不要直接命名 leaf/spine。
请先判断是否存在稳定块结构、方向性慢、节点边际异常、复测稳定性。
最后只输出行为分组和需要的 ground truth。12.4 问题模板：避免过度推断
如果一个跨组实验带宽大约减半，请列出至少 6 个可能原因。
然后告诉我哪些实验能区分“物理超分”“ECMP 碰撞”“接收 rail 瓶颈”和“通信库映射”。13. 本周最小掌握清单
如果时间很少，这周至少掌握这些：
- MAC/IP/GID 分层：MAC 是二层下一跳，IP 是三层寻址，GID 是 RDMA/RoCE 端点标识。
- traceroute 边界：它看到 L3 hop，看不到普通 L2 交换机。
- Clos/leaf-spine：跨 leaf 通信通常经 spine，多条等价路径很常见。
- bisection/oversubscription：它们描述聚合容量，不是单 pair 的固定倍率。
- ECMP flow hash：通常按 flow hash，不是逐 packet 平均。
- 大象流不均：少量长流即使有多路径也可能撞路径。
- queue/buffer/scheduler：交换机会排队，且可能通过 QoS/PFC/ECN 影响发送端。
- 拓扑不可辨识：端到端矩阵最多给行为拓扑，不能自动命名物理 leaf/spine。
- 实验结论边界：多 QP 变快、跨组变慢、热力图有块，都只是支持假设，不是机制闭环。
- ground truth 需求：要命名物理拓扑，最终需要 LLDP、配线表、交换机端口计数、queue/ECN/PFC/drop/bytes 之类证据。
14. 本周结束时你应该能解释的一段话
如果有人问：
“我们有 2016 pair 带宽矩阵，能不能反推出 Muxi 的 leaf/spine 拓扑？”
你应该能回答：
不能直接反推。pair 矩阵是端到端行为观测，不是物理链路观测。
在对称 Clos + ECMP 下，不同物理路径可能产生相同带宽/RTT。
同一个 pair 还可能因为 ECMP、QP、rail、背景流量和队列状态变化而走出不同表现。
如果没有 LLDP、配线表、交换机端口 counter、queue/ECN/PFC/drop/bytes 等 ground truth，矩阵最多支持行为分组、异常候选和共享瓶颈假设，不能命名具体 leaf/spine。这就是第 2 周最核心的理解。