Library: Test Plans

Baseline IPv6 performance testing with IxChariot

Overview

1. Dual stack IPv4/IPv6 performance verification
2. IPv6 Internet traffic performance test
3. IPv6 Internet traffic emulation with stateless IPv6 IMIX traffic for additional network congestion
4. IPv6 Internet traffic performance test with IPv6 DoS attack
5. Basic IPv6 VoIP testing

Overview

IPv6 and its set of well-documented benefits (see Ixia's IPv6 White Paper)

have driven an increasing number of operating system and network equipment vendors to offer IPv6 support in their product lines that previously supported only IPv4. Today, market segments such as National Research Networks (NRNs) and connected university campuses, federal, and government organizations have deployed nationwide IPv6 networks. In addition, engineering organizations working on IPv6 applications or appliances, as well as service providers, require IPv6 capabilities in new product acquisitions.

From a testing perspective, the transition to IPv6 implies that both the entire network and its underlying components have to be stress-tested to meet the forecast amount of IPv6 traffic. The increasing availability of IPv6 applications on user systems will create the expectation that these new applications will offer the same performance as any of their IPv4 predecessors.

From an overall deployment perspective, many equipment vendors and enterprises advocate an IPv6 transition strategy that begins from the edges of the network and moves in toward the core. Such a strategy would have the benefits of better visibility of deployment costs as well provide a unique focus on the needs of applications migrating to IPv6.

IxChariot is the industry-standard test tool to assist companies with their pre-deployment tests and transition to IPv6. Its wide range of IPv6 test capabilities allows an exact impact assessment when deploying IPv6-based applications across dual-stack and, later on, native IPv6 environments. The test cases in this document provide an outline of some of the key capabilities in IxChariot and are based on a popular Layer 3 dual stack switch common to the edge networks of many larger organizations.

Five test cases are presented below:

• Dual-stack IPv4/IPv6 throughput (baseline test)
• IPv6 Internet traffic emulation
• IPv6 Internet traffic emulation with stateless IPv6 IMIX traffic for additional network congestion
• IPv6 Internet traffic emulation with IPv6 Ping of Death attack against the DUT
• IPv6 VoIP traffic emulation

Setup
A minimum of two Ixia ports with stateless stream generation capabilities are required (e.g., port 1 and 4). Each port must run the Performance Endpoint for IxOS and be connected to the ingress and egress ports of the Layer 3 switch respectively. Two subnets need to be set up where Ixia port 1 and the ingress port of the Layer 3 switch are on the same subnet. The second subnet includes Ixia port 4 and the egress port of the switch. The IxChariot console can be run either directly on the Ixia chassis or separately on a workstation connected to the chassis' management port. Ixia's IxApplifier needs to be installed on the same chassis to configure the IPv6 addresses and to download the Performance Endpoint into the port CPU of the Ixia Load Module.


Figure 1: Basic IPv6 test setup to test the performance of a L3 switch or router

1. Dual stack IPv4/IPv6 performance verification

Objective:
IPv4 and IPv6 hosts are expected to coexist for a substantial time during the steady migration from IPv4 to IPv6, and the development of transition strategies, tools, and mechanisms has been part of the basic IPv6 design from the start. From a testing perspective, this means that a basic dual-stack IPv4/IPv6 performance test should be considered as a first step in creating a baseline not only for all future IPv6 tests but also to understand any performance differences that may exist in the device to forward IPv4 versus IPv6 traffic. This is important since many devices offer hardware-based acceleration for IPv4; however, they either do not offer this option for IPv6 or only offer it with greatly reduced performance.

Therefore, the objective of this test is to determine and characterize any throughput differences that may exist in the network and specific Device Under Test (DUT) when forwarding IPv4 and IPv6 traffic.

Input Parameters:
The primary input parameters for this test include:

• IPv4 and IPv6 addresses configured on the Ixia ports running the Performance Endpoints for IxOS to create two pairs - Pair 1 for IPv4 and Pair 2 for IPv6.
• IxChariot script - High Performance Throughput.
• Network protocol - TCP and TCP IPv6 respectively.
• Endpoint 1 (E1) Setup addresses (i.e., management port IPv4 addresses of Ixia port).
• Run Option was set to a fixed duration of one minute.

Test methodology:
The test should involve as many ports on the Ixia Load Modules as there are test ports on the DUT. For a single ingress/egress port pair, two pairs are defined (one for each IP version) and then executed with run options set to a fixed time.


Figure 2: Baseline IPv4/IPv6 throughput performance test results through a Layer 3 switch

IxChariot displays the throughput results in a variety of ways (max, min, average) as well as datagram statistics, such as Bytes Sent and Received by E1. As can be seen in the excerpt from the IxChariot HTML report above, pair 1 (i.e., IPv4) shows significantly better performance than pair 2 (i.e., IPv6), thus indicating that the DUT offers better throughput for IPv4 than for IPv6 traffic.

Note: Please note that IxChariot measures the throughput associated with packet payload, ignoring headers. This metric is referred to as Goodput in RFC 3511.

2. IPv6 Internet traffic performance test

Objective:
While applications that natively support IPv6 are still a nascent market, the fact is that network users will continue to use given set of applications to accomplish the same business and productivity goals independent of the underlying IP version. From a testing perspective, this means that the same application traffic that is normally generated over an IPv4 network will now be sent across a new set of IPv6 devices. These traffic generating applications can be split into two main clusters - Internet and enterprise application traffic. The objective of the following test is to load the Device under Test with standard Internet traffic, i.e., HTTP, Instant Messaging, Email, streaming audio and video, encapsulated in IPv6 packets.

Input Parameters:
The primary input parameters for this test include:

• IPv6 addresses configured on the Ixia ports, running the Performance Endpoints for IxOS to create in nine pairs. In this case, the nine pairs are set up to use the same IPv6 addresses for E1 and E2 (i.e., 2000:21::4 for E1 and 2000:22::4 for E2). However, you can also alias up to 500 MAC/IPv6 addresses on each Ixia port to more accurately emulate a higher number of users.
• IxChariot scripts should reflect a combination of common Internet application scripts using both TCP-IPv6 and UDP-IPv6 as the underlying protocols. Scripts used in this test case include:
  • HTTPtext, HTTPgif
  • FTPget, FTPput
  • MSN Messenger Login, MSN Messenger Text Chat
  • POP3
  • Realmed, NetMtgv
• Network protocol - TCP and UDP for IPv6 respectively depending on the script type. This means that streaming media scripts will use UDP-IPv6.
• E1 Setup addresses (i.e., management port IPv4 addresses of Ixia port).
• The Run Option was set to a fixed duration of one minute.

Test methodology:
Begin this test with a fixed duration of one minute. Expand the test duration if test result accuracy indicators, such as Relative Precision, are indicating that too few timing records were generated for this specific pair. In general, IxChariot users should aim for a Relative Precision value of less than 10 in all tests.

Note: The Relative Precision is obtained by calculating the 95% confidence interval of the Measured Time for each timing record, and dividing it by the average Measured Time. This number is then converted to a percentage by multiplying it by100. The lower the Relative Precision value, the more reliable the result.


Figure 3: IPv6 Internet performance test results through a Layer 3 switch

As can be seen from the results of the above test, the performance of the switch when forwarding a limited amount of Internet application traffic is adequate. However, the test duration for this test should be extended since pair 1 only completed three timing records, thus creating a Relative Precision of more than 10.

3. IPv6 Internet traffic emulation with stateless IPv6 IMIX traffic for additional network congestion

Objective:
The objective of the test is to determine the behavior of the DUT when generating stateless IPv6 background traffic (IMIX) at a percentage of GigE line rate while running a set of Internet application scripts with IxChariot.

Input Parameters:
The primary input parameters for this test include:

• IPv6 addresses configured on the Ixia ports running the Performance Endpoints for IxOS to create n pairs.
• In this case, IxChariot scripts used in nine pairs reflect a combination of common Internet application scripts using both TCP-IPv6 and UDP-IPv6 as the underlying protocols. Scripts used in this test case include:
  • HTTPtext, HTTPgif
  • FTPget, FTPput
  • MSN Messenger Login, MSN Messenger Text Chat
  • POP3
  • Realmed, NetMtgv
• Network protocol - TCP and UDP for IPv6 respectively depending on the script type. This means that streaming media scripts will use UDP-IPv6.
• IPv6 Hardware Performance Pair (HPP) setup. In this case, a HPP using the same IP addresses as the standard IxChariot pairs was created by selecting an IPv6 stream type to generate stateless traffic (IPv6 IMIX). The stream rate was set to a percentage of the line rate of the Ixia port (e.g., 1%).
• E1 Setup addresses (i.e., management port IPv4 addresses of Ixia port).
• Run Option was set to a fixed duration of one minute.

Test methodology:
The test should involve as many ports on Ixia Load Modules as there are test ports on the DUT. For a single ingress/egress port pair, two pairs are defined (one for each IP version) and then executed with run options set to a fixed time. Compare the results to the test case described in Figure 3. Gradually increase the stream rate percentage.


Figure 4: IPv6 Internet performance test results with 1e-05 IPv6 IMIX traffic through a Layer 3 switch Some blurb on results when compared to Figure 3.

Increasing the IMIX stream rate shows that the Layer 3 switch has disproportionate problems to maintain average throughput. In addition, frequent sudden drops in the overall throughput for each pair can be regularly observed.


Figure 5: IPv6 Internet performance test results with 0.1 IPv6 IMIX traffic through a Layer 3 switch. As shown in Figure 6 below, care needs to be taken to not increase the line rate percentage beyond the capabilities of the switch because this may cause the pairs emulating TCP and UDP traffic to either timeout or to not complete any timing records within the test duration defined earlier.


Figure 6: IPv6 Internet performance test results with 0.25% IPv6 IMIX traffic through a Layer 3 switch

4. IPv6 Internet traffic performance test with IPv6 DoS attack

Objective:
The objective of the test is to determine the behavior of the DUT when running a standard mix of IPv6 application scripts while simultaneously flooding the device with an IPv6 Ping of Death attack.

Input Parameters:
The primary input parameters for this test include:

• IPv6 addresses configured on the Ixia ports running the Performance Endpoints for IxOS to create in ten pairs. In this case, the ten pairs are setup to use the same IPv6 addresses for E1 and E2 respectively.
• IxChariot scripts used in nine pairs should reflect a combination of common Internet application scripts using both TCP-IPv6 and UDP-IPv6 as the underlying protocols. Scripts used in this test case include:
  • HTTPtext, HTTPgif
  • FTPget, FTPput
  • MSN Messenger Login, MSN Messenger Text Chat
  • POP3
  • Realmed, NetMtgv
• Network protocol - TCP and UDP for IPv6 respectively depending on the script type. This means that streaming media scripts will use UDP-IPv6.
• IPv6 Hardware Performance Pair (HPP) - set up an HPP using the same IP addresses as the standard IxChariot pairs. Select an IPv6 stream type to generate stateless traffic. In this case, IPv6 PingOfDeath was selected as the stream type. Please note that we are sending traffic against the DUT, so E2 will should be set with the IPv6 address of the DUT. Set the stream rate to a percentage of the line rate of the Ixia port (e.g., 1%).
• E1 Setup addresses (i.e., management port IPv4 addresses of Ixia port).
• Set Run Option to a fixed duration of five minutes and review the test results. Increasing the test duration for tests that stress the DUT with Hardware Performance Pair will help to ensure good Relative Precision values (i.e., 10 or less) in the IxChariot results.

Test methodology:
The test should involve as many ports on Ixia Load Modules as there are test ports on the DUT. For a single ingress/egress port pair, two pairs are defined (one for each IP version) and then executed with run options set to a fixed time. Gradually boost the stream rate percentage to increase the load of the Ping of Death attack.
Figure 7: IPv6 Internet performance test results with 1% IPv6 PingOfDeath traffic targeted against the Layer 3 switch

As shown in Figure 7, the DUT is handling the attack traffic very well with only a minor decrease in overall throughput when compared to Figure 3.

Note: The IPv6 Ping of Death stream traffic was targeted against the IPv6 address of the DUT. Therefore, IxChariot will not report any results for this pair (pair 10). It is recommended that you verify the correct operation of this pair in either IxExplorer or with a protocol analyzer.

Increasing the line rate percentage to 5% resulted in a substantial drop in overall throughput; however, in general, the DUT handled IPv6 Ping Of Death traffic targeted against device better than IMIX traffic traversing the device.


Figure 8: IPv6 Internet performance test results with 5% IPv6 PingOfDeath traffic targeted against the Layer 3 switch

5. Basic IPv6 VoIP testing

Objective:
The objective of the test is to determine IPv6 VoIP quality through the L3 switch with increasing levels of bi-directional calls.

Input Parameters:
The primary input parameters for this test include:

• IPv6 addresses configured on the Ixia ports running the Performance Endpoints for IxOS to create n pairs. In this case, the 20 pairs are setup to use the same IPv6 addresses for E1 and E2, respectively.
• Ten pairs are set up to generate G.711u traffic upstream through the DUT. The other ten pairs are set up to generate G.711u traffic downstream through the DUT.
• E1 Setup addresses (i.e., management port IPv4 addresses of Ixia port).
• Set Run Option to a fixed duration of 1 minute and take test result.

Test methodology:

The test should involve as many ports on Ixia Load Modules as there are test ports on the DUT. For a single ingress/egress port pair, two pairs are defined (one for each IP version) and then executed with run options set to a fixed time. If any RTP compression mechanisms exist on the DUT, run two iterations of the test (RTP compression turned off and turned on).


Figure 9: Maximum jitter delay variations for IPv6 VoIP show significant inconsistency for the duration of the test

The test results show that the DUT introduces significant jitter to the bi-directional VoIP pairs. In general, a maximum jitter delay variation of less than 10 is considered "good" ;whereas, in this case, these values generally exceeded 23ms. This may imply that the jitter buffer values in IP phones may have to be increased should a transition to IPv6 VoIP occur.

Additional scalability-focused test cases could be run that leverage Ixia hardware to emulate tens of thousands of bi-directional calls per port. Depending on the capabilities of the DUT, care needs to be taken when configuring the number of calls that these voice Hardware Performance Pairs (vHPP) are emulating in an IPv6 test. For example, the vast majority of L3 switches can only forward less than 10Mbit/s of IPv6-RTP traffic. This means that the number of concurrent calls to be emulated in the stream needs to be set to be a small percentage of the line rate (e.g., 150 concurrent G.711 streams will generate 9.6Mbit/s in one direction). When setting the number of concurrent calls to be emulated too high, the switch starts to fail forwarding packets, thus causing timeout errors for standard VoIP pairs (CHR216). A screenshot with the main setup options is shown in Figure 10.


Figure 10: Defining concurrent IPv6 VoIP call emulations per stream

[ back | top of page | back to test plans ]