NETCONF, YANG et Zero-Touch Provisioning

OcNOS vous offre la surface de configuration pilotée par modèle complète : NETCONF sur SSH/TLS, OpenConfig et IETF YANG, un datastore candidate avec commit/rollback, ainsi qu'un flux Zero-Touch Provisioning qui amène un châssis neuf de son déballage à l'état opérationnel avec un bail DHCP.

Flux de provisioning Zero-Touch Day-0

Un routeur OcNOS sorti d'usine démarre, demande un bail DHCP, récupère la bonne image depuis le serveur de staging, télécharge sa configuration rendue en YANG depuis le serveur de config, la valide dans le datastore en cours d'exécution et se déclare opérationnel. Aucun opérateur sur site.

Flux de provisionnement NETCONF et ZTP : démarrage OcNOS vers DHCP, puis serveur d'images, serveur de configuration et état opérationnel
NETCONF et ZTP : flux de provisionnement Day-0, du démarrage aux serveurs d'images et de configuration jusqu'à l'état opérationnel.

Pourquoi la configuration model-driven compte

Les scripts CLI ne se composent pas, ne se révoquent pas et ne valident pas les entrées par rapport à un schéma. NETCONF + YANG vous offre une surface de configuration typée et transactionnelle : poussez une configuration candidate, validez, committez, ou effectuez un rollback si une leaf est rejetée. OcNOS expose à la fois des modèles OpenConfig (BGP, interfaces, network-instance, platform) et des modèles IETF (ietf-interfaces, ietf-routing, ietf-system), ainsi que des modèles natifs IP Infusion pour les réglages propres à OcNOS. Combiné au Zero-Touch Provisioning, le workflow d'exploitation devient : monter en rack un équipement, brancher le management, et s'en aller.

L'implémentation NETCONF, YANG et ZTP d'OcNOS

NETCONF

Transport SSH + TLS

Protocole NETCONF RFC 6241, sur SSH (RFC 6242) et TLS (RFC 7589), avec support complet des RPC Get / Get-Config / Edit-Config / Commit / Validate / Lock / Discard-Changes.

Modèles YANG

OpenConfig + IETF + natif

OpenConfig BGP, interfaces, network-instance, platform, telemetry ; IETF system, interfaces, routing ; modèles natifs IP Infusion pour les fonctionnalités uniques.

Datastores

candidate + commit / rollback

Datastore candidate complet avec confirmed commit (RFC 6241), rollback explicite vers les N commits antérieurs et consultation de l'historique de configuration.

ZTP

Provisionnement Day-0

Démarrage piloté par les options DHCP 67 / 239 : récupération de l'image, vérification de signature, installation, redémarrage ; puis récupération du bundle de configuration et validation. Reprise idempotente en cas d'échec partiel.

Ansible / Salt

Modules de référence

Collection Ansible Galaxy et formules Salt pour OcNOS NETCONF : plays BGP, interface et EVPN idempotents et prêts à l'emploi.

gNMI

Coexistence avec NETCONF

Le Set gNMI et l'Edit-Config NETCONF ciblent le même magasin de modèles. Choisissez le protocole qui correspond à votre outillage, l'équipement se comporte de la même manière.

Ce que vous obtenez avec l'automatisation OcNOS

  • Une seule surface de configuration, deux protocoles. NETCONF et gNMI ciblent tous deux le même datastore modélisé en YANG, sans écart de fonctionnalité propre à un protocole.
  • ZTP vérifié. La récupération de l'image Day-0 est vérifiée par signature ; l'intégrité du bundle de configuration est contrôlée avant le commit. Aucune intervention sur site, en toute confiance.
  • Outillage ouvert. Collection Ansible de référence, formules Salt et exemples de client Python publiés, sans verrouillage par un SDK propriétaire.
  • Retour arrière opérationnel. Chaque commit est suivi. Revenez à n'importe quel état antérieur avec un seul RPC si un changement tourne mal.

Vous mettez en place une pile d'exploitation pilotée par modèle ?

Demander une démo technique →
FAQ

Questions fréquentes

Quels modèles YANG OcNOS prend-il en charge via NETCONF ?
OcNOS expose les modèles OpenConfig (BGP, interfaces, network-instance, platform, telemetry), les modèles IETF (ietf-system, ietf-interfaces, ietf-routing) et les modèles natifs IP Infusion pour les fonctionnalités propres à OcNOS.
OcNOS prend-il en charge le rollback de configuration ?
Oui. OcNOS fournit un datastore candidate complet avec confirmed commit (RFC 6241), un rollback explicite vers les commits antérieurs et la consultation de l'historique de configuration, de sorte qu'une modification rejetée peut être annulée au moyen d'un seul RPC.
Comment fonctionne le Zero-Touch Provisioning dans OcNOS ?
Un routeur sortant d'usine démarre, demande un bail DHCP (option 67/239), récupère son image et en vérifie la signature, puis télécharge et applique par commit son bundle de configuration rendu en YANG, atteignant l'état opérationnel sans opérateur sur site. Les défaillances partielles sont relancées de façon idempotente.
Puis-je utiliser à la fois NETCONF et gNMI sur OcNOS ?
Oui. NETCONF Edit-Config et gNMI Set ciblent le même datastore modélisé en YANG ; vous pouvez donc choisir le protocole adapté à votre outillage, et l'équipement se comporte de la même manière.
OcNOS fonctionne-t-il avec Ansible et Salt ?
Oui. IP Infusion publie une collection Ansible Galaxy de référence et des formules Salt pour OcNOS NETCONF, avec des role plays BGP, d'interface et EVPN idempotents et sans lock-in propriétaire de SDK.