9. 网络#

VLAN 自动化已经在实验室运行了三周。三台交换机，每个厂商各一台，所有工作流都能通过。团队信心满满。在第一次生产运行中，800 台园区交换机中有 23 台失败了，全部是 HPE 的，全部运行着没有人记录在案的固件版本。

Playbook 在推送 VLAN 配置后检查每台设备的错误响应。在现代 HPE 固件上，一个已存在的 VLAN 返回错误代码 duplicate-vlan。在这个旧固件版本上，同样的情况返回 vlan-exists。Playbook 被写成将 duplicate-vlan 视为幂等信号，意思是"这已经存在，没问题。“但它没有被写成能处理 vlan-exists，所以它将该响应视为失败。三分之一的 HPE 机队报告失败。回滚干净地运行了。应用团队的工单在网络团队手动审查哪些交换机实际上已配置、哪些没有配置时，又等了三个小时。

自动化没有错，是网络有自己的意见，但没有人将其记录下来。

六个月后，同一个团队有了一个镜像 B 楼的 containerlab 拓扑：24 台交换机，匹配厂商镜像，HPE 节点锁定到 Source of Truth (SoT) 中记录的生产固件版本。在对该拓扑首次测试运行 VLAN 工作流时，8 个 HPE 节点恰好以那个错误代码失败了。团队将 vlan-exists 添加到 HPE 适配器中的幂等响应列表。重新运行：全部 24 个节点通过。生产部署：800 台交换机，零失败。

区别不在于更好的代码，而在于代表现实的测试环境。

本章解决在第 2 部分中一直隐含的模块：网络本身。到目前为止构建的每个构建块都是由自动化团队设计的，按照其有文档记录的接口运行。网络是继承来的。它有各种怪癖、多样化的接口、固件不一致性以及因厂商、平台和软件代次不同而变化的能力。第 9 章解决两个问题：我们需要从网络获得什么才能使自动化可靠，以及我们如何在接触生产之前安全地验证自动化逻辑？

9.1. 基础概念#

9.1.1. 背景#

第 3 章将网络作为 NAF Framework 中七个模块之一引入：自动化团队不"拥有"的唯一模块（它在网络工程的范围内）。他们配置它、观测它并对其意图建模，但他们没有构建操作系统、数据模型或 API 接口。这种依赖关系影响了其上方平台中的每个设计决策。

第 5 章详细介绍了 Executor 的写入路径：自动化角色、参数化任务和幂等性检查如何运作。第 5 章视为理所当然的是，另一端的设备暴露了可靠、一致的接口。第 9 章解决这个假设是否成立，以及当它不成立时该怎么做。

第 6 章介绍了 Collector 的读取路径：gRPC Network Management Interface (gNMI) 流式遥测、SNMP 轮询和数据规范化管道。第 9 章涵盖这些路径的设备端先决条件：网络设备必须满足什么条件，采集器才能一致地从中读取数据。

第 9 章关闭了第 2 部分。前六章构建了自动化平台：一个存储意图的地方、一种执行意图的方式、一种观测结果的方式、一个协调一切的引擎，以及将其暴露给消费者的界面。本章解决平台一直指向的那个东西。

9.1.2. 目标#

三个目标定义了网络模块对自动化平台的贡献：

1. 理解并导航完整的网络基础设施谱系。 任何大规模自动化平台都可能同时与园区交换机、数据中心织构、云 VPC、Kubernetes 覆盖层、覆盖控制器以及遗留设备交互。每种类型暴露不同的可编程接口。平台必须处理所有这些，而不是将其折叠成单一的最低公分母抽象。

2. 在接触生产之前验证自动化逻辑并支持新的网络架构设计。 仿真环境服务于两个目的：它们是预生产门控，逻辑错误、接口合同违规和设备特定怪癖在这里以实验室中几分钟的代价而不是生产事件中数小时的代价被发现；它们也是设计环境，在订购任何硬件之前，新的网络架构在这里被探索和验证。

3. 随着网络演进保持自动化平台稳定。 添加了新厂商，固件版本更改，新的基础设施类型到来。平台必须通过抽象策略而不是在网络每次改变时对每个工作流进行临时修补来吸收这种变化。

9.1.3. 支柱#

三个支柱支撑这些目标，每个功能对应一个：

1. 网络基础设施谱系和可编程接口：平台必须自动化的全范围网络类型，以及每种类型向执行器和采集器暴露的接口。
2. 仿真和测试环境：预生产验证的工具链。不同实验室环境类型的适用场景、它们如何连接到第 7 章的 Saga 模式，以及如何扩展它们。
3. 抽象策略：允许自动化平台随底层网络变化保持稳定的结构化方法，无论厂商、平台代次或接口协议如何。

9.1.4. 范围#

在范围内：

• 执行器和采集器访问网络设备的接口。NETCONF 和 gNMI 都支持配置和遥测操作；在每种使用场景中选择哪种，取决于运营优势，而不是协议专属性。协议通常在模块间共享；操作类型不同。
• 在生产之前验证自动化的测试环境和方法论
• 管理多厂商和多平台异构性的抽象策略
• 云、Kubernetes 和覆盖网络对自动化设计的影响

不在范围内：

• 配置生成和模板渲染（Source of Truth (SoT)，第 4 章）
• 执行机制：自动化工具如何执行任务（执行器，第 5 章）
• 遥测采集管道：指标如何流入时间序列数据库（Observability，第 6 章）

边界是一致的：第 9 章涵盖每个接口的网络侧，而不是平台侧。

9.2. 功能#

网络模块是 NAF 框架中自动化平台不控制的唯一构建块。它只能按照网络允许的方式与网络交互。前五章中的每个设计决策，意图如何存储、执行如何运行、遥测如何采集、工作流如何协调、消费者如何服务，最终都归结为关于连接另一端的网络设备支持什么的问题。本章直接检视这个约束。

graph LR

    subgraph Goals
        direction TB
        A1[Navigate the full network infrastructure spectrum]
        A2[Validate automation before production]
        A3[Keep the platform stable as the network evolves]
    end

    subgraph Pillars
        direction TB
        B1[Network infrastructure spectrum and programmable interfaces]
        B2[Simulation and testing environments]
        B3[Abstraction strategies]
    end

    subgraph Functionalities
        direction TB
        C1[Programmable Interfaces]
        C2[Simulation and Testing Environments]
        C3[Abstraction Strategies]
    end

    A1 --> B1 --> C1
    A2 --> B2 --> C2
    A3 --> B3 --> C3

    classDef row1 fill:#eef7ff,stroke:#4a90e2,stroke-width:1px;
    classDef row2 fill:#ddeeff,stroke:#4a90e2,stroke-width:1px;
    classDef row3 fill:#cce5ff,stroke:#4a90e2,stroke-width:1px;

    class A1,B1,C1 row1;
    class A2,B2,C2 row2;
    class A3,B3,C3 row3;

9.2.1. 可编程接口#

网络天然是异构的。它不是一个东西，而是多年来积累的基础设施类型的谱系，通常由不同团队并行构建（所有权和组织边界在第 13 章中探讨），每种都有自己的接口模型、抽象级别和自动化成熟度。现代自动化平台可以同时跨越园区交换机、数据中心织构、云 VPC、覆盖控制器、Kubernetes 集群、服务提供商 WAN 基础设施和超大规模管理的转发平面。平台必须处理所有这些。基础设施类型决定了可用的接口；自动化平台适应这一现实，而不是要求统一接口。

9.2.1.1. 网络基础设施谱系#

以下是对你可能需要应对的不同网络基础设施场景的高层次回顾，取决于你公司的性质：

• 园区和分支交换是我在第 2 部分中使用的核心场景示例：多厂商物理交换机（Cisco、Arista、HPE、Extreme）。现代园区设备同时暴露 Command Line Interface (CLI)、NETCONF 和 gRPC Network Management Interface (gNMI)。过去五到七年的设备自动化成熟度很高；仍运行十年前固件的遗留设备则参差不齐。

• 数据中心织构拓扑通常是叶脊结构，通常来自较小的厂商集合：Arista、Cisco Nexus 或自动化原生的开放网络平台。接口统一性高于园区；变更管理更严格。EVPN/VXLAN 覆盖层在织构上方添加了一个管理平面，可能有自己的 API，与单个设备接口分离。基于 SONiC 的平台（Cisco 8000、Nvidia Spectrum）在受超大规模影响的数据中心部署中越来越普遍；其配置接口是结构化数据库而不是 CLI 或 NETCONF，在抽象策略部分进一步介绍。

• 服务提供商和 WAN 基础设施（运营商级路由器、MPLS 网络、段路由织构）有自己的自动化挑战：规模、协议复杂性，以及控制平面配置和流量工程策略的双重关注。NETCONF 和 YANG 模型在这一领域已经成熟；Cisco IOS-XR 和 Junos 等厂商有成熟的 YANG 覆盖。自动化平台通常针对控制器（SR-PCE、Crosswork、NSO）而不是单个设备。

• 云网络：AWS VPC、Azure VNet、GCP VPC 等。具有最终一致性语义的 REST API。没有"推送配置"并等待同步确认的概念。执行器处理异步操作：创建、轮询、验证。基础设施即代码工具自然适合这种模型。自动化平台必须考虑不同的一致性模型，而不是假设同步应用并确认的语义。

• SD-WAN 和覆盖网络（Cisco SD-WAN、Versa、VMware VeloCloud）由控制器管理。自动化目标是控制器 API，而不是单个设备。物理底层仍然存在，但完全通过覆盖层的抽象来管理。这影响执行和可观测性：执行器向控制器写入策略；关于流量、路径选择和策略执行的遥测也通过控制器的北向接口流动，而不是直接来自物理底层设备。

• Kubernetes 网络在 CNI 层完全颠覆了设备模型。网络通过 Kubernetes API 对象定义：NetworkPolicy、Services、Ingress，以及来自 Cilium、Calico 或 Flannel 等 CNI 插件的自定义资源。设备作为自动化目标消失了，Kubernetes API 是接口。网络策略是代码，而不是设备配置。这是其他人正在向其收敛的模型：声明式意图、控制器协调状态、无直接设备访问。

• DPU 和智能网卡（Nvidia BlueField、Intel IPU、Marvell Octeon）代表了网络处理发生位置的转变。在现代数据中心，DPU 与 CPU 一起安装在每台服务器上，以卸载网络功能：VXLAN 封装、加密、防火墙策略执行、负载均衡和微分段。这将这些功能从主机 CPU 和网络设备卸载到智能网卡固件。对自动化的影响：“网络设备"不再仅仅是机架中的交换机或路由器。以前通过专用网络设备 API 管理的功能现在通过 DPU 管理平面及其厂商 SDK 管理，这是标准 NETCONF 和 gRPC Network Management Interface (gNMI) 工具尚未能干净访问的新接口类别。

• 开放网络（SONiC、DENT、OPX）在商品硬件上运行 Network Operating System (NOS) 软件。SONiC 的配置接口是具有 Yet Another Next Generation (YANG) 结构化模式的 Redis 数据库，在结构上不同于 CLI 或 NETCONF，并且天然支持编程访问。在受超大规模影响的数据中心和大规模企业数据中心部署中越来越普遍。SONiC 值得注意，因为它从一开始就为自动化而设计：接口是结构化数据库，而不是为程序化访问而改造的 CLI。

• 虚拟网络功能与物理基础设施在许多环境中共存。通过策略定义路径插入流量的软件防火墙、跨应用集群管理流量分发的虚拟负载均衡器、基于软件的 BGP 路由反射器：这些都是自动化目标，使用从厂商 REST API 到 NETCONF 的管理接口。它们通常使用相同的 SoT 和执行器与物理清单一起管理，但需要单独的适配器路径，因为它们的接口模型与物理设备不同。

• 无线控制器（Cisco DNA、Aruba Central、Juniper Mist）基于控制器；自动化目标是控制器 API。每当 VLAN 配置扩展到无线 SSID 以及有线交换机端口时就相关，就像园区场景中那样。

重点不是详尽列举每种基础设施类型，而是确立：自动化任何非平凡网络的平台同时与多种类型交互。执行器和采集器必须将每种操作路由到正确的接口类型。Source of Truth (SoT) 必须在单个接口之上的级别对意图建模。网络的复杂性是平台被构建来吸收的设计约束。

9.2.1.2. 接口类型#

每种基础设施类型向自动化平台暴露一种或多种接口类型。同一台物理交换机可能同时暴露所有三种。平台适应可用的接口，偏好反映可靠性、结构和规模。没有哪种接口类型是通用要求；正确的选择取决于设备支持什么以及操作需要什么。

• SSH 上的 Command Line Interface (CLI)是通用的、遗留的且脆弱的。当固件更改输出格式或添加新字段时，屏幕抓取和文本解析会中断。错误代码在厂商之间和固件版本之间不一致。CLI 仍然是旧设备的唯一选项。建议是最小化其使用，避免构建依赖它的工作流，除了那些没有其他选择的设备（最后手段）。设置接口描述如下所示：

interface GigabitEthernet0/1
 description uplink-to-core

• NETCONF是结构化的、事务性的，并且在工作时是正确的。它支持原子操作和回滚，其数据模型是机器可解析的。传输层通常可靠；数据模型层是差距所在。厂商 YANG 模型质量差异显著：设备可能声称支持 NETCONF，但对于平台需要的功能具有不完整或专有的模型。IETF 和 OpenConfig YANG 模型标准化意图层；厂商原生 YANG 模型填补空白。通过 NETCONF 的相同接口描述：

<config>
  <interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
    <interface>
      <name>GigabitEthernet0/1</name>
      <description>uplink-to-core</description>
    </interface>
  </interfaces>
</config>

• RESTCONF是 NETCONF 的基于 HTTP 的等价物，使用相同的 YANG 模型，但通过 REST 语义暴露。当团队对 HTTP 工具比对 NETCONF 的 XML/SSH 传输更熟悉时，它很有用。数据模型是相同的；只有传输方式不同。厂商支持不如 NETCONF 统一。通过 RESTCONF 的相同接口描述：

PATCH /restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet0%2F1
Content-Type: application/yang-data+json

{
  "ietf-interfaces:interface": {
    "name": "GigabitEthernet0/1",
    "description": "uplink-to-core"
  }
}

• gRPC Network Management Interface (gNMI) 和 gNOI是基于 gRPC Remote Procedure Call (gRPC) 的协议。gRPC Network Management Interface (gNMI) 处理遥测和配置读/写；gNOI 处理操作命令。现代且对规模友好。厂商支持在 Arista 和较新的 Cisco 平台上成熟；在 HPE 和遗留设备上参差不齐。第 6 章从采集器的角度介绍了 gNMI。第 9 章涵盖设备端先决条件：设备必须在平台目标的操作系统版本上支持 gNMI 订阅。运行 SONiC 的 Nvidia Spectrum 交换机原生暴露 gNMI 以及 CONFIG_DB 接口，使其成为配置和遥测方面最支持自动化的平台之一。通过 gNMI SetRequest 的相同接口描述：

path:  /interfaces/interface[name=GigabitEthernet0/1]/config/description
value: "uplink-to-core"

• 厂商 REST API（eAPI、NX-API、Cumulus NVUE 等）是机器可读的，但在厂商之间没有标准化。当 NETCONF 或 gNMI 对特定操作缺失或不完整时，作为填充工具很有用。Nvidia Cumulus 交换机将 NVUE（具有一致 JSON 模式的结构化 REST API）作为其主要编程接口暴露；Arista 和 Cisco Nexus 分别将 eAPI 和 NX-API 作为 NETCONF 的替代暴露。将这些视为适配器层关注点，而不是厂商中立平台的基础。通过 Arista eAPI（HTTPS 上的 JSON-RPC）的相同接口描述：

{
  "jsonrpc": "2.0",
  "method": "runCmds",
  "params": {
    "version": 1,
    "cmds": [
      "interface GigabitEthernet0/1",
      "description uplink-to-core"
    ],
    "format": "json"
  },
  "id": "1"
}

• 云和控制器 API遵循具有最终一致性的 REST 模式。异步操作模型是设计要求，而不是需要绕过的限制。对于 SD-WAN、无线和 DPU 管理平面，控制器 API 通常是唯一可用的接口。向 AWS VPC 添加描述说明了这种模式：异步提交的标记资源更新，没有变更已被应用的同步确认：

POST https://ec2.eu-west-1.amazonaws.com/ HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Authorization: AWS4-HMAC-SHA256 ...

Action=CreateTags
&ResourceId.1=vpc-0a1b2c3d4e5f67890
&Tag.1.Key=Description
&Tag.1.Value=uplink-to-core
&Version=2016-11-15

• Kubernetes API是声明式的、控制器协调的，并且在厂商之间一致。NetworkPolicy、Services 和 CNI 自定义资源是自动化目标。没有直接的设备访问；API 服务器是唯一的接口。app-payments 服务的网络隔离策略：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: app-payments-isolation
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: app-payments
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: app-payments

• **SONiC CONFIG_DB（Redis）**是基于 SONiC 平台的原生接口。它不是在操作系统之上分层的协议，而是操作系统自己的配置存储：具有 YANG 结构化模式的 Redis 数据库。自动化直接将 JSON 条目写入 CONFIG_DB；SONiC 内部的 orchagent 守护进程将意图协调到硬件转发表。gNMI 并行提供用于遥测读取。这在架构上不同于 CLI、NETCONF 或 REST：接口就是数据存储本身。9.2.3.4 节对此进行了更深入的介绍。通过 JSON 补丁（使用 config load 应用）写入 CONFIG_DB 的相同接口描述：

{
  "PORT": {
    "Ethernet0": {
      "description": "uplink-to-core",
      "admin_status": "up"
    }
  }
}

9.2.1.3. 每台设备的接口选择#

当设备暴露多个接口时，平台必须为每种操作类型选择一种，并一致地维护该选择。同时暴露 Command Line Interface (CLI)、NETCONF 和 gRPC Network Management Interface (gNMI) 的园区交换机需要一个决策，而不是因工作流或工程师偏好而变化的混搭方法。

按操作类型应用的推荐层次结构。gRPC Network Management Interface (gNMI) 和 NETCONF 都支持配置写入和遥测读取；以下偏好反映运营优势，而不是协议专属性：

• gRPC Network Management Interface (gNMI) 优先用于遥测采集（流式订阅、结构化、对规模友好；gNMI Set 也是有效的配置路径）
• NETCONF 优先用于配置（事务性、可回滚；NETCONF get 和 get-config 同样有效用于状态读取）
• RESTCONF 或厂商 REST API 作为 NETCONF 对特定功能不完整时的备选
• Command Line Interface (CLI) 作为仅用于遗留设备的最后手段

执行器需要从接口获得的：Idempotency 或至少能可靠区分"已存在"与"失败"的错误代码、结构化错误响应，以及应用后的状态验证能力。HPE 的 vlan-exists 与 duplicate-vlan 问题恰恰是第二个条件的失败：错误代码语义在固件版本之间发生了变化。

采集器需要的：结构化读取、流式遥测订阅，以及一致的数据模型，使可观测性层不需要每台设备专用的解析器。gRPC Network Management Interface (gNMI) 是支持的情况下首选的订阅协议：它在设备处是结构化的、分层的和模式验证的，消除了 SNMP 时代采集中占主导地位的每台设备文本解析。但任何提供结构化、及时数据的订阅机制都能发挥相同的作用。对于 gNMI 不可用的遗留设备，SNMP 轮询仍然有效。Syslog 为基于日志的可观测性提供结构化事件。OpenTelemetry（OTel）是一个值得跟踪的新兴标准：最初为应用可观测性而设计，正在逐渐被采用为网络遥测、指标和追踪的厂商中立传输。采集器的协议选择是设备支持什么的函数；可观测性层不应该需要知道使用了哪种传输方式。

Source of Truth (SoT) 记录平台操作的每个设备属性的预期状态：预期的 VLAN 配置、预期的 BGP 邻居关系、预期的接口描述，以及预期的操作系统版本。操作系统版本在这里值得特别提及，因为它不仅影响配置漂移检测，还影响适配器路径选择本身：当同一厂商的固件在版本之间行为不同时，执行器按操作系统版本分支。这不是操作系统版本的特例；它是应用于平台管理的每个属性的相同意图与现实模式。期望的操作系统版本是运维团队批准的；运行中的版本是可观测性观测到的。当它们出现偏差时，这个偏差是一个信号：设备可能落后于计划的升级，或者发生了计划外的变更。平台需要两个数据点来决定是继续还是阻止。

这个区别在实践中很重要。SoT 说设备应该运行 AOS-CX 10.13。采集器报告它正在运行 10.12.1006。平台有两个选项：阻止执行直到操作系统版本协调，或使用 10.12 适配器路径继续。正确答案取决于团队的变更管理策略，但平台需要两个数据点来做决定。SoT 提供意图；可观测性提供现实。

9.2.2. 仿真和测试环境#

网络是生产基础设施。与应用后端不同，默认情况下没有暂存服务器可以测试。构建一个暂存服务器是这个功能的工作。

测试网络自动化历来比测试应用代码更难。网络是一个分布式系统，有许多自动化团队不控制的组件：对等点的邻居 AS、上游中转提供商、客户管理的 CPE、无线客户端以及第三方运营的云基础设施。测试路由策略变更的服务提供商无法启动来自中转提供商的模拟 BGP 对等点来验证完整行为。测试 WAN 故障转移工作流的企业无法控制 MPLS 提供商如何响应。本节描述的仿真环境是最佳可用替代品：它们重现团队控制的内容，接受无法控制的内容的限制，并将验证集中在错误实际存在的逻辑层。

来自第 2 章的测试金字塔（单元、集成、端到端）在这里直接适用。单元测试隔离验证单个自动化模块，通常使用模拟设备响应。集成测试验证多步骤交互：SoT API 返回预期的数据结构，执行器正确翻译它，正确处理设备响应。端到端测试对行为类似真实网络设备的东西验证完整工作流。仿真环境是端到端层。

9.2.2.1. 环境类型#

正确的环境取决于测试需要验证什么。有一个从低保真度、低成本环境（适合常规 CI/CD 管道）到高保真度环境（值得为生产置信度测试投资）的谱系。

• 基于容器的仿真使用轻量级网络操作系统镜像作为容器运行，通过虚拟链路连接。拓扑启动需要几秒钟。这是常规 CI/CD 的实用默认值：自动化团队在每次变更时对容器化拓扑运行相同的工作流代码，在生产之前捕获逻辑错误。数据平面行为不被复制，但控制平面行为和管理接口行为足以测试自动化逻辑。

• 基于虚拟机的仿真将完整的 NOS 镜像作为虚拟机运行。它提供更广泛的厂商覆盖、更真实的 NOS 行为（包括数据平面），适用于协议设计测试和多厂商互操作性场景。权衡：更高的资源成本、更慢的启动速度，以及与自动化管道的有限集成。对于常规提交级别测试不实用。

• 物理硬件实验室由许多大型组织维护：一架实际的交换机和路由器，通常镜像生产架构模式。这为特定硬件行为、性能测试以及仿真无法准确重现设备行为的场景提供最高保真度。成本很显著：资本投资、电力和空间，以及使实验室拓扑与生产架构同步的运营开销。偏离生产模式的实验室提供虚假的信心。价值是真实的；维护纪律是挑战。

• 数字孪生是生产拓扑的实时副本，由真实数据源（相同的设备模型、拓扑和当前预期配置）和来自可观测性的当前状态提供数据。数字孪生镜像生产实际上现在是什么样子，而不是近似值。运营成本很显著：在数字孪生和生产之间维护同步需要持续协调。这是成熟度级别的投资，适合已经在规模上验证了其平台并需要最高级别的预生产置信度的团队。

基于容器的仿真是大多数团队的实用起点。它在几秒内启动，与 CI/CD 管道原生集成，并涵盖大多数自动化使用案例中使用的现代园区和数据中心设备。构建这个环境的投资在它防止的第一个事件中就能收回成本。

9.2.2.2. 基于容器和虚拟机仿真的工具链#

基于容器的生态系统有几个角色不同但经常被混淆的工具：

• containerlab 实例化并连接基于容器的网络操作系统镜像。由 Roman Dodin 创建，在网络自动化社区中被广泛采用，containerlab 已成为基于容器的网络实验室的事实标准。它直接编排 Docker 容器（Arista cEOS、FRR、SONiC、VyOS 等），并用拓扑文件中定义的虚拟链路连接它们。containerlab 启动拓扑，在几秒内提供运行中的实验室。一个最小的三节点拓扑文件如下所示：

  随着团队规模扩大，在单台机器上运行 containerlab 成为瓶颈。clabernetes 将 containerlab 拓扑分布在 Kubernetes 集群上，允许并行运行多个仿真，使团队能够随平台增长扩展其预生产门控。

name: building-b-sim
topology:
  nodes:
    cisco-1:
      kind: ceos
      image: ceos:17.9.4
    arista-1:
      kind: ceos
      image: ceos:4.31.2F
    hpe-1:
      kind: vr-aoscx
      image: vrnetlab/vr-aoscx:10.12.1006
  links:
    - endpoints: ["cisco-1:eth1", "arista-1:eth1"]
    - endpoints: ["arista-1:eth2", "hpe-1:eth1"]

• netlab 在 containerlab 之上抽象拓扑定义。由 Ivan Pepelnjak 创建，netlab 让工程师描述拓扑应该完成什么，而不是如何连线：“这三个节点运行 BGP”，“这些节点在同一个 VLAN 中”。netlab 解释该描述并将其渲染成 containerlab 拓扑文件加上每个厂商的初始设备配置。将其视为实验室的声明式描述：工程师定义服务；netlab 生成基础设施定义。当目标是对镜像生产网络模型的拓扑测试自动化逻辑时，netlab 是正确的起点；containerlab 是实例化它的工具。相同三节点场景的最小 netlab 拓扑：

nodes:
  cisco-1:
    device: iosxe
    image: ceos:17.9.4
  arista-1:
    device: eos
  hpe-1:
    device: aoscx

links:
  - cisco-1:
    arista-1:
  - arista-1:
    hpe-1:

vlans:
  app-payments:
    id: 210
    links: [ cisco-1, arista-1, hpe-1 ]

• vrnetlab 连接基于容器和基于虚拟机的仿真。某些厂商不提供原生容器镜像。vrnetlab 将厂商虚拟机镜像包装在容器内，使其可以在 containerlab 拓扑中使用。这是在不切换到基于虚拟机的平台的情况下，在 containerlab 环境中测试 Cisco IOS-XR 或 Junos 设备的方法。

• EVE-NG 和 GNS3 是基于虚拟机的仿真平台，提供广泛的厂商覆盖、基于 GUI 的拓扑设计和包括数据平面转发的完整 NOS 行为。权衡：更高的资源使用、更慢的启动速度，以及有限的 CI/CD 集成。这些是协议和设计测试、遗留平台以及多厂商互操作性场景的正确选择。

• Cisco Modeling Labs 是 Cisco 的商业虚拟机实验室平台，具有用于部分 CI/CD 集成的 REST API。对于需要在托管的共享实验室中访问 IOS-XE、IOS-XR 和 NX-OS 虚拟机的以 Cisco 为中心的环境来说是正确的选择。

9.2.2.3. 验证框架#

验证设备是否正确支持给定的接口协议或 YANG 路径是第 5 章（执行）和第 6 章（可观测性）中描述的工作的一部分：执行章节涵盖在生产工作流中依赖配置接口之前验证它；可观测性章节涵盖验证采集路径并确认订阅以预期格式返回数据。

一个场景在仿真上下文中值得特别处理：批次验证。在仿真通过但在提交到完整生产范围之前，一些团队针对第一批次进行结构化验证。pyATS 提供了一个用于编写具有丰富解析和状态比较的结构化设备交互测试的测试框架。Robot Framework 是一个更广泛的关键字驱动的测试自动化框架，具有特定于网络的库。两者都允许团队将预期的变更后状态编码为可执行断言：在 VLAN 210 部署到批次 1 后，确认 VLAN 210 存在于所有交换机上，确认接口关联正确，并确认可观测性层看到预期状态。这直接连接到 9.2.2.4 节：将通过仿真运行与在进行下一批次之前的真正运营置信度分开的结构化验证层。

部署后断言 VLAN 存在的最小 pyATS 测试：

from pyats import aetest

class VlanValidation(aetest.Testcase):
    @aetest.test
    def verify_vlan_exists(self, device):
        output = device.parse('show vlan brief')
        assert 210 in output['vlans'], f"VLAN 210 missing on {device.name}"

    @aetest.test
    def verify_vlan_name(self, device):
        output = device.parse('show vlan brief')
        assert output['vlans'][210]['name'] == 'app-payments'

在 Robot Framework 中使用 NAPALM 库的相同检查，具有明确的设置和可读的关键字名称：

*** Settings ***
Library    Collections
Library    napalm    WITH NAME    NAPALM

*** Variables ***
@{DEVICES}    cisco-1    arista-1    hpe-1

*** Test Cases ***
VLAN 210 Is Present On All Switches After Deployment
    FOR    ${hostname}    IN    @{DEVICES}
        Connect And Check VLAN    ${hostname}    210    app-payments
    END

*** Keywords ***
Connect And Check VLAN
    [Arguments]    ${hostname}    ${vlan_id}    ${vlan_name}
    NAPALM.Open    ${hostname}
    ${vlans}=    NAPALM.Get VLANs
    Dictionary Should Contain Key    ${vlans}    ${vlan_id}
    Should Be Equal    ${vlans}[${vlan_id}][name]    ${vlan_name}
    [Teardown]    NAPALM.Close

9.2.2.4. 仿真作为预生产 Saga 门控#

第 7 章描述了 Saga 模式：一个多步骤工作流，其中每个步骤都有相应的补偿操作，在后续步骤失败时运行。Saga 在生产中处理故障。仿真在 Saga 开始之前添加了一个步骤：首先对仿真环境运行工作流。如果仿真运行失败，不会发生生产变更。只有当仿真通过时，工作流才会进行到生产目标。

flowchart LR
    SoT["SoT export (topology + OS versions)"]
    Lab["Simulation environment (containerlab topology)"]
    Workflow["Workflow execution (same code as production)"]
    Pass{Pass?}
    Prod["Production execution (Orchestrator: full scope)"]
    Fix["Investigate and fix (no production impact)"]

    SoT --> Lab --> Workflow --> Pass
    Pass -- Yes --> Prod
    Pass -- No --> Fix --> Workflow

这是预生产门控：仿真作为生产 Saga 范围开始之前的第一个检查。仿真中的失败在任何生产设备被触及之前就被发现了。

实用实施：

1. 真实数据源导出目标范围的拓扑定义，包括每台设备的操作系统版本。
2. 仿真环境使用匹配的厂商镜像实例化，操作系统版本固定以匹配 SoT 预期状态。
3. 将在生产中运行的相同工作流首先对仿真目标运行。
4. 仿真中失败的任何步骤在生产执行继续之前都会触发调查。

渐进式部署批次

通过仿真并不意味着一次性部署到整个生产范围。对于大规模部署，仿真是一系列渐进式更大批次中的第一个门控，每个门控都有自己的验证检查，然后才能进行下一批次。这是我最喜欢的模式之一，可以对关键部署建立信任，类似于软件开发中流行的金丝雀模式。

将新工作流部署到 100 个数据中心的团队可能这样结构：仿真（虚拟拓扑）→ 1 个试点站点 → 2 个站点 → 4 个 → 8 个 → 16 个 → 剩余站点。每批次验证工作流在上一批次上的行为是否正确，然后再扩展。如果批次 4 出现仿真未捕获的故障（特定硬件行为、特定站点状态），部署停止，问题被修复，批次序列从故障点恢复。

flowchart LR
    Sim["Simulation"] --> W1["Wave 1 (1 site)"] --> W2["Wave 2 (2 sites)"] --> W3["Wave 3 (4 sites)"] --> W4["Wave N (full scope)"]
    W1 -- Fail --> Fix["Investigate + fix"]
    W2 -- Fail --> Fix
    W3 -- Fail --> Fix
    Fix --> Sim

编排器控制批次进展。SoT 按站点、楼栋或设备组范围化每个批次。批次之间的验证门控是明确的工作流步骤：编排器在继续之前检查可观测性层的预期状态。这种模式适用于无论范围是 100 个数据中心还是 800 台园区交换机：原则是在以每次成功批次建立信心的同时，限制任何不可预见故障的爆炸半径。

仿真的局限性：容器镜像不能重现所有固件行为。容器镜像通常运行最新的 NOS 代码；较旧的固件特定怪癖可能无法重现，除非镜像固定到特定版本。仿真捕获逻辑错误、接口合同违规、Yet Another Next Generation (YANG) 模型差距和拓扑级故障。它不能保证生产中遇到的每种可能的设备状态都已被测试。目标是显著的风险降低，而不是零风险。

雪花问题：当生产网络遵循一致的架构模式时，仿真最可靠。具有数百个单独定制配置（每个都有独特状态和历史）的网络更难在仿真中准确表示。这是自动化架构原则（标准化设计模式、黄金模板、SoT 驱动的配置）使测试更有效的原因之一：设计良好的网络更容易仿真。仿真的价值与它所代表的网络设计质量成复利。构建这种可重复性需要与网络工程师密切合作，而不仅仅是自动化工程师：了解哪些站点真正相同、哪些携带隐藏例外的网络工程师才能使仿真具有代表性。仿真质量是网络设计规范和自动化平台的共同输出。

9.2.3. 抽象策略#

网络天然是异构的，不仅仅是厂商不同的意义上。任何在规模上运营的自动化平台同时跨越物理交换、云基础设施、覆盖控制器、服务提供商 WAN 基础设施和遗留设备。每种都说不同的语言。自动化平台在每次添加新基础设施类型时都不应该被重建。

本节是关于设计自动化层以吸收变化而不是在变化下崩溃：不仅处理今天的异构性，而且为明年将要添加的基础设施类型进行设计。

现代自动化平台同时跨越多个基础设施域。干净处理这一问题的架构适用于无论运营商是大型企业、同时管理 WAN 和客户边缘的服务提供商，还是在云网络覆盖层旁边运行数据中心织构的超大规模提供商。关键点：执行器通过相同的设备接口（物理设备的 gRPC Network Management Interface (gNMI)/NETCONF、云和控制器的 REST）写入和采集器读取，所以接口协议是两个模块的共同关注点，而不是每个模块单独的设计选择。

flowchart LR
    SoT["Source of Truth"]
    Orch["Orchestrator"]
    Obs["Observability"]

    subgraph Physical["Physical domain"]
        PhysIF["Network interface (NETCONF/gNMI)"]
        PhysNet["Campus, DC fabric, WAN gear"]
        PhysIF --- PhysNet
    end

    subgraph Cloud["Cloud domain"]
        CloudIF["Network interface (async REST)"]
        CloudNet["Cloud VPCs / networking"]
        CloudIF --- CloudNet
    end

    subgraph Overlay["Overlay domain"]
        OvIF["Network interface (controller API)"]
        OvNet["SD-WAN / MPLS PCE / overlay"]
        OvIF --- OvNet
    end

    SoT --> Orch
    Orch -->|Executor write| PhysIF
    Orch -->|Executor write| CloudIF
    Orch -->|Executor write| OvIF
    PhysIF -->|Collector read| Obs
    CloudIF -->|Collector read| Obs
    OvIF -->|Collector read| Obs

真实数据源将跨所有拓扑类型的完整意图建模为统一的服务模型。Orchestrator 包含按网络域的分支。执行器根据 SoT 数据路由到正确的适配器。可观测性跨越所有层，无论底层基础设施类型如何，都向同一数据管道提供数据。

关键的架构规范：分支发生在执行器和编排器中，而不是在 SoT 中。SoT 保存服务的单一意图模型。如何在不同基础设施类型上实现该意图是执行器关注的问题。

9.2.3.1. 异构性的维度#

在选择抽象策略之前，了解该策略必须吸收的异构性轴是有帮助的。并非所有异构性都是同一类问题。

每行都是平台必须处理的差异轴，无需 SoT 对其进行编码。意图模型保持统一；执行器和编排器吸收变化。以下各节中的策略解决如何做到这一点。

9.2.3.2. 执行器和采集器中的适配器模式#

最常见的起点和最广泛实施的策略。每个厂商一个自动化模块，所有模块都接受来自 SoT 的相同输入数据结构。SoT 存储厂商中立的意图；执行器的适配器层在执行时按厂商翻译。相同的原则适用于采集器：每个厂商或协议一个采集模块，所有模块都向可观测性管道提供规范化的数据结构。支持 gNMI 的厂商使用一个适配器；需要 SNMP 轮询或专有 REST 的厂商使用另一个。无论上游采集方法如何，可观测性层都看到相同的数据模式。

flowchart LR
    SoT["SoT intent (vendor-neutral): vlan_id=210, vlan_name=app-payments"]
    Exec["Executor"]
    CiscoA["Cisco adapter: IOS-XE NETCONF"]
    AristaA["Arista adapter: eAPI / EOS"]
    HPEA["HPE adapter: NETCONF + OS-version error handling"]
    CiscoD["Cisco Catalyst"]
    AristaD["Arista 7050"]
    HPED["HPE Aruba 6300"]

    CollGNMI["Collector: gNMI adapter"]
    CollSNMP["Collector: SNMP adapter"]
    Obs["Observability pipeline (normalized schema)"]

    SoT --> Exec
    Exec --> CiscoA --> CiscoD
    Exec --> AristaA --> AristaD
    Exec --> HPEA --> HPED

    CiscoD --> CollGNMI --> Obs
    AristaD --> CollGNMI
    HPED --> CollSNMP --> Obs

实用且被广泛理解。随着设备库存多样化，维护负担增加：每个新厂商或操作系统版本需要新的或更新的适配器。适配器模式对于定义的厂商集合扩展良好；当平台必须支持大型且频繁变化的设备目录时，它会变得繁重。

9.2.3.3. 社区和行业驱动的 YANG 模型#

两个行业机构发布了减少每厂商适配器工作的厂商中立 YANG 模型。IETF 模型（作为 RFC 和互联网草案发布）定义基础数据结构：ietf-interfaces、ietf-routing、ietf-bgp。OpenConfig 模型由运营商联盟（Google、AT&T、Deutsche Telekom 等）开发，涵盖类似的范围，具有更注重运营的模式和更快的迭代周期。两者都允许自动化平台针对标准模型编写一次意图，并期望它在任何合规设备上都能工作。

定义接口的 YANG 模块如下所示（从 ietf-interfaces 简化）：

module ietf-interfaces {
  container interfaces {
    list interface {
      key "name";
      leaf name      { type string; }
      leaf description { type string; }
      leaf enabled   { type boolean; default true; }
    }
  }
}

相同的结构出现在 OpenConfig（openconfig-interfaces）和厂商原生模型中，但路径、叶节点名称和默认语义不同。YANG 模块定义模式；协议（NETCONF 或 gNMI）传输数据；适配器层在标准与厂商现实之间映射。

OpenConfig 的实际情况：厂商实现在完整性方面差异很大。设备可能声称支持 OpenConfig，但只实现了模型的子集：读取有效，写入无效；或者接口模型有效，但 BGP 模型缺失。

除了缺失路径之外，更隐蔽的问题是数据不一致。设备为 OpenConfig 路径返回一个值，但单位错误、类型不同，或者应该为空的字段填充了厂商特定的默认值。在 SAMPLE 模式下有效的 gRPC Network Management Interface (gNMI) 订阅可能在同一设备上的 ON_CHANGE 模式下静默失败。

这些不是罕见的边缘情况，而是运营依赖于生产中 OpenConfig 的多厂商平台的日常现实。标准在纸面上有效；厂商实现需要与标准本应消除的相同每台设备调查。OpenConfig 显著减少了这种工作，但没有消除它。在生产自动化中依赖新的 OpenConfig 路径之前，计划进行设备特定测试。

关于 YANG 模型系列的说明

三个 Yet Another Next Generation (YANG) 模型系列在生产网络中共存，理解区别对于选择哪个目标很重要：

• IETF 模型通过 IETF 标准流程开发，作为 RFC 或互联网草案发布。它们是基础标准：ietf-interfaces、ietf-routing、ietf-bgp。采用广泛但缓慢；流程彻底但需要数年。厂商实现通常在发布两到四年后才到来。
• OpenConfig 模型由 OpenConfig 联盟开发，这是一个运营商驱动的团体（Google、AT&T、Deutsche Telekom 等）。OpenConfig 比 IETF 迭代更快，更注重运营。它涵盖了许多与 IETF 模型相同的功能领域，但具有不同的模式设计选择。大多数生产 gNMI 部署使用 OpenConfig 路径。
• 厂商原生模型是每个厂商自己的扩展：cisco-ios-xe-native、junos-conf-root、arista-eos-augments。这些暴露标准模型没有涵盖的功能，对于超出 IETF 和 OpenConfig 地址的公分母功能的任何内容，它们通常是必需的。Nokia 是一个极端案例：SR OS 上几乎所有运营数据只能通过 Nokia 特定的 YANG 模型（nokia-conf、nokia-state）访问。标准模型涵盖了一个薄薄的界面；厂商原生模型对于该平台上任何有意义的自动化都是必须的。

抽象以功能访问为代价换取统一性。每个厂商都有标准模型中没有等价物的专有功能。使用 OpenConfig 的团队必须选择：忽略该功能、添加厂商扩展或维护厂商特定的覆盖路径。没有干净的答案。在实践中，大多数自动化工作集中在标准模型覆盖良好的功能中（VLAN、BGP、接口）；专有功能很重要，但很少是核心使用案例。标准也有采用滞后：厂商可能在发布两到四年后才实现 IETF 模块，而且只在较新的平台上。根据 SoT 中记录的操作系统版本而不是假设统一支持来限制功能使用。

9.2.3.4. SONiC 和开放网络#

SONiC 的配置接口是具有 YANG 结构化模式的 Redis 数据库：统一的、可编程的，并且从一开始就为自动化而设计。在多厂商物理环境中消耗精力的厂商特定适配器工作在这里不适用。无论底层硬件厂商如何，相同的自动化逻辑在所有基于 SONiC 的平台上都有效。

SONiC CONFIG_DB 中的 VLAN 条目如下所示：

{
  "VLAN": {
    "Vlan210": {
      "vlanid": "210"
    }
  },
  "VLAN_MEMBER": {
    "Vlan210|Ethernet0": {
      "tagging_mode": "untagged"
    }
  }
}

此 JSON 通过 sonic-cfggen 或 SONiC 管理 REST API 直接写入 Redis。不需要解析 CLI，不需要构建 XML。自动化平台写入结构化数据；SONiC 的 orchagent 将其协调到硬件转发表。

这是开放网络倡导的设计方向：为自动化而设计的网络接口，而不是适应它。引入基于 SONiC 的平台与传统设备并存的团队会发现 SONiC 适配器是最简单的编写和最可靠的运营。

• 厂商产品：SONiC 已经远超其 Microsoft Azure 起源。现在大多数主要交换机芯片厂商都提供基于 SONiC 的平台：Microsoft Azure SONiC（上游参考）、Arista 在特定平台上具有 SONiC 兼容管理 API、Cisco 8000 系列具有基于 Broadcom 的 SONiC 支持、Dell OS10（使用 SONiC 衍生架构）、运行 SONiC 作为第一选项的 Nvidia Spectrum 平台，以及越来越多的 ODM 厂商（Edgecore、Celestica、UfiSpace）推出品牌 SONiC 平台。生态系统已经成熟到在每个价格和性能层级都可以商业获得基于 SONiC 的平台。

• 成熟的使用案例：数据中心叶脊织构是最成熟的部署。超大规模提供商已经在规模上运行 SONiC 超过十年；企业数据中心现在正在跟进。EVPN/VXLAN 覆盖、BGP 路由、ECMP 负载均衡和 400G/800G 接口支持已经过充分验证。自动化故事很强大：gNMI、YANG 和 Redis 支持的 CONFIG_DB 是原生接口。SONiC 机队可以用管理任何其他支持 gNMI 平台的相同工具来管理。

• 新前沿：SONiC 开始出现在传统数据中心织构之外。分解路由平台（SONiC 在高端口计数路由器而不仅仅是交换机上运行）将开放 NOS 模型扩展到路由使用案例。SONiC 现在包括段路由支持：SRv6（基于 IPv6 的段路由）在上游 SONiC 中可用，并被使用基于 SONiC 平台进行流量工程和网络切片的服务提供商在生产中使用。一些服务提供商还在评估 SONiC 用于对等边缘和宽带汇聚。园区 SONiC 部署仍然罕见，但技术上是可行的；园区外形因素的硬件生态系统不太成熟。对于今天构建新平台的团队，问题不再是 SONiC 是否在数据中心中已经达到生产就绪：它已经达到了。悬而未决的问题是厂商的 SONiC 分支和发布节奏是否会在平台生命周期内与上游保持一致。

9.2.3.5. 在固件迁移期间管理共存#

适配器模式假设每台设备有已知的、稳定的操作系统版本。在滚动固件升级期间，这个假设会破裂：相同角色的设备，由相同的自动化平台管理，在数天或数周内同时运行不同的操作系统版本。昨天在固件 10.12 上有效的抽象层在添加新适配器路径之前可能在固件 10.13 上无效。

SoT 应该记录预期的操作系统版本（迁移后的目标），采集器应该将当前的操作系统版本作为运营状态呈现。在执行器应用配置之前，它应该从采集器或可观测性管道读取当前操作系统版本，并选择适当的适配器路径，而不是假设预期版本已经部署。

一个具体机制：执行器查询可观测性模块（或对设备本身进行轻量级预执行检查）以获取运行中的操作系统版本。适配器注册表将操作系统版本范围映射到适配器实现。执行器基于当前状态而不是 SoT 意图调用正确的适配器。一旦设备升级，运行版本与意图匹配，适配器选择就稳定了。在迁移窗口期间，同一厂商的两个适配器路径可能同时活跃。

9.3 节中的实施示例直接演示了这种模式：HPE 适配器错误被触发，因为一个固件版本对相同条件返回 vlan-exists，另一个返回 duplicate-vlan。修复是适配器注册表中的每操作系统版本错误处理。任何管理多版本机队的自动化平台都会遇到这类问题。由当前操作系统版本（从采集器读取）驱动的每版本适配器逻辑编码是系统性的缓解措施。第 11 章解决如何将操作系统版本映射维护为平台级目录，而不是每个 Playbook 的常量。

组织影响：必须有人拥有 SoT 中的操作系统版本跟踪、适配器版本注册表和升级排序工作流。这三个制品构成了升级自动化系统。没有明确的所有权，它们会独立漂移，平台的可靠性会随着每次固件发布而降级。

9.2.4. 网络作为每个模块的约束#

本节涵盖的三个领域，可编程接口、仿真环境和抽象策略，不是孤立的主题。它们描述了网络对 NAF 框架中每个模块的影响。

网络的接口能力约束了执行器可以做什么：只支持 CLI 的设备迫使执行器的适配器进入脆弱的屏幕抓取；具有成熟 gNMI 支持的设备使可靠的配置和流式遥测成为可能。网络的采集支持约束了采集器可以摄入什么：没有实现所需 OpenConfig 路径的设备需要厂商特定的解决方法或采集缺口。网络的拓扑约束了编排器可以安全并行化的内容：对于平坦接入层安全的批次大小对于脊叶织构可能是灾难性的，因为同时更改多个脊柱节点可能分割网络。

SoT 数据模型反映了这些约束。操作系统版本字段控制适配器选择。接口类型字段控制采集方法。拓扑关系控制编排器并发规则。记录设备库存而不记录与自动化相关属性（接口能力、操作系统版本、拓扑角色）的 SoT 是不完整的，这些不完整只会在执行时才会暴露。

第 2 部分中的每个架构决策都有本章呈现的相应网络层约束。网络不仅仅是自动化的目标，它影响作用于它的每个模块，这些约束必须编码在平台的数据模型、适配器逻辑和工作流配置中。将网络视为均匀界面的自动化将一次一个失败的部署地发现异构性。

9.3. 实施示例#

9.3.1. 从仿真到生产#

园区 VLAN 工作流已准备好。八周的开发，三个厂商建模，在三节点实验室中测试幂等性。团队想将其部署到生产：800 台交换机，A 到 F 栋建筑。在此之前，他们对仿真运行它。

这个示例遵循 9.2.2.4 节描述的预生产门控序列，使用 B 栋范围作为仿真目标：24 台交换机，8 台 Cisco，8 台 Arista，8 台 HPE。

步骤 1：从真实数据源导出拓扑

SoT 保存 B 栋交换机清单及其预期操作系统版本：

• 8 台 Cisco Catalyst 9300：IOS-XE 17.9.4
• 8 台 Arista 7050：EOS 4.31.2F
• 8 台 HPE Aruba 6300：AOS-CX 10.12.1006（旧固件线，10.13 之前）

SoT 导出生成一个 netlab 拓扑定义：节点类型、映射到预期操作系统版本的厂商特定镜像标签，以及仿真应该开始时的 VLAN 状态（VLAN 100、150 和 200 已经在所有交换机上配置，匹配生产状态）。

步骤 2：实例化仿真环境

netlab 将 SoT 导出渲染成 containerlab 拓扑文件。containerlab 在团队的 CI 环境中的共享 Linux 仿真主机上运行（一台 64 GB 内存的裸金属服务器，足以同时运行 24 个轻量级 cEOS/vrnetlab 容器）。HPE 节点使用固定到 10.12.1006 的 vrnetlab 包装 AOS-CX 镜像，匹配 SoT 中的预期操作系统版本。containerlab 启动拓扑。所有 24 个节点在九十秒内启动并响应 NETCONF 和 gRPC Network Management Interface (gNMI)。

步骤 3：对仿真目标运行第 7 章 VLAN 工作流

编排器以仿真清单而不是生产清单作为目标范围触发工作流。前四个工作流步骤顺利完成：

• 收到 ServiceNow Webhook，根据 SoT 模式解析和验证
• 预检：仿真中不存在 VLAN 210（正确）
• SoT 更新了 VLAN 210 意图
• 审批门：在仿真模式下自动批准

第五个工作流步骤，通过执行器对所有 24 台仿真交换机的扇出执行，返回失败。

结果：8 台 Cisco 节点通过。8 台 Arista 节点通过。8 台 HPE 节点失败。

来自 HPE 节点的错误：vlan-exists。HPE 适配器中的幂等性检查将 duplicate-vlan 作为无操作处理，但对 vlan-exists 没有处理程序。执行器返回失败，触发 Saga 补偿：VLAN 210 从所有已接收它的节点中删除。

没有发生生产变更，失败的成本是容器启动时间和三十分钟的调查。

步骤 4：诊断和修复

团队查看 AOS-CX 10.12 发行说明。vlan-exists 错误在 10.11.1 中引入，取代了 duplicate-vlan 用于重复 VLAN 检测。10.13 版本恢复了 duplicate-vlan，与 Aruba 产品线的其余部分保持一致。

修复：将 vlan-exists 添加到 HPE 适配器中的幂等错误代码列表。SoT 更新了关于操作系统版本边界的说明（10.11 到 10.12.x 返回 vlan-exists；10.13+ 返回 duplicate-vlan）。

在重新运行之前，团队将预期的变更后状态编码为 pyATS 或 Robot Framework 测试：在工作流完成后，断言 VLAN 210 存在于所有 24 个仿真节点上，并且没有触发 Saga 补偿。此断言被添加到仿真通过标准：只有当工作流完成且验证断言通过时，仿真门控才会关闭。

步骤 5：在仿真中重新运行

修正后的适配器对相同的 containerlab 拓扑运行。所有 24 个节点通过。Saga 无需补偿即完成。SoT 显示 VLAN 210 存在于所有 B 栋节点上。

步骤 6：生产部署

编排器对完整生产范围触发相同的工作流：800 台交换机，A 到 F 栋建筑。每个步骤通过仿真中验证的相同 Saga 模式运行。HPE 节点零失败。当编排器完成时，应用团队的 ServiceNow 工单自动关闭。可观测性层在预期时间窗口内验证所有接口上存在 VLAN 210。

这展示了什么

仿真环境不是当团队感到有信心时可以跳过的验证步骤，而是 Saga 模式中的预生产门控。镜像生产拓扑和操作系统版本的仿真拓扑是在园区规模部署自动化的团队最小可行测试环境。投资是 containerlab 设置、操作系统版本固定的镜像和 SoT 导出机制。回报是在设备特定错误成为事件之前捕获它们的能力。

仿真发现这个错误不是因为奇异的测试，而是因为仿真中的操作系统版本与生产匹配，平台对其运行了完全相同的工作流代码。仿真环境对生产状态的保真度使得捕获成为可能。运行最新厂商镜像的仿真环境会错过这个错误。

第 10 章介绍如何将仿真环境作为平台的一部分进行运营化：在版本控制中维护 containerlab 拓扑，按计划与 SoT 导出同步，并将其集成到 CI/CD 管道中，使仿真门控在每次工作流变更时自动运行。

9.4. 总结#

第 9 章通过解决自动化平台一直指向的模块来关闭第 2 部分：网络本身。

三个思想锚定这一章。

网络不是统一的。 任何大规模自动化平台同时与园区交换、数据中心织构、云 VPC、Kubernetes 覆盖层、覆盖控制器和遗留设备交互。每种都暴露不同的接口，在不同的一致性语义下运行，具有不同的自动化成熟度。平台通过接口选择层次结构（gRPC Network Management Interface (gNMI) 用于遥测，NETCONF 用于配置，Command Line Interface (CLI) 作为最后手段）、真实数据源中的操作系统版本跟踪和执行器中的厂商特定适配器来吸收这种异构性。

仿真环境是预生产门控。 基于容器的仿真提供真实的、快速的、与 CI/CD 集成的环境，其中自动化逻辑针对镜像生产的拓扑和操作系统版本进行测试。仿真中的失败代价低廉，生产中的失败代价高昂。仿真环境对生产状态的保真度使门控有意义。

抽象策略延长了平台寿命。 适配器模式处理今天的多厂商物理环境。OpenConfig 和 YANG 翻译推动向减少长期适配器维护的厂商中立模型发展。SONiC 为支持它的平台完全消除了适配器工作。这些策略都没有提供完美的答案；每种都涉及统一性和功能访问之间的权衡。正确的选择取决于团队的设备目录、运营能力，以及他们的多少自动化工作落在标准功能覆盖范围内。

有了第 9 章，第 2 部分就完成了。六章涵盖了 NAF 框架的所有七个构建块：真实数据源、采集器和可观测性（在第 6 章中一起）、执行、编排、呈现和网络。这些不是独立的工具。SoT 向执行器提供它需要的意图，向采集器提供用于验证的预期状态。编排器对两者进行排序，处理失败，并向呈现层展示进度。网络位于所有这些之下：影响每个其他模块设计的约束，以及自动化最终产生结果或失败的地方。

第 3 部分从构建模块转向在规模上运营平台：为可靠性而工程化、为安全和合规而设计，以及将自动化平台作为具有自己生命周期和运营需求的产品来对待。

参考文献和延伸阅读#

• Network Programmability and Automation，Matt Oswalt、Christian Adell、Scott Lowe、Jason Edelman（O’Reilly，第 2 版，2023 年）。网络自动化工具最全面的实用指南，深入介绍 NETCONF、gNMI、YANG 模型和自动化框架。
• Network Programmability with YANG，Benoit Claise、Loe Clarke、Jan Lindblad（Pearson，2019 年）。YANG 数据建模的权威参考：IETF 和 OpenConfig 模型如何结构化、如何读写 YANG 模块，以及 NETCONF 和 RESTCONF 如何使用它们。
• Cisco pyATS: Network Test and Automation Solution，John Capobianco、Dan Wade（Cisco Press）。pyATS 和 Genie 网络测试自动化的全面指南：测试脚本、解析器、结构化状态验证和 CI/CD 管道集成。
• Infrastructure as Code，Kief Morris（O’Reilly，第 2 版，2021 年）。不是特定于网络的，但对于理解可重复、可测试、版本控制的基础设施背后的原则如何直接适用于网络自动化平台设计是基础性的。

💬 Found something to improve? Send feedback for this chapter