The subject matter described herein relates to testing network equipment. More particularly, the subject matter described herein relates to methods, systems, and computer readable media for providing for specification or autodiscovery of DUT topology information.
In network lab testing environments, network equipment test devices are connected to single or multiple devices under test (DUTs). The network equipment test devices send packets to the DUTs, receive packet from the DUTs, and generate statistics based on the received packets.
Currently, network equipment test devices allow topology information to be specified about the network equipment test devices themselves. However, DUTs are treated as a black box by current network equipment test devices. That is, current network equipment test devices do not allow the specification of topology information associated with DUTs. Accordingly, the test administrator is required to manually interpret received packets statistics to identify configuration errors associated with DUTs. In light of the voluminous nature of network test data, such manual interpretation is undesirable.
Accordingly, there exists a need for methods, systems, and computer readable media for providing for specification or autodiscovery of DUT topology information.
The subject matter described herein includes methods, systems, and computer readable media for providing for specification or autodiscovery of DUT topology information and for using the DUT topology information to generate DUT-topology-specific test results. One exemplary method includes providing for specification or autodiscovery of DUT topology information associated with or more devices under test (DUT). The method further includes transmitting test packets to the at least one DUT. The method further includes receiving packets transmitted from or through the at least one DUT. The method further includes using the DUT topology information and the received packets to generate DUT-topology-specific test results. In one example, the DUT-topology-specific test results are displayed to the user. According to another aspect, DUT-topology-specific test results may be used to reconfigure test cases or generate new test cases for testing one or more devices under test.
The subject matter described herein can be implemented in software in combination with hardware and/or firmware. For example, the subject matter described herein can be implemented in software executed by a processor. In one exemplary implementation, the subject matter described herein can be implemented using a non-transitory computer readable medium having stored thereon computer executable instructions that when executed by the processor of a computer control the computer to perform steps. Exemplary computer readable media suitable for implementing the subject matter described herein include non-transitory computer-readable media, such as disk memory devices, chip memory devices, programmable logic devices, and application specific integrated circuits. In addition, a computer readable medium that implements the subject matter described herein may be located on a single device or computing platform or may be distributed across multiple devices or computing platforms.
The subject matter described herein will now be explained with reference to the accompanying drawings of which:
The subject matter described herein relates to methods, systems, and computer readable media for specifying and utilizing DUT topology information.
Once DUT topology information has been specified, either through user input or autodiscovery and the user starts a test, a test packet generator 103 generates and sends test packets to DUTs 101 based on test cases 104. Because DUT topology information has been specified, when packets are received by received packet processor 108, the topology information can be used to generate DUT-topology-specific test results from the received packets. Examples of DUT-topology-specific test results include DUT coverage by a test, link coverage by a test, and packet statistics on a per link and/or per DUT basis. The DUT-topology-specific test results may also be used to generate new test cases and/or reconfigure existing test cases. For example, if a test indicates that a particular DUT in the DUT topology fails to forward packets, additional test cases may be created for this DUT.
As described above, once DUT topology information is specified, the DUT topology information can be used to visualize and/or analyze test results. For example, test packet generator 103 may transmit test packets to a device under test. Received packet processor 108 may receive packets from the device under test and determine, using the stored topology information, which links between the devices under test were covered by the test. Received packet processor 108 may generate a diagram, similar to that illustrated in
In another example, as illustrated in
As stated above, received packet processor 108 may utilize the DUT topology information to generate DUT-topology-specific test results.
Returning to
In another example of DUT-topology-specific test results, received packet processor 108 may generate latency graphs as a function of location in the DUT topology. For example, a latency graph may be generated showing the average latency on each link 214, 216, 218, 220, 224, and 226 illustrated in
As stated above, the DUT-topology-specific test results may be used to generate new test cases or update existing test cases. Such generation may be performed dynamically by received packet processor 108 during a test or statically by a test administrator using the interface provided by DUT topology specifier 102 after viewing DUT-topology-specific test results. In the automated case, received packet processor 108 may determine that a particular test is not covering all of the DUTs in the topology and may modify the test during execution of the test to send packets to the DUT that was initially not covered by the test. Such a modification may also be performed manually by the test administrator after viewing test results. In another example, if the test results indicate that a particular device under test is causing packet loss for packets over a certain size, received packet processor 108 may reduce the packet size of packets sent to the DUT until the packets pass the DUT.
In another example, if the DUT-topology-specific test results indicate that all packets are being transmitted over one link but no packets are being transmitted over another link through which packets are expected to be transmitted, it may be desirable to review the cabling between the network equipment test devices and the devices under test to determine whether a cable misconfiguration has occurred before running subsequent tests.
In step 504, packets are received from the device under test. The packets may be packets that were transmitted by or through the devices under test. In step 506, the method includes generating DUT-topology-specific information from the test results. An example of such information is illustrated in
Although in the examples above, packets are described as being received from the DUTs, it is understood that packets transmitted from or through the DUTs could be collected by network taps, such as the network taps illustrated in
OUT topology specifier may reside in whole or in part on an administrative terminal that has access to the network equipment test device to configure its test cases and/or interpret test results.
It will be understood that various details of the presently disclosed subject matter may be changed without departing from the scope of the presently disclosed subject matter. Furthermore, the foregoing description is for the purpose of illustration only, and not for the purpose of limitation.
Number | Name | Date | Kind |
---|---|---|---|
5263029 | Wicklund, Jr. | Nov 1993 | A |
5757820 | Angelotti | May 1998 | A |
6122753 | Masuo et al. | Sep 2000 | A |
6321356 | Snodgrass et al. | Nov 2001 | B1 |
6513138 | Ohsawa | Jan 2003 | B1 |
7154860 | Nanba | Dec 2006 | B1 |
7221912 | Nelson et al. | May 2007 | B2 |
7272765 | Ichiyoshi | Sep 2007 | B2 |
7370236 | Szucs et al. | May 2008 | B2 |
7590903 | Volkerink et al. | Sep 2009 | B2 |
8086660 | Smith | Dec 2011 | B2 |
8255749 | Swoboda | Aug 2012 | B2 |
8826088 | Swoboda | Sep 2014 | B2 |
20020093961 | Sharma et al. | Jul 2002 | A1 |
20030043745 | Kano et al. | Mar 2003 | A1 |
20030140279 | Szucs et al. | Jul 2003 | A1 |
20060159033 | Suzuki et al. | Jul 2006 | A1 |
20060268944 | Xu | Nov 2006 | A1 |
20070291650 | Ormazabal | Dec 2007 | A1 |
20080162994 | Szucs et al. | Jul 2008 | A1 |
20080198768 | Nanjundaswamy et al. | Aug 2008 | A1 |
20090222694 | Adir et al. | Sep 2009 | A1 |
20090303880 | Maltz | Dec 2009 | A1 |
20100058457 | Ormazabal | Mar 2010 | A1 |
20100110883 | Russell et al. | May 2010 | A1 |
20100204948 | Kirrmann et al. | Aug 2010 | A1 |
20110305168 | Koide | Dec 2011 | A1 |
20130173940 | Sargent et al. | Jul 2013 | A1 |
20130311646 | Nikaido et al. | Nov 2013 | A1 |
20140098824 | Edmiston | Apr 2014 | A1 |
20140115421 | Cai | Apr 2014 | A1 |
20140269386 | Chu et al. | Sep 2014 | A1 |
20140269390 | Ciodaru et al. | Sep 2014 | A1 |
20150003259 | Gao | Jan 2015 | A1 |
20150106670 | Gintis | Apr 2015 | A1 |
Entry |
---|
Poretsky et al., Benchmarking Methodology for Link-State IGP Data Plane Route Convergence, May 10, 2010, Network Working Group, pp. 1-28. |
Han et al., Star Topology Test Architecture for Multi-site Testing, Jun. 27, 2012 , IEEE, pp. 1-5. |
Commonly-assigned, co-pending U.S. Appl. No. 14/452,205 for “Methods, Systems, and Computer Readable Media for Providing User Interfaces for Specification of System Under Test (SUT) and Network Tap Topology and for Presenting Topology Specific Test Results,” (Unpublished, filed Aug. 5, 2014). |
Number | Date | Country | |
---|---|---|---|
20150106669 A1 | Apr 2015 | US |