MSP Pilot Test Plan - Backbone Use Cases (Phase 2)

Overview

This test plan defines 30+ test cases for the Graphiant private backbone, deployed under an MSP account within the Graphiant portal inside a simulated lab environment (hosted on KVM, ESXi, or Proxmox hypervisors).

Topology Configuration:

• Points of Presence (PoPs) & Gateways: The architecture features three simulated PoPs, with at least two hosting dedicated Gateway (GW) infrastructures to simulate cloud on-ramp, multi-cloud, and third-party interconnect use cases. End-customer site devices (edges) are provisioned across two distinct enterprises under the MSP account within each PoP region.

• Edge Terminators (ETs): Serving as the stateless core devices of the private backbone, ETs are deployed in pairs per region. A regional PoP footprint is collectively represented by its stateless core ET pair combined with its GW infrastructure.

Traffic & Connection Flow: Upon ET activation within the MSP account, all underlying enterprise edge devices automatically establish connections, homing directly to their corresponding regional stateless backbone core ETs.

The test cases covered in this document are broadly categorized into the following sections:

1. Backbone Provisioning & Life-Cycle

2. Backbone HA & Resiliency

3. Backbone Monitoring & Troubleshooting

4. Backbone Security & Performance

Scope and Responsibilities

Use this table to keep track of your pilot test plan progress:

Marketplace Subscription and Registration

Subscribe to Graphiant's Pay-as-you-go offering in AWS Marketplace​, click here for instructions.

Topology

Topology Overview

The Graphiant private backbone is distributed across three simulated, geographically distinct Points of Presence (PoPs) in the West, Central, and East regions. Each regional PoP houses a pair of stateless core devices Edge Terminators (ETs) that establish the foundation of the backbone network.

Lab Internet Firewall Requirements:

To ensure proper connectivity to the Graphiant management, control, and data (backbone) planes, the lab environment's Internet firewall must permit outbound traffic for the specific IP addresses and ports listed in the Graphiant Service IPs and Ports for Firewall Rules

Backup Strategy and PoP Redundancy

• West PoP (PoP-0): Primary region. First backup is Central PoP, second backup is East PoP.

• Central PoP (PoP-1): Hub region. First backup is East PoP, second backup is West PoP.

• East PoP (PoP-2): Primary region. First backup is Central PoP, second backup is West PoP.

This backup strategy ensures that if a primary PoP fails, traffic is automatically rerouted to the designated backup PoPs in order of preference.

Enterprise and Edge Device Configuration

The MSP hosts 2 enterprises with distributed edge devices across the regions.

Enterprise-1:

• 3 edge devices (Edge-1, Edge-2, Edge-3)

• Location: West region (2 edges, dual homed) and Central region (1 edge)

• Devices connect to their respective local PoPs with redundancy to backup PoPs

Enterprise-2:

• 2 edge devices (Edge-1, Edge-2)

• Location: Central region (1 edge) and East region (1 edge)

• Devices connect to their respective local PoPs with redundancy to backup PoPs

Multi-WAN Edge Connectivity (Central Region):

• Central region edge devices are configured with 2 WAN interfaces to demonstrate advanced multi-path connectivity

• Each WAN interface on a central edge device provides independent connectivity paths

• WAN Interface 1: Connects to the active Central PoP (primary connection)

• WAN Interface 2: Connects to the corresponding backup PoP (secondary connection for redundancy and load balancing)

• This configuration allows testing of link failover, load distribution, and multi-path resilience across WAN interfaces

Traffic Hosts and Simulation

Traffic hosts deployed behind the gateways (GW-0 and GW-1) simulate cloud-hosted applications and services, enabling testing of backbone connectivity to cloud resources. Traffic hosts connected behind the edge devices can generate traffic for both site-to-site and site-to-cloud connectivity scenarios, allowing validation of end-to-end data flows across the backbone infrastructure.

Network Architecture Details

PoP Regions:

• PoP-0 (West): Located in Azure and AWS clouds

• PoP-1 (Central): Centrally positioned backbone hub

• PoP-2 (East): Located in Azure and AWS clouds

Core Devices per PoP:

• Each PoP contains 2 core devices deployed as a pair for redundancy

• ET-0 and ET-1 are the two core devices in each region

• Within each region, ET-0 and ET-1 are directly connected to each other

Mesh Connectivity Across PoPs:

• ET-0 Full Mesh: All ET-0 devices across the three PoPs are fully meshed — direct connectivity between West ET-0, Central ET-0, and East ET-0

• ET-1 Full Mesh: All ET-1 devices across the three PoPs are fully meshed — direct connectivity between West ET-1, Central ET-1, and East ET-1

Gateway (GW) Deployment:

• 2 Gateways (GW-0 and GW-1) deployed in at least 2 PoPs (West and East regions in this topology)

• Gateways provide additional routing and traffic management capabilities

WAN Connectivity:

• Each core device has 2 WAN connections (wan-1 and wan-2) for enhanced redundancy and load balancing

• All WAN connections converge through the Internet cloud

Enterprise Edge Integration:

• Enterprise edges (Edge-1, Edge-2, etc.) in each region connect to the local ET-0 and ET-1 core devices

• Edges automatically register with and connect to the geographically nearest core pair in their region

• Multi-region enterprise sites have redundant connectivity paths through the backbone mesh

ET-to-ET Connectivity

Detailed topology diagram showing ET-to-ET connections and mesh architecture across all PoPs:

Automation

Documentation:

• Automation

• Graphiant Playbooks

• Graphiant NaaS Ansible Community Documentation

About Graphiant Backbone Health Dashboard

The Backbone Health Dashboard provides real-time visibility into the operational status and performance of the entire Graphiant backbone infrastructure. It aggregates metrics from all PoPs, core devices, gateways, and connected enterprise edges to enable proactive monitoring and rapid issue detection.

Test Case Summary

Total: 30+ test cases

Test Cases

TC-01: Create private backbone regions

Objective: Create 3 regions (West, Central, East) with backup assignments.

Pre-conditions: MSP admin access, no regions exist.

Expected Result: All regions created with correct backup configuration. Status: Active.

TC-02: Onboard ET devices

Objective: Onboard 6 ET devices (WC-01, WC-02, CC-01, CC-02, EC-01, EC-02).

Pre-conditions: TC-01 complete, hardware available.

Expected Result: All 6 cores in Staging status (2 per region).

TC-03: Onboard Gateway devices

Objective: Onboard 4 gateways (GW-01/02 West, GW-03/04 East).

Pre-conditions: TC-02 complete.

Expected Result: 4 gateways in Staging (West: 2, East: 2, Central: 0).

TC-04: Configure ET devices via API

Objective: Push config to all 6 ETs via API (PUT). Move to Active status.

Automation:

• Graphiant Playbooks

Pre-conditions: TC-02 complete, admin API token.

Expected Result: All 6 cores Active, interfaces Up, config persists.

TC-05: Configure GW devices via API/GUI

Objective: Configure all 4 GWs via portal (hostname, WAN, peer, BGP).

Automation:

• Graphiant Playbooks

Pre-conditions: TC-03 complete.

Expected Result: All 4 GWs configured, Online, BGP Established.

TC-06: Site devices onboarding and connectivity to ETs in Canary mode

Objective: ETs in Canary mode. Canary-enabled edges connect; non-canary edges cannot.

Automation:

• Graphiant Playbooks

Pre-conditions: TC-04/05 complete.

Expected Result: 3 canary edges connected, 1 non-canary isolated.

TC-07: Site devices connectivity to ETs when ETs are moved out of canary mode

Objective: Disable Canary on ETs and edges. Verify standard connectivity.

Automation:

• Graphiant Playbooks

Pre-conditions: TC-06 complete.

Expected Result: All edges connected in standard mode. Monitoring shows connectivity.

TC-08: ET device life cycle active/staging/maintenance

Objective: Demonstrate lifecycle state transitions. Staging isolates connectivity, Maintenance suppresses alarms, Deactivated removes ET from data plane.

Pre-conditions: TC-04 complete, MSP admin portal access.

Expected Result: Each lifecycle state behaves as designed.

TC-09: ET device upgrade

Objective: Demonstrate PoP-level redundancy during a software upgrade. Verify failover and automatic reconnection to upgraded ET.

Pre-conditions: TC-07 complete. New software version available. Continuous traffic Host-1 → Host-2.

Expected Result: Automatic failover during upgrade. WC-01 running new version.

TC-10: ET device as transit only

Objective: Demonstrate pure transit routing via Central PoP with WAN interfaces disabled. All changes reverted at end.

Pre-conditions: TC-07 complete. edge-1 → West PoP, edge-2 → East PoP. Direct West-East connectivity active. Continuous traffic Host-1 → Host-2.

Part A: Baseline – Direct West-East Path

Part B: Test Setup

Part C–D: Transit Verification

Part E: Revert

Expected Result: Central forwards transit with WAN Down. All changes reverted. System matches baseline.

TC-11: Moving site device from one region to another region

Objective: Demonstrate make-before-break region move via portal. edge-1 moves West → Central while traffic flows to edge-2 in East.

Pre-conditions: TC-07 complete. edge-1 in West, edge-2 in East. All 3 regions active. Continuous traffic Host-1 → Host-2.

Part A: Baseline – edge-1 in West

Part B–C: Region Move and Re-optimization

Part D–E: Verify and Post-Move

Expected Result: Make-before-break confirmed. Minimal traffic disruption. Portal correctly reflects Central region assignment.

TC-12: End to end connectivity within the same PoP

Objective: 2 edges same PoP (West). Ping successful.

Pre-conditions: TC-07 complete.

Expected Result: Host A ↔ Host B connectivity verified. Traffic continues to flow, consistent latency.

TC-13: End to end connectivity between the PoPs and across multiple PoPs

Objective: 2 edges different PoPs (West, East). Demonstrate alternate routing through Central when West-East link down.

Pre-conditions: TC-12 complete.

Expected Result: Direct path 30-50ms, alternate path 55-65ms, failover <15sec.

TC-14: ET to ET connectivity over IPSec tunnel

Objective: Demonstrate ET-to-ET connectivity over an IPSec tunnel as an alternative to direct point-to-point circuits.

Pre-conditions: TC-07 complete. All ET devices in Active status. Direct point-to-point circuit between WC-01 and CC-01 either unavailable or disabled. Both ETs have WAN connectivity over Internet.

Use Case: Direct point-to-point circuits between ETs may not be available, take too long to provision, or be too expensive. IPSec tunnels over Internet WAN provide an alternative backbone link.

Expected Result: IPSec tunnel successfully established between WC-01 and CC-01. Backbone traffic flows continuously through tunnel without loss. Tunnel provides functional alternative to direct point-to-point circuit.

TC-15: ET device reboot

Objective: Demonstrate PoP-level redundancy when a ET reboots. Verify failover to backup ET and automatic reconnection on recovery.

Pre-conditions: TC-07 complete. Continuous traffic Host-1 → Host-2.

Expected Result: Automatic failover and reconnection. Traffic continues throughout.

TC-16: ET wan interface flap

Objective: Demonstrate ET WAN interface redundancy. Verify failover to alternate path and automatic reconnection on recovery.

Pre-conditions: TC-07 complete. WC-01 has WAN-1 and WAN-2. Continuous traffic Host-1 → Host-2.

Expected Result: Automatic failover and reconnection on WAN-1 recovery.

TC-17: All ET wan interfaces flap

Objective: With both WAN interfaces on WC-01 down, verify failover to WC-02 and automatic reconnection on full WAN recovery.

Pre-conditions: TC-07 complete. WC-01 has WAN-1 and WAN-2. Continuous traffic Host-1 → Host-2.

Expected Result: Failover to WC-02. Reconnection to WC-01 on full recovery.

TC-18: ET to ET interface down

Objective: Demonstrate inter-PoP link redundancy when an ET-to-ET interface fails. Verify site-to-site traffic reroutes through alternate ET pair paths.

Pre-conditions: TC-07 complete. Enterprise-1 deployed with edge-1 (West) and edge-2 (Central) connected to their local PoPs with redundancy to backup PoPs. Host-A behind edge-1, Host-B behind edge-2. Continuous traffic Host-A ↔ Host-B.

Expected Result: Alternate paths absorb traffic seamlessly. Inter-PoP link failure does not isolate PoPs. Traffic continues to flow post-convergence via alternate paths. Direct path latency restored on recovery.

TC-19: ET device power down

Objective: Demonstrate PoP resilience during extended ET outage. WC-02 sustains traffic; edge reconnects automatically on recovery.

Pre-conditions: TC-07 complete. Continuous traffic Host-1 → Host-2.

Expected Result: WC-02 sustains traffic throughout. Automatic reconnection on recovery.

TC-20: Entire PoP power down

Objective: Demonstrate cross-PoP redundancy when entire West PoP goes down. Active tunnel remains down until West recovers; edge auto-restores active tunnel on recovery.

Pre-conditions: TC-07 complete. edge-1 active to West PoP, backup to Central PoP. Continuous traffic Host-1 → Host-2.

Expected Result: Cross-PoP failover. Active tunnel auto-restored on West PoP recovery.

TC-21: Verify WAN failover on Edge to ET WAN link loss

Objective: Demonstrate class-based WAN failover triggered by loss/latency thresholds. Verify that application traffic classified as Gold, Silver, or Bronze switches to the secondary WAN interface when quality degradation exceeds the threshold for its class, and reverts when the degradation is removed.

Pre-conditions: TC-07 complete. Enterprise-1 and Enterprise-2 deployed. Edge-3 (one enterprise) and Edge-1/Edge-2 (other enterprise) active with dual WAN interfaces. Traffic policies configured to classify application traffic into Gold (low-latency, low-loss tolerance), Silver (moderate tolerance), and Bronze (best-effort) classes. Continuous multi-class traffic flowing from Edge-3 host to Edge-1/Edge-2 hosts.

Traffic Class Thresholds: Gold: <10ms latency, <0.1% loss. Silver: <30ms latency, <1% loss. Bronze: <100ms latency, <5% loss. When a WAN link's loss/latency exceeds a class threshold, only traffic of that class switches to the alternate WAN. Other classes continue via the degraded link if their thresholds are not exceeded.

Expected Result: Class-based thresholds trigger selective WAN failover. Traffic within thresholds continues via primary WAN; traffic exceeding thresholds switches to secondary. All classes revert to primary WAN when conditions normalize. Failover/reversion is transparent to applications.

TC-22: Edge WAN interface down

Objective: Demonstrate edge dual-WAN load balancing and single-WAN failover. On recovery, tunnels re-established and load balancing resumes automatically.

Pre-conditions: TC-07 complete. edge-1 has two WAN interfaces with active and backup tunnels. Continuous traffic Host-1 → Host-2.

Expected Result: Automatic failover and load balancing restoration.

TC-23: Walkthrough backbone health dashboard

The Backbone Health Dashboard provides real-time operational visibility across the entire backbone infrastructure. It is accessible via the Graphiant portal and comprises five main areas, each offering a different level of health and performance detail.

Part A: Backbone Health Overview

• Infrastructure Node Count: Total node count in a circular ring chart, color-coded by health status.

• Health Status Counters: Healthy (green), Suboptimal (yellow), Unhealthy (red), Maintenance (purple), Unreachable (grey). A fully operational backbone shows all nodes Healthy.

• Device Treemap: Visual grid where each tile represents an infrastructure node. All-green confirms all devices healthy.

• Dashboard Tabs: Overview, ET, Portal, and Control tabs for scoped views. Alert Categories dropdown filters by alarm type.

• Last Updated Timestamp: Auto-refreshing with exact collection time.

Part B: Monitor Devices

• Device Type Tabs: ETs, Edges, T2s, and ODPs — each showing device count.

• ETs Table Columns: Hostname, Connectivity Status, Software version, Site, Region, Uptime. Clicking a hostname opens per-device drill-down.

• Consistency Check: Consistent software versions confirm uniform release state. Uptimes flag unexpected reboots.

• Search and Pagination: Filter by hostname or region; paginate for large inventories.

Part C: ET-ET Matrix

• Region Grid: Each cell represents inter-region ET-to-ET health. All-green confirms no inter-region issues.

• View Tabs: Summary, QoE & Latency, and Loss & Jitter tabs.

• Cell Hover Tooltip: Loss, Latency, and Jitter per region pair.

• Per-ET-Pair Drill-Down: Individual ET-to-ET metrics per region pair.

Part D: ET-WAN Matrix

• Region List: Collapsible rows per region with green checkmark when all WAN connections healthy.

• Expanded Region View: Per-ET table showing health per ISP/circuit provider.

• QoE Status Column: Aggregated WAN quality signal for the entire region.

• ISP-Level Fault Isolation: Degraded cells turn yellow/red — pinpoints specific ET and ISP without direct device access.

Part E: Per-Device Drill-Down

• Device Header: Hostname, health badge, SW Version, Up Since, time-range selector.

• Issues Tab: Active and historical issues. "No issues found" confirms clean status.

• System Tab: CPU/Memory/Disk chart plus Up Time, Last Reboot Reason, Crashes, Temperature.

• Data Plane, Control Plane, QoE Matrix Tabs: Deeper per-device diagnostics.

• Device Troubleshooting Link: Launches CLI-level diagnostics from the portal.

TC-24: Alarms / Notification management

The Alarms section of the Graphiant portal provides a comprehensive alarm and notification framework for the backbone, organized into four tabs: Alarms, Notification Management, Rules, and Excluded Entities.

Part A: Alarms Tab

• Alarm List: Displays backbone alarms matching the selected time range. A healthy backbone shows "No alarms."

• Active / Cleared Toggle: Filter between currently firing and auto-resolved alarms.

• Time Range Selector: Past 5 minutes, Past 15 minutes, Past 30 minutes, Past hour, Past 4 hours, Past day, Past 2 days, Past week, Past month, and Custom Range.

• Last Updated Timestamp: Shows last refresh time with manual refresh button.

Part B: Notification Management Tab

• Notifications Summary Chart: Donut chart showing total notifications triggered (e.g., 405 time-triggered), color-coded by notification type.

• Per-Notification Breakdown: Trigger count per type — e.g., Master Notification: 359, ET to ET Loss Beyond High Threshold: 27, ET to ET Loss Beyond Critical Threshold: 19.

• Add Notification Button: Opens the notification creation form.

Part C: Creating a Notification

• Enable Toggle, Name, Description: Enable/disable without deleting; identify and describe the policy.

• Condition – Alarm Type: Dropdown to select the triggering alarm type.

• Suppress After and Evaluation Window: Controls occurrence threshold and evaluation window (e.g., 5 minutes).

• Action: Send an Email: Recipient addresses plus optional custom message.

• Action: Send Additional Notification: Teams and OpsGenie integration dropdowns.

Part D: Rules Tab

• Rule Count: 100 predefined rules covering all major infrastructure health dimensions.

• Table Columns: Plane, Category, Alarm-Set condition, Alarm-Clear condition, Priority (P1/P2), Excluded Entities count.

• Rule Enable/Disable Toggle: Per-rule on/off without removing the rule.

• Examples: CPU/memory/disk at 85% = P2, at 95% = P1. Device to Portal Down, Choppy WAN Link = P2. Pagination across 5 pages.

Part E: Excluded Entities Tab

• Entity Count: Total active exclusions (e.g., 192 items).

• Table Columns: Device, Alarm-set Rule, Notes, Entity Details (Site, Device, Interface, Lan Segment, Enterprise, Peer, Peer Interface tags).

• Exclusion Context: Entity Details tags make the suppressed alarm path explicit.

• Search: Filter by device name, rule, or notes.

TC-25: MSP backbone topology view

The MSP Backbone Topology View gives the MSP admin a visual representation of the backbone via the Graphiant portal. The view adapts based on whether the MSP account has ETs deployed — and when ETs are present, it shows inter-PoP latency and a historical record of path changes over configurable time windows.

Part A: Viewing the Graphiant Backbone (No MSP ETs Deployed)

• Global Backbone Visibility: All Graphiant-operated PoPs and the interconnections between them are visible, even before any customer ETs have been provisioned.

• PoP Locations: Each Graphiant PoP is represented as a geographically positioned node, identifying which regions are available for ET deployment.

• Backbone Interconnects: Links between PoPs show how the Graphiant backbone is interconnected across regions.

Part B: Viewing MSP PoPs (With ETs Deployed)

• MSP PoP Nodes: Each region where the MSP has deployed ETs appears as a PoP node — for example, West, Central, and East regions each represented on the map.

• PoP-to-PoP Connectivity: Links between MSP PoPs reflect the actual inter-PoP connections established by the deployed ETs.

• Node Detail: Clicking or hovering on a PoP node surfaces the number of active ETs, their health status, and the region name.

Part C: Inter-PoP Latency

• Latency Labels on Links: Each link displays the measured latency between the two PoPs it connects (e.g., West ↔ Central: 12ms, West ↔ East: 45ms, Central ↔ East: 38ms).

• Latency-Based Coloring: Links may be color-coded by latency health — green for nominal, yellow for elevated, red for degraded.

Part D: Path Changes

• Path Change Log: Events where traffic paths between PoPs changed are recorded with the affected PoP pair, time, and trigger.

• Time Range Selection: Last 24 hours, Last 2 days, and Last 1 week lookback windows.

• Contextual Value: Useful after a backbone event to confirm routing reconverged correctly and no unexpected path changes persisted.

TC-26: Throughput and traffic profile performance (Site-to-Site and Site-to-Cloud)

Objective: Verify backbone performance and traffic handling under different traffic profiles — steady-state, bursty, and mixed patterns — across both site-to-site and site-to-cloud connectivity. Measure throughput, latency, jitter, and loss under varying traffic conditions.

Pre-conditions: TC-07 complete. Enterprise-1 deployed with Edge-1 (West) and Edge-2 (Central). Enterprise-2 deployed with Edge-3 (East). Gateways GW-0 and GW-1 deployed with traffic hosts behind them. Traffic generation tools (iperf, custom traffic generators) available for creating different traffic profiles. Monitoring tools available for real-time metric collection.

Traffic Profiles: Steady-State: Constant bitrate (e.g., 100 Mbps continuous stream for 60 seconds). Bursty: Traffic bursts (e.g., 500 Mbps bursts of 5 seconds followed by 5 second silence, repeated). Mixed: Combination of steady + bursty (e.g., 100 Mbps baseline + 300 Mbps bursts every 10 seconds).

Metrics to Monitor: Throughput (achieved bitrate vs. requested), Latency (min/avg/max RTT), Jitter (standard deviation of latency), Packet Loss (percentage per profile), Convergence Time (time to reach steady-state latency after burst onset).

Expected Result: Backbone handles steady-state, bursty, and mixed traffic profiles without packet loss. Throughput achieved as requested. Latency and jitter within nominal ranges. Site-to-site and site-to-cloud performance consistent. Concurrent multi-path traffic shows no interference.

TC-27: Data exchange across enterprises (B2B)

Objective: Verify enterprise routing table isolation by default, controlled inter-enterprise traffic via peering policy, and full isolation restoration on policy deletion.

Automation:

• Graphiant Playbooks

Pre-conditions: All ETs Active, multiple enterprise edges deployed, no existing peering policies.

Part A: Enterprise Route Isolation Verification (Default State)

Expected Result (Part A): Complete route table isolation confirmed.

Part B: Backbone Peering Policy Configuration

Expected Result (Part B): Peering policy Active. Firewall zone-pair rules configured.

Part C–F: Route Visibility, Traffic Testing, Policy Removal, Re-apply

Expected Result: Full peering lifecycle demonstrated. Isolation restored on deletion.

TC-28: Secure cloud on-ramp and multi-cloud connectivity with MACsec

Objective: Demonstrate GW LAG creation with MACsec via portal. Verify LACP negotiation, MACsec session, IP addressing, and encrypted traffic.

Automation:

• Graphiant Playbooks

Pre-conditions: TC-05 complete. GW has ≥2 physical LAN interfaces. Cloud-side supports LAG and MACsec. CAK/CKN prepared.

Part A: Baseline

Part B: GW LAG Configuration via Portal

Part C: Cloud-Side Configuration

Part D–E: Verify LACP, MACsec, BGP, Traffic

Expected Result: LACP Up, MACsec Secured, BGP Established, encrypted traffic confirmed.

TC-29: End-to-end connectivity with PQC

Objective: Demonstrate that an enterprise admin can enable Post-Quantum Cryptography (PQC) for an entire enterprise via the Graphiant portal, and verify that end-to-end dataplane connectivity is maintained after PQC is enabled. PQC protects the dataplane tunnels against quantum-computing threats by upgrading the key exchange mechanism used in the encryption negotiation. The setting is applied enterprise-wide — all edges and their tunnels within the enterprise adopt PQC-protected encryption upon enablement.

Pre-conditions:

• TC-07 complete — all ETs Active, edges Online

• At least two edges in the same enterprise deployed in different regions (e.g., edge-1 in West, edge-2 in East), each with a host behind them

• Continuous traffic stream (e.g., ping or iperf) running between Host-1 (behind edge-1) and Host-2 (behind edge-2)

• Enterprise admin portal access with permission to modify enterprise security settings

• PQC is currently disabled for the enterprise (baseline state)

Part A: Baseline Traffic Verification – PQC Disabled

Expected Result (Part A): Traffic flows continuously. PQC confirmed Disabled. Dataplane tunnels operating with standard encryption.

Part B: Enable PQC for the Enterprise

Expected Result (Part B): PQC enabled enterprise-wide. Tunnels renegotiate with PQC-protected key exchange. Any disruption is brief. Portal reflects PQC Enabled.

Part C: Verify End-to-End Dataplane Connectivity with PQC Active

Expected Result (Part C): Edge tunnels re-established with PQC active. Traffic continues to flow. Acceptable throughput. Dataplane fully operational.

Part D: Verify PQC Encryption on Dataplane Tunnels

Expected Result (Part D): All tunnels show PQC-enabled encryption. No edge on legacy key exchange. Enterprise-wide PQC adoption confirmed.

Part E: Post-PQC Traffic Verification and Audit

Expected Result (Part E): Sustained traffic continues to flow. No residual alarms. Audit log records PQC enablement with full attribution and timestamp.

Monitoring / Verification:

• Portal Enterprise Security settings show PQC transitioning from Disabled to Enabled

• All enterprise edge tunnels renegotiate with PQC-protected key exchange upon enablement

• End-to-end dataplane connectivity maintained post-PQC enablement

• Tunnel security details reflect PQC-enabled encryption for all active tunnels

• No edge in the enterprise retains legacy (non-PQC) key exchange after enablement

• Dataplane throughput remains acceptable under PQC encryption

• Audit log captures PQC enablement event with enterprise admin account and timestamp

TC-30: Data assurance and sovereignty policies

Objective: Verify that a Flex Algo policy can be created to select a group of ETs to enforce end-to-end flow of traffic only through that selected group of ETs.

Pre-conditions: TC-07 complete. All ETs Active. Enterprise admin portal access.

Expected Result: Flex Algo policy enforces end-to-end traffic flow exclusively through the selected group of ETs. Traffic is blocked from traversing non-selected ETs. Policy removal restores default behavior.