You are viewing documentation for 1.1.0. This version is no longer maintained.

Choosing a protocol

When to pick gNMI, NETCONF, SNMP, or CLI for collecting from a device — with a decision tree, vendor-support reality check, and scaling implications.

Recommendation

Pick gNMI when the device supports it and you need streaming telemetry. Fall back to NETCONF for configuration-shaped data, SNMP for breadth of vendor coverage, and CLI only when nothing else exposes the data you need.

Why this matters

The Protocol you attach to a Device determines almost everything that follows: how often you can poll without hurting the device, how rich the data is, how much engineering you spend writing Mappings, and whether the same Model can survive a vendor swap. Choosing well at onboarding time saves you from rebuilding Subscriptions later.

Quick decision tree

Walk this top to bottom. Stop at the first answer that fits.

Does the device speak gNMI, and is the data you need exposed in its YANG tree? Use gNMI. This is the right answer for almost all modern routers, switches, and DC fabrics.
Do you need to read or push configuration shapes (interfaces, policies, route maps, ACLs) on a device that speaks NETCONF? Use NETCONF. It is built for transactional config and exposes the same YANG modules you would target with gNMI on devices that ship both.
Is the device an older box, an appliance, or something with no YANG support, but it answers SNMP cleanly? Use SNMP. It is universal, cheap, and well understood. Use v3 for anything you would not put on a management VLAN.
Is the data only available in show output? Use CLI — reluctantly. It is the most expensive protocol to maintain and the first thing that breaks on a vendor software update.

Comparison at a glance

Dimension	gNMI	NETCONF	SNMP	CLI
Transport	gRPC over HTTP/2 + TLS	SSH (typically port 830)	UDP 161 / 162	SSH
Data model	YANG	YANG	MIB / OID tree	Free-form text
Push or pull	Streaming + on-demand	On-demand	On-demand	On-demand only
Typical freshness	Sub-second to seconds	30 s and up	30-60 s and up	Minutes
Mapping cost	Low (YANG path)	Low to medium (YANG path)	Low (OID)	High (regex / parser)
Vendor breakage on upgrade	Rare	Rare	Rare	Frequent
Scale per collector	Highest	Medium	High	Lowest

Vendor support reality

Treat marketing data sheets with caution. What you actually see in the field, today:

Cisco IOS-XR, IOS-XE 17+, NX-OS 9+ — gNMI is solid; NETCONF is available; SNMP is fine for inventory; CLI is the safety net.
Juniper Junos — NETCONF is the historically richest interface; gNMI works on modern releases; SNMP is reliable for counters.
Nokia SR OS — gNMI and NETCONF are both first class.
Arista EOS — gNMI is excellent; eAPI is also available but is not directly modeled by the Collector.
Older, embedded, or non-network devices (UPS, optical line systems, legacy firewalls) — SNMP first, CLI as fallback. Do not assume YANG.

If a vendor advertises gNMI but the YANG tree is sparse for the metric you need, fall through to NETCONF or SNMP rather than fight the tooling.

Scaling implications

Per-collector capacity drops sharply as you move down the list:

gNMI streaming — one TCP session per device carries many paths. A 2 vCPU collector handles a few hundred subscriptions comfortably, consistent with the max-subscriptions = 1000 cap shipped in the default config.
SNMP polling — bound by the worker-pool-size and by the device's own SNMP engine. Plan on poll intervals of 30 s or longer on busy devices.
NETCONF on-demand — a fresh session per poll is expensive. Keep intervals coarse (60 s+) or rely on persistent sessions where the device supports them.
CLI — every poll is an SSH login plus a TTP parse pass. Treat each CLI subscription as ten times the cost of an equivalent gNMI one.

Trade-offs

Picking gNMI by default means:

You depend on the vendor's YANG coverage for the metric you want. If the YANG tree is missing a counter, you cannot magically fish it out — you fall back to another protocol for that one Field.
Streaming subscriptions are sticky. A flapping management link causes a session reconnect storm; tune subscription-stagger-delay and max-concurrent-subscriptions to match what your devices tolerate.
TLS certificate hygiene becomes part of your Day 2 work.

Picking SNMP for breadth means:

You accept coarser freshness and a more brittle data shape (MIB versions, vendor-specific extensions).
Walking large tables (interfaces on a chassis with 1000+ ports) can pressure the device's SNMP engine. Throttle.

When to deviate

You need configuration-shaped data, not just operational state. Use NETCONF over gNMI even on devices that support both — many platforms expose the full config tree (interfaces, policies, ACLs) reliably over NETCONF while gNMI only surfaces operational state.
The metric only exists in vendor-proprietary syslog or CLI output. Use the appropriate protocol for the data, not for the pretty diagram. A single CLI Subscription on three devices is fine; a fleet of 500 CLI Subscriptions is not.
Compliance forbids opening port 830 or gRPC. SNMP v3 over a management VLAN may be the only thing your security team will approve. That is a legitimate forcing function.
You are doing one-shot inventory. SNMP sysDescr and friends beat anything fancier. Do not stand up a YANG repo for a one-time audit.