Why Testing Your Network Virtualization Is So Critical

In my last blog post, I outlined the strategic thinking that must be invested in planning for network virtualization. But planning is just the first phase. The next step – perhaps equally important – is testing.

The ideal situation is to create the virtual network in a lab environment where you can test it.

There are reasons to carry out extensive testing. Since one major justification for virtualizing is cost avoidance to reduce future capital expenditures, you have to make sure that virtualized network performance is at least as good as – if not better – than the hardware you’re replacing. Likewise, you want to be sure virtualization does not have a negative effect on the customer experience.

Another reason to test: virtualization is intended to provide technological advantages, such as reconfiguring your network faster and more easily. The test environment is where you can confirm these benefits exist and identify shortcomings in network engineers’ training and skillsets that need to be remedied.

No matter how much homework you did in picking vendors, only through testing can you confirm to your satisfaction that claims of compatibility, ease of use, and other product/service benefits are accurate. If there’s a workaround needed to make virtualization sync with your existing network, you want to know before plunging down that road!

This is especially true if you have invested in developers, programmers, and network architects to help design a custom solution that suits your network. Anything customized needs extensive testing to find software bugs in advance – and software always has bugs! – and ensure that the network meets the performance standards specified to those skilled workers.

The actual testing will be resource-intensive, and probably expensive, at least as you develop a specific testing methodology. There will be plenty of incremental, iterative testing – if you try to combine multiple stacks, for instance, you have to test all of them against each other head-to-head, then two against two, and so forth. And it’s not just testing under ideal conditions in the lab. It has to include FIT testing and testing in the field under real-world conditions.

This is an area where doing your homework on vendors can pay off. You can go back to the manufacturers of your original network components and ask how they tested their products so that you can use the same methodology on testing the virtual components – one way to make sure the performance parameters are at least as good as the hardware being replaced. Work with the virtualization vendors to identify how they test and validate the performance of their products and services and incorporate those elements into your testing.

As you can see, testing is a long-term commitment. While virtualization is the way to go for all the positive benefits it provides, “trust, but verify” still applies.

In my next post, I’ll talk about the HR issues raised by moving to virtualized networks. Every organization is looking for new hires with strong IT skills – how are you going to meet your firm’s needs?

— Shervin Gerami


You may also be interested in:

Engineer’s Roundtable: Virtualization Challenges

Virtualization From an Operator’s Perspective