📚 课程目录第2章网络配置数据建模

2. 网络配置数据建模

在上一节中我们已经明确：网络配置合规与变更自动化的前提，是把“配置”从一段段难以解析的文本，变成机器可读、可校验、可比较的结构化数据。本节要解决的核心问题就是——用什么语言和模型来描述网络配置数据。目前业界主流方案是 YANG 数据建模语言，配合 OpenConfig、IETF 标准模型以及厂商扩展模型，共同构成一套分层的数据表示体系。

一、YANG：配置数据的“语法与语义”定义语言

YANG（RFC 6020/7950）本身不是配置数据，而是定义配置数据结构、类型、约束和层次关系的建模语言。它类似于数据库的 schema：先定义“有哪些字段、字段是什么类型、取值范围是多少、哪些字段必须存在”，再由设备或控制器按这个 schema 生成实际的配置数据实例。

YANG 模型的基本构件包括：module（模块，命名空间与版本）、container（容器，组织层级）、list（列表，可重复的条目，如多个接口）、leaf（叶子，具体数据项）、leaf-list（叶子列表）、typedef（自定义类型）以及 must、when、range、pattern 等约束。下面是一个简化示例，描述接口的启用状态与 MTU：

module example-interfaces {
  namespace "urn:example:interfaces";
  prefix exif;

  container interfaces {
    list interface {
      key "name";
      leaf name { type string; }
      leaf enabled { type boolean; default true; }
      leaf mtu {
        type uint16 { range "68..9216"; }
        default 1500;
      }
    }
  }
}

这段模型定义了：接口以 name 为键，enabled 为布尔值且默认开启，mtu 取值范围 68～9216、默认 1500。任何不符合该结构的配置数据，在模型校验阶段就会被拒绝，这正是合规自动化的第一道闸门。

二、OpenConfig 与 IETF 模型：标准化的“公共词汇表”

YANG 只是语言，真正让不同厂商设备可以统一管理的是标准模型。其中最具代表性的是 OpenConfig 和 IETF 模型。

OpenConfig 由运营商主导，强调“面向意图、厂商中立”，采用 openconfig-interfaces、openconfig-network-instance、openconfig-bgp 等模块。它的典型路径如 /interfaces/interface[name=eth0]/config/enabled，把配置与状态分离得比较清晰。

IETF 模型则更贴近协议标准本身，例如 ietf-interfaces、ietf-ip、ietf-routing、ietf-yang-types。它由 IETF NETMOD 工作组维护，与 RFC 标准绑定更紧，适合需要严格遵循协议规范的场景。

两者并非互斥：很多设备同时支持 OpenConfig 和 IETF 模型，控制器可以按需选择。选择时通常考虑：是否需要跨厂商统一、是否依赖特定标准 RFC、以及设备实际支持的模型版本。

三、厂商扩展模型：标准之外的“私有补充”

标准模型覆盖通用能力，但厂商往往有大量私有特性，例如华为的 huawei-*、思科的 cisco-*、Juniper 的 junos-* 模块。这些扩展模型通常通过 augment 语句挂接到标准模型上，形成“标准主干 + 厂商枝叶”的结构。

例如，标准接口模型只定义通用字段，厂商可以 augment 出光模块诊断、队列调度、私有 ACL 等节点。对自动化系统而言，这意味着：同一份合规策略，在标准部分可以跨厂商复用，在扩展部分必须按厂商分别处理。因此建模时要明确哪些字段走标准路径、哪些字段走厂商路径，避免策略在异构设备上失效。

四、配置与状态的区分：建模中最容易踩的坑

YANG 模型把数据分为两类：config（可写配置）和 state（只读状态）。在 OpenConfig 中通常体现为 /config/ 与 /state/ 两个子树；在 IETF 模型中则通过 config false 标记状态节点。

这个区分对合规与变更自动化至关重要：合规校验应针对 config 数据，状态数据只用于观测和验证。如果把状态字段误当作配置字段去比对，就会产生大量“假不合规”。例如接口的实际速率、光功率、计数器属于 state，不应写入配置基线；而 MTU、描述、启用状态属于 config，才是变更和合规的对象。

建模时建议遵循一个原则：先确定“这个字段能不能被写”，再决定它进入配置基线还是状态采集。配置基线只保留 config 数据，状态数据单独走监控通道。

五、从模型到数据实例：一次完整的结构化表示

把上述概念串起来，一次典型的配置数据建模过程是：选择标准模型作为主干 → 用厂商扩展模型补充私有字段 → 按 YANG 定义的层次生成配置数据实例 → 区分 config 与 state → 输出为 JSON 或 XML 供自动化系统消费。下图展示了这一数据表示体系的结构关系：

图中可以看到：YANG 是底层语言，OpenConfig 与 IETF 是两套标准词汇表，厂商扩展通过 augment 挂接，最终生成的数据实例必须按 config 与 state 分流。理解这张结构图，就掌握了配置数据建模的骨架。

六、建模实践中的关键判断

在实际项目中，建模决策通常围绕三个问题展开：

用哪套标准？ 若设备以 OpenConfig 为主，优先用 OpenConfig；若需严格对齐 RFC，选 IETF 模型。混合环境可建立映射表，把标准路径与厂商路径对应起来。
哪些字段必须进基线？ 只选 config 数据中影响业务与安全的字段，例如接口 MTU、VLAN、路由策略、ACL 规则。状态字段不进基线。
如何处理厂商差异？ 把标准字段与扩展字段分开存储，合规策略对标准字段统一校验，对扩展字段按厂商分别校验，避免“一刀切”导致误报。

以接口 MTU 为例：标准路径 /interfaces/interface[name=eth0]/config/mtu 在 OpenConfig 与 IETF 中语义一致，可以直接跨厂商比对；而某厂商的私有队列调度字段只存在于扩展模型中，就必须单独建立校验规则。这种“标准优先、扩展隔离”的做法，是配置数据建模落地时最实用的经验。

常见误区：把设备回显的 show running-config 文本直接当作结构化数据使用。文本配置没有类型、没有约束、没有 config/state 区分，无法可靠地做合规比对。必须先经过 YANG 模型映射，转成结构化实例后再进入自动化流程。

总结来说，网络配置数据建模的核心是：用 YANG 定义结构与约束，用 OpenConfig 和 IETF 模型获得跨厂商的公共语义，用厂商扩展模型补齐私有能力，并始终把 config 与 state 分开处理。只有完成这一步，后续的合规校验、差异比对和变更自动化才有可靠的数据基础。