2. Catalyst平台与自动化接口体系

Catalyst 交换机是 Cisco 园区与企业网络的主力产品线，覆盖从接入层到核心层的完整部署场景。理解 Catalyst 的硬件平台差异、IOS-XE 的软件架构，以及 NETCONF、RESTCONF、gNMI、SNMP、CLI 等接口的定位与适用边界，是构建自动化运维体系的第一步。本节从平台分层出发，逐层展开到接口选型，帮助读者建立“什么场景用什么接口”的判断能力。

Catalyst 产品线与 IOS-XE 架构

Catalyst 产品线按部署位置大致可分为三类：接入层以 Catalyst 9200、9300 系列为代表，提供千兆/多千兆端口与 PoE+ 供电；汇聚与中小型核心以 Catalyst 9400、9500 系列为主，具备模块化槽位与更高转发容量；核心与数据中心边缘则由 Catalyst 9600、9800 系列承担，支持高密度 100G/400G 上行。不同系列的 ASIC 转发能力、堆叠方式（StackWise、StackWise Virtual）和可编程能力存在差异，这直接决定了它们对自动化接口的支持程度。

IOS-XE 是运行在这些 Catalyst 平台上的统一操作系统。它并非传统 IOS 的简单延续，而是将 IOS 守护进程运行在 Linux 内核之上，形成“Linux 宿主 + IOSd + 各类管理守护进程”的分层结构。这一架构的关键意义在于：Linux 层提供了标准化的管理通道（如 NETCONF over SSH、RESTCONF over HTTPS、gNMI over gRPC），而 IOSd 负责实际的转发控制与配置解析。配置数据通过 IOS-XE 的配置数据库（基于 YANG 模型）在两者之间同步，使得同一份配置既可以通过 CLI 修改，也可以通过模型驱动接口读写。

需要特别注意的是，IOS-XE 的模型驱动接口并非在所有版本和所有平台上完全一致。例如，NETCONF 的 YANG 模型覆盖度在 16.x 与 17.x 之间存在明显差异，部分平台在 17.x 之后才完整支持 OpenConfig 模型。因此在实际项目中，第一步应确认目标平台的 IOS-XE 版本与可用 YANG 模型集，而不是直接假设接口可用。

模型驱动接口：NETCONF、RESTCONF 与 gNMI

NETCONF 是最早成熟的模型驱动配置协议，基于 SSH 传输，使用 XML 编码，通过 <get-config>、<edit-config>、<commit> 等操作对 YANG 模型定义的数据树进行读写。它的优势在于事务性：一次 edit-config 可以包含多个节点的修改，配合 candidate 数据存储实现“先校验、后提交”，适合批量配置变更。在 Catalyst 上启用 NETCONF 的典型命令如下：

switch(config)# netconf-yang
switch(config)# netconf-yang feature candidate-datastore
switch(config)# username auto priv 15 secret Auto@123
switch(config)# ip ssh version 2

启用后，可用 ssh -p 830 auto@10.1.1.1 -s netconf 建立会话，发送 <hello> 消息交换能力集。若返回的 <capability> 列表中包含 urn:ietf:params:netconf:base:1.1 与 urn:ietf:params:netconf:capability:candidate:1.0，说明候选数据存储可用，可以执行事务性配置。

RESTCONF 可以理解为 NETCONF 的 RESTful 封装，使用 HTTPS 传输，支持 JSON 与 XML 两种编码。它把 YANG 数据树映射为 URL 路径，例如获取接口列表使用 GET /restconf/data/ietf-interfaces:interfaces，修改接口描述使用 PATCH 或 PUT。RESTCONF 的优点是易于被 Python requests、curl 等通用 HTTP 工具调用，学习成本低；缺点是事务性弱于 NETCONF，且部分平台对 PATCH 的支持不完整。在 Catalyst 上启用：

switch(config)# restconf
switch(config)# ip http secure-server
switch(config)# ip http authentication local

gNMI 则面向遥测与流式数据采集，基于 gRPC 和 Protobuf，支持 Subscribe 操作以“一次订阅、持续推送”的方式获取接口计数器、CPU 利用率等高频变化数据。与 SNMP 轮询相比，gNMI 的推送模式显著降低了采集延迟和控制器负载。在 Catalyst 上启用 gNMI 通常需要：

switch(config)# gnmi-yang
switch(config)# gnmi-yang secure-server
switch(config)# gnmi-yang secure-server port 57400

订阅时，客户端指定路径如 /interfaces/interface/state/counters，并设置采样间隔（例如 10 秒）和订阅模式（SAMPLE 或 ON_CHANGE）。若 10 秒内收到多条 SubscribeResponse 且 sync_response 为 true，说明订阅已建立并进入稳定推送阶段。

SNMP 与 CLI 的定位

SNMP 是传统网管的事实标准，通过 MIB 和 OID 读取设备状态，通过 Trap 上报事件。它的优势是生态成熟、几乎所有网管平台都支持；劣势是轮询效率低、OID 语义晦涩、对配置变更支持弱。在自动化体系中，SNMP 更适合作为“兜底监控”而非配置通道。CLI 则是最通用的接口，任何 Catalyst 平台都支持，但输出为半结构化文本，需要正则或 TextFSM 解析，且不同版本命令输出格式可能变化，维护成本较高。

接口选型对比与实操判断

下表从传输、编码、事务性、配置能力、遥测能力和典型场景六个维度对比五种接口，可作为选型参考：

综合来看，Catalyst 平台与 IOS-XE 的接口体系并非“越新越好”，而是“越匹配越好”。接入层设备若仅需批量下发 VLAN，NETCONF 已足够；核心层若需秒级监控队列丢包，则应优先 gNMI。理解每种接口的传输方式、数据模型和事务边界，才能在自动化工程中做出稳定、可维护的选型决策。