Graphiant Test Plan

The test plan outlines functionality testing of the Graphiant Network Services in support of customer’s business requirements and its service offerings. Graphiant provides a private global wide area network that allows customers to establish SLA based any-to-any encrypted edge connectivity, private connectivity to cloud, and business to business network over a private, massively scalable stateless data plane, with highly available control and management delivered as a service.

Equipment / Bill of Materials

Quantity	Platform	Notes
6	Lanner 1515B or Dell VEP
1	VM GNOS image
1	Graphiant Portal

2 (minimum)	Internet DIA circuits	DHCP and/or Static
2	WAN routers	BGP
2	L3 Switches	BGP
1	WAN Emulator	Ability to inject packet loss/latency/jitter
6	Hosts/VMs	VM/hosts for testing; iPerf3
1	Syslog server	Syslog receiver
1	IPFIX server	IPFIX flow receiver
1	Azure account	Azure VNET testing (optional)

Logical Topology

Test Plan Details:

Device Onboarding via DHCP to Graphiant Service

VM Edge bring-up and on-boarding

Test No.	1	Revision:	3.1	Author:	Date:	03/2024
Hostnames:

Test Purpose:		Validate device bring-up and on-boarding to Graphiant Network
Procedure:		Connect site-3 Edge to WAN (with DHCP enabled) and LAN Log into GCS portal to view device on-board status Wait for device to show up in the portal staging screen Allow Edge into the Graphiant network from the portal Check initial base config from the portal
Passed:
Failed:
Reason for Failure:
Remarks and notes:

Device Onboarding with Static IP to Graphiant Service

Edge bring-up and on-boarding

Test No.	1.5	Revision:	3.1	Author:	Date:	03/2024
Hostnames:

Test Purpose:		Validate device bring-up and on-boarding to Graphiant Network
Procedure:		Connect site-3 Edge to WAN (no DHCP) and LAN Connect laptop to port 8 on edge Wait until you receive an IP address on the laptop Log into local web portal by going to https://192.168.1.1 Do not enter a password and click the login button Under the WAN circuits section enter “wan” under description and type a DNS under the DNS section Hit the plus (+) button to the right of interfaces Select GigabitEthernet1 on the left Click the static option in the IPv4 section Enter the IP address and gateway bits Enter the gateway router IP Click the home button in the upper left corner Click the Review button in the upper right corner Click the words “Interfaces” and “WAN Circuits” in the lower section Verify all changes look correct for IP, mask, gateway, and DNS Click Apply in the upper right corner Log into GCS portal (WWT tenant) to view device on-board status Wait for device to show up in the portal staging screen Allow Edge into the Graphiant network from the portal Check initial base config from the portal
Passed:
Failed:
Reason for Failure:
Remarks and notes:

Edge Device One-Touch Upgrade

Test No.	2	Revision:	3.1	Author:	Date:	03/2024
Hostnames:

Test Purpose:		Graphiant Edges can be upgraded ah-hoc or scheduled through the Graphiant portal. This test demonstrates the upgrade process
Procedure:		Go to Service Upgrade on the GCS portal, then click on All Devices Check under Upgrade Status and find a device with the status “Upgrade Available” Select the device, and click “Upgrade” Leave “Upgrade Version” at “Latest” Click Upgrade Now Observe progress and check device after upgrade completes
Passed:
Failed:
Reason for Failure:
Remarks and notes:

Device Base Configuration

Edge basic configuration through Graphiant portal

Test No.	3	Revision:	3.1	Author:	Date:	03/2024
Hostnames:

Test Purpose:		Configure basic device information and connectivity on all platforms from Graphiant portal
Procedure:		Configure hostnames, LAN and WAN IP addresses on HW platforms Site-4 WAN – DHCP Site-4 1st LAN – corp Configure hostname, LAN Segment of “corp” and static IP addresses on platform (WAN is DHCP no need for configuration) Verify config pushes and configuration versions in Graphiant portal
Passed:
Failed:
Reason for Failure:
Remarks and notes:

Validation of Topology and Baseline

Record routing and reachability information from all sites

Test No.	6	Revision:	3.1	Author:	Date:	03/2024
Hostnames:

Test Purpose:		Graphiant network automatically passes routing information for connected networks between all sites if they are on the same LAN Segment. This test verifies that all configured networks and interfaces are visible and reachable as expected
Procedure:		From the Graphiant portal go to Monitor page and select each Edge to verify routing is available: Monitor -> Select Edge -> Routing -> Select LAN Segment Repeat for both Corp and Guest segments From the Graphiant portal go to Troubleshooting page and select each Edge to verify ping reachability: Troubleshooting -> Select Edge -> ping -> Select LAN Segment -> Select source interface and IP address, ping other Edge interfaces in the same LAN segment Repeat for both Corp and Guest segments
Passed:
Failed:
Reason for Failure:
Remarks and notes:

Configure BGP Routing with Customer Routers / L3 Switches

Test No.	7	Revision:	3.1	Author:	Date:	03/2024
Hostnames:

Test Purpose:		Graphiant network can establish BGP routing with third party routers and L3 switches, and automatically redistribute this routing information across the Graphiant control plane for sites on the same LAN Segment. This test verifies that all learned BGP routes are propagated, and networks are visible and reachable
Procedure:		Configure eBGP at Site-1 and Site-3 with L3 switches on the Corp LAN segment Enable redistribution of BGP routes into the Graphiant core. Configure Edge -> Configure Services -> Routing Protocols & Filters -> Chose Graphiant as the Routing Protocol. Under Route Redistribution turn BGP to “On” Verify routes that routes being sent from the L3 switches/routers are being propagated in the routing table. On the Graphiant portal go to Monitor page and select each Edge to verify routes are seen Monitor -> Select Edge -> Routing -> Select LAN Segment
Passed:
Failed:
Reason for Failure:
Remarks and notes:

Cloud Gateway Integration

Bring up Direct Private Connectivity to Customer’s Cloud Region(s)

Test No.	8	Revision:	3.1	Author:	Date:	03/2024
Hostnames:

Test Purpose:		One of the key differentiators of the Graphiant service is the ease of connecting to all of the customer’s multi-cloud regions and workloads in a fast, simple, highly resilient and low-cost integration using the Graphiant managed gateways globally
Procedure:		Order the gateway connection through the Graphiant portal Work with Graphiant support to bring up a connection to AWS, Azure, GCP or Oracle in a customer chosen region Configure BGP between Graphiant’s gateway with cloud native routing elements (DX GW, VWAN, Azure Router or DRG) Test end-to-end traffic between cloud, on-prem, or cloud to cloud Test jumbo frame support (Optional)
Passed:
Failed:
Reason for Failure:
Remarks and notes:

Configure and Test Edge Services

Configure and Test DHCP Server

Test No.	9	Revision:	3.1	Author:	Date:	03/2024
Hostnames:

Test Purpose:		Graphiant Edge at site-3 to be a DHCP server on guest LAN segment
Procedure:		Configure DHCP server at site-3 on the Guest LAN segment Bring up a VM on that LAN segment with DHCP client Verify that it receives an IP address and all DHCP attributes are there Go to the Portal-> Monitor-> DHCP to verify DHCP summary and Leases
Passed:
Failed:
Reason for Failure:
Remarks and notes:

Configure and Test Syslog Service

Test No.	10	Revision:	3.1	Author:	Date:	03/2024
Hostnames:

Test Purpose:		Graphiant Edge can send Syslogs to any server in the customer environment that is listening for logs
Procedure:		Ensure that third-party Syslog server is up and running in Corp LAN segment and record IP address and listening port Configure Graphiant Edge at site-1 to send syslog to the syslog server Verify that logs are being received on the Syslog server Go to the Portal-> Monitor-> Local Services to verify Syslog summary information
Passed:
Failed:
Reason for Failure:
Remarks and notes:

Configure and Test IPFIX Service

Test No.	11	Revision:	3.1	Author:	Date:	03/2024
Hostnames:

Test Purpose:		Graphiant Edge can send IPFIX flow records to third party IPFIX server in the customer environment that is listening for logs
Procedure:		Ensure that third-party IPFIX server is up and running in Corp LAN segment and record IP address and listening port Configure Graphiant Edge at site-1 to send IPFIX to the IPFIX server Verify that flow records are being received on the Syslog server Go to the Portal-> Monitor-> Local Services-> to verify IPFIX summary information
Passed:
Failed:
Reason for Failure:
Remarks and notes:

Edge Redundancy

Setup BGP

Test No.	4	Revision:	3.1	Author:	Date:	03/2024
Hostnames:

Test Purpose:		Use Graphiant edges as both primary and secondary devices for the site with BGP
Procedure:		Disconnect traditional WAN path and connect Edge-B at site-1 Make sure traffic between site-1 and site-3 is going over the Graphiant Edges between these sites Configure BGP on the Edge-B at site-1 Enable BFD if supported by 3rd party L3 switch Check to make sure all the routes from other sites are now visible on Edge-B as well as Edge-A Check to make sure other sites see the site-1 routes from both Edge-A and Edge-B Use ping/traceroute to verify connectivity
Passed:
Failed:
Reason for Failure:
Remarks and notes:

Setup VRRP

Test No.	5	Revision:	3.1	Author:	Date:	03/2024
Hostnames:

Test Purpose:		Use Graphiant edges as both primary and secondary devices for the site with VRRP
Procedure:		Connect Edge-B at site-2 Configure VRRP on Edge-B at site-2 Ensure corp is primary on Edge-A and guest on Edge-B Check to make sure all the routes from other sites are now visible on Edge-B as well as Edge-A at site-2 Check to make sure other sites see the site-2 routes from both Edge-A and Edge-B Use ping/traceroute to verify connectivity
Passed:
Failed:
Reason for Failure:
Remarks and notes:

SLA Routing

Preferred Path Based on Policy

Test No.	18	Revision:	3.1	Author:	Date:	03/2024
Hostnames:

Test Purpose:		Create policy for traffic to take latent path (Gold)
Procedure:		Create policy for YouTube to be Gold class and use primary circuit-1 Create a policy for iPerf traffic as the Default class and use circuit-2 Verify the YouTube and iPerf traffic both adhere to policy
Passed:
Failed:
Reason for Failure:
Remarks and notes:

Path Change on WAN Latency Change

Test No.	19	Revision:	3.1	Author:	Date:	03/2024
Hostnames:

Test Purpose:		Observe traffic changes path based on change in WAN latency
Procedure:		Inject latency in circuit-1 such that it can no longer support “Gold” class Observe YouTube switches path from circuit-1 to circuit-2
Passed:
Failed:
Reason for Failure:
Remarks and notes:

End to End SLA with Remote Path Degradation Avoidance

Test No.	20	Revision:	3.1	Author:	Date:	03/2024
Hostnames:

Test Purpose:		Internet traffic patterns are typically asymmetric, the data will traverse different paths for upload and download directions. When problems are encountered on a particular path, most of the time it’s only affecting one of the directions. It is useful to avoid using a broken path while considering directionality and multiple paths are available. To avoid up vs down link issues independently, the local edge as well as the remote edge should be able to detect and automatically instruct the network to use the best up, or down link path using real time information gathered from TWAMP.
Procedure:		Demonstrate
Passed:
Failed:
Reason for Failure:
Remarks and notes:

Traffic Tests

Custom Application Signature for In-house Applications to Compliment DPI Engine

Test No.	12	Revision:	3.1	Author:	Date:	03/2024
Hostnames:

Test Purpose:		Most enterprise applications are not recognized by built-in DPI engines. Graphiant has integrated Customer Signature capabilities with the DPI engine for customers to name their own applications in the service portal. This helps with ease of operation in visibility & statistics, search, policies as well as reporting.
Procedure:		Select known application parameters and program customer signatures from the Graphiant portal. Customize specific traffic policy to direct the custom application to traverse a specific path. Run traffic and verify application is being recognized by the DPI engine by reviewing traffic behavior and stats.
Passed:
Failed:
Reason for Failure:
Remarks and notes:

Run iPerf and Browser Applications Between Sites 1 & 3

Test No.	13	Revision:	3.1	Author:	Date:	03/2024
Hostnames:

Test Purpose:		Run various applications between sites 1&3
Procedure:		Bring up iPerf/TCP test at hosts in site-1 and site-3 Use Browser on host at site-3 and make sure they can get to internet via site-1 (default exit)
Passed:
Failed:
Reason for Failure:
Remarks and notes:

Traffic Policies

Test No.	14	Revision:	3.1	Author:	Date:	03/2024
Hostnames:

Test Purpose:		Create traffic policies at site3 to select between circuits to put specific traffic on
Procedure:		Create traffic policy to pin iPerf traffic to circuit-1 Create traffic policy to pin ICMP traffic to circuit-1 Create traffic policy to pin YouTube traffic to circuit-2 Create traffic policy to pin a specific traffic from 10.3.11.10 to circuit-2 Assign the traffic class of “Gold” Allow all other traffic as Default Run traffic and review traffic in Monitoring
Passed:
Failed:
Reason for Failure:
Remarks and notes:

Hierarchical Tagging and Route Policies

Test No.	15	Revision:	3.1	Author:	Date:	03/2024
Hostnames:

Test Purpose:		Utilize site tagging mechanism for route policies to prefer the same routes being advertised from multiple locations. This is often needed for route/site redundancies purposes
Procedure:		Create site tags for all sites. Advertise same IP prefix from site 1 and site 3 towards sites 2 and 4 Use route policy to have site 2 prefer site 1, and site 4 prefer site 3 To test redundancy, make the prefix unavailable from site 1, site 2 should then use site 3 to reach the prefix
Passed:
Failed:
Reason for Failure:
Remarks and notes:

BGP Native Best Path Selection

Test No.	16	Revision:	3.1	Author:	Date:	03/2024
Hostnames:

Test Purpose:		Utilize Graphiant ASN in AS-Path to allow remote edges to access site-1 and site-3 for best path
Procedure:		The Graphiant stateless core service uses the registered ASN of 30656 and this ASN is added to all routes going through the core. Go to a site-2 edge and look at the BGP/Graphiant prefix table Verify site-1 routes are seen from site 1 and 3 but only site 1 prefixes are installed in the routing table Verify site-3 routes are seen from site 1 and 3 but only site 3 prefixes are installed in the routing table Start a ping and / or iPerf between site-2 and site-3 Enable maintenance mode on the Edge at site-3. Verify preferred path for site-3 routes are now going through site-1 Optionally power down the site-3 edge. Verify no packet loss. Restore power and remove edge from maintenance mode
Passed:
Failed:
Reason for Failure:
Remarks and notes:

WAN Impairment and Visibility

Test No.	17	Revision:	3.1	Author:	Date:	03/2024
Hostnames:

Test Purpose:		Create traffic policies at site3 for primary and secondary circuits, impair primary circuit out of SLA and observe traffic failover to secondary
Procedure:		Impair circuit-1 such that it can no longer sustain any traffic Verify traffic fails over to circuit-2 Navigate on portal to Monitor for Edge-1 and record screens Application visibility TWAMP/SLA statistics on the WAN links Monitor application traffic and BW usage Monitor incidents
Passed:
Failed:
Reason for Failure:
Remarks and notes:

Maintenance Mode (Hitless Service Mode)

Maintenance Mode

Test No.	21	Revision:	3.1	Author:	Date:	03/2024
Hostnames:

Test Purpose:		In a highly available network, uptime is paramount. Therefore, it’s important to have the ability to service sites with redundant nodes without introducing down time. Maintenance mode is a feature which allows draining of live traffic from an active edge to redundant edge(s) in order to perform services functions (i.e. to upgrades, diagnostics) without packet loss.
Procedure:		Demonstrate maintenance mode while running ICMP and iPerf3 traffic through both edges at a site while performing software upgrade and reboot to both edges at site-1, and/or site-2
Passed:
Failed:
Reason for Failure:
Remarks and notes:

Monitoring and Troubleshooting

Monitoring

Test No.	22	Revision:	3.1	Author:	Date:	03/2024
Hostnames:

Test Purpose:		There are multiple visibility tools in the monitor section. This test is to record some of these screens
Procedure:		Navigate on portal to Monitor for Edge-1 and record screens Connectivity Summary Application visibility Path Monitoring Route visibility Services monitoring
Passed:
Failed:
Reason for Failure:
Remarks and notes:

Troubleshooting

Test No.	23	Revision:	3.1	Author:	Date:	03/2024
Hostnames:

Test Purpose:		There are currently 5 tools under troubleshooting. Ping, Traceroute, Throughput Test, Packet Capture, and Diagnostic Reports. This test is to verify all are working as required
Procedure:		Navigate to Troubleshooting and select Edge-1 Perform ping and traceroute to hosts in Corp and Guest LAN segments at site-1, site-2, site-3 and site-4 Perform Throughput Test at any site While traffic is present perform a packet capture and export Record results Demonstrate Generating a Diagnostic Report
Passed:
Failed:
Reason for Failure:
Remarks and notes:

Failure Scenarios

WAN Path Failover to Graphiant

Test No.	24	Revision:	3.1	Author:	Date:	03/2024
Hostnames:

Test Purpose:		In this scenario, the traffic is going over the traditional WAN path between site-1 and site-3 over third-party routers. The traffic prefers this path because the BGP attributes is more attractive. The Graphiant Edges are also learning the routes between the sites and will only pass traffic between the sites when there’s a failure scenario on the legacy WAN
Procedure:		Enable BFD for BGP if supported on 3rd party L3 switch Verify traffic is going over the legacy WAN path between sites 1 and 3 Verify routes from site-1 and site-3 are visible in the Graphiant Edges form the 2 sites and that their LAN interfaces in Corp segment is pingable by the hosts in their respective segments Start a constant ping from a host at site-1 to a host at site-3 in the Corp segment Fail MPLS traffic to Graphiant: Verify traffic is flowing over Graphiant network Observe missed pings and restart and record result

Failed:
Reason for Failure:
Remarks and notes:

Edge HA Tests with Edge Redundancy

LAN Failure Edge A – Site-1 with BGP

Test No.	HA 1	Revision:	3.1	Author:	Date:	03/2024
Hostnames:

Test Purpose:		Direct Failure Edge-B LAN eth5 site-1 (BGP – Edge-B is primary local)
Procedure:		Run constant ping between hosts in site-1 and site-3 BGP routes from Edge-B on LAN switch should be withdrawn and traffic should flow over Edge-A. Capture convergence time and disruption Make sure routing converges and return traffic goes to Edge-A Recover Edge-B and traffic should reconverge over Edge-B, return path maybe over A or B Capture convergence time when routes are seen from Edge-B
Passed:
Failed:
Reason for Failure:
Remarks and notes:

WAN Failure Edge A – Site-1 with BGP

Test No.	HA 2	Revision:	3.1	Author:	Date:	03/2024
Hostnames:

Test Purpose:		Edge-A site-1 WAN Failure (BGP – Edge-A is primary local)
Procedure:		Run constant ping between hosts in site-1 and site-3 Bring down switch port connected to WAN port on Edge-A Capture convergence time and disruption Make sure routing converges and all traffic goes to Edge-B Recover switch port to Edge-A eth1 Capture convergence time when routes are seen on Edge-A Recover switch port to Edge-A eth1 Traffic should reconverge over Edge-A, return path maybe over A or B Capture convergence time Capture any disruptions Make sure network converges and return traffic goes back to Edge-A
Passed:
Failed:
Reason for Failure:
Remarks and notes:

Edge A – Site-2 with VRRP Fail LAN Interface

Test No.	HA 3	Revision:	3.1	Author:	Date:	03/2024
Hostnames:

Test Purpose:		Failure of Edge-A site-2 Corp (VRRP – Edge-A is primary local)
Procedure:		Run constant ping between hosts in site-2 and site-1 Fail switch port connected to eth5 of edge2A VRRP should fail over to Edge-B, now B is primary. All traffic should converge to Edge-B Capture convergence time and note any disruption Make sure routing converges and remote sees the route updates Recover Edge-A Check route changes Make sure Edge-A is back as primary (if preempt is on) Make sure Edge-B remains primary (if preempt is off) Record any disruptions and convergence time
Passed:
Failed:
Reason for Failure:
Remarks and notes:

WAN Failure Edge B – Site-2 with VRRP

Test No.	HA 4	Revision:	3.1	Author:	Date:	03/2024
Hostnames:

Test Purpose:		Fail Edge-B (VRRP – Edge-B is primary for Guest segment)
Procedure:		Run constant ping between hosts in site-2 and site-1 on guest segment Reboot Edge-B Edge-A should become primary Capture convergence time and any disruption Make sure routing converges and sees the remote route tables Recover Edge-B Check ODP route changes Make sure Edge-B is back as primary for guest (if preempt is on) Make sure Edge-A remains primary for guest (if preempt is off)
Passed:
Failed:
Reason for Failure:
Remarks and notes:

WAN A Failure – Site-3

Test No.	HA 5	Revision:	3.1	Author:	Date:	03/2024
Hostnames:

Test Purpose:		WAN circuit failure Edge site-3
Procedure:		Run constant ping between hosts in site-3 and site-1 Fail circuit-1 (using WAN Emulator) Traffic should converge to circuit-2 as circuit-1 fails Make sure routing converges and routes update at remote edges Capture Edge route table, RIB and FIB Note any disruption to traffic during convergence Restore circuit 1 Make sure routing converges Capture Edge route table, RIB and FIB Note any disruption to traffic during convergence
Passed:
Failed:
Reason for Failure:
Remarks and notes:

Controller Failure – Simulate for Site-1

Test No.	HA 6	Revision:	3.1	Author:	Date:	03/2024
Hostnames:

Test Purpose:		Simulate single controller failure for site-1
Procedure:		Run constant ping between hosts in site-1 and site-3 Simulate a controller failure by ACL blocking access to one controller that’s accessed by site-1 Traffic from site-1 should not be disrupted Record any disruptions to ping Check route table on site-1 Edges and remote Edges Recover Controller (remove ACL) Record any disruptions to ping during controller recovery Check route table on site-1 Edges and remote Edges
Passed:
Failed:
Reason for Failure:
Remarks and notes: