Fabric Validation

The Fabric Validation dashboard provides continuous, automated assurance of fabric health for AI factory clusters. Validation runs every 30 seconds and reports a health score, active violations, 24-hour trend, and blast-radius analysis across pods, planes, and device roles — without requiring manual per-device inspection. Use this dashboard as the operational starting point before opening traffic or congestion dashboards.

Persona Use Cases

Dashboard Overview

The Fabric Validation dashboard is a single workbench organized into three sections:

• Fabric Validation Workbench — health score, active violations, inventory count, and 24-hour trend at a glance.

• AIOps Fault-Domain Analysis — heatmaps that localize violations by pod, plane, and role to quantify blast radius.

• Validation Classes — per-class trend charts that confirm whether a violation is persistent, spreading, or clearing.

Validation covers five classes:

Fabric Validation only evaluates devices that have an assigned fabric role. Devices without a role are excluded from validation regardless of their operational state. To ensure full coverage, assign roles before relying on health scores or violation counts. See Assign Device Roles and Groups.

Validation Intents

Fabric Validation is driven by two intents, both approved by default:

To see the intents and confirm that they are approved, go to Topology > Intent.

Fabric Validation Workbench

The top section of the dashboard provides an at-a-glance status of overall fabric health. Check this section first to determine whether a violation is isolated or affecting a significant fraction of the fabric.

Health Score

Current Fabric Score (5 min): A summary tile showing the current fabric health score as a percentage (0–100). The score is calculated as the percentage of fabric devices that are free of active violations. A score of 100 means no devices are currently affected; a lower score indicates that some fraction of devices have at least one active violation. If inventory data is unavailable, the score is shown as unavailable rather than assumed healthy.

Fabric Score Trend (24h): A line chart of the fabric health score over the past 24 hours. Use it to determine whether current violations are new or have been persistent, and to confirm that remediation actions are driving the score upward.

Inventory | Devices: A line chart showing the count of fabric devices being tracked over time. Use it to confirm that all expected switches are reporting and to catch management-plane gaps that would cause the health score to be computed on an incomplete device set.

Active State

Recent Validation Events: A table of active violations listing pod, role, device name, interface, peer device, peer interface, violation class, and plane. This is the primary triage table — sort by violation class or pod to identify the scope of an issue before opening fault-domain views.

Switch Link Status: A summary table showing how many devices are currently affected by each link-layer violation class (Interface Down, LLDP Missing, Speed Mismatch, MTU Mismatch). Use it for an immediate count of affected devices before drilling into per-device detail.

All BGP Sessions: A summary table showing the count of devices affected by BGP failures. Use it alongside Switch Link Status to separate link-layer faults from routing-protocol faults.

Trends

Validation Events: A 24-hour line chart showing the count of validation events over time, broken out by violation class. Use it to confirm whether a spike is still active or has already cleared, and to distinguish a single event from a recurring or spreading condition.

Highest Risk Devices: A ranked table of devices by total active violations, including pod, role, device name, and the dominant violation class. Use it to identify which individual switches to inspect first when violations span multiple devices.

Fault-Domain Summary

This row of three widgets sits between the workbench and the fault-domain heatmaps. It translates active violation counts into topology-level risk scores so you can assess blast radius before drilling into per-class detail.

Pod Risk: A table ranking pods by the number of affected devices. A pod with many affected devices warrants immediate attention; isolated single-device violations are lower priority.

Plane Health: A bar chart of per-plane health scores over time. A plane score below 100 indicates that at least one device on that plane has an active violation. Diverging scores across planes suggest a plane-specific structural issue rather than a fabric-wide condition.

Role Risk: A table ranking device roles (leaf, spine, superspine) by the number of affected devices. A high role risk on spine switches typically has broader impact than the same violation count on leaf switches. Devices without an assigned role are excluded from Fabric Validation and do not appear in this table.

AIOps Fault-Domain Analysis

Pod, role, and plane views localize blast radius beyond per-device symptoms and help you separate localized interface faults from broader role-tier risk.

Pod x Violation: A heatmap with pods on one axis and violation classes on the other. A bright cell indicates that a specific pod has concentrated violations of a particular class. Use it when violations span many devices to determine whether the issue is pod-specific.

Top Pods: A bar chart showing violation counts by pod over time. Use it to confirm whether a pod-specific spike is new or has been recurring.

Plane x Interface: A heatmap with planes on one axis and violation classes on the other. A bright cell on a specific plane and class indicates a plane-local structural condition. Use it alongside Plane Health to confirm whether a plane score drop corresponds to a specific violation type.

Role x Violation: A heatmap with device roles on one axis and violation classes on the other. Use it to determine whether a violation class is concentrated in one tier (for example, speed mismatches only at the spine) or distributed across the fabric.

Validation Classes

Use these class-specific charts to confirm whether a condition is persistent, spreading, or clearing after remediation. Each chart shows a count of affected devices over time, broken down by individual device or device pair.

Interface Down: A bar chart of operationally down interfaces per device over time. A sustained bar on a single device indicates a hardware or cabling issue at that switch. A spike across many devices simultaneously may indicate a fabric-wide event such as a power disruption.

• On OTLP-fed interfaces, administrative status may not be present in the telemetry stream. When admin status is absent, Fabric Validation treats it as UP. An interface that has been intentionally admin-downed for maintenance and is also operationally down can therefore still raise an Interface Down violation, even though the outage is expected. During planned maintenance windows, suppress or acknowledge Interface Down violations on intentionally admin-down ports to avoid false escalations.

LLDP Missing: A bar chart of missing LLDP neighbors per device over time. LLDP absence on an otherwise operationally up interface can indicate a configuration mismatch or a silent link failure where the physical layer is up but no protocol traffic is exchanged.

Speed Mismatch: A bar chart of speed-mismatched link endpoints, shown as device pairs. A persistent mismatch on the same pair of devices indicates a configuration or hardware inconsistency that is unlikely to self-resolve.

MTU Mismatch: A bar chart of MTU-mismatched link endpoints, shown as device pairs. MTU mismatches on fabric links can cause silent packet fragmentation or discard for large frames and should be resolved before workloads begin.

BGP Not Established: A bar chart of devices with BGP sessions that have not reached the Established state, shown per device over time. A single device with persistent BGP failures may have a routing configuration issue; multiple devices failing simultaneously may indicate a fabric-wide routing disruption.

Last updated: October 21, 2026