Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

Understanding Dial-in Telemetry

Dial-in telemetry is a network monitoring method where the collector initiates the connection to the device to retrieve telemetry data. The collector "dials in" to the network device, typically using protocols like gRPC to request and receive data.

In dial-in mode, the data collector initiates the connection to the network device and subscribes to telemetry data. A session is established between the collector and the device, and then data is streamed from the device to the collector at configured intervals. This method is preferred by operators who want a single configuration and operational data channel.

Figure 1: Dial-in Telemetry Network communication flow: Collector connects to target device via customer cloud network to gather telemetry data.

The JTI supports both gNMI and Juniper Extension Toolkit (JET) dial-in connections over gRPC transport.

Note:

Juniper’s gNMI support in JTI is primarily dial-out, where the device acts as the gRPC client and the collector is the gRPC server. Dial-in (collector connecting to the device) isn’t a standard JTI feature for gNMI/gRPC telemetry streaming. However, you can use gNMI in a dial-in fashion for on-demand requests (for example, a one-time “get” operation to fetch data), but this is not the same as a persistent telemetry subscription. For streaming telemetry, gRPC in JTI is usually device-initiated. For gNMI dial-in connections gNMI service must be enabled. The POLL (collector polls snapshots), and ONCE (single snapshot) subscription modes are supported.

gRPC Service

gRPC is an open-source framework that provides secure and reliable data transport. You can use a set of Remote Procedure Call (RPC) interfaces to configure the Junos telemetry interface and stream telemetry data using the gRPC framework. gRPC remote procedure calls (gRPC) are used to provision sensors and to subscribe to and receive telemetry data. OpenConfig supports the YANG data models. The OpenConfig data model generates data as Google Protocol Buffer (gpb) messages in a universal key/value format.

Note: Starting in Junos OS Release 18.2R1, OpenConfig-based routing engine (RE) sensors can stream data as gpb-structured messages over UDP.

Using gRPC to Stream Data

According to the OpenConfig specification, only gRPC-based transport is supported for streaming data. The gRPC server terminates the gRPC sessions from the management system that runs the client. RPC calls trigger the creation of Junos OS sensors that either stream data periodically or report events, which are then funneled onto the appropriate gRPC channel .

Note:

Starting in Junos OS Release 18.2R1, when an external streaming server, or collector, provisions sensors to export data through gRPC on devices running Junos OS, the sensor configuration is committed to the junos-analytics instance of the ephemeral configuration database, and the configuration can be viewed by using the show ephemeral-configuration instance junos-analytics operational command. In earlier releases, the sensor configuration is committed to the default instance of the ephemeral configuration database.
Note:

The Juniper telemetry header that was exported as part of updates is now exported as an extension header. GnmiJuniperTelemetryHeader.proto is used to decode the updates from Juniper devices running Junos OS Release 19.3 or earlier and GnmiJuniperTelemetryHeaderExtension.proto is used for devices running Junos OS Release 19.4 or later.

See Table 1 for a list and descriptions of the RPCs implemented to support the Junos telemetry interface.

Table 1: Telemetry RPCs

RPC Name

Description

telemetrySubscribe

Specify telemetry parameters and stream data for the specified list of OpenConfig paths.

getTelemetrySubscriptions

Retrieve the list of subscriptions that are created through telemetrySubscribe.

cancelSubscription

Unsubscribe a subscription created through telemetrySubscribe.

Data streamed through gRPC is formatted in OpenConfig key/value pairs in protocol buffers (gpb) messages. In this universal format, keys are strings that correspond to the path of the system resources in the OpenConfig schema for the device being monitored. The values correspond to integers or strings that identify the operational state of the system resource, such as interface counters, and the state of the resource.

Note:

Starting in Junos OS Release 18.2R1, data streamed through gRPC can be formatted as protobuf in addition to key/value pairs for OpenConfig-based routing engine (RE) sensors. These sensors are in addition to the packet forwarding engine (PFE) sensors.

The following shows the universal key/value format:

The following example shows how a set of counters for an interface can be represented:

A mapping table maps field names to the OpenConfig key strings.

Enable Junos Telemetry Interface Using OpenConfig

OpenConfig for Junos OS specifies an RPC model to enable the Junos telemetry interface. This package also includes the required YANG models.

You can locate all YANG data models in a GitHub repository for a given OS and release in a single download package. The package and repository include the native configuration, state, and RPC data models and the OpenConfig and IETF data models supported by that OS. You can also access the YANG data models from the Juniper Networks download site.

Using a Web browser, navigate to the All Junos Platforms software download URL on the Juniper Networks webpage: https://www.juniper.net/support/downloads/. From the Network Management tab, scroll down to select OpenConfig. Select the Software tab. Select the appropriate version of OpenConfig module.

The programmatic interface OpenConfigTelemetry defines the telemetry gRPC service. The telemetrySubscribe RPC specifies the following subscription parameters:

  • OpenConfig path that identifies the system resource to stream telemetry data, for example:/interfaces/interface/state/counters/

  • Interval at which data is reported and streamed to the collector server, in milliseconds, for example: sample_frequency = 4000

The telemetrySubscribe RPC is used by a streaming server, or collector, to request an inline subscription for data at the specified path. The device should then send telemetry data back on the same connection as the subscription request.

gRPC Server Overview

The Junos Telemetry Interface (JTI) includes the capability for multi-port service configuration, allowing you to configure multiple sets of telemetry services to listen on different ports.

The Telemetry Interface introduces flexible gRPC service configuration capabilities, enabling you to set up multiple gRPC servers, each with distinct services, listening addresses, and ports. This functionality provides granular control over service management and telemetry data collection. You can configure TLS certificates for each server to ensure secure communications. To configure gRPC server, see Configure gRPC Services.

gNMI Service

The gNMI (gRPC Network Management Interface) is a protocol based on gRPC that configures and monitors network devices. Developed by OpenConfig specifically for network management, gNMI allows network operators to retrieve and modify device configuration data and subscribe to real-time telemetry data from network devices. Data collection is a key task in telemetry solutions. gNMI supports subscription modes such as ONCE, POLL, and STREAM for telemetry updates. gNMI leverages the gRPC framework and uses efficient data encoding formats such as Protocol Buffers (protobuf), and assures secure communication using TLS. YANG models to define structure of configuration and telemetry data.

The main components of gNMI are:

  • gNMI Client: Runs on an external system. It sends gNMI requests to configure the device, retrieve configuration data, and subscribe to telemetry streams.

  • gNMI Server: Runs on the network device and provides access to telemetry and configuration data. The gNMI server processes the request based on its type. If it is a configuration management change, it updates the device configuration and sends a response to the client. The data will be streamed to the gNMI client if it is a telemetry data collection request.

gNMI supports the following Remote Procedure Calls (RPCs) for managing and monitoring network devices:

  • Get: This RPC retrieves the current state of the network device, including configuration and operational data.

    Note:

    In the gNMI get command, the type option is used to specify the type of data to be retrieved. The available options are CONFIG, STATE, and ALL. The valid type option is CONFIG. Encoding defines the value encoding formats that are supported by the gNMI protocol. JSON, BYTES, PROTO, ASCII, and JSON_IETF are available options. The valid encoding options are JSON_IETF and ASCII. Choosing any other configuration apart from the valid options will result in an error message.

  • Set: The set RPC modifies the configuration of the network device.

  • Subscribe: You can use this RPC to subscribe to telemetry data from a network device. The following subscription modes are supported:

    • ONCE: Retrieves the current values only once.
    • POLL: Sends current values whenever a poll message is received.
    • STREAM: Continuously sends updates at specified intervals or when changes occur.

    For more information, see Guidelines for Telemetry Data Subscriptions over gNMI

  • Capabilities: This RPC discovers the capabilities of the network device, such as supported models and encodings.

gNMI Origin

The origin field in the Path message identifies a schema that the path belongs to. origin is encoded as a string. The path specified within the message is uniquely identified by the tuple of <origin, path>.

The origin field is valid in any context of a Path message. Typically it is used in the following ways:

  • In a SetRequest to indicate a particular schema is being used to modify the target configuration.
  • In a GetRequest to retrieve the contents of a particular schema, or in a GetResponse to indicate that the payload contains data from a particular <origin, path> schema.
  • In a SubscribeRequest to subscribe to paths within a particular schema, or SubscribeResponse to indicate an update corresponds to a particular <origin, path> tuple.

If more than one origin is used within a message, a path in the prefix must not be specified, because a prefix applies to all paths within the message. In the case that a prefix is specified, it must specify any required origin. A single request must not specify origin in both prefix and path fields in any RPC payload messages.

Special Values of Origin

Origin values are agreed out-of-band to the gNMI protocol. Where the origin field is unspecified, its value should default to openconfig. It is recommended that the origin is explictly set.

Definition of origin for YANG-modelled Data

The openconfig-extensions:origin field may be utilised to determine the origin within which a particular module is instantiated.

Note:

origin is distinct from namespace. While a YANG namespace is defined at any depth within the schema tree, an origin is only used to disambiguate entire schema trees. That is to say, any element that is not at the root inherits its origin from its root entity, regardless of the YANG schema modules that make up that root.

Partial Specifications of Origin in Set

If a Set RPC specifies delete, update, or replace fields which include an origin within their Path messages, the corresponding change must be constrained to the specified origin in the following ways:

  • replace operations must only replace the contents of the specified origin at the specified path. Origins that are not specified within the SetRequest must not have their contents replaced. In order for a replace operation to replace any contents of an origin it must be explicitly specified in the SetRequest.
  • delete operations must delete only the contents at the specified path within the specified origin. To delete contents from multiple origins, a client must specify multiple paths within the delete of the SetRequest.

These rules apply where origins represent data that doesn't overlap. in some cases (e.g., CLI and OpenConfig) origins may reflect different 'views' on the same data, and thus their interaction is more complex.

Transactionality of Sets with multiple Origins

Where a SetRequest specifies more than one origin - i.e., two or more operations whose path include more than one origin - manipulations to all affected trees must be considered as a single transaction. That is to say, only if all transactions succeed should the SetResponse indicate success. If any of the transactions fail, the contents of all origins must be rolled back, and an error status returned upon responding to the Set RPC.