Open Networking User Group SD-WAN Requirements Demonstration Talari Test Results

Transcription

1 Open Networking User Group SD-WAN Requirements Demonstration Talari Test Results May 13, 2015 Talari 550 South Winchester Suite 550 San Jose, CA

2 Defining the Software Defined WAN The SD-WAN Working Group, part of the Open Networking User Group (ONUG), brought together end users, networking experts and vendors to create a description of a Software Defined WAN that would remain true to the architectural goals of Software Defined Networking (SDN) while accomplishing the business goals of enterprises to modernize their Wide Area Networks. The results of this effort were laid out in ONUG Software-Defined WAN Use Case, October 2014 available at The group then distilled the contents of the paper into 10 key requirements of an SD-WAN. The paper and the top ten requirements served a dual purpose to give vendors confidence that the products they built would satisfy the needs of business and to give businesses guidance and knowledge they could use when selecting an SD-WAN solution. The next step in this process was testing the viability of the definition and top ten requirements. Could vendors create products that satisfied the details laid out in the Use Case. After all, the solution description and requirements were only a wish list unless real products were available that met that standard. Talari tested its Software Defined THINKING WAN against eight of those requirements, and in the course of testing proved that it could meet and exceed what was listed. This document describes the network configuration used by Talari during the testing and the details of the test results. The high-level result summary is that Talari demonstrated: An SD-WAN composed of Talari physical and virtual appliances The ability to direct traffic across Hybrid WANs according to company policy and application type The ability to detect loss on an individual link failure and move traffic to remaining links without creating a new session, with negligible jitter, with no out of order packets and with zero loss Enforcement of application prioritization defined by network-wide policies within a congested network Line, flow and application-level graphical dashboards Seamless integration with Layer 2 and Layer 3 protocols Test Network Configuration Talari conducted the tests from its engineering facilities in Raleigh, North Carolina. As per the test setup requirements, it was configured as a four site network with two data centers and two branch locations, with each branch location connected to each DC with MPLS link and an Internet link. The SD-WAN was created with Talari Appliance T3010s and Talari Virtual Appliance VT500s. The test data were generated by Ixia IxChariot,which was also used to measure the test results. Page 2 of 6

3 Figure 1: Talari SD-WAN Test Configuration Test Results Requirement 1: Ability for remote site/branch to leverage public and private WANs in an activeactive fashion for business applications Requirement 3: A secure hybrid WAAN architecture that allows for dynamic traffic engineering capability across private and public WAN paths as specified by application policy, prevailing network WAN availability and/or degradation at transport of application layer performance Requirement 4: Visibility, prioritization and steering of business critical and real-time applications as per security and corporate governance and compliance policies Requirement 5: A highly available and resilient hybrid WAN environment for optimal client and application experience Requirements 1, 3, 4, and 5 shared a common configuration and demonstration methodology. In each case, IxChariot was used to generate traffic that simulated several applications, each with multiple simultaneous users and sessions. The role of the SD- WAN was to direct traffic according to company policy during normal, non-impaired, conditions such that all links were used. During times of impaired network function, such as an excessive loss on one link or an outage of one link, those sessions had to be moved Page 3 of 6

4 to the remaining link to avoid the impairment. If an outage on one link caused congestion on the remaining link, then traffic was to be prioritized and potentially cached or dropped according to company policy. Talari s SD-WAN passed each of these requirements. By monitoring every path through the WAN, Talari s solution was able to detect the poor quality link and the link outage within a fraction of a second and shift all WAN traffic to the alternate path. During this shift, no sessions were terminated. (While the test used sustained loss, Talari s error detection is so fast, that even small spikes in latency or loss could have been detected and avoided.) The end result was application traffic on the receiving end that had no loss, no out of order packet, and negligible jitter. In other words, if there had been a real user on the other end of that connection, they would have noticed no interruption or quality degradation in the application. Instantaneous detection of the failed link and shift of traffic to the remaining link No loss, no out of order packets, no dips in throughput and virtually no jitter Figure 2: Highlight from Requirement #5 Requirement 2: Ability to deploy CPE in a physical or virtual form factor on commodity hardware The test configuration for Requirement #2 replaced one of the physical Talari Appliances with a Talari Virtual Appliance VT500, the newest addition to Talari s product line. This is a software-only solution running within a Virtual Machine (VM) on customer-provided servers. The VT500 allows Talari customers to simplify their branch office networks by service chaining the Talari SD-WAN solution with other on-premise network services such as firewalls and WAN optimization. Page 4 of 6

5 Requirement 6: Layer 2 and 3 interoperability with directly connected switch and/or router During the test, and specifically demonstrated while validating Requirement #6, the Talari solution interoperated with Layer 2 and 3 platforms running various routing protocols. Requirement 7: Site, Application and VPN performance level dashboard reporting The Talari SD-WAN contains a web-based GUI interface that was used to fulfill this requirement. The quality of each WAN link and the multiple possible paths that network traffic could take across those paths in each direction was displayed in report and graph form. The quality of the tunnels that were created from each site to each data center was also displayed. Of particular note was that the quality of the tunnel, which is abstracted from and composed of, the multiple paths remained constant even as the individual paths and WAN links exhibited impairment as displayed in Figure 2. This reflects the experience of the applications that use the tunnels. Application level reports confirmed this fact as application quality was shown to be consistently high until artificial congestion forced the deprioritization of non-business, non-critical traffic. Requirement 8: Open northbound API for controller access and management, ability to forward specific log events to network event co-relation manager and/or Security Incident and Event Manager Talari demonstrated the ability to generate log events through a variety of Northbound interfaces, including SNMP, Syslog, and . Requirement 9: Capability to effect zero touch deployment at branch site with minimal to no configuration changes on directly connected infrastructure ensuring agility in provisioning and deployment While Talari did not test against requirement #9, it s worth commenting on Talari s solution with respect to that requirement. The concept of zero-touch deployment at the branch has been the subject of much debate lately, in an effort to define what true zero-touch means. Talari s centralized controller downloads configuration files, created via a centralized management system, to new appliances and there is no requirement for any person to touch the appliance to complete the process. Changes to configurations are seamless downloaded to each appliance in the network, with a 2 stage process that first pushes the new configuration, validates that each appliance has received the new configuration, and then switches to the new configuration simultaneously to ensure the network operates with nothing out of sync. New and changed configurations can be pushed during operating hours as all commonly occurring changes do not impact the ability of the Talari SD-WAN to function nor cause any interruption in traffic. Requirement 10: FIPS validation certification for cryptography modules/encryption with automated certification left cycle management and reporting Talari will pursue FIPS compliance in Summer of Page 5 of 6

6 What s Next? As the process continues, the next logical step for most vendors is to validate that the certified solutions meet the actual needs of real businesses running real application over real networks. Lab tests serve a purpose and provide a basis for comparison, but as any IT manager will tell you, a working network is not a lab and real users are more demanding than certification bodies. Talari doesn t need to wait for this step. We ve helped hundreds of companies in over 35 countries create a better WAN, one that proactively adapts to changing application requirements and underlying network conditions, applying centrally defined business policies to real-time network traffic to create a THINKING WAN that frees every employee to be more productive so the entire company can be brilliant. Page 6 of 6