📚 课程目录第3章 Comware配置模型与数据建模

3. Comware配置模型与数据建模

在传统CLI运维中，配置以“命令行文本”的形式存在：我们输入 interface GigabitEthernet1/0/1，再输入 ip address 192.168.1.1 24，设备把这两行文本解析后写入运行配置。文本配置对人友好，但对程序并不友好——程序很难稳定地“读懂”一段自由格式的文本，也很难判断某一行属于哪个对象、哪个层级。Comware配置模型要解决的核心问题，就是把“给人看的命令行”抽象成“给程序看的数据结构”，并进一步用YANG模型描述这个结构。

一、Comware配置的层次结构

Comware的配置本质上是一棵层次化的树。树的根是系统，向下分为若干功能模块（如接口、VLAN、路由协议、ACL），每个模块下又有具体的实例对象，实例对象再挂载属性。以接口配置为例，其结构可以理解为：

模块层：interface，表示“接口”这一类配置；
实例层：GigabitEthernet1/0/1，表示具体的一个接口对象；
属性层：ip address、description、shutdown 等，表示该接口的具体参数。

这种“模块—实例—属性”的三层结构，是理解Comware配置模型的基础。CLI中的视图切换（如 system-view 进入系统视图、interface GigabitEthernet1/0/1 进入接口视图）实际上就是在配置树上移动指针；而 display current-configuration 输出的缩进文本，正是这棵树的一种线性化表达。

二、命令行与数据模型的映射关系

命令行与数据模型之间不是一一对应的“翻译”，而是一种结构映射。CLI中的“进入视图 + 设置参数”两步操作，在数据模型中通常合并为“对某个实例对象的某个叶子节点赋值”。例如：

system-view
interface GigabitEthernet1/0/1
 description To-Core-Switch
 ip address 192.168.1.1 255.255.255.0
 quit

映射到数据模型后，可以表示为一条带路径的配置记录：

/interface/GigabitEthernet1/0/1/description = "To-Core-Switch"
/interface/GigabitEthernet1/0/1/ipv4/address = "192.168.1.1"
/interface/GigabitEthernet1/0/1/ipv4/mask = "255.255.255.0"

这里的关键在于：路径唯一标识一个配置节点，值表示该节点的内容。有了这种映射，程序就可以通过路径精确地读取、修改或删除某个配置项，而不必依赖文本匹配。这也是NETCONF、RESTCONF等协议能够对Comware进行结构化操作的前提。

理解映射关系时，可以把CLI视图看作“路径的导航过程”，把最终生效的配置行看作“路径上的叶子节点值”。视图本身不产生配置，只有视图下的具体命令才对应数据模型中的节点。

三、YANG模型在Comware中的实现方式

YANG（RFC 6020/7950）是一种用于描述配置和状态数据的建模语言。它用 module、container、list、leaf 等语句定义数据的层级、类型和约束。Comware从V7版本开始逐步引入YANG模型支持，其实现方式可以概括为“内置模型 + 映射引擎”：

内置YANG模块：Comware将常用功能（接口、VLAN、路由、ACL等）预先建模为YANG模块，模块名通常与功能对应，如 h3c-if、h3c-vlan；
映射引擎：负责在YANG数据节点与Comware内部配置树之间进行双向转换，使NETCONF/RESTCONF请求能够落到具体的配置项上；
能力通告：设备通过NETCONF的 <hello> 消息或RESTCONF的 /.well-known/host-meta 对外声明自己支持哪些YANG模块，客户端据此决定可以操作哪些数据。

下面这张图展示了从CLI配置到YANG模型、再到程序化接口的完整映射链路，以及各层之间的对应关系：

四、从模型到操作：一个可执行的观察过程

理解模型之后，更重要的是知道如何在实际设备上观察和验证这种映射。以下过程以Comware V7设备为例，属于教学示例，具体输出以设备实际版本为准。

第一步，查看设备支持的YANG模块能力。通过NETCONF客户端连接设备后，设备会在 <hello> 消息中返回能力集，其中包含类似 urn:ietf:params:xml:ns:yang:ietf-interfaces 或厂商自定义模块的命名空间。也可以使用命令行查看：

display netconf capability

第二步，用NETCONF的 <get-config> 操作读取接口配置。请求中指定数据源为 running，并用XPath或子树过滤定位到目标接口：

<rpc message-id="1" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <get-config>
    <source><running/></source>
    <filter type="subtree">
      <interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
        <interface>
          <name>GigabitEthernet1/0/1</name>
        </interface>
      </interfaces>
    </filter>
  </get-config>
</rpc>

设备返回的XML中，<name>、<description>、<ipv4> 等节点与配置树中的属性一一对应。此时可以对比 display current-configuration interface GigabitEthernet1/0/1 的输出，确认两者描述的是同一个对象、同一组参数。

第三步，用 <edit-config> 修改描述信息，再重新读取，观察变化是否落到运行配置中。这一“读—改—读”的闭环，正是配置治理中“可观测、可验证”的基础。

不同Comware版本对YANG模块的覆盖范围不同，部分功能可能仍只支持CLI或SNMP。实际使用前应先通过能力通告确认模块可用性，避免对不存在的节点发起操作。

五、配置治理视角下的模型价值

把配置抽象为模型，带来的直接收益有三点。其一，可校验：YANG模型自带类型和约束（如IP地址格式、取值范围），非法数据在进入设备前就能被拦截。其二，可对比：两个配置树可以按路径逐节点比较，快速定位差异，而不必逐行diff文本。其三，可编排：自动化平台可以基于模型生成配置，而不是拼接命令字符串，降低因命令顺序、视图切换导致的错误。

因此，学习Comware配置模型，重点不在于记住某条命令，而在于建立“配置即数据”的认知：CLI是数据的一种呈现方式，YANG是数据的规范描述，NETCONF/RESTCONF是数据的传输通道。三者贯通之后，配置治理才能从“人工核对文本”走向“程序校验结构”。