📚 课程目录第3章 Spectrum软件系统与NOS概览

3. Spectrum软件系统与NOS概览

NVIDIA Spectrum 交换机的硬件能力最终要通过网络操作系统（NOS）释放。Spectrum 平台在软件层面提供两条主流路径：一是 NVIDIA 自家的 Cumulus Linux，二是开放社区主导的 SONiC。两者都运行在 Spectrum ASIC 之上，但设计哲学、配置模型和运维工具链差异明显。理解这些差异，是后续做选型、初始化和日常运维的前提。

两条 NOS 路径：Cumulus Linux 与 SONiC

Cumulus Linux 是 NVIDIA 面向 Spectrum 深度优化的 Linux 发行版，采用“Linux 原生 + 声明式网络配置”的思路。它的核心特征是：整个交换机就是一台 Linux 主机，/etc/network/interfaces 或 NVUE（NVIDIA User Experience）模型负责描述期望状态，路由协议由 FRR 提供，EVPN/VXLAN 通过 ifupdown2 与 FRR 协同。Cumulus 的配置是“意图式”的——你声明接口、VLAN、BGP 邻居应该是什么样，系统负责收敛到该状态。

SONiC 则是微软开源、现由 Linux 基金会托管的容器化 NOS。它把 BGP、LLDP、SNMP、Redis 数据库等拆成独立容器，通过 config_db 这一集中式数据库驱动所有子系统。SONiC 的优势在于多厂商硬件统一运维、生态开放、与大型云数据中心自动化体系天然契合。在 Spectrum 上，SONiC 通过 SAI（Switch Abstraction Interface）调用 ASIC，NVIDIA 提供对应的 SAI 适配层。

选择上可以这样判断：如果团队熟悉 Linux 网络栈、需要成熟的 EVPN 多租户方案和 NVUE 声明式接口，Cumulus Linux 更顺手；如果目标是云化、容器化、与 Kubernetes 或大规模自动化平台对接，SONiC 的开放数据库模型更合适。两者都支持 ZTP、NetQ 和标准路由协议，差异主要在配置入口和运维习惯。

NetQ：跨 NOS 的遥测与验证平台

NetQ 是 NVIDIA 的现代网络运维平台，它不替代 NOS，而是从交换机采集遥测数据，做状态验证、路径追踪和故障定位。NetQ 的采集方式有两种：一是基于 Netlink 的轻量代理，二是基于 gNMI 的流式遥测。在 Cumulus 和 SONiC 上都能部署，因此它天然适合混合 NOS 环境。

NetQ 最实用的能力是“验证”而非“展示”。例如，你可以用 netq check bgp 检查所有节点的 BGP 会话是否全部建立，用 netq trace 从源到目的逐跳追踪 VXLAN 隧道是否贯通。它把“配置是否正确”转化为“状态是否符合预期”，这对 EVPN 多租户场景尤其重要。日常运维中，NetQ 常与 ZTP 配合：设备上电后自动注册到 NetQ，运维人员立即获得全局拓扑和健康视图。

ZTP 零接触配置：从开箱到纳管

ZTP 解决的是“设备上电后如何自动获得正确配置”的问题。Spectrum 交换机的 ZTP 流程基于标准 DHCP 和 HTTP/TFTP：交换机启动后，管理口发出 DHCP 请求，DHCP 服务器在响应中通过 Option 67 或厂商自定义 Option 返回引导脚本 URL；交换机下载并执行该脚本，脚本再拉取完整配置、安装许可证、注册到 NetQ 或自动化平台。

一个典型的 ZTP 脚本会做四件事：设置管理 IP 和默认网关、配置 NTP 和 DNS、拉取并应用完整配置、上报注册信息。以 Cumulus 为例，脚本通常放在 /var/lib/ztp/ 下，由 ztp 服务在首次启动时执行。SONiC 则通过 sonic-ztp 服务读取 DHCP Option 或本地 ztp.json 完成类似动作。关键点是：ZTP 脚本必须幂等，重复执行不会破坏已配置状态；同时要设置超时和失败回退，避免设备卡在引导阶段。

ZTP 的 DHCP 服务器需要为每台设备准备唯一标识（如序列号或 MAC），并映射到对应的配置模板。生产环境中建议用模板引擎（如 Jinja2）生成每台设备的差异化配置，而不是为每台设备手工维护一份完整配置。

系统初始化与基础运维

设备完成 ZTP 后，进入日常运维阶段。基础运维围绕几个核心动作展开：查看接口状态、检查路由邻居、验证 VXLAN 隧道、采集日志和升级固件。

在 Cumulus 上，常用命令包括 nv show interface 查看接口状态，nv show router bgp 查看 BGP 邻居，net show evpn vni 查看 EVPN VNI 状态。在 SONiC 上，对应命令是 show interface status、show ip bgp summary、show vxlan tunnel。两者都支持 show techsupport 收集诊断信息。

固件升级是运维中风险较高的操作。Spectrum 平台通常通过 ONIE 或 NOS 内置的升级工具完成。升级前应确认当前 NOS 版本与目标版本的兼容性，备份配置，并在维护窗口内执行。升级后要验证 ASIC 初始化是否成功、所有端口是否正常 up、路由协议是否重新收敛。

# Cumulus Linux 示例：查看 BGP 邻居与 EVPN VNI
nv show router bgp neighbor
nv show evpn vni

# SONiC 示例：查看 BGP 摘要与 VXLAN 隧道
show ip bgp summary
show vxlan tunnel

# 通用：收集诊断信息
show techsupport

基础运维中还有一个容易被忽视的环节：时间同步。EVPN 和 NetQ 都依赖准确的时间戳来关联事件。建议在 ZTP 阶段就配置 NTP，并确保所有交换机指向同一组 NTP 服务器。时间偏差过大会导致日志无法关联、NetQ 验证结果异常。

ZTP 脚本中不要硬编码明文密码或密钥。应使用一次性令牌或从安全存储中拉取凭据，并在首次配置完成后立即更换默认密码。生产环境中，ZTP 服务器本身也需要高可用和访问控制。

总结来看，Spectrum 的软件系统提供了从 Cumulus Linux 到 SONiC 的灵活选择，NetQ 统一了跨 NOS 的运维视图，ZTP 解决了规模化部署的自动化问题，而系统初始化与基础运维则决定了网络长期运行的稳定性。理解这四者的关系，比单独记住某条命令更重要。