Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
EE Times-Asia > Networks

Tips on IPv6 testing

Posted: 09 May 2012 ?? ?Print Version ?Bookmark and Share

Keywords:IPv4? IPv6? Ethernet?

Today's IPv4 networking software and hardware has been proven over the years. You know how they work and you have confidence in your network. You know how many routes a specific device can hold and you know your PE routers will handle a routing update, and how much data can be forwarded because the router is working today.

The quality of IPv6 software and features in vendor equipment is unproven and largely untested. While vendors are delivering IPv6 features to their products as new hardware or software updates, these features aren't necessarily perfect, reliable or performing properly. In this article, we consider the causes of poor IPv6 compatibility and how to address them by running a testing environment to detect problems, test vendor fixes and establish a validation process for network equipment.

You can trim down IPv6 product defects to just four causes:

???Some IPv6 standards are still changing and updating, which requires ongoing software updates to your network hardware.
???Some vendors started IPv6 development late and features aren't completed.
???Vendors don't always have strong testing and validation processes which results in buggy software.
???Existing network hardware doesn't fully support IPv6 because, for example, the TCAM Memory architectures are tuned to 32bit addressing which affects IPv6 performance or scalability.

Some IPv6 standards are being updated or extended as feedback from the early deployments is gathered from the industry. This is normal and to be expected but also means that vendors' software and hardware requires regular testing and validation.

While a testing plan should be developed for your specific environment, consider the following elements as inspiration for your initial testing plan. First, a document from, "Requirements For IPv6 in ICT Equipment," provides a comprehensive resource to the IETF RFCs for IPv6 and makes a great reference for a test plan. Consider the following three core functional tests as examples:

IPv6 native forwarding performance, single and mixed mode with IPv4
Products such as the Cisco ACE 2.0 hardware supports more than 10Gb/s of IPv4 in hardware but IPv6 is software only and supports less than 100Mbps. This led to Cisco withdrawing IPv6 on the Cisco ACE2.0. This test is vital to validating the 'real life' deployment in a mixed mode network and determining where IPv6 scaling is a problem.

IPv6 over IPv4 tunnel performance
Many companies will tunnel IPv6 in GRE tunnels on their existing IPv4 backbones. When tunneling, the network device must perform the encapsulation of the payload in addition to forwarding the frame.

Some devices perform this in CPU and may not scale. Also, the IP packet needs a larger IP MTU to perform the encapsulation and fragmentation can impact system performance. This can change the traffic performance in WAN services and certain types of switching hardware where the Ethernet MTU must also be extended.

In this test, you are looking for packet loss, packet sequence errors, validating device features to support GRE and the performance when tunneling.

IPv6 Routing Protocol performance
This test focuses on validating the performance of routing protocols such as OSPF, IS-IS and BGP for size, convergence and stability and whether devices can handle route flaps reliably. The test platform will be able to emulate many routers and inject routes according to a schedule and measure the propagation of routes between devices.

Executing test plan
Now that you have described a foundation for building a test plan the next step is considering how to execute that plan and manage your test resources. There are three components that you should strongly consider: repeatability, measurement and reporting, and resource management.

With IPv6 vendor code today, it is almost certain that you will find bugs or performance problems in your systems and you'll be submitting them to vendor support. When the vendor responds with the patch you will need to repeat the test for the bug itself, but also to test that no other bugs have been introduced (it happens far too often, right?). So make sure that you have built a test bed and management system that can repeat the test easily, and lets you compare the results with confidence.

1???2?Next Page?Last Page

Article Comments - Tips on IPv6 testing
*? You can enter [0] more charecters.
*Verify code:


Visit Asia Webinars to learn about the latest in technology and get practical design tips.

Back to Top