Telemetry Collector: Overview and Deployment Guide

This article explains how to ingest telemetry from Cisco IOS XR and IOS XE routers for visualization in Provider Connectivity Assurance (formerly Accedian Skylight Analytics).

This material is intended to assist technical Cisco employees who want to set up and leverage Provider Connectivity Assurance to ingest the default, out-of-the-box Model Driven Telemetry metrics from IOS-XR and IOS-XE routers.

If you require data ingestion that is not covered by our default out-of-the-box IOS XE and IOS XR offering described here, please reach out to Sales to obtain a quote for a custom Telemetry Collector solution tailored to your particular use case. Cisco CX and Partner organizations are able to quote and build custom Collector components to ingest time-series assurance data from other sources (such as Cisco or third-party Streaming Telemetry devices, SNMP devices, network applications like VoIP, and others).

The following topics are covered:

• Solution Architecture: Familiarize yourself with how the solution works
• Default Out-Of-The-Box Telemetry Metrics: Overview of the specific sensor paths and ingested metrics
• Capacity Planning and Compute Requirements: Understand how much data a Telemetry Collector can handle
• Deployment Instructions: Give it a try yourself (on a non-production environment)
• Commercials: How to quote this solution to a customer

Solution Architecture

First, you will learn about the Telemetry Collector and its purpose in the Provider Connectivity Assurance solution.

The Telemetry Collector receives and ingests a default set of sensor path telemetry metrics that are being streamed out of the IOS XR and IOS XE devices on a user-defined cadence.

The Telemetry Collector transforms the data to OpenMetrics format and transmits the data to the Sensor Collector, the data collector component for Provider Connectivity Assurance. The Sensor Collector securely transmits the data to Provider Connectivity Assurance in the cloud.

For the out-of-the-box default Telemetry collection, the router is configured for gNMI dial-out connectivity to the Telemetry Collector and is set up to stream the telemetry at whatever cadence is specified on the router (every 1 minute or every 5 minutes, for example). As shown in the diagram, this cadence is the interval at which the data will appear in Provider Connectivity Assurance.

In scenarios where the out-of-the-box IOS device metrics are not sufficient, customization of the Telemetry Collector and Sensor Collector can be quoted by CX or Partners. At its core, the Telemetry Collector integrates Telegraf within it. This architecture allows CX or Partners to customize it for specific use cases.

Contact Sales if additional customization is required to augment the default IOS XE and IOS XR with additional sensor paths, metrics, metadata ingestion, or if an entirely different data source is required.

Default Out-Of-The-Box Telemetry Metrics

The default out-of-the-box Telemetry Collector solution ingests the following metric categories from IOS-XR routers:

• Y.1731 (Layer 2) or IPSLA (Layer 3) ICMP Echo or UDP jitter performance test metrics
• Policy and Interface bandwidth utilization metrics
• Router environment CPU/Memory utilization metrics

For IOS-XE, the collected metric categories include:

• Router environment CPU/Memory utilization metrics
• Interface bandwidth utilization metrics

For more details on the object types and metrics that will appear in Provider Connectivity Assurance, refer to Default Telemetry Ingestion.

If your customer use case involves other MDT telemetry data that is not covered by these defaults, please reach out to Sales for a customization quote.

Capacity Planning and Compute Requirements

A single Telemetry Collector instance can ingest data from one or more IOS devices.

A single data ingestion pipeline (which is comprised of a Telemetry Collector paired with a Sensor Collector) can handle 19,500 metric records being streamed to it from the IOS device every 1 second (or at a less frequent cadence, depending on the user requirements).

If more than 19,500 records at 1 second streaming are required, multiple data ingestion pipelines (Telemetry Collectors and Sensor Collectors) can be deployed to handle the requirements.

Note: Any additional software running on the virtual machine(s) that house the Telemetry Collector and Sensor Collector will require additional processor and memory resources; the compute requirement specifications above are only for the data ingestion pipeline components.

Solution Engineers can decide whether to deploy the Sensor Collector and Telemetry Collector on a single virtual machine or, as an alternative, they can each be deployed on separate machines that have one-to-one pairing.

The tables below list the default, out-of-the-box telemetry objects for IOS-XE and IOS-XR, including the number of metrics for each object.

IOS XR Default Objects:

IOS XE Default Objects:

A tool is available for measuring the number of objects being streamed out from an IOS device. This is useful for capacity planning to assess if the 195,000 metric threshold will be surpassed, requiring multiple Telemetry Collectors to handle the load. Refer to Step 2: Configuration and Deployment for instructions on using the tool.

Deployment Instructions

Step 1: Getting Started

Ensure you have the right environment, tools and components to start ingesting default telemetry from IOS-XR and IOS-XE devices.

Step 2: Configuration and Deployment

Create, deploy and configure the components to build a data ingestion pipeline for default telemetry data from your IOS XR and XE device(s).

Step 3: Enabling Data in Provider Connectivity Assurance

Enable your data in Provider Connectivity Assurance.

Commercials: Quoting Instructions

This section provides guidance on testing this in a non-production lab environment.

When quoting the solution to a customer, they will require software licenses and deployment services.

Software Licenses

The Advanced Right-to-Use (RTU) for Provider Connectivity Assurance is required to have access to Telemetry ingestion functionalities.

Additionally, one Telemetry software license is required for each object that is ingested into Provider Connectivity Assurance.

There is a tool to measure how many objects are being streamed out of an IOS device, which determines the quantity of Telemetry licenses that are required by the customer. For more details about this tool, see: Step 1: Getting Started.

Contact Sales for assistance with quoting telemetry ingestion for your customer. The quote will include:

• Software charges (mandatory): One Advanced Right-to-Use RTU and one Telemetry software license for every ingested object
• Delivery Services (mandatory): CX deployment and enablement services to get the solution running in the customer environment
• Customization Services (optional): If the default out-of-the-box solution is not sufficient for the use case, Cisco CX and Partners can quote the work to build and deploy a custom ingestion solution for your requirements.