OcNOS 7.0 · Ansible · NETCONF/YANG · gNMI · ZTP · Docker

自动化 &
Programmability

OcNOS 通过标准、开放的接口公开全部配置与运行状态——既无需屏幕抓取，也不依赖专有编排器，您现有的 NetDevOps 工具从第一天起即可工作。

网络团队正从以 CLI 为中心的运维方式向可编程、API 驱动的自动化转型。OcNOS 正是为此转型而构建。所有协议状态、配置元素与运行指标均可通过 Ansible、NETCONF/YANG、gNMI、REST 与 Docker 访问 — 与 Cisco IOS-XR 和 Juniper Junos 暴露的标准接口完全一致。差异在于平台:开放硬件、开放软件,以及一小部分的成本。

OcNOS 自动化所解决的问题

之前

手动 CLI 操作

配置通过 SSH 逐台下发，SNMP 以 5 分钟间隔轮询，新硬件需工程师到场上架与布线，没有结构化状态记录，也没有回滚机制。

→

采用 OcNOS 后

从 Day 0 到 Day N 全程可编程

Ansible 可在数分钟内将 BGP 与 EVPN-VXLAN 部署到 100 台交换机；gNMI 以亚秒级粒度流式上送遥测；ZTP 在零人工干预下完成新硬件启动；回滚耗时仅几秒。

可编程接口

自动化 OcNOS 的 6 种方式

可任选其一，也可六者并用。OcNOS 不会强制使用专有编排器——它能与您团队已有的工具协同工作。

Ansible 集合

ansible-galaxy collection install ipinfusion.ocnos

在 Ansible Galaxy 上发布的 IP Infusion 官方 collection，包含的模块： ocnos_facts, ocnos_config, ocnos_command, ocnos_bgp_facts, and ocnos_isis_facts。用于动态全局配置的 Jinja2 模板。直接使用您现有的 Ansible playbook — OcNOS 与 Arista、Juniper 与 Cisco 使用相同的语言。

ansible-playbook deploy-sr-mpls.yml

$ansible-playbook -i inventory deploy-sr-mpls.yml

ok: [spine-01] — IS-IS + SR-MPLS 已配置

ok: [leaf-01..04] — BGP-LU overlay up

ok: [all] — config backup saved

PLAY RECAP · 5 台交换机 · 0 失败 · 0:42 用时

OcNOS 文档中的 Ansible 指南

NETCONF / YANG 1.1

IPI 原生 + OpenConfig 模型 · RFC 6241

完整的 NETCONF 1.1，同时支持 IPI 原生与 OpenConfig YANG 数据模型，提供结构化的配置与运行状态读取—— get, edit-config, commit, rollback, and candidate datastore. Works with Python's ncclient library, Ansible's netconf_config module, or any NETCONF client.

netconf — edit-config + commit

<edit-config>

</edit-config>

<ok/> ← 候选已锁定

<commit/> ← applied atomically

gNMI 流式遥测

OcNOS 7.0 · On-Change + 定期 · 100+ 传感器路径

通过 gRPC 上的 gNMI 提供实时推送式遥测，取代 SNMP 轮询，针对接口、BGP 会话状态、MPLS 转发、QoS 队列、PFC/ECN 计数器与系统健康度提供结构化的亚秒级更新。可对接： Telegraf、Prometheus 或任何兼容 gRPC 的采集器 — 在 Grafana 中可视化。

gnmic subscribe — interfaces

$gnmic subscribe --path /interfaces/interface[name=et-0/0/1]/

in-octets： 4,218,753,012

out-octets：3,874,112,440

mode: ON_CHANGE · encoding: PROTO

零接触配置

DHCP + TFTP/HTTP · Day 0 自动化

上架、接线、上电。其余全部由 ZTP 处理。DHCP 分配地址并指向预配置服务器。交换机通过 TFTP 或 HTTP 下载其 OS 镜像和启动配置,应用后加入网络 — 无需控制台线缆,无需现场工程师。将 ZTP 与 Ansible 结合,即可获得从 Day 0 到 Day 2 的完整流水线。

实际应用场景： 在一个周末内、无需现场工程师即完成配置的 48 节点 AI GPU 集群 leaf-spine 架构。ZTP 启动每台交换机,Ansible 下发 BGP + PFC 配置,gNMI 确认无损架构。

IP Maestro GUI 编排

Web UI · REST API · 单一面板 OcNOS 管理

面向希望在 API 自动化之外保留可视化控制的团队。IP Maestro 提供整个 OcNOS 资产的交互式拓扑视图、GUI 驱动的 ZTP 仪表板、软件生命周期管理(升级、调度、回滚)、流式遥测可视化以及配置模板。同时提供 REST API,可与 OSS/BSS 及 CI/CD 流水线集成。

了解 IP Maestro

Docker & 交换机内容器

OcNOS 7.0 · Docker · Kubernetes

OcNOS 7.0 在交换机上原生承载 Docker 容器：可在 NOS 旁边运行 Telegraf 代理、Zabbix 代理、自定义 Python 监控脚本或安全工具——无需外部计算硬件。同时支持 Kubernetes（K8s），可对整个设备群的容器生命周期进行编排。

另外： OcNOS exposes standard SNMP MIBs, so it can be monitored with Zabbix's generic SNMP templates — keeping legacy SNMP-based NOC tooling working alongside gNMI.

100+ gNMI 传感器路径

6 自动化接口

0 需要专有编排器

600+ 生产网络

Day 0 首次自动下发

覆盖完整生命周期

Day 0 → Day 1 → Day 2

OcNOS 通过开放标准工具覆盖完整的运维生命周期——无需专有编排器、无需 CLI 脚本、也无需 SNMP 轮询。

Day 0 — 配置

硬件自动接入网络

交换机上电后，DHCP 分配 IP，ZTP 通过 TFTP/HTTP 下载 OcNOS 镜像与基础配置，设备自动注册到 IP Maestro。无需 console 线缆、无需工程师到场——整个机架在团队休息时即可完成自动开通。

ZTP DHCP IP Maestro

Day 1 — 配置

服务以分钟级而非天级部署

通过 Ansible playbook 在全网下发 BGP、MPLS、EVPN-VXLAN、QoS、ACL 与时钟配置；NETCONF/YANG 保证结构化、可校验的下发，并在失败时自动回滚；意图化部署可使用 IP Maestro 模板。

Ansible NETCONF/YANG OpenConfig IP Maestro

Day 2 — 运维

实时可视化、自动修复

gNMI 将亚秒级遥测流式发送至 Telegraf → Prometheus → Grafana。Ansible 负责配置漂移检测、定期备份与软件升级。Docker 在交换机上运行自定义工具。IP Maestro 提供拓扑告警与生命周期调度。

gNMI Telegraf Grafana Docker Zabbix

生态系统

与您现有的技术栈协同

OcNOS 使用标准协议——无需对工具链推倒重来，您团队已熟悉的工具从第一天起就能正常使用。

配置管理

Ansible

官方 Galaxy 集合 — ipinfusion.ocnos

遥测采集器

Telegraf

gNMI 输入插件,直接订阅

指标存储

Prometheus

gNMI 导出器,时序指标

可视化

Grafana

面向 OcNOS 遥测的预构建仪表板

SNMP 监控

Zabbix

Standard SNMP MIBs — works with Zabbix SNMP templates

Python NETCONF

ncclient

标准 Python 库，完整 NETCONF 1.1

gNMI CLI 客户端

gnmic

subscribe、get、set — 命令行测试

交换机内计算

Docker / K8s

OcNOS 7.0 中原生集成的容器运行时

常见问题

OcNOS 自动化，一文读懂

网络工程师在部署前真正会问的问题。

OcNOS 是否支持 Ansible？

支持。IP Infusion 在 Ansible Galaxy 上发布了官方 Ansible Collection(ipinfusion.ocnos),包含用于事实收集、命令执行、配置管理以及协议专用操作的模块,包括 ocnos_facts、ocnos_config、ocnos_command、ocnos_ping、ocnos_bgp_facts 与 ocnos_isis_facts。Playbook 使用 Jinja2 模板,实现对数百台 OcNOS 设备的全局动态配置。

OcNOS 支持哪些 YANG 模型？

OcNOS 在 NETCONF 1.1 上同时支持 IPI 原生 YANG 模型与 OpenConfig 模型。这使得结构化配置与运行状态检索成为可能 — get、edit-config、commit、rollback 与 candidate datastore 操作。这与 Cisco IOS-XR 和 Juniper Junos 所采用的模型驱动方式一致。Python 的 ncclient 库可直接与 OcNOS NETCONF 协同工作。

可以将 OcNOS 遥测流式上送到 Grafana 或 Prometheus 吗？

支持。OcNOS 7.0 支持 gNMI 流式遥测,提供 on-change 与周期性两种订阅模式。可直接连接 Telegraf(gNMI 输入插件)、Prometheus(gNMI 导出器)或任何兼容 gRPC 的采集器,并在 Grafana 中可视化。提供 100 多条传感器路径,覆盖接口、BGP 状态、MPLS 标签、QoS 队列、PFC 计数器与系统健康 — 以推送式结构化数据取代 SNMP 轮询。

OcNOS 中的 Zero Touch Provisioning（ZTP）是什么？

ZTP 完全自动化 Day 0 设备上线。新交换机加电后,通过 DHCP 定位预配置服务器,经 TFTP 或 HTTP 下载正确的 OcNOS 镜像与启动配置 — 无需控制台线缆,无需现场工程师。结合 Ansible 后,ZTP 覆盖从 Day 0 到 Day 2 的完整生命周期:ZTP 负责首次启动与镜像下发,Ansible 负责持续配置管理,gNMI 负责运行监控。

可以直接在 OcNOS 上运行 Docker 容器吗？

OcNOS 7.0 原生支持在交换机上运行 Docker 容器。运维方可在 NOS 之外直接运行第三方监控代理(Telegraf、Zabbix)、安全工具或自定义 Python/Go 脚本 — 无需外部计算资源。Kubernetes(K8s)亦受支持,可在整个 OcNOS 交换机集群范围内管理容器生命周期。

OcNOS 是否可与 Zabbix 配合用于 SNMP 监控？

Yes. OcNOS exposes standard SNMP MIBs, so it can be monitored with Zabbix using Zabbix's generic SNMP device templates. For teams still using SNMP-based NOC tooling, OcNOS runs SNMP alongside gNMI — you can operate both in parallel during a migration to streaming telemetry.

OcNOS 自动化与 Arista EOS 或 Cisco NX-OS 相比如何？

OcNOS 暴露与 Arista EOS 与 Cisco NX-OS 相同的标准接口 — NETCONF/YANG、gNMI、OpenConfig、Ansible。差异在于平台:OcNOS 运行于 Edgecore、UfiSpace 等白盒厂商提供的经过验证的开放硬件上,总体成本显著更低。您现有的 Ansible playbook 与 Grafana 仪表板只需极少改动即可迁移到 OcNOS。

可自动化的产品

用一套工具链管理整个开放网络

本页提及的每个自动化接口都同时适用于 OcNOS-SP、OcNOS-DC 与 IP Maestro——在您的全部设备上形成一致的流水线。

立即开始

了解 OcNOS 自动化的实际运行

预约我们工程团队的现场演示——带上您的自动化需求，我们会为您具体展示 OcNOS 如何接入您的流水线。

预约技术演示免费试用 OcNOS → 查看文档 →

解决方案

产品

资源

合作伙伴

公司

自动化 &Programmability