Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

Components of Juniper’s Telemetry Solution

Sensors

Telemetry sensors are an important component of a telemetry solution. They measure various physical, environmental, and performance parameters and convert them into signals that are transmitted over gRPC, gNMI, or UDP connections to the collector for remote monitoring and analysis. Some examples are temperature sensors, interface sensors, flow sensors, and so on. Juniper supports both Openconfig and native sensors. You can configure Openconfig-based sensors to retrieve sensor information in a vendor-neutral format or configure native sensors to retrieve Juniper proprietary information in a native format. Openconfig sensors mostly track counter-based or state-based metrics. Native sensors are more effective in tracking event-driven metrics as these sensors have access to in-depth device data.

Openconfig Sensors

To configure data collection from Openconfig sensors, define the subscriptions and sensor paths (for example, /interfaces/interface/state/counters), set up the data collector, and download the Junos Telemetry Interface protocol buffers files from the Juniper Networks support page. Capture and decode the captured data on the collector.

Native Sensors

To configure data collection from native sensors, use the Junos CLI to provision native sensors for collecting specific data. Configure the telemetry interface to stream data using gRPC or UDP. Use the protocol buffer's files to decode the streamed data on the collector.

For detailed information, see Configuring a Junos Telemetry Interface Sensor (CLI Procedure)

A telemetry sensor path is a specific route within a data model, often defined using YANG, that specifies the exact data to be collected and streamed from a network device. For information on sensor paths, see Telemetry Sensor Paths.

Telemetry Data Collector

The telemetry collector is a specialized tool or software that performs data collection, processing, transmission, and storage of telemetry data. It is an intermediary between the Junos devices generating telemetry data and the backend systems that store, analyse, and visualize it.

Functions of a data collector:

  • Data Collection: The collector receives telemetry data from Juniper devices over gRPC, gNMI, or UDP connections.
  • Data Processing: The collector processes the collected data by aggregating and normalizing it to filter out unnecessary information, aggregate metrics, and perform an initial analysis. This processing helps reduce the data volume and focus on the most critical metrics.
  • Data Transmission: It ensures reliable data transmission and low latency.
  • Data Storage: The processed data is then exported to various backend systems for further analysis, visualization, and storage. It can be stored in data lakes for long-term analysis and historical comparison. The collector supports multiple data formats and protocols, making it compatible with different monitoring and analytics tools. The analysed data can be presented through interactive dashboards and reports, providing actionable insights to network administrators.

Telemetry Protocols

The Juniper Telemetry Interface supports the gRPC (gRPC Remote Procedure Calls), gNMI, and UDP protocols to collect and stream telemetry data from Juniper devices to the data collector.

gRPC Remote Procedure Calls (gRPC)

gRPC remote procedure calls (gRPC) are used to provision sensors and to subscribe to and receive telemetry data. gRPC is based on TCP and supports TLS, which enables data transmission security over TCP. TLS establishes secure and reliable encrypted communication channels for data transmission. For more information, see gRPC Services for Junos Telemetry Interface.

User Datagram Protocol (UDP)

Streaming Telemetry Data over UDP is based on the dial-out mechanism. The sensor paths are configured through the CLI, and the device sends the data for the configured sensor paths over UDP to the collector's destination address. The destination address is configured through the CLI. While streaming telemetry over UDP from native sensors, the data is sent to the collector over UDP in the protobuf format. UDP is suitable for exporting stateless data. For more information, see Streaming Telemetry Data Over UDP.

gRPC Network Management Interface (gNMI)

The gNMI is a protocol based on gRPC that configures and monitors network devices. Network operators can retrieve and modify device configuration data and subscribe to real-time telemetry data from network devices. gNMI supports subscription modes such as ONCE, POLL, and STREAM for telemetry updates. gNMI uses data encoding formats such as Protocol Buffers (protobuf) and ensures secure communication using TLS. For more information, see gNMI Protocols and Operations and Subscribing to Telemetry Data Using gNMI.

Telemetry Modes

The Juniper Telemetry Interface supports telemetry sessions in two modes:

  1. Dial-in mode
  2. Dial-out mode

Juniper devices can operate in both dial-in and dial-out modes. You can configure the Juniper device in either mode based on your network's topology. Both modes use the same data models and stream the same telemetry data over the network. The difference between the two modes is based on whether the collector or Juniper device initiates and maintains the connection.

Note:

JTI is predominantly a "dial-out" system for streaming telemetry, regardless of whether you’re using gRPC (with or without gNMI) or UDP. However, it supports some limited dial-in capabilities.
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.

Subscription Modes

JTI supports various subscription modes, enabling tailored data collection based on specific needs and conditions. The subscription modes are configured on the device and dictate the behavior of the data stream. Implementation of subscription modes depends on whether you’re using a dial-out or a dial-in connection. Streaming intervals determine the frequency of telemetry data transmission between the device and the collector. Data collection and streaming are triggered when certain conditions are met or events occur that initiate the collection and streaming of telemetry data. These triggers ensure that data is collected when specific criteria are met. For example, telemetry data can be collected and streamed when packet loss is detected. Both dial-in and dial-out telemetry support the following subscription modes:

  1. Once: This is a one-time request for telemetry data. You can configure this mode when a snapshot of the current state of the subscribed data is required. It is supported in both dial-in and dial-out connections but is primarily used in dial-in connections. The device sends the data once to the collector and stops for a dial-out connection. The collector requests dial-in connections through a "Subscribe" RPC with ONCE mode. In a dial-out connection, you must configure a sensor and subscription to trigger only once, which is not a common scenario. In dial-in connection, it is like a "Get" RPC but framed as a subscription.
  2. Poll: Is periodic on-demand retrieval of telemetry data. This configuration is suitable for monitoring sensors at specific intervals. POLL is supported in a dial-in scenario, where the collector initiates the connection to the device’s gNMI server. It’s not a typical dial-out streaming mode, as JTI’s streaming is device-driven. Requires the device to run a gNMI server. The collector subscribes with POLL and then polls as needed.
  3. Stream: This ongoing subscription continuously streams data when configured triggers occur.

Note: Not all sensors (OpenConfig or native) support all modes.

This form of subscription has three sub-modes:

  • ON_CHANGE: The device sends updates only when the monitored data changes (for example, an interface counter increments or a state flips). This mode is suitable for event-driven metrics rather than time-driven. Native sensors have an edge over Openconfig sensors in the context of event-driven metrics.
  • SAMPLE: Telemetry updates are streamed at regular intervals based on the configured interval. This mode is suitable for metrics like packet counts or bytes transferred, which are sampled over time.
  • TARGET_DEFINED: The device decides the best mode (SAMPLE or ON_CHANGE) based on the monitored sensor or resource. Juniper's implementation may default to SAMPLE unless ON_CHANGE is explicitly supported for the sensor.
    • NOTE: The TARGET_DEFINED subscription requests for configuration paths are treated as ON_CHANGE requests only.
Guidelines for Configuring the Subscription Modes

Consider the following guidelines before selecting the telemetry sensors, connection method (dial-in or dial-out), and subscription mode suitable for your network topology:

  1. A combination of OpenConfig sensors and the subscription mode SAMPLE is ideal for standardized, periodic monitoring (for example, multivendor dashboards).
  2. A combination of Native sensors and ON_CHANGE subscription mode is suitable for Juniper-specific and event-driven insights (for example, troubleshooting hardware).

GitHub Resources

GitHub is a code hosting platform for version control and collaboration. It lets you and others work together on projects from anywhere. Juniper Networks is part of the OpenConfig community that uses GitHub to develop telemetry code and store documents. Contribute to Juniper telemetry development by creating an account on GitHub.

Table 1: GitHub Resources

Telemetry Resources

Description

Juniper telemetry on GitHub

Juniper telemetry models, augments, and deviations.

Protobuf file

Juniper protocol buffer files, organized by Junos OS Release.

gNMI protobuf file

Juniper gNMI protocol buffer files, organized by Junos OS Release.
YANG models Starting in Junos OS Evolved Release 23.4R1, all YANG data models for a given OS and release are in a single download package and GitHub repository. The package and repository include the native configuration, state, and RPC data models and the OpenConfig and Internet Engineering Task Force (IETF) data models supported by that OS.

Determine the Appropriate Telemetry Configuration for your Network

To determine the appropriate telemetry session for your network, the following information summarizes a comparison between dial-in and dial-out telemetry modes:

Dial-In vs. Dial-Out

  • Dial-in (gRPC with gNMI) pulls snapshots from either sensor type (Openconfig or native).

    Example: Collector uses gNMI over gRPC to pull OpenConfig stats (/interfaces) or native PFE stats (/junos/system/linecard).

  • Dial-out (gRPC with gNMI or UDP) streams updates, with gNMI/gRPC favoring structure and UDP suiting native simplicity.

    Example: Device streams OpenConfig BGP stats through gNMI over gRPC, or native firewall counters over UDP.