Overview
This article explains how network performance data is collected, transported, and visualized in Cisco Provider Connectivity Assurance (formerly Skylight performance analytics). It clarifies key terminology, outlines data sources and flow, and summarizes SNMP trap versus polling.
Both Cisco Provider Connectivity Assurance and non-Provider Connectivity Assurance devices can collect key performance indicators (KPIs) that are sent to Cisco Provider Connectivity Assurance.
Terminology Alignment
To align terms used across components:
Legacy Orchestrator (formerly Skylight Orchestrator)
- Network Element: Device that generates performance metrics.
- Collection Matrix: View showing the device session being polled for data.
- Statistics: Contain the key performance indicators (KPIs).
Cisco Provider Connectivity Assurance (formerly Analytics)
- Monitor Session: Device generating performance metrics.
- Session: Device collecting metrics being polled for data.
- Performance Metrics: Contain the KPIs.
Data Sources
Legacy Orchestrator collects performance monitoring data from managed and non-managed devices. Performance monitoring data can originate from:
- Cisco Provider Connectivity Assurance Sensors: GT, LT, and LX (previously Skylight performance elements).
- Cisco Provider Connectivity Assurance Sensor Control (formerly Skylight sensor: control).
- Cisco Provider Connectivity Assurance Sensor SFP (formerly Skylight sensor: SFP compute).
- Cisco Provider Connectivity Assurance Sensor Modules (formerly Skylight sensor: module).
- Other vendor applications that reflect frames or packets.
For non-Provider Connectivity Assurance devices, SNMP is used to discover devices and sessions. Rules based on discovery determine which sessions, devices, and interfaces are visualized.
Data Flow and Collection
- Legacy Orchestrator streams collected performance data from managed devices to Cisco Provider Connectivity Assurance in CSV format.
- The Sensor Collector (formerly Roadrunner) polls devices and sends resulting files to Cisco Provider Connectivity Assurance.
Capture Data
Packet capture refers to the interception of a data packet at a specific network point for short-term storage and analysis, after which the packet can be downloaded, archived, or discarded.
Packet sniffers intercept and log network traffic via wired or wireless network interface on a host machine.
After capture, Cisco Provider Connectivity Assurance analyzes the raw packet data and presents it in a readable format for visualization.
Session Examples (KPIs)
Here are some examples of data collected via Legacy Orchestrator from Cisco Provider Connectivity Assurance devices:
TWAMP Session from Sensor Control
The information circled in this screen capture presents the actual values that will be streamed to Cisco Provider Connectivity Assurance.
TWAMP Session from Assurance Sensor LT
The information underlined in this screen capture, presents the actual values that will be streamed to Cisco Provider Connectivity Assurance.
The KPIs are outlined in red
CFM Sessions from Assurance Sensor LT
Assurance Sensor LT CFM sample session MEP statistics.
Assurance Sensor LT CFM sample session DMM statistics.
Assurance Sensor LT CFM sample Packet loss
PAA Session from Assurance Sensor LT
PAA offers the capability to measure QoS performance metrics at the IP and Ethernet layers.
The KPIs are the columns boxed in gold.
Legacy Orchestrator Configuration
To configure Legacy Orchestrator to stream CSV files to Cisco Provider Connectivity Assurance:
- Go to Collection > Server Configuration.
- Use the following configuration:
- Use Provider Connectivity Assurance Legacy Orchestrator as default server for metrics collection: Check to export metrics from Assurance Sensors GT/GT-S, LT-S, and LX-S (PAA, BRW, SOAM, etc.) and Sensor Control (NFV SOAM, flowemeter, etc.)
- Enable export of performance sessions: Check to export metrics from Legacy Orchestrator sessions.
- User, Password, Host: Sensor Collector host OS IP address and credentials
- Directory: Sensor Collector data directory
- Click Test to test your connection with Sensor Collector.
- Click Apply.
SNMP: Traps vs. Polling
SNMP follows the command center-agent model, where you have a central command center, and multiple agents at various remote locations. Agents collect operational information—including self-status such as system alarms—and report it to the command center. Communication mechanisms include SNMP traps and SNMP polling.
- Traps: Agents send immediate notifications to the command center when events occur. Limitation: If no trap is sent, the command center cannot confirm agent health.
- Polling: The command center regularly requests data from agents. If an agent is offline, no response is returned, indicating a potential issue.
Recommendation: Choose a hybrid approach—such as that supported by Cisco Provider Connectivity Assurance—which uses both traps and polling to combine immediacy with ongoing health checks.
© 2025 Cisco and/or its affiliates. All rights reserved.
For more information about trademarks, please visit: Cisco trademarks
For more information about legal terms, please visit: Cisco legal terms
For legal information about Accedian Skylight products, please visit: Accedian legal terms and tradmarks