Home · Documentazione · Tecnologia · NETCONF & YANG

NETCONF, YANG e Zero-Touch Provisioning

OcNOS ti offre la superficie di configurazione model-driven completa: NETCONF su SSH/TLS, OpenConfig e IETF YANG, un datastore candidate con commit/rollback e un flusso Zero-Touch Provisioning che porta uno chassis nuovo di fabbrica dall'apertura della scatola allo stato operativo con un lease DHCP.

Flusso di Zero-Touch Provisioning Day-0

Un router OcNOS appena uscito di fabbrica si avvia, richiede un lease DHCP, recupera l'immagine corretta dal server di staging, scarica la propria configurazione resa in YANG dal config server, esegue il commit sul running datastore e segnala lo stato operativo. Nessun operatore in loco.

Flusso di provisioning NETCONF e ZTP: avvio OcNOS verso DHCP, server immagine, server di configurazione e stato operativo
NETCONF e ZTP: flusso di provisioning Day-0 dall'avvio attraverso i server immagine e di configurazione fino allo stato operativo.

Perché la configurazione model-driven è importante

Gli script CLI non si compongono, non eseguono rollback e non validano gli input rispetto a uno schema. NETCONF + YANG le offre una superficie di configurazione tipizzata e transazionale: invia un candidate, lo valida, esegue il commit oppure il rollback se un qualsiasi leaf viene rifiutato. OcNOS espone sia modelli OpenConfig (BGP, interfaces, network-instance, platform) sia modelli IETF (ietf-interfaces, ietf-routing, ietf-system), oltre ai modelli nativi di IP Infusion per i parametri specifici di OcNOS. In combinazione con lo Zero-Touch Provisioning, il workflow operativo diventa: installa l'apparato nel rack, collega la gestione, allontanati.

L'implementazione OcNOS di NETCONF, YANG e ZTP

NETCONF

Trasporto SSH + TLS

Protocollo NETCONF RFC 6241, su SSH (RFC 6242) e TLS (RFC 7589), con supporto completo per gli RPC Get / Get-Config / Edit-Config / Commit / Validate / Lock / Discard-Changes.

Modelli YANG

OpenConfig + IETF + nativo

OpenConfig BGP, interfaces, network-instance, platform, telemetry; IETF system, interfaces, routing; modelli nativi IP Infusion per funzionalità uniche.

Datastores

candidate + commit / rollback

Datastore candidate completo con confirmed commit (RFC 6241), rollback esplicito agli N commit precedenti e consultazione della cronologia di configurazione.

ZTP

Provisioning Day-0

Boot pilotato da DHCP option 67 / 239: recupero dell'immagine, verifica della firma, installazione, reboot; quindi recupero del config bundle e commit. Retry idempotente in caso di guasto parziale.

Ansible / Salt

Moduli di riferimento

Collection Ansible Galaxy e formule Salt per OcNOS NETCONF: play idempotenti per BGP, interfacce e ruoli EVPN pronti all'uso.

gNMI

Coesistenza con NETCONF

gNMI Set e NETCONF Edit-Config puntano allo stesso model store. Scelga il protocollo più adatto ai suoi strumenti: il dispositivo si comporta allo stesso modo.

Cosa si ottiene con l'automazione OcNOS

  • Una sola superficie di configurazione, due protocolli. NETCONF e gNMI puntano entrambi allo stesso datastore modellato in YANG, senza gap di funzionalità specifici per protocollo.
  • ZTP verificato. Il fetch dell'immagine Day-0 è verificato tramite firma; l'integrità del config bundle viene controllata prima del commit. Zero interventi on-site, con piena affidabilità.
  • Tooling aperto. Pubblicati una collection Ansible di riferimento, formula Salt ed esempi di client Python, senza alcun lock-in a SDK proprietari.
  • Rollback operativo. Ogni commit viene tracciato. Effettui il rollback a qualsiasi stato precedente con un'unica RPC se una modifica va storta.
Telemetria in streaming OcNOS-SP OcNOS-DC Automazione della rete

Stai allestendo uno stack di operazioni model-driven?

Richiedi una Demo Tecnica →
FAQ

Domande frequenti

Quali modelli YANG supporta OcNOS tramite NETCONF?
OcNOS espone modelli OpenConfig (BGP, interfaces, network-instance, platform, telemetry), modelli IETF (ietf-system, ietf-interfaces, ietf-routing) e modelli nativi IP Infusion per le funzionalità specifiche di OcNOS.
OcNOS supporta il rollback della configurazione?
Sì. OcNOS fornisce un datastore candidate completo con confirmed commit (RFC 6241), rollback esplicito ai commit precedenti e consultazione della cronologia di configurazione, cosicché una modifica respinta può essere annullata mediante un singolo RPC.
Come funziona lo Zero-Touch Provisioning in OcNOS?
Un router appena uscito di fabbrica si avvia, richiede un lease DHCP (opzione 67/239), recupera la propria immagine e ne verifica la firma, quindi scarica e applica tramite commit il proprio bundle di configurazione reso in YANG, raggiungendo lo stato operativo senza operatore in sede. I guasti parziali vengono ritentati in modo idempotente.
Posso utilizzare sia NETCONF sia gNMI su OcNOS?
Sì. NETCONF Edit-Config e gNMI Set puntano allo stesso datastore modellato in YANG, per cui potete scegliere il protocollo più adatto al vostro tooling e il dispositivo si comporta allo stesso modo.
OcNOS funziona con Ansible e Salt?
Sì. IP Infusion pubblica una collection Ansible Galaxy di riferimento e formule Salt per OcNOS NETCONF, con role play BGP, di interfaccia ed EVPN idempotenti e senza lock-in proprietario di SDK.
Datasheet e schede soluzione

Approfondite. Portatelo con voi.

Due download tecnici e sintetici che vanno oltre questa pagina: il datasheet completo di OcNOS-SP e il datasheet completo di OcNOS-DC.

Datasheet

Datasheet OcNOS-SP

Specifica completa di OcNOS-SP: il set di funzionalità access, cell site e aggregazione, gli SKU software, le piattaforme hardware supportate e la guida all'ordine della soluzione.

Ottieni il datasheet
Datasheet

Datasheet OcNOS-DC

Specifica completa di OcNOS-DC: il set di funzionalità EVPN-VXLAN e Ethernet for AI, gli SKU software, le piattaforme hardware supportate e la guida all'ordine della soluzione.

Ottieni il datasheet