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

Automatisation &
Programmability

Vos outils NetDevOps existants fonctionnent dès le premier jour. OcNOS expose chaque élément de configuration et chaque état opérationnel via des interfaces standard et ouvertes, sans screen-scraping et sans orchestrateurs propriétaires.

Les équipes réseau passent d'opérations centrées sur la CLI à une automatisation programmable, 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 et OpenConfig : les mêmes interfaces standard, pilotées par modèle, qu'exposent Cisco IOS-XR et Juniper Junos. La différence, c'est la plateforme : matériel ouvert, logiciel ouvert, et une fraction du coût.
Note d'application

Les playbooks qu'utilisent les ingénieurs.

Un guide éprouvé sur le terrain pour intégrer Ansible à OcNOS : modules, modèles d'inventaire et structure du playbook Day-0/1/2.

Le problème que résout l'automatisation OcNOS

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.

Avant
→

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.

Après OcNOS
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, et 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 configured
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, et le datastore candidate. Compatible avec le ncclient library, Ansible's netconf_config module, ou tout client NETCONF.

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 · Dial-in + Dial-out · On-Change + Periodic · TLS

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, puis visualisez dans 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

Provisionnement zéro contact

DHCP + TFTP/HTTP · automatisation Day 0

Montez-le en rack. Câblez-le. Mettez-le sous tension. Le ZTP s'occupe de tout le reste. Le DHCP attribue une adresse et pointe vers un serveur de provisioning. Le switch télécharge son image OS et sa config de démarrage via TFTP ou HTTP, l'applique et rejoint le réseau, sans câble console et sans ingénieur sur site. Combinez le 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.

IP Maestro EMS

Interface web · API REST · gestion d'éléments OcNOS

Pour les équipes qui souhaitent une interface graphique en complément de l'automatisation par API. IP Maestro est un système de gestion d'éléments (EMS) à interface graphique pour OcNOS : une carte de topologie interactive, l'inventaire et les détails des équipements, la surveillance des pannes et des performances, la gestion de la configuration et des logiciels, et la visualisation de la télémétrie en continu. Il communique en NETCONF avec les équipements OcNOS et expose une API REST nord afin qu'un contrôleur de niveau supérieur ou un OSS puisse s'y intégrer.

Découvrir IP Maestro

Conteneurs sur switch

OcNOS 7.0 · Runtime de conteneurs (K3S) · conteneur unique

OcNOS 7.0 intègre un runtime de conteneurs sur switch (K3S) avec gestion du cycle de vie d'un conteneur unique. Exécutez un agent Telegraf, un proxy Zabbix, un script Python ou Go personnalisé, ou un outil de sécurité directement sur le switch, aux côtés du NOS, sans matériel de calcul externe. SSH, SCP, SFTP et FTP standard déplacent images et configurations.

Aussi : OcNOS expose des standards SNMP MIBs, de sorte qu'il peut être surveillé avec les modèles SNMP génériques de Zabbix, en gardant l'outillage NOC hérité basé sur SNMP opérationnel aux côtés de gNMI.

Opérations cloud native

Piloté par modèle, transactionnel et résilient par conception

Le modèle opérationnel que les ingénieurs attendent d'un NOS moderne : état structuré, changements sécurisés avec rollback, visibilité en streaming, et résilience du plan de contrôle. Interfaces standard, matériel ouvert.

Configuration pilotée par modèle

OpenConfig + IPI-native YANG · NETCONF 1.1

La configuration et l'état opérationnel sont des données structurées, et non du texte issu du screen scraping. Modifiez le datastore candidat, puis validez de façon atomique ou effectuez un rollback, le même workflow piloté par modèle qu'utilisent Cisco IOS-XR et Juniper Junos, via NETCONF 1.1 standard avec les modèles OpenConfig et IPI-native YANG.

Télémétrie en streaming, dans les deux sens

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

gNMI Subscribe (dial-in) et Publish (dial-out via grpctunnel), en modes on-change et periodic, sécurisés par TLS et authentifiés par utilisateur. Fonctionne en bande (in-band) sur un ou plusieurs VRF, sur des modèles OpenConfig. État structuré de type push pour Telegraf, Prometheus et Grafana, à la place du polling SNMP.

Résilience du plan de contrôle

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

Graceful Restart avec Non-Stop Forwarding maintient le transfert du plan de données pendant le redémarrage du plan de contrôle, pour BGP, OSPF, OSPFv3 et IS-IS. Les redémarrages de processus et la maintenance planifiée n'interrompent pas le trafic de transit.

Programmabilité sur switch

Runtime de conteneurs (K3S) · ZTP · SSH/SCP/SFTP

Exécutez un agent ou un outil dans un conteneur directement sur le switch, via le runtime intégré (K3S, cycle de vie d'un conteneur unique), afin qu'un collecteur, un script ou une sonde s'exécute aux côtés du NOS, sans calcul externe. ZTP démarre le nouveau matériel de façon autonome (hands-free), et SSH, SCP, SFTP et FTP déplacent images et configurations.

gNMI Streaming, pas de polling
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 est mis sous tension. Le DHCP attribue une adresse IP. Le ZTP télécharge l'image OcNOS et la configuration de base via TFTP/HTTP. L'équipement démarre prêt à être administré. Aucun câble console. Aucun ingénieur sur site. L'ensemble du rack est provisionné pendant que votre équipe dort.

ZTP DHCP OcNOS
Day 1 : Configuration

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

Les playbooks Ansible poussent les configurations BGP, MPLS, EVPN-VXLAN, QoS, ACL et de synchronisation sur l'ensemble du parc. NETCONF/YANG garantit des poussées structurées et validées, avec rollback en cas d'échec. IP Maestro, l'EMS à interface graphique pour OcNOS, ajoute la diffusion de configuration et la planification via une interface graphique.

Ansible NETCONF/YANG OpenConfig IP Maestro
Day 2 : Exploitation

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

gNMI diffuse la télémétrie vers Telegraf → Prometheus → Grafana. Ansible assure la détection des dérives de configuration, les sauvegardes planifiées et les mises à jour logicielles. Un conteneur sur switch exécute des outils personnalisés. IP Maestro fournit la topologie, la surveillance des pannes, ainsi que les mises à jour planifiées de configuration et de logiciel.

gNMI Telegraf Grafana Conteneurs 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.

Ansible

Collection Galaxy officielle : ipinfusion.ocnos

Gestion de configuration

Telegraf

Plugin d'entrée gNMI, souscription directe

Collecteur de télémétrie

Prometheus

Exporteur gNMI, métriques de série temporelle

Stockage de métriques

Grafana

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

Visualisation

Zabbix

MIB SNMP standards, compatible avec les templates SNMP Zabbix

Monitoring SNMP

ncclient

Bibliothèque Python standard, NETCONF 1.1 complet

Python NETCONF

gnmic

subscribe, get, set : tests en ligne de commande

Client CLI gNMI

Runtime K3S

Runtime pour conteneur unique, natif dans OcNOS 7.0

Calcul sur switch
Questions fréquentes

Automatisation OcNOS, en clair

Questions posées par les ingénieurs réseau avant le déploiement.

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 sur le datastore candidat. La même approche pilotée par les modèles qu'utilisent Cisco IOS-XR et Juniper Junos. La bibliothèque ncclient de Python fonctionne 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 en streaming gNMI, avec les modes d'abonnement on-change et periodic, en styles dial-in et dial-out (grpctunnel), sécurisés par TLS et une authentification par utilisateur. Connectez-vous directement à Telegraf (plugin d'entrée gNMI), à Prometheus (exportateur gNMI) ou à tout collecteur compatible gRPC, puis visualisez les données dans Grafana. Les chemins de capteurs couvrent les interfaces, l'état BGP, les labels MPLS, les files QoS, les compteurs PFC et l'état de santé du système, remplaçant le polling SNMP par des données structurées, de type push.
Qu'est-ce que le Zero Touch Provisioning (ZTP) dans OcNOS ?
Le ZTP automatise entièrement la configuration des équipements au Day 0. Lorsqu'un nouveau switch est mis sous tension, il utilise DHCP pour localiser un serveur de provisioning, puis télécharge la bonne image OcNOS et la configuration de démarrage via TFTP ou HTTP, sans câble console ni ingénieur sur site. Combiné à Ansible, le ZTP couvre l'ensemble du cycle de vie Day 0 à Day 2 : le ZTP gère le démarrage initial et la livraison de l'image, Ansible gère la gestion continue de la configuration, et gNMI gère la supervision opérationnelle.
Puis-je exécuter des conteneurs directement sur OcNOS ?
OcNOS 7.0 intègre un runtime de conteneurs sur switch (K3S) pour la gestion du cycle de vie d'un conteneur unique. Exécutez un agent de supervision tiers tel que Telegraf ou un proxy Zabbix, un outil de sécurité, ou un script Python ou Go personnalisé, directement sur le switch, aux côtés du NOS, sans calcul externe. SSH, SCP, SFTP et FTP standard assurent le transfert des images et des configurations.
OcNOS est-il cloud native ?
OcNOS est un NOS piloté par modèle et API-first, conçu pour des opérations automatisées sur du matériel ouvert. La configuration et l'état opérationnel sont des données structurées via OpenConfig et IPI-native YANG sur NETCONF 1.1, avec un datastore candidat, un commit atomique et un rollback, plutôt qu'une CLI de type screen scraping. La télémétrie est diffusée en streaming via gNMI (dial-in et dial-out, on-change et periodic, sécurisé par TLS, VRF simple ou multiple), à la place du polling SNMP. Graceful Restart avec Non-Stop Forwarding maintient le transfert du plan de données pendant les redémarrages du plan de contrôle, et un runtime de conteneurs intégré héberge des agents sur le switch. Chaque interface est standard, si bien que le même pipeline NetDevOps qui gère Cisco ou Arista gère OcNOS, sur du matériel whitebox Broadcom, à moindre coût.
OcNOS fonctionne-t-il avec Zabbix pour le monitoring SNMP ?
Oui. OcNOS expose des MIB SNMP standard, il peut donc être supervisé avec Zabbix à l'aide des modèles génériques de périphériques SNMP de Zabbix. Pour les équipes utilisant encore un outillage NOC basé sur SNMP, OcNOS fait tourner SNMP en parallèle de gNMI. Vous pouvez exploiter les deux en parallèle durant une migration vers la télémétrie en streaming.
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 et Ansible, que Arista EOS et Cisco NX-OS. La différence réside dans la plateforme : OcNOS fonctionne sur du matériel ouvert validé provenant d'Edgecore, d'UfiSpace et d'autres fournisseurs de whiteboxes, à un coût total nettement 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émonstration en direct avec notre équipe d'ingénierie. Apportez vos exigences d'automatisation, et nous vous montrerons précisément comment OcNOS s'intègre à votre pipeline.