Home/ Prodotti/ Automazione e programmabilità
OcNOS 7.0 · Ansible · NETCONF/YANG · gNMI · ZTP · Containers

Automazione &
Programmability

I Suoi strumenti NetDevOps esistenti funzionano fin dal primo giorno. OcNOS espone ogni configurazione e ogni stato operativo tramite interfacce standard e aperte, senza screen-scraping e senza orchestratori proprietari.

Prenota una demo Provi OcNOS gratis → Leggi la documentazione →
I team di rete stanno passando da operazioni basate su CLI ad automazione programmabile e basata su API. OcNOS è costruito per questa transizione. Ogni stato dei protocolli, elemento di configurazione e metrica operativa è accessibile tramite Ansible, NETCONF/YANG, gNMI e OpenConfig: le stesse interfacce standard, model-driven, esposte da Cisco IOS-XR e Juniper Junos. La differenza è la piattaforma: hardware aperto, software aperto e una frazione del costo.
Nota applicativa

I playbook usati dagli ingegneri.

Una guida pratica e collaudata sul campo all'integrazione di Ansible con OcNOS: moduli, pattern di inventory e la struttura dei playbook Day-0/1/2.

Nota applicativa

Automatizzare la gestione della rete: integrare Ansible con OcNOS

Ansible Collection ufficiale di IP Infusion: moduli, pattern di inventory ed esempi di playbook che coprono BGP, EVPN-VXLAN e operazioni specifiche di OcNOS.

Ottieni la nota applicativa
Il problema che l'automazione OcNOS risolve
Prima

Operazioni CLI manuali

Configurazione distribuita dispositivo per dispositivo via SSH. Polling SNMP con intervalli di 5 minuti. Ingegneri on-site per installare e cablare il nuovo hardware. Nessuno stato strutturato, nessun rollback.

→
Dopo OcNOS

Completamente programmabile, dal Day 0 al Day N

Ansible distribuisce BGP e EVPN-VXLAN su 100 switch in pochi minuti. gNMI trasmette telemetria con aggiornamenti sub-secondo. ZTP avvia il nuovo hardware senza intervento umano. Rollback in pochi secondi.

Interfacce programmabili

Sei modi per automatizzare OcNOS

Ne scelga uno o le utilizzi tutte e sei insieme. OcNOS non impone un orchestratore proprietario: funziona con gli strumenti che il suo team già utilizza.

Ansible Collection

ansible-galaxy collection install ipinfusion.ocnos

Collezione ufficiale IP Infusion su Ansible Galaxy. Moduli inclusi: ocnos_facts, ocnos_config, ocnos_command, ocnos_bgp_facts, e ocnos_isis_facts. Templating Jinja2 per provisioning dinamico esteso all'intera flotta. Utilizzi gli stessi playbook Ansible che già scrive – OcNOS parla la stessa lingua di Arista, Juniper e 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 switch · 0 errori · 0:42 trascorsi
Guida Ansible nella documentazione OcNOS

NETCONF / YANG 1.1

Modelli IPI nativi + OpenConfig · RFC 6241

NETCONF 1.1 completo con modelli dati YANG IPI-native e OpenConfig. Recupero strutturato di configurazione e stato operativo: get, edit-config, commit, rollback, e il datastore candidate. Funziona con il ncclient library, Ansible's netconf_config modulo, o qualsiasi client NETCONF.

netconf: edit-config + commit
<edit-config>
<target><candidate/></target>
<config>...payload YANG...</config>
</edit-config>
<ok/> ← candidato bloccato
<commit/> ← applied atomically

Telemetria gNMI in streaming

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

Telemetria push in tempo reale via gNMI su gRPC. Sostituisce il polling SNMP con aggiornamenti strutturati sub-secondo su interfacce, stato delle sessioni BGP, forwarding MPLS, code QoS, contatori PFC/ECN e salute del sistema. Si connetta a Telegraf, Prometheus o qualsiasi collector gRPC, quindi visualizzi in 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

Zero Touch Provisioning

DHCP + TFTP/HTTP · automazione Day 0

Lo monti nel rack. Lo cabli. Lo accendi. Lo ZTP gestisce tutto il resto. Il DHCP assegna un indirizzo e indirizza verso un provisioning server. Lo switch scarica la propria immagine OS e la startup config tramite TFTP o HTTP, le applica e si unisce alla rete, senza cavo console e senza un tecnico in loco. Combini lo ZTP con Ansible per una pipeline completa dal Day 0 al Day 2.

Caso d'uso reale: Un fabric leaf-spine per cluster AI GPU a 48 nodi messo in produzione in un weekend senza ingegneri on-site. ZTP avvia ciascuno switch, Ansible distribuisce la configurazione BGP + PFC e gNMI conferma il fabric lossless.

IP Maestro EMS

Interfaccia web · REST API · gestione degli elementi OcNOS

Per i team che desiderano una GUI insieme all'automazione tramite API. IP Maestro è un sistema di gestione degli elementi (EMS) basato su GUI per OcNOS: una mappa interattiva della topologia, inventario e dettagli dei dispositivi, monitoraggio di guasti e prestazioni, gestione di configurazione e software e visualizzazione della telemetria in streaming. Comunica in NETCONF con i dispositivi OcNOS ed espone un'API REST northbound così che un controller di livello superiore o un OSS possa integrarsi con esso.

Esplora IP Maestro

Container on-switch

OcNOS 7.0 · Container runtime (K3S) · container singolo

OcNOS 7.0 include un container runtime on-switch (K3S) con gestione del ciclo di vita per container singolo. Esegui un agente Telegraf, un proxy Zabbix, uno script Python o Go personalizzato o uno strumento di sicurezza direttamente sullo switch, insieme al NOS, senza hardware di calcolo esterno. SSH, SCP, SFTP e FTP standard trasferiscono immagini e configurazioni.

Inoltre: OcNOS espone strumenti standard SNMP MIBs, così può essere monitorato con i template SNMP generici di Zabbix, mantenendo operativi gli strumenti NOC legacy basati su SNMP insieme a gNMI.

Operazioni cloud-native

Model-driven, transazionale e resiliente per progettazione

Il modello operativo che gli ingegneri si aspettano da un NOS moderno: stato strutturato, modifiche sicure con rollback, visibilità in streaming e resilienza del control plane. Interfacce standard, hardware aperto.

Configurazione model-driven

OpenConfig + IPI-native YANG · NETCONF 1.1

La configurazione e lo stato operativo sono dati strutturati, non testo ottenuto tramite screen-scraping. Modifica il candidate datastore, poi esegui il commit atomicamente o il rollback, lo stesso workflow model-driven utilizzato da Cisco IOS-XR e Juniper Junos, su NETCONF 1.1 standard con modelli OpenConfig e IPI-native YANG.

Telemetria in streaming, in entrambe le direzioni

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

gNMI Subscribe (dial-in) e Publish (dial-out su grpctunnel), in modalità on-change e periodica, protetto con TLS e autenticato per utente. Funziona in-band su una o più VRF, su modelli OpenConfig. Stato strutturato push-based per Telegraf, Prometheus e Grafana, al posto del polling SNMP.

Resilienza del control plane

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

Graceful Restart con Non-Stop Forwarding mantiene l'inoltro sul data plane mentre il control plane si riavvia, per BGP, OSPF, OSPFv3 e IS-IS. I riavvii di processo e la manutenzione pianificata non causano la perdita di traffico in transito.

Programmabilità on-switch

Container runtime (K3S) · ZTP · SSH/SCP/SFTP

Esegui un agente o uno strumento in un container direttamente sullo switch tramite il runtime integrato (K3S, ciclo di vita per container singolo), così un collector, uno script o una sonda funziona insieme al NOS senza calcolo esterno. Lo ZTP avvia il nuovo hardware in modo automatico, e SSH, SCP, SFTP e FTP trasferiscono immagini e configurazioni.

gNMI Streaming, non polling
6 Interfacce di automazione
0 Orchestratori proprietari necessari
600+ Reti in produzione
Day 0 Primo push automatizzato
Copertura completa del ciclo di vita

Day 0 → Day 1 → Day 2

OcNOS copre l'intero ciclo di vita operativo con strumenti aperti e standard. Nessun orchestratore proprietario, nessuno scripting CLI, nessun polling SNMP.

Day 0: Provisioning

L'hardware si unisce da solo alla rete

Lo switch viene acceso. Il DHCP assegna un IP. Lo ZTP scarica l'immagine OcNOS e la configurazione di base tramite TFTP/HTTP. L'apparato si avvia pronto per la gestione. Nessun cavo console. Nessun ingegnere in loco. L'intero rack viene provisionato mentre il vostro team riposa.

ZTP DHCP OcNOS
Day 1: Configurazione

Servizi distribuiti in minuti, non in giorni

I playbook Ansible distribuiscono le configurazioni BGP, MPLS, EVPN-VXLAN, QoS, ACL e di temporizzazione sull'intero parco. NETCONF/YANG garantisce distribuzioni strutturate e validate, con rollback in caso di errore. IP Maestro, l'EMS basato su GUI per OcNOS, aggiunge il push della configurazione e la pianificazione tramite interfaccia grafica.

Ansible NETCONF/YANG OpenConfig IP Maestro
Day 2: Operatività

Visibilità in tempo reale, remediation automatica

gNMI trasmette in streaming la telemetria a Telegraf → Prometheus → Grafana. Ansible gestisce il rilevamento del config drift, i backup pianificati e gli aggiornamenti software. Un container on-switch esegue strumenti personalizzati. IP Maestro fornisce topologia, monitoraggio dei guasti e aggiornamenti pianificati di configurazione e software.

gNMI Telegraf Grafana Container Zabbix
Ecosistema

Funziona con il suo stack esistente

OcNOS parla protocolli standard. Nessuna sostituzione integrale della sua toolchain: gli strumenti che il suo team già conosce funzionano fin dal primo giorno.

Gestione della configurazione

Ansible

Collezione Galaxy ufficiale: ipinfusion.ocnos

Collector di telemetria

Telegraf

Plugin di input gNMI, sottoscrizione diretta

Archivio metriche

Prometheus

Esportatore gNMI, metriche di serie temporali

Visualizzazione

Grafana

Dashboard predefinite per la telemetria OcNOS

Monitoraggio SNMP

Zabbix

MIB SNMP standard, funziona con i template SNMP di Zabbix

Python NETCONF

ncclient

Libreria Python standard, NETCONF 1.1 completo

Client CLI gNMI

gnmic

subscribe, get, set: test da riga di comando

Compute su switch

Runtime K3S

Runtime a container singolo, nativo in OcNOS 7.0

Domande frequenti

Automazione OcNOS, con risposte chiare

Domande che pongono gli ingegneri di rete prima del deployment.

OcNOS supporta Ansible?
Sì. IP Infusion pubblica una Ansible Collection ufficiale su Ansible Galaxy (ipinfusion.ocnos). Include moduli per la raccolta di facts, l'esecuzione di comandi, la gestione della configurazione e operazioni protocollo-specifiche tra cui ocnos_facts, ocnos_config, ocnos_command, ocnos_ping, ocnos_bgp_facts e ocnos_isis_facts. I playbook usano il templating Jinja2 per il provisioning dinamico a livello di fleet su centinaia di dispositivi OcNOS.
Quali modelli YANG supporta OcNOS?
OcNOS supporta sia i modelli YANG nativi IPI sia i modelli OpenConfig tramite NETCONF 1.1. Questo consente la configurazione strutturata e il recupero dello stato operativo: operazioni get, edit-config, commit, rollback e candidate datastore. Lo stesso approccio model-driven utilizzato da Cisco IOS-XR e Juniper Junos. La libreria ncclient di Python funziona direttamente con NETCONF di OcNOS.
Posso trasmettere la telemetria di OcNOS verso Grafana o Prometheus?
Sì. OcNOS 7.0 supporta la telemetria in streaming gNMI con modalità di sottoscrizione sia on-change che periodica, in stile dial-in e dial-out (grpctunnel), protetta con TLS e autenticazione per utente. Connettiti direttamente a Telegraf (plugin di input gNMI), Prometheus (exporter gNMI) o qualsiasi collector compatibile con gRPC e visualizza i dati in Grafana. I sensor path coprono interfacce, stato BGP, etichette MPLS, code QoS, contatori PFC e stato di sistema, sostituendo il polling SNMP con dati strutturati push-based.
Cos'è Zero Touch Provisioning (ZTP) in OcNOS?
ZTP automatizza interamente la configurazione del dispositivo al Day 0. Quando un nuovo switch viene acceso, utilizza DHCP per individuare un server di provisioning, quindi scarica l'immagine OcNOS corretta e la configurazione di avvio tramite TFTP o HTTP, senza cavo console e senza la presenza di un ingegnere in loco. In combinazione con Ansible, ZTP copre l'intero ciclo di vita dal Day 0 al Day 2: ZTP gestisce il boot iniziale e la distribuzione dell'immagine, Ansible gestisce la gestione continuativa della configurazione e gNMI gestisce il monitoraggio operativo.
Posso eseguire container direttamente su OcNOS?
OcNOS 7.0 include un container runtime on-switch (K3S) per la gestione del ciclo di vita di un container singolo. Esegui un agente di monitoraggio di terze parti come Telegraf o un proxy Zabbix, uno strumento di sicurezza o uno script Python o Go personalizzato direttamente sullo switch, insieme al NOS, senza calcolo esterno. SSH, SCP, SFTP e FTP standard gestiscono il trasferimento di immagini e configurazioni.
OcNOS è cloud-native?
OcNOS è un NOS model-driven e API-first, costruito per operazioni automatizzate su hardware aperto. La configurazione e lo stato operativo sono dati strutturati tramite OpenConfig e IPI-native YANG su NETCONF 1.1, con candidate datastore, commit atomico e rollback, invece di una CLI basata su screen-scraping. La telemetria viene trasmessa in streaming tramite gNMI (dial-in e dial-out, on-change e periodica, protetta con TLS, VRF singola o multipla) al posto del polling SNMP. Graceful Restart con Non-Stop Forwarding mantiene l'inoltro sul data plane durante i riavvii del control plane, e un container runtime integrato ospita agenti sullo switch. Ogni interfaccia è standard, quindi la stessa pipeline NetDevOps che gestisce Cisco o Arista gestisce anche OcNOS, su hardware whitebox Broadcom a costo inferiore.
OcNOS funziona con Zabbix per il monitoraggio SNMP?
Sì. OcNOS espone le MIB SNMP standard, quindi può essere monitorato con Zabbix utilizzando i template SNMP generici di Zabbix. Per i team che usano ancora strumenti NOC basati su SNMP, OcNOS esegue SNMP insieme a gNMI. È possibile operare entrambi in parallelo durante una migrazione verso la streaming telemetry.
Come si confronta l'automazione OcNOS con Arista EOS o Cisco NX-OS?
OcNOS espone le stesse interfacce standard, NETCONF/YANG, gNMI, OpenConfig e Ansible, di Arista EOS e Cisco NX-OS. La differenza è la piattaforma: OcNOS gira su hardware aperto validato di Edgecore, UfiSpace e altri vendor whitebox, a un costo totale significativamente inferiore. I suoi playbook Ansible e le sue dashboard Grafana esistenti possono migrare a OcNOS con modifiche minime.
Prodotti automatizzabili

Un'unica toolchain per tutta la sua rete aperta

Ogni interfaccia di automazione presente in questa pagina funziona con OcNOS-SP, OcNOS-DC e IP Maestro: un'unica pipeline coerente sull'intero parco installato.

NOS service provider

OcNOS-SP

Automatizzi i deployment SR-MPLS, BGP e mobile backhaul con Ansible. Trasmetta in streaming lo stato di timing IEEE 1588v2 e le metriche di forwarding MPLS tramite gNMI. ZTP per i rollout dei gateway di cell site.

Pagina prodotto OcNOS-SP → NOS per data center

OcNOS-DC

Distribuisca un fabric leaf-spine EVPN-VXLAN con Ansible in meno di un'ora. Trasmetta in streaming i contatori PFC e ECN tramite gNMI per la visibilità sul fabric AI. ZTP per l'onboarding su larga scala dei rack di cluster GPU.

Pagina prodotto OcNOS-DC → EMS per OcNOS

IP Maestro

Il sistema di gestione degli elementi (EMS) con GUI per OcNOS. Visualizzazione della topologia, monitoraggio di guasti e prestazioni, grafici di telemetria, distribuzione e pianificazione della configurazione e aggiornamenti delle immagini software, con un'API REST northbound.

Pagina prodotto IP Maestro →
Inizi oggi stesso

Vedere l'automazione OcNOS in azione

Prenoti una demo live con il nostro team di ingegneria. Porti i Suoi requisiti di automazione e Le mostreremo esattamente come OcNOS si integra con la Sua pipeline.

Prenota una demo tecnica Provi OcNOS gratis → Leggi la documentazione →