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），可對整個設備群的容器生命周期進行編排。

另外： IP Infusion ships an official Zabbix SNMP 模板 適用於 OcNOS — 讓仍在與 gNMI 並行使用傳統 SNMP NOC 工具的團隊可進行設備發現與監控。

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

官方 IPI 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 在 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 監控？

可以。IP Infusion 為 OcNOS 提供官方 Zabbix SNMP 模板，開箱即用地實現設備發現與監控。對於仍在使用 SNMP NOC 工具的團隊，OcNOS 也能與 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