The ExtremeXOS Service verification tool (ESVT) tests traffic throughput between two Extreme Network switches without having to use a traffic generator. Typical Service Verification Test Tool Environment shows a typical service verification test tool environment:
In this example, you have an Extreme Networks switch DUT1 installed at a customer location, and customer service is defined to be from the antenna to the Extreme Networks switch DUT2 (and possibly beyond the DUT2). You can use the service verification test tool to test the portion of the service between the DUT1 and the DUT2. The connection between the antenna and the DUT1 is not covered by the test tool. Additionally, any continuation of the service beyond the DUT2 is not included in the test.
Prior to beginning the test, you must provision the part of the network to be tested by the service verification test tool. This includes the VLAN (Virtual LAN) (tagged or untagged on port 9) on the DUT1, any L2 devices in the path through the network, and the VLAN (tagged or untagged on port 3) at the DUT2. Additionally, any L2/L3 protocol packets created in the CPU on any of the above devices, and sent over the same VLAN as the service being verified, will create errors in the test results. All L2/L3 protocols for the service VLAN must be disabled unless specifically included in the test tool instructions.
The most straightforward mode of operation is for the DUT1 to generate sufficient test packets to fill the allocated bandwidth of the service going towards the DUT2. The DUT1 counts the test packets sent towards the DUT2. On the DUT2, the simplest mode of operation is to wrap the received test packets back to the DUT1 using the reverse path of the service connection. The DUT1 counts the received test packets. At the conclusion of the test, the DUT1 displays the total number of test packets sent and received.
As line rate test traffic cannot be generated by the CPU in the DUT1, generating test packets must make use of some hardware resources. You can form an internal loop by placing a single port into loopback mode. You can generate line rate traffic by placing a test packet into this loop. You can then use a metered (internal) connection to the service VLAN to send test packets into the service under test at the desired bandwidth. You can assign a loopback port using a CLI command that will mimic the QOS of egress port (port 9).
At the DUT2, it is best to update the source MAC address of the test packets as they are forwarded back to the DUT1. This prevents MAC learning problems in any L2 devices between the DUT1 and the DUT2 that might be caused by learning the same source MAC address on two different ports. By making a L3 forwarding decision at the DUT2, the source MAC address of the test packets is modified to be that of the DUT2.
To make an L3 forwarding decision at the DUT2, the destination MAC address of the test packets must be the address of the DUT2.The destination IP address lookup on the DUT2 must point to an IP next hop that is the DUT1. The DUT1 will also modify the destination MAC address of the test packets to be that of the DUT1.
To make the test as simple as possible, you should assign IP addresses to the service VLAN interfaces at the DUT1 and the DUT2. These IP addresses should be from private IP address space, and should be in the same IP subnet. For example, you could assign 15.15.15.14/24 to the DUT1 and 15.15.15.15/24 to the DUT2. These temporary IP addresses should be unconfigured as soon as the service verification test is completed.
Note
The service being verified is an L2 service only. The test network must not cross L2 boundaries.The Service Verification Tool is supported on the following platforms: Summit X450-G2, X460-G2, X670-G2, X770, ExtremeSwitching X440-G2, X620, Stacking.
Print
this page
Email this topic
Feedback
View PDF
Download EPUB