MSP Pilot Test Plan

MSP Pilot Test Plan Overview

This test plan defines 50 end-to-end test cases for the Graphiant NaaS solution deployed under an MSP account in Graphiant portal, spanning two enterprises:

• Enterprise-1:  Three office sites — San Jose (us-west-2), Ashburn (us-east-1), Frankfurt (eu-central-1). Cloud direct connect (on-ramp) to Azure VPC and AWS VPC via the Gateway (GW) nodes at Chicago (us-central-1) PoP.

• Enterprise-2:  One office site — Tokyo (ap-east-1).

All configuration, monitoring, and verification is performed exclusively through the Graphiant portal UI or API.

Troubleshooting tools (ping, traceroute, packet capture, throughput test) are available within the portal.

Traffic between enterprises is only possible when a B2B Extranet peering policy is explicitly configured by the MSP administrator.

The portal monitoring view updates the data periodically.

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

PoP Reference

Sites

Key design points:

• The GW nodes sit at CH PoP and are dedicated to enterprise-1 for cloud on-ramp to Azure VPC and AWS VPC.

• The backbone interconnects all 11 POPs across AP, US, and EU regions.  

• Enterprise-1 has 2 sites.  

• Enterprise-2 has 1 site.

Automation

Documentation:

• Automation

• Graphiant Playbooks

• Graphiant NaaS Ansible Community Documentation

About Graphiant Data Assurance

Graphiant's Data Assurance service provides end-to-end visibility and precision control over data in motion across the entire network, built on four core capabilities:

Test Case Summary

Test Cases

TC-01 — Enterprise Onboarding:  Provision Enterprise-1 and Enterprise-2 Under MSP

Objective: Verify that both enterprise-1 and enterprise-2 can be successfully created and provisioned in the MSP portal as separate tenant enterprises, each with their own configuration space, user access scope, and policy isolation, prior to any Edge or GW deployment.

Pre-conditions:

• MSP admin account is active and accessible in the Graphiant portal

• enterprise-1 and enterprise-2 have not yet been created

• Required enterprise details are available: enterprise name, contact information, region scope, and subscription details

Steps:

1. Log into the Graphiant portal as the MSP administrator.

2. Navigate to the Enterprises section in the MSP portal.

3. Create a new enterprise named enterprise-1. Assign the correct subscription tier, region scope (US-West-2, US-East-1, EU-Central-1), and primary contact details. Save and confirm.

4. Verify enterprise-1 appears in the MSP portal enterprise list with status Active.

5. Create a new enterprise named enterprise-2. Assign the correct subscription tier, region scope (AP-East-1), and primary contact details. Save and confirm.

6. Verify enterprise-2 appears in the MSP portal enterprise list with status Active.

7. Log into the portal as an enterprise-1 user and confirm visibility is scoped to enterprise-1 only — enterprise-2 resources, policies, and routes are not visible.

8. Log into the portal as an enterprise-2 user and confirm visibility is scoped to enterprise-2 only.

9. Confirm in the MSP portal that both enterprises are independently listed under the MSP account with separate configuration namespaces.

Expected Result:  Both enterprise-1 and enterprise-2 successfully created with Active status. Each enterprise has its own isolated configuration namespace. Enterprise-level user access is correctly scoped with no cross-enterprise visibility. MSP admin can see and manage both enterprises.

Monitoring / Verification: MSP portal enterprise list shows enterprise-1 and enterprise-2 with Active status. Enterprise-scoped user logins confirm namespace isolation. No cross-enterprise resources visible under either enterprise account.

TC-02 — Enterprise Lifecycle:  Provision, Configure, Decommission

Objective: Verify that an enterprise can complete its full lifecycle: provisioning, configuration, and decommissioning through the Graphiant portal.

Pre-conditions:

• MSP admin access to Graphiant portal

• New enterprise ready to be provisioned

• Configuration parameters available

Steps:

1. Provision: Create new enterprise in MSP portal. Verify active status with unique namespace.

2. Configure: Assign subscription tier, contact information, region scope, and user access controls.

3. Operate: Add sites, devices, and configurations to enterprise. Verify all configurations take effect.

4. Monitor: View enterprise dashboard, monitoring, and alarms for entire enterprise.

5. Decommission: Remove all devices and routes. Delete enterprise from portal. Verify complete removal.

Expected Result:

• Enterprise successfully provisioned with Active status

• Enterprise fully configured with correct parameters

• All resources operational within enterprise

• Enterprise completely removed on decommissioning

• No orphaned configuration remains

Monitoring / Verification:

• Portal shows enterprise with Active status

• Enterprise configuration persisted and accurate

• Audit logs show provisioning and decommissioning events

TC-03 — Sites and LAN Segments (VRFs):  Creation in Enterprises

Objective: Verify that sites and LAN segments (VRFs) can be successfully created and provisioned for both enterprise-1 and enterprise-2 in the Graphiant portal, with correct site names, regions, and LAN segment associations, and that the two enterprises are completely isolated with no route leakage.

Pre-conditions:

• enterprise-1 and enterprise-2 are provisioned and Active in the MSP portal (TC-01 completed)

• Site device provisioning tokens are available for each site

• Required site details are available: Site Name, Region, LAN segment prefix, and enterprise association

• Network is ready to accept new site configurations

Steps:

1. Log into the Graphiant portal as the MSP administrator.

2. Create sites for enterprise-1:

   • Navigate to Sites section under enterprise-1

   • Create site "San Jose" in region us-west-2 (SJ POP)

   • Create site "Ashburn" in region us-east-1 (VA POP)

   • Create site "Frankfurt" in region eu-central-1 (FR POP)

3. Create site for enterprise-2:

   • Navigate to Sites section under enterprise-2

   • Create site "Tokyo" in region ap-east-1 (TK POP)

4. Verify all sites appear in the portal with correct regions and enterprise association.

5. Create LAN segments for enterprise-1:

   • Navigate to LAN Segments section under enterprise-1

   • Create a LAN segment (e.g. 10.1.0.0/16) and associate it with San Jose, Ashburn, and Frankfurt sites

   • Save and apply the LAN segment configuration

6. Create LAN segment for enterprise-2:

   • Navigate to LAN Segments section under enterprise-2

   • Create a LAN segment (e.g. 10.2.0.0/16) and associate it with the Tokyo site

   • Save and apply the LAN segment configuration

7. Verify enterprise-1 LAN segment is active on all three enterprise-1 sites and prefix is visible in the enterprise-1 route monitoring view.

8. Verify enterprise-2 LAN segment is active on the Tokyo site and prefix is visible in the enterprise-2 route monitoring view.

9. Confirm enterprise-2 prefix does NOT appear in enterprise-1 route table, and vice versa.

10. Verify no cross-enterprise route leakage in the portal route monitoring views.

11. Confirm no configuration errors or alarms are generated during site and LAN segment creation.

Expected Result:

• All sites successfully created with correct names, regions, and enterprise association (San Jose, Ashburn, Frankfurt for enterprise-1; Tokyo for enterprise-2)

• LAN segments created and correctly associated with their respective sites

• enterprise-1 LAN segment active on all three enterprise-1 sites

• enterprise-2 LAN segment active on Tokyo site only

• Complete route table isolation between enterprises with no leakage

• All configurations visible and accurate in the portal

Monitoring / Verification:

• Portal Sites list shows all 4 sites with correct names, regions, and enterprise associations

TC-04 — Site Device Onboarding:  Token/URL/QR Code-Based Device Onboarding and Staging; LWS Configuration, Monitoring and Troubleshooting

Objective: Verify that site devices can be successfully onboarded using multiple authentication methods (Token-based, URL-based, and QR code-based provisioning), with proper Local Web Server (LWS) configuration, and that monitoring and troubleshooting capabilities function correctly throughout the onboarding process.

Automation:

• Graphiant Playbooks

Pre-conditions:

• Site devices (hardware or VMs) are powered on with WAN connectivity

• Graphiant portal access with admin credentials

• LWS (Local Web Server) is accessible on devices

• Network connectivity to onboarding endpoints (onboarding-gw, stargate, T2, ODP, Core)

Steps:

Deploy the edges in different region using the Terraform script, link provided above under Automation.

Part A: Token-Based Device Onboarding

1. Log into the Graphiant portal and navigate to the device provisioning section

2. Generate an onboarding token via REST API endpoint (/v1/devices/bringup/token):

   • Provide the valid expiration timestamp in the payload

   • Receive the access token in the API response

3. Retrieve the bearer token from the portal

4. Apply the access token to the device configuration

5. Monitor the device status in the portal as it transitions through onboarding states

6. Verify the device appears as "Staging" in the portal

7. Confirm the device successfully authenticates with onboarding-gw and onboarding service

8. Verify the access token is consumed (single-use) after successful validation

Part B: URL-Based and QR Code-Based Onboarding

9. Log into the Graphiant portal and navigate to device onboarding section

10. Generate provisioning URL for a new device

11. Scan the QR code or copy the URL displayed in the portal or device console

12. Use the URL to authorize the device in a browser or scanning tool

13. Confirm the device transitions from Pending to Staging status

14. Verify proper notification or confirmation message after device authorization

Part C: LWS Configuration and Monitoring

15. Access the device's Local Web Server (LWS) via IP:port (e.g., https://device-ip)

16. Verify LWS UI displays current device status and configuration

17. Confirm LWS shows:

    • Device hostname and name configuration fields

    • WAN interface configuration options

    • System summary information

18. Verify LWS can push configuration to the device

19. Monitor device health indicators in LWS (connectivity, service status)

20. Test LWS connectivity testing tools to verify reachability to:

    • Portal Service

    • Control Plane service

    • Core / Dataplane service

Part D: Troubleshooting Verification

21. Use LWS UI to view device logs and connection status

22. Test device connectivity from LWS:

    • Verify services reachability status

    • Confirm network path validation

23. Simulate a connectivity issue (e.g., firewall block) and verify LWS can detect it

24. Verify error messages and diagnostic information are clear and actionable

25. Test LWS ability to collect and display system metrics during onboarding

Expected Result:

• Devices successfully onboarded via Token, URL, and QR code methods

• All three onboarding methods result in device appearing as "Staging" in portal

• Token is validated once and becomes invalid on re-use

• Invalid timestamps are rejected with clear error messages

• LWS UI is accessible and displays correct device information

• LWS can successfully push configuration to devices

• LWS connectivity testing tools identify connectivity issues accurately

• Device logs and troubleshooting information are accessible via LWS

• No configuration errors or alarms during onboarding process

TC-05 — Site device system summary configuration:  Hostname, Site Name, and Region

Objective: Verify that the site device System Summary configuration can be completed for each device via the Graphiant portal or Local Web Server (LWS), including setting the correct Hostname, Site Name (San Jose, Ashburn, Frankfurt, or Tokyo), and Region, and that these settings are correctly reflected in the portal and device after saving.

Pre-conditions:

• All 4 site devices are onboarded and showing as "Staging" in the portal (TC-04 completed for each device)

• enterprise-1 and enterprise-2 are provisioned and Active in the MSP portal (TC-01 completed)

• Devices have WAN connectivity to the nearest Graphiant POP

• MSP admin and user-level portal access available

• LWS (Local Web Server) is accessible on each device via HTTPS

Steps:

Part A: Configure San Jose Site Device (enterprise-1)

1. Log into the Graphiant portal as MSP administrator

2. Navigate to the San Jose site device under enterprise-1

3. Open the device System Summary configuration panel/tab

4. Set the Hostname field to a descriptive identifier (e.g., "edge-sanjose-01" or "sj-device-primary")

5. Set the Site Name dropdown/field to "San Jose"

6. Set the Region dropdown to "us-west-2" (SJ POP - San Jose)

7. Verify all three fields are populated with correct values

8. Click Save/Apply button

9. Monitor the portal for success confirmation message

10. Wait for configuration to be pushed to the device (observe status transitions)

11. Confirm the San Jose device System Summary in the portal reflects the updated values:

    • Hostname: edge-sanjose-01

    • Site Name: San Jose

    • Region: us-west-2 (SJ)

12. Verify device status remains "Online" or "Active" after configuration update

13. Confirm no configuration errors or alarms are generated after saving

Part B: Configure Ashburn Site Device (enterprise-1)

14. Navigate to the Ashburn site device under enterprise-1

15. Open the device System Summary configuration panel

16. Set Hostname to "edge-ashburn-01"

17. Set Site Name to "Ashburn"

18. Set Region to "us-east-1" (VA POP - N. Virginia)

19. Save and apply the configuration

20. Verify Ashburn device System Summary reflects:

    • Hostname: edge-ashburn-01

    • Site Name: Ashburn

    • Region: us-east-1 (VA)

21. Confirm no configuration errors or alarms after save

Part C: Configure Frankfurt Site Device (enterprise-1)

22. Navigate to the Frankfurt site device under enterprise-1

23. Open the device System Summary configuration panel

24. Set Hostname to "edge-frankfurt-01"

25. Set Site Name to "Frankfurt"

26. Set Region to "eu-central-1" (FR POP - Frankfurt)

27. Save and apply the configuration

28. Verify Frankfurt device System Summary reflects:

    • Hostname: edge-frankfurt-01

    • Site Name: Frankfurt

    • Region: eu-central-1 (FR)

29. Confirm no configuration errors or alarms after save

Part D: Configure Tokyo Site Device (enterprise-2)

30. Log into the Graphiant portal as enterprise-2 user or MSP admin

31. Navigate to the Tokyo site device under enterprise-2

32. Open the device System Summary configuration panel

33. Set Hostname to "edge-tokyo-01"

34. Set Site Name to "Tokyo"

35. Set Region to "ap-east-1" (TK POP - Tokyo)

36. Save and apply the configuration

37. Verify Tokyo device System Summary reflects:

    • Hostname: edge-tokyo-01

    • Site Name: Tokyo

    • Region: ap-east-1 (TK)

38. Confirm no configuration errors or alarms after save

Part E: Portal Verification and Dashboard Visibility

39. Navigate to the portal Site Health Dashboard

40. Verify all 4 devices are listed with correct Site Names:

    • enterprise-1: San Jose, Ashburn, Frankfurt

    • enterprise-2: Tokyo

41. Confirm each device displays the correct Region in the dashboard:

    • San Jose → us-west-2 (SJ)

    • Ashburn → us-east-1 (VA)

    • Frankfurt → eu-central-1 (FR)

    • Tokyo → ap-east-1 (TK)

42. Open the Route Monitoring view and verify each device's region assignment is reflected in the topology

43. Verify no cross-enterprise configuration (enterprise-1 devices do not appear under enterprise-2 and vice versa)

Expected Result:

• All 4 site devices successfully configured with correct:

  • Hostnames: edge-sanjose-01, edge-ashburn-01, edge-frankfurt-01, edge-tokyo-01

  • Site Names: San Jose, Ashburn, Frankfurt, Tokyo (correct for respective enterprises)

  • Regions: us-west-2 (SJ), us-east-1 (VA), eu-central-1 (FR), ap-east-1 (TK)

• Portal Site Health Dashboard displays all devices with correct site names and regions

• All devices remain "Online" or "Active" status after configuration updates

• No configuration errors or alarms generated during System Summary configuration

• Configuration changes propagated successfully to all devices

• Device region assignments correctly reflect topology in Route Monitoring view

• Enterprise isolation maintained (no cross-enterprise configuration)

TC-06 — Site Device Activation:  Verify All Devices Active and Tunnels Established

Objective: Verify that all 4 site devices are fully activated in the Graphiant network after System Summary configuration, with Graphiant tunnels successfully established to their nearest POPs and the devices appearing as "Active" or "Online" in the portal, ready for service configuration and traffic forwarding.

Pre-conditions:

• All 4 site devices have completed System Summary configuration (TC-05 completed for each device)

• Each device has WAN connectivity to its nearest Graphiant POP

• Devices are showing "Staging" or "Pending Activation" status in the portal

• All four devices are powered on and have network connectivity

• Graphiant portal is accessible with MSP admin credentials

• No firewall blocks between devices and Graphiant infrastructure

Steps:

Part A: Pre-Activation Verification

1. Log into the Graphiant portal as MSP administrator

2. Navigate to the Site Health Dashboard

3. Verify current device status before activation:

   • San Jose device status:  "Staging" or "Pending Activation"

   • Ashburn device status:  "Staging" or "Pending Activation"

   • Frankfurt device status:  "Staging" or "Pending Activation"

   • Tokyo device status:  "Staging" or "Pending Activation"

4. Record baseline status and timestamps

5. Navigate to each device's configuration page and confirm System Summary is complete with correct values

Part B: Activate San Jose Device (enterprise-1)

6. Navigate to the San Jose site device under enterprise-1

7. Locate the "Activate" or "Enable" button/action

8. Click the Activate button to initiate device activation

9. Monitor the portal as device status transitions:

   • "Staging" → "Activating" → "Online" or "Active"

10. Wait for the activation process to complete (typically 2-5 minutes)

11. Verify the San Jose device status now shows:

    • Status: "Online" or "Active"

    • WAN Interface: "Up" or "Connected"

    • LAN Interface: "Up"

    • Tunnel Status: "Established" to SJ POP

12. Record the tunnel establishment timestamp

13. Verify no errors or warnings in device status panel

14. Check that the device appears in the backbone topology view

Part C: Activate Ashburn Device (enterprise-1)

15. Navigate to the Ashburn site device under enterprise-1

16. Click the Activate button

17. Monitor status transitions until Ashburn shows:

    • Status: "Online" or "Active"

    • WAN Interface: "Up"

    • LAN Interface: "Up"

    • Tunnel Status: "Established" to VA POP

18. Verify tunnel latency and uptime metrics are displayed

19. Confirm no configuration errors after activation

Part D: Activate Frankfurt Device (enterprise-1)

20. Navigate to the Frankfurt site device under enterprise-1

21. Click the Activate button

22. Monitor status transitions until Frankfurt shows:

    • Status: "Online" or "Active"

    • WAN Interface: "Up"

    • LAN Interface: "Up"

    • Tunnel Status: "Established" to FR POP

23. Verify tunnel connection to EU POP is established

24. Confirm no configuration errors after activation

Part E: Activate Tokyo Device (enterprise-2)

25. Log out and log back in as enterprise-2 user or continue as MSP admin

26. Navigate to the Tokyo site device under enterprise-2

27. Click the Activate button

28. Monitor status transitions until Tokyo shows:

    • Status: "Online" or "Active"

    • WAN Interface: "Up"

    • LAN Interface: "Up"

    • Tunnel Status: "Established" to TK POP

29. Verify tunnel connection to Asia-Pacific POP is established

30. Confirm no configuration errors after activation

Part F: Post-Activation Verification

31. Navigate back to the Site Health Dashboard

32. Verify all 4 devices show as "Online" or "Active":

    • San Jose (enterprise-1) ✓

    • Ashburn (enterprise-1) ✓

    • Frankfurt (enterprise-1) ✓

    • Tokyo (enterprise-2) ✓

33. Verify health indicators for all devices:

    • WAN interface status: All "Up"

    • Tunnel status: All "Established"

    • LAN interface status: All "Up"

34. Navigate to each device and confirm:

    • Tunnel uptime displayed

    • Tunnel latency to POP displayed (in milliseconds)

    • No error messages or alarms

35. Verify in the Route Monitoring view that:

    • All 4 devices appear in the topology

    • Device-to-POP connections are visible

    • Routes are being learned and advertised

Part G: Tunnel Health and Connectivity Verification

36. Navigate to the Monitoring section for each device

37. Verify tunnel metrics for San Jose:

    • Tunnel status: "Up" or "Established"

    • Last heartbeat: Recent (within seconds)

    • Control plane connectivity: "Connected"

38. Repeat verification for Ashburn, Frankfurt, and Tokyo devices

39. Use the portal's System Information section to confirm:

    • Tunnel encryption status (if applicable)

    • Tunnel MTU/MSS settings

    • Device uptime since activation

40. Verify portal Alarm view shows no tunnel establishment errors or warnings

Part H: Enterprise Isolation Verification

41. Verify in Route Monitoring that:

    • enterprise-1 devices (San Jose, Ashburn, Frankfurt) show separate route table

    • enterprise-2 device (Tokyo) shows separate route table

    • No cross-enterprise routes visible

42. Confirm enterprise isolation is maintained after device activation

Part I: Portal Communication Verification

43. For each activated device, verify portal communication by:

    • Pushing a minor configuration change (e.g., device name update)

    • Observing configuration sync status in portal

    • Confirming device acknowledges the change

44. Verify all devices successfully receive and apply configuration pushes

Expected Result:

• All 4 site devices successfully activated and showing "Online" or "Active" status:

  • San Jose → Online, tunnel established to SJ POP (us-west-2)

  • Ashburn → Online, tunnel established to VA POP (us-east-1)

  • Frankfurt → Online, tunnel established to FR POP (eu-central-1)

  • Tokyo → Online, tunnel established to TK POP (ap-east-1)

• All device interfaces (WAN, Tunnel, LAN) showing "Up" or "Connected" status

• All tunnels established and maintaining heartbeat connectivity

• Tunnel latency metrics visible and within acceptable range (typically < 100ms to nearest POP)

• No activation errors, warnings, or alarms visible in portal

• Device Health Dashboard displays all 4 devices as operational

• Backbone topology shows all 4 devices connected and active

• Portal communication with all devices confirmed functional

• Enterprise isolation maintained after activation

Monitoring / Verification:

• Portal Site Health Dashboard shows all 4 devices as "Online" or "Active"

• Each device displays:

  • WAN Interface: "Up"

  • Tunnel Status: "Established"

  • LAN Interface: "Up"

  • Tunnel Uptime: Displays continuous uptime since activation

  • Tunnel Latency: Shows latency metrics to respective POP

• Route Monitoring view shows all 4 devices in network topology

• No errors, warnings, or alarms in device status panels

• Alarm view clean of tunnel establishment failures

• Configuration push test successful on all 4 devices

• Control plane connectivity confirmed for all devices

• Separate route tables maintained per enterprise

TC-07 — Sites Basic Connectivity Verification:  Portal, Control Plane, and Data Plane

Objective: Verify that after site device activation, the fundamental three-layer connectivity is confirmed for all 4 devices: (1) Portal connectivity; (2) Control Plane connectivity; (3) Data Plane connectivity. This ensures devices can communicate with Graphiant management systems and successfully forward traffic between sites.

Pre-conditions:

• All 4 site devices are fully activated and showing "Online" or "Active" status (TC-06 completed)

• All devices have established tunnels to their respective POPs

• LAN segments are configured on all devices (TC-03 completed)

• Graphiant portal is accessible with MSP admin credentials

• All devices have WAN connectivity

• No firewall blocks between devices and Graphiant infrastructure

Steps:

Part A: Portal Connectivity Verification

1. Log into the Graphiant portal as MSP administrator

2. Navigate to the Site Health Dashboard

3. Verify San Jose device is visible in the portal monitoring view

4. Verify Ashburn device is visible in the portal monitoring view

5. Verify Frankfurt device is visible in the portal monitoring view

6. Verify Tokyo device is visible in the portal monitoring view

7. For each device, navigate to its configuration page

8. Make a minor configuration change on San Jose device (e.g., update device name or description)

9. Save the configuration change

10. Monitor the portal for configuration push status indicator

11. Wait for configuration to be pushed to the device (typically 30-60 seconds)

12. Verify portal shows confirmation that San Jose device has acknowledged the change

13. Repeat steps 8-12 for Ashburn, Frankfurt, and Tokyo devices

14. Confirm all devices successfully acknowledge configuration pushes from portal

15. Verify no "Communication Failure" or "Offline" warnings appear in portal during connectivity tests

16. Check that device Last Update timestamps are current (within last few minutes)

Part B: Control Plane Connectivity Verification

17. Navigate to the San Jose device monitoring page

18. Locate the "Control Plane Status" or "Session Status" section

19. Verify the San Jose device shows:

    • Control Plane Status: "Connected" or "Established"

    • Session Status: "Active" or "Up”

20. Verify the Last Heartbeat timestamp has updated (device continues sending heartbeats)

21. Repeat steps 17-20 for Ashburn device

22. Verify Ashburn shows:

    • Control Plane Status: "Connected"

23. Repeat steps 17-22 for Frankfurt device

24. Verify Frankfurt shows:

    • Control Plane Status: "Connected"

25. Repeat steps 17-20 for Tokyo device

26. Verify Tokyo shows:

    • Control Plane Status: "Connected"

27. Verify no Control Plane errors or warnings appear for any device

28. Check device system logs (if accessible via LWS) for any control plane connection errors

Expected Result:

• Portal Connectivity:

  • All 4 devices visible in portal monitoring view

  • Configuration pushes successful from portal to all devices

  • All devices acknowledge configuration changes

  • Last Update timestamps current and regularly updated

  • No communication failure warnings

• Control Plane Connectivity:

  • All 4 devices show "Connected" Control Plane status

  • Heartbeat timestamps update regularly upon refresh

  • No Control Plane connection errors or warnings

  • Control Plane maintained continuously without disconnections

• Overall System Health:

  • All three connectivity layers (Portal, Control Plane, Data Plane) operational

  • No alarms or critical errors in portal

  • All devices showing healthy status

  • Network topology correctly displayed in Route Monitoring

  • Enterprise isolation maintained

Monitoring / Verification:

• Portal Site Health Dashboard shows all 4 devices as "Online" or "Active"

• Device status pages display:

  • Portal Connectivity: Configuration changes acknowledged

  • Control Plane: Shows Connected or Up

  • Data Plane: Shows Connected or Up

TC-08 — Site Device Lifecycle:  Upgrades, Maintenance Mode, Deactivation, Decommission

Objective: Verify that site devices support a complete lifecycle management including software upgrades, maintenance mode operations, graceful deactivation, and full decommissioning. Ensure that devices can be taken offline for maintenance without disrupting services, upgraded with minimal impact, and cleanly removed from the system when no longer needed.

Pre-conditions:

• All 4 site devices are fully activated and operational (TC-06 completed)

• Devices have established control plane and data plane connectivity (TC-07 completed)

• MSP admin access to Graphiant portal

• Software upgrade packages available for testing

• Device backup/snapshot available (if possible)

• Minimal or no production traffic on test devices (or during maintenance window)

Steps:

Part A: Software Upgrade - Initial State Verification

1. Log into the Graphiant portal as MSP administrator

2. Navigate to San Jose device configuration

3. Record current device software version (e.g., GraphNOS v2.5.1)

4. Verify device status: "Online" or "Active"

5. Record device uptime

6. Verify active data flows in WAN monitoring (if any)

7. Verify control plane heartbeat is current

8. Navigate to device → System Information → Software Version section

9. Document all current software components and versions

10. Take a configuration snapshot/backup (if available in portal)

Part B: Maintenance Mode - Enable and Verify

11. Navigate to San Jose device → Management section

12. Locate "Maintenance Mode" or "Put in Maintenance" option

13. Click to enable Maintenance Mode

14. Portal should display confirmation dialog:

    • Confirm action to put device in maintenance mode

    • Acknowledge any potential traffic impact

15. Confirm the maintenance mode action

16. Monitor device status transition:

    • Previous: "Online" or "Active"

    • Now: "Maintenance" or "In Maintenance" status

17. Verify portal displays warning/indicator that device is in maintenance

18. Verify device accepts configuration changes (if allowed in maintenance mode)

19. Test portal communication with device while in maintenance:

    • Push a test configuration change

    • Verify device receives and acknowledges change

Part C: Software Upgrade Process

24. While San Jose device is in Maintenance Mode, navigate to device → Upgrades section

25. Check for available software updates/upgrades

26. Verify a new software version is available.

27. Review upgrade release notes and compatibility information

28. Click "Upgrade" or "Install Update" button

29. Confirm upgrade action (typically requires confirmation)

30. Monitor upgrade progress in portal:

    • Status should show "Upgrading" or "Installing"

    • Progress indicator should update (if available)

31. Wait for upgrade to complete

32. Verify upgrade completion:

    • Device status transitions back to "Online" or "Active"

    • No errors displayed in upgrade logs

33. Verify new software version is installed:

    • Navigate to System Information

    • Confirm software version changed

34. Verify device functionality post-upgrade:

    • Control plane connectivity restored

    • Heartbeat current

    • Interfaces up

35. Verify configuration is preserved after upgrade:

    • Hostname unchanged

    • Site Name unchanged

    • Region configuration unchanged

Part D: Exit Maintenance Mode

36. Navigate to San Jose device → Management section

37. Locate "Exit Maintenance Mode" or "Take Device Online" option

38. Click to exit maintenance mode

39. Monitor device status transition:

    • "Maintenance" → "Online" or "Active"

40. Verify device is fully operational:

    • Control plane connected with current heartbeat

    • Data plane active (verify with ping test to another device)

    • All interfaces up

    • WAN monitoring shows device online

Part E: Device Deactivation - Controlled Removal

41. Select Ashburn device for deactivation testing

42. Verify Ashburn device is Online and Active

43. Navigate to Ashburn device → Management section

44. Locate "Deactivate" or "Disable Device" option

45. Click to deactivate device

46. Portal displays confirmation dialog:

    • Confirm deactivation action

    • Acknowledge any data disruption

    • Option to decommission or just deactivate

47. Select "Deactivate" (not decommission) to keep configuration

48. Monitor device status transition:

    • "Active" → "Deactivating" → "Inactive" or "Disabled"

49. Verify device behavior when deactivated:

    • Device remains visible in portal

    • Device configuration is retained

    • Control plane connection is terminated

    • Data plane is no longer operational

50. Verify portal shows Ashburn as "Inactive" or "Disabled" status

51. Attempt to ping from San Jose to Ashburn:

    • Verify 100% packet loss (expected, device is deactivated)

52. Verify device can be re-activated if needed:

    • Navigate to Ashburn device

    • Locate "Reactivate" or "Enable Device" option

    • Click to reactivate

    • Monitor status transition back to "Active"

    • Verify control plane and data plane restored

Part F: Device Decommissioning - Complete Removal

53. Select Frankfurt device for decommissioning testing

54. Verify Frankfurt device is Online and Active

55. Optionally put device in Maintenance Mode first (recommended)

56. Navigate to Frankfurt device → Management section

57. Locate "Decommission" or "Remove Device" option

58. Click to decommission device

59. Portal displays final confirmation dialog:

    • Confirm complete decommissioning action

60. Confirm decommissioning action

61. Monitor device status and removal:

    • Device transitions through status changes

    • Device may disappear from device list or show as "Decommissioned"

62. Verify decommissioning effects:

    • Device configuration is deleted from portal

    • Device no longer appears in Site Health Dashboard

    • Device no longer appears in Route Monitoring topology

    • All device configuration, routes, and policies removed

63. Verify data integrity:

    • Other devices unaffected

    • enterprise-1 continues operating with San Jose and Ashburn only

    • No residual configuration or routes from Frankfurt remain

64. Verify device cannot be re-used without full re-onboarding:

    • If same device hardware powered on, it requires fresh token/provisioning

    • Previous configuration is not restored automatically

Part H: Post-Lifecycle Verification

67. Navigate to Site Health Dashboard

68. Verify final device status:

    • San Jose (enterprise-1): Online/Active (upgraded)

    • Ashburn (enterprise-1): Inactive (deactivated, then reactivated to Active)

    • Frankfurt (enterprise-1): Not present (decommissioned)

    • Tokyo (enterprise-2): Online/Active

69. Navigate to Route Monitoring

70. Verify topology shows correct devices:

    • San Jose → SJ POP connection visible

    • Ashburn → VA POP connection visible

    • Frankfurt NOT visible (decommissioned)

    • Tokyo → TK POP connection visible

71. Verify enterprise isolation:

    • enterprise-1 has 2 devices in topology (San Jose, Ashburn)

    • enterprise-2 has 1 device in topology (Tokyo)

72. Verify no orphaned configuration:

    • No dangling routes in Route Monitoring

    • No orphaned LAN segments

    • No broken policy references

Part I: Alarm and Logging Verification

74. Navigate to portal Alarm view

75. Verify alarms generated during lifecycle:

    • "Device Entered Maintenance Mode" alarm for San Jose

    • "Software Upgrade Started/Completed" alarms

    • "Device Deactivated" alarm for Ashburn

    • "Device Reactivated" alarm for Ashburn

    • "Device Decommissioned" alarm for Frankfurt

76. Verify no error alarms for lifecycle operations (only informational)

77. Check system logs (if accessible) for:

    • Software upgrade completion messages

    • Maintenance mode transitions

    • Device deactivation/reactivation events

    • Device decommissioning events

Expected Result:

• Maintenance Mode:

  • Device transitions to "Maintenance" status

  • Device remains visible in portal

  • Configuration changes accepted

  • Data plane isolated

  • Device can be returned to normal operation

• Software Upgrades:

  • Upgrade initiated successfully while in maintenance

  • Upgrade progress monitored in portal

  • Software version updated after completion

  • Configuration preserved post-upgrade

  • Device fully operational after upgrade

• Maintenance Mode Exit:

  • Device transitions back to "Active" or "Online"

  • Control plane and data plane fully restored

  • All connectivity verified

• Device Deactivation:

  • Device transitions to "Inactive" or "Disabled" status

  • Configuration retained in portal

  • Control and data plane terminated

  • Device not operational but can be reactivated

  • Device removable from topology view

• Device Reactivation (if tested):

  • Device returns to "Active" status

  • Configuration restored automatically

  • Control and data plane re-established

• Device Decommissioning:

  • Device completely removed from portal

  • All configuration deleted

  • Device not visible in topology or device list

  • No residual data remains

  • Cannot be re-used without fresh provisioning

• Post-Lifecycle State:

  • Remaining devices fully operational

  • Enterprise isolation maintained

  • No orphaned configuration

  • Topology accurate (decommissioned devices not present)

Monitoring / Verification:

• Portal Site Health Dashboard reflects accurate device status

• Maintenance mode, upgrade, deactivation, and decommissioning alarms logged

• Software version updated after upgrade

• Device configuration preserved during upgrade and deactivation

• Decommissioned devices completely removed from all portal views

• Route Monitoring topology accurately reflects active devices

• Enterprise isolation maintained throughout lifecycle operations

• No connectivity errors for remaining active devices

• All lifecycle transitions logged and timestamped

TC-09 — Gateway Service Request:  Provision GW Nodes at CH (us-central-1)

Objective: Verify that the Gateway (GW) node can be successfully requested, provisioned, and deployed in the Graphiant portal at the CH (US-Central-1) region for enterprise-1, establishing it as the cloud on-ramp point for Azure VPC and AWS VPC connectivity. Verify the GW node becomes operational and ready for cloud service attachment configuration.

Pre-conditions:

• enterprise-1 is provisioned and Active in the MSP portal (TC-01 completed)

• All site devices in enterprise-1 are activated (TC-06 completed)

• GW node hardware or virtual instance is available and powered on in CH region

• GW node has WAN connectivity to nearest Graphiant POP (CH POP)

• GW provisioning credentials or token are available from Graphiant portal

• Azure VPC and AWS VPC are already configured in enterprise-1 cloud environment

• MSP admin access to Graphiant portal

• Network connectivity between GW and Graphiant infrastructure confirmed

Steps:

Part A: Pre-Provisioning Verification

1. Log into the Graphiant portal as MSP administrator

2. Navigate to enterprise-1 configuration

3. Locate "Gateway Service" or "GW Management" section

4. Verify no existing GW nodes are present for enterprise-1

5. Confirm Gateway Service is available for provisioning

6. Navigate to GW provisioning page

7. Verify CH (US-Central-1) region is available as a provisioning option

8. Record available GW provisioning methods (Token, URL, QR code)

9. Confirm no errors or warnings preventing GW provisioning

Part B: Generate GW Provisioning Credentials

10. Click "Request Gateway Service" or "Provision New Gateway" button

11. Portal displays GW provisioning request form with fields:

    • Gateway Region: Dropdown menu

    • Subscription Tier: (if applicable)

    • Cloud Connectivity Type: (e.g., Direct Connect, ExpressRoute)

    • Contact Information: (optional)

12. Select "CH (US-Central-1)" from Region dropdown

13. Confirm desired subscription tier for GW service

14. Verify cloud connectivity options (Azure ExpressRoute, AWS Direct Connect)

15. Enter/confirm contact information

16. Click "Generate Provisioning Credentials" or "Request GW Service"

17. Portal displays provisioning instructions for GW deployment

18. Verify all credentials are visible and can be copied

19. Record provisioning token for GW device configuration

Part C: Configure GW Node with Provisioning Credentials

21. Monitor GW status in portal:

    • Initial status: "Pending" or "Initializing"

    • Expected transition: "Pending" → "Provisioning" → "Online" or "Active"

22. Wait for GW node initialization (typically 3-5 minutes)

Part D: GW Node Status Monitoring

27. Navigate back to enterprise-1 → Gateway Service section

28. Verify GW node is visible in the portal with status:

    • Node Name or ID: Unique identifier

    • Region: CH (US-Central-1)

    • Status: "Online" or "Active"

    • Deployment Status: "Ready" or "Operational"

29. Verify GW node information displays:

    • GW Node ID/Serial Number

    • Region: US-Central-1 (CH)

    • Status: Online

    • Tunnel Status: Established to CH POP

    • Hardware/Instance Type (if visible)

    • IP Address (Management/Control Plane)

30. Confirm no errors or warnings in GW provisioning logs

31. Verify GW is reachable from portal:

    • Navigation to GW details shows responsive interface

    • GW responds to configuration queries

    • No timeout or connectivity errors

Part E: GW Tunnel Establishment Verification

32. Verify GW tunnel to CH POP is established:

    • Navigate to GW → Tunnel Status section

    • Confirm tunnel status: "Established" or "Up"

    • Verify tunnel uptime is displayed

    • Record tunnel establishment timestamp

33. Verify tunnel metrics:

    • Latency to CH POP: (should be low, < 50ms typical)

    • Tunnel heartbeat: Current and regular

    • Control plane connectivity: Connected

34. Monitor GW backbone connectivity:

    • Navigate to Route Monitoring view

    • Verify GW node appears in network topology

    • Confirm CH POP connection is visible

    • Verify GW is connected to Graphiant backbone network

35. Check GW interface status:

    • Management Interface: Up/Connected

    • WAN Interface: Up/Connected

    • All required interfaces operational

Part F: GW Provisioning Completion Verification

36. Navigate to enterprise-1 dashboard

37. Verify GW Service status shows:

    • Gateway Service: Provisioned and Ready

    • Number of GW Nodes: 1 (CH)

    • Operational Status: Active

    • Cloud On-Ramp Status: Ready for configuration

38. Confirm GW appears in enterprise-1 configuration list under:

    • Gateway Nodes section

    • Cloud Services section

    • Network Architecture view

39. Verify GW is ready for cloud VPC attachment:

    • Check status indicates "Ready for Cloud Configuration"

    • No prerequisite tasks pending

    • Proceed to next phase (TC-10) is available

40. Verify no errors, warnings, or alarms related to GW provisioning

Part G: GW Connectivity and Health Verification

41. If available, access GW node's Local Management Interface (LMI) or portal health view:

    • Navigate to GW → System Health

    • Verify CPU, Memory, Disk usage within normal ranges

    • Verify all critical services running

42. Check GW Control Plane connectivity:

    • Verify connection to Onboarding Service

    • Verify connection to Control Plane (GCS)

    • Verify connection to Data Plane infrastructure

43. Run GW connectivity diagnostics (if available):

    • Test reachability to CH POP

    • Test reachability to backbone network

    • Verify DNS resolution for Graphiant services

44. Monitor GW logs for any error messages:

    • Check provisioning logs

    • Verify no authentication/authorization failures

    • Confirm no tunnel establishment errors

45. Verify GW is isolated from enterprise site traffic:

    • Confirm GW is in management/control plane only

    • Verify no user data traffic flowing through GW yet

    • Confirm isolation until cloud VPC attachment configured

Part H: Enterprise-1 GW Assignment Verification

46. Verify GW is properly associated with enterprise-1:

    • Navigate to enterprise-1 → Properties

    • Confirm "Gateway Node" field shows: CH GW (or GW node ID)

    • Verify no cross-enterprise association

47. Confirm GW provisioning request status shows: "Completed" or "Active"

48. Verify GW Service Request appears in enterprise-1 audit log with:

    • Request timestamp

    • Requesting user/admin

    • GW region: CH (US-Central-1)

    • Provisioning status: Successful

49. Verify GW nodes cannot be provisioned again:

    • Attempt to request another GW for CH region

    • Verify portal shows error or prevents duplicate request

    • Confirm only one GW node allowed per region per enterprise

Part I: Portal Navigation and Documentation

50. Verify GW node is accessible from multiple portal locations:

    • Enterprise-1 → Gateway Service: Shows GW node

    • Network Topology view: Shows GW connected

    • Administration → Resources: Lists provisioned GW

51. Verify documentation/information available:

    • GW Configuration guide accessible

    • Cloud VPC attachment procedures documented

    • Troubleshooting guide available

52. Confirm GW ready state message clearly displayed:

    • Portal shows "Gateway Ready for Cloud Configuration"

    • Next steps to attach cloud VPCs are clear

    • Links to TC-10 (Cloud Configuration) available

Expected Result:

• GW Provisioning Successfully Completed:

  • GW node provisioned in CH (US-Central-1) region

  • Status: "Online" or "Active"

  • Deployment Status: "Ready" or "Operational"

• GW Node Operational:

  • Tunnel established to CH POP

  • Tunnel uptime and latency metrics displayed

  • Control plane connectivity confirmed

  • All interfaces (Management, WAN) operational

• GW Network Integration:

  • GW appears in network topology/Route Monitoring

  • GW connected to Graphiant backbone

  • Backbone connectivity verified and stable

  • No connectivity errors or warnings

• Enterprise-1 Association:

  • GW properly associated with enterprise-1

  • Accessible from enterprise-1 configuration

  • No cross-enterprise association

  • Provisioning request marked as completed

• GW Ready for Next Phase:

  • GW Health Status: All systems normal

  • Management connectivity: Operational

  • Gateway Service: Ready for cloud VPC attachment configuration

  • No blocking issues preventing cloud service attachment

Monitoring / Verification:

• Portal Gateway Service section shows:

  • GW Node: CH (US-Central-1) - Online/Active

  • Tunnel Status: Established

  • Tunnel Metrics: Uptime and latency displayed

  • Health Status: All systems operational

• Network Topology displays GW connected to backbone

• Audit logs show successful provisioning request completion

• No alarms or errors related to GW provisioning

• GW ready indicator confirms operational status

• Enterprise-1 shows GW Service as provisioned and ready

• Portal navigation confirms GW visible in all appropriate sections

• GW node system health shows normal resource utilization

TC-10 — Gateway Service Configuration — AWS and Azure DirectConnect/ExpressRoute Configuration

Objective: Verify that the Gateway (GW) node at CH (US-Central-1) can be successfully configured to attach and establish secure, high-bandwidth connections to Azure VPC via ExpressRoute and AWS VPC via Direct Connect. Ensure both cloud VPC connections are operational and bidirectional traffic flows correctly through the GW.

Automation:

https://github.com/Graphiant-Inc/graphiant-playbooks/tree/main/terraform

Pre-conditions:

• GW node is provisioned and fully operational at CH (TC-09 completed)

• GW tunnel to CH POP established and confirmed

• Azure VPC and AWS VPC are pre-configured in respective cloud environments

• Azure ExpressRoute circuit provisioned and available for Graphiant connection

• AWS Direct Connect Virtual Interface (VIF) provisioned and available

• BGP configuration parameters available for both cloud providers

• Azure account access to configure ExpressRoute connection

• AWS account access to configure Direct Connect connection

• MSP admin access to Graphiant portal

• Network connectivity and firewall rules properly configured in cloud environments

Steps:

Part A: Pre-Configuration Verification

1. Log into the Graphiant portal as MSP administrator

2. Navigate to enterprise-1 → Gateway Service

3. Verify GW node status: "Online" or "Active"

4. Confirm GW tunnel to CH POP is "Established"

5. Navigate to GW → Configuration section

6. Verify "Cloud VPC Attachment" or "Cloud Configuration" option is available

7. Confirm no existing Azure or AWS attachments (fresh GW)

8. Record GW configuration details needed for cloud connections:

   • GW Node ID

   • GW Control Plane IP Address

   • BGP ASN

   • Supported VPC attachment methods

Part B: Azure ExpressRoute Configuration

9. Navigate to enterprise-1 → Gateway Service → GW Configuration

10. Locate "Azure VPC" or "Microsoft Azure" attachment option

11. Click "Add Azure VPC Attachment" or "Configure Azure Connection"

12. Portal displays Azure connection configuration form with fields:

    • Azure Subscription ID

    • Azure Resource Group

    • Azure Virtual Network (VNet) Name

    • ExpressRoute Circuit ID or Circuit Name

    • BGP Peering Configuration (with Graphiant AS number as 30656)

    • Authentication Key (ExpressRoute primary/secondary)

13. Enter Azure VPC details:

    • Subscription ID: Azure subscription containing the VPC

    • Resource Group: Resource group where VPC resides

    • VNet Name: Name of the Azure Virtual Network

    • VPC CIDR Prefix: Azure VPC address space (e.g., 10.0.0.0/16)

14. Enter ExpressRoute configuration:

    • ExpressRoute Circuit ID: Circuit identifier from Azure

    • Peering Type: Private Peering (for VPC connectivity)

    • Vlan ID: ExpressRoute vlan assignment

    • BGP Peer IP (GW side): Graphiant GW BGP peer IP

    • BGP Peer IP (Azure side): Azure side BGP peer IP

    • BGP ASN (Graphiant): AS number for Graphiant (30656)

    • BGP ASN (Azure): AS number for Microsoft

15. Configure BGP Session Parameters:

    • Primary Key: ExpressRoute primary authentication key

    • Secondary Key: ExpressRoute secondary authentication key (if applicable)

16. Verify Azure VPC prefix is correctly entered

17. Click "Validate Azure Configuration" or "Test Connection"

18. Portal performs validation:

    • Confirms connectivity to Azure ExpressRoute circuit

    • Verifies BGP configuration parameters

    • Tests peering establishment readiness

19. Verify validation successful (no errors)

20. Click "Attach Azure VPC" or "Create Azure Connection"

21. Monitor Azure attachment status in portal:

    • Initial status: "Configuring" or "Initializing"

    • Expected transition: "Configuring" → "Validating" → "Connected" or "Active"

22. Wait for Azure attachment establishment (typically 2-5 minutes)

Part C: Azure ExpressRoute Connection Verification

23. Verify Azure VPC attachment status shows: "Connected" or "Active"

24. Confirm Azure connection displays:

    • Attachment Status: Connected/Active

    • Azure VPC: Correct VPC name displayed

    • CIDR Prefix: Correct Azure VPC prefix (e.g., 10.0.0.0/16)

    • BGP Status: Established or Up

    • Last Update: Recent timestamp

25. Navigate to GW → BGP Sessions or Peering Status

26. Verify Azure ExpressRoute BGP session shows:

    • Peer ASN: 12076 (Microsoft)

    • BGP State: "Established" or "Up"

    • Prefixes Received: Should show Azure VPC prefixes

    • Prefixes Advertised: Should show enterprise-1 site prefixes

    • Session Uptime: Displayed (should be actively running)

27. Verify Azure connectivity metrics:

    • Bandwidth Utilization: Shows current/peak usage

    • Packet Loss: 0% (if traffic flowing)

    • Latency: Typical range for ExpressRoute (< 50ms)

    • Connection Quality: Stable/Good

28. Check Azure route table for Graphiant routes:

    • In Azure portal, verify GW is advertising routes to Azure VPC

    • Confirm Azure can reach Graphiant network through ExpressRoute

29. Verify no errors or warnings in Azure attachment configuration

Part D: AWS Direct Connect Configuration

30. Navigate to enterprise-1 → Gateway Service → GW Configuration

31. Locate "AWS VPC" or "Amazon AWS" attachment option

32. Click "Add AWS VPC Attachment" or "Configure AWS Connection"

33. Portal displays AWS connection configuration form with fields:

    • AWS Account ID

    • AWS Region

    • AWS Virtual Private Cloud (VPC) ID

    • Direct Connect Virtual Interface (VIF) ID

    • BGP Configuration (if applicable)

34. Enter AWS VPC details:

    • AWS Account ID: AWS account ID containing the VPC

    • Region: AWS region where VPC resides (e.g., us-east-1, us-west-2)

    • VPC ID: VPC identifier from AWS (vpc-xxxxx)

    • VPC CIDR Prefix: AWS VPC address space (e.g., 10.1.0.0/16)

35. Enter AWS Direct Connect configuration:

    • Direct Connect Connection ID: DX connection identifier

    • Virtual Interface (VIF) ID: Private VIF for VPC attachment

    • VIF Type: Private Virtual Interface (for VPC)

    • VLAN ID: VLAN assigned to VIF

    • BGP Peer IP (GW side): Graphiant GW BGP peer IP

    • BGP Peer IP (AWS side): AWS side BGP peer IP

    • BGP ASN (Graphiant): AS number for Graphiant

    • BGP ASN (AWS): AS number for Amazon (typically 16509)

36. Configure BGP Session Parameters:

    • Virtual Gateway ASN: Virtual Gateway ASN from AWS

    • Customer Address: Customer side (Graphiant) BGP IP

    • Amazon Address: AWS side BGP IP

37. Verify AWS VPC prefix is correctly entered

38. Click "Validate AWS Configuration" or "Test Connection"

39. Portal performs validation:

    • Confirms connectivity to AWS Direct Connect VIF

    • Verifies BGP configuration parameters

    • Tests peering establishment readiness

40. Verify validation successful (no errors)

41. Click "Attach AWS VPC" or "Create AWS Connection"

42. Monitor AWS attachment status in portal:

    • Initial status: "Configuring" or "Initializing"

    • Expected transition: "Configuring" → "Validating" → "Connected" or "Active"

43. Wait for AWS attachment establishment (typically 2-5 minutes)

Part E: AWS Direct Connect Connection Verification

44. Verify AWS VPC attachment status shows: "Connected" or "Active"

45. Confirm AWS connection displays:

    • Attachment Status: Connected/Active

    • AWS VPC: Correct VPC ID displayed

    • CIDR Prefix: Correct AWS VPC prefix (e.g., 10.1.0.0/16)

    • BGP Status: Established or Up

    • Last Update: Recent timestamp

46. Navigate to GW → BGP Sessions or Peering Status

47. Verify AWS Direct Connect BGP session shows:

    • Peer ASN: 16509 (Amazon)

    • BGP State: "Established" or "Up"

    • Prefixes Received: Should show AWS VPC prefixes

    • Prefixes Advertised: Should show enterprise-1 site prefixes

    • Session Uptime: Displayed (should be actively running)

48. Verify AWS connectivity metrics:

    • Bandwidth Utilization: Shows current/peak usage

    • Packet Loss: 0% (if traffic flowing)

    • Latency: Typical range for Direct Connect (< 50ms)

    • Connection Quality: Stable/Good

49. Check AWS VPC route table for Graphiant routes:

    • In AWS console, verify GW is advertising routes to AWS VPC

    • Confirm AWS can reach Graphiant network through Direct Connect

50. Verify no errors or warnings in AWS attachment configuration

Part F: Dual Cloud Configuration Verification

51. Navigate to enterprise-1 → Gateway Service → Cloud Attachments

52. Verify both cloud VPCs are listed and configured:

    • Azure: Status "Connected", CIDR 10.0.0.0/16

    • AWS: Status "Connected", CIDR 10.1.0.0/16

53. Verify both BGP sessions are active:

    • Azure ExpressRoute BGP: Established

    • AWS Direct Connect BGP: Established

54. Navigate to Route Monitoring view

55. Verify routes from both cloud VPCs are visible:

    • Azure routes (10.0.0.0/16) with GW as next-hop

    • AWS routes (10.1.0.0/16) with GW as next-hop

56. Verify enterprise-1 sites can see both cloud VPC routes:

    • In Route Monitoring, select San Jose site

    • Confirm both Azure (10.0.0.0/16) and AWS (10.1.0.0/16) routes visible

    • Repeat for Ashburn and Frankfurt sites

57. Verify no duplicate or conflicting routes

58. Confirm GW is only cloud on-ramp for enterprise-1:

    • No alternative paths to cloud VPCs

    • All cloud traffic routes through GW

Part G: Multi-Cloud Traffic Flow Testing

59. From San Jose site, test reachability to Azure VPC:

    • Use portal Ping Test tool

    • Destination: Azure VPC IP (e.g., 10.0.1.10)

    • Verify 0% packet loss

    • Record latency (typical: 50-100ms depending on geography)

60. From San Jose site, test reachability to AWS VPC:

    • Use portal Ping Test tool

    • Destination: AWS VPC IP (e.g., 10.1.1.10)

61. Test bidirectional connectivity:

    • From Azure VPC → San Jose LAN: Verify reachability

    • From AWS VPC → Ashburn LAN: Verify reachability

    • Use Azure/AWS network interface or test instances

62. Monitor GW WAN metrics during traffic:

    • Verify bandwidth usage on both ExpressRoute and Direct Connect

    • Confirm no packet loss on cloud connections

    • Verify latency remains stable

Part H: Cloud VPC Inter-Communication Verification

65. Test Azure VPC → AWS VPC connectivity through GW:

    • Source: Azure VPC instance (10.0.1.10)

    • Destination: AWS VPC instance (10.1.1.10)

    • Verify bidirectional communication

    • Both VPCs can communicate through Graphiant GW

66. Monitor GW traffic for Azure-to-AWS flows:

    • Verify traffic traverses both ExpressRoute and Direct Connect

    • Confirm no routing loops

    • Verify bandwidth split appropriately

Part I: Portal Configuration Verification

67. Navigate to GW → Configuration page

68. Verify complete configuration displayed:

    • GW Node ID and status

    • Azure VPC attachment with all parameters

    • AWS VPC attachment with all parameters

    • BGP session status for both

    • Tunnel to CH POP

69. Verify no configuration errors or warnings

70. Test portal configuration push capability:

    • Make minor configuration change (e.g., update description)

    • Verify GW receives and acknowledges change

    • Confirm change persists after refresh

Part J: Alarm and Logging Verification

71. Navigate to portal Alarm view

72. Verify no critical alarms related to:

    • Azure ExpressRoute connection failures

    • AWS Direct Connect connection failures

    • BGP session down events

    • Cloud routing issues

73. Verify informational alarms logged:

    • "Azure VPC Attached" event

    • "AWS VPC Attached" event

    • BGP session establishment events

74. Check system logs for:

    • Successful Azure attachment completion

    • Successful AWS attachment completion

    • BGP session establishment with Microsoft and Amazon

    • No connection failures or retries

Expected Result:

• Azure ExpressRoute Configuration:

  • Azure VPC attachment status: "Connected" or "Active"

  • BGP session with Microsoft (ASN 12076): "Established"

  • Azure VPC routes (10.0.0.0/16) visible in Route Monitoring

  • Bidirectional traffic flows between enterprise-1 sites and Azure VPC

  • 0% packet loss on Azure connectivity

• AWS Direct Connect Configuration:

  • AWS VPC attachment status: "Connected" or "Active"

  • BGP session with Amazon (ASN 16509): "Established"

  • AWS VPC routes (10.1.0.0/16) visible in Route Monitoring

  • Bidirectional traffic flows between enterprise-1 sites and AWS VPC

  • 0% packet loss on AWS connectivity

• Dual Cloud Functionality:

  • Both Azure and AWS VPCs reachable from all enterprise-1 sites

  • Azure ↔ AWS communication through GW functional

  • No routing conflicts or loops

  • Bandwidth metrics displayed for both connections

  • BGP sessions stable and continuously established

• Overall System Health:

  • No critical alarms related to cloud attachments

  • Both cloud connections operational and stable

  • GW properly functioning as multi-cloud on-ramp

  • All enterprise-1 sites have access to both cloud VPCs

  • Configuration persisted and verified

Monitoring / Verification:

• GW Configuration page shows both Azure and AWS attachments as "Connected"

• Route Monitoring displays both Azure and AWS VPC routes

• All site devices can reach both Azure and AWS VPC IP ranges

• Ping tests from all enterprise-1 sites to both clouds show 0% packet loss

• BGP sessions for both cloud providers show "Established" status

• No connection errors, routing loops, or policy violations

• Bandwidth utilization visible on both ExpressRoute and Direct Connect

• Alarms show successful attachment events, no failure events

• Portal configuration accurately reflects dual-cloud setup

TC-11 — Site Device Configuration:  Circuits, Interfaces, Routing, Services

Objective: Verify that site devices can be configured with WAN circuits, network interfaces, routing, and services via portal.

Automation:

https://docs.ansible.com/projects/ansible/latest/collections/graphiant/naas/index.html#plugins-in-graphiant-naas

Pre-conditions:

• All site devices are activated and operational (TC-06 completed)

• Portal connectivity verified (TC-07 completed)

• LAN segments configured (TC-03 completed)

Steps:

1. Circuits: Configure primary and secondary WAN circuits on San Jose device. Set failover parameters. Verify both circuits show in portal with correct status.

2. Interfaces: Configure WAN interface (IP, gateway, MTU) and LAN interface (IP, DHCP pool, DNS). Verify interface statistics update in real-time.

3. Routing: Add static routes (e.g., 10.0.0.0/16 to Azure, 10.1.0.0/16 to AWS). Configure dynamic routing if supported (BGP/OSPF). Verify routes appear in routing table.

4. Services: Enable and configure DHCP (pool, lease time, DNS), DNS (forwarding), NTP (time sync), SSH (access). Verify services operational.

5. Testing: Test circuit failover. Verify interfaces reach configured gateways. Test routing to other sites. Verify DHCP assigns IPs, DNS resolves names, NTP syncs time.

6. Monitoring: Verify interface stats, circuit health, routes, and service status display in portal.

7. Backup: Create configuration backup. Verify persistence after device reload.

8. Consistency: Repeat for Ashburn, Frankfurt, and Tokyo. Verify configuration consistency across enterprise and enterprise isolation maintained.

Expected Result:

• All circuits configured and operational

• All interfaces up with correct IP configuration

• All routes visible and reachable

• All services (DHCP, DNS, NTP) operational

• No configuration errors or alarms

• Configuration persists after reload

Monitoring / Verification:

• Portal Configuration Summary shows all settings

• Interface statistics updating in real-time

• Circuit health metrics displayed

• Routing table complete and correct

• Service status shows all operational

TC-12 — Site-to-Site Reachability:  Same Segment Across Enterprise-1 Sites

Objective: Verify that hosts within the same LAN segment can communicate across all enterprise-1 sites (San Jose, Ashburn, Frankfurt) through the Graphiant network using basic connectivity (ping) and bandwidth/stability testing (iperf).

Pre-conditions:

• All enterprise-1 sites are activated and operational (TC-06 completed)

• LAN segment configured and active on all three sites (TC-03 completed)

• Basic connectivity verified (TC-07 completed)

Steps:

1. Ping San Jose → Ashburn: Use portal ping tool. Verify successful responses with consistent latency.

2. Ping San Jose → Frankfurt: Use portal ping tool. Verify successful responses.

3. Ping Ashburn → Frankfurt: Use portal ping tool. Verify successful responses.

4. iperf TCP San Jose → Ashburn: Use portal throughput test. Run iperf TCP for bandwidth measurement. Record throughput and stability metrics.

5. iperf TCP San Jose → Frankfurt: Run iperf TCP between sites. Record bandwidth.

6. iperf UDP San Jose → Ashburn: Run iperf UDP for low-latency traffic simulation. Record jitter and packet loss.

7. iperf UDP Ashburn → Frankfurt: Run iperf UDP. Verify successful UDP flow.

8. WAN Monitoring: Verify active flows visible in portal for each site-to-site pair during both ping and iperf tests.

9. Bidirectional Verification: Test reverse paths (Ashburn → San Jose, Frankfurt → San Jose). Verify equal bandwidth in both directions.

10. Sustained Traffic: Send sustained traffic for 5+ minutes. Verify no disconnections or degradation.

Expected Result:

• All ping tests successful with consistent latency

• iperf TCP shows measurable bandwidth (expected range based on circuit provisioning)

• iperf UDP shows low jitter and minimal packet loss

• All flows visible in WAN monitoring

• Bidirectional traffic symmetric

• No degradation during sustained testing

Monitoring / Verification:

• Portal WAN monitoring shows active flows for all site-to-site pairs

• Ping tests successful

• iperf TCP throughput consistent and documented

• iperf UDP jitter within acceptable range (< 50ms typical)

• No alarms or errors in portal

TC-13 — DIA breakout at sites

Objective: Verify that internet-destined traffic from enterprise-1 sites breaks out locally via Direct Internet Access (DIA) links and does not traverse the Graphiant network.

Pre-conditions:

• All enterprise-1 sites activated and operational (TC-06 completed)

• DIA policy configured on edge devices

• DIA circuits available at each site

Steps:

1. Enable DIA Policy: Configure DIA policy on San Jose device to route all internet-bound traffic locally.

2. Test Internet Traffic: Send traffic to public destination (e.g., 8.8.8.8). Use portal traceroute to verify first hop is local DIA gateway (not Graphiant network).

3. Test Simultaneous Flows: Send traffic to DIA destination AND Ashburn LAN simultaneously. Verify DIA traffic exits via local gateway, enterprise traffic uses Graphiant tunnel.

4. WAN Monitoring: Verify flows appear on correct interfaces (DIA on WAN, Graphiant on tunnel).

5. Repeat for Ashburn and Frankfurt: Repeat steps 1-4 for other sites.

6. Verify No Graphiant Transit: Confirm internet traffic never appears on Graphiant tunnel interface.

Expected Result:

• Internet traffic exits via local DIA link

• Enterprise traffic uses Graphiant tunnel

• Both flow types visible in WAN monitoring on correct interfaces

• No internet traffic on Graphiant WAN interface

Monitoring / Verification:

• WAN monitoring shows DIA and Graphiant flows on separate interfaces

• Traceroute confirms DIA first hop is local gateway

• No internet traffic on Graphiant tunnel

TC-14 — enterprise-1 Site to AWS VPC via GW

Objective: Verify that enterprise-1 sites (San Jose, Ashburn, Frankfurt) can reach AWS VPC through the Gateway node at CH via Direct Connect with basic connectivity (ping) and bandwidth/stability testing (iperf).

Pre-conditions:

• GW node provisioned at CH (TC-09 completed)

• AWS VPC attached to GW (TC-10 completed)

• AWS Direct Connect configured and active

• All enterprise-1 sites activated (TC-06 completed)

Steps:

1. Verify AWS Route: Confirm AWS VPC prefix (10.1.0.0/16) visible in enterprise-1 Route Monitoring with GW as next-hop.

2. Ping San Jose → AWS: Use portal ping tool to AWS VPC IP. Verify successful responses.

3. Ping Ashburn → AWS: Verify successful ping.

4. Ping Frankfurt → AWS: Verify successful ping.

5. iperf TCP San Jose → AWS: Run iperf TCP to AWS VPC. Record bandwidth and latency.

6. iperf TCP Ashburn → AWS: Run iperf TCP. Record throughput.

7. iperf TCP Frankfurt → AWS: Run iperf TCP. Verify bandwidth from EU site.

8. iperf UDP San Jose → AWS: Run iperf UDP for low-latency traffic. Record jitter and packet loss.

9. Traceroute: Run traceroute from San Jose to AWS VPC. Verify path includes CH and GW.

10. Bidirectional Test - AWS → San Jose: Test AWS → San Jose on both TCP and UDP. Verify return traffic flows.

11. WAN Monitoring: Verify AWS traffic visible in WAN monitoring for each site. Confirm bandwidth metrics displayed.

Expected Result:

• All site-to-AWS pings successful

• iperf TCP shows measurable bandwidth from all three sites

• iperf UDP shows acceptable jitter

• Traceroute confirms CH and GW in path

• Bidirectional traffic flows correctly

• WAN monitoring displays AWS flows

Monitoring / Verification:

• Route Monitoring shows AWS VPC route with GW next-hop

• All site-to-AWS pings successful

• iperf TCP throughput consistent from all sites

• iperf UDP jitter acceptable

• WAN monitoring displays AWS flows with bandwidth metrics

TC-15 — enterprise-1 Site to Azure VPC via GW

Objective: Verify that enterprise-1 sites (San Jose, Ashburn, Frankfurt) can reach Azure VPC through the Gateway node at CH via ExpressRoute with basic connectivity (ping) and bandwidth/stability testing (iperf).

Pre-conditions:

• GW node provisioned at CH (TC-09 completed)

• Azure VPC attached to GW (TC-10 completed)

• Azure ExpressRoute configured and active

• All enterprise-1 sites activated (TC-06 completed)

Steps:

1. Verify Azure Route: Confirm Azure VPC prefix (10.0.0.0/16) visible in enterprise-1 Route Monitoring with GW as next-hop.

2. Ping San Jose → Azure: Use portal ping tool to Azure VPC IP. Verify successful responses.

3. Ping Ashburn → Azure: Verify successful ping.

4. Ping Frankfurt → Azure: Verify successful ping.

5. iperf TCP San Jose → Azure: Run iperf TCP to Azure VPC. Record bandwidth and latency.

6. iperf TCP Ashburn → Azure: Run iperf TCP. Record throughput.

7. iperf TCP Frankfurt → Azure: Run iperf TCP. Verify bandwidth from EU site.

8. iperf UDP San Jose → Azure: Run iperf UDP for low-latency traffic. Record jitter and packet loss.

9. Traceroute: Run traceroute from San Jose to Azure VPC. Verify path includes CH and GW.

10. Bidirectional Test - Azure → San Jose: Test Azure → San Jose on both TCP and UDP. Verify return traffic flows.

11. WAN Monitoring: Verify Azure traffic visible in WAN monitoring for each site. Confirm bandwidth metrics displayed.

Expected Result:

• All site-to-Azure pings successful

• iperf TCP shows measurable bandwidth from all three sites

• iperf UDP shows acceptable jitter

• Traceroute confirms CH and GW in path

• Bidirectional traffic flows correctly

• WAN monitoring displays Azure flows

Monitoring / Verification:

• Route Monitoring shows Azure VPC route with GW next-hop

• All site-to-Azure pings successful

• iperf TCP throughput consistent from all sites

• iperf UDP jitter acceptable

• WAN monitoring displays Azure flows with bandwidth metrics

TC-16 — Multi-Cloud — Azure VPC to AWS VPC

Objective: Verify that Azure VPC and AWS VPC can communicate bidirectionally through the Gateway node at CH using basic connectivity (ping) and bandwidth/stability testing (iperf).

Pre-conditions:

• GW node provisioned at CH (TC-09 completed)

• Azure VPC attached to GW via ExpressRoute (TC-10 completed)

• AWS VPC attached to GW via Direct Connect (TC-10 completed)

• Both VPC connections operational

Steps:

1. Verify Routes: Confirm both Azure (10.0.0.0/16) and AWS (10.1.0.0/16) routes visible in Route Monitoring.

2. Ping Azure → AWS: Send ping from Azure VPC instance to AWS VPC instance. Verify successful responses.

3. Ping AWS → Azure: Send ping from AWS VPC instance to Azure VPC instance. Verify successful responses.

4. iperf TCP Azure → AWS: Run iperf TCP from Azure to AWS. Record bandwidth.

5. iperf TCP AWS → Azure: Run iperf TCP in reverse direction. Verify symmetrical bandwidth.

6. iperf UDP Azure → AWS: Run iperf UDP for low-latency traffic. Record jitter and packet loss.

7. iperf UDP AWS → Azure: Run iperf UDP in reverse. Verify UDP jitter.

8. Traceroute: Verify path includes GW at CH for both directions.

9. GW Monitoring: Verify traffic flows on both ExpressRoute and Direct Connect connections simultaneously.

10. Sustained Traffic: Send multi-minute traffic flow between VPCs. Verify no disconnections.

Expected Result:

• Azure ↔ AWS bidirectional communication via GW

• Successful ping responses in both directions

• iperf TCP shows measurable bandwidth

• iperf UDP shows acceptable jitter

• Path confirmed through GW at CH

• Both cloud connections carrying traffic simultaneously

• No degradation during sustained testing

Monitoring / Verification:

• Route Monitoring shows both VPC routes

• GW WAN monitoring displays traffic on both cloud connections

• Ping tests show successful responses

• iperf metrics (TCP throughput, UDP jitter) documented

TC-17 — DIA Breakout at Gateways

Objective: Verify that internet-destined traffic from the Gateway node at CH breaks out locally via DIA and does not traverse the Graphiant backbone unnecessarily.

Pre-conditions:

• GW node provisioned and operational at CH (TC-09 completed)

• DIA policy configured on GW device

• DIA circuit available at CH region

Steps:

1. Enable DIA Policy: Configure DIA policy on GW to route internet-bound traffic locally.

2. Test Internet Traffic from GW: Send traffic to public destination (e.g., 8.8.8.8) from GW. Verify first hop is local DIA gateway via traceroute.

3. Test Simultaneous Flows: Send internet traffic AND cloud VPC traffic simultaneously. Verify internet exits via DIA, cloud traffic uses Express Route/Direct Connect.

4. WAN Monitoring: Verify flows appear on correct interfaces (DIA on WAN, cloud connections on ExpressRoute/Direct Connect).

5. Verify No Backbone Transit: Confirm internet traffic never traverses Graphiant backbone.

Expected Result:

• Internet traffic exits via local DIA link

• Cloud VPC traffic uses ExpressRoute/Direct Connect

• Both flow types visible in WAN monitoring on correct interfaces

• No internet traffic on Graphiant backbone

Monitoring / Verification:

• WAN monitoring shows DIA and cloud flows on separate interfaces

• Traceroute confirms DIA first hop is local gateway

• No internet traffic on Graphiant backbone connections

TC-18 — Site Health Dashboard, Data Assurance Dashboard, Bandwidth Dashboard

Objective: Verify that the site health dashboard displays device status, control plane connectivity, data plane connectivity, and active alerts.

Pre-conditions:

• All 4 site devices activated (TC-06 completed)

• Connectivity verified (TC-07 completed)

Steps:

1. Navigate to Site Health Dashboard.

2. Verify all 4 devices visible with correct enterprise association.

3. Verify each device displays:

   • Control Plane: Connected/Last Heartbeat timestamp

   • Data Plane: WAN, Tunnel, LAN interface status

   • Alerts: Any active alarms with severity

4. Disable WAN interface on one device. Verify dashboard reflects change and generates alert.

5. Re-enable interface. Verify status restored and alert cleared.

6. Verify real-time updates when status changes.

7. Navigate to Data Assurance and Bandwidth Dashboards

8. Visualize traffic/applications paths and consumptions.

Expected Result:

• All devices visible with Control Plane Connected status

• Data Plane status (WAN, Tunnel, LAN) accurate

• Alerts displayed with severity level

• Real-time updates on status changes

Monitoring / Verification:

• Dashboard shows all devices with Control Plane and Data Plane status

• Alerts panel displays active alarms

• Status updates reflect changes immediately

• Data assurance and bandwidth dashboards show traffic/applications paths and consumptions accordingly

TC-19 — Device Monitoring:  Device Summary, Application/DIA Stats, Circuit Stats, Network Stats

Objective: Verify that device monitoring displays comprehensive statistics including device summary, application/DIA traffic stats, circuit health, and network performance metrics.

Pre-conditions:

• All 4 site devices activated (TC-06 completed)

• Connectivity verified (TC-07 completed)

• Configuration complete (TC-11 completed)

• Traffic flowing through devices

Steps:

1. Navigate to San Jose device → Monitoring section.

2. Verify Device Summary displays:

   • Hostname, Site Name, Region, Status

   • Uptime, Last Update, Software Version

3. Verify Application/DIA Stats display:

   • Application classification (Gold/Silver/Bronze)

   • DIA traffic volume and percentage

   • Enterprise traffic volume and percentage

4. Verify Circuit Stats display:

   • Primary circuit: Bandwidth, latency, packet stats

   • Secondary circuit: Status and metrics (if configured)

   • Circuit utilization percentage

5. Verify Network Stats display:

   • WAN interface: Bytes in/out, packets in/out, errors

   • LAN interface: Bytes in/out, connected device count

   • Tunnel: Status, uptime, heartbeat

6. Send test traffic from San Jose to Ashburn. Verify stats update in real-time.

7. Repeat for Ashburn, Frankfurt, and Tokyo devices.

Expected Result:

• Device Summary accurately displays device configuration and status

• Application/DIA Stats show correct traffic classification

• Circuit Stats display health and utilization metrics

• Network Stats update in real-time with traffic

• All metrics accurate and consistent

Monitoring / Verification:

• Device monitoring displays all four stat categories

• Stats update in real-time when traffic changes

• Metrics accurately reflect device configuration

TC-20 — Route Monitoring:  Route Table

Objective: Verify that the route monitoring view accurately displays complete and accurate route tables for both enterprises, including all configured routes, learned routes, and route changes.

Pre-conditions:

• All site devices activated (TC-06 completed)

• LAN segments configured (TC-03 completed)

• Cloud VPCs attached to GW (TC-10 completed)

• Routing configured on devices (TC-11 completed)

Steps:

1. Navigate to Route Monitoring view.

2. Select enterprise-1. Verify route table displays:

   • LAN routes (San Jose, Ashburn, Frankfurt)

   • Azure VPC route (10.0.0.0/16) with GW as next-hop

   • AWS VPC route (10.1.0.0/16) with GW as next-hop

3. Verify each route shows: Destination CIDR, Next Hop, Metric, Route Source.

4. Select enterprise-2. Verify route table displays:

   • Tokyo LAN routes only

   • No enterprise-1 routes visible

5. Add a new static route on San Jose device. Verify new route appears in enterprise-1 table.

6. Delete the route. Verify route withdrawn from table.

7. Verify no cross-enterprise route leakage.

8. Test route accuracy by pinging destinations listed in route table. Verify connectivity matches routes shown.

Expected Result:

• enterprise-1 route table shows all LAN and cloud VPC routes

• enterprise-2 route table shows only Tokyo LAN routes

• Route changes visible in monitoring

• No cross-enterprise routes visible

• All displayed routes are reachable via ping

Monitoring / Verification:

• Route Monitoring displays complete and accurate route tables per enterprise

• Route changes propagate when applied

• Enterprise isolation maintained in route tables

TC-21 — Alarm and Alarm Notification via Email

Objective: Verify that the Graphiant portal generates alarms for device and network fault conditions, and that alarm notifications are correctly sent to configured email recipients.

Pre-conditions:

• All site devices activated (TC-06 completed)

• Email recipient configured in portal for alarm notifications

• Access to recipient email inbox to verify delivery

Steps:

1. Navigate to portal Settings → Notifications/Alarms.

2. Verify at least one email recipient is configured for alarm events.

3. Disable WAN interface on San Jose device to trigger a fault alarm.

4. Verify alarm generated in portal Alarm view with: device name, alarm type, severity, timestamp.

5. Check recipient email inbox. Verify alarm notification email received with all details.

6. Re-enable WAN interface on San Jose. Verify alarm cleared in portal.

7. Verify alarm cleared notification email received.

8. Repeat for different alarm types (LAN down, tunnel down, service failure) on other devices.

Expected Result:

• Alarms generated correctly for fault conditions

• Email notifications sent for both fault and recovery events

• Email contains all required information (device, alarm type, severity, timestamp)

• Alarm cleared notifications sent when faults resolved

Monitoring / Verification:

• Portal Alarm view shows active and cleared alarms

• Email notifications received for fault and recovery events

• Alarm notifications contain accurate and complete information

TC-22 — Site Device Reboot via Portal:  Reboot Action and Recovery Monitoring

Objective: Verify that site devices can be rebooted via the portal and that the device status transitions and recovery are properly monitored.

Pre-conditions:

• All enterprise-1 sites activated (TC-06 completed)

• Active traffic flowing through devices (TC-12 completed)

• Portal monitoring operational

Steps:

1. Navigate to Ashburn device → Management section.

2. Verify active traffic from San Jose to Ashburn in WAN monitoring.

3. Click "Reboot Device" or "Restart" button.

4. Confirm reboot action in portal dialog.

5. Monitor device status transitions: Online → Rebooting → Online.

6. Verify reboot progress visible in portal status panel.

7. Verify control plane disconnects during reboot and reconnects after.

8. Verify data plane restores after reboot (traffic resumes).

9. Verify device remains associated with enterprise and site configuration.

10. Repeat for San Jose and Frankfurt devices.

Expected Result:

• Device transitions through Rebooting state

• Device returns to Online status

• Control plane reconnects after reboot

• Data plane traffic resumes

• Configuration persists after reboot

Monitoring / Verification:

• Portal shows device status transition (Online → Rebooting → Online)

• Site Health Dashboard reflects state changes

• Traffic resumes in WAN monitoring after reboot

TC-23 — Traffic Recovery After Site Device Reboot

Objective: Verify that traffic automatically resumes and normalizes after a site device reboot without manual intervention.

Pre-conditions:

• All enterprise-1 sites activated (TC-06 completed)

• Continuous traffic flowing between sites (TC-12 completed)

• Device reboot capability verified (TC-22 completed)

Steps:

1. Establish active traffic flow from San Jose to Ashburn.

2. Monitor traffic metrics in WAN monitoring (throughput, packet count).

3. Reboot San Jose device via portal (TC-22).

4. Monitor traffic during reboot:

   • Verify brief traffic interruption during reboot

   • Verify traffic resumes after device comes Online

5. Verify traffic metrics restore to pre-reboot levels in WAN monitoring.

6. Verify no packet loss or errors after traffic resumes.

7. Verify connection state maintained or gracefully re-established.

Expected Result:

• Traffic interrupts during reboot

• Traffic automatically resumes after device Online

• Traffic metrics return to normal levels

• No manual intervention required

• Connection stable post-reboot

Monitoring / Verification:

• WAN monitoring shows traffic interruption during reboot

• WAN monitoring shows traffic resumption post-reboot

• Throughput metrics return to baseline

TC-24 — Troubleshooting:  Ping Test Between Sites

Objective: Verify that the portal ping tool accurately tests reachability and latency between enterprise-1 sites.

Pre-conditions:

• All enterprise-1 sites activated (TC-06 completed)

• Site-to-site connectivity verified (TC-12 completed)

• Portal diagnostics tools accessible

Steps:

1. Navigate to San Jose device → Diagnostics → Ping Test.

2. Enter destination IP: Ashburn LAN IP (e.g., 10.1.x.x).

3. Start ping test.

4. Verify ping responses received with:

   • Source: San Jose IP

   • Destination: Ashburn IP

   • Response time/RTT

   • Status: Success

5. Repeat ping from San Jose to Frankfurt LAN IP.

6. Repeat ping from Ashburn to Frankfurt LAN IP.

7. Disable Ashburn LAN interface. Run ping San Jose → Ashburn. Verify no response.

8. Re-enable Ashburn LAN interface. Verify ping responds.

Expected Result:

• All site-to-site pings return successful responses

• Response times consistent and reasonable

• Disabled interface shows no response

• Re-enabled interface returns to responding

Monitoring / Verification:

• Portal ping tool shows successful responses for active paths

• No response when path is down

• Response times displayed accurately

TC-25 — Troubleshooting:   Traceroute from Device via Portal

Objective: Verify that the portal traceroute tool accurately displays the network path from a device to a destination.

Pre-conditions:

• All site devices activated (TC-06 completed)

• Connectivity verified (TC-07 completed)

• Cloud VPCs attached to GW (TC-10 completed)

Steps:

1. Navigate to San Jose device → Diagnostics → Traceroute.

2. Enter destination: Ashburn LAN IP. Start traceroute.

3. Verify traceroute output shows hops with latency for each hop.

4. Confirm final hop reaches Ashburn.

5. Run traceroute San Jose → Azure VPC. Verify path includes CH and GW.

6. Run traceroute San Jose → AWS VPC. Verify path includes CH and GW.

7. Run traceroute Ashburn → Frankfurt. Verify expected path.

8. Disable Ashburn WAN interface. Run traceroute San Jose → Ashburn. Verify no response or alternate path.

Expected Result:

• Traceroute displays all hops to destination

• Latency shown for each hop

• Cloud destination paths include GW at CH

• Disabled paths show no response

Monitoring / Verification:

• Portal traceroute shows complete path to destinations

• Hop details (IP, latency) displayed accurately

TC-26 — Troubleshooting:  Packet Capture on Device Interface

Objective: Verify that the portal packet capture tool can capture traffic on device interfaces and display packet details for troubleshooting.

Pre-conditions:

• All enterprise-1 sites activated (TC-06 completed)

• Connectivity verified (TC-07 completed)

• Traffic flowing between sites (TC-12 completed)

Steps:

1. Navigate to San Jose device → Diagnostics → Packet Capture.

2. Select LAN interface. Set filter for traffic generator source IP.

3. Start packet capture. Send test traffic.

4. Verify captured packets display:

   • Source IP, Destination IP

   • Protocol (TCP/UDP/ICMP)

   • Port numbers

   • Packet size

5. Verify packet headers visible (Ethernet, IP, TCP/UDP headers).

6. Stop capture after sufficient packets collected.

7. Run DIA traffic capture on WAN interface. Verify DIA traffic on correct interface.

8. Repeat for Ashburn and Frankfurt devices.

Expected Result:

• Packet capture shows correct source/destination IPs and protocols

• LAN interface captures internal traffic

• WAN interface captures external/DIA traffic

• Packet headers display correctly

Monitoring / Verification:

• Packet capture displays correct traffic details

• Captured packets match expected traffic profile

• Interface source correctly identified

TC-27 — Traffic Policy:  Gold, Silver, Bronze; Custom Applications

Objective: Verify that traffic classes (Gold, Silver, Bronze) and custom applications can be configured with traffic steering for enterprise overlay traffic (site-to-site), DIA breakout, and cloud traffic. Verify correct classification in portal monitoring.

Pre-conditions:

• All enterprise-1 sites activated (TC-06 completed)

• Connectivity verified (TC-07 completed)

• Device configuration complete (TC-11 completed)

• DIA policy configured on devices (TC-13 completed)

Steps:

1. Navigate to San Jose device → Configuration → Traffic Policy.

2. Create Gold class: Real-time traffic, highest priority, no bandwidth limit.

3. Create Silver class: Business apps, minimum bandwidth guarantee, standard priority.

4. Create Bronze class: Bulk transfer, lowest priority, bandwidth cap (e.g., 5 Mbps).

5. Create custom application: Business-App matched by TCP port 5000, destination 10.1.1.0/24, assign to Silver class.

6. Create DIA Steering Policy: Configure policy to steer DIA-bound traffic (public internet destinations) to local DIA gateway with no bandwidth limit (Gold equivalent priority)

7. Apply all policies to enterprise-1 devices.

Traffic Classification Testing:

8. Gold Traffic (Real-time): Send real-time traffic (e.g., voice/video). Verify Gold classification in WAN monitoring. Confirm high priority handling.

9. Silver Traffic (Business-App): Send business app traffic (TCP 5000). Verify Silver classification and Business-App identification.

10. Bronze Traffic (Bulk): Send bulk transfer. Verify Bronze classification and bandwidth cap enforced.

11. DIA Traffic Steering: Send internet-bound traffic (public destination). Verify steered to DIA. Confirm exits via local gateway, not Graphiant tunnel.

Overlay Traffic (Site-to-Site) Testing:

12. Gold Overlay: Send Gold-class traffic from San Jose to Ashburn (overlay traffic). Verify routed via Graphiant tunnel with high priority

13. Silver Overlay: Send Silver-class traffic (TCP 5000) from San Jose to Ashburn. Verify correct classification and routing

14. Bronze Overlay: Send Bronze-class traffic from San Jose to Ashburn. Verify bandwidth cap enforced on overlay path

15. Verify hit counters for each class in portal monitoring:

    • Gold (Real-time + DIA)

    • Silver (Business-App overlay)

    • Bronze (Bulk overlay)

Expected Result:

• Gold, Silver, Bronze classes correctly configured

• Business-App custom application created and identified

• DIA traffic steered to local gateway with Gold priority

• Overlay traffic between sites classified and prioritized correctly

• All traffic types visible in monitoring with accurate hit counters

• DIA and overlay traffic handled independently

Monitoring / Verification:

• WAN monitoring shows Gold, Silver, Bronze classifications

• DIA traffic visible on DIA interface, not Graphiant tunnel

• Overlay traffic visible on Graphiant tunnel

• Business-App visible in application list with correct traffic

• Hit counters per class display accurate counts

• DIA steering and overlay routing work simultaneously

TC-28 — Traffic policy:  Path Steering Based on Application Type (Overlay vs DIA)

Objective: Verify that traffic is steered to different paths based on application type: Internet-bound traffic routes to Overlay (Central Breakout) vs DIA (Local Breakout)

Pre-conditions:

• All enterprise-1 sites activated (TC-06 completed)

• Cloud VPCs attached to GW (TC-10 completed)

• Device configuration complete (TC-11 completed)

Steps:

1. Navigate to San Jose device → Configuration → Traffic Policy.

2. Create path steering policy:

   • Match an Internet App and then configure a traffic policy with the Action Exit via DIA

   • Match another Internet App and then configure a traffic policy with the Action Exit via Graphiant for Central Breakout

3. Send Internet-bound traffic . Verify path via traceroute.

4. Send on-prem traffic . Verify path via traceroute goes to remote site only.

5. Verify both traffic types flow simultaneously on same WAN link.

6. Confirm hit counters show traffic matched to each policy rule.

Expected Result:

• Internet-bound traffic steered from sites directly to Internet for the App based on the Action Exit via DIA

• Internet bound traffic steered to other enterprise sites for the App based on the Action Exit via Graphiant

• Both traffic types flow without conflict

• Hit counters show traffic matched to correct policy rules

Monitoring / Verification:

• WAN monitoring shows both Local and Central Breakout traffic flows

• Traceroute confirms different paths based on application type

• Hit counters display accurate traffic matching

TC-29 — Traffic Policy:  DSCP Marking Preservation End-to-End

Objective: Verify that DSCP markings applied at source device are preserved end-to-end through the Graphiant network to destination device.

Pre-conditions:

• All enterprise-1 sites activated (TC-06 completed)

• Connectivity verified (TC-07 completed)

• Device configuration complete (TC-11 completed)

Steps:

1. Navigate to San Jose device → Configuration → Traffic Policy.

2. Configure DSCP marking policy:

   • Real-time traffic: Mark with DSCP EF (46)

   • Business apps: Mark with DSCP AF31 (26)

3. Apply policy to San Jose device.

4. Send real-time traffic from San Jose to Ashburn. Capture packets on Ashburn. Verify DSCP EF marking preserved in captured packets.

5. Send business app traffic from San Jose to Ashburn. Capture packets on Ashburn. Verify DSCP AF31 marking preserved.

6. Repeat for San Jose → Frankfurt path.

7. Verify DSCP markings unchanged from source to destination.

Expected Result:

• DSCP EF (46) preserved on real-time traffic end-to-end

• DSCP AF31 (26) preserved on business app traffic end-to-end

• No DSCP modification in transit

Monitoring / Verification:

• Packet capture shows DSCP markings preserved at destination

• DSCP values match applied markings

TC-30 — Traffic policy:  Bandwidth Rate Limiting per Application Class per Site

Objective: Verify that bandwidth rate limits are independently enforced per application class on each site device.

Pre-conditions:

• All enterprise-1 sites activated (TC-06 completed)

• Connectivity verified (TC-07 completed)

• Traffic classes configured (TC-27 completed)

Steps:

1. Navigate to Ashburn device → Configuration → Traffic Policy.

2. Configure Bronze class bandwidth cap: 5 Mbps.

3. Configure Silver class minimum bandwidth guarantee: 10 Mbps.

4. Apply policy to Ashburn device.

5. From Ashburn, send bulk transfer (Bronze class) at 50 Mbps. Verify capped at 5 Mbps in WAN monitoring.

6. Simultaneously send business app traffic (Silver class). Verify Silver traffic unaffected and receives minimum 10 Mbps.

7. Repeat configuration on Frankfurt device.

8. Send bulk transfer from Frankfurt at 50 Mbps. Verify independently capped at 5 Mbps on Frankfurt.

9. Verify Ashburn and Frankfurt bandwidth limits enforced independently (not affecting each other).

Expected Result:

• Bronze class capped at 5 Mbps on Ashburn

• Bronze class capped at 5 Mbps on Frankfurt independently

• Silver class unaffected by Bronze rate limit

• Per-site enforcement verified

Monitoring / Verification:

• WAN monitoring shows Bronze traffic capped at 5 Mbps per site

• Silver traffic maintains minimum bandwidth

• Rate limits per-site and independent

TC-31 — Traffic policy:  Application Visibility and Classification; Policy Stats

Objective: Verify that portal WAN monitoring correctly identifies and classifies all applications per site with policy statistics.

Pre-conditions:

• All site devices activated (TC-06 completed)

• Connectivity verified (TC-07 completed)

• Traffic policies configured (TC-27 completed)

Steps:

1. Navigate to San Jose device → WAN Monitoring.

2. Send simultaneous traffic: Real-time (Gold), Business-App (Silver), Bulk transfer (Bronze).

3. Verify WAN monitoring displays:

   • Application name and classification (Gold/Silver/Bronze)

   • Traffic volume per application

   • Percentage breakdown per class

   • WAN interface where traffic flows

4. Verify policy statistics display:

   • Hit counters for each policy rule

   • Bytes matched per policy

   • Packets matched per policy

5. Repeat for Ashburn, Frankfurt, and Tokyo devices.

6. Verify all application types correctly classified in monitoring per site.

Expected Result:

• All applications correctly identified and classified

• Policy hit counters accurate and updating

• Traffic volume breakdown visible per application

• Statistics consistent across all sites

Monitoring / Verification:

• WAN monitoring shows all application types with correct classification

• Policy hit counters display accurate counts

TC-32 — Zone-Based Firewall Policy:  Permit and Deny LAN to DIA for Certain Applications

Objective: Verify that zone-based firewall policies can permit and deny specific applications from LAN to DIA based on application type.

Pre-conditions:

• All enterprise-1 sites activated (TC-06 completed)

• DIA policy configured (TC-13 completed)

• Device configuration complete (TC-11 completed)

Steps:

1. Navigate to San Jose device → Configuration → Firewall Policy.

2. Define LAN and DIA zones.

3. Create inter-zone policy: Permit TCP 443 (HTTPS) from LAN to DIA, Deny all other traffic.

4. Apply policy to San Jose device.

5. Send HTTPS traffic from San Jose LAN to DIA. Verify permit and traffic flows.

6. Send TCP 23 (Telnet) from San Jose LAN to DIA. Verify deny.

7. Verify permit and deny hit counters in portal firewall monitoring.

8. Verify deny logs contain source IP, destination IP, protocol, port, and action.

Expected Result:

• HTTPS traffic permitted from LAN to DIA

• Telnet traffic denied from LAN to DIA

• Hit counters and deny logs accurate

Monitoring / Verification:

• Firewall monitoring shows permit and deny hit counters

• Deny logs display full packet details (source, destination, protocol, port)

TC-33 — Zone-Based Firewall:  Intra-Zone Traffic Policy (LAN to LAN) - Allow/Deny/Reject/Inspect

Objective: Verify that traffic within the same LAN zone is handled correctly with intra-zone firewall policies using different action types (Allow, Deny, Reject, Inspect). Demonstrate the differences between unidirectional (Allow, Deny, Reject) and bidirectional (Inspect) traffic handling.

Pre-conditions:

• All enterprise-1 sites activated (TC-06 completed)

• Connectivity verified (TC-07 completed)

• Device configuration complete (TC-11 completed)

• Zone-based firewall accessible via portal

Firewall Action Types — Reference:

Steps:

Part A: Create Intra-Zone Policy with Allow Action (Unidirectional)

1. Navigate to San Jose device → Configuration → Firewall Policy

2. Define LAN zone encompassing all LAN interfaces

3. Create intra-zone policy rule 1:

   • Source: LAN zone (Host A)

   • Destination: LAN zone (Host B)

   • Protocol: TCP

   • Port: 443 (HTTPS)

   • Action: Allow

   • Direction: Unidirectional (Host A → Host B only)

   • Logging: Enabled

4. Apply policy to San Jose device

5. Send HTTPS traffic (TCP 443) from Host A → Host B within LAN zone

6. Verify Allow Action (Unidirectional):

   • Forward traffic Host A → Host B flows successfully

   • Host B receives traffic

   • Return traffic Host B → Host A is BLOCKED (not allowed by this rule)

   • Host B cannot send response back to Host A

   • Application hangs waiting for response

   • Firewall logs show "Allow" for Host A → Host B only

   • Hit counter increments for forward direction only

Part B: Create Intra-Zone Policy with Deny Action (Unidirectional)

7. Create intra-zone policy rule 2:

   • Source: LAN zone

   • Destination: LAN zone

   • Protocol: TCP

   • Port: 8080 (HTTP alternate)

   • Action: Deny

   • Direction: Unidirectional

   • Logging: Enabled

8. Apply policy to San Jose device

9. Send traffic (TCP 8080) within LAN zone

10. Verify Deny Action (Unidirectional):

    • Traffic silently dropped in matching direction

    • Sender receives timeout (no ICMP/TCP response)

    • Application-level timeout occurs (typically 30-60 seconds)

    • Firewall logs show "Deny" entries

    • Sender unaware why connection failed

    • Hit counter increments for this rule

Part C: Create Intra-Zone Policy with Reject Action (Unidirectional)

11. Create intra-zone policy rule 3:

    • Source: LAN zone

    • Destination: LAN zone

    • Protocol: TCP

    • Port: 3389 (RDP)

    • Action: Reject

    • Direction: Unidirectional

    • Logging: Enabled

12. Apply policy to San Jose device

13. Send traffic (TCP 3389) within LAN zone

14. Verify Reject Action (Unidirectional):

    • Traffic immediately rejected

    • Sender receives TCP RST (connection reset) response

    • Sender immediately aware connection refused

    • Sender does NOT wait for timeout

    • Firewall logs show "Reject" entries with RST sent notation

    • Hit counter increments for this rule

    • Response time much faster than Deny action

Part D: Create Intra-Zone Policy with Inspect Action (Bidirectional)

15. Create intra-zone policy rule 4:

    • Source: LAN zone (Host A)

    • Destination: LAN zone (Host B)

    • Protocol: TCP

    • Port: 443 (HTTPS with inspection)

    • Action: Inspect

    • Direction: Bidirectional

    • Inspection Profile: SSL/TLS inspection (if available)

    • Logging: Enabled

16. Apply policy to San Jose device

17. Send encrypted HTTPS traffic (TCP 443) from Host A with inspection

18. Verify Inspect Action (Bidirectional):

    • Forward traffic Host A → Host B payload examined for threats

    • If no threats detected → traffic allowed Host A → Host B

    • Return traffic Host B → Host A automatically ALLOWED (bidirectional)

    • Host B can send response back to Host A without explicit rule

    • Application completes successfully (bidirectional communication)

    • Firewall logs show "Inspect" entries with inspection details

    • Inspection results logged (threats detected, protocol violations, etc.)

    • If threat detected in either direction → traffic blocked

    • Hit counter shows inspection counts for both directions

Part E: Demonstrate Directional Difference

19. Setup Scenario with Allow:

    • Rule: LAN Host A → LAN Host B on TCP 443 = Allow

    • Test 1: Host A sends to Host B → Succeeds ✓

    • Test 2: Host B sends to Host A → Fails (blocked) ✗

    • Reason: Unidirectional rule only permits A→B

20. Setup Scenario with Inspect:

    • Rule: LAN Host A ↔ LAN Host B on TCP 443 = Inspect (bidirectional)

    • Test 1: Host A sends to Host B → Inspected, then succeeds ✓

    • Test 2: Host B sends to Host A → Automatically allowed succeeds ✓

    • Reason: Inspect enables bidirectional allow after inspection passes

Part F: Combined Policy Testing

21. Send simultaneous traffic across all four action types:

    • TCP 443 (Allow): Host A → Host B flows; Host B → Host A blocked

    • TCP 8080 (Deny): Silently drops, timeout occurs

    • TCP 3389 (Reject): Immediately rejected with RST

    • TCP 443 (Inspect): Bidirectional flow after inspection (A↔B both succeed)

22. Verify all four actions function independently and correctly

Part G: Monitoring and Logging Verification

23. Navigate to firewall monitoring view

24. Verify detailed logs showing:

    • Allow logs: Unidirectional traffic allowed, return traffic noted as blocked

    • Deny logs: Traffic silently dropped, no response (timeout)

    • Reject logs: Traffic rejected with explicit response (RST sent)

    • Inspect logs: Bidirectional flow allowed, inspection details, threat analysis

25. Verify hit counters show directional awareness:

    • Allow rule: Hits only for allowed direction

    • Deny rule: Hits for blocked direction

    • Reject rule: Hits for rejected direction

    • Inspect rule: Hits for both directions if successful

Expected Result:

• Allow Action (Unidirectional): Forward traffic flows, return traffic blocked unless separate rule exists

• Deny Action (Unidirectional): Traffic silently blocked, sender experiences timeout

• Reject Action (Unidirectional): Traffic immediately rejected, sender notified via TCP RST

• Inspect Action (Bidirectional): Both directions allowed after payload inspection passes; if threat detected in either direction, traffic blocked

• All four actions function correctly within same intra-zone policy

• Firewall logs clearly distinguish directionality per action

• Hit counters accurately track directional flow

• Return traffic handling differs significantly between Allow and Inspect

Monitoring / Verification:

• Firewall monitoring shows directional behavior per action

• Allow rule permits only forward direction; return traffic blocked

• Deny rule silently blocks specific direction

• Reject rule explicitly rejects specific direction

• Inspect rule automatically permits bidirectional flow after inspection

• Hit counters show directional awareness

• Log entries include directionality (A→B vs B→A)

• Return traffic handling demonstrates key differences

TC-34 — Zone-Based Firewall:  DIA to LAN (Inbound Deny by Default)

Objective: Verify that unsolicited inbound traffic from DIA to LAN is denied by default, while return traffic from established outbound sessions is permitted via stateful inspection.

Pre-conditions:

• All enterprise-1 sites activated (TC-06 completed)

• DIA policy configured (TC-13 completed)

• Zone-based firewall configured (TC-32 completed)

Steps:

1. Navigate to San Jose device → Configuration → Firewall Policy.

2. Define LAN and DIA zones.

3. Create inter-zone policy: DIA to LAN deny by default (implicit deny).

4. Apply policy to San Jose device.

5. From external DIA host, send unsolicited TCP SYN and UDP to San Jose LAN. Verify deny.

6. From San Jose LAN, initiate TCP session to DIA destination. Verify connection established.

7. Verify return traffic from DIA destination permitted (stateful).

8. Verify deny logs show DIA→LAN zone direction with source/destination IPs, protocol, action.

Expected Result:

• Unsolicited inbound DIA→LAN traffic denied

• Stateful return traffic from established sessions permitted

• Deny logs contain full packet details

Monitoring / Verification:

• Firewall monitoring shows deny for unsolicited DIA→LAN traffic

• Return traffic allowed for established sessions

• Deny logs display DIA→LAN zone direction and packet details

TC-35 — Zone-Based Firewall:  Multi-site Zone Policy Consistency

Objective: Verify that the same zone-based firewall policy is consistently applied and enforced across all enterprise-1 site devices.

Pre-conditions:

• All enterprise-1 sites activated (TC-06 completed)

• Zone-based firewall policies configured (TC-32, TC-33, TC-34 completed)

Steps:

1. Navigate to enterprise-1 → Firewall Policy.

2. Create zone policy: Permit TCP 443/80 from LAN to DIA, deny all else.

3. Apply policy to San Jose, Ashburn, and Frankfurt devices.

4. Send HTTPS to DIA on San Jose. Verify permit.

5. Send HTTPS to DIA on Ashburn. Verify permit.

6. Send HTTPS to DIA on Frankfurt. Verify permit.

7. Send non-permitted traffic on all three sites. Verify deny on all sites.

8. Verify hit counters consistent across all three sites.

Expected Result:

• Zone policy consistently applied across all three sites

• Identical permit/deny behavior on each site

• Hit counters reflect consistent policy enforcement

Monitoring / Verification:

• Firewall monitoring shows identical policy behavior across all sites

• Hit counters display consistent traffic matching per site

TC-36 — Zone-Based Firewall Policy:  Policy Stats

Objective: Verify that the portal firewall monitoring view accurately displays firewall policy hit counters, permit/deny statistics, and denial logs across all devices.

Pre-conditions:

• All site devices activated (TC-06 completed)

• Connectivity verified (TC-07 completed)

• Zone-based firewall policies configured (TC-32, TC-33, TC-34, TC-35 completed)

Steps:

1. Generate mixed permitted and denied traffic from San Jose, Ashburn, and Frankfurt simultaneously.

2. Navigate to portal Firewall Monitoring view.

3. Verify permit and deny hit counters displayed for each device.

4. Verify statistics show:

   • Number of packets permitted per policy

   • Number of packets denied per policy

   • Bytes matched per policy

5. Verify deny logs contain:

   • Timestamp, source IP, destination IP, protocol, port, action, policy name

6. Verify statistics update in real-time as traffic flows.

7. Verify hit counters aggregated across all sites.

Expected Result:

• Permit and deny hit counters accurate and updating

• Deny logs contain all required fields

• Statistics visible and accurate across all sites

Monitoring / Verification:

• Firewall monitoring displays permit/deny hit counters per policy

• Deny logs show full packet details

• Statistics update in real-time

TC-37 — Extranet:  Route Sharing, Bidirectional Traffic, and Non-Extranet Segment Isolation

Objective: Verify that Extranet policies enable controlled route sharing between different LAN segments with firewall zone-pair policies permitting data traffic, tested with basic connectivity (ping) and bandwidth/stability testing (iperf).

Pre-conditions:

• All enterprise-1 sites and GW activated (TC-06, TC-09 completed)

• Multiple LAN segments configured on edges (TC-03 completed)

• GW configured with separate LAN segment (different from edge sites)

• Cloud VPCs attached to GW (TC-10 completed)

• Zone-based firewall configured (TC-32, TC-33, TC-34 completed)

Steps:

1. Segment Configuration: Verify edge sites (San Jose, Ashburn, Frankfurt) on segment-A (10.1.0.0/16). Verify GW on segment-B (10.2.0.0/16).

2. Pre-Extranet Test - Ping: Ping segment-A (San Jose) to segment-B (GW). Verify no response.

3. Create Extranet Policy: Configure Extranet policy to share segment-A and segment-B prefixes.

4. Configure Firewall Zone-Pair: Create zone-pair policy between segment-A zone and segment-B zone. Permit TCP 443 and TCP 80 for data traffic between zones. Deny all other traffic.

5. Apply Zone Policy: Apply zone-pair policy to all enterprise-1 devices.

6. Verify Route Sharing: Confirm segment-A prefix appears in Route Monitoring for segment-B. Confirm segment-B prefix appears in Route Monitoring for segment-A.

7. Bidirectional Test - Ping: Ping San Jose (segment-A) to GW (segment-B). Verify successful response.

8. Bidirectional Test - Reverse Ping: Ping GW (segment-B) to San Jose (segment-A). Verify successful response.

9. iperf TCP San Jose → GW: Run iperf TCP on TCP 443. Record bandwidth.

10. iperf TCP GW → San Jose: Run iperf TCP in reverse direction. Verify symmetrical bandwidth.

11. iperf UDP San Jose → GW: Run iperf UDP. Record jitter and packet loss.

12. Denied Traffic Test: Attempt TCP 8080 from San Jose to GW. Verify deny (not permitted by firewall policy).

13. Route Leak Prevention: Verify segment-C (if on different segment) does NOT appear in Route Monitoring for segment-B.

14. Remove Extranet Policy: Delete Extranet policy. Verify routes withdrawn. Ping segment-A to segment-B. Verify no response.

15. Verify Firewall Blocks: Confirm firewall policy logs show denied traffic when Extranet removed.

Expected Result:

• Extranet enables route sharing between segment-A and segment-B

• Firewall zone-pair permits only approved traffic (TCP 443/80) between segments

• Bidirectional ping and iperf flows successful for permitted applications

• Non-permitted traffic (TCP 8080) blocked by firewall

• Non-shared segments remain isolated

• Route withdrawal removes connectivity when Extranet removed

Monitoring / Verification:

• Route Monitoring shows shared prefixes only with Extranet policy

• Firewall monitoring shows permit for TCP 443/80 and deny for TCP 8080

• Bidirectional ping and iperf metrics documented

• Zone-pair policy consistently enforced

• Route withdrawal on policy removal

TC-38 — Extranet:  Policy Removal and Route Withdrawal

Objective: Verify that Extranet policy removal results in route withdrawal and traffic stops completely between previously connected segments.

Pre-conditions:

• Extranet policy configured and active (TC-37 completed)

• Bidirectional traffic flowing between segments

• Route Monitoring showing shared routes

Steps:

1. Verify active Extranet policy in portal. Confirm routes shared between segment-A (edges) and segment-B (GW).

2. Verify bidirectional traffic flowing between segments.

3. Delete the Extranet policy from portal.

4. Monitor Route Monitoring view. Verify shared routes completely withdrawn from both segments.

5. Attempt ping from San Jose (segment-A) to GW (segment-B). Verify no response.

6. Verify traffic generator shows zero connectivity between segments.

7. Re-add the Extranet policy.

8. Verify routes reappear in Route Monitoring.

9. Verify bidirectional traffic resumes.

Expected Result:

• Routes completely withdrawn after policy removal

• Traffic completely stops between segments (no connectivity)

• Routes restored after policy re-addition

• Traffic completely resumes after policy restoration

Monitoring / Verification:

• Route Monitoring shows complete route withdrawal on policy removal

• Route Monitoring shows complete route restoration on policy re-addition

• Traffic connectivity stops and starts based on Extranet policy presence

TC-39 — Site-to-Site Traffic:  Different LAN Segments

Objective: Verify that traffic between sites on different LAN segments requires Extranet policy to flow, tested with basic connectivity (ping) and bandwidth/stability testing (iperf).

Pre-conditions:

• All enterprise-1 sites activated (TC-06 completed)

• Multiple LAN segments configured on different sites (TC-03 completed)

• San Jose on segment-A (10.1.0.0/16), Ashburn on segment-B (10.2.0.0/16)

• Firewall zone policies configured (TC-32, TC-33, TC-34 completed)

Steps:

1. Pre-Extranet Test - Ping: Verify San Jose on segment-A and Ashburn on segment-B in Route Monitoring. Ping San Jose to Ashburn. Verify no response (segments not shared).

2. Create Extranet Policy: Create Extranet policy to share segment-A and segment-B.

3. Configure Firewall Zone-Pair: Configure firewall zone-pair to permit TCP 443 between segments.

4. Apply Policy: Apply policy to both sites.

5. Connectivity Test - Ping: Ping San Jose to Ashburn on TCP 443. Verify successful response.

6. iperf TCP San Jose → Ashburn: Run iperf TCP on TCP 443. Record bandwidth.

7. iperf TCP Ashburn → San Jose: Run iperf TCP in reverse. Verify symmetrical bandwidth.

8. iperf UDP San Jose → Ashburn: Run iperf UDP. Record jitter and packet loss.

9. Denied Traffic Test: Attempt TCP 8080 from San Jose to Ashburn. Verify deny (firewall blocks).

10. Firewall Hit Counters: Verify hit counters show permits and denies in firewall monitoring.

11. Remove Extranet Policy: Delete Extranet policy. Verify no response on ping (traffic stops).

12. iperf Test After Removal: Attempt iperf. Verify no connectivity.

Expected Result:

• Traffic blocked without Extranet policy

• Traffic flows after Extranet policy with firewall permits for TCP 443

• iperf TCP shows measurable bandwidth

• iperf UDP shows acceptable jitter

• Non-permitted traffic (TCP 8080) denied by firewall

• Traffic stops when Extranet policy removed

Monitoring / Verification:

• Route Monitoring shows separate segment routes without Extranet

• Route Monitoring shows shared routes with Extranet policy

• Firewall monitoring shows permit/deny statistics

• ping and iperf metrics documented

• Traffic connectivity matches Extranet policy presence

TC-40 — Multi-Cloud:  Azure VPC to AWS VPC on Different LAN Segments Requires Extranet

Objective: Verify that Azure VPC and AWS VPC on different LAN segments cannot communicate without Extranet policy, and can communicate after Extranet policy is configured with firewall zone-pair rules, tested with ping and iperf.

Pre-conditions:

• GW node provisioned and operational at CH (TC-09 completed)

• Azure VPC attached to GW on segment-B (10.2.0.0/16) (TC-10 completed)

• AWS VPC attached to GW on segment-B (10.2.0.0/16) (TC-10 completed)

• Enterprise-1 sites on segment-A (10.1.0.0/16) (TC-03 completed)

• Zone-based firewall configured (TC-32, TC-33, TC-34 completed)

Steps:

1. Verify Segment Assignment: Confirm Azure VPC on segment-B and AWS VPC on segment-B in Route Monitoring.

2. Pre-Extranet Test - Ping: Attempt ping from Azure VPC to AWS VPC. Verify no response (different segments, no Extranet).

3. Create Extranet Policy: Create Extranet policy to share segment-B prefixes between Azure and AWS.

4. Configure Firewall Zone-Pair: Configure firewall zone-pair to permit TCP 443 between Azure and AWS zones.

5. Apply Policy: Apply policy to GW device.

6. Connectivity Test - Ping: Ping Azure VPC to AWS VPC on TCP 443. Verify successful response.

7. Reverse Ping: Ping AWS VPC to Azure VPC on TCP 443. Verify successful response.

8. iperf TCP Azure → AWS: Run iperf TCP on TCP 443. Record bandwidth.

9. iperf TCP AWS → Azure: Run iperf TCP in reverse direction. Verify symmetrical bandwidth.

10. iperf UDP Azure → AWS: Run iperf UDP. Record jitter and packet loss.

11. iperf UDP AWS → Azure: Run iperf UDP in reverse. Verify UDP jitter acceptable.

12. Denied Traffic Test: Attempt TCP 8080 between VPCs. Verify deny (firewall blocks).

13. Remove Extranet Policy: Delete Extranet policy. Verify ping fails again.

14. iperf After Removal: Attempt iperf. Verify no connectivity.

Expected Result:

• Azure ↔ AWS blocked without Extranet policy

• Azure ↔ AWS communication flows after Extranet policy with firewall permits

• iperf TCP shows measurable bandwidth

• iperf UDP shows acceptable jitter

• Non-permitted traffic (TCP 8080) blocked by firewall

• Communication stops when Extranet policy removed

Monitoring / Verification:

• Route Monitoring shows separate segment routes without Extranet

• Route Monitoring shows shared prefixes with Extranet policy

• Firewall monitoring shows permit/deny statistics

• ping and iperf metrics documented

• Traffic connectivity matches Extranet policy presence

TC-41 — Data Assurance:  Threat Detection and GAPS Score