Library: Test Plans

Switch Testing

1. Overview

1. RFC 2889 Address Cache Size Test
2. Data Integrity and Error Checking Test
3. RFC 2544 Benchmark Tests
4. RFC 2889 Frame Error Filtering Test
5. RFC 2889 Fully MeshED Test
6. Layer 2-3 Stateless QoS Functional Test
7. Spanning Tree Network Convergence Performance Test
8. OSPF Performance test

Overview

Switching in this document refers to the function of Layer 2 and 3 devices that interconnect other network devices and computing equipment. While there is some overlap with the functionality of other devices, such as routers, switches operate at Layers 2 and 3 of the seven layer OSI Model.

There are a great variety of switches available today. Figure 1 provides a view of the various features and functionality of switches, ranging from simple low-end switches to multi-function high-end switch products. High-end switches additionally provide much higher performance than low-end switches.

The primary functions of a switch include:

• Forwarding based on Layer 2 and/or 3 information
• Forwarding with traffic prioritization (QoS)
• Internetworking with other switches and devices
• Switching between various network interfaces and speeds (e.g., 10/100/1000/10G Ethernet, ATM, T1, E1, etc.)
• Security features and filtering (e.g., VLAN, ACL, etc.)

Low-end switches are unmanaged, plug-and-play devices. Their purpose is to forward traffic with no advanced traffic analysis or scheduling. They are designed for small user groups, including home use.

Medium range switches are more advanced, configurable devices capable of running Spanning Tree for loop prevention as well as supporting VLANs and traffic prioritization/scheduling. These devices also often support multicast protocols.

Medium to high-end switches are deployed in larger networks and are distinguished by the addition of IP routing functionality. They are capable of effectively managing various types of traffic including a mix of data, voice, and video traffic, and forwarding traffic at line rate. They provide higher port density, higher scalability and performance, as well as offering a wider variety of interface modules and types.

High-end switches are deployed in large scale networks where high performance and resiliency are critical requirements. They interconnect with many other switches and routers and can operate as the backbone of the network. These devices are highly scalable in both ports and protocols, providing a high level of reliability and performance.

This test plan provides a general framework and structure for custom test plan development that addresses the performance and functional tests requirements for the first three categories of switches outlined above. It provides a starting point that can be extended to cover many other aspects of switch functionality. Ixia's IP testing systems can be used to meet your specific switch testing requirements, and assist in the benchmarking and pre-deployment analysis of network devices and systems.

Following is a description of the 8 test cases outlined in this test plan.

Test Case	Description
RFC2889 Address Cache Size	Identifies the switch address table size capacity. This is achieved using a binary search algorithm. beginning at half the size of the initial user-specified table size
Data Integrity and Error checking	Verifies the DUTs ability to forward frames under certain traffic rates without corrupting the payload. Frames are transmitted with a predefined data pattern and it is verified that the DUT properly forwards the frames.
RFC 2544 Benchmark	Provides a benchmark performance analysis of the DUT using industry standard methodology. Four functional test areas are covered: Back-to-Back, Frame Loss, Latency, and Throughput. These tests measure forwarding performance and latency using linear or binary searches.
RFC2889 Frame Error Filtering	Determines if the DUT correctly filters illegal frames such as undersized frames, oversized frames, frames with CRC errors, fragmented frames, alignment errors, and dribble errors.
RFC2889 Fully Meshed	Determine the total number of frames that the DUT can handle when it receives frames on all its ports. Each port in the test sends frames to all other ports in an evenly distributed, round-robin fashion at a specific user defined rate.
Layer 2-3 Stateless QoS Functional Test	Measures the baseline performance of the DUT with and without QoS when stateless traffic is injected into the network.
Spanning Tree Network Convergence	Verifies the DUTs Spanning Tree convergence performance. This test measures the network convergence based on the handling of Topology Changes Notifications and Configuration BDPUs as well as traffic switchover.
OSPF Performance	Measures the OSPF performance and scalability of a DUT. A defined OSPF topology is set up and the no-drop throughput and latency measured across it. The test supports both OSPFv2 and OSPFv3 protocols.

1. RFC 2889 Address Cache Size Test

Objective(s): The purpose of this test is to determine the switch's address table size capacity. The size of the address table for each port or for the entire switch is found by starting with half of the size of the initial user-specified table size and using a binary search algorithm. Learned frames are transmitted between each iteration. Then generic frames are transmitted at a user-specified frame rate to see if the DUT has properly learned all of the addresses. If neither frame loss nor flooding is detected, the address table size is increased, and the test is repeated in a binary fashion until the address table size is determined.

Setup
The baseline setup for this test requires three test ports. The DUT receives the traffic on one port and forwards it back to the other two emulated test ports for analysis. See Figure 2.

Ixia's IxScriptMate "RFC 2889 Address Cache Size Test" script can be used to set up and execute this test.

Figure 2. Address Cache Size test setup

Input Parameters

Parameters	Description
Frame Size	The selected frame size used for the test
Traffic Rate	Initial rate of Traffic to be sent from the transmit port
Table Size	The desired table size the user sets for this test
Age	The Age value that coincides with the address table aging parameter on the DUT

Table 2. RFC 2889 Address Cache Size Test Input Parameters Table

Methodology

1. Configure to start the test with an initial frame size, traffic rate, and a desired table size. Refer to Table 2 above for the necessary Input Parameters.
2. Run the test. The traffic received by the DUT is forwarded back to the other test ports for the DUT learned addresses accuracy check.

Figure 3. RFC 2889 Address Cache Size test setup

Results
The results shown in Figure 4 indicate that the traffic was sent to the DUT and received back from the DUT at a line rate of 5% and at a desired table size of 200, with a final address table size of 199. A total of 2000 frames were sent to the DUT at a rate of 10 frames for each learned address.

Figure 4. RFC 2889 Address Cache Size results

2.Data Integrity and Error Checking Test

Objective(s): The purpose of this test is to verify the ability of the DUT to forward frames at a certain traffic rate without corrupting the payload. This test consists of transmitting frames that contain some predefined data pattern and verifying that the DUT forwards the frames properly. The test calculates the number of sequence errors and the number of data errors.

The first measurement is made when the traffic rate is set at one level, and the second measurement is made when the traffic rate is increased to another level. A comparison is made between the two measurements to identify any possible impact on the data integrity results.

Setup
The baseline setup for this test requires two test ports. Both ports send Layer 2 or 3 traffic to the DUT with a predefined data pattern. The DUT receives the traffic and forwards it back to the same two emulated test ports for analysis. See Figure 5.

Ixia's IxScriptMate "MATS Data Integrity Test" script can be used to set up and execute this test.

Figure 5. Data Integrity test setup

Input Parameters

Parameters	Description
Frame Size	The selected frame size used for the test
Traffic Rate	Initial Traffic rate that the transmit port(s) will send
Data Pattern	User selected data pattern, for example AllOnes

Table 3. Data Integrity Test Input Parameters Table

Methodology
TEST 1 - Initial traffic rate

1. Configure to start the test with an initial, maximum traffic rate, e.g., 50%.
2. Enter the appropriate test parameters - refer to Table 3.
3. Run the test for the specified duration for all frame sizes. The traffic received by the DUT is forwarded back to the same transmitting test ports for analysis. The emulated test ports check for the validity of the frames and perform data integrity on the payload and sequence frames checking.

TEST 2 - Increased traffic rate

1. Increase the initial maximum traffic rate (e.g., 75%) and rerun the test.>

Figure 6. IxScriptMate Data Integrity test setup

Results
The results indicate that the traffic that was sent to the DUT and received back from the DUT at a line rate of 50% showed no errors in data, frame sequence, or any traffic loss. See Figure 7.

However, as the traffic line rate was increased to 75%, both traffic loss, as well as sequence errors, were observed. In addition, as the frame size was increased at the new higher traffic rate, sequence errors were also increased, though slightly. See Figure 8.

Figure 7. Data Integrity and Frame Loss / Error count report (traffic rate at 50%)

Figure 8. Data Integrity and Frame Loss / Error count report (traffic rate set at 75%)

3. RFC 2544 Benchmark Tests

Objective
These test cases address four performance benchmark tests defined by RFC 2544: Back-to-Back, Frame Loss, Latency, and Throughput. These tests determine throughput and latency characteristics of the device under test using linear or binary search algorithms.

An overview of these tests is listed below:

BACK-to-BACK: Starting with a maximum traffic rate, this test determines the maximum duration that the DUT can receive and forward without frame loss. Frames are sent at a user-specified rate. A binary search algorithm is used to obtain the longest duration by the DUT without any loss.

FRAME LOSS : Starting with the initial frame rate, the test transmits a specified number of frames to the DUT. The DUT receives the frames and then forwards them back to the other test ports, which in turn calculate the number of frames received and analyze the measured frame loss. A binary search algorithm is used to obtain the highest traffic load that the DUT can handle without any frame loss.

THROUGHPUT: Starting with an initial frame rate, the test transmits a specified number of frames to the DUT. The DUT forwards the frames back to the other port. A binary search algorithm is used to obtain both the rate and the frame size at which the DUT provides the best throughput.

LATENCY: Starting with a maximum traffic rate (where the DUT does not lose frames) the test compares the transmit timestamp of the tagged frames with the receive timestamp. The difference between the two timestamps is the measured latency.

Setup
The baseline setup for these test requires two test ports directly connected to the DUT and generating traffic at various frame sizes and traffic rates. See Figure 9.

Ixia's IxScriptMate "RFC 2544" test suite can be used to set up and execute this test.

Figure 9. RFC 2544 Benchmark Tests setup

Input Parameters

Parameters	Description
Frame Size	The selected frame size(s) used for the test
Traffic Rate	Initial Traffic rate of the transmit port

Table 4. RFC 2544 Benchmark Tests Input Parameters Table

Methodology
TEST 1- Back-to-Back

1. Set up the test parameters for this test. Refer to Table 4 for the Input Parameters.
2. Start the test and run for all selected frame sizes. This test performs a binary search to determine the longest duration the DUT experiences in forwarding frames without any loss.
3. See Figures 11 and 12 for results analysis.

TEST 2- Frame Loss

1. Set up the test parameters for this test. Refer to Table 4 for the Input Parameters.
2. Start the test and run for all selected frame sizes. The test performs a binary search for the highest traffic load that the DUT can handle with the least frame loss.
3. Once the test concludes, note the frame loss values as both the frames size and the traffic rate changes. See Figures 13 and 14 for results analysis.

TEST 3- Throughput

1. Set up the test parameters for this test. Refer to Table 4 for the Input Parameters.
2. Start the test and run for all frame sizes. The test performs a binary search for the highest traffic load that the DUT can handle with the best throughput.
3. See Figure 15 for results analysis.

TEST 4- Latency

1. Set up the test parameters for this test. Refer to Table 4 for the Input Parameters.
2. Set the traffic rate for a relatively low rate to ensure the least possible traffic loss and more accurate latency measurements.
3. Start the test and run for all frame sizes. The test performs a binary search for the highest traffic load that the DUT can handle with the least latency.
4. See Figures 16 and 17 for results analysis.

Figure 10. IxScriptMate RFC 2544 Benchmark Tests setup

Results
The results for each of the 4 test cases are given below.

The Back-to-Back test concludes the maximum number of back-to-back frames that the DUT is capable of forwarding without any frames loss for each of the frame sizes. See Figures 11 and 12.

The Frame Loss test concludes that frame loss is experienced when the traffic rate increases above the 50% mark, regardless of the frames size. See Figures 13 and 14

The Throughput test concludes that the best aggregate throughput for the DUT is experienced when frame size is at a minimum of 64 bytes size. The results show the best traffic that the DUT is able to forward without any data loss for each of the frame sizes. See Figure 15.

The Latency test concludes that the least average latency for the DUT is observed when frame size it at a minimum of 64 bytes size. The best throughput is noted when frame size is at a minimum of 64 bytes size. See Figures 16 and 17.

Figure 11. RFC 2544- Back-to-Back iterations statistics results

Figure 12. RFC 2544- Back-to-Back summary results per frame size

Figure 13. RFC 2544- Frame Loss iteration statistics results

Figure 14. RFC 2544- Frame Loss aggregate results per frame size

Figure 15. RFC 2544- Throughput aggregate results per frame size

Figure 16. RFC 2544- Latency aggregate results per frame size

Figure 17. RFC 2544- Latency statistics results per frame size

4. RFC 2889 Frame Error Filtering Test

Objective
This test determines if the DUT correctly filters illegal frames, such as undersized frames, oversize frames, frames with CRC errors, fragmented frames, alignment errors and dribble errors.

The results show the type of error transmitted, the number of transmitted frames, inter-frame gap, and the number of errored frames at each frame size.

Setup
The baseline setup for this test requires three test ports. One emulated port sends Layer 2 traffic to the DUT. The DUT receives the traffic and filters any of the illegal frames or errors and forward back only acceptable frames to the test ports for analysis. See Figure 18.

Ixia's IxScriptMate "RFC 2889 Frame Error Filtering Test" script can be used to set up and execute this test.

Figure 18. RFC2889 Frame Error Filtering test setup

Input Parameters

Parameters	Description
Frame Size	The selected frame size(s) used for this test
Illegal frame types	Selected illegal frames and types to send to the DUT
Traffic Rate	Initial Traffic rate that the transmit port(s) will send

Table 5. RFC2889 Frame Error Filtering Input Parameters Table

Methodology

1. Set up the test parameters for this test. Refer to Table 5 for the Input Parameters.
2. Start the test and run for all selected illegal frame types and maximum traffic rate. See Figure 19.
   The traffic goes through the DUT and is forwarded back to the emulated test ports after all illegal and unaccepted frames are filtered by the DUT.
3. Once the test concludes note the Frame Error Filtering results. See Figure 20.

Figure 19. IxScriptMate RFC2889 Frame Error Filtering test setup

Results
The only error that was found and detected by the test ports in this test was for a frame size of 1,519, which was allowed to be forwarded by the DUT. See Figure 20.

Figure 20. IxScriptMate Frame Error Filtering report

5. RFC 2889 Fully Meshed Test

Objective
The purpose of this test is to determine the total number of IP frames that the DUT can handle when it receives frames on all its ports. Each port in the test sends frames to all other ports in an evenly distributed, round-robin type fashion at a specific user-defined rate.

Setup
The baseline setup for this test requires three test ports. All ports send Layer 2 or 3 traffic to the DUT with an initial traffic rate. Traffic is forwarded back to the same three ports for analysis. This test requires VLAN and IP addresses to be configured on the DUT.

Ixia's IxScriptMate "RFC 2889 Fully Meshed Test" script can be used to set up and execute this test.

Figure 21. IxScriptMate Fully Mesh test setup

Input Parameters

Parameters	Description
Frame Size	The selected frame size(s) used for the test
Traffic Rate	Initial traffic rate that the transmit port(s) will send
Traffic Data Type	The user selected Data Type, for example IP
DUT setup	DUT is configured for VLANs with IP address association

Table 6. RFC 2889 Fully Meshed Test Input Parameters Table

Methodology

1. Set the initial Traffic Rate, Frame Sizes, and Data Type for the test. Refer to Table 6 for the Input Parameters.
2. Run the test for the desired duration for all selected frame sizes and traffic rate. See Figures 22 and 23.
3. Once the test concludes, note the ports statistics results. See Figure 24.

Figure 22. IxScriptMate RFC 2889 Fully Meshed test traffic setup (1)

Figure 23. IxScriptMate RFC 2889 Fully Meshed test traffic setup (2)

Results
The results indicate that the DUT experienced frame loss for each of the selected frame sizes when the traffic rate was set at 50%. See Figure 24. This degradation in performance is possibly related to the buffering algorithm on the DUT, which had slowed down due to the intensive load of frames received and the associated processing requirement.

Figure 24. RFC 2889 Fully Meshed port statistics per frame size test report

6. Layer 2-3 Stateless QoS Functional Test

Objective
The purpose of this test is to measure the baseline performance of the DUT with and without QoS when stateless traffic is injected into the network. Stateless traffic is of type Layer 2 -3 data and does not emulate true user application traffic. This test verifies that the latency and the packet loss on the egress traffic port degrades significantly when QoS is enabled on the receiving DUT. The first step is to take measurements and collect statistics when QoS is disabled on the DUT. The second step is to take measurements and collect statistics when QoS with IP Precedence classifying and marking are enabled on the DUT.

Setup
The baseline setup for this test requires four test ports. Three ports are used to generate Layer 3 traffic connected to three DUT ports. These connections are considered the ingress ports to the DUT or the network. Each port carries a separate stream with a specific IP Precedence marked value. The fourth test port is connected to a fourth DUT port to evaluate the outgoing network traffic (egress) based on the QoS service characteristics and settings. See Figure 25.

Ixia's IxScriptMate "QoS Many-to-One" test can be used to setup and execute this test.

Figure 25. QoS Many-to-One test setup

Input Parameters
Two sets of parameters are required prior to running the Layer 2/3 QoS functional test. One set of parameters is for the test tool and the other for the DUT.

Parameters	Description
Frame size	Packet frame size can bet set as fixed or random
Duration	Test Duration to run ranges from hours down to seconds
Traffic Rate	Traffic rate per priority level
DUT-QoS	Administrative DUT QoS setting (enabled or disabled)
DUT-Line speed	The link / interface speeds of the DUT ports
DUT-QoS type	DUT QoS type settings: COS, ToS IP Precedence, or DSCP
DUT-QoS Policies	DUT QoS Policies applied to the ingress traffic
DUT-Queue type	Queuing mechanism such as Weighted Random Early Detection (WRED) and Weighted Round Robin (WRR) Queuing

Table 7. QoS Many-to-One Input Parameters Table

Methodology
TEST 1- QoS is disabled on the DUT

1. With QoS disabled on the DUT, configure the network according to Figure 25.
2. Set up the simulated traffic rate per type. Refer to Figure 26. Refer to Table 7 for the test Input Parameters.
3. Start the traffic, and run for the test duration. The traffic is received by the DUT and is not prioritized or classified. See Figure 27. Note the packet loss and the latency measurements in Figure 28 and 29.

TEST 2- QoS is enabled on the DUT

1. Enable QoS on the DUT, and rerun the same test.
2. The traffic that is received (ingress) by the DUT is classified, prioritized and processed accordingly. See Figure 30. The resultant traffic (egress port) is measured for packet loss and latency.
3. Observe the new packet loss and latency measurements in Figures 31 and 32.)

Figure 26. IxScriptMate QoS Many-to-One Test Setup

Results
The results show some packet loss but no particular order in latency is shown when QoS is disabled. See Figure 27. The lower priority traffic (priority 0) still shows the highest packet loss.

Figure 27. IxScriptMate log with QoS disabled on the DUT

Figure 28. Receive and Loss rate for all three streams

Figure 29. Latency for all three streams

Figure 30.IxScriptMate log with QoS enabled on the DUT

Figure 31. Receive and Loss rate for all three streams

Figure 32. Latency for all three streams

Figure 33. QoS Many-to-One test per port statistics

7. Spanning Tree Network Convergence Performance Test

Objective
This test verifies that whenever the Path Cost to root changes, a bridge link goes down, or a bridge stops sending BPDUs during traffic generation on a switched LAN, that the Spanning Tree topology is recalculated to update all bridges on the network with the latest BPDU topology notification and changes. This test also measures the network convergence based on the DUT performance and handling of the Topology Changes Notifications and Configurations BDPUs, as well as traffic switchover.

This test case validates the following:

• DUTs Spanning Tree recalculation based on new Root Path Cost, a bridge link failure, or a bridge stops sending BPDUs
• Network topology changes and convergence due to the occurrence of any of the previously listed conditions
• Traffic switchover from one emulated bridge port to another due to the occurrence to any of the previous listed conditions

Any traffic forwarded by the emulated bridge from Host A to Host B through the DUT bridge will be halted until the complete Spanning Tree is recalculated, the new Spanning Tree topology has stabilized, and all network bridges ports have reached their final state. After the Spanning Tree is stabilized, the traffic is switched over from one path to another. This switchover mechanism should take about twenty-eight seconds for the Spanning Tree to complete, and is virtually immediate for the Rapid Spanning Tree protocol, since the later is designed with less port states to cycle through before the Spanning Tree network topology is stabilized.

Setup
The baseline setup for this test requires three test ports. Each of the first two test ports emulates a bridge connected to two separate physical ports on the DUT running Spanning Tree Protocol. In addition, a third DUT bridge port is connected to a non-Spanning Tree emulated test port for sending and receiving traffic. At startup, the emulated bridge is the root bridge for the network (set the emulated bridge ID to be the lowest ID by changing priority and/or MAC address).

Ixia's IxRouter application can be used to set up and execute this test

Figure 34. Multiple Spanning Tree emulated bridges connected to the DUT

Input Parameters

Parameters	Description
Root ID	Contains the bridge ID of the root bridge. The root ID consists of the Priority, System ID and MAC Address. After convergence, all Configuration BPDUs in the bridged network should contain the same value for this field.
Root Cost	The cumulative cost of all links leading to the root bridge.
Bridge Mode	Bridge mode type can be Spanning Tree or Rapid Spanning Tree.

Table 8. Spanning Tree network convergence Input Parameters

Methodology
TEST 1- Traffic switchover due to Path Cost change

1. Set BR1 and BR2 Sending Root bridge MAC address to CC CC CC CC CC CC and priority 4096. The root is the imaginary emulated root bridge.
2. BR1 and BR2 bridge ports are in Root Forwarding. One of the DUT bridge ports is in Alternate / Blocking state.
3. Set up two traffic streams on BR1 and BR2 for the emulated Host B, and stream 3 for the emulated Host A.
4. Stream 1 on BR1 is set with the Host B MAC address value for the DUT to learn Host B MAC address from BR1. Stream 2 on BR2 is set with the Host B MAC address value for the DUT to learn Host B MAC address from BR2.
5. Set up traffic stream 3 on the emulated traffic receive / generation port for the DUT to learn Host A MAC address.
6. Start traffic streams enabling the DUT to learn the MAC address of the emulated LAN nodes.
7. Host A <- -> Host B traffic is going over one of the available DUT / emulated bridge Paths. See Figure 34.
8. Select the emulated bridge that is forwarding the traffic, and change its Path Cost to Root from 0 to 3, forcing the Spanning Tree to be recalculated.
9. The traffic is temporarily halted due to the new topology change occurrence.
10. Once the Spanning Tree is stabilized and all ports have reached their final states, the traffic will switch over to the other Path. See Figure 34.
11. Any other path from any of the bridges in the network to the root bridge (DUT) that is not needed in this switched network will be set to blocking state, avoiding redundant path to the Root and possible looping condition.

TEST 2- Traffic switch over due to link down

1. Given that the traffic has been handled by one of the DUT ports that is connected to the emulated bridge port via one of the paths, select this emulated bridge port and simulate a cable disconnect.
2. The same behavior as in previous step is observed: The Spanning Tree is recalculated based on the new topology change and the network converges.
3. The traffic is once again switched over to the other available path. This process will only take few seconds.

TEST 3- Traffic switch over due to one bridge stopping BPDUs

1. Given that the traffic has been handled by one of the DUT ports that is connected to the emulated bridge port via one of the paths, select this emulated bridge and stop its Spanning Tree protocol.
2. The same behavior as in previous step is observed: The Spanning Tree is recalculated based on the new topology change, and the network converges since one of the bridge ports has removed itself from the Spanning Tree topology.
3. The traffic is once again switched over to the other available path. This process will only take a few seconds.

Results
The success of this test depends on the convergence of the Spanning Tree and traffic switchover. This process will only take about 15-20 seconds for Spanning Tree mode (STP), and is virtually immediate for Rapid Spanning Tree mode (RSTP). The results shown below are captured for Spanning Tree mode (STP).

The verification is calculated before and after the change of the Spanning Tree due to the new Path cost bridge parameters change.

NOTE: The initial Spanning Tree state shows that the lowest cost to the root is the preferable path. To avoid looping, the Spanning Tree Protocol will block the other path from forwarding traffic. The other port will be set as Alternate/Blocking on the DUT.

Before switchover, the bridge ports state show the following:

• Ixia BR1 port 1 Designated/Forwarding
• Ixia BR2 port 2 Designated/Forwarding
• DUT indicates the imaginary bridge with MAC is the Root (that is CC CC CC CC CC CC)
• DUT port 1 is Root/Forwarding
• DUT port 2 is Alternate/Blocking

The traffic passes through Ixia port 1 as shown in Figure 34 prior to switchover.

After switchover, the bridge ports state should show the following:

• Ixia BR1 port 1 Designated/Forwarding
• Ixia BR2 port 2 Designated/Forwarding
• The imaginary bridge with MAC is the Root (shown in the DUT)
• DUT port 1 is Alternate/Blocking
• DUT port 2 is Root/Forwarding

The traffic is shown passing through Ixia port 2 as illustrated in Figure 35 below, identifying the drop down of packets received on BR1, the delay (about 28 seconds), then the traffic picking up with the BR2.

Figure 35. Traffic switch over from BR1 to BR2

8. OSPF Performance test

Objective
The OSPF performance test is designed to measure the no-drop throughput and latency by setting up defined routes and a topology and then measuring the no-drop throughput and latency between advertised ports. The test can be executed with either the OSPFv2 or OSPFv3 protocols.

Setup
This test requires two ports to be connected to the DUT. Each test port simulates routers and networks behind the routers on each side of the DUT. See Figure 36.

Ixia's IxScriptMate "OSPF Performance Test" can be used to setup and execute this test.

Figure 36. OSPF Performance test setup

Input Parameters

Parameters	Description
Frame Size	The selected frame size(s) used for the test
Traffic Rate	Initial Traffic rate that the transmit port(s) will send
OSPF Parameters	OSPF area ID, number of emulated routers, number of emulated routes, Inter-area or External type routes
DUT setup	DUT is configured for OSPFv2 or OSPFv3 operation
DUT OSPF Area	DUT interfaces are set for OSPF area 0 (backbone)

Table 9. OSPF Performance Input Parameters Table

Methodology

1. Configure two test ports for OSPF. Refer to Table 9 for the Input Parameters. This test sets up a routing infrastructure and topology where several routers on each side of the DUT have been simulated with hundreds of routes behind each router.
2. Once route verification is successful, start traffic across the learned routes.
3. Observe the results once the test concludes. See Figures 37 and 38.

Results
This test shows the DUT's ability to handle OSPF routed traffic in addition to learning and announcing all the OSPF learned routes by using either a linear or binary search function. Refer to Figure 37 for the OSPF performance statistics per port describing Frame Loss, Latency, and Throughput per port.

Figure 37 indicates that as the frame size increases from 64k to 128k, the no drop rate decreases from 58.33% down to 54.41%.

The more interesting results appear in Figure 38, which illustrates that as the traffic is increased above the 55-56% mark, a noticeable increase in traffic loss is experienced. Such results and measurements indicate that the DUT is experiencing packet processing and route forwarding performance degradation.

Figure 37. OSPF Performance per port statistics

Figure 38. OSPF Performance - Iterations statistics

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