3. 网络自动化基础

传统网络自动化大量依赖 CLI 屏幕抓取（screen scraping）和 SNMP。CLI 抓取的本质是“把人类可读的文本当作机器接口”，一旦设备版本升级、提示语或字段顺序变化，脚本就会失效；SNMP 虽然结构化，但以 OID 为中心、写操作能力弱、语义贫乏，难以表达复杂的配置模型。模型驱动接口（Model-Driven Interface）改变了这一局面：它把网络设备的能力抽象为一份可机器解析的数据模型，接口只负责在模型与设备之间搬运数据，从而让自动化脚本与设备内部实现解耦。

本节围绕四类主流模型驱动接口——NETCONF、YANG、RESTCONF、gNMI——讲清它们的原理、分工与选型依据。

一、YANG：先有模型，才有接口

YANG（RFC 7950）是一种数据建模语言，用来描述设备上可被配置和读取的数据。它本身不是协议，而是“契约”。一个 YANG 模块由 module 声明，内部用 container、list、leaf、leaf-list 组织层级数据，用 type 约束取值，用 config false 区分只读状态数据，用 mandatory、must、when 表达约束与依赖。

module iface-demo {
  namespace "urn:demo:iface";
  prefix d;
  container interfaces {
    list interface {
      key "name";
      leaf name { type string; }
      leaf enabled { type boolean; default true; }
      leaf mtu { type uint16; default 1500; }
      leaf oper-status { type string; config false; }
    }
  }
}

这段模型定义了接口列表：name 是键，enabled、mtu 可配置，oper-status 为只读运行状态。设备厂商发布自己的 YANG 模块（如 ietf-interfaces、openconfig-interfaces），自动化系统据此生成数据结构、校验输入、渲染配置，无需猜测字段名。

YANG 还定义了两种编码：XML（NETCONF 默认）和 JSON（RESTCONF/gNMI 常用）。同一份模型，两种编码，语义一致。

二、NETCONF：面向配置的事务型协议

NETCONF（RFC 6241）运行在 SSH 之上，默认端口 830，用 XML 承载 RPC。它的核心能力是事务化配置：通过 <candidate> 候选库暂存修改，用 <commit> 一次性生效，失败则 <discard-changes> 回滚。它还支持 <get-config>、<edit-config>、<lock>/<unlock> 和 <get> 读取状态。

<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <edit-config>
    <target><candidate/></target>
    <config>
      <interfaces xmlns="urn:demo:iface">
        <interface><name>GE0/0/1</name><mtu>9000</mtu></interface>
      </interfaces>
    </config>
  </edit-config>
</rpc>

NETCONF 适合“改配置”这类需要原子性和回滚的场景，但 XML 冗长、编程体验偏重，且不同厂商对候选库、确认提交（confirmed-commit）的支持程度不一。

三、RESTCONF：把 YANG 映射成 HTTP

RESTCONF（RFC 8040）把 YANG 数据树映射为 URL 路径，用 HTTP 方法操作：GET 读、PUT 替换、PATCH 合并、POST 创建、DELETE 删除。数据默认用 JSON 编码，天然适配现代编程语言和 API 网关。

PATCH /restconf/data/iface-demo:interfaces/interface=GE0%2F0%2F1
Content-Type: application/yang-data+json

{ "iface-demo:mtu": 9000 }

RESTCONF 上手快、工具链成熟，但它没有候选库和事务提交，每次请求直接作用于运行库，回滚需自行实现。因此它更适合读多写少、单点修改或与上层平台集成的场景。

四、gNMI：面向遥测的流式接口

gNMI（gRPC Network Management Interface）基于 HTTP/2 与 Protobuf，定义 Capabilities、Get、Set、Subscribe 四类 RPC。它的最大特色是 Subscribe：客户端可订阅某个路径，设备按 SAMPLE（周期采样）、ON_CHANGE（变化上报）、TARGET_DEFINED 模式持续推送数据，实现秒级甚至亚秒级遥测，替代高频轮询 SNMP。

SubscribeRequest {
  subscribe {
    subscription {
      path: "/interfaces/interface[name=GE0/0/1]/state/counters/in-octets"
      mode: SAMPLE
      sample_interval: 10000000000   // 10s
    }
    mode: STREAM
  }
}

gNMI 的 Set 支持 replace、update、delete 三种操作，路径同样来自 YANG/OpenConfig 模型。它适合大规模、高频、持续观测的场景，但对 gRPC 生态和 TLS 证书管理有一定门槛。

五、选型：按任务性质而非按“新旧”

四者不是替代关系，而是分层协作。YANG 是共同底座，NETCONF、RESTCONF、gNMI 是三种访问通道。选型时先问三个问题：

• 是写配置还是读状态？ 写配置且要求原子性、回滚，优先 NETCONF；只读或轻量写，RESTCONF 更省事。
• 是单次操作还是持续观测？ 单次用 NETCONF/RESTCONF；持续高频用 gNMI Subscribe，避免轮询放大设备 CPU。
• 团队技术栈是什么？ 熟悉 HTTP/JSON 的团队用 RESTCONF 起步最快；已有 gRPC/Protobuf 体系则 gNMI 更顺。

实际工程中常见组合是：用 gNMI 做秒级指标采集与告警，用 NETCONF 做变更下发与回滚，用 RESTCONF 对接上层工单与 CMDB 系统。三者共享同一份 YANG 模型，因此路径、字段、类型可以复用，脚本与数据管道不必为每种协议重写。