Startseite/ Produkte/ Automatisierung & Programmierbarkeit
OcNOS 7.0 · Ansible · NETCONF/YANG · gNMI · ZTP · Containers

Automatisierung &
Programmability

Ihre bestehenden NetDevOps-Tools funktionieren ab dem ersten Tag. OcNOS stellt jeden Konfigurations- und Betriebszustand über standardisierte, offene Schnittstellen bereit, ohne Screen-Scraping und ohne proprietäre Orchestratoren.

Demo vereinbaren OcNOS kostenlos testen → Dokumentation lesen →
Netzwerkteams wechseln von CLI-first-Betrieb zu programmierbarer, API-gesteuerter Automatisierung. OcNOS ist für diesen Übergang konzipiert. Jeder Protokollstatus, jedes Konfigurationselement und jede Betriebskennzahl ist über Ansible, NETCONF/YANG, gNMI und OpenConfig zugänglich: dieselben standardisierten, modellgetriebenen Schnittstellen, die Cisco IOS-XR und Juniper Junos bieten. Der Unterschied liegt in der Plattform: offene Hardware, offene Software und ein Bruchteil der Kosten.
Application Note

Die Playbooks, die Engineers verwenden.

Eine praxiserprobte Anleitung zur Integration von Ansible mit OcNOS: Module, Inventory-Muster und die Day-0/1/2-Playbook-Struktur.

Anwendungshinweis

Automatisierung des Netzwerkmanagements: Ansible mit OcNOS integrieren

Offizielle IP Infusion Ansible Collection: Module, Inventory-Patterns und Playbook-Beispiele für BGP, EVPN-VXLAN und OcNOS-spezifische Operationen.

Application Note erhalten
Das Problem, das die OcNOS-Automatisierung löst
Vorher

Manuelle CLI-Vorgänge

Konfiguration per SSH Gerät für Gerät ausgerollt. SNMP-Polling im 5-Minuten-Intervall. Engineers vor Ort für Racking und Verkabelung neuer Hardware. Kein strukturierter State, kein Rollback.

→
Nach OcNOS

Vollständig programmierbar, von Day 0 bis Day N

Ansible rollt BGP und EVPN-VXLAN in Minuten auf 100 Switches aus. gNMI streamt Telemetrie mit Sub-Sekunden-Updates. ZTP bootet neue Hardware ohne menschlichen Eingriff. Rollback in Sekunden.

Programmierbare Schnittstellen

Sechs Wege, OcNOS zu automatisieren

Wählen Sie eine Option oder nutzen Sie alle sechs gemeinsam. OcNOS erzwingt keinen proprietären Orchestrator – es funktioniert mit den Tools, die Ihr Team bereits einsetzt.

Ansible Collection

ansible-galaxy collection install ipinfusion.ocnos

Offizielle IP Infusion Collection auf Ansible Galaxy. Enthaltene Module: ocnos_facts, ocnos_config, ocnos_command, ocnos_bgp_facts, und ocnos_isis_facts. Jinja2-Templating für dynamisches, flottenweites Provisioning. Verwenden Sie dieselben Ansible-Playbooks, die Sie bereits schreiben – OcNOS spricht dieselbe Sprache wie Arista, Juniper und 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 Fehler · 0:42 verstrichen
Ansible-Guide in der OcNOS-Dokumentation

NETCONF / YANG 1.1

IPI-native + OpenConfig-Modelle · RFC 6241

Vollständiges NETCONF 1.1 mit IPI-nativen und OpenConfig YANG-Datenmodellen. Strukturierte Abfrage von Konfiguration und Betriebszustand: get, edit-config, commit, rollback, und Candidate-Datastore. Funktioniert mit Pythons ncclient library, Ansible's netconf_config Modul oder einem beliebigen NETCONF-Client.

netconf: edit-config + commit
<edit-config>
<target><candidate/></target>
<config>...YANG-Payload...</config>
</edit-config>
<ok/> ← Kandidat gesperrt
<commit/> ← applied atomically

gNMI-Streaming-Telemetrie

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

Echtzeit-Push-basierte Telemetrie via gNMI über gRPC. Ersetzt SNMP-Polling durch strukturierte Sub-Sekunden-Updates für Interfaces, BGP-Session-Status, MPLS-Forwarding, QoS-Queues, PFC/ECN-Counter und System-Health. Verbinden mit Telegraf, Prometheus oder einen beliebigen gRPC-Collector und visualisieren Sie anschließend 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 · Day-0-Automatisierung

Einbauen. Verkabeln. Einschalten. ZTP erledigt alles Weitere. DHCP weist eine Adresse zu und verweist auf einen Provisioning-Server. Der Switch lädt sein OS-Image und seine Startup-Config über TFTP oder HTTP herunter, wendet sie an und tritt dem Netzwerk bei, ohne Konsolenkabel und ohne Techniker vor Ort. Kombinieren Sie ZTP mit Ansible zu einer vollständigen Pipeline von Day 0 bis Day 2.

Praxis-Use-Case: Ein 48-Node-AI-GPU-Cluster-Spine-Leaf-Fabric, das übers Wochenende ohne Engineer vor Ort provisioniert wurde. ZTP bootet jeden Switch, Ansible verteilt die BGP- und PFC-Konfiguration, gNMI bestätigt das verlustfreie Fabric.

IP Maestro EMS

Web-UI · REST API · OcNOS-Element-Management

Für Teams, die eine GUI zusätzlich zur API-Automatisierung wünschen. IP Maestro ist ein GUI-basiertes Element-Management-System (EMS) für OcNOS: eine interaktive Topologiekarte, Inventar und Gerätedetails, Störungs- und Leistungsüberwachung, Konfigurations- und Softwareverwaltung sowie die Visualisierung von Streaming-Telemetrie. Es kommuniziert per NETCONF mit OcNOS-Geräten und stellt eine Northbound-REST-API bereit, sodass sich ein übergeordneter Controller oder OSS darin integrieren kann.

IP Maestro erkunden

On-Switch-Container

OcNOS 7.0 · Container-Runtime (K3S) · einzelner Container

OcNOS 7.0 enthält eine On-Switch-Container-Runtime (K3S) mit Lifecycle-Management für einen einzelnen Container. Führen Sie einen Telegraf-Agenten, einen Zabbix-Proxy, ein individuelles Python- oder Go-Skript oder ein Sicherheitstool direkt auf dem Switch aus, parallel zum NOS, ohne externe Compute-Hardware. Standard-SSH, SCP, SFTP und FTP übertragen Images und Konfigurationen.

Außerdem: OcNOS stellt standardisierte SNMP MIBs, sodass es sich mit den generischen SNMP-Templates von Zabbix überwachen lässt und Legacy-SNMP-basiertes NOC-Tooling parallel zu gNMI funktionsfähig bleibt.

Cloud-native Betriebsabläufe

Modellgetrieben, transaktional und resilient von Grund auf konzipiert

Das Betriebsmodell, das Engineers von einem modernen NOS erwarten: strukturierter Status, sichere Änderungen mit Rollback, Streaming-Transparenz und Control-Plane-Resilienz. Standardschnittstellen, offene Hardware.

Modellgetriebene Konfiguration

OpenConfig + IPI-native YANG · NETCONF 1.1

Konfiguration und Betriebsstatus sind strukturierte Daten, kein per Screen-Scraping erfasster Text. Bearbeiten Sie den Candidate-Datastore und committen Sie dann atomar oder führen Sie ein Rollback durch, derselbe modellgetriebene Workflow, den Cisco IOS-XR und Juniper Junos nutzen, über Standard-NETCONF 1.1 mit OpenConfig- und IPI-native-YANG-Modellen.

Streaming-Telemetrie in beide Richtungen

gNMI · Dial-in + Dial-out · TLS · Multi-VRF

gNMI Subscribe (Dial-in) und Publish (Dial-out über grpctunnel), in On-Change- und periodischen Modi, abgesichert mit TLS und pro Benutzer authentifiziert. Läuft in-band über eine einzelne oder mehrere VRFs auf OpenConfig-Modellen. Push-basierter, strukturierter Status für Telegraf, Prometheus und Grafana, anstelle von SNMP-Polling.

Control-Plane-Resilienz

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

Graceful Restart mit Non-Stop Forwarding sorgt dafür, dass die Data Plane weiterleitet, während die Control Plane neu startet, für BGP, OSPF, OSPFv3 und IS-IS. Prozessneustarts und geplante Wartungsarbeiten verwerfen keinen Transitverkehr.

On-Switch-Programmierbarkeit

Container-Runtime (K3S) · ZTP · SSH/SCP/SFTP

Führen Sie einen Agenten oder ein Tool in einem Container direkt auf dem Switch aus, über die integrierte Runtime (K3S, Lifecycle-Management für einen einzelnen Container), sodass ein Collector, ein Skript oder eine Probe parallel zum NOS läuft, ohne externe Compute-Ressourcen. ZTP bootet neue Hardware hands-free, und SSH, SCP, SFTP und FTP übertragen Images und Konfigurationen.

gNMI Streaming statt Polling
6 Automatisierungsschnittstellen
0 Proprietäre Orchestratoren erforderlich
600+ Produktivnetze
Day 0 Erster automatisierter Push
Vollständige Lifecycle-Abdeckung

Day 0 → Day 1 → Day 2

OcNOS deckt den gesamten Betriebs-Lifecycle mit offenen, standardisierten Tools ab. Keine proprietären Orchestratoren, kein CLI-Scripting, kein SNMP-Polling.

Day 0: Provisionierung

Die Hardware verbindet sich selbst mit dem Netzwerk

Der Switch wird eingeschaltet. DHCP weist eine IP zu. ZTP lädt das OcNOS-Image und die Basiskonfiguration über TFTP/HTTP herunter. Das Gerät startet betriebsbereit zur Verwaltung. Kein Konsolenkabel. Kein Techniker vor Ort. Das gesamte Rack wird provisioniert, während Ihr Team schläft.

ZTP DHCP OcNOS
Day 1: Konfiguration

Services in Minuten statt Tagen bereitgestellt

Ansible-Playbooks verteilen BGP-, MPLS-, EVPN-VXLAN-, QoS-, ACL- und Timing-Konfigurationen über die gesamte Flotte. NETCONF/YANG stellt strukturierte, validierte Übertragungen mit Rollback bei Fehlern sicher. IP Maestro, das GUI-basierte EMS für OcNOS, ergänzt GUI-basiertes Config-Push und Scheduling.

Ansible NETCONF/YANG OpenConfig IP Maestro
Day 2: Betrieb

Echtzeit-Visibility, automatisierte Remediation

gNMI streamt Telemetriedaten an Telegraf → Prometheus → Grafana. Ansible übernimmt die Erkennung von Konfigurationsabweichungen, geplante Backups und Software-Upgrades. Ein On-Switch-Container führt individuelle Tools aus. IP Maestro bietet Topologie, Fehlerüberwachung sowie geplante Konfigurations- und Software-Updates.

gNMI Telegraf Grafana Container Zabbix
Ökosystem

Funktioniert mit Ihrem bestehenden Stack

OcNOS spricht Standardprotokolle. Kein kompletter Austausch Ihrer Toolchain. die Tools, die Ihr Team bereits kennt, funktionieren ab Tag eins.

Konfigurationsmanagement

Ansible

Offizielle Galaxy-Collection: ipinfusion.ocnos

Telemetrie-Collector

Telegraf

gNMI-Input-Plugin, direkte Subscription

Metrik-Speicher

Prometheus

gNMI-Exporter, Time-Series-Metriken

Visualisierung

Grafana

Vorgefertigte Dashboards für OcNOS-Telemetrie

SNMP-Monitoring

Zabbix

Standard-SNMP-MIBs, funktioniert mit Zabbix-SNMP-Templates

Python NETCONF

ncclient

Standard-Python-Bibliothek, vollständiges NETCONF 1.1

gNMI CLI Client

gnmic

subscribe, get, set: Tests über die Kommandozeile

On-Switch-Compute

K3S-Runtime

Runtime für einen einzelnen Container, nativ in OcNOS 7.0

Häufige Fragen

OcNOS-Automatisierung, beantwortet

Fragen, die Netzwerktechniker vor dem Deployment stellen.

Unterstützt OcNOS Ansible?
Ja. IP Infusion veröffentlicht eine offizielle Ansible Collection auf Ansible Galaxy (ipinfusion.ocnos). Sie enthält Module für Facts-Erfassung, Befehlsausführung, Konfigurationsmanagement und protokollspezifische Operationen, darunter ocnos_facts, ocnos_config, ocnos_command, ocnos_ping, ocnos_bgp_facts und ocnos_isis_facts. Die Playbooks nutzen Jinja2-Templating für flottenweites, dynamisches Provisioning über Hunderte von OcNOS-Geräten hinweg.
Welche YANG-Modelle unterstützt OcNOS?
OcNOS unterstützt sowohl IPI-native YANG-Modelle als auch OpenConfig-Modelle über NETCONF 1.1. Dies ermöglicht eine strukturierte Konfiguration und den Abruf des Betriebszustands: get, edit-config, commit, rollback und Operationen auf dem Candidate-Datastore. Es ist derselbe modellgetriebene Ansatz, den auch Cisco IOS-XR und Juniper Junos verwenden. Die ncclient-Bibliothek von Python arbeitet direkt mit OcNOS NETCONF.
Kann ich OcNOS-Telemetrie an Grafana oder Prometheus streamen?
Ja. OcNOS 7.0 unterstützt gNMI-Streaming-Telemetrie sowohl im On-Change- als auch im periodischen Subscription-Modus, in Dial-in- und Dial-out-Varianten (grpctunnel), abgesichert mit TLS und benutzerbezogener Authentifizierung. Verbinden Sie sich direkt mit Telegraf (gNMI-Input-Plugin), Prometheus (gNMI-Exporter) oder jedem gRPC-kompatiblen Collector und visualisieren Sie die Daten in Grafana. Die Sensorpfade decken Interfaces, BGP-Status, MPLS-Labels, QoS-Warteschlangen, PFC-Zähler und Systemzustand ab und ersetzen SNMP-Polling durch push-basierte, strukturierte Daten.
Was ist Zero Touch Provisioning (ZTP) in OcNOS?
ZTP automatisiert die Day-0-Einrichtung von Geräten vollständig. Wenn ein neuer Switch eingeschaltet wird, nutzt er DHCP, um einen Provisioning-Server zu lokalisieren, und lädt anschließend das korrekte OcNOS-Image und die Startkonfiguration per TFTP oder HTTP herunter, ohne Konsolenkabel und ohne Ingenieur vor Ort. In Kombination mit Ansible deckt ZTP den gesamten Lebenszyklus von Day 0 bis Day 2 ab: ZTP übernimmt den initialen Boot und die Image-Bereitstellung, Ansible das laufende Konfigurationsmanagement und gNMI das operative Monitoring.
Kann ich Container direkt auf OcNOS ausführen?
OcNOS 7.0 enthält eine On-Switch-Container-Runtime (K3S) für das Lifecycle-Management eines einzelnen Containers. Führen Sie einen Monitoring-Agenten eines Drittanbieters wie Telegraf oder einen Zabbix-Proxy, ein Sicherheitstool oder ein individuelles Python- oder Go-Skript direkt auf dem Switch aus, parallel zum NOS, ohne externe Compute-Ressourcen. Standard-SSH, SCP, SFTP und FTP übernehmen die Übertragung von Images und Konfigurationen.
Ist OcNOS cloud-native?
OcNOS ist ein modellgetriebenes, API-first NOS für automatisierte Betriebsabläufe auf offener Hardware. Konfiguration und Betriebsstatus sind strukturierte Daten über OpenConfig und IPI-native YANG via NETCONF 1.1, mit einem Candidate-Datastore, atomarem Commit und Rollback, statt einer per Screen-Scraping ausgelesenen CLI. Telemetrie streamt über gNMI (Dial-in und Dial-out, On-Change und periodisch, TLS-gesichert, mit einzelner oder mehreren VRFs) anstelle von SNMP-Polling. Graceful Restart mit Non-Stop Forwarding hält die Data Plane während Control-Plane-Neustarts weiterleitend, und eine integrierte Container-Runtime hostet Agenten auf dem Switch. Jede Schnittstelle ist standardisiert, sodass dieselbe NetDevOps-Pipeline, die Cisco oder Arista verwaltet, auch OcNOS verwaltet, auf Broadcom-Whitebox-Hardware zu niedrigeren Kosten.
Funktioniert OcNOS mit Zabbix für SNMP-Monitoring?
Ja. OcNOS stellt standardmäßige SNMP-MIBs bereit, sodass es mit Zabbix über dessen generische SNMP-Device-Templates überwacht werden kann. Für Teams, die noch SNMP-basiertes NOC-Tooling nutzen, betreibt OcNOS SNMP parallel zu gNMI. Sie können beide während einer Migration zu Streaming-Telemetrie parallel betreiben.
Wie ist die OcNOS-Automatisierung im Vergleich zu Arista EOS oder Cisco NX-OS?
OcNOS stellt dieselben Standard-Schnittstellen bereit, NETCONF/YANG, gNMI, OpenConfig und Ansible, wie Arista EOS und Cisco NX-OS. Der Unterschied liegt in der Plattform: OcNOS läuft auf validierter offener Hardware von Edgecore, UfiSpace und anderen Whitebox-Anbietern, bei deutlich niedrigeren Gesamtkosten. Ihre bestehenden Ansible-Playbooks und Grafana-Dashboards lassen sich mit minimalen Anpassungen auf OcNOS migrieren.
Diese Produkte automatisieren

Eine Toolchain für Ihr gesamtes offenes Netzwerk

Jede auf dieser Seite gezeigte Automatisierungs-Schnittstelle funktioniert mit OcNOS-SP, OcNOS-DC und IP Maestro – eine konsistente Pipeline über Ihren gesamten Bestand.

Service-Provider-NOS

OcNOS-SP

Automatisieren Sie SR-MPLS-, BGP- und Mobile-Backhaul-Deployments mit Ansible. Streamen Sie IEEE 1588v2-Timing-Status und MPLS-Forwarding-Metriken via gNMI. ZTP für Cell-Site-Gateway-Rollouts.

OcNOS-SP-Produktseite → Data Center NOS

OcNOS-DC

Rollen Sie ein EVPN-VXLAN-Leaf-Spine-Fabric mit Ansible in unter einer Stunde aus. Streamen Sie PFC- und ECN-Counter via gNMI für AI-Fabric-Visibility. ZTP für das Onboarding von GPU-Cluster-Racks im großen Maßstab.

OcNOS-DC-Produktseite → OcNOS EMS

IP Maestro

Das GUI-Element-Management-System (EMS) für OcNOS. Topologievisualisierung, Störungs- und Leistungsüberwachung, Telemetriediagramme, Konfigurationsübertragung und -planung sowie Software-Image-Updates, mit einer Northbound-REST-API.

IP Maestro Produktseite →
Starten Sie noch heute

OcNOS-Automatisierung in Aktion erleben

Vereinbaren Sie eine Live-Demo mit unserem Engineering-Team. Bringen Sie Ihre Automatisierungsanforderungen mit, und wir zeigen Ihnen genau, wie sich OcNOS in Ihre Pipeline integriert.

Technische Demo buchen OcNOS kostenlos testen → Dokumentation lesen →