Step 1: Getting Started

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

The following topics are covered in this article:

1. Environment Requirements
2. Software Licenses
3. Capacity Planning Tools
4. Key Concepts and Definitions

Environment requirements

You will need Administrative access to a Provider Connectivity Assurance (formerly Accedian Skylight analytics) lab environment and Cisco IOS XR or IOS XE routers in order to build and test your solution. 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 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 from a default set of sensor-paths
- Converts parsed data into OpenMetrics Format and transfers 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 Config, Sensor Path Config, 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/virtual circuits if they require utilization monitoring in Provider Connectivity Assurance

Software License Estimation Tool

For trying out the solution in a lab, non-production environment, there is no need to purchase software licenses. However when it comes time to quote a customer for this solution, Sales can assist with creating a quote for software licenses and CX deployment services. If you are supporting the Sales team to build a quote, note that you can run the Telemetry Collector in a "stand alone" mode, whereby 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 gives you the exact quantity of Telemetry software licenses required on the quote. Contact the Provider Connectivity Assurance TME team if you would like instructions on running this 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 in a yang model format

Sensor Path: Describes a Yang path or subset of data defined in a yang Model. 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

As Session is a logical grouping of metrics that appear in the Inventory in Analytics.

A Session can represent a synthetic test (TWAMP, y.1731) or a telemetry entity being monitored (CPU, Memeory, Interface)

Objects and Sessions are the same thing. The terms are used interchangeably.

Monitored Object Name:

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

Meaningful Monitored Object Names names help make Skylight easy to read and ensure that the customer can locate information easily.

The monitored object name values must contain alpha-numeric (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_ where ‘data identifier’ is specific to each object type based on how unique entities are represented.

Monitored Object ID:

A unique system Identifier. Used to create the inventory in Provider Connectivity Assurance.

Each object in an inventory has a unique Monitored Object ID.
The Telemetry Collector defaults is to set the Monitored Object ID and Monitored Object Name to the same value (i.e._)