OcNOS 7.0 · Ansible · NETCONF/YANG · gNMI · ZTP · Docker

Automatisation &
Programmability

OcNOS expose toutes les configurations et tous les états opérationnels via des interfaces standard et ouvertes. Pas de screen-scraping, pas d'orchestrateurs propriétaires. Vos outils NetDevOps existants fonctionnent dès le premier jour.

Les équipes réseau passent d'opérations centrées sur le CLI à une automatisation programmable et pilotée par API. OcNOS est conçu pour cette transition. Chaque état de protocole, élément de configuration et métrique opérationnelle est accessible via Ansible, NETCONF/YANG, gNMI, REST et Docker — les mêmes interfaces standard qu'exposent Cisco IOS-XR et Juniper Junos. La différence se situe au niveau de la plateforme : matériel ouvert, logiciel ouvert, et une fraction du coût.
Le problème que résout l'automatisation OcNOS
Avant

Opérations CLI manuelles

Configuration poussée équipement par équipement via SSH. Polling SNMP toutes les 5 minutes. Ingénieurs sur site pour racker et câbler le nouveau matériel. Aucun état structuré, aucun rollback.

Après OcNOS

Entièrement programmable, du Day 0 au Day N

Ansible déploie BGP et EVPN-VXLAN sur 100 commutateurs en quelques minutes. gNMI streame la télémétrie en sous-seconde. ZTP démarre le nouveau matériel sans intervention humaine. Rollback en quelques secondes.

Interfaces programmables

Six façons d'automatiser OcNOS

Choisissez-en un ou utilisez les six ensemble. OcNOS n'impose aucun orchestrateur propriétaire — il fonctionne avec les outils que votre équipe utilise déjà.

Collection Ansible

ansible-galaxy collection install ipinfusion.ocnos

Collection officielle IP Infusion sur Ansible Galaxy. Modules inclus : ocnos_facts, ocnos_config, ocnos_command, ocnos_bgp_facts, and ocnos_isis_facts. Templating Jinja2 pour un provisioning dynamique à l'échelle du parc. Utilisez les mêmes playbooks Ansible que vous écrivez déjà — OcNOS parle la même langue qu'Arista, Juniper et Cisco.

ansible-playbook deploy-sr-mpls.yml
$ansible-playbook -i inventory deploy-sr-mpls.yml
ok : [spine-01] — IS-IS + SR-MPLS configuré
ok : [leaf-01..04] — BGP-LU overlay up
ok: [all] — config backup saved
PLAY RECAP · 5 switches · 0 erreurs · 0:42 écoulés
Guide Ansible dans la doc OcNOS

NETCONF / YANG 1.1

Modèles natifs IPI + OpenConfig · RFC 6241

NETCONF 1.1 complet avec modèles YANG IPI-native et OpenConfig. Récupération structurée de configuration et d'état opérationnel — 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>...payload YANG...</config>
</edit-config>
<ok/> ← candidat verrouillé
<commit/> ← applied atomically

Télémétrie gNMI en streaming

OcNOS 7.0 · On-Change + Périodique · 100+ chemins de capteurs

Télémétrie temps réel push-based via gNMI sur gRPC. Remplace le polling SNMP par des mises à jour structurées sub-seconde des interfaces, de l'état des sessions BGP, du forwarding MPLS, des files QoS, des compteurs PFC/ECN et de la santé système. Connectez à Telegraf, Prometheus ou tout collecteur gRPC — visualisé dans 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

Provisionnement zéro contact

DHCP + TFTP/HTTP · automatisation Day 0

Posez-le en rack. Câblez-le. Mettez-le sous tension. ZTP s'occupe du reste. DHCP attribue une adresse et désigne un serveur de provisioning. Le switch télécharge son image OS et sa configuration de démarrage via TFTP ou HTTP, les applique et rejoint le réseau — sans câble console, sans intervention sur site. Combinez ZTP avec Ansible pour un pipeline complet du Day 0 au Day 2.

Cas d'usage réel : Un fabric leaf-spine de cluster IA GPU à 48 nœuds provisionné sur un week-end sans aucun ingénieur sur site. ZTP boot chaque switch, Ansible déploie la configuration BGP + PFC, gNMI confirme le fabric lossless.

Orchestration GUI IP Maestro

UI Web · API REST · Gestion OcNOS unifiée

Pour les équipes qui souhaitent un contrôle visuel aux côtés de l'automatisation par API. IP Maestro fournit une carte de topologie interactive de l'ensemble de votre parc OcNOS, des tableaux de bord ZTP pilotés par interface graphique, la gestion du cycle de vie logiciel (mise à niveau, planification, rollback), la visualisation de la télémétrie en streaming et des modèles de configuration. Il expose également une API REST pour l'intégration avec les pipelines OSS/BSS et CI/CD.

Découvrir IP Maestro

Docker & conteneurs sur switch

OcNOS 7.0 · Docker · Kubernetes

OcNOS 7.0 héberge nativement des conteneurs Docker directement sur le commutateur. Exécutez des agents Telegraf, des proxies Zabbix, des scripts de monitoring Python personnalisés ou des outils de sécurité aux côtés du NOS — sans matériel de compute externe. Kubernetes (K8s) est également pris en charge pour l'orchestration du cycle de vie des conteneurs sur l'ensemble du parc.

Aussi : 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+ Chemins de capteurs gNMI
6 Interfaces d'automatisation
0 Orchestrateurs propriétaires requis
600+ Réseaux en production
Jour 0 Premier push automatisé
Couverture complète du cycle de vie

Day 0 → Day 1 → Day 2

OcNOS couvre l'ensemble du cycle de vie opérationnel avec des outils ouverts et standard. Pas d'orchestrateurs propriétaires, pas de scripting CLI, pas de polling SNMP.

Day 0 — Provisionnement

Le matériel rejoint le réseau de lui-même

Le commutateur s'allume, le DHCP attribue une IP, le ZTP télécharge l'image OcNOS et la configuration de base via TFTP/HTTP, l'équipement s'enregistre dans IP Maestro. Pas de câble console, pas d'ingénieur sur site — tout le rack est provisionné pendant que votre équipe dort.

ZTP DHCP IP Maestro
Day 1 — Configuration

Services déployés en minutes, pas en jours

Les playbooks Ansible déploient BGP, MPLS, EVPN-VXLAN, QoS, ACLs et la configuration de timing sur l'ensemble du parc. NETCONF/YANG garantit des push structurés et validés, avec rollback en cas d'échec. Modèles IP Maestro pour un déploiement intent-based.

Ansible NETCONF/YANG OpenConfig IP Maestro
Day 2 — Exploitation

Visibilité en temps réel, remédiation automatique

gNMI diffuse une télémétrie infraseconde vers Telegraf → Prometheus → Grafana. Ansible gère la détection de dérive de configuration, les sauvegardes planifiées et les mises à niveau logicielles. Docker exécute des outils personnalisés on-switch. IP Maestro fournit les alertes de topologie et la planification du cycle de vie.

gNMI Telegraf Grafana Docker Zabbix
Écosystème

Compatible avec votre stack existante

OcNOS parle des protocoles standard. Aucun changement complet de votre chaîne d'outillage — les outils que votre équipe maîtrise déjà fonctionnent dès le premier jour.

Gestion de configuration

Ansible

Collection Galaxy officielle — ipinfusion.ocnos

Collecteur de télémétrie

Telegraf

Plugin d'entrée gNMI, souscription directe

Stockage de métriques

Prometheus

Exporteur gNMI, métriques de série temporelle

Visualisation

Grafana

Tableaux de bord prêts pour la télémétrie OcNOS

Monitoring SNMP

Zabbix

Standard SNMP MIBs — works with Zabbix SNMP templates

Python NETCONF

ncclient

Bibliothèque Python standard, NETCONF 1.1 complet

Client CLI gNMI

gnmic

subscribe, get, set — tests en ligne de commande

Calcul sur switch

Docker / K8s

Runtime de conteneurs natif dans OcNOS 7.0

Questions fréquentes

Automatisation OcNOS, en clair

Questions que les ingénieurs réseau posent avant de déployer.

OcNOS prend-il en charge Ansible ?
Oui. IP Infusion publie une Collection Ansible officielle sur Ansible Galaxy (ipinfusion.ocnos). Elle inclut des modules pour la collecte de facts, l'exécution de commandes, la gestion de configuration et les opérations spécifiques aux protocoles, dont ocnos_facts, ocnos_config, ocnos_command, ocnos_ping, ocnos_bgp_facts et ocnos_isis_facts. Les playbooks utilisent le templating Jinja2 pour un provisioning dynamique à l'échelle d'un parc de centaines d'équipements OcNOS.
Quels modèles YANG OcNOS prend-il en charge ?
OcNOS prend en charge à la fois les modèles YANG natifs IPI et les modèles OpenConfig sur NETCONF 1.1. Cela permet une configuration structurée et la récupération de l'état opérationnel — opérations get, edit-config, commit, rollback et candidate datastore. La même approche model-driven que celle utilisée par Cisco IOS-XR et Juniper Junos. La bibliothèque Python ncclient s'interface directement avec NETCONF d'OcNOS.
Puis-je streamer la télémétrie OcNOS vers Grafana ou Prometheus ?
Oui. OcNOS 7.0 prend en charge la télémétrie streaming gNMI avec des modes de souscription on-change et périodique. Connectez-vous directement à Telegraf (plugin d'entrée gNMI), Prometheus (exporteur gNMI) ou tout collecteur compatible gRPC, et visualisez dans Grafana. Plus de 100 sensor paths sont disponibles, couvrant les interfaces, l'état BGP, les labels MPLS, les files QoS, les compteurs PFC et la santé du système — remplaçant le polling SNMP par des données structurées push.
Qu'est-ce que le Zero Touch Provisioning (ZTP) dans OcNOS ?
Le ZTP automatise entièrement la mise en service Day 0 d'un équipement. À la mise sous tension d'un nouveau switch, il utilise DHCP pour localiser un serveur de provisioning, puis télécharge l'image OcNOS correcte et la configuration de démarrage via TFTP ou HTTP — sans câble console, sans intervention sur site. Combiné à Ansible, le ZTP couvre l'intégralité du cycle Day 0 à Day 2 : le ZTP gère le boot initial et la livraison de l'image, Ansible la gestion de configuration en continu, et gNMI le monitoring opérationnel.
Puis-je exécuter des conteneurs Docker directement sur OcNOS ?
OcNOS 7.0 prend nativement en charge les conteneurs Docker on-switch. Les opérateurs peuvent ainsi exécuter des agents de monitoring tiers (Telegraf, Zabbix), des outils de sécurité ou des scripts Python/Go personnalisés directement aux côtés du NOS — sans calcul externe. Kubernetes (K8s) est également pris en charge pour la gestion du cycle de vie des conteneurs sur l'ensemble d'un parc de switches OcNOS.
OcNOS fonctionne-t-il avec Zabbix pour le monitoring 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.
Comment l'automatisation OcNOS se compare-t-elle à Arista EOS ou Cisco NX-OS ?
OcNOS expose les mêmes interfaces standard — NETCONF/YANG, gNMI, OpenConfig, Ansible — qu'Arista EOS et Cisco NX-OS. La différence se situe au niveau de la plateforme : OcNOS fonctionne sur du matériel ouvert validé d'Edgecore, UfiSpace et d'autres fournisseurs whitebox, à un coût total significativement inférieur. Vos playbooks Ansible et tableaux de bord Grafana existants peuvent migrer vers OcNOS avec un minimum de modifications.
Commencez aujourd'hui

Voir l'automatisation OcNOS en action

Réservez une démo en direct avec notre équipe d'ingénierie. Apportez vos exigences d'automatisation — nous vous montrerons précisément comment OcNOS s'intègre à votre pipeline.