datasheets.com EBN.com EDN.com EETimes.com Embedded.com PlanetAnalog.com TechOnline.com  
Events
UBM Tech
UBM Tech

Design Article

Comment


Embd SW netwk

4/26/2012 4:00 PM EDT

One comment about remote testing. The IPv6 test equipment should be connected to ...

More...



Luis Sanchez

4/26/2012 2:45 PM EDT

This article lets me see that testing can be done with different tools but ...

More...

IPv6 testing: Tips you need to know

Assaf Lev, QualiSystems

4/23/2012 10:22 AM EDT

Today's IPv4 networking software and hardware has been proven over time - 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 simplify IPv6 product defects to just four primary causes:

  1. Some IPv6 standards are still changing and updating, which requires ongoing software updates to your network hardware.
  2. Some vendors started IPv6 development late and features aren't completed.
  3. Vendors don't always have strong testing and validation processes which results in buggy software.
  4. Existing network hardware doesn't fully support IPv6 because, for example, the TCAM Memory architectures are tuned to 32-bit 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 RIPE, "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.





Luis Sanchez

4/26/2012 2:45 PM EDT

This article lets me see that testing can be done with different tools but nowadays seem to be concentrating in using some kind of scripting language for automating tests. Also its necessary to use source code management to handle the set of scripts and an issue tracking system to follow up on bugs. But most importantly, a good test management system which simplifies and orders the test plan and execution. It also eases the reporting tasks. I once worked without a test management system and yikes... it sucks! Mostly at the time of gathering the results and preparing a report.
Ideally all these systems should be linked so that if there's a failure or bug found in a certain test case, the test plan should link with the issue tracking system where a bug for that defect should reside. Prove of the failure in the form of log files should also be linked with the bug and the issue tracking system. Ideally perhaps through good old fashion hyperlinks. Testing is good when you have the right tools!

Sign in to Reply



Embd SW netwk

4/26/2012 4:00 PM EDT

One comment about remote testing. The IPv6 test equipment should be connected to the system(s)-under-test by a L2 network. Using a router can prevent some of the malformed packets from making it to the system under test.

Sign in to Reply



Please sign in to post comment

Navigate to related information

Datasheets.com Parts Search

185 million searchable parts
(please enter a part number or hit search to begin)