Simple Network Management Protocol (SNMP) was designed in 1988 for networks that carried kilobits of traffic per second. It works by polling — a management system asks a device for its current state, the device responds, and the cycle repeats every 60–300 seconds. For the networks SNMP was designed for, this was adequate.
For a modern AI data center where a single link can move 800 gigabits per second, or a service provider network carrying real-time 5G traffic, SNMP polling is not just inadequate — it actively masks the network behavior that operators need to observe.
The Fundamental Problem with Polling
SNMP polling (5-minute interval) completely misses a 30-second congestion event that occurs between polls. gNMI on-change streaming detects the event within milliseconds and pushes data to the collector immediately — enabling automated remediation before the event becomes a service impacting issue.
Why SNMP Fails in AI and High-Speed Networks
Polling granularity — even aggressive 1-minute SNMP polling misses events that last seconds. Queue fills and drains in under 100ms in 800G fabrics.
CPU overhead — each SNMP poll request consumes CPU cycles on the network device. At scale, polling hundreds of interfaces creates a predictable CPU spike every cycle.
No event semantics — SNMP tells you the state at polling time. It does not tell you what changed, when it changed, or what caused it.
Counter wrap — 32-bit SNMP counters wrap in under 7 seconds on a 400G interface. Most SNMP implementations use 64-bit counters, but the wrapping behavior creates gaps in high-speed monitoring.
AI fabric specific — PFC pause frame storms, ECN marking events, and RoCEv2 retransmission bursts are transient and invisible to SNMP polling.
gNMI Streaming Telemetry: How It Works
gNMI (gRPC Network Management Interface) inverts the monitoring model. Instead of the management system asking the device for data, the device pushes data to the collector the moment it changes. Two subscription modes are available:
On-Change — data is pushed only when the value changes. A link going down triggers an immediate push. Ideal for state changes (interface status, BGP session state, route table changes).
Sample — data is pushed at a configured interval. Used for counters and metrics where absolute values at regular intervals are needed (queue depth, byte counters).
! OcNOS -- Using OpenConfig data models for vendor-neutral monitoring
!
! OpenConfig paths are standardized across vendors --
! the same collector config works with OcNOS, Arista, Juniper, etc.
!
telemetry
subscription OC-INTERFACES
protocol gNMI
encoding JSON_IETF
sensor-group OC-INTF
! OpenConfig interface model (vendor-neutral)
path openconfig:/interfaces/interface[name=*]/state
!
destination-group COLLECTOR-1
sample-interval 0
!
!
! Verify subscriptions are active:
show telemetry subscription
show telemetry sensor-group
!
! Check collector connectivity:
show telemetry destination
Migration Path: SNMP to gNMI
Step
Action
Notes
1
Deploy gNMI collector (Prometheus + gNMI Exporter, InfluxDB, or commercial)
Run in parallel with SNMP initially
2
Configure OcNOS gNMI subscriptions for key sensors
Configuration backups are one of those operational tasks that every network team acknowledges is critical but often lacks a clean, automated solution for. OcNOS does not have built-in scheduled backup functionality, but it integrates cleanly with Ansible — making it straightforward to build a robust backup workflow using tools most network teams already have.
This guide covers three approaches from simple to full production-grade:
As networks grow in size and complexity, manual configuration becomes the primary bottleneck for both new deployments and day-2 operations. A service provider managing hundreds of cell site routers cannot afford to configure each one individually. A data center operator managing dozens of leaf switches needs a repeatable, auditable way to push VXLAN fabric configurations. OcNOS supports multiple automation interfaces that integrate with the tools network teams already use.
OcNOS Automation Interfaces
Interface
Protocol
Best For
Data Model
NETCONF
SSH/XML
Ansible, Terraform, custom scripts
Native YANG + OpenConfig
gNMI
gRPC
Telemetry, config push, streaming
OpenConfig + native
CLI via SSH
SSH
Ansible raw module, Expect scripts
CLI text
REST API
HTTPS
IP Maestro integration, custom apps
JSON
Ansible + NETCONF: Configuration Deployment
# Ansible playbook: deploy IS-IS SR config to multiple OcNOS nodes
# inventory.yaml defines hosts with NETCONF connection
- name: Deploy IS-IS SR configuration
hosts: ocnos_sp_nodes
connection: netconf
gather_facts: false
vars:
isis_net_prefix: "49.0001"
srgb_start: 16000
srgb_end: 23999
tasks:
- name: Configure IS-IS SR on each node
netconf_config:
content: |
<config>
<routing xmlns="urn:ietf:params:xml:ns:yang:ietf-routing">
<control-plane-protocols>
<control-plane-protocol>
<type>isis</type>
<name>CORE</name>
<isis xmlns="urn:ietf:params:xml:ns:yang:ietf-isis">
<interfaces>
<interface>
<name>{{ ansible_host_loopback }}</name>
<passive>true</passive>
</interface>
</interfaces>
</isis>
</control-plane-protocol>
</control-plane-protocols>
</routing>
</config>
- name: Verify IS-IS neighbors via NETCONF get
netconf_get:
filter: |
<routing-state xmlns="urn:ietf:params:xml:ns:yang:ietf-routing">
<routing-instance>
<routing-protocols>
<routing-protocol>
<isis xmlns="urn:ietf:params:xml:ns:yang:ietf-isis">
<adjacencies/>
</isis>
</routing-protocol>
</routing-protocols>
</routing-instance>
</routing-state>
register: isis_state
- name: Assert all neighbors are UP
assert:
that: "'UP' in isis_state.output"
gNMI: Real-Time Config Push and State Retrieval
! gNMI CLI (gnmic tool) -- push configuration to OcNOS
!
# Install gnmic:
bash -c "$(curl -sL https://get-gnmic.openconfig.net)"
# Push interface description via gNMI Set:
gnmic -a 10.0.0.1:57400 -u admin -p admin --insecure set --update-path '/interfaces/interface[name=eth-0-1]/config/description' --update-value '"Uplink to Spine-1"'
# Get current BGP neighbor state:
gnmic -a 10.0.0.1:57400 -u admin -p admin --insecure get --path '/network-instances/network-instance[name=default]/protocols/protocol/bgp/neighbors/neighbor[neighbor-address=10.0.0.2]/state'
# Subscribe to interface state changes (on-change):
gnmic -a 10.0.0.1:57400 -u admin -p admin --insecure subscribe --path '/interfaces/interface/state/oper-status' --mode on-change
Zero-Touch Provisioning Pattern
! OcNOS -- ZTP hook: execute script on first boot
!
! OcNOS supports a ZTP boot script that runs when no startup config exists.
! The script can pull configuration from a DHCP/TFTP/HTTP server:
!
! 1. DHCP option 67 points to ZTP script URL
! 2. OcNOS downloads and executes the script on first boot
! 3. Script fetches device-specific config based on MAC/serial number
! 4. Config is applied via CLI or NETCONF
!
! Example ZTP script (Python, runs on OcNOS):
! import subprocess, urllib.request
! serial = subprocess.check_output(['show', 'version'], text=True)
! config_url = f"http://ztp-server/configs/{serial.strip()}.cfg"
! urllib.request.urlretrieve(config_url, '/tmp/startup.cfg')
! subprocess.run(['copy', '/tmp/startup.cfg', 'running-config'])