With few exceptions, I always encourage my clients to build a test lab—whether those clients are IPv6 implementers or not. Large network operators need little encouragement, because they readily understand the benefits of the lab. But as the size of the network gets smaller, justifying a lab becomes more difficult.
Test labs are often dismissed as prohibitively expensive, but the more you depend on your network to support your business, the more vital a test lab becomes. This is particularly true if you control all layer 3 aspects of your network; if the control of your network is in the hands of your service provider or outsourced to a managed services provider, you might not need a test lab of your own (although you should insure that whoever manages your network does have one). But even in these circumstances, at least a rudimentary lab can be warranted.
Although this series of posts is focused on IPv6 implementation, the rationale given in this post is equally important for the safe introduction of any new technology into your network and for the ongoing safe operation of your network.
Making the Business Case
It’s common for those holding the purse strings to question the need for a test lab; why should expensive gear be tied up, apparently doing nothing, when there are dozens of pressing needs in the production network crying out for investment? Getting funding for the test lab, therefore, is a matter of making a business case that demonstrates clear value to the network and to the business.
At the CFO level, that value should be expressed as:
- Reduction of operational expense
- Reduction of network risk
- Increase of network uptime and reliability
These values can be quantified, in turn, with a clear understanding of the mission of the test lab.
The Test Lab Mission
The most important missions of the test lab are as follows:
Change Verification (Assumption Testing): Any change of your network beyond the installation of the exact same kinds of hardware and software already used in other parts of the network, or the addition of links exactly like those used in other parts of the network, should be lab tested first. Even if you have used the same vendor for years, never assume that a new component or new release of software is going to behave the same as what you already have. Change verification is also important when you are making configuration changes; particularly changes to security or routing policies, which can be high-risk and are a cause of many network outages.
Interoperability Testing: These tests are especially important when you are introducing a new vendor’s product into your network; implementations of the same protocol standards can vary in small ways from one vendor to another. And even the same vendor can, on occasion, have interoperability problems among their various product lines.
Functional Verification: A tremendous number of vendors claim support for IPv6, but this does not mean they support every function necessary for the practical implementation of IPv6. Therefore you must verify both the full set of IPv6 core functions and the functional support of any other IPv6-enabled protocols you want to run. There are a number of commercial IPv6 conformance verification suites, but you can also find free, open verification suites, the most well-known of which is TAHI.
Performance Testing: Vendor performance claims do not always live up to reality. In the area of IPv6, it is far from unusual to find that IPv6 performance is below IPv4 performance. However, expensive commercial traffic generators are often required to find the upper limits of high-end network devices, putting thorough performance testing out of the reach of smaller network operators.
Vendor Evaluation: This is a combination of all the previous missions; when a new vendor is being considered, you need to understand not only how their gear behaves and under what parameters, but also how the gear would fit into your existing network.
Training: This is an often-undervalued lab mission. Many operations personnel are limited in what they can learn because they are strictly limited in what they can do on an operational network, and formal hands-on training is often too structured and time-constrained. A standing lab allows your staff to experiment and learn at their own pace and with their own agenda, without fear of “breaking” the network. The skills they learn in the lab contribute directly to a more reliable, more secure production network.
Troubleshooting: Distinct outages in your production network call for immediate fixes. But more subtle problems often go unaddressed because operators are wary of making the problem worse. A lab enables the operator to try to replicate the problem and analyze it, trying various solutions, without risk to the production network. The result is improved reliability, security, and performance.
Methodology Development: The most reliable networks have well-documented methods of procedure for a multitude of network operations and changes. A lab allows you to develop and refine these procedures without using trial-and-error on your production network.
Customer Relations: Like training, customer relations is an often-undervalued lab mission. A good lab can be a showcase for demonstrating your network capabilities to your customers or potential customers.
Building the Lab
Determining the missions of your lab influences what your lab looks like. A basic IPv6 lab might include just a few routers and switches to emulate a network, a server or two to carry common services like DNS, SMTP, and HTTP plus testing applications, and a few hosts to represent end-users. With such a lab you can verify basic network and application behavior, and test new gear before it goes into your production network.
If you run a large enterprise or service provider network, on the other hand, your lab should contain enough equipment to emulate at least a couple of PoPs plus a data center, and support all production applications; you should be able to replicate enough of your real network to insure that your tests of any changes, additions, or upgrades are providing you with accurate, realistic results.
In the next post, I’ll write about the milestones and methodologies in an IPv6 implementation plan.
Network World and I are going to try something new: A live hosted chat in which you can pose questions and I’ll do my best to answer in real time.
Join me for this live chat on August 1, at 2PM Eastern (18:00 GMT). No registration is required; just point your browser to:
www.networkworld.com/chat
I hope to “see” you there!
