Step 1: Getting Started

This article will help ensure you have the right environment, tools, and concepts to start ingesting telemetry for IOS-XR or IOS-XE devices.

The following topics are covered:

• Environment Requirements
• Software License Estimation Tool
• Key Concepts and Definitions

Environment Requirements

To build and test your solution, you need administrative access to a Provider Connectivity Assurance (formerly Accedian Skylight analytics) lab environment and Cisco IOS XR or IOS XE routers.

You will configure and deploy your Telemetry Collector(s) and Sensor Collector(s) into the environment where the routers reside.

Provider Connectivity Assurance - Cloud Deployment

• User interface/portal where users can see all MDT data from router devices
• Includes several OpenMetrics SDK APIs, including the API for building a Sensor Collector and Telemetry Collector components
• Non-Production (lab) environment must always be used when integrating new data sources to avoid disruption to Production systems

Sensor Collector - Deployed in Customer Environment

• Sensor Collection component that collects metrics and data from Telemetry Collectors
• Converts OpenMetrics from Telemetry Collector to a Provider Connectivity Assurance-compliant format and transfers them to the Provider Connectivity Assurance deployment in the cloud
• Deployed instance must have access to Provider Connectivity Assurance in the cloud and to the Telemetry Collector

Telemetry Collector - Deployed in Customer Environment

• Receives MDT data from IOS Routers using a default set of sensor-paths
• Converts parsed data into OpenMetrics format and transfers it to configured Sensor Collector instance
• Deployed instance must be accessible by the router via gNMI dial-out

IOS-XR and/or IOS-XE Router

• MDT enabled routers
• Configured with Destination configuration, Sensor Path configuration, and Subscription Group for our environment
• IOS- XR devices running IPSLA (either ICMP Echo or UDP Jitter) or Y.1731 performance tests if that service assurance data is desired for ingestion to Provider Connectivity Assurance
• IOS-XE devices report device environmental (CPU, Memory) and Interface usage metrics without any additional provisioning required
• Defining service policies for services and virtual circuits if they require utilization monitoring in Provider Connectivity Assurance

Software License Estimation Tool

To test the solution in a lab, a non-production environment, purchasing software licenses is not required. However, when quoting the solution for a customer, Sales can help create a quote for software licenses and CX deployment services.

Note: If you are supporting the Sales team to build a quote, you can run the Telemetry Collector in a stand-alone mode, where it is not connected to Sensor Collector and not streaming any data to Provider Connectivity Assurance, but does output the exact quantity of objects that are being streamed from the IOS device. This number provides the exact quantity of Telemetry software licenses required on the quote.

Contact the Provider Connectivity Assurance TME team if you require instructions on running the software license estimator tool.

Provider Connectivity Assurance Concepts and Definitions

MDT:

Model Driven Telemetry

YANG Model:

Tree-like data structure containing hierarchal structured data; IOS-XR MDT data is stored and outputted as a YANG model format

Sensor Path:

Describes a YANG path or subset of data defined in a YANG Model and functions like a map to the desired data; a sensor path can be specified to end at any level of the hierarchal data.

Sessions and Objects:

A Session is a logical grouping of metrics that appear in the Inventory in Provider Connectivity Assurance.

Sessions can represent a synthetic test (TWAMP, Y.1731) or a telemetry entity being monitored (CPU, Memory, Interface)

Objects and Sessions refer to the same concept and can be used interchangeably.

Monitored Object Name:

The name of an object type instance is configurable and referred to as the Monitored Object Name.

Meaningful Monitored Object Names clearly indicate the entity being monitored, making it easier for customers to locate information.

The Monitored Object Name values must contain alphanumeric (a-z, A-Z, 0-9), “_” (underscore), “-” (dash), “.” (dot) and “/” (slash) characters.

The format for the Monitored Object Name in our Telemetry Collector solution is < source >_< Data identifier> where ‘Data identifier’ is specific to each object type based on how unique entities are represented.

Monitored Object ID:

A Monitored Object ID is a unique system identifier and is used to create the inventory in Provider Connectivity Assurance.

Each object in an inventory has a unique Monitored Object ID.

By default, the Telemetry Collector sets the Monitored Object ID and Monitored Object Name to the same value (i.e. < source >_< Data identifier> ).