Popular tests our customers ask for in the ATC for Cisco Viptela SD-WAN

Summary

Since 2015, we've been executing Proofs of Concept (or POCs)  in the Advanced Technology Center (or ATC) around the Viptela SD-WAN solution.  That's right...before Cisco acquired Viptela in 2017, we were testing Viptela on a regular basis with our customers since 2015.

In fact, we were in the middle of a Viptela POC with a customer and one of the architects from Viptela at the time was working with us in the ATC lab.  (He originally worked for Cisco as a Lab architect in Cisco's CPOC labs, but left to go work for Viptela).  He left the ATC after work on a Tuesday as a Viptela employee and arrived back at the ATC on Wednesday as a Cisco employee. :)

The point I am making is that we have a lot of experience with the Cisco Viptela SD-WAN solution with the lab testing we've done over the years.  An extraordinary amount of hours have gone into testing the solution with our customers who wanted to evaluate it.  I will explore some of the more popular tests we have performed with our customers in the lab around Cisco Viptela which have been instrumental in choosing Cisco Viptela as their SD-WAN strategy.

ATC Insight

Our customers ask us to test out many different use cases in regards to SD-WAN and under many different custom scenarios.  Here are three example tests that customers always want to see when evaluating the Cisco Viptela SD-WAN solution.  The tests include Brownout Detection and Rerouting, Routing Integration with Non-SD-WAN enabled sites, and Forward Error Correction.

Brownout Detection and Rerouting

Customers always ask to test the brownout detection and rerouting function of Cisco Viptela SD-WAN. This use case refers to how the SD-WAN solution handles the ability to move data traffic automatically when it detects issues with a particular circuit path.  For example, if a customer MPLS circuit experiences packet loss, jitter, or delay, then how does Cisco Viptela SD-WAN detect the issue and correct it.

Routing Integration with Non-SD-WAN Site

Customers always ask to see how a Cisco Viptela SD-WAN solution can integrate with legacy or non-SD-WAN sites.  The reason for this is because SD-WAN deployments 99.9% of the time are "brownfield" environments, and require a phased migration strategy for moving all data centers and branches to the Cisco Viptela SD-WAN solution.  Depending on how a solution handles the communication between an SD-WAN enabled site and a non-SD-WAN enabled site has a direct impact on the implementation strategy.

Forward Error Correction or FEC

Now that Cisco Viptela has the ability to perform Forward Error Correction (or FEC) in the solution (which they did not have in the original Viptela solution), customers definitely want to see how it works in the lab to see if they can take advantage of the capability.  FEC recovers lost packets on a link by sending redundant data.  On the receiving end, the receiver can then take the redundant data and correct errors without having to request re-transmission of data.  

Having this ability to perform FEC can be critical to very sensitive applications that require peak performance of the circuits.  An example customers always gravitate to is if FEC can help mitigate performance issues of circuits in relation to VOIP sessions or calls.

Test Plan/Test Case

Brownout Detection and Rerouting Testing Results

We used Branch 1 as depicted above for this testing.  The idea was to identify a brownout condition on a transport path (e.g. Internet with 20% loss and 200ms delay) and steer critical traffic over to alternate path (e.g. MPLS, LTE, or another Internet circuit).

At the time of this writing (12-17-2019), we found that the Cisco Viptela SD-WAN solution handled brownout conditions very well.  The solution was able to detect packet loss, delay, and jitter, and successfully moved data traffic (if thresholds were exceeded) to other circuits that were healthy.  Here are some of our results shown below:

The Baseline was no introduction of packet loss, and traffic always prefers MPLS1 as depicted in the Cisco Viptela vManage Console below:
 

We then introduced 20% packet loss to the MPLS1 circuit, and you can see how our Mean Opinion Scoring (or MOS) is effected in our Ixia toolset below:

At the same time that we are watching this in our IXIA toolset, we see in the vManage console that the traffic has now moved to different circuit paths to get to the proper destination away from MPLS1.

One more test, we introduce 20% packet loss to MPLS1 and MPLS2 circuits, and our expectation is that the traffic will then move to the Internet circuit exclusively.  Below is what vManage Console showed after we applied the packet loss to the MPLS1 and MPLS2 circuits:

Routing Integration with Non-SD-WAN Site Testing Results

There are two specific methods that customers use in order to route traffic between SD-WAN enabled sites and legacy or Non-SD-WAN enabled sites.  The first method is to backhaul the traffic to the Data Center which communicates between the different site types.  The second method is to send the traffic from branch to branch without backhauling to the Data Center by using the underlay network.  Typically this is done with an MPLS private network.  Each method requires the use of dynamic routing protocols to help make the correct forwarding decisions.

At the time of this writing (12-17-2019) the preferred method from a Cisco Viptela perspective is to use the backhaul method to the DC for routing between SD-WAN enabled sites and Non-SD-WAN enabled sites.  Although, Cisco Viptela does support direct branch to branch communication via MPLS in the underlay (it is possible).

Here are some specific results from testing the backhaul strategy between Branch1 and Branch3 via Data Center1.  The first traceroute is sourcing from Branch1 to Branch3.  The second traceroute is sourced from Branch3 back to Branch1.  In both cases, the traffic is backhauled to Data Center1 before being sent to the destination address.

Here is a testing result of us mimicking an ongoing voice call between Branch1 (SD-WAN enabled site) and Branch3 (Non-SD-WAN site).  The traffic is backhauled to the Data Center1, and the performance of the call remains perfect at 4.41 Mean Opinion Score.

Forward Error Correction or FEC

The diagram above depicts the environment we used for the Forward Error Correction or FEC testing scenario.  We configured Branch2 with Forward Error Correction, specifically "FEC Adaptive" which only sends FEC information when the system detects packet loss.  The other option is "FEC Always" which sends FEC information with every transmission. As of this writing (12-17-2019) Cisco also has the ability to do "Packet Duplication", which is not listed in the screenshot which is an older code version of vManage that we used in the POC testing for our customer.  With "Packet Duplication" turned on, duplicate packets are sent through secondary links to reduce packet loss if one link goes down.

We found that Cisco Viptela SD-WAN performed really well when we had FEC Adaptive configured on Branch2.  Below are two different results from our IXIA Toolset showing that the Mean Opinion Scores or MOS stay very consistent when 10% packet loss is applied to all the circuits at Branch2.  Branch2 to Branch1 SIP traffic MOS never drops below 4.2, and Branch2 to Data Center1 SIP traffic MOS dips to 3.85, but then recovers quickly to above 4.0. 

Test Tools

IXIA IxLoad Test Tool

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

Documentation

Here are the physical and logical diagrams we used for a specific customer Proof of Concept (or POC) around Cisco Viptela SD-WAN.  In this particular POC, the customer wanted us to mimic two data centers, three Internet Service Providers (or ISPs), and three different branches which more closely resembled their production network.