Part of the challenge for solution providers as they build new LANs or even extend existing ones is making sure that switches in the system are interoperable. After all, traffic flows between these switches, which ultimately share the workload. The problem is that many LAN switches aren't interoperable and therefore can't effectively pull off the job. That can even be the case for switches of various models from the same vendor.
So testing must be done in order to ensure interoperability. But this testing can be complex, and it varies depending on the specific needs of the LAN in question.
LAN switches interoperate at many levels. At the simplest level, those that communicate directly via copper or fiber connections need to agree on port speed and other important characteristics. Higher up in the protocol stack, switches must not, for example, lose or corrupt header information associated with virtual LANs or quality of service (QoS). At layer 3, the switches must accurately store and replicate routing table updates or run the risk of hindering connectivity in the larger corporate network.
So as part of the LAN switch interoperability guide -- a kind of cookbook for testing -- the Tolly Group has identified nearly 20 functions in LAN switches to test for interoperability. Among the functions tested are 10 Gigabit Ethernet PHY support, IP routing, and Multiprotocol Label Switching (MPLS).
These tests are not based on any one vendor's switch
The LAN switch interoperability test cookbook is part of the "Tolly Common RFP" series, a collection of detailed test plans designed to help validate feature/function and performance characteristics of information technology products and solutions. Among the topics covered in the series are application switches, virtual server performance, and LAN switch and VoIP system power consumption.
Here is an excerpt of the LAN switch interoperability testing guide that will include the following three testing functions: IEEE 802.1p/Q VLAN Tag Propagation, Rapid Spanning Tree Protocol (IEEE 802.1w), RIPng.
IEEE 802.1p/Q VLAN Tag Propagation
This test will verify that when a VLAN tag and priority frame is introduced, the switch forwards the packet appropriately, without modification to the frame.
The two switches will be configured for 802.1p/Q. Using a traffic generator (test tool), generate a stream of 100 1,518-byte VLAN tagged frames with desired VLAN IDs and priority values destined for the remote switch. A network sniffing software like Wireshark is used to capture the VLAN tagged frames inputted to the first switch, and outputted from the second switch to verify the presence of the VLAN tag. The test tool will count all frames received maintaining the 802.1p/Q VLAN tags. The test will then be repeated running in the reverse direction initiating traffic from the original receiving network.
Rapid Spanning Tree Protocol (IEEE 802.1w)
If the switch supports Rapid Spanning Tree Protocol (IEEE 802.1w), construct a small, multi-switch network composed of a pair of switches -- one from each switch model. The participants will then demonstrate that any convergence acceleration mechanisms work correctly between the switches.
The switches will be configured and then connected as shown above. Generate test traffic consisting of 64-byte frames at 10,000 frames per second in both directions, and verify that traffic can pass successfully. The management console of each switch is verified to determine the active link carrying the test traffic between the switches. Then fail the active link and verify that the traffic resumes on the other link after a certain duration known as convergence time. The convergence time in seconds is calculated by dividing the number of frames lost during failover with 10,000. (End stations will be configured for the same IP network.)
This test will verify that the switches exchange routing table information via RIPng and verify successful forwarding of traffic to the correct destination.
The switches under test will be configured for RIPng and no static routes. The interface connected to the "common" network (i.e., the network across which the devices will connect to one another) will be configured for an IPv6 address of 2001:xyff::1/64 (where the value "xy" will be assigned to be specific to each switch under test as shown in Table 1.) The interface connected to the "private" network will be configured for an IPv6 address of 2001:ffff::1/64 (where "xy" is the device specific value assigned to each switch under test).
Testers will confirm that each switch shows appropriate routing information in its IP routing table. Send IP traffic between disjoint IP subnets using the traffic generator's test ports, and make sure that the switches under test forward the traffic to the correct destination.
To read more of the Tolly Group's LAN Switch Interoperability RFP, or to learn more about the Tolly Common RFP project click here.
This was first published in April 2009