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

自动化 &
Programmability

您现有的 NetDevOps 工具从第一天起即可使用。OcNOS 通过标准、开放的接口暴露每一项配置和运行状态,无需屏幕抓取,也无需专有编排器。

网络团队正从以CLI为主的运维方式转向可编程、API驱动的自动化。OcNOS正是为这一转型而构建。每一项协议状态、配置元素和运行指标,均可通过Ansible、NETCONF/YANG、gNMI和OpenConfig访问:这与Cisco IOS-XR和Juniper Junos所提供的标准模型驱动接口完全一致。不同之处在于平台本身:开放硬件、开放软件,成本仅为一小部分。
应用说明

工程师所用的 playbook。

经现场验证的 Ansible 与 OcNOS 集成实操指南:模块、清单模式以及 Day-0/1/2 playbook 结构。

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,以及 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 configured
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,以及 candidate 数据存储。可与 Python 的 ncclient library, Ansible's netconf_config 模块,或任何 NETCONF 客户端。

netconf: edit-config + commit
<edit-config>
<target><candidate/></target>
<config>...YANG 负载...</config>
</edit-config>
<ok/> ← 候选已锁定
<commit/> ← applied atomically

gNMI 流式遥测

OcNOS 7.0 · Dial-in + Dial-out · On-Change + Periodic · TLS

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

gnmic subscribe: interfaces
$gnmic subscribe --path /interfaces/interface[name=eth1]/
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 下载其操作系统镜像和启动配置,加以应用,随后接入网络,全程无需 console 线缆,也无需工程师到场。将 ZTP 与 Ansible 结合,即可构建完整的 Day 0 至 Day 2 流水线。

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

IP Maestro EMS

Web 界面 · REST API · OcNOS 网元管理

专为希望在 API 自动化之外同时拥有 GUI 的团队打造。IP Maestro 是一款面向 OcNOS、基于 GUI 的网元管理系统(EMS):提供交互式拓扑地图、设备清单与设备详情、故障与性能监控、配置与软件管理,以及流式遥测可视化。它通过 NETCONF 与 OcNOS 设备通信,并提供北向 REST API,使上层控制器或 OSS 能够与之集成。

了解 IP Maestro

交换机上容器

OcNOS 7.0 · 容器运行时(K3S)· 单容器

OcNOS 7.0内置交换机上容器运行时(K3S),支持单容器生命周期管理。可在交换机上直接运行Telegraf代理、Zabbix代理、自定义Python或Go脚本,或安全工具,与NOS并行运行,无需额外的计算硬件。标准SSH、SCP、SFTP和FTP负责传输镜像和配置文件。

另外: OcNOS 提供标准化 SNMP MIBs,因此可使用 Zabbix 的通用 SNMP 模板进行监控,让基于 SNMP 的传统 NOC 工具与 gNMI 并行运作。

云原生运维

从设计之初即模型驱动、事务化且具备弹性

这正是工程师对现代NOS所期望的运维模式:结构化状态、可安全回滚的变更、流式可视性,以及控制平面弹性。标准接口,开放硬件。

模型驱动配置

OpenConfig + IPI-native YANG · NETCONF 1.1

配置和运行状态均为结构化数据,而非屏幕抓取的文本。编辑候选数据存储,然后原子化提交或回滚,这与Cisco IOS-XR和Juniper Junos所采用的模型驱动工作流相同,均基于标准NETCONF 1.1,并使用OpenConfig和IPI-native YANG模型。

双向流式遥测

gNMI · dial-in + dial-out · TLS · multi-VRF

gNMI Subscribe(dial-in)与Publish(通过grpctunnel实现的dial-out),支持On-Change和周期性两种模式,并通过TLS按用户进行身份验证保护。可在单个或多个VRF上以带内方式运行,基于OpenConfig模型。为Telegraf、Prometheus和Grafana提供推送式结构化状态数据,取代SNMP轮询。

控制平面弹性

Graceful Restart / NSF · BGP · OSPF · IS-IS

Graceful Restart结合Non-Stop Forwarding,可在控制平面重启期间保持数据平面持续转发,适用于BGP、OSPF、OSPFv3和IS-IS。进程重启和计划性维护不会导致过境流量中断。

交换机上可编程性

容器运行时(K3S)· ZTP · SSH/SCP/SFTP

通过内置运行时(K3S,单容器生命周期管理),可在交换机上直接以容器方式运行代理或工具,使采集器、脚本或探针与NOS并行运行,无需外部计算资源。ZTP可实现新硬件免手动开局,SSH、SCP、SFTP和FTP用于传输镜像和配置文件。

gNMI 流式传输,而非轮询
6 自动化接口
0 需要专有编排器
600+ 生产网络
Day 0 首次自动下发
覆盖完整生命周期

Day 0 → Day 1 → Day 2

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

Day 0:配置

硬件自动接入网络

交换机上电。DHCP 分配 IP。ZTP 通过 TFTP/HTTP 下载 OcNOS 镜像与基础配置。设备启动后即可管理。无需控制台线缆。无需工程师到场。整个机架在您的团队休息期间即完成配置。

ZTP DHCP OcNOS
Day 1:配置

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

Ansible playbook 将 BGP、MPLS、EVPN-VXLAN、QoS、ACL 和授时配置下发到整个设备群。NETCONF/YANG 确保下发结构化、经过验证,并在失败时回滚。 IP Maestro,面向OcNOS的基于GUI的EMS,增加了基于GUI的配置下发与调度功能。

Ansible NETCONF/YANG OpenConfig IP Maestro
Day 2:运维

实时可视化、自动修复

gNMI将遥测数据流式传输至Telegraf → Prometheus → Grafana。Ansible负责配置漂移检测、定时备份和软件升级。交换机上的容器运行自定义工具。IP Maestro提供拓扑、故障监控,以及定时配置和软件更新。

gNMI Telegraf Grafana 容器 Zabbix
生态系统

与您现有的技术栈协同

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

配置管理

Ansible

官方 Galaxy 集合:ipinfusion.ocnos

遥测采集器

Telegraf

gNMI 输入插件,直接订阅

指标存储

Prometheus

gNMI 导出器,时序指标

可视化

Grafana

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

SNMP 监控

Zabbix

标准 SNMP MIB,兼容 Zabbix SNMP 模板

Python NETCONF

ncclient

标准 Python 库,完整 NETCONF 1.1

gNMI CLI 客户端

gnmic

subscribe、get、set:命令行测试

交换机内计算

K3S运行时

单容器运行时,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 同时支持 IPI 原生 YANG 模型以及通过 NETCONF 1.1 承载的 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和周期性两种订阅模式,支持dial-in和dial-out(grpctunnel)两种方式,并通过TLS和按用户身份验证进行安全保护。可直接连接Telegraf(gNMI输入插件)、Prometheus(gNMI导出器)或任何兼容gRPC的采集器,并在Grafana中实现可视化。传感器路径涵盖接口、BGP状态、MPLS标签、QoS队列、PFC计数器和系统健康状况,以推送式结构化数据取代SNMP轮询。
OcNOS 中的 Zero Touch Provisioning(ZTP)是什么?
ZTP 将 Day 0 设备配置完全自动化。当新交换机上电时,它通过 DHCP 定位部署服务器,然后经由 TFTP 或 HTTP 下载正确的 OcNOS 镜像和启动配置,无需 console 线缆、无需工程师到现场。与 Ansible 结合后,ZTP 覆盖从 Day 0 到 Day 2 的完整生命周期:ZTP 负责初始引导和镜像分发,Ansible 负责持续的配置管理,gNMI 负责运维监控。
能否在OcNOS上直接运行容器?
OcNOS 7.0内置交换机上容器运行时(K3S),用于单容器生命周期管理。可在交换机上直接运行第三方监控代理(如Telegraf或Zabbix代理)、安全工具,或自定义Python或Go脚本,与NOS并行运行,无需外部计算资源。标准SSH、SCP、SFTP和FTP负责镜像和配置文件传输。
OcNOS是否云原生?
OcNOS是一款模型驱动、API优先的NOS,专为开放硬件上的自动化运维而构建。配置和运行状态通过OpenConfig和IPI-native YANG,基于NETCONF 1.1呈现为结构化数据,采用候选数据存储、原子化提交和回滚,而非屏幕抓取式CLI。遥测数据通过gNMI(dial-in与dial-out、on-change与periodic、TLS加密、单或多VRF)流式传输,取代SNMP轮询。Graceful Restart结合Non-Stop Forwarding,可在控制平面重启期间保持数据平面持续转发,内置容器运行时则可在交换机上承载各类代理。所有接口均为标准接口,因此管理Cisco或Arista的同一套NetDevOps流水线,同样可以管理运行在Broadcom白盒硬件上、成本更低的OcNOS。
OcNOS 是否可与 Zabbix 配合用于 SNMP 监控?
是的。OcNOS 暴露标准的 SNMP MIB,因此可使用 Zabbix 的通用 SNMP 设备模板通过 Zabbix 进行监控。对于仍在使用基于 SNMP 的 NOC 工具的团队,OcNOS 可让 SNMP 与 gNMI 并存。在向流式遥测迁移的过程中,你可以并行运行两者。
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 自动化的实际运行

预约与我们工程团队的现场演示。带上您的自动化需求,我们将为您精确展示 OcNOS 如何与您的流水线集成。