The Definitive Guide to Switch Testing

Transcription

1 Inspired Innovation Test Methodology Journal The Definitive Guide to Switch Testing July 2007

2 Table of Contents Introduction 2 Layer 2 and Layer 3 Testing 3 VLAN 48 RFC RFC Multicast Registration Protocols 154 Spanning Tree Protocol 256 Access Control List 282 Negative Testing 319 Glossary 341 1

3 Introduction Welcome to The. This guide from is a comprehensive handbook for testing a variety of common switch functions and provides all of the information necessary to begin testing basic and advanced features of switches. Functional, performance and scalability tests are included, along with fully illustrated and detailed step-by-step instructions. Switches have significantly evolved in the past several years. Basic packet forwarding at line rates is now only a small portion of their tasks. Today s switches also must handle QoS, ACLs and VLANs while supporting multicast traffic, providing security and ensuring data integrity. While handling all of these processes, switches also must monitor and address constantly changing topologies and then correctly process error conditions. If that s not enough, they have to be extremely scalable to meet the demands of next generation networks. As the overall complexity of switches continues to increase, it follows that switch testing will require increasingly sophisticated tools and personnel. has many switch testing solutions that validate and measure switch functionality, scalability and performance characteristics. This book will guide test engineers in the use of this equipment for many types of tests. Users can test VLANs, IGMP join and leave latency even RFC 2544 or RFC 2889 by following easy to understand instructions. Additional permutations are also suggested for most test cases so the test engineer can expand and customize tests. Additional test methodologies can also be found at Spirent s online Knowledge Center at Best wishes with your testing efforts. Sincerely, 2

4 Layer 2 and Layer 3 Testing Table of Contents Introduction to Layer 2 and Layer 3 Testing 4 The Test Methodologies Capacity Testing 5 QoS Performance Testing 22 3

5 Introduction A typical test plan for a network or network device starts with basic Layer 2 and Layer 3 (L2/L3) functional testing and progresses to more complex scenarios. The purpose of this document is to help the user understand the steps for performing data plane only tests on TestCenter. The test methodologies listed below should serve as examples and not all-encompassing L2/L3 testing scenarios. They require at least three TestCenter ports and the Spirent TestCenter application. Two tests are included in this document: Test 1 Capacity Test This test illustrates how to test the capacity of a device. The Device Under Test (DUT) is configured to use two Virtual Local Area Networks (VLANs) and traffic is sent from one VLAN to the other. The test is run for a finite amount of time and once the test has completed the capacity of the DUT can be determined. Test 2 QoS Performance Testing This test illustrates how to test a device for L3 Quality of Service (QoS) performance. The DUT is configured for 3 classes of service based on IP precedence. Traffic is sent from two ingress ports to the same egress port. A few permutations are run to understand the performance of the DUT when the egress port is oversubscribed. 4

6 Capacity Testing Associated RFCs RFC 1242: Benchmarking Terminology for Network Interconnection Devices RFC 2544: Benchmarking Methodology for Network Interconnect Devices Objective This test validates workloads, ensuring proper functionality with minimal loads. Overview This procedure ensures a candidate workload functions correctly. It also assists with discovery of connectivity issues, syntax errors and other problems before the high-load test is run. Use this validation as a first step before the upcoming test methodologies in this journal. Setup 5

7 Step-by-Step 1. Configure the Device Under Test (DUT) to use at least two Virtual Local Area Networks (VLANs). Traffic will be generated and sent in a meshed port pairing from one VLAN to another. This will help determine the capacity and latency of the DUT. 2. Launch the Spirent TestCenter Application and select the Port Reservation button. 6

8 3. In the new window, reserve the required ports and select the close button. 7

9 4. Depending on the DUT s configuration, it might be required to manually configure the port speed and duplex. Select the port from the port listing in the navigation window. 5. Select the correct Media Type and then uncheck the Auto Negotiate box. This will allow for the selection of Speed and Duplex settings. Notice on the right side a display of the currently configured settings. Once changes have been made, the Apply button will become enabled. Press this button to effect the changes. Also, do this for the other reserved ports. 8

10 6. Expand the first reserved port in the navigation box and select Hosts. 7. In the new screen that appears to the right, select Add. 9

11 8. In the window that appears, the first screen allows you to select the ports you wish to configure. We will configure each port separately, though it is possible to configure multiple ports. As the first port is already selected, press Next. 10

12 9. As we are not going to use advanced protocols, use the defaults in this window. Press Next to continue. 10. The default encapsulation is also okay. Press Next to continue. 11

13 11. If you are configuring multiple hosts use the buttons at the extreme right of the window to correctly configure them. If only a single host is being configured, make sure to correctly set the IPv4 address and the IPv4 gateway fields. If you wish to view a preview, select Next; otherwise select Finish. 12

14 12. After making sure that everything is configured correctly in the Preview window, select Finish to commit the updated information. 13. Repeat steps 4-10 for the second reserved port, if necessary. 14. In the navigation window, select Traffic Generator under the first reserved port. 13

15 15. In the frame that just loaded, select the Add button to start creating traffic streams. 16. From the Add drop down menu, select Add Bound Stream Block(s). 17. In the window that appears make sure both ports are selected and press Next. 14

16 18. Select the Fully meshed Distribution option and again make sure both ports are selected. Once completed press the Next button. 15

17 19. The defaults in this screen are okay. Press Next to continue. 16

18 20. It is possible to change the name of the Stream block. Make sure to select the Random option and change the Max frame size to This will provide a more realistic test case. Also, increase the Load value to 100. Once these configuration changes have been completed, press Next. 17

19 21. If you wish to make any changes to the header, it is possible to do so in this screen. Use the defaults in this test case and press Finish to finalize the creation of the streams. 22. Select the All Traffic Generators Option in the All Ports navigation window. Notice that two streams have been created. 18

20 23. Next, we must configure the test so that each stream will only run for 120 seconds. Select the Traffic Generation option under the first test port. 24. Change the Duration Mode to Seconds using the drop down menu. Next, change the Second(s) option to 120. Repeat this and the previous step for the second test port. Once both ports have had their traffic streams configured to run for 120 seconds, continue to the next step. 19

21 25. Before the traffic can be started we must send an ARP request to each host. Right-click on All Hosts under the All Ports. Select ARP/ND Start ARP/ND On All Hosts. If any of the ARP requests fail, verify the DUT s and Spirent TestCenter s configuration. 26. Once the ARPs have been successfully resolved, it is possible to start transmitting traffic. Start the traffic by selecting the button. This will start traffic on both ports. 27. In the Results Browser, verify that traffic is being successfully transmitted. 28. While the test is running, it is possible to view the bit rate at which data is being transmitted. In the Basic Traffic Results window scroll over to the right till the Total Rx Bit Rate is visible. This value will drop to zero once the test has completed, so take note of this value. 29. With the value of the Total Rx Bit Rate, use the below formula to calculate the actual transmission speed of the DUT. The formula will convert the Total Rx Bit Rate to Mbps. The formula is as follows: TotalRxBit Rate The DUT used in creating this methodology had a Total Rx Bit Rate of Using the formula, this provides a value of about 9.3 Mbps. The ports were configured for only 10 Mbps with Full Duplex. 2 20

22 31. Once the test has successfully completed, a new view is required in the Results Browser. Use the drop down menu in the right Results Browser display and select Stream Results Detailed Stream Results. 32. Locate the Tx and Rx Frame Count columns. Calculate the % Loss of frames, the formula is provided below. ( TxFrameCou nt RxFrameCount) TxFrameCount 33. If this value is less than 2%, the test has successfully been completed. If this value is greater than or equal to 2%, reduce the streams load and rerun the test. 21

23 QoS Performance Testing Overview This test analyzes Layer 3 Quality of Service (QoS) performance of a device. The Device Under Test (DUT) is configured for 3 classes of service based on IP precedence. Three Spirent TestCenter ports are connected to 3 ports on the DUT: two will serve as ingress ports for the traffic and one will serve as the target egress port. The ports on the DUT are all 10Mb Ethernet, so two ingress ports are needed to oversubscribe the egress port and cause QoS prioritization to occur. Traffic containing all 3 classes of service is transmitted to the DUT and a few permutations of oversubscription are run to understand how the DUT prioritizes the traffic. Objective Verify the DUT can properly prioritize traffic with different classes of service when oversubscription of available bandwidth occurs. Setup 22

24 Step-by-Step 1. Configure the DUT for 3 classes of service based on IP precedence value: HI = IP precedence 5, MED = IP precedence 4 and LO = IP precedence 3. Configure the relative weightings of the classes of service for egress port: HI = minimum guaranteed bandwidth of 60%, MED = minimum guaranteed bandwidth of 30% and LO = minimum guaranteed bandwidth of 10%. 2. Launch the Spirent TestCenter application and reserve the appropriate ports. 23

25 3. If necessary, configure the correct media type, port speeds and duplex settings. In this test Auto Negotiation is disabled, Speed is set to 10M and full duplex is used. Note that even though Auto Negotiation is fully supported, the use of a static port speed is generally recommended. To configure the port, select the required port in the navigation window. 4. In the navigation window, expand the first port and select Hosts. 5. There are two ways to create the required hosts. The first way is to create each host on each port separately. The second way is to create all the hosts at the same time, though this depends on how the DUT is configured and which IP addresses are used. Ports on the DUT in this test are configured /24, /24 and /24. As it is easy to step the IPs per port, we will use the second way to create the hosts. Select the Add button to start. 24

26 6. Select all the ports, as hosts need to be created on each one. Once completed, press the Next button. 25

27 7. The defaults are okay, press Next to continue. 26

28 8. Again the defaults are okay, press Next to continue. 27

29 9. Fill in the correct IPv4 address that the host will use. If necessary, configure the Prefix length. The IPv4 gateway will automatically be determined. To configure multiple hosts, select the button in the IPv4 section. 10. Set the Step per port value to work with the DUT s port configuration. Once completed, press OK. 28

30 11. Notice how the Step field changed under the IPv4 section. To preview the host configuration, press the Next button. 29

31 12. Verify the hosts are correctly configured. If they are not, use the back button to reconfigure them correctly. Once the hosts are correctly configured press the Finish Button. 30

32 13. In the navigation window, select Traffic Generator under the first port. 14. Select the Add button and then select Add Bound Stream Block(s) from the list. 31

33 15. The defaults in the first screen are okay. Press Next to continue with the configuration. 32

34 16. Select the two hosts that will be used as the source and destination of the stream. 33

35 17. Once the hosts have been selected, press the Add button. Notice that the pair has been added. Press Next once completed. 34

36 18. The defaults are okay, press Next to continue. 35

37 19. First, change the Stream block name prefix to something that will make it easier to realize what QoS the stream has. Next, select the Vary Protocol & QOS check box. In the Load Options, change the Load Unit to Mbps and the Load to 1. This stream will be configured with a QoS value of 3. Next select the Configure button to configure the QoS settings. 36

38 20. Select the QoS tab and then in the Precedence section use the drop down menu to select a precedence value of 3 Flash. Next, press the Add button and then the OK button. 37

39 21. As no other changes need to be made, press Finish. 22. Repeat steps for QoS values of MED and HI. Though, make sure to use a different stream block prefix and to set the QoS values accordingly and make sure to set the Load value to 3 for MED and 6 for HI. In creating these streams, do not overwrite the existing configuration as this will delete the previously configured streams. 38

40 23. Once completed, three steams should be created. Verify the Load and Load Unit are correctly configured. If not, it is possible to edit the values in this view. 24. Another stream must be created on the second port. Expand the second port if not already done and select Traffic Generator. 39

41 25. Select the Add button and then select Add Bound Stream Block(s) from the list. 26. The defaults in the first screen are okay. Press Next to continue with the configuration. 40

42 27. Select the correct hosts for the Source and Destination. Once completed select the Add button. Again, notice how it adds the pair to the listing. 28. Repeat steps exactly as they are stated, as we wish to create another traffic stream that has a QoS value of LO. In creating the stream, do not overwrite the existing configuration as this will delete the previously configured streams. 29. Verify that the Load and Load Unit are correctly configured. As a stream already has the name of LO-1, change the stream name to LO-2 so it is easy to distinguish them. 41

43 30. Before we can start sending traffic, ARP requests must be sent out. Right-click on the All Ports item in the navigation window. Select ARP/ND Start ARP/ND and make sure that all the ARPs are successfully resolved. Below the Results Browser, it should mention if all the attempted ARPs resolved successfully. If they did not resolve correctly, check the test configuration. 31. Now traffic can start to be transmitted. Right-click on Traffic Generator under the first port and select Start Traffic. 42

44 32. In the Results Browser, the Total Tx Frame Count for the first port should increase as the Total Rx Frame Count for the third port increases too. This means traffic is being transmitted successfully. 33. Change the view to Stream Results Detailed Stream Results. This will provide information and statistics about each individual stream. 34. In the Detailed Stream Results window, scroll over to the right till the Rx Frame Rate is visible. 43

45 35. Using CTRL + Left Click select all four Rx Frame Rates. Once they are all selected, right-click and choose Add to Chart. 36. Fill in the View name and select Stream Results as the location to create the chart in. Once completed press OK. 44

46 37. A chart view should be created. It is also possible to place the mouse curser on one of the streams and receive more information. 45

47 38. Next, start the LO-2 stream by right clicking Traffic Generator under the second port and selecting Start Traffic. This will test the DUT s ability and check how the DUT handles oversubscription of the egress port. 46

48 39. The results for the permutation given in the previous step are shown below. Note the DUT creates some impact on the MED and HI traffic. Though it does drop a majority of the LO priority traffic. If the DUT was 100% compliant, no traffic would be dropped from the MED and HI classes since the egress bandwidth needed is still within the configured parameters. However, it is still doing a reasonable job of favoring high priority traffic over lower priority traffic. Also note the DUT is dropping more LO priority traffic from steam LO-2 than from stream LO-1. 47

49 VLAN Table of Contents VLAN Testing 49 Standards-Based Testing 49 Test Tool Challenges 49 VLAN Overview 50 Types of VLANs 51 Trunk Ports 59 Trunk Links, Access Ports and Hybrid Ports 59 VLAN Tagging and QoS with 802.1P 63 The Test Methodologies Functional Single VLAN Test 66 Functional Multiple VLAN Test 87 Routing with VLANs: Throughput Test over Trunk Link Test

50 VLAN Testing Standards-Based Testing From initial development to large-scale performance testing, the network switch manufacturer is not always sure how to test according to the well-established methodologies. By understanding the techniques to test, network equipment manufacturers increase their success rate with in-house tools for development testing and quality assurance. Third-party tools are needed for unbiased, hard results of switch performance. Knowing what and how to test provides efficiency and expedites the manufacturer s time to market. Once assured of an acceptable level of performance and scalability, manufacturers make their equipment available to their end-user customers: service providers and business customers, also referred to as enterprises. The well-quantified and optimized product has a much greater sales success rate to these endusers. To justify their equipment choices and implement the best network services possible, service providers and enterprises need to test per accepted standards prior to making purchasing decisions. After deployment into live networks, existing equipment can be retested in lab environments using the same RFC-based test tools. By performing regression testing, users can compare baseline test results with results after equipment is updated with new versions of switch firmware. Test Tool Challenges For years, networking professionals have turned to industry-established standards for guidance on testing the performance of switches and routers. RFC 2544, Benchmarking Methodology for Network Interconnect Devices by the Internet Engineering Task Force (IETF), is one such standard. With companion RFC 1242, Benchmarking Terminology for Network Interconnect Devices, the RFCs define a specific set of tests used to measure and report the performance characteristics of network devices. The results of these tests provide the user comparable data from different vendors with which to evaluate network devices. Despite the utility of the measurements outlined in RFC 2544 and 2889, the RFCs are dated and do not specify the explicit use of the latest technologies and trends: Layer 2 switches have added new capabilities of spanning tree and Local Area Networks (LANs). Layer 3 switches have added Quality of Service (QoS) techniques and IPv6. Technology across all OSI-layers continues to be driven by demand for video content and voice applications. The popularity of the Internet has contributed to the presence of complex routing protocols on core routers, and mission critical applications promote the need for content-aware multi-layer switches. Security reigns supreme as a must-have in all types of switching and routing devices. Additionally, these technologies are now frequently combined in a systematic way to work in unison in a single Device Under Test (DUT), or a System Under Test (SUT). This raises the bar for testing by requiring a test tool designed from its inception as an integrated system for accommodating all layers of the OSI model, and with a rich-set of technologies and test approaches or capabilities. A prolific technology that has advanced since benchmark RFCs were ratified is VLAN, or Virtual Local Area Network. The popularity of Ethernet-based services has increased the need for VLANs virtually everywhere on the network: edge, access and core. While IEEE standards exist for VLAN usage, there are no IEEE or IETF standards for VLAN testing. A standards-based test tool that provides coverage for essential VLAN techniques fills this void and provides a level of confidence for benchmarking and comparing the results in multiple test bed scenarios. 49

51 VLAN Overview So, why are VLANs used in the first place? VLANs can be used to group a set of related users, regardless of their physical connectivity. They can be located within a local organization or even across geographically dispersed locations. The users might be assigned to a VLAN because they belong to the same department or functional team, or because data flow patterns among them is such that it makes sense to group them together. A VLAN is a logical network grouping that can be used to isolate network traffic so members of the VLAN receive traffic only from other members of the same VLAN. Creating a VLAN is the equivalent of physically moving a group of devices to a separate switch (creating a Layer 2 broadcast domain). Note, however, that without a router, hosts in one VLAN usually cannot communicate with hosts in another VLAN. One particular type of router that may be used is the One-Armed Router (OAR), also called router on a stick (see Figure 1 on page 50). The OAR normally uses one Ethernet NIC or port for multiple VLANs and enables the VLANs to be joined. Its effectiveness depends on the 80/20 rule, which states that 80% of traffic in a network remains within a virtual local area network and doesn't need routing service. The other 20% of network traffic is between VLANs and goes through the one-armed router. Figure 1. One-Armed Router Configuration Therefore, networks with VLANs usually consist of both Layer 2 and Layer 3 devices. In essence, Layer 3 devices have the intelligence to drive a multiple VLAN network, while Layer 2 devices can only participate in the VLAN network. VLANs offer the following benefits: Broadcast Control VLANs create bridging domains and provide isolations of broadcasts and multicast traffic between VLANs, similar to the way switches isolate collision domains for attached hosts and only forward appropriate traffic out a particular port. IP workstation performance can be impeded, and can even be effectively shut down by broadcasts flooding the network. Security With VLANs, high-security users can be grouped into a VLAN and possibly on the same physical segment so that no users outside of that VLAN can communicate with them. Also, with VLANs that use routable protocols, i.e. IP, communication between VLANs (inter-vlans) can be achieved through a router, and the security and filtering functionality in routers can be utilized. 50

52 Performance Logical groupings provided by VLANs essentially create dedicated LANs on which users of network intensive applications can be assigned, thus improving performance for all users. Network management Network management is greatly improved. Due to the logical grouping of users, it is no longer necessary to pull cables to move a user from one network to another. Reduced costs The majority of large enterprise networks experience problems related to an abundance of broadcast traffic and/or network moves. These problems translate into increased costs to effectively run the organization. VLANs may be able to substantially reduce these costs and provide a means to leverage existing investments. Also, the number of devices required to implement a given network topology can be reduced by deploying VLANs. Without VLANs, if your network design requires ten machines divided into five different LANs, you would need five different switches or hubs. Therefore, most of the ports would be wasted. With VLANs, this scenario can be accommodated with one device. These inherent benefits come with test challenges that demand solutions for easily determining the following situations: Whether VLANs have been implemented correctly (functional testing). How the underlying network performance is affected (performance testing). If conformance to IEEE standards has been maintained. For all the benefits of VLANs and trunking, some risks must be weighed. Compared with physical separation between network segments, VLANs rely on the switch to be correctly handled. VLANs effectively create logical sub-interfaces on a port up to 4095 on a single port when using tagged VLANs and increase the network mishandling potential of the DUT. One major risk is that a packet leaks from one VLAN to another (VLAN leakage), possibly revealing sensitive information. (Testing with simple utilities such as ping or Traceroute are not practical when testing in large-scale and/or high performance environments.) Also, the occurrence of some frame types in a VLAN-aware environment can result in unexpected connectivity problems and security issues. Specially crafted packets can be injected into a VLAN to create a security breach. Any attack that could cause VLAN barriers to break requires a machine directly attached to the physical network. Only a local machine can execute an attack against the switch, and testing those conditions at various points on the network is imperative to evaluate the DUT s capability to block such an attack. It is possible that a misconfiguration or a bug could cause the VLAN barriers to be broken. These risks can be greatly mitigated with proper network testing. Even if the VLAN-based network is configured and operating well against security breaches, VLAN implementations can cause additional table lookups and processing by the DUT, and can adversely affect performance. To understand the test challenges regarding VLANs it is necessary to look at the various VLAN organizational methods. Types of VLANs Vendor implementations of VLANs can vary greatly. The following are some of the most common VLAN organizational methods. Port-Based MAC-Based Protocol or Network-Layer Based Frame Tagging Port-Based VLANs Also known as VLANs by port and segment-based VLAN, this is the simplest and most common form of VLAN. (See Figure 2 on page 52). In a port-based VLAN, the system administrator assigns the switch's ports to a specific VLAN. With port-based VLANs, no Layer 3 address recognition takes place. All traffic within the VLAN is switched, and traffic between VLANs is routed (by an external router or by a router within the switch). For example, the network administrator can designate Ports 2, 4, 6 and 9 as part of the engineering VLAN and Ports 17, 19, 21 and 23 as part of the marketing VLAN. With port-based VLANs the packet forwarding decision is based on the destination MAC address and its associated port. 51

53 In the diagram below, VLAN 1 is built from the ports of switch 1 (2, 3 and 7), of switch 2 (2 and 3), of switch 3 (1, 2, 3, 6 and 7), and of switch 4 (2, 3 and 7). At switch No. 5, no port is assigned to VLAN 1. VLAN 2 is built from the ports of switch 2 (1, 5 and 8), of switch No. 4 (4, 5 and 8), and of switch 5 (1, 2, 5 and 7). At switches 1 and 3, no port is assigned to VLAN 2. Switch 1 Switch 2 Switch 3 Switch 4 Switch 5 VLAN 1 Ports 2, 3, 7 2, 3 1, 2, 3, 2, 3, 7 None 6, 7 VLAN 2 Ports None 1, 5, 8 None 4, 5, 8 1, 2, 5, 7 Figure 2. Port-Based VLANs Advantages Defining VLAN membership and configuration is fairly straightforward. Advances in technology provide support for VLANs that span multiple switches. Compatible and complementary with Dynamic Host Configuration Protocol (DHCP), this would make IP address configuration automatic when IP subnets correspond one-to-one with VLANs. Disadvantages A port belongs to only one VLAN. Defining VLANs purely by port group does not allow multiple VLANs to include the same physical segment (or switch port). If hubs are connected to the switches, the users assigned to a specific hub can only be assigned to a common VLAN. 52

54 The network manager must reconfigure VLAN membership when a user moves from one port to another (unless DHCP is used). Communicating VLAN membership changes (such as after manual port reassignments) and updating the cached address tables of each switch can cause substantial congestion of the backbone. Test Concerns Ample number of test ports to simulate the network topology. The ability to cycle through multiple destinations MAC addresses, since forwarding decisions are made on destination MAC address. Integrated testing with DHCP since DHCP is often used with VLANs by port. VLAN leakage requires reporting of stray frames and capture ability to troubleshoot while the test is running. Testing with broadcast (and multicast) to assure they stay in the correct broadcast domain Insight into the MAC address cache tables, i.e. capacity, proper aging, and with ample number of MACs, and flexible MAC addressing. Support for negative testing including ports with overlapping VLANs, and duplicate addresses and VLANs. Learning issues with respect to MAC address or, with inter-vlan routing, address resolution. Inter-VLAN routing can affect performance negatively compared to intra-vlan communications. Since VLANs by port may be combined with other organizational methods such as VLAN tagging (described below) test setup wizards are needed to quickly create a mixture of tagged and untagged frames. One-armed routers can be a single point of failure in a network, or they can develop into a bottleneck if there are large amounts of traffic between VLANs. Checks and counters for proper broadcast behavior, i.e. assure broadcasts are not leaked. MAC-Based VLANs In MAC address-based VLANs, the MAC address of a workstation is assigned to a VLAN. (See Figure 3 on page 54.) Each switch maintains an assignment table of MAC addresses and their corresponding VLAN memberships. The source or destination MAC address in the frame (implicitly) determines to which VLAN a packet belongs. For example, in the diagram on page 54, VLAN 1 is built from the MAC addresses MAC_01, MAC_02, MAC_03, and MAC_04 through switch 3, as well as from the MAC addresses MAC_05 and MAC_06 (server) through switch 4. Through switches 1, 2, and 5, no MAC address is assigned to VLAN 1. VLAN 2 is built from the MAC addresses MAC_07 and MAC_08 through switch 4 as well as from the MAC addresses MAC_09, MAC_10, and MAC_11 (server) through switch 5. Through switches 1, 2, and 3, no MAC address is assigned to VLAN 2. 53

55 Switch 1 Switch 2 Switch 3 Switch 4 Switch 5 VLAN 1 None None MAC_1 MAC_5 None Source MACs MAC_2 MAC_6 MAC_3 MAC_4 VLAN2 None None None MAC_7 MAC_9 Soure MACs MAC_8 MAC_10 MAC_11 Figure 3. MAC-based VLANs2 Advantages VLANs based on MAC addresses enable workstations to be moved to a different physical location on the network with its VLAN membership automatically retained. Support of shared media hubs, which permit users from different VLANs to be on the same segment. Disadvantages All users must initially be manually configured (even with an automated tool) to be in at least one VLAN, and a list of MAC addresses maintained. When implemented in shared media environments, serious performance degradation will be run into as members of different VLANs coexist on a single switch port. A single MAC address cannot easily be assigned to multiple VLANs. This may lead to a limitation with respect to sharing server resources between more than one VLAN and result in serious problems when dealing with existing routers and bridges. Performance degradation can result in larger-scale implementations. Static reconfiguration is required when users migrate across the physical network, i.e. use a different docking station for their laptops. Security issues: An experienced user can reconfigure a NIC with a different MAC address, then directly access another VLAN. 54

56 Broadcasts cannot be restricted; users of all the VLANs will soon be distributed over all the switch systems. All broadcasts will be forwarded to all systems and therefore network traffic becomes quite complex and can reduce network efficiency. Test Concerns Need to measure performance degradation when members of different VLANs coexist on a single switch port. To emulate this effect multiple unique MAC addresses are configured on a test port that is connected to a switch. (The test ports are in-turn connected to disparate switches.) Requires multiple MAC addresses per port to be tracked by source port. Ample number of test ports to simulate the network topology. The ability to cycle through multiple source and destination MAC addresses, since forwarding decisions are made on either. VLAN leakage requires reporting of stray frames and capture ability to troubleshoot while the test is running. Testing with broadcast (and multicast) frames to assure they stay in the correct broadcast domain. Insight into the MAC address cache tables, i.e. capacity, proper aging, and with ample number of MACs, and flexible MAC addressing. Support for negative testing including duplicate addresses and VLANs. Learning issues with respect to MAC address or, with inter-vlan routing, address resolution. Inter-VLAN routing can affect performance negatively compared to intra-vlan communications. One-armed routers can be a single point of failure in a network, or can develop into a bottleneck if there are large amounts of traffic between VLANs. Checks and counters for proper broadcast behavior, i.e. assure broadcasts are not leaked. Network-Based: Protocol or IP Subnet VLANs With this method, the delivery of packets depends on protocols (IPv4, IPv6, IPX, NetBIOS, etc.) and/or Layer 3 addresses. VLANs based on network addresses at Layer 3, also referred to as Layer 3 VLANs, can differentiate between different protocols. This allows the definition of VLANs to be made on a per-protocol basis (implicitly). IP-subnet VLANs are not the same thing as IP protocol VLANs. An IP protocol VLAN sends all IP broadcasts on the ports within the IP protocol VLAN. An IP subnet VLAN sends only the IP subnet broadcasts for the subnet of the VLAN. With network-based VLANs, it is possible to have a different virtual topology for each protocol or address range, with each topology having its own set of rules, firewalls, and so forth. While within a VLAN, IP addresses may be used only as a mapping to determine membership in VLANs, routing between VLANs comes automatically without an external router or card. Network address-based VLANs will mean that a single port on a switch supports more than one VLAN. This type of VLAN is also known as a virtual subnet VLAN. Protocol or network-based VLANs can be a more flexible variant than port- or MAC-based VLANs since they provide the most logical grouping of users and eliminate the need for an external router. For example, two IP sub-networks can be assigned their own VLAN. A virtual routing interface, or logical port, can be configured that causes the Layer 3 switch to forward IP subnet broadcasts within each VLAN at Layer 2, but route Layer 3 traffic between the VLANs using the virtual routing interfaces. In the example on page 56, VLAN 1 is built from the IP addresses , , , and through switch 3, as well as from the IP addresses and (server) through switch 4. Through switches 1, 2, and 5, no IP address is assigned to VLAN 1. VLAN 2 is built from the IP addresses and through switch 4 as well as from the IP addresses , , and through switch 5. Through switches 1, 2, and 3, no IP address is assigned to VLAN 2. 55

57 Switch 1 Switch 2 Switch 3 Switch 4 Switch 5 VLAN 1 None None None Source MACs VLAN2 None None None Soure MACs Figure 4. Protocol-Based VLANs 56

58 Advantages Enables partitioning by a range of subnetworks or by protocol type. This is especially helpful when service or application controls are desired. Users can physically move their workstations without having to reconfigure each workstation s network address a benefit primarily for TCP/IP users. Defining VLANs at Layer 3 can eliminate the need for frame tagging in order to communicate VLAN membership between switches, reducing transport overhead. Protocol-based assignment also enables the administrator to use non-routable protocols such as NetBIOS to assign those to larger VLANs than would be possible with IP or IPX. This leads to a considerable increase in efficiency. Disadvantages Performance. Inspecting Layer 3 addresses in packets is generally more time consuming than looking at MAC addresses in frames. This is not true with some vendor implementations. Effective in dealing with TCP/IP but not as effective with IPX or AppleTalk, which do not involve manual configuration at the desktop. End stations running unroutable protocols such as NetBIOS may not be differentiated so they cannot be defined as part of a network-layer VLAN. Potential for more network management complexity. DHCP may be incompatible with this method unless the DHCP service understands how to support multiple subnets, or a DHCP server exists in each VLAN. Test Concerns Performance issues related to the additional processing overhead to analyze the data at Layer 3 instead of Layer 2. Some Layer 3 VLAN implementations associate the end station MAC address to a VLAN based on the subnet address, so there is a need to test with an ample MAC addresses. VLAN filtering, in which VLAN information is located within the packet may be used. The DUT may adversely affect performance based on the complexity and size of the tables. This may be particularly true if filtering functions are performed in software (on the DUT). Wizard for easy setup that allows configuring ports and subnet addresses that are assigned to the VLANs on DUT. Need automated, flexible traffic pattern options such as backbone and full mesh traffic in which traffic from each subnet is transmitted to each and every traffic subnet. Multiple subnets/networks per port to emulate the logical sub-interfaces with Layer 3 definition, as they would have in the real world. A variety of Layer 3 protocols and header content to simulate actual network traffic. VLAN leakage requires reporting of stray frames and capture ability to troubleshoot while the test is running. Ample number of test ports to simulate the network topology. Scalability of addressing for both MAC and IP. Learning issues with respect to MAC address or, with inter-vlan routing, address resolution. Inter-VLAN routing can affect performance, i.e., using virtual interfaces per VLAN, negatively compared to intra-vlan communications. Since VLANs by subnet/network may be combined with other organizational methods such as port-based VLANs, or VLAN tagging (described below) test setup wizards are needed to quickly create a mixture of VLANS with and without spanning subnets, and also a mixture of tagged and untagged frames. Checks and counters for proper broadcast behavior, i.e. assure broadcasts are not leaked Q Frame Tagging Tagging is most often based on the IEEE 802.1Q specification, which was ratified to improve the interoperability of VLAN between switches and network adapters from different vendors. While the standard addresses organizing VLANs by port, its emphasis is on the addition of a VLAN tag in the Ethernet frame. The tag provides an explicit, uniform way to create VLANs within a network and enables creation of a 57

59 VLAN that can also span across the network. Previously, VLAN implementation was vendor specific such as with Cisco ISL, so it was not possible to create a VLAN across devices from different vendors. Note: Some switches may look at the subnet mask in IP subnet-based VLANs and decide which VLAN the traffic belongs to based on that information. These switches may then decide whether or not to explicitly tag the frames, since both tagged and untagged frames can be forwarded. Advantages Allows VLANs to span multiple switches via a single trunk, unlike port-based VLANs where each VLAN requires a separate pair of trunk ports. The tagged VLANs provide a more effective means of connecting devices than port based VLANs, which require a separate trunk for every VLAN that you create. Interoperability across multiple vendor DUTs. VLANs can contain tagged or untagged ports. Can improve performance by helping to contain broadcast and multicast traffic across the switch. Ports can belong to more than one VLAN. This is beneficial if you have a file or print server that must belong to multiple VLANs. Provides security and improves performance by logically isolating users and grouping them together. Disadvantages Vendors differ in the way they solve the problem of occasionally exceeding the maximum length of MAC-layer frames as these headers are inserted. These headers also add overhead to network traffic. Can increase processing overhead on DUT that has to inspect frames and add/remove tags. The VLAN tag contains a VLAN Identifier (VID) that identifies the frame as belonging to a specific VLAN. These tags allow switches that support the 802.1Q specification to segregate traffic between devices and communicate a device's VLAN association across switches. A VLAN tag in the following location of the Ethernet frame has the following structure: The VLAN-aware DUT inserts the VLAN tag after the MAC source address in the frame, adding 4 bytes to the frame length, thereby increasing the maximum length to (Jumbo frames are also increased in size during this process.) 58

60 Components of the tag are: Tpid Tag protocol identifier. Default is 0x8100 for IP, TCP and UDP frames. Priority User priority. Stores the priority level of the frame used for QoS. Use of this field is defined in IEEE 802.1P as described in VLAN Tagging and QoS with 802.1P on page 63. CFI Canonical Format Identifier. Denotes whether MAC addresses in the frame are in canonical (the usual or standard state) format. When 0 (off) it indicates the device should read the information in a field canonically (right-to-left or low-order bits first), which is the case for Ethernet. But for Token Ring devices, which read in a non-canonical form, the value should be 1 (on). For this reason, the CFI is sometimes referred to as the Token Ring Encapsulation Flag. (It is of little concern in Ethernet only networks as long as it is set to 0.) Vid VLAN identifier. This 12-bit field allows up to 4095 VLANs per physical port or logical interface/network. Note: The tpid has assumed even more significance with the advent of VLAN stacking; also known as QinQ or super-vlans. QinQ is a mechanism that allows for the frame to contain 2 or more tags. Carriers usually add the additional tag as a public VLAN tag for frames to be transported over a metro network. This also allows a carrier to partition the network among several national ISPs, while allowing each ISP to still utilize VLANs to their full extent. Without VLAN stacking, if one ISP provisioned an end user into VLAN 1, and another ISP provisioned one of their end users into VLAN 1, the two end users would be able to see each other on the network. Trunk Ports The switch-to-switch connections (links) are typically called trunks. A trunk link is a point-to-point link that supports several VLANs. A trunk is a single physical connection that carries multiple LANs. (The tagged VLANs provide a more effective means of connecting devices than port-based LANs, which require a separate trunk for every VLAN that you create.) The main purpose of a trunk is to save ports when creating a link between two devices that are implementing VLANs typically two switches. Each frame that crosses the trunk has a VLAN identifier attached to it, so it can be identified and kept within the correct VLAN. Trunking protocols that use a frame tagging mechanism assign an identifier (via the VLAN tag) to the frames to make their management easier. This in turn achieves a faster delivery of the frames (at least theoretically compared to maintaining multiple MAC tables as would have to be done in the absence of VLANs). These tags are added on the way out of a trunk link and removed at the other end. When a VLAN-aware router or computer receives a tagged frame, it examines the tag to determine to which virtual interface the frame belongs and removes the tag. They are not broadcast. The VLAN tag is never included in a packet sent to a non-vlan device. Part of the function of a VLAN capable device is to add or remove VLAN tags as required, usually based on the learned capability of the peer device. Trunk links usually interconnect switches. However, they may also attach end devices such as servers that have special adapter cards that participate in the multiplexing protocol. When using trunks, it is important to consider that all the VLANs carried over the trunk share the same bandwidth. If the trunk is running over a 1Gig interface, for example, the combined bandwidth of all the VLANs crossing that trunk is limited to 1Gig. As a side note, 802.1Q is defined on only 100Mbps or higher Ethernet; it does not support 10Mbps. Trunk Links, Access Ports and Hybrid Ports Access ports are also present on the network along with trunk ports. In contrast with the trunk port, an access port is defined to a single VLAN only. Access ports provide connections for non-vlan-aware devices, such as some PCs, giving them access to the VLAN environment. Frames sent on access ports do not have VLAN information attached. In the example shown in Figure 5, Switch 1 is installed at one location, and Switch 2 and the Hub are in another. The small squares are access ports, and the larger squares are trunk ports. 59

61 Figure 5. Trunk and Access Port Scenario By defining trunk ports on both switches to the VLAN and then connecting the two trunk ports, VLAN6 is a network that exists across both locations. The router is a VLAN-capable device, attached to one of the trunk ports. The router provides a path between VLAN5 and VLAN7, and between either of these networks and the Wide Area Network (WAN) signified as a cloud. This is usually done by defining a virtual network device against the physical port on the router, linking that virtual interface to the VLAN and enabling the interface for routing. VLAN6 has no access to any other VLAN, or to the WAN. Even though VLAN6 shares access to trunk ports in both switches with VLAN7, the VLAN architecture prevents traffic from flowing between the two networks. If routing to VLAN6 is required, the Switch 1 trunk port to the router could be included into VLAN6 and a virtual interface for VLAN6 defined in the router. The only machines in the entire network permitted to access the server LINUXA are those in VLAN6. This is the same reason VLAN6 cannot access the external network: there is no routing path between VLAN6 and the other VLANs. A frame generated by a device that is not VLAN-capable is called an untagged frame when it arrives at the VLAN-capable switch. The action taken by the switch in this case can vary. The 802.1Q also contains specification for hybrid ports. These ports can act both as a trunk port to handle tagged frames, and as an access port to handle untagged frames. Hybrid ports provide additional flexibility for VLAN handling and for interoperability with other tagging techniques such as Cisco ISL. Some switch vendors offer a combination of VLAN organizational techniques, i.e. port based and tagging, to be used together. For example, with one particular vendor switch, a single port can be a member of a one port-based VLAN. In this vendor-case, tags must accompany all additional VLAN membership for the port. Not all ports in the VLAN must be tagged. As traffic from a port is forwarded out of the switch, the switch determines (in real time) if each destination port should use tagged or untagged packet formats for that VLAN. The switch adds and strips tags, as required, by the port configuration for that VLAN. Clause 9 of the 802.1Q standard defines the encapsulation protocol used to multiplex VLANs over a single link, and introduces the concept of a native VLAN. Frames belonging to the native VLAN are not modified 60

62 when sent over the trunk. While switch implementations vary across vendors and models, hybrid ports are often configured on a switch to work in concert with the native or default VLAN, i.e. any frames not tagged will be assigned to the default VLAN. Native or default VLANs are also referred to as Management VLANs. (Many switches use Port 1 as the management VLAN, at least by default.) The action taken by the switch in this case can vary depending on the vendor and configuration. The switch can assign a default VLAN number to untagged frames that enter the switch, or it can tag the frames with a port-specific VLAN number (providing a function similar to a port-based VLAN). Native VLANs on both ends of a trunk must match. A native VLAN mismatch on the two ends of the trunk causes problems using the native VLAN configured on each end. Note that packets sent out from the trunk port on the native/default VLAN are untagged. For example, suppose you have an 802.1Q port with VLANs 2, 3, and 4 assigned to it. If VLAN 2 is the Native VLAN, frames on this VLAN, which are to egress this port are not given an 802.1Q header, i.e. they are plain Ethernet frames. Frames which ingress this port, and which have no 802.1Q header, are put into VLAN 2. You can (obviously) only have one Native VLAN per port. Frames over VLAN3 and 4 would be tagged accordingly: frames identified for VLAN3 (perhaps by IP subnet or protocol) would be tagged for VLAN3, and frames identified for VLAN4 would be tagged for VLAN4. A number of possibilities for proper VLAN handling result based on the particular network configuration and vendor-implementation. For example, the decision tree shown in Figure 6 is based on a particular vendor s implementation that employs both VLANs by protocol and VLAN tagging. 61

63 Figure 6. VLAN Decision Tree In this example, allopen is equivalent to the IEEE Standard 802.1Q term Shared VLAN Learning (SVL). SVL is used when it is necessary to allow address information learned in one VLAN to be shared among several VLANs. On the other hand, Independent VLAN Learning (IVL) is used ensure that address information learned in one VLAN is not shared with other VLANs. While the scope of SVL and IVL are beyond this document, in general, IVL is used to directly associate a MAC address to a VLAN and is considered more secure since data cannot be forwarded between VLANs. Test Concerns Does the DUT properly support the maximum number of VLANs per port? The ability to support both tagged and untagged frames in a test bed that includes trunk, access, and/or hybrid links. (Many test tools either do not do this, or they require manual assignment one port at a time.) A wizard technique for quickly creating frames with or without VLAN and numbering VLAN IDs within or across ports. Additional overhead caused by the switch while adding and stripping tags. Mapping between proprietary tagging methods and tagging based on 802.1Q can cause additional overhead that affects performance. All proper frame-size ranges, including 64 byte-frames that get transmitted to an access link. In this case the DUT would remove the tag reducing the size to 60, but then the DUT would likely pad the frame with 4 bytes to assure that a legal Ethernet frame size is used before the frame exits the egress port. Frame size incompatibility: may lead to the appearance of packets slightly bigger than the current IEEE 802.3/Ethernet maximum of 1,518 bytes (non-jumbo). This may affect packet error counters in other devices, and may also lead to connectivity problems if non-802.1q bridges or routers are placed in the path. A new frame check sequence (FCS) must be computed and added to the frame when the frame is changed by adding/removing the VLAN tag. Is adding and removing 802.1Q headers adding processing overhead and contributing to poor 62

64 performance? The ability to emulate multiple devices in the VLAN configuration: end nodes, edge switch ports, trunk ports, access ports, one-armed routers, metro core routers, and even entire networks. Parsing and mapping/handling of VLAN priority (see below) may contribute to performance issues. Test tools should provide a way to map IP priority and DSCP to VLAN priority to easily create traffic flows that simulate egress trunk traffic in which the switch performed the same mapping. VLAN leakage requires reporting of stray frames and capture ability to troubleshoot while the test is running. When SVL is used, the test tool should be able to support multiple MACs on ports with multiple VLANs, i.e This is because with SVL you must use different MAC addresses per-vlan. QinQ tagging, in which one or more additional VLAN tags are added to frames, also introduces translation processes in which tags may be converted in a double to double tag or double to single tag fashion. These logical examinations and operations often require additional processing and may be further complicated by quality of service processing, rate shaping, and switching that is specified by a service policy map. VLAN Tagging and QoS with 802.1P Quality of Service (QoS) and Class of Service (CoS) use one or more schemes that help improve the predictability of network performance and improve bandwidth utilization, especially during periods of congestion. Techniques for prioritizing incoming traffic include DiffServ, and Weighted Round Robin (WRR), which can also prevent head-of-line blocking (HOLB). HOLB can simplistically be described as a phenomenon in which congestion on a given port impacts performance (throughput) of other congested ports. IEEE 802.1P supplements 802.1Q by adding a technique for prioritizing network traffic at the OSI Layer 2. The 802.1P header includes a three-bit field for prioritization, which allows packets to be grouped into various traffic classes P establishes eight levels of priority similar to IP Precedence. Network adapters and switches route traffic based on the IP Precedence level. Using Layer 3 switches allows you to map 802.1P prioritization to IP Precedence before forwarding to routers. Administrators can set up the queues to match various business requirements and priority levels. Typical assignments of the 8 values for the 3-bit IP Precedence as recommended in the IEEE 802.1P standard are shown in Table

65 Table 1-1. Typical Assignments The VLAN priority is separate from IP priority mechanisms unless there is specific mapping between the two. Without this mapping, VLAN priority is used to prioritize the frames of a VLAN relative to other VLANs, while IP prioritization operates within the IP layers of routers. While most vendors today agree that 802.1P is the mechanism to tag frames for prioritization, there is no single uniform approach to implementing the underlying queuing mechanisms that actually implement the priority flows. Furthermore, it is possible that two switches with the same number of traffic queues could actually forward traffic marked with the same priority level (say Level 3) with differing internal priorities. The 802.1P standard also offers provisions to filter multicast traffic to ensure it does not proliferate over Layer 2-switched networks. Testing The tests described in this section focus on VLAN testing using 802.1Q tags. These tests can be easily adapted to other VLAN organizational methods such as MAC-based VLANs, for which information is provided in tech tips and the Additional Test scenarios section for each of the tests. The tests are typically run over 100M, 1Gig or 10Gig interfaces. Tip: DUT Configuration Tips Disable trunking and trunk negotiation on all ports except those absolutely necessary. Enable MAC flood protection on all ports. Isolate the management VLAN from workstations and servers. Set ports to full-duplex mode. 64

66 Refer to these sections for detailed information on the tests described in this document. Test 1- Functional Single VLAN Test - Layer 2 After you have planned and configured your initial network design, the first order is business is likely functional testing. This test assures that a single VLAN-tagged stream is successfully transmitted and received through a VLAN-aware DUT. Test 2 - Functional - Multiple VLANs Test - Layer2 This test assures that multiple VLAN-tagged streams are successfully transmitted and received through a VLAN-aware DUT. Test 3 - Routing with VLANs: Throughput Test over Trunk Link This methodology verifies the DUT functions properly when receiving and forwarding VLAN-tagged traffic over trunk links. The test measures the performance of the DUT when handling large numbers of VLANs from an emulated switch, router or server. The test is first run with 2 port pairs, and then can be scaled to include dozens or even hundreds of ports. Test 4 - Routing with VLANs: QoS/MultiLayer Frame Loss Test This methodology verifies the DUT functions properly when receiving non-tagged frames over an access link, and subsequently tags the frames before forwarding them out a trunk link. The test measures DUT performance when handling traffic from a large number of emulated hosts on adjacent network interfaces. 65

67 Functional Single VLAN Test Associated Standards IEEE Std Q-2003: sub clause 5.1 IEEE Std Q-2003: Annex D Objective A Virtual Local Area Network (VLAN) tagged stream will be transmitted from test Port 1 to test Port 2. The test will demonstrate the finite control and analysis of a single VLAN tagged traffic stream through the Device Under Test (DUT), and the DUT s VLAN tagged forwarding ability. The tagged traffic should be received through the DUT with no packet loss and with an acceptable result for a variety of metrics, including receive and latency rates. Overview Assure that a single VLAN tagged stream is successfully transmitted and received through the DUT. Setup 66

68 Step-by-Step 1. Launch Spirent TestCenter and reserve the required ports. 67

69 2. Select Hosts under the first reserved port. 3. Select the Add button to launch the host configuration window. 68

70 4. Select both ports and then click Next. 69

71 5. The defaults are okay, press Next. 70

72 6. Enable VLANs by selecting the Number of VLAN Headers check box. The default value of 1 is okay. Press Next to continue. 71

73 7. Configure the correct VLAN ID and the required stepping. The Step will increase the VLAN ID by the set amount across the selected ports. 8. Configure the IPv4 address. The IPv4 Gateway should automatically be configured based on the Prefix length. Select the button to configure the Step per port. 72

74 9. Change the Step per port and the Step per VLAN as required. 10. Click Next to preview how the ports will be configured. If any changes are needed, make them at this time. 73

75 11. Make sure the configuration is correct. If changes need to be made, go back and make them as required. Press Finish when completed. 12. Select the Traffic Generator option under the first port. 74

76 13. Use the Add drop down menu and select Add Bound Stream Block(s). 14. Make sure both ports are selected and then press Next. 75

77 15. Select the first host as the source and the second host as the destination. Press Add to add the pairing. 16. Make sure the pairing has been added and then press Next. 76

78 17. The defaults are okay, press Next. 77

79 18. Increase the Load from 10% to 100%. Press Finish once completed. 19. Right-click on the stream that was just created and select Edit. 78

80 20. Select the Frame tab and the under the Frames section choose Create new Frame Create new Frame. 79

81 21. Choose Ethernet II and select VLANs. For the Upper Layer Protocols select IPv4. Press OK once finished. 80

82 22. Select Expand All and then change the value of the VLAN ID. 23. Next right-click on Destination MAC and choose Insert MAC Modifier. 81

83 24. Change the count to 100 and change the Step if desired. Once completed press OK. 82

84 25. Press OK to finalize the edited stream. 26. Before traffic can be transmitted, ARPs must be sent. Right-click on All Hosts and select ARP/ND Start ARP/ND On All Hosts. 83

85 27. Verify all ARPs were successful. A message should appear in the lower left of the screen saying they were resolved successfully. If an ARP fails, troubleshoot the problem before continuing. 28. Now it is possible to start transmitting traffic. Select the button on the top of the screen. This will start all the traffic streams that are currently present. 84

86 29. Make sure the Results Browser is set to Stream Results Detailed Stream Results and Port Traffic Basic Traffic Results. 30. If Results Browser is not on the correct view, use the Change Result View drop down menu to select the correct views. 85

87 31. Using the Stream Results Detailed Stream Results view, verify traffic is being transmitted and received. 32. It is also possible to verify that traffic is being transmitted and received using the Port Traffic Basic Traffic Results view. 86

88 Functional Multiple VLANs Test Associated Standards IEEE Std Q-2003: sub-clause 5.1 IEEE Std Q-2003: Annex D Objective This test assures that multiple Virtual Local Area Network (VLAN) tagged streams that cover the entire legal VLAN range are successfully transmitted and received through the Device Under Test (DUT) from a single transmit port. The test will also reveal if key forwarding performance metrics such as throughput, latency and packet loss are affected by the number of VLANs. When expanded to include more than 2 ports the test will easily show if VLAN leakage, in which traffic received on the wrong port, is occurring. It also will show whether the DUT favors any VLAN (or port) as contention occurs. The tagged traffic should be received through the DUT with no packet loss and with an acceptable result for a variety of metrics. Overview The 802.1Q standard specifies a VLAN range of up to 4095 VLAN IDS on a single port. Some DUTs are not able to scale to this range even on a small number of ports. Furthermore, network traffic performance can easily be compromised by the additional overhead imposed by VLAN tags and their corresponding look up tables. Setup 87

89 Step-by-Step 1. Launch Spirent TestCenter and reserve the required ports. 88

90 2. Select Hosts under the first reserved port. 3. Select the Add button to launch the host configuration window. 89

91 4. Select both ports and then click Next. 90

92 5. The defaults are okay, press Next. 91

93 6. Enable VLANs by selecting the Number of VLAN Headers check box. The default value of 1 is okay. Press Next to continue. 92

94 7. Change the number of VLANs per port to 350. Configure the correct VLAN ID and the required stepping. The Step will increase the VLAN ID by the set amount across the selected ports. Select the Repeat mode that best fits the DUT s configuration. 93

95 8. Configure the IPv4 address. The IPv4 Gateway should automatically be configured based on the Prefix length. Select the button to configure the Step per port. 94

96 9. Change the Step per port and the Step per VLAN as required. 10. Click Next to preview how the ports will be configured. If any changes need to be made, please do so at this time. 95

97 11. Make sure the configuration is correct. If changes need to be made, go back and make them as required. Once completed press Finish. 12. Select the Traffic Generator option under the first port. 96

98 13. Use the Add drop down menu and select Add Bound Stream Block(s). 14. Make sure both ports are selected and then press Next. 97

99 15. Select all the hosts under the first reserved port as the source and all the hosts under the second port as the Destination. Once the source and Destination are selected press the Add button. 16. Make sure the pairings has been added and then press Next. 98

100 17. The defaults are okay, press Next. 99

101 18. Increase the Load from 10% to 100%. Press Finish once completed. 19. Before traffic can be transmitted, ARPs must be sent. Right-click on All Hosts and select ARP/ND Start ARP/ND On All Hosts. 100

102 20. Verify all ARPs were successful. A message should appear in the lower left of the screen saying they were resolved successfully. If an ARP fails, troubleshoot the problem before continuing. 21. Now it is possible to start transmitting traffic. Select the button on the top of the screen. This will start all the traffic streams that are currently present. 101

103 22. Make sure the Results Browser is set to Stream Results Detailed Stream Results and Port Traffic Basic Traffic Results 23. If Results Browser is not on the correct view use the Change Result View drop down menu to select the correct views. 102

104 24. Using the Stream Results Detailed Stream Results view, verify traffic is being transmitted and received. Not all streams are viewable on a single page. Use the navigation arrows at the top right of the Results Browser to navigate to the remainder of the streams. 25. It is also possible to verify traffic is being transmitted and received using the Port Traffic Basic Traffic Results view. 26. Additional tests should also be run to test other aspects and functionality of the DUT. If time permits, try to run the following test examples. Increase the number of VLANs to determine how the DUT handles even larger amounts of VLANs. RFC 2544 testing performed with VLANs enabled. Set illegal VLAN and frame values to perform negative what-if testing on the DUT, and for interoperability concerns. Add additional VLAN tags for QinQ to emulate traffic between the service provider network and the metro/edge. 103

105 Routing with VLANs: Throughput Test over Trunk Link Associated Standards IEEE Std Q-2003: sub clause 5.1 IEEE Std Q-2003: Annex D Objective Spirent TestCenter will emulate a switch, router, or server on the network that transmits tagged frames to the Device Under Test (DUT). This test reports the zero-loss throughput of the DUT and validates the DUT properly forwards tagged frames over a trunk link in a Virtual Local Area Network (VLAN) aware device when hundreds of VLANs are being used. The trunk link is assumed to be connected to a router over which VLANtagged traffic is sent intra-vlan. Resulting performance impact will be measured and can easily be compared to previously obtained baseline results on non-vlan tagged traffic, and non-routed VLAN traffic. If there is VLAN leakage, whereby ports are receiving traffic on the wrong VLAN, then stray frames will be reported. Overview Tagged frames are forwarded over the network by a VLAN aware device and its egress port. Another VLAN aware device should be able to accept tagged frames over its ingress trunk link (port) and forward the frames over its egress trunk link (port). The test tool assists in trunk link testing by emulating VLAN tagged traffic from one VLAN aware device. This traffic is sent to the DUT and received on another test port for analysis of proper handling by the DUT. When VLAN enabled traffic is received on a test port connected to a DUT trunk port, the traffic should remain tagged accordingly. Communication between VLANs is provided by Layer 3 routing. Trunk links connected to a router allow users of each and every VLAN to communicate with each other, and present a challenging mix of traffic to the DUT. When a router is thrown in the mix, multiple facets of the DUT are tested. While this may be corner-case, since VLANs are used to segregate traffic, there are situations when VLAN users need to communicate with one another. The throughput will be reported globally for each frame size and group of transmit ports. Each sub-interface on Port 2 should receive traffic from each sub-interface on Port 1. Each sub-interface on Port 4 should receive traffic from each sub-interface Port 3. Any misdirected traffic will be shown as stray frames. RFC 2544 performance metrics should not be directly compared with metrics of non-vlan tagged traffic. Setup 104

106 Step-by-Step 1. Launch Spirent TestCenter and reserve the required ports. 105

107 2. Select the first port and if needed, configure the Media Type, Port Speed and Duplex. Repeat for the other three ports. 3. Select the Wizards button. 4. Next select Test Wizards Rfc 2544 Throughput and then press the Next button. 106

108 5. Select all the ports by using the Select All button. Once done press Next. 6. Select the first reserved port as a Source and the second reserved port as the Destination and then press Add. Do the same for the remaining two ports. Once finished select Addressing. 107

109 7. As VLANs are going to be used, check the Enable VLAN box. Next, under the Port Configuration section configure the correct IPv4 Address, IPv4 Gateway Address and the Vlan Id. Next, configure the correct Step for each one. Change the Host Count to 20, and configure the correct stepping and correct Mask. Once completed select IP Header. 108

110 8. Use the drop down menu to select TCP and then press Add. Once completed press Next. 109

111 9. Change the Rate lower limit to 10 and change the Initial Rate to 90. All the other parameters are okay, press Next to continue. It is now possible to perform a trial run of the test using a single frame size. 110

112 10. Select LIFO as the Latency Type and choose Learn every frame size for the Frequency. Once completed press Run. This will start running the test. 11. If a pop-up window appears asking a question about the Results Report Integration, select the Yes button. 111

113 12. Spirent TestCenter Result Reporter will open and be similar to the below screen shot. 13. Even though Spirent TestCenter Result Reporter can be viewed, it is still possible to view results in the Results Browser of Spirent TestCenter. 112

114 14. The test will take a while to complete. But while the test is running it is possible to view results for already completed iterations. To view some of the results expand the Rfc2544 Throughput Test Result Summary View menu item, next expand the Trial item. A list of frame sizes should be viewable. Select the frame size you wish to view results of and expand it. This will provide a listing of the Loads performed; select one of them to view the results of the iteration. 15. Once selected, a great deal of information is now available for viewing. The results will show some of the information that is already known and a great deal of information which is not known. The important values to view are the Forwarding Rate (fps), the Minimum Latency and Maximum Latency. 113

115 16. Once the binary search has found a throughput rate for each frame size, an RFC 2889 Summary iteration is shown with the results (per the RFC). Select the Rfc2544 Throughput Test Result Detailed Summary View. This listing will provide you with all the same information as just a single iteration view. 17. Select the 2544-Tput-Summary option in the results section. Next use the drop down menu and select Rfc2544ThroughputStats. 114

116 18. Select the Test Summary Tab and this will show a chart that compares the Throughput by Frame Size to the Theoretical Max. As you can tell, the DUT used in this test performed very well. 19. Next, select the Trial Summary tab. This will show the Throughput of each Frame Size as a percentage and as Frames Per Second (fps). 115

117 20. It is also possible to save the results. Select the results item in the tool bar and select one of the two options, PDF or HTML. 21. Additional tests should also be run to test other aspects of the DUT. If time permits try to run the following test examples. Expand the test to include multiple ports (and VLANs) to completely exercise the switching fabric of the DUT. Trunk link performance can easily be compared to trunk-to-link performance by connecting the receive test port to an access link on the DUT. The test configuration could easily be re-used, and the test re-run. Changes in performance should be noticed due to the additional processing time required for the DUT to strip the VLAN-tag before traffic is sent to the access port. Use RFC 2544 to run VLAN by port, by MAC or by network test by omitting the VLAN tags, and organizing the test traffic as per the DUT configuration. A routing protocol peering session (e.g. BGP, OSPF, IS-IS or RIP can be defined on each VLAN and the routes reachability can be advertised before or during test execution. 116

118 RFC 2544 Table of Contents Introduction 118 Directing Traffic in the Network 118 Assuredness and Interoperability Using Industry Standards 118 RFC 2544/1242 Concepts and Terminology 119 The Test Methodologies Throughput

119 Directing Traffic in the Network Introduction Layer 3 switches, also called routers, determine the next network point to which a packet should be forwarded toward its destination. The router is connected to at least two networks and decides which way to send each information packet based on its current understanding of the networks. In contrast to Layer 2 switches, routing is associated with the Network Layer (Layer 3) in the standard model of network programming, the Open Systems Interconnection (OSI) model. A router may create or maintain a table of available routes and their conditions and use this information along with distance and cost algorithms to determine the best route for a packet. Typically, a packet may travel through many network points with routers before arriving at its destination. Assuredness and Interoperability Using Industry Standards Layer 3 switch manufacturers are not always sure how to test according to the well-established methodologies. By understanding the techniques to test, network equipment manufacturers increase their success rate with in-house tools for development testing and quality assurance. They also need third-party tools such as Spirent TestCenter for unbiased, hard results of switch performance. Once assured of an acceptable level of performance and scalability, manufacturers make their equipment available to their customers: service providers and business customers, also referred to as enterprises. To justify their equipment choices and have the best network services possible, service providers and enterprises need to test per accepted standards before purchasing decisions are made. After deployment into live networks, existing equipment can be re-tested in lab environments using the Spirent TestCenter RFC-based test tools. By performing regression testing, users can compare baseline test results with results after equipment is updated with new versions of switch firmware. One of the first steps to quantify the performance of the Layer 3 switch is to follow industry standards. RFC 2544 (Benchmarking Methodology for Network Interconnect Devices) is for Layer 3 switch testing. With its companion, RFC 1242 (Benchmarking Terminology for Network Interconnect Devices), the RFCs together define reliable, repeatable methods for evaluation of Layer 3 switch performance using 10/100/1000 Mbps and 10 Gig Ethernet. Specific tests are: Throughput Latency Frame Loss Rate Back-to-Back System Recovery Reset These are described in RFC 2544 and provide the tester peace of mind. These tests provide a baseline specifically according to the RFC and reveal the effects of newer technologies as they are incrementally introduced. Both RFC 2544 and this document refer to terms defined in RFC 1242, Benchmarking Terminology for Network Interconnection Devices. Please refer directly to these documents as needed. 118

120 RFC 2544/1242 Concepts and Terminology This section provides an overview of RFC 2544 and RFC 1242 concepts and terminology that are commonly used throughout the benchmark test. Device Under Test (DUT) The DUT is the network interconnect device being tested. This is typically a device that forwards traffic based on the addresses contained in the Layer 3 header, such as a gateway, router or Layer 3 switch. The actual physical configuration of the DUT could be a single chassis with one or more blades or multiple chassis with multiple blades interconnected in some way. Regardless of the physical configuration, these tests view the DUT as a single unit with multiple ports. Test results are aggregated over all ports. Topologies A test port generates traffic that simulates one or more sources. The simulated source may be on the same physical network as the DUT port (as in test Ports 3 and 4 in the diagram below) in which case direct delivery is be used. Test ports may also simulate traffic that originated on a different physical network than the DUT port, so the test port simulates a network interconnect device (such as a gateway) that forwarded the message (as test Ports 1 and 2 in the diagram below). In the second case, the DUT will require routing table entries to implement indirect delivery. RFC 2544 recommends the DUT immediately learn these routes using a routing protocol enabled on the DUT. This should be done prior to testing. RFC 2544 also recommends using the IP address pool through , which have been assigned to the benchmark working group by the IANA. It has further instructions for assigning DUT port addresses and simulated router addresses on test ports. Please refer to RFC 2544, Appendix C, for a discussion of IP address assignments. Another recommendation from RFC 2544 is that tests be run with a single stream of traffic (single Layer 3 source and single Layer 3 destination) and then repeated using Layer 3 destination addresses randomly chosen from a pool. This is reasonable for exercising the DUT s route lookup engine. In the diagram below, a four-port DUT is connected to four test ports. IP addresses assigned are from the RFC 2544 recommended pool of IP addresses, with DUT ports using host number 1 and simulated routers using host number

121 Traffic Pattern RFC 2544 indicates that the ports on the DUT are to be divided into 2 groups, one referred to as the input port(s) and the other referred to as the output port(s). In the diagram above, DUT Ports 1 and 2 have been designated input Ports and Ports 3 and 4 have been designated output ports. RFC 2544 Traffic has the following characteristics: For unidirectional traffic, the source and destination addresses in each test frame should result in frames being routed in an even distribution from each input port to each output port, and vice versa. This is known as a unidirectional partial mesh. For bi-directional traffic, each port is considered a member of both the input and output groups of ports, so frames from each port are routed in an even distribution to all other ports. This is known as a bi-directional full mesh. The test frames should be routed to the same output port in the same order. For example, the first test frame arriving at all input ports should all be routed to the first output port, the second test frame arriving at all input ports should be routed to the second output port and so on. This ensures the DUT can simultaneously handle multiple frames routed to the same port. If a DUT blade has multiple ports, the ports should be evenly distributed between the input and output groups. Frame Sizes Each test should be repeated over a range of frame sizes. Guidelines for choosing a set of frame sizes from RFC 2544 are: At least 5 frame sizes should be used for each test. The sizes should include the maximum and minimum legitimate sizes for the protocol under test on the media under test and enough sizes in between to obtain a full characterization of DUT performance. Recommended Ethernet frame sizes: 64, 128, 256, 512, 1024, 1280 and 1518 bytes. Trial Duration The duration of each trial should be long enough that it reflects the DUT behavior under continuous traffic. RFC 2544 indicates a 60-second minimum. Modifiers RFC 2544 identifies four modifiers to the benchmark tests. Each modifier describes a condition likely to exist in real world traffic. Each benchmark test defined in RFC 2544 should be run without any modifiers and then repeated under each condition separately. The modifiers listed are the following: Broadcast Frames Management Frames Routing Update Frames Traffic Filters Network traffic from a modifier should be evenly mixed with test traffic and not supplied to the DUT through a separate port. The following is a brief description of the four modifiers listed above. See RFC 2544, Section 1, for more details. Broadcast Frames Augment the test frames with 1 percent frames addressed to the hardware broadcast address. The broadcast frames should be of a type the DUT will not need to process internally. 120

122 Management Frames Augment the test frames with 1 management query at the beginning of each second of test traffic (such as an SNMP GET for one or more of the MIB-II objects: sysuptime, ifinoctets, ifoutoctets, ifinucastpkts and ifoutucastpkts). The result of the query should fit into a single response frame and should be verified by the test equipment. Routing Update Frames Augment the test with routing update frames that will change the routing table in the DUT for routes that will not affect the forwarding of test traffic. A routing update is sent as the first frame of each trial. RFC 2544 recommends sending routing update frames every 30 seconds for RIP and each 90 seconds for OSPF. The test should ensure the DUT processes the routing updates. Filters The following should be defined on the DUT. Separate tests should be run for each of the following two filter conditions: Define a single filter on the DUT that permits the forwarding of the test traffic. This tests basic filter functionality. Define 25 filters on the DUT. The first 24 filters block traffic that will not occur in the test traffic. The last filter permits the forwarding of test traffic. This ensures filters not participating in the forwarding test traffic do not negatively impact performance. The Step-by-Step methodologies in this section are just a small sample of all the RFC 2544 tests. Please contact your local representative for the remainder of the RFC 2544 tests. 121

123 Throughput Associated RFCs RFC 1242: Benchmarking Terminology for Network Interconnection Devices RFC 2544: Section 26.1 Objective The objective of the throughput test is to determine the throughput of the DUT. Throughput is defined in RFC 1242 as the maximum rate at which none of the offered frames are dropped by the device. Overview The throughput test determines how well suited a device is to applications in which minimal frame loss is critical. Some applications, such as voice over IP or video conferencing require minimal frame loss to be useable. Other applications may be more tolerant of frame loss, although loss of a single frame may cause response time to suffer while the upper layer protocols recover from timeouts. With each trial of the throughput test, test frames are sent at a specific frame rate and the number of frames forwarded by the DUT is counted. If there is any frame loss, the rate is decreased; otherwise, the rate is increased. The trials are repeated until the maximum rate is found at which there is no frame loss. RFC 2544 does not specify an algorithm to implement, however the most common approach is a binary search algorithm. With the binary search algorithm, the first trial uses a configured initial frame rate (or percent utilization). If there is frame loss with a specific trial, the next trial uses a rate calculated as the midpoint between the current rate and a configured minimum; otherwise, the next trial uses a rate calculated as the midpoint between the current rate and a configured maximum. The test is stopped when the difference between the frame rate of the current trial and previous trial is less than or equal to a configured delta. Setup In this test example we will use a 4-port DUT. Traffic will be sent into the DUT by the Spirent TestCenter equipment simulating a Fully Meshed traffic pattern. Step 6 below allows the user to select various traffic patterns such as Partial Mesh, Many-to-One, One-to-One, as well as traffic can be Unidirectional or Bidirectional. Testing the throughput of the device in several different scenarios is encouraged. For example, all ports within a line card, across line cards, etc., which will verify various parts of the switch fabric. Make sure the DUT is a Layer 3 device. If desired, enable VLANs on the DUT ports. (This test will not use VLANs, but the test wizards allow the test to be conducted with them.) 122

124 Make any modifications to the DUT required to enable traffic to pass. No modifications are allowed that would tune the DUT to the test (for example, reallocating resources to minimize frame loss at the expense of increased latency). (Optional.to be done before the Test Steps section below). Advertise any routes required by the DUT to allow it to forward test traffic using a routing protocol. Pause several seconds to allow the routes to update. If all of the destinations reside on physical networks connected to the DUT or if the DUT has static routes defined, this step may be skipped. Spirent TestCenter has the unique capability to inject routes using any routing protocol and then run RFC 2544 tests on top of them. It is recommended that you maintain a console connection to the DUT (if applicable) this is very useful for checking statistics and debugging any problems. 123

125 Step-by-Step 1. Launch the Spirent TestCenter application and reserve 4 ports. 2. Click on the Wizards icon in the upper right portion of the Spirent TestCenter GUI. 124

126 3. Once in the Wizard, expand Test Wizards and then expand Rfc2544. Select the Throughput test option. Read the test methodology that is provided to better understand the test methodology, the configurable parameters, and the expected outcome of the test. Then click the Next button. Note: Navigating the Wizard is quite simple using the Back and Next buttons. You can also save/load your Wizard configuration using the File button. If you would like to return your Wizard settings back to their factory defaults, select the Default button. After each successful run of the test Wizard, the same configuration parameters will be saved/used in the next Wizard run (until the DEFAULT button is pressed again). 125

127 4. Select the required ports using either the Select All button or by selecting them individually. Press Next once completed. 126

128 5. Select the Fully meshed Distribution option and select each port as an Endpoint. Next, select the Addressing option under Traffic Descriptors section. 127

129 6. Change the Start and Stepping for the IPv4 Address and IPv4 Gateway Address. Select the IP Header option under the Traffic Descriptors section. Test Port IP DUT Port IP Port 1: / /24 Port 2: / /24 Port 3: / /24 Port 4: / /24 Other useful parameters on this screen: (See Help (F1) for additional information) Enable IPv6 headers, or BOTH IPv4 and IPv6. If both are enabled, an even amount of IPv4 and IPv6 traffic will be generated/used in the test. Enable VLANs to be used in the addressing of the Endpoints. Increase the number of hosts per port, and configure the MAC and IP addresses. 128

130 7. Use the drop down menu to select the IP next protocol variation. The default of UDP is perfectly fine to use, though it is not required to use one. Once selected, press the Add button. Finally, press Next. 129

131 8. From the Test Parameters screen, use the (default) Custom frame sizes (per the RFC). In the Load Section a search algorithm will be used to find the Throughput of the device. Leave the binary option selected for this. A search should be used if you do not know the capabilities of the DUT. Also, note the ability to set the Pass/Fail criteria shown as the Acceptable Frame Loss %. This allows a user-defined amount of loss to happen and still pass the iteration. The RFC states that for an iteration to pass it must have zero loss. For this particular DUT, we will use 1% acceptable loss, as the DUT regularly loses at least a few packets on every test run. Other useful parameters on this screen (See Help (F1) for additional information) Number of trials This will run the entire test multiple times if more than 1 is selected. This may be useful to determine if errors seen on a given test run repeat themselves 2-n times. Duration The RFC recommends 60 seconds per iteration. Optionally, you can choose to send X number of packets by selecting the Bursts option. Throughput Thresholds Additional Pass/Fail criteria. They work the same as the Acceptable Frame Loss % field. If any iteration exceeds the configured value, the iteration will fail and the binary search algorithm will reduce its rate/load accordingly. 130

132 9. In the Options Screen, select FIFO Latency type, and then select the Run button. Selecting the Run button will start the test right away. Other useful parameters on this screen (See Help (F1) for additional information) a. Options: i. Delay after transmission waiting for the DUT to forward all frames. ii. Traffic Start Delay a fixed time (after learning) to allow the DUT to process learning frames. iii. Offered load See Online help (F1) for a good description. b. Latency types: See Online help (F1) for a good description. i. recommends using the FIFO option in most cases to test in accordance with RFC When comparing against other platforms, use the LILO (default) option. LILO was typically used in measuring latency. 131

133 10. If a pop-up window appears asking a question about the Results Report Integration, select the Yes button. 132

134 11. Eventually, Spirent TestCenter Result Reporter will open and be similar to the below screen shot. 12. Even though Spirent TestCenter Result Reporter is able to be view, it is still possible to view results in the Results Browser of Spirent TestCenter. 133

135 13. The test will take a while to complete. But, while the test is running it is possible to view results for already completed iterations. To view some of the results expand the Rfc2544 Throughput Test Result Summary View menu item, next expand the Trial item. A list of frame sizes should be viewable, select the frame size you wish to view results of and expand it. This will provide a listing of the Loads performed; select one of them to view the results of the iteration. 14. Once selected, a great deal of information is now available for viewing. The results will show some of the information that is already known, though it also provides a great deal of information which is not known. The important values to view are the Forwarding Rate (fps), the Minimum Latency and Maximum Latency. 15. Once the binary search has found a Throughput rate for each frame size, an RFC 2889 Summary iteration is shown with the results (per the RFC). Select the Rfc2544 Throughput Test Result Detailed Summary View. This listing will provide you with all the same information as just a single iteration view. 134

136 16. Select the 2544-Tput-Summary option in the results section. Next use the drop down menu and select Rfc2544ThroughputStats. 17. Select the Test Summary Tab and this will show a chart that compares the Throughput by Frame Size to the Theoretical Max. As you can tell, the DUT used in this test performed very well. 18. Next, select the Trial Summary tab. This will show the Throughput of each Frame Size as a percentage and as Frames Per Second (fps). 135

137 19. It is also possible to save the results. Select the results item in the tool bar and select one of the two options, PDF or HTML. 20. If you need to troubleshoot any of the results, viewing the more detailed results of the Rfc2544ThroughputStats or viewing the individual iteration will be more beneficial to solving the issue. These results (especially the ones with lost packets) will help identify where the switch fabric may have fallen short in its deliverance of the packets or its deliverance of the packets in a timely manner. While this Full-Mesh test will help show where the main areas of the switch fabric that may have broken down, the detailed results may show other areas of the switch that need to be tested further using the one-to-many, many-to-one, or Unidirectional traffic, possibly using all ports within a DUT line card, or just a port pair. 21. Other RFC 2544 tests are available by contacting your local representative for the remainder of the RFC 2544 tests. The remainder of the RFC2544 tests include: Frame Loss Back-to-Back Frames Latency 136

138 RFC 2889 Table of Contents Introduction 138 RFC 2889: The Basis for Layer 2 Testing 138 Standards Promote Assuredness and Interoperability 138 The Test Methodologies Throughput, Frame Loss, and Forwarding Rates in a Full Mesh

139 RFC 2889: The Basis for Layer 2 Testing Introduction The Layer 2 Ethernet switch is one of the most common networking devices. Layer 2 switching is associated with the Data Link Layer (Layer 2) of the standard of network programming, the Open Systems Interconnection (OSI) model. Layer 2 Ethernet switches forward traffic, also called network frames, across various network segments. Forwarding is based on information in the frame s Ethernet header. Layer 2 switches are simple compared with sophisticated switches and routers operating at Layer 3 and higher. But even Layer 3+ switches usually have a Layer 2 mode. In fact, it is often preferable to assure that switches and networks operate at lower layers before testing at upper layers of the OSI stack. By testing at Layer 2 before Layer 3, network equipment manufacturers increase their success rate in development testing and quality assurance while using in-house tools. However, Network Equipment Manufacturers (NEM) also need third-party tools such as Spirent TestCenter for unbiased, hard results of switch performance. Once assured of an acceptable level of performance and scalability, NEMs market their equipment to service providers and enterprises. To justify equipment choices and offer the highest quality services, service providers and enterprises should test according to accepted standards. After the equipment is deployed in live networks, existing equipment can be retested in the lab using the same RFC-based test tools. Regression testing allows users to compare baseline results with results obtained after the equipment or switch is updated with the latest firmware. Standards Promote Assuredness and Interoperability NEMs, service providers and enterprises should quantify the performance of the Layer 2 switch by following industry standards. RFC 2889 (Benchmarking Methodology for LAN Switching Devices) is for local area switch testing. With its companion, RFC 2285 (Benchmarking Terminology for LAN Switching Devices), the RFCs together define reliable, repeatable methods for evaluating Layer 2 switch performance in 10/100/1000 Mbps and 10Gig Ethernet. The following tests are mandatory per RFC 2889: Forwarding Rate Broadcast Handling Head-of-Line Blocking Illegal Frame Handling Backbone Switching The tester must introduce simulated network traffic to the Layer 2 switch and take measurements on ports that receive traffic. Port patterns such as full mesh and partial mesh (backbone) are specified, along with different frame sizes and traffic loads. Spirent TestCenter easily creates these traffic prescriptions and provide intuitive, meaningful results for accurate and timely reporting. The Step-by-Step methodologies in this section are just a small sample of all the RFC 2889 tests. Please contact your local representative for the remainder of the RFC 2889 tests. 138

140 Throughput, Frame Loss, and Forwarding Rates in a Full Mesh Associated RFCs RFC 1242: Benchmarking Terminology for Network Interconnection Devices RFC 2285: Benchmarking Terminology for LAN Switching Devices RFC 2289: Benchmarking Methodology for LAN Switching Devices Objective Determines the Throughput, frame loss, and forwarding rates of the DUT as offered by the fully meshed, one-to-many, many-to-one, or one-to-one traffic as defined in RFC Overview This test will determine if the Layer 2 (L2) switch can handle various traffic patterns at various traffic loads. The Spirent TestCenter RFC 2889 Test Wizard called Forwarding can run the first 4 tests as outlined in RFC Each of these tests basically give the same test results, however they offer different traffic patterns to stress the Switch Fabric of the DUT in various ways. The first four RFC 2889 tests including in the Forwarding Wizard are: RFC 2889 Section Fully meshed throughput, frame loss and forwarding rates This test uses a fully meshed traffic pattern to thoroughly stress the DUTs switch fabric, fully exercises the forwarding tables and reveals weaknesses in resource allocation mechanisms RFC 2889 Section Partially meshed one-to-many/many-to-one A one-to-many and/or many-to-one traffic pattern can stress the switches ability to aggregate smaller links into bigger links (and vice-versa). RFC 2889 Section Partially meshed multiple devices A partial mesh traffic pattern with multiple DUTs will determines the switch(es) ability to interoperate with other switches using multiple traffic patterns RFC 2889 Section Partially meshed unidirectional traffic Unidirectional traffic will help determine if the switch has any issues with one-way traffic. This test is also useful when doing link aggregation. These tests are more stressful and exacting than a simple forwarding rate test, which does not penalize a switch that drops an occasional packet at all offered loads. These tests measures the DUT/SUT s forwarding rate and throughput on each of the recommended RFC 2889 frames sizes. 139

141 Setup In this test example we will use a 4-port DUT sending in a Fully Meshed traffic pattern as defined in Section 5.1 of RFC Sections 5.2, 5.3, and 5.4 of RFC 2889 should be run separately. Step 5 below allows the user to select all four traffic patterns defined in Section of RFC 2889 to be run. Make sure the DUT is a Layer 2 switch, or is in Layer 2 Switch mode. If desired, enable VLANs on the ports of switch. (This test will not use VLANs, but the test wizards allow the test to be conducted with them.) Note: it is recommended that you maintain a console connection to the switch (if applicable) this is very useful for checking statistics and debugging any problems. 140

142 Step-by-Step 1. Make sure the DUT is configured as a flat Layer 2 switch. No routing or IP addresses should be assigned to any of the DUT s interfaces. 2. Launch the Spirent TestCenter application and reserve 4 ports. 3. Click on the Wizards icon in the upper right portion of the Spirent TestCenter GUI. 141

143 4. Once in the Wizard, expand Test Wizards and then expand Rfc2889. Select the Forwarding test option. Read the test methodology that is provided to better understand the test methodology, the configurable parameters, and the expected outcome of the test. Then click the Next button. Note: Navigating the Wizard is quite simple using the Back and Next buttons. You can also save/load your Wizard configuration using the File button. If you would like to return your Wizard settings back to their factory defaults, select the Default button. After each successful run of the test wizard, the same configuration parameters will be saved/used in the next Wizard run. 142

144 5. From the Port screen, use the Select All button to select all the required ports. Then click the Next button. 143

145 6. First select Fully meshed as the Distribution method and check-mark the four ports. Next, select Addressing under the Traffic Descriptors section. Other useful parameters on this screen: (See Help (F1) for additional information) a. Backbone and Pair traffic patterns. These alternate patterns are used to run tests covered in Sections 5.2, 5.3, and 5.4 of RFC 2889 as explained in the Overview section above. These patterns also allow traffic to be sent unidirectionally or bidirectionally. b. Use addresses in Card Setup/SUT address If you pre-configured MAC/IP addresses from the Port Setup/IP setup screens in the main Spirent TestCenter GUI, check these boxes so the wizard will not over-write them. 144

146 7. Disable (uncheck) the Enable IPv4 check box and then select Eth/IP Header in the Traffic Descriptors section. Other useful parameters on this screen: (See Help (F1) for additional information) a. Enable IPv4/IPv6/VLANs headers (Optional) If you would like to enable an IPv4 or an IPv6 header on top of the MAC header. b. Host Count Increase the number of hosts per port. Also, allows for the configuration of MAC Addresses, IPv4 and IPv6 address and VLANs, depending on if they are enabled or not. Note: To use both IPv4 and IPv6 frames in the test, simply re-run the RFC wizard again selecting No to not delete your existing configuration (which is after the FINISH button). 145

147 8. Change the Ether Type of X.75 Internet and press the Next button. 146

148 9. In the Test Parameters screen make sure that the Custom Frame size option is select. This should display the frame sizes that should be tested (per the RFC). In the Load Section a search algorithm will be used to find the Throughput of the device, leave the binary option selected for this, and a search should be used if you do not know the capability of the DUT. Also, note the ability to set the Pass/Fail criteria shown as Acceptable Frame Loss %. This allows a user-defined amount of loss to happen and still pass the iteration. The RFC says that for an iteration to pass it must have zero loss. For this particular DUT we will use 1% acceptable loss. Press the Next button once completed. Other useful parameters on this screen (See Help (F1) for additional information) Number of Trials This will run the entire test multiple times if more than 1 is selected. This may be useful to determine if the errors seen on a given test run repeat themselves 2-n times. Burst Size Defines the number of frames sent back-to-back at the Minimum IFG (Inter Frame gap). Leave this at its default of 1 for now, as specifying a step function will multiply the number of test iterations by the number of steps chosen. The RFC says the burst size should (not MUST) vary from frames. Duration The RFC recommends 30 seconds per iteration, but also says it should be adjustable from seconds. 147

149 10. From the Test Options screen, select the FIFO latency type, and then select Run as the configuration for the RFC 2889 test has been completed. a. Learning: i. L2 learning or NO learning. ii. Rate, Retry and Delay of the learning. iii. Frequency of the learning. b. Latency types: See Online help (F1) for a good description. i. recommends using the FIFO option in most cases to test in accordance with RFC When comparing against other platforms, use the LILO (default) option. LILO was typically used in measuring Latency. 148

150 11. If a pop-up window appears asking a question about the Results Report Integration, select the Yes button. 12. Spirent TestCenter Result Reporter will open and be similar to the below screen shot. 149

151 13. Even though Spirent TestCenter Result Reporter can be viewed, it is still possible to view results in the Results Browser of Spirent TestCenter. 14. The test will take a while to complete. But, while the test is running it is possible to view results for already completed iterations. To view some of the results, expand the Rfc2889 Forwarding Test Result Summary View menu item, next expand the Trial item. A list of frame sizes should be viewable. Select the frame size you wish to view the results of and expand it. This will provide a listing of the Loads performed; select one of them to view the results of the iteration. 150

152 15. Once selected, a great deal of information is now available for viewing. The results will show some of the information that is already known though it also provides much information that is not known. The important values to view are the Rx Expected Frame Count, the Expected Frame Count, and Percent Frame Loss. If the Percent Frame Loss is greater than 1%, this iteration did not pass the test. 16. Once the binary search has found a Throughput and Maximum forwarding rate for each frame size, an RFC 2889 Summary iteration is shown with the results (per the RFC). Select the Rfc2889 Forwarding Test Result Detailed Summary View. This listing will provide you with all the same information as just a single iteration view. 17. Select the 2889-For-Summary option in the results section. Next, use the drop down menu and select Rfc2889ForwardingStats. 151

153 18. Select the Test Summary Tab. This will show the results of the test and for each frame size whether the test passed. 19. Next, select the Trial Summary tab. This will provide a quick and easy way to view the results of each iteration; it very closely resembles Rfc2889ForwardingStats minus a lot of the unneeded information. 20. It is also possible to save the results. Select the results item in the tool bar and select one of the two options, PDF or HTML. 152

154 21. If you need to troubleshoot any of the results, viewing the more detailed results of the Rfc2889ForwardingStats or viewing the individual iteration will help to solve the issue. These results (especially those with lost packets) will help identify where the switch fabric may have fallen short in packet delivery or its deliverance of packets in a timely manner. While this Full-Mesh test will show where the main areas of the switch fabric may have broken down, the details results may show other areas of the switch that need to be tested further. Tests may include one-to-many, many-to-one or unidirectional traffic as defined in sections 5.2, 5.3, or 5.4, possibly using all ports within a DUT line card, or just a port pair. 22. Other RFC 2889 tests are available by contacting your local representative for the remainder of the RFC 2889 tests. The remainder of the RFC 2889 test include: Congestion Control Forward Pressure and Maximum Forwarding Rate Address Caching Capacity Address Learning Rate Errored Frames Filtering Broadcast Frame Forwarding and Latency 153

155 Multicast Registration Protocols Table of Contents Introduction 155 IGMP/MLD Overview 155 IPv6 157 IGMP Snooping 157 IGMP and MLD Testing 157 Test Methodologies 158 The Test Methodologies IGMP/MLD Join Functional Test 160 IGMP/MLD Leave Functional Test 187 IGMP/MLD Filter Functionality 191 IGMP/MLD Join / Leave Latency Test 208 IGMP/MLD Snooping Test

156 Introduction Multicast applications are proliferating throughout the telecommunications industry. Applications such as data casting (news, sports scores and stock tickers), video and audio transmissions, and training seminars (also called webinars) all depend on multicast technology. Additionally, many service providers are expanding beyond their traditional boundaries and entering the lucrative Internet Protocol Television (IPTV) market that also is entirely dependent on multicast communications. Multicast traffic requires the replication of data. A single packet can be transmitted from the source, but copies of that packet may need to be delivered to dozens, hundreds or even thousands of receivers. The impact of the resulting increased traffic loads on networks and equipment is largely unknown. Fortunately, advanced test equipment like popular Spirent TestCenter will allow the user to model various multicast test scenarios in the lab. The functionality, performance, scalability and limits of various multicast network topologies and components can be determined prior to deploying these devices in a production network. IGMP/MLD Overview There are two fundamental operations associated with successfully delivering multicast traffic over a complex IP network. The first component and focus of this paper is the registration process. This is the process by which end stations identify themselves to the network and indicate that they want to join particular multicast groups. The second operation is the routing of packets through the network to all of the registered receivers. The first step toward multicast communications is the identification of the receivers. This is accomplished via the Internet Group Management Protocol (IGMP), which takes place between the end stations (hosts) and their local router. Historically, IGMP has been an integral part of the Internet Protocol (IP) suite. In fact, IGMP has a Protocol ID of 2, indicating it is one of the earliest extensions of IP (only preceded by ICMP which has an ID of 1 ). IGMP first appeared in RFC 988 in Since then, it has been revised several times. The latest rendition is known as IGMP version 3 and codified in RFC 3376 from IGMP allows users to announce their intention to join particular multicast groups. These groups are identified by their unique Class D IP addresses. When a workstation wants to participate in a multicast group, it sends an IGMP join message to its local router. If multiple routers exist on a single segment, they can mutually elect a Designated Router (DR) that will manage all of the IGMP messages for that segment. After a router receives one or more join messages for a specific group, it will forward any packets destined for that particular group to the appropriate interface(s). The router should only forward one copy of each multicast data packet per interface. If there are multiple receivers on a single interface (such as when the router is connected to a hub or switch), they will all receive the same information by monitoring common multicast MAC and IP addresses. If a multicast group has receivers spread over several router interfaces, the router must replicate the data packets and deliver a copy to each interface that contains registered subscribers. IGMP is a stateful protocol. The designated router regularly verifies that the attached workstations want to continue to participate in their respective multicast groups by sending periodic queries to the receivers. These queries are transmitted to the reserved multicast address that is monitored by all participating workstations. If the receivers are still interested in that particular multicast group, they will respond with a membership report message. When the router stops seeing responses to its queries, it will remove the appropriate group from its forwarding table. IGMP version 2 (from 1997) allows receivers to gracefully withdraw from a multicast group. This is accomplished by creating a new leave message that a workstation will use to depart from a particular 155

157 group. This allows the router to immediately update its multicast state tables, without waiting for the expiration of the query timers. The diagram above indicates the typical path of IGMP messages. The hosts act as multicast receivers and send join or leave messages (generically known as reports ) to the local designated router. Queries and reports are periodically exchanged between the designated router and the hosts to facilitate a basic keep-alive process. Note the IGMP protocol only exists on the local LAN segment; the designated router does not forward any IGMP messages upstream to the other network devices. Multicast protocols were initially designed based upon the assumption that communications streams would consist of a single source transmitting to multiple receivers. However, nothing in the protocols prevents the inclusion of multiple sources transmitting to the same group of receivers. Several video conferencing applications are designed to support this type of configuration. In this scenario, most receivers also act as sources. However, in other environments, receiving unwanted packets from multiple ad hoc sources could adversely impact some of the receivers applications. Additionally, this could create serious security problems if an unauthorized source transmits invalid or malicious information to a large group of receivers (consider the stock quotes example). IGMP version 3 (the latest version) addresses this potential risk. IGMPv3 specifies the source(s) to which a receiver is willing to listen. Sources can be stipulated with include filters in the join and report messages, or conversely sources can be specifically rejected with exclude filters. Overall, these filters greatly enhance the security and performance of multicast communications. These filters also add another new dimension to the tables for the participating routers, since the devices must now keep track of acceptable sources for every multicast group. The specifications for IGMP versions 2 and 3 state that routers must support earlier versions of the protocol in essence, the protocol requires backwards compatibility. Although most multicast applications are currently based on IGMP version 2, version 3 is rapidly increasing in popularity and will likely supersede its predecessor soon. 156

158 IPv6 Multicast support has been built into the IPv6 protocol at its inception. The first three bits of an IPv6 address identify the format prefix (FP) of the overall 128-bit address. If the format prefix is set to binary 111, then it usually refers to a multicast address (similar to an IPv4 Class D address). Instead of using IGMP, IPv6 has its own unique registration protocol called Multicast Listener Discovery (MLD). The first version of MLD (contained in RFC 2710) is extremely similar to IGMP version 2 it supports the multicast join and leave functions. MLD version 2 is contained in RFC 3810 (from June 2004), and it adds include and exclude filter functionality as in IGMP version 3. The chart below can be used to identify the correct functionality for all of the various versions of the IGMP and MLD protocols. It should be noted that Spirent TestCenter supports all versions of these protocols. Feature IGMP MLD Joins Version 1 Version 1 Leaves Version 2 Version 1 Filters Version 3 Version 2 IGMP Snooping A fundamental supposition of both IGMP and MLD is workstations are directly connected to the designated router. This works for users of traditional Ethernet hubs or even the old fashioned baseband cable depicted in the diagram above. However, these architectures are somewhat out of date; a much more contemporary topology might consist of an Ethernet switch interconnecting many different users. The difference between a hub and a switch is a hub is a passive device that forwards all traffic to every port. A switch, on the other hand, is an intelligent device that specifically forwards data directly to the correct receivers. A switch will learn the MAC addresses (and sometimes even the IP addresses) of the locally attached workstations and build an internal forwarding table based on this information. Multicast data breaks the basic switching paradigm. Multicast packets will have special IP (Class D) destination addresses as well as unique MAC addresses (a series of Ethernet addresses have been reserved specifically for multicast data packets). If multiple workstations attached to the switch join the same multicast group, they will then share the same destination multicast IP and MAC addresses (in addition to having their own exclusive unicast addresses). Most switches do not directly participate in the IGMP or MLD protocols. Instead, they transparently pass the query and report messages back and forth from the workstations to the designated router. However, in order to do this, the switches must first learn the appropriate destinations for the query messages. They learn by eavesdropping (or snooping ) the initial IGMP/MLD join requests from the workstations to the router. The switches then build their own forwarding tables based upon the snooped IGMP/MLD information. After building this table, they can forward multicast data directly to all of the correct receivers. IGMP and MLD Testing IGMP and MLD testing will focus on the functionality, performance and scalability aspects of a designated router. From a functional perspective, the tester should verify that all of the versions of IGMP and MLD operate correctly. This process validates the basic multicast functionality of a device; this is a necessary first step prior to testing any performance or scalability characteristics. Joins and leaves should be processed while data is being forwarded. For IGMPv3 and MLDv2, these tests should also verify that the device s security filters are correctly implemented. Performance testing typically involves measuring the latency associated with a device s join and leave processes. This is especially significant for IPTV networks since channel surfing requires the rapid processing of IGMP join and leave requests (and channel surfers often tend to be impatient individuals!). 157

159 Scalability testing is a major concern for equipment manufacturers, end-users and service providers alike. Since most router ports will be attached to an Ethernet switch or hub, they could potentially support hundreds or even thousands of users. Each of these users may, from time to time, subscribe to their own unique set of multicast groups. Therefore the router may be required to track hundreds or even thousands of groups. At some point, the router s tables will become saturated. It is critical that equipment manufacturers and users identify and understand these limits. This methodology will first cover the basic functionality tests for a designated router. Then it will follow with performance (join/leave latency) tests. And finally, it will provide a separate test methodology for IGMP snooping switches. Test Methodologies The following test methodologies should serve as examples only; they are not all-encompassing multicast routing testing solutions. Most of these examples will not use a concurrent routing protocol or unicast traffic, but these variables can be added to increase test realism. Most of the tests described below will require two Spirent TestCenter ports. More extensive testing can certainly be conducted using the same basic methodologies and many more ports. In fact, increased port counts are especially useful for performance and scalability tests. In this document, gigabit Ethernet ports are used for all of the examples. However, other media and speeds can be used without adverse consequences. Finally, all tests described in this document are based upon IGMP. MLD and IPv6 addresses can be directly substituted for the IGMP parameters if needed. IGMP and MLD functional and performance testing will be divided into six different tests in order to validate all of the main protocol operations. These tests are listed (in order) below: IGMP/MLD Join Functional Test IGMP/MLD Leave Functional Test IGMP/MLD Filter Functionality IGMP/MLD Join / Leave Latency test In all cases, the DUT will be expected to appropriately forward (or block) data plane traffic. Also, in all cases IGMP version 3 will be used. 158

160 The basic test setup for the first five tests is indicated in the diagram below. VLANs will be used on LAN segment 2 to simulate multiple receivers for the same multicast groups. The sixth and final test will insert a Layer 2 Ethernet switch in between the router and the emulated IGMP receivers. This test will validate the performance of an IGMP snooping device. 159

161 IGMP Join Test Associated RFCs RFC 2236: Internet Group Management Protocol Version 2 November 1977 RFC 2710: Multicast Listener Discovery (MLD) for IPv6 October 1999 RFC 3376: Internet Group Management Protocol Version 3 October 2002 RFC 3810: Multicast Listener Discovery Version 2 (MLDv2) for IPv6 June 2004 RFC 3918: Methodology for IP Multicast Benchmarking October 2004 Overview When a workstation chooses to participate in a multicast group, it sends an Internet Group Management Protocol (IGMP) join message to its local router. The router will then add that workstation to its multicast table and forward any relevant data to that station. Objective This test validates the Device Under Test s (DUT) ability to process IGMP join requests. It also can be used to measure the DUT s IGMP group capacity. IGMP version 3 will be used for this test, but the join functionality is equally applicable for the previous versions and also for MLD. Setup The basic test setup is indicated in the diagram below. Virtual Area Networks (VLANs) will be used on Local Area Network (LAN) segment 2 to simulate multiple receivers for the same multicast groups. 160

162 Step-by-Step 1. Configure the local router to support IGMP. Often when Protocol Independent Multicast (PIM) is enabled on a link, IGMP is also enabled by default. Also, if desired, enable VLANs on Port 2 of the router. (This test will use VLANs, but these tests can also be conducted without them). Note: It is recommended that you maintain a console connection to the router this is very useful for checking statistics and debugging problems. 2. Launch Spirent TestCenter and reserve the required ports. 161

163 3. Select the port in the navigation window to configure the Media type, Port speed and duplex if needed. Repeat for all reserved ports. 4. Expand the first port and then select Hosts. 162

164 5. Select the Add button. Only a single host will need to be configured for this port. Multi-port host configuration will not be used as the second port requires VLANs, which will be configured next. 6. The defaults are okay; double check to make sure only the first port is selected and press Next. 163

165 7. Again, the defaults are okay, press Next. 164

166 8. Again, the defaults are okay, press Next. 165

167 9. Configure the correct IPv4 address and the IPv4 gateway will automatically be configured. At this point it is possible to either select Next if you wish view a preview of the configured host, or select Finish. In this test, Finish is selected. 10. Next, to configure the Multicast hosts select the Wizard buttons. 166

168 11. Expand the Configuration Wizards menu item and select Create Hosts. Press Next once completed. 167

169 12. Make sure that the second port is selected and then press Next. 168

170 13. Select the Access/Multicast radio button and then Enable IGMP/MLD. Finally, press the Next button. 169

171 14. As VLANs are going to be used, check the VLANs check box and press Next. 170

172 15. A total of 5 VLANs will be used. Change the value of VLANs per port to 5 and change the initial VLAN ID. Configure the Step to be used to create the VLANs. The VLANs, which the DUT used to create this test, is configured to use VLAN IDs of 11, 22, 33, 44, and 55. Once completed press Next. 171

173 16. Configure the correct IPv4 address (this should match the IP for the first VLAN). The IPv4 gateway will automatically be configured (change the Prefix length if needed). Next, if required, the stepping per VLAN needs to be changed. Select the button to do this. 17. Change the step per VLAN #1 as required and then press OK. 172

174 18. Once back to the previous screen press Next. 19. Change the IGMP version to Version 3 and then press Next. 173

175 20. Make sure everything is configured correctly and then press Finish. 174

176 21. Expand the second port and select Hosts. 22. Select the IGMP/MLD tab and then select the Edit Group Memberships button. 175

177 23. Select the Manage Multicast Groups button. 24. Add 4 more Groups. It is not required, but for easier viewing of the results it is recommended to change the IP Address for each group so they differ. Also, set the number of Groups to 5 for each. Once the configuration has been completed, press Close. 25. Use the Select Hosts drop down menu and select Host

178 26. The Multicast Group needs to be changed to one of the ones just created. Select the Delete Button to remove this Multicast group from Host As no Multicast Group is now associated with Host 5, one of the previously created ones needs to be added. Select the Add button to perform this task. 28. Select Ipv4Group2 to add to Host 5. Press OK once finished. 177

179 29. Notice how Host 5 now has Ipv4Group2 as its Multicast Group. Repeat steps for Hosts 6, 7 and 8 making sure to select different Multicast Group for each host. 30. Once completed with the configuration of Host 8 Multicast Group select the Close button. 178

180 31. Select Traffic Generator under the first port. 32. Use the Add drop down menu and select Add Bound Stream Block(s). 179

181 33. The defaults are okay, press Next. 34. Select Host 3 as the Source and select IPv4 under Project as the Destination. Then select the Add button. 180

182 35. Verify that 5 stream Pairs have been added then select Finish. 36. Next, ARPs must be sent out. Right click on All Hosts under All Ports. In the drop down menu, select ARP/ND Start ARP/ND On All Hosts. 37. Make sure all ARPs have successfully been resolved. A message stating whether they have all successfully been resolved should appear in the lower left of the Spirent TestCenter application. If some ARPs did not resolve successfully, check the test and DUT configuration. 181

183 38. Before traffic can be started, the IGMP Joins must first be sent. Select Hosts under the second port and make sure IGMP/MLD tab is selected. 39. Select all the Hosts and then press the button to start sending Join requests. This will send join requests for each Host. 40. Next, start transmitting the traffic by selecting the stop light with a green arrow button. 182

184 41. In the Result Browser the Total Tx Frame Count for the first port should be increase as the Total Rx Frame Count for the second port increases. This means that traffic is successfully being transmitted. 42. In the left Results Window, use the Change Result View button and select Host Protocols IGMP Results. 43. The results window should show each host with a value under Tx Frames. As each Host has 5 groups, the Tx Frames should always be a multiple of

185 44. In the right Results Window use the Change Result View button and select Host Protocols IGMP- MLD Group Results IGMP Host-Group Results. 184

186 45. There should be 5 entries per host and each entry will have a different Group Address. 46. The final check to ensure IGMP Joins have been sent successfully is to check the DUT s console. Ensure the groups have been advertised and learned. 47. Other types of tests can also be performed. It is possible to vary the input parameters (packet size and speeds), output ports (VLANs or physical ports), quantity of groups and the version of IGMP in order to fully verify the IGMP join and replication functionality of the DUT. 185

187 48. While performing this test it is also possible to increase the quantity of hosts and groups (independently and together) to determine the maximum quantities of each that the DUT can support (this limit is generally related to memory capacity). 186

188 IGMP Leave Test Associated RFCs RFC 2236: Internet Group Management Protocol Version 2 November 1977 RFC 2710: Multicast Listener Discovery (MLD) for IPv6 October 1999 RFC 3376: Internet Group Management Protocol Version 3 October 2002 RFC 3810: Multicast Listener Discovery Version 2 (MLDv2) for IPv6 June 2004 RFC 3918: Methodology for IP Multicast Benchmarking October 2004 Overview When a workstation leaves an Internet Group Management Protocol (IGMP) group, the designated router must update its tables to reflect this change. The router should also cease forwarding multicast data to that workstation. Routers will recognize that a workstation has left a multicast group when a series of queries go unanswered. Alternatively, if the workstation is using IGMPv2 or IGMPv3 (or either version of MLD), a separate leave message can be generated to gracefully exit the group. Objective This test validates the DUT s ability to process IGMP leave reports. IGMP version 3 will be used for this test, but the leave functionality is equally applicable for the IGMPv2 and also for MLD. Setup The basic test setup is indicated in the diagram below. Virtual Local Area Networks (VLANs) will be used on LAN segment 2 to simulate multiple receivers for the same multicast groups. 187

189 Step-by-Step After successfully validating the IGMP join functionality, the next step is to test the leave processes. The IGMP join test described above is a prelude to a leave functional test. 1. Perform the IGMP Join test. 2. In the navigation window select Hosts under the second port. 3. Make sure the IGMP/MLD tab is selected. Select every Host. 188

190 4. Right-click on the host listing and select IGMP/MLD Send Leave for all Groups. 5. Make sure the Results Window view is set to Port Traffic Basic Traffic Results. Once all the leaves have successfully been transmitted no traffic should be received on the second port. Notice how the Total Tx Frame Count is increasing on the first port while the Total Rx Frame Count for the second port is not. This means the Leave requests have successfully been transmitted and understood by the DUT. 189

191 6. Several of the test parameters can be altered to see their effects on the results. These include the quantities of ports, VLANs, IGMP groups and the IGMP version numbers. Data plane parameters such as packet size and rate can also be modified as desired. 190

192 IGMP Filter Test Associated RFCs RFC 2236: Internet Group Management Protocol Version 2 November 1977 RFC 2710: Multicast Listener Discovery (MLD) for IPv6 October 1999 RFC 3376: Internet Group Management Protocol Version 3 October 2002 RFC 3810: Multicast Listener Discovery Version 2 (MLDv2) for IPv6 June 2004 RFC 3918: Methodology for IP Multicast Benchmarking October 2004 Overview Internet Group Management version 3 (IGMPv3) and MLDv2 both support include and exclude source filters for security purposes. The communications industry has determined that include filters are the only practical solution for reasonably ensuring multicast data security and integrity, so exclude filters have not been commonly implemented by equipment manufacturers. Instead, include filters indicate acceptable source IP addresses; packets from all other sources must be ignored. To test this feature, include filters will be used. If the router accepts packets from these addresses and disposes of packets from other addresses, then it will satisfactorily pass this functional test. Objective This test will validate a router s ability to correctly process IGMPv3 join requests for specific multicast data sources. The test also validates the DUT s ability to process IGMPv3 join requests with specific include filters. These test procedures can also be used for MLDv2 with the IPv6 protocol. Setup The basic test setup is indicated in the diagram below. Virtual Local Area Networks (VLANs) will be used on LAN segment 2 to simulate multiple receivers for the same multicast groups. Initially, data will be transmitted from an invalid host this should be dropped by the router. Then a valid source IP address will be used; this information should be successfully delivered to the receivers. 191

193 1. Repeat Steps 1 18 of the IGMP Join test. 2. Select IGMPv3 as the version; change the Number of groups to 5. Make sure the Filter Mode of Include is selected. Select Use existing host blocks, as only one host is available to use the default should be okay. Press Next once completed with the configuration. 192

194 3. Verify the setup is correct and select Finish. 4. Select the IGMP/MLD Tab and then select the Edit Group Memberships button. 193

195 5. Select all the hosts using the Select Host drop down menu. 6. Verify the Source Filter Mode is set to INCLUDE for each host and the Starting Source IP is the correct IP. Press the Close button once completed. 194

196 7. Next, select Traffic Generator under the first port. 8. Select Add Add Bound Stream Block. 195

197 9. The defaults are okay, select Next. 196

198 10. Select the first ports Host as the Source and the IPv4Group as the destination. Press the Add button once both are selected. 11. Once the Pair is successfully added, press Next. 197

199 12. The defaults are okay. Press Next to continue. 198

200 13. Again, the defaults are okay, press Next to continue. 14. Right-click on Source and select Insert IPv4 Modifier. 199

201 15. Change the value to an IP Address that is not configured in the IGMP INCLUDE. Press OK to continue. 16. Press Finish. 200

202 17. Next, ARP requests must be sent out. Right-click on All Hosts and select ARP/ND Start ARP/ND On All Hosts. 18. Verify in the lower left that it says All attempted ARPS resolved successfully. If by chance some of the ARPS did not resolve, check both the DUT s and Spirent TestCenter s configuration. 201

203 19. Next, IGMP Join requests must be sent out. Select Hosts under the second port. 20. Make sure the IGMP/MLD Tab is selected, then select the button to start sending Join requests. 202

204 21. Once the requests have started to be sent, verify the DUT has properly handled them. 22. Start transmitting traffic. Select the traffic light with the green arrow to start transmitting the traffic. 23. In the right view of the Result Browser Port Traffic Basic Traffic Results should be selected. Scroll over to the right and make sure that for the second port Total Rx Frame Rate is 0. This means the IGMP Filter is correctly working. 203

205 24. Next, we will verify that by setting the correct IP address the traffic is able to be received. Select Traffic Generator under the first port. 25. Right-click on the stream block and select Edit. 204

206 26. Select the Frame tab and expand the Frame and Source. 27. Right-click on the RageModifer and select Delete RangeModifer. 205

207 28. If necessary, edit the Source value back to the correct IP and then press OK. 29. Press the Apply button. 206

208 30. Go back and view the Total Rx Frame Rate in the Results Browser. Traffic should be delivered to all the multicast groups on all four VLANs. 31. Similar to the two tests above, several of the parameters can be modified to see how they will affect the results. These parameters can include the quantity of ports, VLANs, groups or sources. Data plane parameters such as packet size and transmit rate can also be varied. 207

209 IGMP Join and Leave Latency Test Associated RFCs RFC 2236: Internet Group Management Protocol Version 2 November 1977 RFC 2710: Multicast Listener Discovery (MLD) for IPv6 October 1999 RFC 3376: Internet Group Management Protocol Version 3 October 2002 RFC 3810: Multicast Listener Discovery Version 2 (MLDv2) for IPv6 June 2004 RFC 3918: Methodology for IP Multicast Benchmarking October 2004 Overview The next two tests are rather similar in nature. The setup and testing procedures, along with the results, will be comparable for the join latency, leave latency and Internet Group Management Protocol (IGMP) snooping tests. The IGMP join functionality was validated in test 1 above. The next step is to measure the latency associated with the IGMP (or MLD) join process and the IGMP (or MLD) leave process. Objective This test will measure and quantify the latency associated with the IGMP join and leave process. Setup The basic test setup is indicated in the diagram below. One Spirent TestCenter port will join a series of IGMP groups, and the other port will transmit data to those groups. Convenient IGMP Join/Leave Latency wizards will be used to simplify the configuration of this test. The DUT s latency associated with processing the join requests, and then correctly forwarding the data will be measured and recorded. Once the join latency has been calculated, the first port will then leave the groups. The DUT s latency associated with processing the leave requests, and then correctly forwarding the data will be measured and recorded. Note: Additional iterations of this test should also be run with multiple ports. 208

210 Step-by-Step 1. Repeat Steps 1 35 of the IGMP Join test. 2. Make sure the Command Sequencer is visible. If not select View Command Sequencer, this should make it appear on the right side of the screen. 3. Select the Edit Sequence button in the Command Sequencer. 209

211 4. Select ArpNdStartOnAllDevicesCommand from the list and then select the arrow to add it to the list on the right. 5. Double-click the ArpNdStartOnAllDevicesCommand. 210

212 6. Select the Port handle list and then select the which appears. In the window that opens, select the required ports. Once the command is finished being configured press OK. 211

213 7. In the command listing scroll down and locate the GeneratorStartCommand. Once located add it to the list of commands that will be run. As previously done, double-click the entry to edit it. 8. Select both ports to start the Generator on. Press OK once completed. 212

214 9. In the list of commands, locate the StreamBlockStart command and add this to the listing of commands that will be run. Edit the command and add the correct stream block. Press OK once finished. 10. Locate and add IgmpMldJoinGroupsCommand and then edit the command. Select each one of the hosts, and select the Calculate Join Latency check box. Next, set a value of 60 for the Delay after joins option. 213

215 11. Locate and add IgmpMldLeaveGroupsCommand and then edit the command. Select each one of the hosts, and select the Calculate Leave Latency check box. Next, set a value of 180 for the Delay after leaves option. 12. Select the StreamBlockStopCommand from the options list. Once the command has been added edit it and select the correct Stream Block to stop. 214

216 13. Locate and add the GenratorStopCommand to the sequence of commands to be run. Once it has been added, edit the command and select both ports to stop the generator on. 215

217 14. The final sequence should appear like the image below. Press OK once completed. 216

218 15. Start the Command Sequencer by select the Green Arrow. If any of the commands fail, please check the setup or the commands configuration. 16. The Results Reporter is not really required, so press No to continue. 217

219 17. Once the test has finished, the command sequencer should appear like the image below. The total test completion time is provided in the lower right of the Command Sequencer. 218

220 18. Change one of the Result Browser views to Host Protocols IGMP-MLD Group Results IGMP Host-Group Results. Scroll to the right to see the Join and Leave Latency in msec. 19. If by chance a value of 0 is given, edit the timings of the IGMP Join and Leave Delay. Increasing this time might provide the results that are missed due to the fact that a longer delay is provided to receive the join or leave request. If any changes are made, rerun the test. 219

221 IGMP/MLD Snooping Test A traditional Ethernet switch forwards Layer 2 traffic through a process of learning the source and destination address and populating a MAC address table. If frames come into a port destined for a MAC address that is unknown, the switch will replicate the packet out all of its ports and when the correct destination replies it adds the entry to its table and effectively learns that address. Multicast traffic uses a reserved block of addressing for the first 6 bytes of the 12 byte MAC address (01:00:5E:xx:xx:xx:). As a result, a Layer 2 switch will essentially treat multicast traffic as broadcast traffic, forwarding it out all ports without ever correctly populating its MAC address table. As there are no destinations that will reply with a multicast MAC address. This can consume a lot of bandwidth if many multicast servers are sending streams to the segment. To prevent multicast traffic from being forwarded out all ports of a switch (or a Virtual Local Area Network (VLAN)), a feature called Internet Group Management Protocol (IGMP) Snooping can be enabled making the Layer 2 switch multicast aware. IGMP Snooping is a Layer 2 function. It does not require multicast routing to be enabled. When IGMP Snooping is enabled, the Layer 2 switch keeps track of Layer 3 IGMP messages, and only forwards multicast traffic to the port, or part of the local network that requires it. IGMP snooping optimizes the usage of network bandwidth and prevents multicast traffic from being flooded to parts of the local network that do not need it. In IP Multicast there are two active components: a Source (which transmits a multicast stream for a particular group) and a Host (which joins the multicast group and becomes the receiver of the group). The join mechanism depends on the version of IGMP or Multicast Listener Discovery (MLD) that the Host is running. There is IGMP v1, v2, v3 and MLD v1, v2. The intent of this document is to focus on testing IGMP snooping so details of the various versions will not be covered. In a typical IP Multicast environment there are routers that exist between the Source and the Hosts. The router closest to the Hosts is called the Last Hop Router (LHR). A Last Hop Router will typically send query messages to the Hosts periodically to ensure there are still hosts interested in the IP Multicast Source that is being forwarded. The query message triggers the Host to reply with a Report (join) message which keeps the Host entry from timing out in the IP Multicast forwarding table or the switch. When IGMP Snooping is enabled, the switch will build a forwarding table based on the IGMP join/report messages received on port. If a Host transmits a Leave message the switch will remove that entry from the table and stop forwarding traffic on that port. Some switches also have the ability to transmit a query message to ensure there are no other Hosts interested in the multicast group before stopping the transmission. 220

222 Associated RFCs RFC 2236 Internet Group Management Protocol (IGMP) Version 2 RFC 2544 Benchmarking Methodology for Network Interconnect Devices RFC 2889 Benchmarking Methodology for LAN Switching Devices RFC 2710 Multicast Listener Discovery (MLD) for IPv6 RFC 3376 Internet Group Management Protocol (IGMP) Version 3 RFC 3810 Multicast Listener Discovery (MLD) Version 2 for IPv6 RFC 3918 Methodology For IP Multicast Benchmarking Overview Establish a performance baseline by running RFC 2544 and RFC 2889 benchmark testing. With IGMP Snooping disabled, send IP Multicast traffic on one port of the switch (or VLAN) and ensure that it is forwarded out on all the ports. Next, IGMP Snooping will be enabled and traffic will be sent to the same IP Multicast group on one port of the switch. Ensure the traffic is not forwarded to any of the other ports. On a specific port or ports, transmit a join/report message to the IP Multicast group that is being transmitted. Using IGMPv2 or IGMPv3, transmit a leave for the IP Multicast group being transmitted. Verify the ports stop receiving the multicast traffic. Repeat this process and measure the IGMP join and leave latency. Again, the process will be repeated with packet sizes specified in RFC 2544 and characterize the performance at different packet sizes and loads up to 100% line rate. Please be aware that IGMP entries may time out in the Layer 2 switch forwarding table. To keep the table populated, a join/report message must be transmitted before the timeout. Since typically a router issues the Query message to trigger the join/report message, the first option to test this is depicted in Figure 1. Objectives Enabling IGMP Snooping on a DUT assures that traffic is not forwarded to any unnecessary ports. Also, this test will help determine the effectiveness and ability of IGMP Snooping. 221

223 Setup Figure 1 222

224 The second option is to isolate the Layer 2 switch. In this case, the test equipment can be configured to emulate the router and send query messages as depicted in Figure 2: Figure 2 223

225 Step-by-Step 1. Launch Spirent TestCenter and reserve the required ports. 224

226 2. Select Hosts under the first reserved port. 3. Select the Add button. 225

227 4. Select the first port and then press Next. Only the first port needs to be selected as this port is not going to be configured as a multicast host. 226

228 5. The defaults are okay, press Next. 227

229 6. Again, the defaults are okay. Press Next to continue. 228

230 7. Configure the IPv4 Address and based upon the Prefix length the IPv4 gateway will automatically be configured. As this is the only port being configured, none of the Step information needs to be changed. Press Next to preview the hosts configuration. 229

231 8. Verify the hosts configuration is correct and press Finish. 230

232 9. Next, select Hosts under the second reserved port. The last two ports will be configured as multicast hosts. 10. Select the Add button. 231

233 11. Select the two unconfigured ports and press Next. 232

234 12. Enable Access/Multicast and select IGMP/MLD from the Protocol list. Once complete, press Next. 233

235 13. The defaults are okay, press Next to continue. 234

236 14. Configure the Ipv4 Address and the IPv4 gateway should automatically be configured based on the Prefix length. Select the button in the IPv4 section to configure the Step per port. 15. Change the Step per port to the correct value and press OK. 235

237 16. Notice that the Step field has been updated and press Next to continue. 236

238 17. It is possible to change the IGMP version to match the configuration of the DUT. Also, the Starting group IP can be changed as well. Once satisfied with the IGMP configuration, press Next. 237

239 18. Verify the hosts configuration is correct and press Finish. 238

240 19. Select Traffic Generator under the first reserved port. 20. Use the Add drop down menu and select Add Bound Stream Block(s). 239

241 21. The defaults are okay, press Next. 240

242 22. Select the host on the first reserved port as the Source and select the multicast group address as the Destination. Press the Add button once completed. 23. Verify the pair has been added and press Next. 241

243 24. The defaults are okay, press Next to continue. 242

244 25. Change the Scheduling mode to Rate Based and then change the Load unit to Frames/Sec (FPS). Finally, change the Load value to 1000 and press Finish. 26. Before traffic can be started, ARPs must be sent. Right-click on All Hosts under All Ports. Select ARP/ND Start ARP/ND On All Hosts. 243

245 27. Verify all ARPs have successfully been resolved. A message saying so should be visible in the lower left of the screen. 28. Next, start the traffic stream by pressing the button. 29. Traffic should not be seen on the second and third reserved port, as the IGMP Joins have not yet been sent. Verify this by using the Results Browser. Make sure the view is set to Port Traffic Basic Traffic Results. If it is not visible, use the Change Result View drop down menu to select it. 30. If is also useful to verify the IGMP snooping table on the DUT. The results are as expected there is a sender but no receivers. 244

246 31. Next, send the join requests. Select Hosts under the second reserved port and then select the IGMP tab. 32. Select the Send Report for All Groups button. 245

247 33. After the join has been sent, traffic should start to be received on that port alone. Verify this by looking at the results browser Port Traffic Basic Traffic Results view. 34. Also, verify the results on the DUT. The results now indicate one income stream and one outgoing stream. 35. An optional step is to very the IGMP Snooping timeout. For example, this particular DUT times out multicast receivers after 260 seconds. After 260 seconds, the entry times out and is cleared from the table. At that point, the DUT stops forwarding IP Multicast traffic to the second reserved port. To prevent IGMP entries from timing out, IGMP Query messages are used. 246

248 36. Select Traffic Generator under the first reserved port. 247

249 37. Use the Add drop down menu and select Add Bound Stream Block(s). 38. The defaults are fine, press Next. 248

250 39. Select the host on the first reserved port as the Source and select the multicast group address as the Destination. Press the Add button once completed. 40. Verify that the pair has been added and press Next. 249

251 41. The defaults are okay, press Next to continue. 250

252 42. Change the Scheduling mode to Rate Based and then change the Load unit to Frames/Sec (FPS). Finally, change the Load value to 1 and press Next. 43. Right-click and select Add Header. 251

253 44. Select IGMPv2 and press OK. 252

254 45. Configure the frame as needed. Change the Message Type to Membership Query, change the Maximum Response Time and the Group Address. Once done press Finish. 46. Make sure to answer No. 253

255 47. Right-click on the new stream entry and select Start. 48. Verify that Port 2 is seeing and responding to the query messages. Change the view in the results browser to Port Protocols IGMP Results. In this case 10 Rx frames indicate 10 query messages were received, however, only 2 Tx (Report) messages were sent. This is due to the Maximum Response Time configured in the query value is in 1/10 of a second. Reducing the Maximum Response Time to 10 produces the following. 49. As per RFC 2236 the default IGMP query time is 125 seconds, so sending IGMP query packets at 1 fps is a much higher rate than necessary. To work around this, a tester can manually enable and disable the IGMP Query traffic stream, or use the Command Sequencer to start and Stop the stream every 125 seconds. 254

256 50. While transmitting IGMP Query messages, on the DUT verify the AGE timer is not incrementing more than the Query interval. 51. As a functional test, stop the query stream and verify the IGMP table entry times out of the DUT. 52. The following is a list of additional tests which can also be performed. Testing Tips: With IGMP Snooping disabled, test the switch s ability to rate-limit multicast/broadcast traffic Test the switch s ability to filter IGMP and IP Multicast packets Test the IGMP stack for backwards compatibility Test the size of the IGMP cache on the switch (Sources and Hosts) Configure static IGMP Snooping entries and verify they are working Test various timers of the IGMP Snooping capability Repeat test cases with VLANs enabled and multiple VLANs Verify commands to examine the counters and cache on the switch work properly Incorporate white box testing to configure/monitor/verify the DUT during the test Some DUTs will not allow an IGMP host and an IP Multicast source to be on the same port. If the setup works unidirectionally, but not bi-directionally, this is most likely the issue. If the Maximum Age Timer in the IGMPv2 header = 0 then as per RFC 2236, the packet is an IGMPv1 query. To make it an IGMPv2 query, verify the Maximum Age Timer is not equal to 0. On a LAN segment or VLAN there is typically only one querier. If the DUT does not allow the querier to exist on the same port as the IP Multicast stream, then configure the query on another port of the VLAN, for example Port 3 of the above example. 255

257 Spanning Tree Protocol Table of Contents Introduction 257 Root Bridge Election Process 257 Network Topology Changes 258 Spanning Tree Protocol Testing 258 The Test Methodologies STP Basic Functionality Test 260 STP Topology Change Test

258 Introduction When designing a Local Area Network (LAN) with multiple switches, most network engineers would include redundant links and segments between switches to keep the network service available in case of failure in the network (e.g., switch and/or link failure). Without Spanning Tree Protocol (STP), frames would loop for an indefinite period of time in the networks with physically redundant links. These looping frames would cause serious network performance degradation. To prevent looping frames, STP blocks some ports from forwarding frames so that only one active path exists between any pair of LAN segments (collision domains). Bridge 4 Blocked Port Bridge 2 Bridge 3 Bridge 5 Bridge 1 Figure 1 Basic Function of Spanning Tree Protocol: Blocking Prevents Loops As shown in Figure 1, STP places interfaces in a forwarding state or blocking state using the following criteria. STP elects a root bridge. STP puts all interfaces on the root bridge in forwarding state. Each non-root bridge considers one of its ports to have the least administrative cost between itself and the root bridge. STP places this least-root-cost interface, called that bridge s root port, in forwarding state. Many bridges can attach to the same Ethernet segment. The bridge with the lowest administrative cost from itself to the root bridge, as compared with the other bridges attached to the same segment, is placed in forwarding state. The lowest-cost bridge on each segment is called the designated bridge, and that bridge s interface attached to that segment is called the designated port. All other interfaces are placed in blocking state. Root Bridge Election Process STP defines and uses the messages, called Bridge Protocol Data Units (BPDUs), to exchange information with other bridges. STP begins by sending a BPDU with the root bridge s bridge ID and the cost to reach the root from this bridge along with the bridge ID of the sender of this BPDU. The process of choosing the root begins with all bridges claiming to be the root by sending hello BPDUs with their bridge ID and priorities. If 257

259 a bridge hears of a better candidate, it stops advertising itself as root and starts forwarding the hello sent by the better bridge. Eventually, a switch wins and everyone supports the elected switch. The bridge ID is the concatenation of the bridge s priority and a MAC address of the bridge unless it is explicitly configured as another number. The bridges elect a root bridge based on the bridge IDs in the BPDUs. The root bridge is the bridge with the lowest numeric value for the bridge ID. Network Topology Changes Once the STP topology has been set, the root bridge sends a new hello BPDU every 2 seconds by default. When a bridge doesn t receive the hellos after the MaxAge amount of time, something has failed, so it reacts and starts the process of changing the spanning tree. P1 Bridge 4 P2 P2 P2 Blocked port Bridge 2 P1 Forwarding Bridge 5 P1 Bridge 3 P1 P2 Bridge 1 Figure 2. Reacting to Network Failure. As shown in Figure 2, when the Bridge 5 detects the link failure between Bridge 2 and itself it will need to change from blocking to forwarding on its Port 2. However, if Bridge 5 makes that transition immediately, and other bridges/switches were also converging loops could possibly occur. To prevent this potential loop, STP uses two intermediate interfaces states. The first, listening, allows each device to wait to make sure that there are no new, better hellos with a new, better root. The second state, learning, allows the bridge to learn the new location of MAC addresses with allowing forwarding and possibly causing loops. These steps help prevent the bridges from flooding frames until all the switches have converged and learned the new MAC addresses. Spanning Tree Protocol Testing STP testing will focus on the functional aspects of a Device Under Test (DUT). There are sets of rules on electing a root bridge and discovering root and designated ports. Functional testing is the most important aspect of STP testing, verifying the DUT participating in the processes follows the rules and builds a proper spanning tree. Also, verifying the DUT s capability to react to any changes on the spanning tree, including a disruptive network failure and/or administrative change. 258

260 All of the STP test methodologies in this journal are listed below: Test 1 STP Basic Functionality Test The first test methodology validates basic STP functionality. This test verifies the DUT properly processes BPDU and participates in the root election process. There are several parameters that affect the election, including bridge priority, bridge ID (MAC address part), root path cost, etc. By manually manipulating those parameters in various ways, one can test many different election scenarios. This can also serve as a baseline for subsequent STP testing. For a more realistic test environment, background traffic will be introduced while the test is running. Monitoring traffic flows to and from the different ports will be a good visual indication of the state (forwarding) of the ports. Test 2 Topology Change (Bridge Failure) Test The second test methodology is designed to determine the DUT s capability of reacting to a network failure and consequent topology change, and measure the time to converge into the new topology (tree). There are several timers (e.g., MaxAge and Forward Delay) that will affect the convergence time. By measuring the time while monitoring the state of each port, one can verify the DUT s capability to build a new spanning tree. For a more realistic test environment, background traffic will be introduced while the test is running. Monitoring traffic flows to and from the different ports will be a good visual indication of the state (forwarding) of the ports. 259

261 STP Basic Functionality Test Associated RFCs RFC 1493: Definitions of Managed Objects for Bridges RFC 1525: Definitions of Managed Objects for Source Routing Bridges RFC 2674: Definitions of Managed Objects for Bridges with Traffic Classes, Multicast Filtering and Virtual LAN Extensions Overview This test is designed to validate basic Spanning Tree Protocol (STP) functionality. For this test, the Spirent TestCenter platform (Port 1, Port 2, and Port 3) will emulate bridges on the network with the Device Under Test (DUT). Initially, they will be set up such that the DUT is elected as a designated bridge on all the segments as well as a root bridge across the network. The DUT will put all of its port in a forwarding state. Then the root priority will be lowered on two of the bridges (Bridge 2 and Bridge 3) this will cause Bridge 2 and Bridge 3 to advertise and be elected as a root bridge. Then, verify that the DUT blocks one of its ports (Port 2 in this case) to prevent a loop. Objective This test will determine the DUT s ability to participate in the election process properly and make necessary changes on its ports when there is a better root bridge advertised. Setup Bridge ID: 32768/22 P2 P1 Bridge 4 Bridge ID: 32768/44 P DUT Bridge ID: Bridge 2 P /MAC P1 Bridge 3 P2 Bridge ID: 32768/ P1 P2 Bridge 1 Bridge ID: 32768/11 260

262 Step-by-Step 1. Launch Spirent TestCenter and reserve the required ports. If the technology selector appears select STP. 261

263 2. If the Technology Selector did not appear on the launch of TestCenter, select Tools Select Technology from the menu bar. Then use the Technology Selector to choose STP. 262

264 3. In the navigation window select All Ports All Routers. 4. Next, select the Add button. 263

265 5. Select all the reserved ports and then press Next. 264

266 6. The defaults are okay, press Next to continue. 265

267 7. Again the defaults are okay, press Next. 8. Configure the IPv4 address and the IPv4 gateway should automatically be calculated depending on the IPv4 address and the Prefix length. Once done press the button next to Step in the IPv4 section. 266

268 9. Configure the Step per port and then press OK. 10. Press Next once back to the previous screen. This will then take you to a preview of the configured routers. 267

269 11. Verify all the routers are configured correctly and press Finish. 12. Select the STP tab and then Activate each one of the routers. 13. Change the Bridge MAC Address so that each entry has a unique value. Also, change the Root Bridge value of the last two ports to Custom and change the Root Priority to a value greater than what the DUT is configured as and as a multiple of Finally, change the Root MAC Address field to another unique value, but keep it the same for both ports. 268

270 14. Next, we need to create traffic streams. Expand the first port and select Traffic Generator. 15. Select Add Add Bound Stream Block. 269

271 16. Make sure all ports are selected and then press Next. 270

272 17. Select Fully meshed as the Distribution and make sure that each router is selected. Once completed press Finish. 18. If you wish, you can set each traffic stream grouping to transmit at a certain rate. Select Rate Based as the Scheduling mode. Then scroll over to the right and change the Load and Load Unit to the desired values. Repeat this procedure for the remaining ports. 271

273 19. Right-click on All Routers in the navigation window and select ARP/ND Start ARP/ND On All Routers. 20. A message will appear in the lower left of the screen. This message will tell you if all the ARPS were successfully resolved. 21. First start the routers by selecting the button. 22. Next start the traffic by selecting the button. 272

274 23. Verify traffic being sent by viewing Stream Results Detailed Stream Results in the Results Browser. If this view is not currently being displayed, change the view using the Change Result View drop down menu. Traffic is successfully being transmitted if both the Tx and Rx Frame Count are being increased. 24. Go to the DUT s console window to verify the status of all ports. Also check the Root Bridge and the cost to that bridge. 273

275 25. Check the STP results by selecting Change Result View Router Protocols STP Results. 26. Using the STP Results view in the Results Browser provides a great deal of information. It can provide you with the Bridge ID MAC Address, the Root ID MAC Address, the Tx State and more. 274

276 27. Now, change the root priority for Bridge 2 and 3 to one that is lower than the DUT s priority, in this case This will cause a reelection of the root bridge, in this case it will be that is elected as the new root bridge. To do this select All Ports All Routers. 28. Locate the Root Priority and change this to To make the changes take affect press the Apply Button. 275

277 30. Go to the DUT s console window to verify the status of all the ports. Also check the root bridge and the cost to that bridge. 31. Check the Results Browser Stream Results Detailed Stream Results view. Make sure that streams to and from ports that are in the forwarding status are being received. In this case, the DUT starts blocking its Port 5. So, the streams from Spirent TestCenter s third port to the other ports should no longer be received. As Port 2/9 is sending at a rate of 100 fps it is sending 50 frames to each of the other two ports. Port 2/10 is sending at a rate of 200 fps each of the other two ports receives 100 fps. Port 2/11 is sending at 300 fps, but no frames are being received by the other ports. 276

278 STP Topology Change Test Associated RFCs RFC 1493: Definitions of Managed Objects for Bridges RFC 1525: Definitions of Managed Objects for Source Routing Bridges RFC 2674: Definitions of Managed Objects for Bridges with Traffic Classes, Multicast Filtering and Virtual LAN Extensions Overview This test will determine the Device Under Test s (DUT) capability to react to a network failure and the consequent topology change. By measuring time while monitoring the state of each port, one can verify the DUT s capability to build a new spanning tree. For a more realistic test environment, background traffic will be introduced while the test is running. In this test, similar to the previous test, the Spirent TestCenter platform (Port 1, Port 2, and Port 3) will emulate bridges on the network with the DUT. From the last status of the previous test case where the DUT blocks Port 2, we will fail the emulated Bridge 2 on Spirent TestCenter s Port 2. Then, it will be verified that DUT put the blocked port (Port 2) back into the forwarding status. Objective This test will determine the DUT s ability to react to the failure of neighbor bridges and topology changes. Setup P1 Bridge ID: 32768/44 P2 Bridge 4 Bridge ID: 32768/ DUT Bridge ID: Bridge 2 P /MAC P1 Bridge 3 P2 Bridge ID: 32768/ P1 P2 Bridge ID: 32768/11 277

279 Step-by-Step 1. This test continues from the end of the previous test. To simulate a failure of one of the emulated bridges, you can stop a router. We will stop the router that is enabled on the second reserved port in this test. Select Routers under the second reserved port. 2. Next, select the button. This will stop this router only. 278

280 3. After waiting for the hello BPDU for MasAge (in this case 20 seconds by default), the DUT is supposed to change the status of the previously blocked port to the Listening state. Go to the DUT s console window to verify the status of the port. 4. Then, after listening for Forward Delay (in this case 15 seconds), the DUT places the port in the Learning state. Go to the DUT s console window to verify the state of the port. 279

281 5. When the DUT has finally put the port in the forwarding state, the remaining traffic streams will start to be transmitted. View the Rx Frame Rate in the Stream Results Detailed Stream Results view. If this view is not currently selected use the Change Result View drop down menu to change to it. 6. Go to the DUT s console window to verify the state of the port. 280

282 7. Additional iterations of this simple test can be run varying some of the following parameters and measure the time to merge with different timer values: MaxAge Hello Forward Delay Hold Count 281

283 Access Control List Table of Contents Introduction 283 Access Control List Testing 284 The Test Methodologies ACL Basic Functionality Test 285 ACL Performance Test

284 Introduction If you ve ever managed a large network before, chances are you ve had encounters with Access Control Lists (ACLs) or stateless packet filters. ACLs are features in some routers and switches that allow you to drop, limit or mark certain types of traffic. Use of ACLs may be for security, protection against Denial of Service (DoS) attacks, or to limit certain types of traffic from entering the routing domain at an administrative boundary, e.g. Simple Network Management Protocol (SNMP). The list is a structure containing an ordered collection of entries called Access Control Entries (ACE). Depending on the device capabilities, ACLs may be applied to incoming or outgoing packets on a physical interface, Virtual Local Area Network (VLAN), tunnel or other logical interfaces. ACLs are useful for solving certain network security problems, but they do have downsides. They can degrade the forwarding capacity of the device and add latency. From Address To Address Action Any /16 Discard Any /12 Discard Any /8 Discard Any Any Forward Figure 1 - ACL Applied to Outgoing Interface In an ACL, transit packets are compared against each ACE in the ACL until the packet matches the criteria specified. If an ACE is matched, that ACE contains actions to be applied against the packet. The ACE can match against information in any of the headers in the packet, from Layer 2 to Layer 4 and above. Examples of criteria to be compared against an ACE: Address information DiffServ Code Point/Type of Service/Class of Service values IP fragment information IP protocol type IP options TCP/UDP source/destination ports TCP flags (no-ack, SYN) 283

285 Examples of some actions that may be taken against a packet matching an ACE: Discard the packet, and send an ICMP unreachable message to the source noting the packet is administratively prohibited. Silently discard the packet. Police (limit) the rate of all packets matching the ACE. Mark the packets with a specific DiffServ Code Point (DSCP) for special handling downstream. Set a DiffServ Per-hop Behavior (PHB). Write security entry into the system log. Sample (save) the packet to a file for flow analysis. A combination of the above. The goal of this test methodology is to help you characterize your device with ACLs configured. This methodology will help you determine: Whether ACLs are actually performing their intended purpose. The maximum forwarding rate of the device with ACLs applied. Access Control List Testing ACL testing will focus on the functional and performance aspects of a device under test (DUT). By performing these test methodologies, the functional operability and performance impacts against the DUT may be properly gauged. All of the ACL test methodologies in this journal are listed below: Test 1 ACL Basic Functionality Test The first test methodology validates basic ACL functionality. We will place an ACL on an outgoing interface of the DUT. In the Spirent TestCenter GUI, we will also configure streams and place those streams into traffic groups. Next we will start sending traffic. The configured traffic groups will show, at a glance, whether the DUT is forwarding or discarding the appropriate traffic. We will also show the difference in latency with, and without, the ACL in place by using the interactive average latency feature. Test 2 ACL Performance Test The second test methodology is designed to determine the DUT s capacity to forward traffic under load with an ACL in place. We will use the built-in RFC 2544 throughput test to determine the forwarding capacity of the DUT with different frame lengths configured. This is an automated test that may be run from the GUI, and facilitates troubleshooting by returning to interactive mode without replicating the test configuration in a different tool. 284

286 ACL Basic Functionality Test Overview This test is designed to validate basic Access Control List (ACL) functionality. For this test, we will use two test ports on the Spirent TestCenter platform. On one port, we will create four streams. One stream is used to represent good traffic, which will be allowed to pass. Two other streams will be used to represent IP fragmented traffic. One last stream will be used with an IP source address from the RFC 1918 private address space. All of the last three streams will be restricted by the Device Under Test (DUT) and discarded. The access control list will be configured on the DUT outgoing interface to discard IP fragmented traffic and traffic from private addresses. All other traffic will be allowed. IP fragmented traffic for this test is defined as one of the following: IP packets with a fragment offset of zero and the more fragments (MF) flag set in the fragment options field IP packets with a fragment offset greater than zero, regardless of the MF flag We will use two streams to represent both types of fragmented data Objective This test will determine the DUT s ability to properly handle traffic according to its ACL configuration. It will also show the latency with and without the ACL in place. Setup Fragmented Packets Traffic from private addresses /24 Good traffic /24 Good traffic 285

287 Step-by-Step 1. Connect and configure the DUT on Ports 1 and 2. Do not apply the Access Control List just yet. Keep the DUT s console window open for additional direct feedback or configuration modifications. 2. Launch the Spirent TestCenter application and reserve the required ports. 286

288 3. Select Hosts under the first reserved port. 4. Depending on your DUT configuration, it is possible to configure hosts for each Port. Select the Add button. 287

289 5. Select both ports to configure Hosts for each. Press Next to continue. 288

290 6. The defaults are okay, press Next. 289

291 7. Again, the defaults are okay, press Next. 290

292 8. Configure the correct IPv4 address, and the gateway will automatically be configured depending on the Prefix length. Change the Prefix length if needed. Select the button in the IPv4 section. This will allow us to configure the step per port of the hosts. 9. Change the Step per port to match your DUT configuration. Press OK once finished. 291

293 10. Notice how the Step field has been update to reflect the changes. To view a preview of the Host configuration press Next. 292

294 11. Verify that the Host configuration is correct. If it is not correct go back and make the required changes before continuing. Once finished press the Finish button. 12. In the navigation window select Traffic Generator under the first reserved port. 293

295 13. Use the Add drop down menu and select Add Bound Stream Block(s). 14. The defaults are okay, press Next. 294

296 15. Select Host 3 as the Source and Host 4 as the Destination. Once both are selected press the Add button to add the pair. 16. Make sure the Pair has been added and then as no other configurations need to be done press Finish. 295

297 17. Right-click on the stream block that was created and select Duplicate. 18. Choose 3 for the number of copies to create. Click OK. 19. The three duplicated streams will be edited. To edit a stream block right-click on the second stream block and select edit. 296

298 20. Select the Frame Tab and check the Show All Fields box. Locate the MF Bit and change the value from 0 to 1. Once completed press OK. 297

299 21. Edit the next bound stream block and change the Fragment Offset value from 0 to 5. Press OK after you are finished. 298

300 22. Edit the last bound stream block and change the source IP address to , an address in the RFC 1918 space. To change the Destination address, a modifier might have to be used. The only value in the modifier that will need to be changed is Value(s). Press OK after you are finished. 299

301 23. To make identifying the streams easier, it is possible to update the name of the bounded streams. 24. Next, ARPs must be sent out. Right-click on All Hosts under All Ports. In the drop down menu select ARP/ND Start ARP/ND On All Hosts. 25. Make sure all ARPs have been resolved successfully. A message saying if they have all successfully been resolved should appear in the lower left of the Spirent TestCenter application. If some of the ARPs did not resolve successfully, check the test and DUT configuration. 26. Now traffic can be started. Each of the streams should be able to successfully transmit as the ACL is not activated. To start traffic press the button. 300

302 27. In the results browser make sure that Stream Results Detailed Stream Results is selected. If not, use the Change Result View button to select this view. 301

303 28. Notice that each stream is able to transmit traffic successfully as the Rx Frame Count is increasing as the Tx Frame Count increases. Other methods of verification are possible, such as looking at the Tx and Rx receive rates. 29. Select all the Rx Frame Rate values for each Stream. Right-click and Select Add to Chart. 302

304 30. Enter in a View Name, select Stream Results and Press OK. This will create a chart that shows the Rx rate for each individual stream. 303

305 31. A chart like the one below should be created. 304

306 32. Next apply the ACL to the interface on the DUT. The ACL configured b the author for this DUT is shown below. 305

307 33. After applying the ACL to the interface, the prohibited traffic Rx should drop to View the chart and notice that the Prohibited traffic also dropped to 0, as would be expected and that the permitted traffic is the only traffic that is still being received. 306

308 ACL Performance Test Overview This test will determine the Device Under Test s (DUT) capability to forward traffic at line rate while processing a large Access Control List (ACL). We will use the RFC 2544 throughput test to find the maximum forwarding rate of the DUT, or line rate, whichever is less. In this test, similar to the previous test, we will use two ports of the Spirent TestCenter platform. We will use a Tcl script to generate a large ACL. Each Access Control Entry (ACE) of the ACL will match against a random destination IP address not directly in use by the test. At the end of the access control list will be a permit any statement which allows all traffic not matching an ACE to be forwarded. The exact number of ACEs in the ACL is implementation specific and varies from DUT to DUT. In this example, the ACL has 400 ACEs and a default ACE which matches all traffic. Objective This test will determine the DUT s forwarding capacity with a large ACL configured. Setup 307

309 Step-by-Step 1. Use a script to generate a large ACL with a default ACE at the end of the list that will match all traffic. Set the action for this ACE to forward traffic. Apply the ACL to an interface of the DUT. 2. Launch Spirent TestCenter and reserve the required ports. 308

310 3. Select the Wizards button from the toolbar; select Test Wizards Rfc 2544 Throughput. Click Next. 309

311 4. Select both ports. Click Next. 310

312 5. Select Fully meshed as the Distribution and make sure port ports are selected. Next select Addressing in the Traffic Descriptors section. 311

313 6. Configure the IP Address and the IPv4 Gateway Address. Select IP Header once completed. 312

314 7. Use the drop down menu to select the next protocol. The default is okay, to add to the list press the add button. It is not required to add an IP next protocol as the test will still perform as expected without it. Once done click Next. 313

315 8. Change the Trial Duration Time to 30 seconds. You may wish to use 60 seconds for an RFC standard test. Enter the custom frame sizes as shown. Setup the initial rate to 100%. By setting the initial rate to 100% the test may finish sooner, depending on the DUT. Once completed click Run. This will automatically start the RFC 2544 test. 9. If a pop-up window appears asking a question about the Results Report Integration, select the Yes button. 314

316 10. The Results Reporter will open once results are available. 11. The test will take a while to complete. While the test is running, it is possible to view results for already completed iterations. To view some of the results, expand the Rfc2544 Throughput Test Result Summary View menu item, next expand the Trial item. A list of frame sizes should be viewable. Select the frame size you wish to view the results of and expand it. This will provide a listing of the Loads performed; select one of them to view the results of the iteration. 315

317 12. Once selected, a great deal of information is now available for viewing. The results will show some of the information that is already known, though it also provides a great deal of information which is not known. The important values to view are the Forwarding Rate (fps), the Minimum Latency and Maximum Latency. 13. Once the binary search has found a Throughput rate for each frame size, an RFC 2544 Summary iteration is shown with the results (per the RFC). Select the Rfc2544 Throughput Test Result Detailed Summary View. This listing will provide you with all the same information as just a single iteration view. 14. Select the 2544-Tput-Summary option in the results section. Next use the drop down menu and select Rfc2544ThroughputStats. 316

318 15. Select the Test Summary Tab and this will show a chart that compares the Throughput by Frame Size to the Theoretical Max. As you can tell, the DUT used in this test performed very well for the larger size packets, yet with the smaller sized packets it did not perform as well as one would have hoped. 317

319 16. Next, select the Trial Summary tab. This will show the Throughput of each Frame Size as a percentage and as Frames Per Second (fps). 17. To see what the effects of having a 400 line ACL were on the DUT, the RFC 2544 test should be performed again without the ACL enabled. Compare the results of the two tests to determine how the ACL affects the DUT. 318

320 Negative Testing Table of Contents Introduction 320 Negative Testing 321 The Test Methodologies Transmission of PDUs with Errors

321 Introduction This test methodology explains some of the basic concepts of negative testing, and how you may use the Spirent TestCenter platform to perform negative testing. Negative testing means many things to many people and unlike normal testing, it is difficult to quantify and plan. Only through extensive experience and a feel for how a device behaves and reacts can negative testing be adequately executed. Unlike your typical testing where you attempt to figure out if the device is performing as expected for a given stimulus, you are deliberately trying to find faults. This is done by sending control, management or data traffic that is out of the norms. By digging and probing the system, you find ways to make bad situations worse and discover if the device gracefully degrades service, or crashes and burns. Negative testing is a complex subject. Many wonderful resources freely exist on the Internet for you to check out to help make things clearer. One such white paper is A Positive View of Negative Testing by James Lyndsay. While this white paper was written from the perspective of testing software, many of the same techniques are applicable to testing network devices. Search Google for negative testing, and you ll get quite a few useful links to read. Spirent TestCenter gives you extensive access to both the data plane and control plane to invoke faults. With its flexible traffic and route generation functions, you re only limited by your creativity and knowledge of your device. Here are examples of negative tests you may run in Spirent TestCenter: Inject more routes than the device can handle, how does it react? Does most traffic follow the fast path and some follow the slow path? Does the device run out of memory? Do routing adjacencies start failing? Does the Command Line Interface (CLI) slow down? Send traffic from two different ports with the same MAC address. Some switches consider this a symptom of a spanning tree problem. The forwarding table is constantly reprogrammed with a new port. What happens? How does the switch affect other normal traffic? Does other traffic fail while the forwarding table is reprogrammed? Do you see spanning tree forcing a root re-election? Max out the switch s forwarding (CAM) table. Does it flood forward out all ports except the port the frame entered? Does it refuse to forward traffic of MAC addresses it hasn t learned? Send frames with errors in the headers or trailers. Corrupt the Frame Check Sequence (FCS). Does the device forward the corrupt traffic? What happens with a miscalculated IP total length or checksum error? Send fragments or jumbo frames without the jumbo frames feature enabled. What happens to the traffic? Perform an overnight soak test send traffic while constantly flapping routes. What happens? Do you find memory leaks? 320

322 By applying negative testing concepts, you can assure your system is adequately robust to all of these kinds of events. Negative Testing Negative testing will focus on the functional aspects of a Device Under Test (DUT). By performing these types of test methodologies, the functional operability and robustness of the DUT may be properly gauged. The negative testing methodology in this journal is listed below: Test 1 Transmission of PDUs with Errors The first test methodology validates basic DUT filtering and forwarding capability. We will set the Spirent TestCenter system to send PDUs with FCS errors. At the same time we will send error-free PDUs. In this test, we will verify the DUT discards the errored traffic while allowing the error-free traffic to pass. 321

323 Transmission of PDUs with Errors Overview This test is designed to validate basic error filtering functionality. For this test, we will use two test ports on the Spirent TestCenter platform. On one port, we will create three streams. One stream is used to represent good traffic, which will be allowed to pass. Two other streams will be used to represent corrupted traffic. The last two streams should be restricted by the Device Under Test (DUT) and discarded. Depending on capabilities, the DUT may have logging or counters showing the errors as they occur. Using the packet generator functionality, we will corrupt the frames by introducing bad Frame Check Sequence (FCS). We will use two streams to represent both types of data traffic, one stream for the good traffic and one stream for the corrupted traffic. Objective This test will show the DUT s ability to discard traffic that has FCS errors and still have the ability to forward good traffic. Setup 322

324 Step-by-Step 1. Launch Spirent TestCenter application and select the Port Reservation button. 323

325 2. In the new window, reserve the required ports and select the close button. 3. Depending on the DUT s configuration, it might be required to manually configure the port speed and duplex. Select the port form the port listing in the navigation window. 324

326 4. Select the correct Media Type and uncheck the Auto Negotiate box. This will allow for the Speed and Duplex settings to be selected. Notice on the right side it displays the currently configured settings. Also, once changes have been made the Apply button will become enabled. Press this button to make the changes take affect. Do this for the other reserved port too. 325

327 5. Expand the first port in the navigation box and select Hosts. 6. In the new screen that appears to the right select Add. 326

328 7. Depending on the DUT s configuration, it is possible to configure Hosts on each port at the same time. It is also possible to configure the Hosts on each port separately, as demonstrated in other tests. To configure Hosts on both ports at the same time select both ports and press Next. 8. The defaults are okay in this current view, press Next to continue. 327

329 9. Again, the defaults are okay, press Next. 10. Change the IP address to the correct IP for the first port. The gateway will automatically change too, though if it is not correct then make the change as needed. Select the button in the IPv4 section. This will cause a new window to be displayed. 328

330 11. Change the Step per port value and press OK. 12. Notice how the Step field in the IPv4 section has changed. Press Next to verify that each Host has been created correctly. 329

331 13. If the Preview section is correct press Finish. If it is not correct, use the Back button to make the changes or configure each host separately. 14. In the navigation window, select the Traffic Generator option under the first reserved port. 330

332 15. Select Add and then Add Bound Stream Block(s) from the drop down menu that appears. 16. The defaults are okay in the new window that appears. Press Next to continue creating a bound stream. 331

333 17. Select the first Host as the Source and the second Host as the Destination. Press the Add button; notice how it adds the Pair below. Press Next to continue with the configuration. 332

334 18. The default is okay, press the Next button to continue. 333

335 19. Change the Stream block Name prefix for each recognition later. Also, change the Load unit to Frames/Sec (FPS) and the Load value to 100. Once completed press Finish. 334

336 20. Right-click on the stream that was created and select Duplicate. 21. Leave Number of copies at 1 and press OK. This will create a single duplicate of the stream. 22. Change the Scheduling mode to Rate Based; rename the duplicated stream for easy recognition and change the Load to

337 23. Right-click on the Bad Traffic stream and select Edit. 336

338 24. Select the Insert Ethernet FCS error field and then select OK. 25. Before traffic can be started, ARP requests must be performed. Right-click on All Ports in the navigation window and select ARP/ND Start ARP/ND. Make sure all ARPs are successfully performed. If not, check the configuration of the Hosts and try again. 337

339 26. In the navigation window, right-click Traffic Generator under the first port and select Start Traffic. 27. In the Results Browser in the Port Traffic Basic Traffic Results view scroll to the right till the Generator Frame Rate is visible. Verify this has a value of about

340 28. In the right view of the Results Browser change the view to Stream Results Detailed Stream Results. 29. Verify the Rx Frame Count for the Bad Traffic stream has a value of 0. This means that the frames which are sent are being dropped by the DUT due to the FCS error. 30. To determine that nothing else is wrong with the stream that has the FCS error invoked, disable the error by editing the stream again. Once in the Stream Editor, uncheck the Insert FCS Error box and press OK. 339

341 31. Finally, hit the Apply button located near the top of the screen. This will apply the changes to the streams. 32. If all is correct, both streams should now be transmitting traffic. Other tests can also be performed. If the switch is able to handle Layer 3 traffic, IPv4 checksum errors can be injected into the traffic as well. The load on the DUT can be increased to see how the discarding of errored packets affects the DUT s performance. Though these are just a few examples, more may be possible. 340

342 Glossary A ACE. ACL. (Access Control Entries) A list of data structures containing entries that specify individual user or group rights to specific system objects, such as a program, a process or a file. (Access Control List) A method used to enforce privilege separation. It is a means of determining the appropriate access rights to a given object depending on certain aspects of the process making the request. B BPDU. C (Bridge Protocol Data Units) These are the frames that carry the needed information for the Spanning Tree Protocol (STP). CFI. (Canonical Format Indicator) denotes whether MAC addresses in the frame are in canonical (the usual or standard state) format. When 0 (off), it indicates the device should read the information in a field canonically (right-to-left or low-order bits first), which is the case for Ethernet. But for Token Ring devices that read in a non-canonical form, the value should be 1 (on). For this reason, the CFI is sometimes referred to as the Token Ring Encapsulation Flag. Class-D Address. IP addresses in the range of This range has been specifically dedicated for the use of multicast communications. CoS. (Class of Service) CoS is a queuing algorithm. The CoS algorithm looks at the CoS tags and assigns the packets to different queues depending on the priority. D DoS. DR. DSCP. (Denial of Service) An attempt at making a certain resource not available to others. (Designated Router) This term is used in several routing protocols, each of which has its own specific purpose for the DR. Internet Group Management Protocol (IGMP) and Multicast Layer Discovery (MLD) elects a DR when multiple routers are connected to a single LAN Dynamic Host Configuration Protocol (DiffServ Code Point) A field in the header of IP packets used for the classification purposes. 341

343 DUT. F FCS. (Device Under Test) A device (i.e., a switch) that will have its functionality tested. (Frame Check Sequence) The extra checksum characters added to a frame for error detection and correction. Forwarding Rate. The maximum number of frames per second the DUT/SUT can forward at various loads. I IVL. ICMP. IGMP. (Independent VLAN Learning) Used to directly associate a Medium Access Control (MAC) address to a Virtual Local Area Network (VLAN), which is considerably more secure since data cannot be forwarded between VLANs. (Internet Control Message Protocol) Used for reporting errors and troubleshooting IP networks. (Internet Group Management Protocol) An extension of the Internet Protocol (IP) used by end stations to register with multicast groups. IGMP Snooping. A method employed by some Layer 2 switches to determine the multicast group membership of their locally attached workstations. The switches do not participate in the Internet Group Management Protocol (IGMP) process; they just passively read the packets transmitted to/from the workstations and the local router. IPTV. (Internet Protocol Television) Digital television is delivered to subscribing customers using the Internet Protocol (IP) over a broadband connection. IPTV is often provided with Video on Demand (VoD) and can also include Triple Play. L LAN. (Local Area Network) A small computer network that most likely will run either switched Ethernet or Wi-Fi. Layer 2. The second layer in the OSI seven-layer model. Layer 2 is known as the Data Link Layer. This layer responds to service requests from the network layer (Layer 3) and issues service requests to the Physical Layer (Layer 1). Layer 3. The third layer of the OSI seven-layer model. This layer is also known as the Network Layer. This layer responds to service requests from the transport layer (Layer 4) and issues service requests from the Data Link Layer (Layer 2). 342

344 LHR. (Last Hop Router) The router at the end of the delivery path for multicast messages. This router sends the messages to the receivers based on their Internet Group Management Protocol (IGMP) or Multicast Listener Discovery (MLD) registration. Line Tap. A hardware device that allows for easy access to the data flowing across a computer network. M MAC. MLD. (Medium Access Control) A unique identifier attached to most pieces of networking equipment. (Multicast Listener Discovery) An IPv6 version of the Internet Group Management Protocol (IGMP) for registering IPv6 workstations with multicast groups. Multicast. A communication transmission from a single sender to a unique group of multiple receivers. N Negative Testing. Unlike typical testing where you attempt to figure out if the device is performing as expected for a given stimulus, with negative testing you are deliberately trying to find faults. This is done by sending control, management or data traffic that is out of the norms. P PIM. (Protocol Independent Multicast) A multicast forwarding protocol that uses the routers existing routing tables (derived from other protocols) to forward traffic. Q QoS. (Quality of Service) QoS is the ability of a network to meet a certain traffic contract. R RTP. (Real-time Transport Protocol) A standardized packet used for transporting voice and video over the Internet. S SLA. (Service Level Agreement) An agreement (usually a contract) between a service provider and a customer. Guarantees a certain quantitative and/or qualitative level of service. 343

345 STP. SVL. (Spanning Tree Protocol) A network protocol that provides a loop-free topology for any bridged Local Area Network (LAN). (Shared VLAN Learning) Used when necessary to allow address information learned in one Virtual Local Area Network (VLAN) to be shared among a number of other VLANs. T Throughput. The maximum load at which the DUT/SUT will forward traffic without frame loss. TOS. TPID. (Type of Service) A 1-byte field in the IP Header that defines how the datagram should be handled by the network during transportation. (Tag Protocol Identifier) Default is 0x8100 for IP, TCP and UDP frames. V VLAN ID. (Virtual Local Area Network Identifier) A 12-bit field that allows up to 4095 Virtual Local Area Networks (VLANS) per physical port. IEEE 802.1Q does not actually encapsulate the original frame. Instead, it adds an extra 4-bytes in the original Ethernet header. The EtherType is changed to 0x8100, denoting the new frame format. VLAN. (Virtual LAN) A network whose elements behave as if they are connected to the same physical LAN even though they might be located on separate physical networks. 344

346 Inspired Innovation is a worldwide provider of integrated performance analysis and service assurance systems for next-generation network technologies. Our solutions accelerate the profitable development and Performance Analysis, deployment of network equipment and services by emulating Wireless and Positioning real-world conditions in the lab and assuring end-to-end 541 Industrial Way West Eatontown, NJ USA performance of large-scale networks. SALES AND INFORMATION Spirent performance analysis solutions include instruments and systems that measure and analyze the performance of network sales-spirent@spirentcom.com equipment, particularly the devices that route voice and data messages to their destination. Our service assurance solutions include remote test, fault and performance management systems that let network service providers quickly identify network Americas T: SPIRENT faults and monitor real-time performance. Spirent s integrated performance analysis and service assurance solutions enable Europe, Middle East, Africa T: our customers to more rapidly develop and certify new devices, lowering the cost of widespread deployment and operation of new networking services. Asia Pacific T: , Inc. All of the company names and/or brand names and/or product names referred to in this document, in particular the name Spirent and its logo device, are either registered trademarks or trademarks pending registration in accordance with relevant national laws. All rights reserved. Specifications subject to change without notice. P/N