Migrating telemetry paths from vendor native to OpenConfig

Introduction to OpenConfig and Verification‑Gated Migration

Overview of OpenConfig Benefits

OpenConfig provides vendor‑neutral YANG data models that enable consistent telemetry, configuration, and operational data retrieval across heterogeneous equipment. By adopting OpenConfig subscriptions, operators gain:

• Model‑driven consistency – identical YANG path yields the same semantic meaning on Juniper, Cisco, Arista, Nokia, etc.
• Reduced vendor lock‑in – automation scripts, dashboards, and alerting can be written once and reused.
• Future‑proof telemetry – as vendors add new OpenConfig‑compliant capabilities, existing subscriptions continue to work without re‑instrumentation.
• Standardized encoding – support for gNMI/gNOI with JSON or protobuf payloads simplifies parsing pipelines.

Challenges in Migrating from Vendor‑Specific Paths

Migrating from legacy, vendor‑specific telemetry paths to OpenConfig introduces several execution risks:

• Semantic drift – a vendor‑specific OID or CLI command may map to multiple OpenConfig leaves, or granularity may differ (e.g., per‑interface vs. per‑sub‑interface counters).
• Implementation gaps – some vendors support only a subset of the OpenConfig model for a given feature, causing missing data or default values.
• Performance impact – OpenConfig subscriptions often use gNMI over TLS, which can consume more CPU and memory than legacy SNMP or CLI‑based polling.
• Operational visibility – existing alarms, thresholds, and correlation rules are tied to the old payload format; a direct swap can break downstream processes.
• Rollback complexity – reverting a subscription is not a transactional rollback; it requires manual removal of the OpenConfig subscription and re‑instantiation of the vendor‑specific collector.

Because of these challenges, a verification‑gated, staged migration is essential to limit blast radius and provide clear go/no‑go criteria.

Pre‑Migration Planning and Assessment

Identifying Vendor‑Specific Paths and OpenConfig Equivalents

1. Inventory collection – export all active telemetry subscriptions (CLI, SNMP, streaming) from each device type using a vendor‑neutral script (e.g., pybatconf for Juniper, cisco‑telemetry‑exporter for IOS XR).
2. Path mapping table – create a spreadsheet with columns:
   • Vendor‑specific path (e.g., show interfaces extensive | match "input packets" on Juniper)
   • OpenConfig YANG path (e.g., /interfaces/interface[name=<ifname>]/counters/in-packets)
   • Data type (counter, gauge, enum)
   • Sampling interval currently used
   • Vendor support level (Full, Partial, None) – consult the vendor’s OpenConfig support matrix.
3. Gap analysis – flag any vendor‑specific path lacking a direct OpenConfig equivalent or marked as Partial. These become candidates for workarounds or retention.

Evaluating Semantics and Potential Incompatibilities

• Unit and scale verification – compare a sample of raw values from both sources over a 5‑minute window. Compute scaling factors (e.g., vendor reports bytes, OpenConfig reports octets; both should be identical).
• Rate vs. absolute – some vendor counters are cumulative; OpenConfig may expose a rate. Determine if conversion is needed downstream.
• Missing fields – note any OpenConfig leaves that are always zero or not populated (e.g., /interfaces/interface/state/phys-address may be absent on certain line cards).
• Timing differences – legacy polling may be every 30 s while OpenConfig subscriptions can be configured for 10 s; assess whether higher frequency impacts downstream aggregation.

Defining Acceptance Criteria and Rollback Conditions

These criteria are evaluated after each rollout phase; failure to meet any triggers an immediate rollback for the affected device or group.

Setting Up Parallel Runs for Verification

Configuring OpenConfig Subscriptions in Parallel

During the parallel run, both the legacy collector and the OpenConfig subscription remain active. Example CLI for three major vendors (adjust paths per your mapping table):

Juniper (JunOS)

# Legacy SNMP (unchanged)
set snmp v3 usm local-engine user monitor auth sha auth-key <key> privacy aes privacy-key <key>
set snmp v3 vacm access group monitor default-context-prefix sec-model usm sec-level authPriv read-view all notify-view all

# OpenConfig gNMI subscription (new)
set protocols openconfig telemetry subscription if-counters \
    update-mode on-change \
    update-interval 10000 \
    exclude-none \
    sensor-path /interfaces/interface[name=<ifname>]/counters \
    transport grpc \
    address <collector-ip>:50051 \
    tls profile default

Cisco IOS XR

# Legacy NetFlow (unchanged)
flow monitor MONITOR-LEGACY
 record ipv4 original-input
 exporter EXPORT-LEGACY
 cache timeout active 60
 interface GigabitEthernet0/0/0/0
  ip flow monitor MONITOR-LEGACY input

# OpenConfig gNMI subscription (new)
telemetry model-driven
 subscription IF_COUNTERS
  sensor-group-id IF_COUNTERS_SG
   sensor-path /interfaces/interface[name=<ifname>]/counters
   sample-interval 10000
  !
  destination-group DEST_GRP
   ipv4 address <collector-ip> port 50051 protocol grpc tls
  !
  subscription-id 100
  source-address <loopback-ip>
  vrf default
  sensor-group-id IF_COUNTERS_SG
  destination-group DEST_GRP

Arista EOS

# Legacy sFlow (unchanged)
sflow enable
sflow polling-interval 30
sflow sample-rate 1024
interface Ethernet1
  sflow

# OpenConfig gNMI subscription (new)
daemon Telemetry
   exec /usr/bin/telemetry -s /interfaces/interface[name=<ifname>]/counters -i 10s -a <collector-ip>:50051 --tls

All three examples keep the legacy collector untouched while adding an OpenConfig subscription that streams to the same (or a duplicate) collector endpoint for side‑by‑side comparison.

Implementing Data Collection and Comparison Tools

1. Collector duplication – run a second instance of your telemetry collector (e.g., Prometheus + OpenTelemetry collector) listening on a different port exclusively for OpenConfig data.
2. Normalization layer – use a lightweight Python script that subscribes to both streams, converts OpenConfig JSON/protobuf to a common internal representation (e.g., Pandas DataFrame), and aligns timestamps to the nearest second.
3. Difference engine – compute per‑sample delta:

   diff = abs(legacy_value - openconfig_value) / max(legacy_value, 1)
   if diff > threshold:
       raise Alert

   Store results in a time‑series database (e.g., InfluxDB) for dashboarding.
4. Alerting – configure alerts on the difference engine to fire when any of the acceptance thresholds from the planning stage are exceeded.

Establishing Baseline Metrics for Verification

Before enabling any OpenConfig subscription, capture a baseline for each metric:

• Legacy value distribution (mean, stddev, min, max) over a 15‑minute window.
• Collector CPU/memory usage (show system resources or top).
• Network overhead – bytes/sec on the management interface (show interfaces mgmt0).

Store these baselines in a version‑controlled JSON file (baseline-<device>.json). During the parallel run, the comparison script references this file to compute percentage changes.

Performing the Migration

Step‑by‑Step Migration Process

The migration follows a controlled sequence per device (or per device‑group) with explicit verification gates:

1. Pre‑check – verify baseline file exists, collector duplication is healthy, and no active alarms on the legacy stream.
2. Enable OpenConfig subscription – push the subscription configuration via your automation tool (Ansible, Nornir, or custom Python script).
3. Parallel run window – maintain both streams for a configurable period (e.g., 20 minutes).
4. Verification gate – run the difference engine; if all acceptance criteria are met, proceed; otherwise, trigger rollback for this device.
5. Commit – if verification passes, schedule a maintenance window to disable the legacy collector for the migrated paths and retain only the OpenConfig subscription.
6. Post‑change verification – repeat the validation script for another 10‑minute window to ensure stability after legacy removal.
7. Final sign‑off – update inventory, close the change ticket, and archive logs.

Handling Incompatible Semantics and Workarounds

When a vendor‑specific path lacks a perfect OpenConfig equivalent:

• Aggregation workaround – if OpenConfig provides per‑sub‑interface counters but the legacy source reported aggregate interface counters, sum the sub‑interface values in the comparison script before calculating deviation.
• Default‑value substitution – for missing leaves (e.g., /interfaces/interface/state/phys-address), inject the legacy value (obtained via CLI) into the normalized stream solely for comparison; do not rely on this for production telemetry.
• Rate conversion – if OpenConfig delivers a rate and the legacy source a cumulative counter, compute the rate from the legacy counter ((value_t2 - value_t1) / interval) before comparison.
• Documentation – record each workaround in the migration runbook with a reference to the vendor’s OpenConfig support matrix and a note that the workaround is temporary until the vendor adds full support.

Executing CLI Commands for OpenConfig Subscriptions

Below are representative CLI snippets for enabling/disabling subscriptions on each platform. Wrap these in your automation playbook with check_mode support to preview changes.

Enable (Juniper)

configure
 set protocols openconfig telemetry subscription if-counters sensor-path /interfaces/interface[name=ge-0/0/1]/counters
 commit and-quit

Disable (Juniper)

configure
 delete protocols openconfig telemetry subscription if-counters
 commit and-quit

Enable (Cisco IOS XR)

configure
 telemetry model-driven
  subscription IF_COUNTERS
   sensor-group-id IF_COUNTERS_SG
    sensor-path /interfaces/interface[name=GigabitEthernet0/0/0/0]/counters
   !
   destination-group DEST_GRP
    ipv4 address 10.0.0.10 port 50051 protocol grpc tls
   !
   subscription-id 200
   source-address Loopback0
   vrf default