3 reasons our customer chose VeloCloud for their SD-WAN deployment

ATC Insight

After our testing completed and we were able to review the results with our customer, it became clear that they were going to move forward with VMware VeloCloud for their SD-WAN initiative. The three things they ultimately cared about were Cloud Delivered Management and Orchestration, Ease of Configuration, and VeloCloud's version of Forward Error Correction (FEC) called Dynamic Multi-path Optimization.

Let's dive further into each one of these.

1.) Cloud Delivered Management and Orchestration

**We utilized the VeloCloud Cloud Gateways for our testing in the lab.**

**We utilized the VeloCloud SD-WAN Orchestrator which was also in the cloud for our testing in the lab.**

Our customer preferred cloud-based SD-WAN controllers. One of our first tests was to demonstrate how management and orchestration systems are delivered specifically from the VeloCloud SD-WAN Gateways and VeloCloud SD-WAN Orchestrator. No virtual machines were allowed in the on premise data center for device management and orchestration. All functionality was required to be delivered via the cloud.

We verified via our testing in the lab that in fact the customer's requirement to manage the system without local hardware or virtual machines worked properly. We managed all the configuration and management via the VeloCloud SD-WAN Orchestrator which was in the cloud. We encountered NO issues when testing the orchestrator's ability to configure and manage the environment in the testing lab. The customer was excited at the thought of not having to manage the orchestrator or gateway on-premise. The responsibility to upgrade and maintain this portion of the solution is shifted to VMware VeloCloud.

**Sample Web UI screen of Velocloud Orchestrator we used in our lab.**

Caveat Note: At the time of the testing (Oct-2018) VMware VeloCloud did not have Command Line Interface (or CLI) abilities for viewing and troubleshooting. They said they would be integrating that into future releases. Fast forward to a year later (Nov 2019) and VMware does have some capabilities around CLI viewing and troubleshooting but this is still in beta. It is not released in production level code at this time.

Thoughts: As time goes on with SD-WAN I believe that customers will continue to be more comfortable around management and configuration in GUI and Web UI tools. I am not sure the demand for CLI is really a big driver in the market that SD-WAN vendors like VMware VeloCloud need to focus on as a priority. In our case, this customer definitely did not care about CLI and cared more deeply about ease of use via the Web UI.

2.) Ease of Configuration

Some of the specific configuration items we ran through that the customer paid special attention to were configuration at the Data Center, Zero Touch Provisioning for edge devices, and configuration at the branch. We walked through several Data Center Edge configurations around establishing internet connectivity, BGP and route configuration, and discussed how VeloCloud protects against remote branch sites becoming transit areas.

**BGP configuration example at the Data Center edge in VeloCloud Orchestrator**

**At the branch level, setting the uplink neighbor flag in the BGP editor of the VeloCloud orchestrator prevents the branch from becoming a transit.**

**Successfully registering a VeloCloud Edge device via Zero Touch Provisioning in our lab**

Caveat Notes: We did not have time to test configuration capabilities via REST API. It was also not in scope for this customer. They were not interested in managing configuration via their own tools via API integration. They specifically cared about using VMware VeloCloud's Web UI only. VMware VeloCloud also provides a fully functional API to customers who wish to integrate configuration tools with their solution for configuration and management.

Additionally, Zero Touch for VMware Velocloud is a low touch "pull model". You provision the new edge model (device you intend to bring into production) in the VeloCloud Orchestrator and then it sends an activation email for the new edge appliance to get registered.

Thoughts: Our testing via the Velocloud Orchestrator went very well. The customer was impressed at how well it performed and found it easy to configure the necessary components to bring up the overlay and establish connectivity at the data center and branches, register edge devices, and bring them into the network properly. They found the ease of use as a major factor in choosing VeloCloud for SD-WAN because they definitely felt they could "live" in the Web UI and operate it on a daily basis quite easily across their team.

3.) Forward Error Correction (or FEC)

VMware VeloCloud's branded feature called Dynamic Multi-path Optimization is focused on features like automatic link monitoring, dynamic link steering and on-demand remediation. Our customer specifically liked how well VMware VeloCloud handled FEC when we added degradation to the individual links. VMware VeloCloud does provide some visibility into link or circuit performance in the VeloCloud Orchestrator as depicted below. They supply a quality score to the link or circuit before and after the quality of the link or circuit has been enhanced by VeloCloud.

We in the ATC of course took this a step further and gained more testing visibility outside of the VMware VeloCloud Orchestrator. We opted to use reporting gathered from our Ixia IxLoad instance used in this performance testing. During our testing of Circuit Degradation/Brownout use cases, we used our IXIA Toolset to generate traffic flows onto the links. We used our ATC Traffic Jam Toolset to create impairment on the individual links in the form of latency, jitter, and packet loss.

**Depiction of Branch 3 we used for link degradation for testing VeloCloud's Forward Error Correction abilities**

When we created 200ms latency, 10ms jitter, and 5 percent packet loss onto to the MPLS link at Branch 3, the Mean Opinion Score (or MOS) which is used to indicate Voice over IP (or VOIP) call quality dropped to 4.2 for a couple of seconds, but then rebounded to 4.4 fairly quickly.

When we changed to 200ms latency, 10ms jitter, and upped the packet loss to 20 percent on the MPLS link, we saw some traffic drop to 3.9 but then settle out to 4.0. It wasn't until we upped the packet loss at Branch 3 to 40 percent packet loss that we finally saw the MOS score dip down to 2.0. Keeping a MOS score at 4.0 with 20% packet loss on a link showed that VeloCloud's abilities around FEC performed very well.

Below, is a glimpse of some of the evidence from our IXIA IxLoad tool while performing this traffic generation and impairment on the MPLS circuit at Branch 3. There are different traffic flows in the environment and their respective MOS scores time-stamped by 2 second intervals. The traffic flows depicted are North/South Flows from data center to branch as well as branch to branch traffic flows.

**Sample IXIA IxLoad Report of different traffic flows used during our VOIP MOS testing**

Just for fun, we ran additional traffic generation impairment tests on the Branch 3 MPLS circuit to understand MOS scoring WITHOUT VeloCloud's forward error correction enabled. At 200ms latency, 10ms jitter, and 15 percent packet loss (without FEQ enabled) the MOS score dropped down to 2.9. When we increased the packet loss to 40 percent packet loss (without FEQ enabled) then the link became unusable for VOIP and had a MOS score that dropped down to 1.450.

**Branch 3 MPLS link degradation at 15 percent packet loss without FEQ enabled by VeloCloud**

**Branch 3 MPLS link degradation at 40 percent packet loss without FEQ enabled by VeloCloud**

Thoughts: Ultimately, the customer was impressed by VMware VeloCloud's abilities around Forward Error Correction (FEQ). Keeping the Mean Opinion Score (MOS) for VOIP calls around 4.0 in situations where the circuit or link was degraded by 5-20% packet loss was appealing to them. You can see when VMware VeloCloud's FEC is not applied to the links, the circuits or links can become unusable for VOIP calls.

Test Tools

IXIA IxLoad Test Tool

Used for Traffic Generation in the Data Center and Branch environment.

**IXIA IxLoad used in our testing for Traffic Generation**

A sample of the requirements used for traffic generation in this lab testing around VMware VeloClouds SD-WAN solution below:

Data Center One > Branch One > Application HTTP(S) > 10 connections flow rate > 1MB file size > 104 ToS Value
Data Center One > Branch Two > Application HTTP(S) > 10 connections flow rate > 1MB file size > 104 ToS Value
Data Center One > Branch Three > Application HTTP(S) > 10 connections flow rate > 1MB file size > 104 ToS Value

Data Center One > Branch One > Application SIP > 10 User Agents > 184 ToS Value
Data Center One > Branch Two > Application SIP > 10 User Agents > 184 ToS Value
Data Center One > Branch Thre > Application SIP > 10 User Agents > 184 ToS Value

Branch One > Branch Two > Application SIP > 10 User Agents > 184 ToS Value
Branch One > Branch Three > Application SIP > 10 User Agents > 184 ToS Value

Data Center One > Branch One > Application FTP > 10 Connections flow rate > 1MB file size > 0 ToS Value
Data Center One > Branch Two > Application FTP > 10 Connections flow rate > 1MB file size > 0 ToS Value
Data Center One > Branch Three > Application FTP > 10 Connections flow rate > 1MB file size > 0 ToS Value

ATC Traffic Jam Tool

Used for traffic impairment around delay, jitter, and packet loss in the Data Center and Branch environment.

Documentation

**Physical Diagram of the Lab in the ATC we utilized for VeloCloud SD-WAN testing for our customer.**

SD-WAN Use Cases Used to Test VMware VeloCloud Solution

Building Overlay Fabric
1.2         Cloud Delivered Management and Orchestration
1.3         Automation API Capabilities
1.4         Installation and Configuration of DC SD-WAN Edge
1.5         Zero Touch Provisioning (ZTP)
1.6         Data Center LAN Routing Integration
1.7         Branch LAN Routing Integration
1.8         Branch WAN Routing Integration
1.9         Segmentation
1.10       Service Insertion

Defining Standard Application Sets
1.11       SD-WAN OEM Shows List of The "Canned" Applications That Can Be Used In The Environment
1.12       Demonstrate Speed and What The Capabilities Application Recognition

Defining Custom Application Sets
1.13       SD-WAN Voice Traffic
1.14       SD-WAN OEM Shows How to Define Custom Applications That Can Be Used

Building Traffic Rules for Application Paths on Overlay Fabric
1.15       Show Traffic Rules and Application Definitions Being Tied and How It Can Be Sent Over The SD-WAN Fabric
1.16       Per path QoS
1.17       Circuit Degradation / Brownout
1.18       Application Routing Topology
1.19       SD-WAN Appliance Isolation and Recovery

Failover Testing
1.20       Branch 1 MPLS Failure
1.21       Branch 1 MPLS Restoration
1.22       Appliance Failure (Hard Failure)
1.23       Break Communications Between Site SD-WAN Appliances
1.24       VoIP Failover Test
1.25       Demonstrate Impairment on Both MPLS and Internet links for Voice – Priority 1

SD-WAN Operations
1.26       Verify Configuration Sync Between SD-WAN Edge Appliances
1.27       Logging and Rollback
1.28       One-off Configuration (post-script)

SD-WAN Controller Monitoring, Reporting, Visualization
1.29 Demonstrate Monitoring Capabilities of The Platform Throughout The Test – Priority 1
1.30 Operational Support Capabilities Cloud Controller

SD-WAN Controller Failure Scenario
1.31 Failure of SD-WAN Controller
1.32 Demonstrate Recovery of Cloud SD-WAN Controller