3. YANG模型与Catalyst数据建模
在自动化运维中，如果只靠 CLI 抓取回显文本，脚本会非常脆弱：设备升级、提示语变化、字段顺序调整，都可能让解析失败。YANG 正是为了解决“数据如何被结构化描述”而出现的建模语言。它由 IETF 在 RFC 6020 中定义，后由 RFC 7950 升级为 YANG 1.1，用于描述网络设备的配置数据、状态数据、RPC 操作和通知。对 Catalyst 交换机而言，YANG 模型把原本散落在 CLI 中的配置和状态，抽象成有层级、有类型、有约束的树形数据，使 NETCONF、RESTCONF 以及基于模型的下发与查询成为可能。
YANG 基础：模块、节点与路径
一个 YANG 模块（module）通常对应一个功能域，例如接口、VLAN、路由或 ACL。模块内部由容器（container）、列表（list）、叶子（leaf）、叶列表（leaf-list）等节点构成。容器用于分组，列表用于表达可重复的条目，叶子承载具体值，叶列表承载一组同类型值。每个节点都有名字和类型，类型可以是 string、uint32、boolean、enumeration、inet:ipv4-address 等，还可以通过 must、when、range、pattern 施加约束。
YANG 数据在逻辑上是一棵树，访问某个节点使用路径表达式。例如接口配置路径可写作 /ietf-interfaces:interfaces/interface/name，其中冒号前是模块名，冒号后是节点名。路径解析是自动化脚本的核心能力：只有先定位到正确节点，才能读取或修改数据。理解命名空间、前缀和路径层级，是后续使用 NETCONF/RESTCONF 的前提。
IOS-XE 原生模型与 OpenConfig 模型
Catalyst 交换机运行 IOS-XE，思科为其提供了原生 YANG 模型，通常以 Cisco-IOS-XE- 开头，例如 Cisco-IOS-XE-interfaces、Cisco-IOS-XE-vlan、Cisco-IOS-XE-native。原生模型与 IOS-XE 的 CLI 结构高度对应，能覆盖大量设备特有功能，适合需要精细控制思科特性的场景。
OpenConfig 则是由运营商和设备厂商共同推动的厂商中立模型，路径通常以 openconfig- 开头，例如 openconfig-interfaces、openconfig-vlan。它的优势是跨厂商一致，便于多品牌混合环境统一编排；但部分思科私有特性在 OpenConfig 中可能没有对应节点，或需要映射转换。实际工程中常见做法是：通用配置优先用 OpenConfig，设备专有功能回退到 IOS-XE 原生模型。
模型浏览与路径解析
在 Catalyst 上浏览 YANG 模型，常用手段有三种。第一，通过 show yang-modules 或 show yang-modules | include Cisco-IOS-XE 查看设备支持的模块列表。第二，使用 pyang 工具在本地解析 .yang 文件，生成树形结构：pyang -f tree Cisco-IOS-XE-interfaces.yang，输出中会清晰列出每个节点的层级、类型和约束。第三，通过 NETCONF 的 <get-schema> 操作从设备直接拉取模型文件，再用工具解析。
路径解析时要注意几个易错点。其一，列表节点通常需要键（key）来唯一定位，例如 interface 列表的 key 是 name，访问时必须带上具体接口名。其二，配置数据与状态数据可能位于不同容器，例如 config 与 state 子树，读取状态应走 state 路径。其三，模块前缀必须与命名空间对应，不能随意简写。其四，OpenConfig 与 IOS-XE 原生模型的路径不能混用，同一份脚本中要明确使用哪套模型。
Catalyst 配置对象映射
把 CLI 配置对象映射到 YANG 路径，是自动化脚本落地的关键一步。以 Catalyst 9300 为例，假设需要配置接口 GigabitEthernet1/0/1 的 IP 地址并启用接口。使用 OpenConfig 模型时，路径可组织为：/openconfig-interfaces:interfaces/interface[name=GigabitEthernet1/0/1]/subinterfaces/subinterface[index=0]/openconfig-if-ip:ipv4/addresses/address[ip=192.168.10.1]/config/ip，同时把 config/enabled 设为 true。使用 IOS-XE 原生模型时，则可能走 /Cisco-IOS-XE-interfaces:interfaces/interface[name=GigabitEthernet1/0/1]/ipv4/address 等路径。
实际下发前，建议先做一次“读—改—写”验证：先用 NETCONF <get-config> 读取当前接口配置，确认路径可访问；再构造 <edit-config> 修改目标节点；最后再次读取并比对。若返回 data-missing 或 invalid-value，通常说明路径层级、键值或数据类型不匹配。下表给出常见 Catalyst 对象与模型路径的对应关系，可作为脚本编写时的速查参考。
| Catalyst 配置对象 | OpenConfig 路径片段 | IOS-XE 原生路径片段 |
|---|---|---|
| 接口启用/关闭 | interfaces/interface/config/enabled | interfaces/interface/shutdown |
| 接口 IPv4 地址 | interfaces/interface/subinterfaces/subinterface/ipv4/addresses/address/config/ip | interfaces/interface/ipv4/address |
| VLAN 创建与命名 | vlans/vlan/config/vlan-id、name | vlan/vlan-list/id、name |
| 接口描述 | interfaces/interface/config/description | interfaces/interface/description |
| 接口状态与计数 | interfaces/interface/state/oper-status、counters | interfaces/interface/state/oper-status |
实践建议：在编写自动化脚本前，先用 pyang -f tree 把目标模块的树形结构导出为文本，标注出需要读写的叶子节点及其类型。这样在构造 NETCONF XML 或 RESTCONF JSON 时，能显著减少因路径错误导致的反复调试。
注意：不同 IOS-XE 版本支持的 YANG 模块集合可能不同。同一路径在 17.3 与 17.9 上可能一个可用、一个缺失。上线前应通过 show yang-modules 确认目标设备实际支持的模块与版本，避免脚本在跨版本设备上失效。
总结来看，YANG 提供了数据建模的语法与结构，IOS-XE 原生模型和 OpenConfig 模型提供了两套可选的“词汇表”，路径解析是把业务意图翻译成模型地址的过程，而 Catalyst 配置对象映射则把 CLI 世界与模型世界连接起来。掌握这四层关系，才能在后续的 NETCONF、RESTCONF 和自动化编排中做到路径清晰、读写可控、结果可验证。