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

自動化 &
Programmability

您現有的 NetDevOps 工具從第一天起即可使用。OcNOS 通過標準、開放的接口暴露每一項配置和運行狀態，無需螢幕抓取，也無需專有編排器。

網路團隊正從以 CLI 為中心的運維方式向可編程、API 驅動的自動化轉型。OcNOS 正是為此轉型而構建。所有協議狀態、配置元素與運行指標均可通過 Ansible、NETCONF/YANG、gNMI、REST 與 Docker 訪問：與 Cisco IOS-XR 和 Juniper Junos 暴露的標準接口完全一致。差異在於平台:開放硬體、開放軟體,以及一小部分的成本。

應用說明

工程師所用的 playbook。

經現場驗證的 Ansible 與 OcNOS 整合實操指南：模組、清單模式以及 Day-0/1/2 playbook 結構。

應用說明

網路管理自動化：將 Ansible 與 OcNOS 整合

官方 IP Infusion Ansible Collection：涵蓋 BGP、EVPN-VXLAN 及 OcNOS 專屬操作的模組、清單（inventory）模式與 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 已配置

ok: [leaf-01..04] – BGP-LU 疊加已建立

ok: [all] – 配置備份已保存

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>

</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 下載其作業系統鏡像和啟動配置，加以應用，隨後接入網路，全程無需 console 線纜，也無需工程師到場。將 ZTP 與 Ansible 結合，即可構建完整的 Day 0 至 Day 2 流水線。

實際應用場景： 在一個周末內、無需現場工程師即完成配置的 48 節點 AI GPU 叢集 leaf-spine 架構。ZTP 啟動每臺交換機,Ansible 下發 BGP + PFC 配置,gNMI 確認無損架構。

IP Maestro EMS

Web UI · REST API · OcNOS 網元管理

專為希望在 API 自動化之外也擁有圖形介面的團隊而設。IP Maestro 是一套以圖形介面為基礎、專為 OcNOS 打造的網元管理系統 (EMS)：提供互動式拓撲地圖、資產清單與設備詳細資訊、故障與效能監控、組態與軟體管理，以及串流遙測視覺化。它透過 NETCONF 與 OcNOS 設備通訊，並提供北向 REST API，讓上層控制器或 OSS 得以與其整合。

了解 IP Maestro

Docker & 交換機內容器

OcNOS 7.0 · Docker · Kubernetes

OcNOS 7.0 在交換機上原生承載 Docker 容器：可在 NOS 旁邊運行 Telegraf 代理、Zabbix 代理、自定義 Python 監控腳本或安全工具、無需外部計算硬體。同時支持 Kubernetes（K8s），可對整個設備群的容器生命周期進行編排。

另外： OcNOS 提供標準化 SNMP MIBs，因此可使用 Zabbix 的通用 SNMP 模板進行監控，讓基於 SNMP 的傳統 NOC 工具與 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 映像與基礎組態。設備啟動後即可管理。無需主控台纜線。無需工程師到場。整個機架在您的團隊休息期間即完成佈建。

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 streams sub-second telemetry to Telegraf → Prometheus → Grafana. Ansible handles config drift detection, scheduled backups, and software upgrades. Docker runs custom tools on-switch. IP Maestro 提供拓撲、故障監控，以及排程組態與軟體更新。

gNMI Telegraf Grafana Docker 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：命令行測試

交換機內計算

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 同時支持 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 與周期性兩種訂閱模式。可直接連接 Telegraf(gNMI 輸入插件)、Prometheus(gNMI 導出器)或任何兼容 gRPC 的採集器,並在 Grafana 中可視化。提供 100 多條傳感器路徑,覆蓋接口、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 上運行 Docker 容器嗎？

OcNOS 7.0 原生支持在交換機上運行 Docker 容器。運維方可在 NOS 之外直接運行第三方監控代理(Telegraf、Zabbix)、安全工具或自定義 Python/Go 腳本、無需外部計算資源。Kubernetes(K8s)亦受支持,可在整個 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-SP、OcNOS-DC 與 IP Maestro：在您的全部設備上形成一致的流水線。

立即開始

了解 OcNOS 自動化的實際運行

預約與我們工程團隊的現場演示。帶上您的自動化需求，我們將為您精確展示 OcNOS 如何與您的流水線整合。

預約技術演示免費試用 OcNOS → 查看文檔 →

解決方案

產品

合作夥伴

資源

公司

自動化 &Programmability