这个问题没有一个“标准答案” ，但在工程实践里有一套非常稳定、被反复验证过的经验区间。我从常见规模 → 影响因素 → 不同场景推荐三个层面给你一个可落地的结论。
一、先给结论（经验值）
Underlay 子网常见大小：
/24或/23，大规模会用/22，很少超过/21
| 子网 | 可用 IP | 常见使用场景 |
|---|---|---|
/24 | 254 | 最常见：ToR–Leaf、Rack 级 |
/23 | 510 | 一组 ToR / 小规模 Fabric |
/22 | 1022 | 大机柜 / Pod |
/21 | 2046 | 超大 Pod（不推荐新建） |
/30 / /31 | 2 / 1 | 点对点链路（BGP） |
二、underlay 网络本质决定了子网不能太大
1️⃣ underlay 主要用途（不是业务网）
underlay 一般只承载：
- 节点互联（Leaf ↔ Spine）
- 隧道承载（VXLAN / Geneve / GRE）
- BGP / IGP 路由
- 心跳 / 管理通信
❌ 不会跑业务流量
❌ 不会做大二层广播
➡️ 所以 不需要超大广播域
2️⃣ 广播域 & 故障域是第一约束
子网越大：
- ARP / ND 广播越多
- 单个误配置影响面越大
- 故障 blast radius 增大
经验规则：
一个 underlay 子网 = 一个“故障可接受边界”
所以常见设计是：
- 一个 Rack 一个 /24
- 一个 Pod 若干个 /24
三、影响 underlay 子网大小的关键因素
🔹 1. 节点规模（最核心）
你要先回答这几个问题：
-
一个二层域 / Rack / Pod 里：
- 有多少 物理服务器？
- 有多少 网络设备？
- 有多少 虚拟节点（VMI / BMH / GW） ？
经验预留：
实际节点数 × 1.3 ~ 1.5
例子：
- 120 台服务器
- 10 台网络设备
- 预留 30%
≈ 170 IP → /24
🔹 2. 路由模型（L3 vs L2）
✅ L3 underlay（主流）
- Leaf–Spine
- BGP
- 点对点链路
特点：
- underlay 不依赖二层
- 子网可以非常小
- /30 /31 用在链路上
- Loopback 用
/32
👉 这种模式下：
- 大子网只用于管理 / loopback 汇总
- 数据转发几乎不依赖子网大小
❌ L2 underlay（少见 & 不推荐）
- 早期云 / 小规模集群
- 全二层 + overlay
问题：
- 广播风暴风险
- ARP scale 问题
👉 如果是这种模式，子网一定要小（/24 以内）
🔹 3. 运维 & IP 管理复杂度
子网越大：
- IPAM 更难
- 人工分配更容易出错
- 回收困难
现实经验：
/24 是人脑可控的上限
你可以快速判断：
- IP 是否用完
- 哪段可回收
- 是否异常
🔹 4. 与 overlay / Pod CIDR 的解耦
underlay 子网：
- 不需要和 Pod CIDR 对齐
- 不需要连续
- 更不需要为了“好看”而变大
很多生产事故来自：
“为了将来扩容，一开始建了个 /20”
然后：
- ARP 爆了
- 广播异常难定位
- 半个机房受影响
四、典型架构下的推荐方案
🟢 Kubernetes + VXLAN / Geneve
推荐：
- 每个 Rack：
/24 - BGP 点对点：
/31 - Loopback：
/32
Rack-1: 10.0.1.0/24
Rack-2: 10.0.2.0/24
...
🟢 裸金属 + Kube-OVN / Calico BGP
推荐：
- underlay 管理网：
/24 - Fabric 链路：
/31 - GW / NAT：独立
/24
🟡 小规模实验 / PoC
/23可以接受- 不要超过
/22
五、什么时候“必须”用大子网？
只有以下情况才合理：
- 超大 Pod（> 500 节点）
- 自动化 IPAM（无人工）
- 严格 L3 underlay
- 明确的故障域隔离设计
即使这样：
宁愿多个 /24，也不要一个 /21
六、一句话总结（给设计评审用）
underlay 子网的大小不是为了“容纳未来”，而是为了“控制故障半径”
如果你愿意，我可以：
- 🔧 按你当前集群规模帮你算一个合理的 underlay 规划
- 📐 画一张 underlay / overlay / Pod CIDR 的对照图
- ⚠️ 帮你 review 现有 underlay 设计是否有隐患
