📚 课程目录第3章光网络自动化接口概览

3. 光网络自动化接口概览

在 Ciena 光网络设备（如 6500、WaveLogic 系列、SAOS 系列交换机、Blue Planet 纳管域）上做自动化，第一件事不是写脚本，而是选对接口。同一台设备往往同时开放 CLI、NETCONF、RESTCONF、gRPC、SNMP、TL1 六类接口，它们面向的运维阶段、数据模型、传输语义和并发能力完全不同。选错接口，后面所有代码都要重写；选对接口，自动化脚本可能只有几十行。

六类接口的定位差异

CLI 是设备最原始的人机接口，通过 SSH/Telnet 登录后输入命令，输出为人类可读文本。它的优势是覆盖最全、任何版本都有、排障时最直接；劣势是输出非结构化，命令回显随版本变化，解析脆弱。Ciena 的 SAOS 与 6500 均支持 CLI，适合一次性操作、应急排障和少量设备的手工脚本。

NETCONF 是基于 SSH 的 XML 配置协议，使用 YANG 模型描述数据，支持 candidate/confirmed-commit、get-config、edit-config 等标准操作。Ciena 在 SAOS 和 6500 上提供 NETCONF 服务，端口 830，适合需要事务性配置、配置回滚和模型化数据的场景。RESTCONF 是 NETCONF 的 HTTP 映射，用 JSON/XML 通过 HTTP 方法操作同样的 YANG 数据，端口通常为 443 或 8080，适合 Web 化、云原生工具链和轻量集成。

gRPC 基于 HTTP/2 和 Protobuf，支持流式传输和双向通信，Ciena 在 WaveLogic 与部分 SAOS 平台上通过 gRPC 提供高频遥测（Telemetry）与配置下发，适合秒级甚至亚秒级性能数据采集。SNMP 是传统网管协议，通过 OID 读取 MIB 数据，Ciena 设备支持 SNMPv2c/v3，适合存量网管系统对接和低频性能采集。TL1 是光传输领域的经典协议，Ciena 6500 等设备保留 TL1 接口，适合与既有 OSS 和传统传输网管集成。

接口选择的关键判断维度

面对具体任务，可以从四个维度快速判断：数据模型（是否有 YANG 模型）、事务性（是否需要 candidate 提交与回滚）、频率（低频轮询还是高频流式）、生态兼容（现有工具链支持哪种协议）。例如，批量修改 50 台 6500 的交叉连接，应选 NETCONF 的 edit-config 配合 confirmed-commit；而采集 100G 端口的秒级误码率，应选 gRPC 流式遥测，SNMP 轮询在秒级频率下会丢点且加重设备 CPU 负担。

实操示例：同一配置任务的三种接口写法

以在 SAOS 设备上创建一个 VLAN 100 并绑定端口为例，三种接口的写法差异明显。CLI 方式直接输入命令：

configure vlan 100
  add port 1/1
  exit
show vlan 100

NETCONF 方式使用 XML 封装，通过 edit-config 下发：

<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <edit-config>
    <target><running/></target>
    <config>
      <vlan xmlns="urn:ciena:params:xml:ns:yang:ciena-vlan">
        <vlan-id>100</vlan-id>
        <name>AUTO_VLAN</name>
        <port>1/1</port>
      </vlan>
    </config>
  </edit-config>
</rpc>

RESTCONF 方式则用 HTTP PATCH 提交 JSON：

PATCH /restconf/data/ciena-vlan:vlan=100
Content-Type: application/yang-data+json

{
  "ciena-vlan:vlan": [
    {
      "vlan-id": 100,
      "name": "AUTO_VLAN",
      "port": ["1/1"]
    }
  ]
}

三种写法中，CLI 最直观但不可回滚；NETCONF 支持事务提交，失败可回滚；RESTCONF 最易被 Python requests 或 curl 调用，适合快速集成。实际工程中，建议配置类任务优先 NETCONF/RESTCONF，排障类任务用 CLI，性能采集用 gRPC 或 SNMP，传统 OSS 对接用 TL1。

在 Ciena 设备上启用 NETCONF 前，需确认 SSH 服务已开启且端口 830 可达；RESTCONF 通常需要单独开启 HTTP/HTTPS 服务并配置认证方式。gRPC 遥测需在设备侧配置 telemetry 订阅参数，包括采样间隔、目标地址和编码格式。

接口能力与限制对照

接口	传输层	数据格式	事务支持	典型频率	Ciena 支持情况
CLI	SSH/Telnet	文本	无	手动/低频	全平台
NETCONF	SSH (830)	XML/YANG	candidate/confirmed-commit	中低频	SAOS、6500
RESTCONF	HTTP/HTTPS	JSON/XML	部分（依赖实现）	中低频	SAOS、Blue Planet 北向
gRPC	HTTP/2	Protobuf	流式订阅	秒级/亚秒级	WaveLogic、部分 SAOS
SNMP	UDP (161/162)	OID/MIB	无	分钟级	全平台
TL1	TCP (3082)	命令码	无	低频	6500 等传输平台

需要特别注意的是，同一台设备上不同接口看到的配置视图可能不完全一致。例如通过 CLI 修改的配置，NETCONF 的 running 数据存储会同步反映，但部分厂商私有 MIB 的 SNMP 视图可能滞后。做自动化时，应固定使用一种接口作为配置权威源，其他接口仅用于监控或兜底，避免多接口并发写入导致配置漂移。

TL1 和 SNMP 均不支持事务回滚，批量操作时若中途失败，设备可能处于部分配置状态。建议在批量变更前先通过 NETCONF 的 candidate 数据存储预演，确认无误后再提交到 running。

总结来看，Ciena 设备的多接口并存不是冗余，而是面向不同运维阶段的分层设计。理解每种接口的协议栈位置、数据模型能力和适用边界，才能在自动化工程中做出稳定、可维护的接口选型。