Alex Henthorn-Iwane

Subscribe to Alex Henthorn-Iwane: eMailAlertsEmail Alerts
Get Alex Henthorn-Iwane: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Related Topics: Cloud Computing, Virtualization Magazine, Software Testing Journal, Software Configuration Management, SDN Journal


Software-Automated Testing for Software-Defined Networks

You should already be deploying software-driven testing processes, driven by a test and lab automation framework

Software-defined networks are all the rage these days - and why not? They offer the promised benefit of making networks far more agile and responsive to dynamically changing application requirements. Consequently, in theory, the entire networking-computing-storage-applications ecosystem of IT and telecom will dance nimbly to the contrapuntal rhythms of the top and bottom line. And let's not forget that there will be big-time winners and losers in the networking technology industry, making not only a fascinating business issue, but something of a blood sport as well, and who doesn't like to watch competitors bash each other silly?

Amid all the hype and hyperbole, there remains plenty of gritty detail in building, deploying, and maintaining networks, software-defined or not. One immensely important detail is making sure all this new-fangled networking will work, and that means testing. Networks may become software driven, but unless we find another dimension within which to switch communications data around, there will still be hardware. The vendor logo on the faceplate of that hardware may change over time, but hardware will still be humming away in millions of racks in thousands of data centers, central offices, points of presence, and telco closets. Inside those millions upon millions of pieces of hardware will be billions of virtual resources - hypervisors, virtual machines, virtual switches, and trillions of application instances. All of that, hardware included, has to be tested. Today, many software functions are collocated within the hardware - for example, the computation of network paths has been delivered within the switch or router.

The new frontier of SDN makes the picture more complex. Separate network components perform control-plane path calculations (now network-critical control plane functions) based on requests from applications and then propagate those paths to data-plane switches. From a testing point of view, functions that formerly ran in the software of a switch or router are now network applications, requiring testing against a matrix of network topologies and conditions. If the control plane breaks, the entire network will break catastrophically. If that doesn't qualify as something that needs extremely thorough testing, then maybe nothing does.

Let's consider what is involved in testing a service provider network today by taking the simplest case - adding a new piece of hardware or a software upgrade to something in the network. There is a huge, nay, massive matrix of hardware components, subcomponents, OS versions, firmware versions, configurations, etc., that are deployed in the network. Each hardware component amortizes over a very long time so they're not going away anytime soon. Consequently, each new bit must be tested against all the bits that are already deployed. This is a very large, time-consuming and expensive undertaking involving all the representative equipment sitting in a lab to do the job. Know of any service providers that only run one service? All those different services with all their features need to be tested, at different loads, etc.

Ironically, network testing is probably one of the least "software-enabled" functions in IT today, making testing more complex and less efficient. Imagine a large business that operated using manual phone switchboards for telephony, its messaging via sticky notes, and with no calendaring system. That doesn't exist in the front office of any business of scale today, but such a primitive state of IT automation is very common in large test labs, despite millions of dollars of capital, space and power being poured into labs annually. Very costly devices under test (DUTs) and test generators are often connected together with a spaghetti of cables and manual patch panels. Testing teams coordinate their usage of equipment through "hands off" post-it notes placed on equipment that is in use, and through emails. Visibility to and calendaring of resources is typically non-existent as well - it's all handled in a very manual fashion.

The lack of automation increases the time it takes to connect test equipment together and to configure the test devices so that they're ready for testing. Sorting through a tangle of cables and physically connecting the various test components into a testing topology can take hours or even days. A test engineer may take additional hours or days to load the right OS or firmware versions and configure the devices in a large test bed topology. Since nobody wants to make a mistake during setup and configuration, equipment is often kept locked down and powered up during that entire period. And that's when the new features arrive on time. If the new gear to be tested is delayed, given the onerous time investment just to prepare for the test, engineers often will simply keep test topologies locked up to avoid the risk of losing access to a critical test component or having their configuration messed up. The not-so-shocking result is that the ratio of time spent in setup and configuration vs. actual testing can be as lopsided as 80% vs. 20%. Ever hear of "process re-engineering?" This is a business process begging to be optimized. To recap, software-defined networks will add complexity to an already daunting testing task against a massive matrix of legacy and continually added new hardware and virtual network components. Most network test labs aren't software-driven today. What would it look like to software-enable network testing? Enter test and lab automation solutions, which are ideally flexible frameworks that can take these massive CAPEX and OPEX investments from the dark ages into the bright, post-modern light of efficiency and savings. Test and lab automation software does this by changing the way that test labs operate:

  • Connecting to, controlling and inventorying all the equipment in the lab, including DUTs, test devices L1 switches, and even power distribution units. All lab personnel now find gear and build their test topologies through a GUI rather than by manually hunting through telecom racks.
  • Enabling testers to build and schedule the precise resources needed in a test topology, including the design and activation of their connectivity, provisioning of proper OS and firmware versions onto devices, and configuration of logical parameters and features. This advanced scheduling and automated provisioning minimizes both physical and logical setup time, speeds test execution, improves sharing of resources, and enables test labs to deliver more test coverage in less time.
  • Automated administrative functions such as the ability to save and restore an entire test topology once it is designed, or to restore devices to a baseline state, cuts down on repeated design work, and prevents errors from tests run on the wrong device configurations
  • Tracking scheduling and activation indicators of device utilization and test completion provide vital business intelligence reports to help managers and architects continue to refine best practices and continuously improve efficiency.

What's the take away? If you're considering deploying software-defined networks, you should already be deploying software-driven testing processes, driven by a test and lab automation framework. To attempt to roll out such complex new technology without proper automation could lead to experiencing some hard realities.

More Stories By Alex Henthorn-Iwane

Alex Henthorn-Iwane joined QualiSystems in February 2013 and is responsible for worldwide marketing and public relations. Prior to joining QualiSystems, he was Vice-President of Marketing and Product Management at Packet Design, Inc., a provider of IP/MPLS route analytics network management software, and has 20+ years of experience in senior management, marketing and technical roles at telecom-oriented networking and security startups. Alex holds a BA from U.C. Berkeley.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.