In This Insight


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.

copy link

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


Brownout Detection and Data Traffic Rerouting Use Case in Cisco Viptela SD-WAN
Brownout Detection and Data Traffic Rerouting Use Case in Cisco Viptela SD-WAN

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


Routing Integration between SD-WAN and Non-SD-WAN sites Use Case in Cisco Viptela SD-WAN
Routing Integration between SD-WAN and Non-SD-WAN sites Use Case in Cisco Viptela SD-WAN

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


Forward Error Correction or FEC Use Case in Cisco Viptela SD-WAN
Forward Error Correction or FEC Use Case in Cisco Viptela SD-WAN

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.

copy link

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:

Branch 1 vEdge always sending traffic through MPLS1 circuit to destination Data Center 1 vEdge


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:


Packet loss introduction to MPLS1 creates a dip in MOS scoring to 3.05, but then recovers back to above 4 MOS score.

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.


Cisco Viptela SD-WAN solution moves traffic away from MPLS1 circuit to other circuits like MPLS2 and Internet depicted in diagram.

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:

Traffic moves exclusively over the Internet circuit when MPLS1 and MPLS2 have exceeded packet loss thresholds.


Routing Integration with Non-SD-WAN Site Testing Results


Branch1 SD-WAN enabled site and Branch3 Non-SD-WAN enabled site used for testing the communication path.

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.


Backhaul Traffic Testing Traceroutes between Branch1 and Branch3 shows traffic back to Data Center1.

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.

IXIA Toolset showing perfect MOS score from a performance perspective between SD-WAN enabled branch and Non-SD-WAN branch

copy link


Forward Error Correction or FEC


Environment used between Branch2 and Branch1 to show Forward Error Correction capabilities from Cisco Viptela SD-WAN.


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.


Depiction of where Forward Error Correction is Configured in Cisco Viptela vManage Controller.


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. 

Branch2 to Branch1 SIP Traffic when 10% Packet Loss applied to circuits at Branch2 (INET/MPLS).
Branch2 to Data Center1 SIP Traffic when 10% Packet Loss applied to circuits at Branch2 (INET/MPLS).

copy link

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


IXIA IxLoad Traffic Profile used for this Customer Proof of Concept for Traffic Generation

copy link


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.

Physical Diagram of an customer's production Data Center and Branch environment for Cisco Viptela SD-WAN testing


Logical Diagram of an customer's production Data Center and Branch environment for Cisco Viptela SD-WAN testing


Hardware used for the Cisco Viptela SD-WAN Customer Proof of Concept as depicted in the Physical and Logical Diagrams