The subject matter described herein testing network devices. More particularly, the subject matter described herein relates to methods, systems, and computer readable media for misdirected packet drill down and negative packet capture at a network test device.
Network test devices test the functionality of network devices, such as routers, switches, firewalls, and network address translators, by sending test packets to the network devices and monitoring the responses. For example, in order to test whether the routing tables of a router are properly configured, a network test device may generate packets, send the packets to the router, and monitor one or more output ports of the router to determine whether the packets are routed to the proper destinations. In a load testing scenario, the network test device may send packets to the router at a high data rate to see how the router's performance is affected by increased traffic loads.
In these and other test scenarios, it is desirable for the network test device to detect lost and misdirected packets. Misdirected test packets are test packets that are transmitted to the device under test that are received by the network test device at a port other than the expected receive port of the device under test. Lost packets are test packets that are transmitted to the device under test but that are not returned to the network test device. Packets may be lost or misdirected for a variety of reasons, including misconfiguration of the device under test, misconfiguration of the test setup, hardware or software defects in the device under test, etc. For both lost and misdirected packets, it is desirable to provide the test system operator with as much information as possible so that the operator can determine the cause of lost and misdirected packets.
Accordingly, in light of these difficulties, a need exists for improved methods, systems, and computer readable media for misdirected packet drill down and negative packet capture at a network test device.
Methods, systems, and computer readable media for misdirected packet drill down and negative packet capture at a network test device are disclosed. One exemplary method includes, at a network test device, receiving and storing, in the network test device, expected receive port information regarding a plurality of test packets. The method further includes transmitting the test packets to a device under test. The method further includes receiving at least some of the test packets from the device under test. The method further includes using the expected receive port information and the received test packets to identify misdirected test packets. The method further includes, for each of the packets identified as misdirected, determining a port of the network test device at which the packet should have been received and outputting an indication of the port of the network test device at which the packet should have been received.
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 executable instructions that when executed by the processor of a computer control the processor to perform steps. Exemplary non-transitory computer readable media suitable for implementing the subject matter described herein include chip memory devices or disk memory devices accessible by a processor, 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 computing platform or may be distributed across plural computing platforms.
The subject matter described herein will now be explained with reference to the accompanying drawings of which:
Methods, systems, and computer readable media for misdirected packet drill down and negative packet capture at a network test device are disclosed.
In the illustrated example, network test device 100 includes a plurality of port units 104 that transmit packets to device under test 102 and receive packets from device under test 102 via ports 106. Each port unit 104 may be implemented as all or part of a printed circuit board mounted in a chassis. In the illustrated example, each port unit 104 includes a test packet generator 108, memory 110, a test packet receiver 112, and a port processor 114. Test packet generator 108 of each port unit generates test packets to be transmitted to device under test 102. Test packet receiver 112 receives packets from device under test 102 and generates statistics for the received packets. Memory 110 stores both configuration information for test packet generator 108 and test packet receiver 112 and also stores the generated statistics and any other information needed or collected by port unit 104. Port processor 114 controls the overall operation of each port unit 104. In addition, each port processor 114 may communicate with a control processor 116 over a backplane 118. Control processor 116 may control the overall operation of network test device 100. Control processor 116 may also control communications between admin terminal 120 and port processors 114. Admin terminal 120 may be a general purpose computer through which a test system operator configures network test device 100 and views output generated by network test device 100.
Network test device 100 further includes an expected receive port configuration function 122 and a lost or misdirected packet drill down function 124. Expected receive port configuration function 122 may perform operations that enable a user to configure each port unit 108 with information regarding the expected receive port for each transmitted packet. In one exemplary implementation, expected receive port configuration function 122 allows the user to configure, for each port unit, packet group identifier values (PGIDs) to be inserted in each packet and PGIDs that are expected to be received by each port unit 104. A PGID is an identifier for a packet group. The packet group is any plurality of packets for which network statistics are generated. In one implementation, the PGID is a 20-bit value stored in the packet payload. However, any number of bits that corresponds to addresses and available memory space of port units 104 may be used without departing from the scope of the subject matter described herein.
In one exemplary implementation, each port unit 104 may support 20-bit PGID values. That is, in hexadecimal, the complete range of PGID values supported by port units 104 is 0x00000-0xFFFFF. In a simplified example, it can be assumed that ranges of PGID values are divided equally between port units 104. In such an example, a first port unit 104 may support PGIDs ranging from 0x00000-0x3FFFF. A second port unit 104 may support PGID values 0x40000-0x7FFFF. A third port unit 104 may support PGID values 0x80000-0xBFFFF. A fourth port until 104 may support PGID values ranging from 0xC0000-0xFFFFF. These ranges are illustrated in
Although ranges of PGID values are assigned to each port unit 104 in the example illustrated in
Thus, when a packet is transmitted by one of port units 104 to device under test 102, the packet may be returned by device under test 102 to the same port 106, to a different port 106 from which the packet was transmitted, or the packet may be lost. If the test packet is received by network test device 100, upon receipt of the test packet, test packet receiver 112 will compare the PGID value in the packet to the range of PGID values associated with its respective port. If the PGID value is in range, test packet receiver 112 will classify the packet as a correctly received packet. If the PGID value is out of range, test packet receiver 112 will classify the packet as a misdirected packet.
In the example illustrated in
In addition to identifying misdirected packets, lost or misdirected packet drill down function 124 identifies lost packets and displays lost packets to the user via a capture interface. A capture interface is a graphical interface that displays information regarding received or captured packets to a user. Examples of packet fields that may be displayed in the packet capture interface will be provided below. However, rather than displaying these fields for received or captured packets, lost or misdirected packet drill down function may display these fields for lost packets.
To identify lost packets, lost or misdirected packet drill down function 124 may keep a record of each packet transmitted by each test packet generator 108 in a given test. Such records may be kept in memory 110 resident on each port unit 104 or in a memory separate from port units 104 and accessible by lost or misdirected packet drill down function 124. Lost or misdirected packet drill down function 124 may periodically access memories 110 to determine which test packets have been received. For each received test packet, lost or misdirected packet drill down function 124 may mark the corresponding entry in memory to indicate that the test packet has been received. Lost or misdirected packet drill down function 124 may maintain a timer for each entry. If the timer expires before a transmitted test packet is received, the packet may be identified as a lost packet. In an alternate implementation, lost or misdirected packet drill down function 124 may detect lost packets without using timers. For example, lost or misdirected drill down function 124 may identify lost packets using sequence number errors. If the sequence number in a given received packet or in an acknowledgement of a transmitted packet is not equal to the next expected sequence number, a lost packet may be indicated. Lost packets may be presented to the user by a capture interface on admin terminal 120, which will be described in more detail below.
In step 202, test packets are generated. The test packets may have different sized payloads to test the functionality of device under test 102 in processing packets of different sizes. In another example, the test packets may carry payloads of different applications to see how device under test 102 responds to packets for different applications. In step 204, the test packets are transmitted to the device under test. In one example, network test device 100 may transmit the test packets to device under test 102 at line rate to stress test device under test 102.
In step 206, at least some of the transmitted packets are received from the device under test. The packets may be received on various ports 106, depending on how device under test 102 is configured. Some of the transmitted packets may be lost or misdirected based on misconfiguration, defects, or poor performance of device under test 102.
In step 208, the expected receive port identification information is used to identify misdirected packets. As described above, the PGID value in each received packet may be compared with the PGID values associated with the port on which the packet is received. If the PGID value in the packet is within the range of PGID values for the port on which the packet is received, the packet may be identified as a correctly received packet. If the PGID value in the packet is out of range for the port on which the packet is received, the packet may be identified as misdirected.
In step 210, additional information regarding misdirected packets is determined and presented to the user. In one example, the additional information determined for each misdirected packet may include the port on which the packet was actually received and the port on which the misdirected packet should have been received. To determine the port on which a misdirected packet should have been received, the PGID value in the packet may be compared against the PGID values of the remaining ports of network test device 100. If the PGID value matches one of the ranges of PGID values for the remaining ports, that port may be identified as the port on which the misdirected packet should have been received. The information associated with the port on which the packet should have been received and the port on which the packet is received may be presented to the user.
Returning to
It will be understood that various details of the subject matter described herein may be changed without departing from the scope of the subject matter described herein. Furthermore, the foregoing description is for the purpose of illustration only, and not for the purpose of limitation, as the subject matter described herein is defined by the claims as set forth hereinafter.
Number | Name | Date | Kind |
---|---|---|---|
5343463 | van Tetering et al. | Aug 1994 | A |
5477531 | McKee et al. | Dec 1995 | A |
5600632 | Schulman | Feb 1997 | A |
5742760 | Picazo, Jr. et al. | Apr 1998 | A |
5787253 | McCreery et al. | Jul 1998 | A |
5850386 | Anderson et al. | Dec 1998 | A |
5878032 | Mirek et al. | Mar 1999 | A |
5982753 | Pendleton et al. | Nov 1999 | A |
6028847 | Beanland | Feb 2000 | A |
6041053 | Douceur et al. | Mar 2000 | A |
6065053 | Nouri et al. | May 2000 | A |
6088777 | Sorber | Jul 2000 | A |
6172989 | Yanagihara et al. | Jan 2001 | B1 |
6252891 | Perches | Jun 2001 | B1 |
6295557 | Foss et al. | Sep 2001 | B1 |
6360332 | Weinberg et al. | Mar 2002 | B1 |
6389532 | Gupta et al. | May 2002 | B1 |
6446121 | Shah et al. | Sep 2002 | B1 |
6545979 | Poulin | Apr 2003 | B1 |
6601098 | Case et al. | Jul 2003 | B1 |
6717917 | Weissberger et al. | Apr 2004 | B1 |
6728929 | Luong | Apr 2004 | B1 |
6789100 | Nemirovsky et al. | Sep 2004 | B2 |
6820034 | Hanes et al. | Nov 2004 | B2 |
6823219 | Lee et al. | Nov 2004 | B2 |
6888818 | Gubbi | May 2005 | B1 |
6910061 | Hu et al. | Jun 2005 | B2 |
6950405 | Van Gerrevink | Sep 2005 | B2 |
7007089 | Freedman | Feb 2006 | B2 |
7035223 | Burchfiel et al. | Apr 2006 | B1 |
7187683 | Sandoval et al. | Mar 2007 | B1 |
7406089 | Rahim et al. | Jul 2008 | B1 |
7443870 | Zioulas et al. | Oct 2008 | B2 |
7489706 | Hatley et al. | Feb 2009 | B2 |
7561559 | Hannel et al. | Jul 2009 | B2 |
7594159 | Fujikami et al. | Sep 2009 | B2 |
7643431 | Pepper | Jan 2010 | B2 |
7826377 | Pepper | Nov 2010 | B2 |
7826381 | Kastuar et al. | Nov 2010 | B1 |
8248926 | Bockwoldt et al. | Aug 2012 | B2 |
8310942 | Gintis et al. | Nov 2012 | B2 |
8391157 | Ginsberg et al. | Mar 2013 | B2 |
8582466 | Gintis et al. | Nov 2013 | B2 |
9094336 | Gintis | Jul 2015 | B2 |
20010016867 | Hu et al. | Aug 2001 | A1 |
20020183969 | Hanes et al. | Dec 2002 | A1 |
20030033025 | Lee et al. | Feb 2003 | A1 |
20040052259 | Garcia et al. | Mar 2004 | A1 |
20040252686 | Hooper et al. | Dec 2004 | A1 |
20050068891 | Arsikere et al. | Mar 2005 | A1 |
20050086336 | Haber | Apr 2005 | A1 |
20050286564 | Hatley et al. | Dec 2005 | A1 |
20060088060 | Fujikami et al. | Apr 2006 | A1 |
20060153078 | Yasui | Jul 2006 | A1 |
20070115833 | Pepper et al. | May 2007 | A1 |
20070291654 | Pepper | Dec 2007 | A1 |
20080112332 | Pepper | May 2008 | A1 |
20080181123 | Huang et al. | Jul 2008 | A1 |
20080198754 | Savoor et al. | Aug 2008 | A1 |
20090147671 | Jaworski et al. | Jun 2009 | A1 |
20090161559 | Bielig et al. | Jun 2009 | A1 |
20090175180 | Yang et al. | Jul 2009 | A1 |
20090310491 | Ginsberg et al. | Dec 2009 | A1 |
20100034100 | Beyers | Feb 2010 | A1 |
20100036939 | Yang et al. | Feb 2010 | A1 |
20100095160 | Dickens et al. | Apr 2010 | A1 |
20110069620 | Gintis et al. | Mar 2011 | A1 |
20110069626 | Sun et al. | Mar 2011 | A1 |
20110279138 | Mutnury et al. | Nov 2011 | A1 |
20110280137 | Bockwoldt et al. | Nov 2011 | A1 |
20120051234 | Gintis et al. | Mar 2012 | A1 |
20130064125 | Gintis et al. | Mar 2013 | A1 |
20130111535 | Howe et al. | May 2013 | A1 |
20130329572 | Gintis | Dec 2013 | A1 |
20140269347 | Gintis | Sep 2014 | A1 |
Number | Date | Country |
---|---|---|
2012-113371 | Jun 2012 | JP |
WO 2014149573 | Sep 2014 | WO |
Entry |
---|
Torrents, “Open Source Traffic Analyzer,” 2010, KTH Information Communication Technology. |
Ixia, “Border Gateway Protocol (BGP) Conformance and Performance Testing Sample Test Plans,” 2004, Ixia. |
Non-Final Office Action for U.S. Appl. No. 13/847,477 (Sep. 23, 2014). |
Notification of Transmittal of the International Search Report and the Written Opinion of the International Searching Authority, or the Declaration for International Application No. PCT/US2014/019690 (Jun. 17, 2014). |
Notice of Allowance and Fee(s) Due for U.S. Appl. No. 13/672,335 (Sep. 12, 2013). |
Notice of Allowance and Fee(s) Due for U.S. Appl. No. 12/870,729 (Aug. 31, 2012). |
Non-Final Office Action for U.S. Appl. No. 12/870,729 (Jul. 2, 2012). |
Extended European Search Report for European Application No. 11008066.0 (Feb. 10, 2012). |
Sadasivan et al., “Architecture for IP Flow Information Export,” Network Working Group, RFC 5470, pp. 1-31 (Mar. 2009). |
“IxExplorer User's Guide,” Revision 2.1.0, Ixia, pp. 1-384 (Nov. 1, 1999). |
Brownlee et al., “Traffic Flow Measurement: Architecture,” Network Working Group, RFC 2722, pp. 1-49 (Oct. 1999). |
“The Ixia 200 Traffic Generator and Analyzer,” Product Description, Ixia, pp. 1-2 (Copyright 1997-1999). |
“Load Modules—Multilayer Gigabit Ethernet for LM1000LX, LM1000SX, LM1000GBIC, & LM1000T,” Product Specification Sheet, Ixia, pp. 1-2 (Publication Date Unknown). |
“Ixia 200 Chassis,” Product Description, Ixia, p. 1 (Publication Date Unknown). |
Extended European Search Report for European Application No. 14002802.8 (Feb. 26, 2015). |
Notice of Allowance and Fee(s) Due for U.S. Appl. No. 13/847,477 (Feb. 23, 2015). |
Non-Final Office Action for U.S. Appl. No. 13/965,037 (Apr. 24, 2015). |
Number | Date | Country | |
---|---|---|---|
20140269337 A1 | Sep 2014 | US |