Why you can’t afford to play Russian roulette with your network

Why you can’t afford to play Russian roulette with your network
Joan Wrabetz is the Chief Technology Officer for Quali. Prior to her current role, she was the Vice President and Chief Technology Officer for the Emerging Product Division of EMC. Joan has over 20 years of executive management experience at public and privately held technology companies. She has been an executive at a number of startup technology companies, has been a Venture Partner with BlueStream Ventures, and has been on the board of directors or advisory board of many early stage technology companies. She was the founder and CEO of Aumni Data, a developer of big data analytics technology. She was the CEO of Tricord Systems (acquired by Adaptec), one of the first companies to introduce a commercial product based on distributed file system technology. Earlier, Ms. Wrabetz was the Vice President and General Manager for SAN operations at StorageTek, a $650M revenue business, responsible for all open systems products, including tape libraries, disk systems, and SAN switches. Prior to joining StorageTek, Ms. Wrabetz was the founder and CEO of Aggregate Computing, a grid computing software company, acquired by Platinum Technologies. Prior to Aggregate, Ms. Wrabetz held management and senior technical positions at Control Data Corporation and SRI International. Ms. Wrabetz holds an MBA from the University of California, Berkeley, an MSEE from Stanford University, and BSEE from Yale University. She has taught as an adjunct faculty member at the University of St. Thomas, St. Mary’s University, and at the Carlson School of Business at the University of Minnesota. She holds patents in load balancing, distributed systems and machine learning classification and analytics.

(c)iStock.com/rocter

With the advent of software defined networks (SDN), NFV (network function virtualization), and new network equipment, networks are being upgraded at a faster pace than ever before.  But dropping a new piece of equipment into a live network environment is a lot like playing Russian roulette – you have no way of knowing if a bullet is in the chamber or not. Luckily, network test labs can help you spot network problems before anyone pulls the trigger to go live.

Let’s examine the various elements that make up a good network test lab, and then we will review some key pointers to make sure you get the most out of the testing stages.

Four components of a good test lab

The four key pieces that make up a good network test lab include Layer 1/2 switching; abstraction; sandboxing; and visibility. Layer 1/2 switching is necessary to enable large groups of testers to set up their own isolated network configurations for testing. Otherwise, people will be required to manually re-cable network equipment, and will quickly run into conflicts over scheduling and resources.

One of the exciting new options for automatic physical network re-configuration involves using Layer 2 switching, either physical or SDN, to mimic Layer 1 switches. Emulating expensive Layer 1 switches with layer 2 networks can lower costs while still producing the same results. Layer 2 switching is applicable for most network tests, except in cases of extreme performance testing.

Since the network of the future will be a mixture of physical and software-defined, or all software defined, it is important to set up an abstraction between the physical network and the SDN. A good network test lab defines processes and selects tools that work consistently, whether or not the network components are physical, mixed, or all software-defined. Otherwise, users will have to rewrite tests and reset configurations whenever they use a software-defined network component rather than a physical network component.

For example, most virtualisation solutions can deploy VMs and set a simple network connection to a VM. However, they cannot tell if a VM is implementing a network device with multiple interfaces and ports, in which case the virtualisation solution cannot properly configure the rest of the network to connect to those ports. Therefore it’s critical to deploy network test tools that can recognise those port configurations. 

Sandboxes are another critical component of a good network test lab. Sandboxes allow testers to automate the network environment in which they run their test cases. Sandboxes provide tools for each tester to set up the proper network configurations and run their own tests in an isolated configuration.

In addition, sandboxes enable testers to incorporate all of the devices being tested, any traffic generators, and their tests into a single automation sequence. Sandboxes also create the necessary context for a complete audit trail of all the configurations, tests and results together.

The last key part of a successful network test lab involves getting visibility into all the lab resources in order for testers to quickly and easily access whatever resources are needed. Visibility also ensures that testers can quickly identify test failures and respond accordingly.

Likewise, lab managers need visibility as to when and how the test lab resources have been used, including the historical trending for all physical and virtual resources. Visibility tools allow lab managers to monitor each user and the amount of lab resources that they consume.

Two final steps to get the most from network lab tests

Automation and network path checking are both important elements to make any network test lab successful. Automation is key because the network setup, configuration and teardown tend to be time consuming and error prone. In fact, manual setup mistakes are often the main reason why tests fail, not the actual test errors themselves.

Manual steps also create unneeded bottlenecks that delay test cycle times. Users can save time and reduce errors by applying automation to the configuration of the network environment, the orchestration of traffic generators, and the actual tests.

The final step is to include network path checking as part of automation. After users have configured a network for automated testing, they still need to pre-validate that the network is properly connected and steering traffic correctly. Network path checking also creates an audit trail for each validation, which really should be done prior to running any tests.

Don’t shoot yourself in the foot, or even worse, don’t shoot yourself in the head by playing Russian roulette with your network. Remember to combine the four main components of an effective test lab with strong systems for automation and network path checking, and you will be on your way to test lab success. 

View Comments
Leave a comment

Leave a Reply

Your email address will not be published. Required fields are marked *