Network

⭐️
接入层：就是机柜最上面直接连服务器的交换机
汇聚层：多台接入层交换机 汇聚到 机房中间两台大交换机
核心层：多个汇聚层交换机连到它上面，通过它连接到外网  

一、传统数据中心三层架构

传统数据中心（非 AI 机房）通常采用三层结构，从下到上是：接入层 → 汇聚层 → 核心层。

1. 接入层（Access Layer）

英文：Access Layer /ˈækses ˈleɪər/

接入层是服务器直接连接 的那一层。机柜里每台服务器的网线，最终都插到这一层的交换机上。这种交换机通常叫 ToR switch（Top of Rack，机柜顶部交换机），因为它就放在机柜最上面。

机房实例 ：

你走进机房，看到一排机柜，每个机柜最上面（U42 位置）放着一台 48 口的交换机，下面 40 台 1U 服务器全部用网线连上去。这台交换机就是接入层交换机。

---

2. 汇聚层（Aggregation Layer / Distribution Layer）

英文：Aggregation Layer /ˌæɡrɪˈɡeɪʃən/

汇聚层把多台接入层交换机的流量汇聚到一起，再向上送到核心层。它通常承担 VLAN 终结、防火墙、负载均衡等功能。

机房实例 ：

机房里有 20 个机柜，每个机柜的 ToR 交换机都用 2 条 100G 光纤上连到机房中间的两台大交换机，那两台大交换机就是汇聚层。

---

3. 核心层（Core Layer）

英文：Core Layer /kɔːr ˈleɪər/

核心层是整个数据中心的骨干，负责高速转发，连接多个汇聚层，也连接外网（互联网或专线）。

机房实例 ：

机房有两个区域（Zone A 和 Zone B），每个区域都有自己的汇聚层。这两组汇聚层都上连到机房中央的两台超大核心交换机，再由核心交换机连到运营商的边界路由器。这两台超大交换机就是核心层。

类比：接入层像小区门口的快递柜，汇聚层像区域分拣中心，核心层像全国总枢纽。

---

二、Spine-Leaf 与 Underlay / Overlay

⭐️
AI 机房不用三层架构，而是两层架构 Spine-Leaf. 

AI 机房现在几乎不用三层架构了，而是用 Spine-Leaf（两层架构）。然后在 Spine-Leaf 上跑两个"网络"：底层网络和叠加网络。

4. Underlay Network（底层网络）

英文 ：Underlay Network /ˈʌndərleɪ/

中文：底层网络

Underlay 是真实的物理网络，由真实的交换机、光纤、IP 地址、路由协议（通常是 BGP 或 OSPF）组成。它的唯一任务就是：保证任意两个交换机之间 IP 可达。

机房实例 ：

8 台 Spine 交换机和 32 台 Leaf 交换机之间用 400G 光纤全互联，每条链路配 /31 的 IP，跑 eBGP，形成一张"任意两点都通"的物理网络。这就是 Underlay。

---

5. Overlay Network（叠加网络）

英文 ：Overlay Network /ˈoʊvərleɪ/

中文：叠加网络

Overlay 是建在 Underlay 之上的虚拟网络 ，常用 VXLAN + EVPN 实现。它把租户的二层网络封装在 UDP 包里，通过 Underlay 传输。

机房实例 ：

客户 A 的 100 台 GPU 服务器分散在不同机柜，但客户 A 希望它们看起来在同一个 VLAN 里。我们就在 Leaf 交换机上配 VXLAN，给客户 A 分配 VNI 10001，他们的流量被封装成 VXLAN 包，通过底层 IP 网络传输，到对端再解封装。客户 A 感知到的就是一张二层网，但实际跑在三层 Underlay 上。

类比：Underlay 是高速公路，Overlay 是公路上跑的"专车专线"。

---

6. 等价多路径路由（ECMP）

英文 ：Equal-Cost Multi-Path Routing

缩写 ：ECMP /ˌiːsiːemˈpiː/

中文：等价多路径路由

当从 A 到 B 有多条代价相同 的路径时，路由器会把流量分摊到这些路径上，而不是只用其中一条。

机房实例 ：

一台 Leaf 交换机上连到 8 台 Spine，每条链路都是 400G。Leaf 上有 8 条等价的路由可以到达对端 Leaf。当 GPU 训练流量过来时，交换机用 5 元组（源 IP、目的 IP、协议、源端口、目的端口）做 hash，把不同的 flow 分散到 8 条链路上，总带宽就是 8 × 400G = 3.2T。

注意：ECMP 是按 flow 分配的，不是按 packet。所以如果只有一条大象流（elephant flow），仍然只能用一条链路，这是 AI 网络中的常见痛点，需要通过 adaptive routing 或 packet spraying 解决。

---

三、AI 机房特有概念

7. Rail-Optimized Network（轨道优化网络）

英文 ：Rail-Optimized Network /reɪl ˈɑːptɪmaɪzd/

中文：轨道优化网络（也叫 Rail 架构）

AI 训练里，每台 GPU 服务器有 8 张 GPU ，每张 GPU 配一张专属网卡（比如 ConnectX-7 400G）。Rail-Optimized 的核心思想是：同一编号的 GPU 网卡（同一个 rail）连到同一组 Leaf 交换机。

机房实例 ：

机房里有 32 台 H100 服务器，每台 8 张 GPU、8 张网卡。

• 所有服务器的 GPU0 网卡 都连到 Leaf-Rail0
• 所有服务器的 GPU1 网卡 都连到 Leaf-Rail1
• 一直到 GPU7 网卡 连到 Leaf-Rail7

这样当 GPU0 之间做 AllReduce 时，流量只在 Rail0 这个平面里走，不需要跨 Rail，路径短、冲突少、延迟低。

类比：8 条独立的高铁轨道，每条轨道只跑一种车，不会互相干扰。

---

8. OOB Management（带外管理）

英文 ：Out-of-Band Management

缩写 ：OOB /ˌoʊoʊˈbiː/

中文：带外管理

OOB 是一张独立于业务网络的管理网络，专门用来管设备：登录设备 CLI、看监控、做配置、远程开关机。即使业务网络挂了，OOB 网也通，让你能远程救援。

机房实例 ：

每台交换机除了业务口（前面的 64 个 400G 口），背后还有一个 mgmt0 口（1G RJ45）。我们专门用一组小的 1G 管理交换机把所有设备的 mgmt0 串起来，单独走一条 VLAN，连到跳板机。

某天晚上一台 Leaf 交换机的业务口配错了路由，业务流量全断，但因为 OOB 没断，你能 SSH 到这台交换机回滚配置。如果没有 OOB，你就得开车去机房现场插 console 线，那是噩梦。

服务器的 BMC / iDRAC / iLO 也是接到 OOB 网的。

---

9. Breakout Cable（分支线缆 / 一分多线缆）

英文 ：Breakout Cable /ˈbreɪkaʊt ˈkeɪbl/

中文：分支线缆 / 一拖多光缆

一根高速线缆，一头是 1 个高带宽接口，另一头分成多个低带宽接口。

机房实例 ：

Spine 交换机的端口是 400G QSFP-DD ，但你的 GPU 服务器网卡是 100G QSFP28。你不能直接用 400G 模块连 100G 网卡。怎么办？

用一根 400G to 4×100G breakout cable：

• 一头插 Spine 的 1 个 400G 口
• 另一头分成 4 个 100G 接头，分别插到 4 台不同服务器的 100G 网卡上

这样 1 个 400G 口顶 4 个 100G 口用，节省交换机端口、降低成本。

常见组合：

• 400G → 4×100G
• 400G → 2×200G
• 100G → 4×25G
• 40G → 4×10G

---

四、运维操作概念

10. Configuration Push（配置下发）

英文 ：Configuration Push /ˌkənfɪɡjəˈreɪʃən pʊʃ/

中文：配置下发 / 推送配置

把配置文件（或配置变更）从集中管理系统自动批量推送到一台或多台设备上，不再需要工程师逐台 SSH 进去手敲命令。

机房实例 ：

你需要给 32 台 Leaf 交换机加一条 ACL，禁止某个 IP 访问。你不会一台一台 SSH 进去敲，而是：

1. 在 Ansible / NetBox / Terraform / 自研控制器 里改模板
2. 提交 Git，走 PR review
3. 自动化系统把渲染好的配置 push 到 32 台设备
4. 每台设备执行 commit，新配置生效

如果同事说："Did you push the config?" 意思是"你把配置下发了吗？"

如果说："Roll back the config push." 意思是"回滚这次配置下发。"

在 Cisco/Arista 设备上常见的命令：commit、copy running-config startup-config，背后都属于 push 流程的一部分。

---

11. CRC Errors（CRC 错误 / 校验错误）

英文 ：CRC Errors /ˌsiːɑːrˈsiː ˈerərz/

全称 ：Cyclic Redundancy Check Errors /ˈsaɪklɪk rɪˈdʌndənsi/

中文：循环冗余校验错误

每个以太网帧末尾都带一个 CRC 校验码。接收端会重新计算一遍，如果对不上，说明这个帧在传输中损坏了，就丢弃它，并且 CRC 错误计数加 1。

机房实例 ：

一台 GPU 服务器训练任务变慢，你登录上联的 Leaf 交换机查端口：

Ethernet33/1 is up
  input rate 380 Gbps, output rate 250 Gbps
  RX
    1,234,567,890 packets, ...
    45,231 CRC errors    ← 不正常！
    12,003 input errors

CRC errors 持续增长，几乎一定是物理层问题，可能原因：

• 光模块脏了 / 老化
• 光纤跳线被弯折、被压
• 光模块没插紧
• 光衰过大（attenuation 太高）
• 光模块与交换机不兼容
• DAC/AOC 线缆损坏

标准排查动作：

1. show interface ethernet 33/1 看 CRC 计数是否还在涨
2. show interface ethernet 33/1 transceiver 看光功率（RX power）是否正常，一般 -7 dBm 到 0 dBm 是健康范围，低于 -10 dBm 就有问题
3. 拔下来用无尘布 + 光纤清洁笔擦干净两端
4. 还不行就换光模块
5. 还不行就换光纤
6. 还不行就换对端口

一句话：CRC errors 几乎都是硬件问题，不是配置问题。

---

---

一、Underlay 和 Overlay 在 AI 机房的详细例子

先理解一个关键事实：AI 机房里其实有两张（甚至三张）独立的网络：

1. 前端网络（Frontend Network）------给服务器上互联网、对外服务、存储访问用，跑普通以太网（TCP/IP）
2. 后端网络（Backend Network / Compute Fabric）------专门给 GPU 之间训练通信用，跑 InfiniBand 或 RoCE v2
3. 带外管理网络（OOB）------管设备用

Underlay / Overlay 的概念，主要用在"前端网络"和"存储网络"上，不太用在 GPU 后端网络上。这是关键区别，下面会讲。

---

详细场景：一个真实的 AI 机房

假设你管一个机房，里面有：

• 64 台 H100 服务器（客户 A 租 32 台，客户 B 租 32 台）
• 32 台 Leaf 交换机（前端网络）
• 8 台 Spine 交换机（前端网络）
• 另外有一套独立的 InfiniBand 网络（后端 GPU 训练用）

Underlay（底层网络）------真实的物理路由网

前端网络的 32 台 Leaf 和 8 台 Spine 之间，用 400G 光纤全互联。我们给每条链路配 IP：

Leaf-01 的 Eth1 ←→ Spine-01 的 Eth1   IP: 10.0.1.0/31
Leaf-01 的 Eth2 ←→ Spine-02 的 Eth1   IP: 10.0.1.2/31
Leaf-01 的 Eth3 ←→ Spine-03 的 Eth1   IP: 10.0.1.4/31
... 一直到 Eth8

每台交换机还有一个 Loopback IP（环回地址）：

Leaf-01: 10.255.0.1
Leaf-02: 10.255.0.2
Spine-01: 10.255.1.1

然后所有设备之间跑 eBGP ，每台 Leaf 把自己的 Loopback 通告出去，最终结果是：任何一台 Leaf 都能用 IP 访问到任何另一台 Leaf。

**这就是 Underlay。**它是一张纯三层 IP 路由网，只解决一件事："包能不能从 A 走到 B"。

Overlay（叠加网络）------虚拟出来的二层网

⭐️ overlay
不同机柜，看起来是同一个网段
客户A B可以用相同的ip 而不冲突。做多租户隔离的

现在客户 A 提需求："我的 32 台服务器虽然分散在 8 个机柜，但我希望它们看起来在同一个网段（比如 192.168.10.0/24），互相能 ping 通，能广播 ARP，就像在一个交换机下面一样。"

客户 B 也提同样的需求，但他想用 192.168.10.0/24（IP 跟客户 A 撞了）。

怎么办？用 VXLAN + EVPN 做 Overlay：

• 给客户 A 分配 VNI 10001
• 给客户 B 分配 VNI 10002

当客户 A 的服务器（在 Leaf-01 下）发一个包给同样属于客户 A 的另一台服务器（在 Leaf-15 下）时，发生了什么？

1. 服务器发出原始以太网帧（源IP 192.168.10.5 → 目的IP 192.168.10.20）
2. Leaf-01 收到后，把这个帧整个塞进一个 UDP 包里，加上 VXLAN 头，标记 VNI=10001
3. 外层 IP 是：源 10.255.0.1（Leaf-01 Loopback）→ 目的 10.255.0.15（Leaf-15 Loopback）
4. 这个外层包通过 Underlay 的 BGP 路由，经过某个 Spine，到达 Leaf-15
5. Leaf-15 解封装，发现 VNI=10001，知道是客户 A 的流量
6. 把里面原始的以太网帧丢给客户 A 的目的服务器

**这就是 Overlay。**对客户 A 来说，他完全感知不到中间这些复杂操作，他眼里 32 台服务器就是在一个二层网里。客户 B 用同样的 IP 段也不冲突，因为 VNI 不同。

类比：Underlay 是真实的城市道路网。Overlay 是地图软件画出来的"上班通勤路线"------A 公司员工走绿色路线，B 公司员工走蓝色路线，两条路线可能用同一条物理马路，但不会互相干扰。

---

二、InfiniBand / RoCE v2 和 Underlay/Overlay 的关系

这是一个非常好的问题，很多工程师都搞混。

关键事实

Underlay/Overlay 是针对"以太网 + IP 网络"的概念。InfiniBand 是另一套完全独立的网络体系，不用 Underlay/Overlay 这套术语。RoCE v2 跑在以太网上，所以可以涉及 Underlay 概念。

InfiniBand（IB）

• 是 NVIDIA / Mellanox 主导的一套独立网络协议，不是以太网
• 用自己的交换机（NVIDIA Quantum 系列）、自己的网卡（ConnectX 系列工作在 IB 模式）
• 由 Subnet Manager（SM） 集中管理整个网络的路由
• 不跑 BGP，不跑 VXLAN
• 天然支持 RDMA、低延迟、无损传输

机房里如果用 IB 做 GPU 后端网络，通常是这样：

H100 服务器 8 张 ConnectX-7 IB 网卡
       ↓
IB Leaf 交换机（NVIDIA Quantum-2 QM9700）
       ↓
IB Spine 交换机（NVIDIA Quantum-2 QM9700）

这套网络只跑 GPU 训练流量，跟前端的以太网完全独立，不需要 Underlay/Overlay 概念，因为它本身就是一个扁平的、由 SM 统一管理的网络。

RoCE v2

• 全称：RDMA over Converged Ethernet v2
• 跑在标准以太网 + UDP/IP 上的 RDMA
• 用普通的以太网交换机（Arista、Cisco、Nvidia Spectrum），只要支持 PFC 和 ECN 就行
• 因为它跑在 IP 上，所以它的网络架构就是 Underlay

如果用 RoCE v2 做 GPU 后端：

• 这个 GPU 后端网络本身就是一个 Underlay（跑 BGP 的 Spine-Leaf 以太网）
• 但通常不在 GPU 后端网络上做 VXLAN Overlay，因为 Overlay 会增加封装开销，影响性能
• Overlay 是用在前端网络上做多租户隔离的

总结这个关系

网络	架构	是否有 Underlay	是否有 Overlay
前端业务网（以太网）	Spine-Leaf	是（BGP IP 网）	是（VXLAN/EVPN 多租户）
GPU 后端网（InfiniBand）	Fat-Tree，由 SM 管理	不适用	不适用
GPU 后端网（RoCE v2）	Spine-Leaf 以太网	是	通常不做
OOB 管理网	简单二层或三层	不适用	不适用

所以"AI 机房网络就是 IB 和 RoCE v2"这个说法只对了一半------那是 GPU 后端网络。机房里还有前端网络、存储网络、管理网络，这些地方 Underlay/Overlay 仍然是核心概念。

---

三、ECMP、大象流、Adaptive Routing、Packet Spraying

1. ECMP 是什么

ECMP：Equal-Cost Multi-Path，等价多路径。

当从 A 到 B 有多条代价相同的路径时，路由器把流量分散到这些路径上。

详细例子

Leaf-01 要把包发给 Leaf-15。它上连了 8 台 Spine（Spine-01 到 Spine-08），每条链路都是 400G。BGP 算出来的结果是：

去 Leaf-15 的路：
  下一跳 Spine-01  cost=10
  下一跳 Spine-02  cost=10
  下一跳 Spine-03  cost=10
  ...
  下一跳 Spine-08  cost=10

8 条路代价都一样，Leaf-01 不会只选一条用，而是 8 条都用，这就是 ECMP。

怎么决定每个包走哪条？

交换机用 hash 算法 ，输入是这个包的 5 元组：

源 IP + 目的 IP + 协议号 + 源端口 + 目的端口
        ↓ hash
得到一个数字，比如 5
        ↓
取模 8 = 5
        ↓
走第 5 条链路（Spine-06）

关键点 ：同一个 flow（同样的 5 元组）的所有包，hash 出来都是同一个值，所以永远走同一条链路。这是为了防止包乱序（out-of-order）。

2. 大象流（Elephant Flow）问题

Elephant Flow：长时间、超大量的单一数据流。

AI 训练里的真实场景

GPU0 在 Server-A 上，GPU0 在 Server-B 上，它们做 AllReduce，要传输 8GB 的梯度数据 。这是一个 TCP/RDMA 连接，源 IP、目的 IP、源端口、目的端口都是固定的。

→ 5 元组固定 → hash 固定 → 8GB 数据全部走同一条 400G 链路

结果：

• 这一条链路被打满 400G，拥塞、排队、延迟暴增
• 另外 7 条链路完全空闲
• 总带宽 3.2T，实际只用了 400G

这就是 AI 网络里最经典的痛点。普通互联网流量是无数小流（很多用户访问网站），ECMP hash 一下分布得很均匀。但 AI 训练就那么几个超大流，hash 完容易撞到一起，链路严重不均衡。

3. Adaptive Routing（自适应路由）

核心思想 ：不再死板地按 hash 选路，而是实时看哪条路不堵就走哪条。

详细机制

每台交换机不停地监控自己每个上联端口的：

• 队列长度（buffer 占用）
• 已用带宽
• 拥塞通知（ECN 标记）

当一个包要转发时，交换机查路由表发现 8 条等价路径，不再用 hash，而是：

查看 8 个出端口的队列长度：
  Eth1 → Spine-01: queue depth 80%（堵）
  Eth2 → Spine-02: queue depth 30%
  Eth3 → Spine-03: queue depth 5%（最空）
  ...
→ 选 Eth3

这样能把流量真正动态地铺开。

InfiniBand 的 Adaptive Routing 非常成熟，由 Subnet Manager 配合交换机实现，这也是 NVIDIA 一直推 IB 的卖点之一。

NVIDIA Spectrum-X 以太网交换机也支持类似机制（叫 Dynamic Routing 或 Adaptive Routing）。

4. Packet Spraying（包级喷洒）

核心思想 ：比 Adaptive Routing 更激进------同一个 flow 的不同包，强制走不同链路。

详细机制

GPU0 → GPU0 这个 flow 要发 1000 个包：

• Packet 1 走 Spine-01
• Packet 2 走 Spine-02
• Packet 3 走 Spine-03
• ...
• Packet 8 走 Spine-08
• Packet 9 走 Spine-01
• ...（轮询）

8 条链路全部用上，带宽利用率接近 100%。

但有个大问题：包乱序

包从不同链路走，到达对端的顺序可能是 1, 3, 2, 5, 4, 8, 7, 6...

普通 TCP 看到乱序会以为丢包，触发重传，性能爆炸式下降。

解决方案：

• 接收端网卡硬件做重排序（reordering）
• 比如 NVIDIA ConnectX-7 网卡 + Spectrum-X 交换机，组合起来实现 packet spraying + 网卡侧硬件重组
• AWS 自研的 SRD 协议也支持类似机制

所以 Packet Spraying 不是随便能开的，需要交换机和网卡配套支持。

---

四、OOB 救援故事的完整经历

⭐️
交换机和服务器都有🔧网口，并且他们是连在一起，组成独立的网络

我把它写成一个真实工单的样子。

---

时间 ：周五晚上 23:47

值班工程师 ：你（二线）

告警：Datadog 报警，Customer-A 的 Leaf-17 下挂的 8 台服务器全部 unreachable

23:48 接到告警

你正准备睡觉，手机疯狂响。打开电脑看告警面板：

[CRITICAL] Leaf-17 - 8 servers unreachable
[CRITICAL] Leaf-17 - BGP sessions DOWN to all spines
[WARN]     Leaf-17 - Last config change: 23:42 by automation-bot

最后一条 BGP session 断了，但设备本身还在线（OOB 还能 ping 通）。

23:50 查看变更记录

你打开 GitLab，发现 23:40 一线工程师小张提交了一个 PR，给所有 Leaf 加 ACL，CI 自动跑完测试就 push 了。23:42 配置已经下发到 Leaf-17。

打开那个 PR 的 diff，你倒吸一口冷气：

+ ip access-list BLOCK_BAD_IP
+   deny   ip any any         ← 应该是 deny ip 1.2.3.4 any，模板渲染出错
+ interface Ethernet1-32
+   ip access-group BLOCK_BAD_IP in

ACL 写成了 deny ip any any 应用到了所有上联接口------所有进入 Leaf-17 的流量被全部丢弃，包括 BGP keepalive 包。BGP 邻居超时断掉，整台 Leaf 在路由层面变成了孤岛。

23:52 准备 SSH 救援

业务网已经断了，怎么登录 Leaf-17？

→ 走 OOB 管理网

你 SSH 到机房跳板机：

ssh jumpbox.dc1.internal

从跳板机再 SSH 到 Leaf-17 的管理 IP（不是业务 IP）：

ssh admin@10.99.17.1   # 这是 OOB 网的 IP，跑在独立的 mgmt0 物理口上

OOB 网完全不受业务网影响，因为它走的是另一张物理网络（独立的 1G 管理交换机），跟业务网那 8 条 400G 上联完全无关。所以你能登上去。

23:54 回滚配置

Leaf-17# show running-config | include access-group
  ip access-group BLOCK_BAD_IP in   ← 在所有 32 个端口上
  ...

Leaf-17# configure
Leaf-17(config)# interface Ethernet1-32
Leaf-17(config-if)# no ip access-group BLOCK_BAD_IP in
Leaf-17(config-if)# end
Leaf-17# write memory

23:56 BGP 恢复

Leaf-17# show ip bgp summary
Neighbor       State    Up/Down
10.0.1.1       Estab    00:00:30
10.0.1.3       Estab    00:00:28
...（8 个全部 Established）

23:58 业务恢复，写工单

ping 测试通过，客户 A 的服务器全部恢复。你在工单里写：

Service restored at 23:57 UTC. Root cause: misrendered ACL pushed to Leaf-17 blocked all ingress traffic, causing BGP sessions to drop. Mitigated by removing the ACL via OOB. RCA and config template fix to follow on Monday.

如果没有 OOB 会怎样

你需要：

1. 开车去机房（路上 40 分钟）
2. 刷门禁、刷生物识别进冷通道
3. 找到 Leaf-17 所在机柜
4. 拿出笔记本和 USB-to-RJ45 console 线
5. 拔出机柜后面的 console 接口插自己电脑
6. 用 PuTTY 配 9600 8N1 登录
7. 改配置

业务中断时间从 10 分钟变成 1.5 小时以上。这就是 OOB 存在的全部意义。

---

五、BMC / iDRAC / iLO 是什么

这是服务器主板上的一颗独立小电脑 ，专门用来管这台服务器，完全独立于操作系统。

概念详解

每台服务器主板上都焊着一颗管理芯片（叫 BMC），它有：

• 自己的 CPU
• 自己的内存
• 自己的网口（专用 RJ45，标着 mgmt 或 BMC）
• 自己的电源（只要服务器插上电源线就供电，哪怕服务器没开机）
• 自己的 IP 地址

不同厂商给这颗芯片起不同名字：

厂商	名字
通用术语	BMC（Baseboard Management Controller）
Dell	iDRAC /aɪˈdræk/
HPE	iLO /ˈaɪloʊ/（Integrated Lights-Out）
Supermicro	IPMI 或 SuperBMC
Lenovo	XCC

它能做什么

通过浏览器访问 BMC 的 IP（比如 https://10.99.50.7），你可以：

1. 远程开机/关机/重启------服务器关机状态下，你也能远程按"开机键"
2. 看硬件状态------CPU 温度、风扇转速、电源功率、内存错误、磁盘健康
3. 远程 KVM------就像你坐在服务器面前一样看屏幕、用键盘鼠标，能进 BIOS、能装系统
4. 挂载虚拟光驱------把一个 ISO 文件远程挂给服务器，远程装系统
5. 看启动日志------OS 蓝屏 / kernel panic 时，你还能看到屏幕

它接到哪里------OOB 网

每台服务器主板上有一个独立的 RJ45 BMC 口（不是业务网卡）。这个口接到机柜里的 OOB 管理交换机，跟交换机的 mgmt0 接到一起。

机柜：
  Server-01 ─ BMC 口 ─→ OOB 交换机
  Server-02 ─ BMC 口 ─→ OOB 交换机
  ...
  Leaf-01   ─ mgmt0 ─→ OOB 交换机
                       │
                       ↓
                     跳板机

为什么对 AI 机房至关重要

AI 训练任务跑了 12 天，第 12 天某台 H100 服务器突然死机，OS 完全卡死，SSH 也连不上。

• 如果没有 BMC：你得开车去机房，按机箱上的物理 reset 键
• 有 BMC：浏览器打开 iDRAC，点 "Power → Force Reset"，10 秒搞定。还能远程进 BIOS 看看是不是 GPU 报硬件错误

一句话总结

BMC/iDRAC/iLO 是服务器自己的"OOB"，跟交换机的 OOB 走同一张管理网，是远程运维的命脉。

---

六、配置 Push 的完整流程

我以一个真实变更为例：给所有 Leaf 交换机加一条 NTP 服务器。

步骤 0：现状

机房有 32 台 Arista Leaf 交换机。所有配置都用 Ansible 模板 管理，存在 GitLab 上。

步骤 1：本地改模板

工程师 clone 仓库：

git clone git@gitlab:netops/datacenter-config.git
cd datacenter-config

打开模板文件 templates/leaf.j2：

ntp server 10.99.0.10
ntp server 10.99.0.11
ntp server 10.99.0.12   ← 新增

提交：

git checkout -b add-ntp-server-3
git commit -am "Add third NTP server for redundancy"
git push origin add-ntp-server-3

步骤 2：CI 自动校验

GitLab CI 自动跑：

1. 语法检查------用 Arista 的 cEOS 容器加载渲染后的配置，看有没有语法错
2. Lint------检查命名规范、IP 段是否合法
3. Diff 预览 ------生成一个差异报告，告诉你这次变更会改哪些命令

步骤 3：Code Review

PR 发出来，团队 review。资深工程师确认无误，approve。

步骤 4：Dry Run（试运行）

合并前，先在预生产环境（一对实验室 Leaf）push 一遍：

ansible-playbook deploy.yml -i lab_inventory --check

--check 表示只看 diff，不真的改。输出大致是：

TASK [Apply config to lab-leaf-01]
changed: configuration would change:
+ ntp server 10.99.0.12

确认 diff 跟预期一致。

步骤 5：正式 Push（这就是 Configuration Push）

合并 PR 到 main 分支，触发自动化：

ansible-playbook deploy.yml -i prod_inventory --limit "leaf-*" --serial 4

--serial 4 表示一次只改 4 台，不是 32 台一起改，避免出问题全军覆没。

Ansible 在每台设备上做的事情：

1. SSH 到 Leaf-01
2. 进入 configure 模式
3. 敲命令: ntp server 10.99.0.12
4. 执行: commit              ← 让配置生效到 running-config
5. 执行: copy running-config startup-config   ← 保存，重启后还在
6. 退出
7. 校验：show ntp associations 看新 NTP 是否同步成功
8. 通过则继续下一台

关于 commit 和 copy running-config startup-config

交换机里有两份配置：

名称	存放位置	作用
running-config	内存（RAM）	当前正在生效的配置
startup-config	闪存（Flash）	重启后加载的配置

操作流程：

工程师敲: ntp server 10.99.0.12
   ↓
立即进入 running-config（开始生效）
但是 startup-config 还没变
   ↓
如果这时设备掉电重启 → 新配置丢失！
   ↓
所以必须执行: copy running-config startup-config
   ↓
running-config 被复制到 startup-config，永久保存

commit 是什么

某些设备（Juniper、Arista 在 session 模式下、Cisco IOS-XR）支持两阶段提交：

1. 工程师敲一堆配置命令     ← 这时还没生效，叫 candidate config
2. 执行: commit check       ← 检查语法是否正确
3. 执行: commit             ← 真正生效到 running-config
4. 执行: commit confirmed 5 ← 生效但 5 分钟内不再确认就自动回滚（救命用）

commit confirmed 是 OOB 之外的另一道保险------如果改配置改到把自己锁出去，5 分钟没操作设备会自动回滚。

步骤 6：监控

Push 完成后，监控系统检查：

• 所有 Leaf 的 NTP 是否同步到新服务器
• 时间偏差是否在 ±10ms 内
• BGP session 是否仍然 Established
• 端口 CRC 是否正常

任何异常都会告警，触发自动回滚。