Frequently Asked Questions - gNMI

What is the difference between dial-in and dial-out telemetry?

Telemetry supports two communication models: Dial-in and Dial-out, each with a different approach to how data flows between OpManager and the monitored device.

Dial-in: OpManager requests data from the device, similar to SNMP polling.

Dial-out: The device continuously streams data to OpManager without explicit requests.

Currently, OpManager supports the dial-in model. Dial-out (streaming) is planned for future enhancements.

What transport modes are supported in gNMI?

OpManager supports three communication modes:

Plain Text: No encryption; recommended only for testing.

One-Way TLS: Encrypts communication and verifies the server identity.

mTLS (Mutual TLS): Enables two-way authentication, where both OpManager and the device verify each other using certificates.

How does Auto Fetch work in TLS/mTLS configuration?

When Auto Fetch is enabled: OpManager automatically retrieves the server certificate during the initial connection. The retrieved certificate is trusted for subsequent communication.

When Auto Fetch is disabled: The server certificate must be manually uploaded.

What is Hostname Override and when should it be used?

Hostname Override is used when the certificate hostname does not match the device IP address. Certificates are typically issued with a DNS name, and if the device is accessed via IP, validation may fail. Hostname Override ensures proper certificate validation by matching the expected hostname.

What is the difference between Self-signed and External CA in mTLS?

Self-signed certificates: Generated and managed within OpManager. Must be manually configured on the device. Suitable for controlled or test environments.

External CA certificates: Issued by a trusted third-party Certificate Authority. Require uploading the client certificate, private key, and CA chain. Recommended for enterprise environments with centralized certificate management.

How are certificates managed in OpManager?

Certificates are stored in a secure keystore and truststore, with private keys maintained securely. The latest uploaded certificate is used for authentication. Only one external CA can be maintained across credential profiles.

How is device type identified during telemetry discovery?

Unlike SNMP, which uses SysObjectID, telemetry devices do not provide a direct identifier. OpManager determines the device type using one or more of the following attributes: Model Name, Description, Hardware Version, Software Version, Manufacturer Name, and Port Number.

How frequently is telemetry data collected?

Telemetry data is collected using configured paths (XPath/OpenConfig models) at configurable intervals, with a recommended default of 15 minutes.

How are performance monitors created and how is telemetry data collected?

For telemetry devices, performance data is not collected using SNMP OIDs. Instead, OpManager uses model-driven paths (XPath/OpenConfig paths) to retrieve metrics from the device.

During discovery, once the Vendor, Category, and Device Type are identified, OpManager checks for a matching Device Template. If a template is not available, it is created dynamically. These monitors use predefined XPath/OpenConfig paths to fetch telemetry data. Data is collected at regular intervals (typically every 15 minutes) and populated in the corresponding performance monitors.

Are there any limitations in telemetry discovery?

Yes, the current limitations include:

• Only one gNMI credential can be used per discovery.
• Telemetry credentials cannot be combined with SNMP, WMI, or CLI.
• Only the dial-in model is supported.
• Only one external CA can be configured globally.
• Device type identification is model-based and not direct.

To learn how to add a gNMI credential and the steps to discover a gNMI device, visit our help page.