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>
<target><candidate/></target>
<config>...YANG 負載...</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 自動化的實際運行

預約我們工程團隊的現場演示——帶上您的自動化需求,我們會為您具體展示 OcNOS 如何接入您的流水線。