Choosing Between eAPI and gNMI for a Bulk VLAN Audit
You need to audit VLAN-to-port assignments across 120 switches every 15 minutes and store the results. Your team already has a Python library that speaks JSON-RPC over HTTPS to EOS eAPI and is well tested. A colleague proposes switching to gNMI/OpenConfig for the audit because "it's more modern." The switches are a mix of 4.28 and 4.31. The VLAN data is currently read via show vlan through eAPI. The audit must complete in under 3 minutes and must not disrupt production. Your team has no existing gNMI tooling or protobuf experience.
1. Evaluate the proposal. What factors should drive the decision, and what would you recommend?
Read the worked answer
Decision factors:
- Data model fit:
show vlanis a native EOS command; eAPI exposes it directly as structured JSON. OpenConfig VLAN models exist but may not cover every EOS-specific field, and mapping may be lossy. - Operational maturity: the team has tested eAPI tooling; gNMI requires protobuf, path subscriptions, and new failure modes. Introducing it for a read-only audit adds risk for little gain.
- Performance: 120 devices × JSON-RPC
show vlanis fast (sub-second per device in parallel); 3 minutes is easily met with a thread pool of ~20-30 workers. - Version consistency: both 4.28 and 4.31 support eAPI; gNMI support and OpenConfig path coverage varies by train and may differ between them.
Recommendation: stay on eAPI for this audit. The "more modern" argument is not a technical requirement. Revisit gNMI only if you need streaming telemetry or a vendor-neutral model across mixed vendors.
2. How would you structure the eAPI audit to meet the 3-minute SLA without disrupting production?
Read the worked answer
- Use parallel workers (e.g.,
concurrent.futures.ThreadPoolExecutor(max_workers=20)) so 120 devices complete in ~6 batches. - Issue a single
show vlanper device viarunCmdswithformat: json, not multiple round trips. - Set timeouts (connect 5s, read 15s) and retry once with backoff; log failures rather than blocking the batch.
- Use a read-only credential and a dedicated management VRF path; eAPI reads are non-disruptive.
- Rate-limit to avoid overwhelming the management plane: cap concurrency so no single device gets hammered, and stagger start times slightly.
- Store results with a timestamp and device serial; diff against the previous run to surface drift.
- Validate the JSON schema before storing so a firmware difference in output shape doesn't silently corrupt the dataset.