In my previous blog, I talked about building out a lab to help with IPv6 integration testing.  It cannot be understatedhow important it is to test any new featurethat is going to be deployed on the network.  This statement is true independent of the feature involved.  In this case, we are talking about IPv6, but we could just as easily be talking about virtualization or BYOD.

So now that we have the lab build up in progress, what's next? 

First, you should communicate to your teams that you have a lab and that it is there to test new applications. Too often, IT people are told of an integration plan at the last minute or not at all.

Second, it is always important to have a plan and objective when going into any testing situation.  A test plan and objective gives you something that you can fall back on to either recreate the observed results, or ground you in the middle of a complicated configuration.

So what's in an IPv6 integration test plan?

Just as the lab setup tries to mimic the "real world", the test plan should be developed to create test cases and scenarios that will mimic situations that are common in the daily operations.  To help define what the "real world" looks like, refer to your audit of the current features that are in use, or conduct a new one to get that information.  This audit will help define what needs to be tested and how it should be tested.  The test cases should also be inclusive of the end system operating systems and applications that are part of the operational network.  The features and services (e.g. DHCPv6, DNS) that these devices use should also be part of the test plan.

A primary divergence from testing that has been done for IPv4 networks, is that the network now has two transports available for use -IPv4 and IPv6.  The test plan has to take into account that at any given time, one or both transport protocols will be used.  The test plan needs to be developed to cover situations where both transports are available as well as situations where only one transport is accessible.  In the operational network, situations might develop where the only transport available is IPv6.  It is important to understand how the network, end systems, services, and applications work in that scenario.

It is also very important to build up test cases and scenarios that fall outside of normal operations.  These scenarios give insight into how the system will behave when operating outside of the envelope.

Test cases should be developed to find out the performance peaks (e.g. packets per second, connections per second) and resource utilization characteristics (e.g. CPU and memory utilization) of the system.  Lab testing can also be used to evaluate the performance of the individual components that are part of the design, to ensure that they do the functions they are configured to do.  Results found in the lab can be used to compare against equipment vendors benchmarks.

It is important to establish the performance envelopes during the testing phase. These results will be used to establish some key performance indicators that can be used as a basis of comparison when the design is moved into the operational phases.  The performance benchmarks in the lab can be used to establish operational thresholds that can be monitored by the network management system when the design is deployed.

There are also resources available to help with the overall testing efforts.  The following sites can be used to help define some test cases and what features should be used to evaluate IPv6 feature functionality:

•                 https://www.ipv6ready.org/
•                 http://www-x.antd.nist.gov/usgv6/index.html
•                 http://www.ripe.net/ripe/docs/current-ripe-documents/ripe-554

The IPv6 Ready and USGv6 sites will also help indicate which vendors' products have been evaluated by these testing programs.  Keep in mind that these programs are a starting point for testing, and should not be used as a substitute for doing your own analysis and testing.