Patent Application
20080101225
When a customer experiences a problem with a local network, the customer often contacts technical support personnel for assistance in diagnosing and remedying the problem. In such a situation, the support technician will normally need detailed information as to what packets are being transmitted and received by the components of the network, such as by one or more of the network switches.
Information as to what packets are being transmitted and received by a switch can be obtained by using an independent packet capture device. In particular, such a device can be physically connected to a mirror port of the switch to collect packets transmitted and received by the switch. Often, the packet capture device is configured to decode the machine-language packets into a human-readable form. The decoded information can provide an indication as to what is happening on the network and therefore may reveal the source of the problem.
One disadvantage of the above method is that it requires the customer to physically access the switch that may comprise the troubled link of the network. This can be difficult for the customer in cases in which the switch is positioned in a remote location or a location that is, for one reason or another difficult to access. Furthermore, that method presumes that the customer possesses an appropriate packet capture device that is configured to collect the packets. Moreover, even assuming that the customer possesses a packet capture device, the customer must possess the requisite level of expertise to configure the mirror port if not already configured, use the packet capture device, and then share the human-readable information obtained from the device with the support technician.
Disclosed are systems and methods for capturing network packets. In one embodiment, a method includes transmitting packets from and receiving packets with a network switch, and copying transmitted and received packets to a packet repository within memory of the network switch such that the packets are stored on the switch and available for later retrieval.
The components in the drawings are not necessarily to scale, emphasis instead being placed upon clearly illustrating the principles of the present disclosure. In the drawings, like reference numerals designate corresponding parts throughout the several views.
As described above, current methods for capturing network packets can be difficult for customers to perform, especially for those customers that lack computer network expertise. As described below, however, network packet capture can be simplified through automatic capture and storage of network packets on the switches of the network. Once the packets are so stored, they can be retrieved through an appropriate file transfer process, and then forwarded to a support technician, if necessary. Accordingly, network problems can be diagnosed and remedied without the need to physically access a network switch and capture packet data with an independent packet capture device.
Referring now to the drawings, in which like numerals indicate corresponding parts throughout the several views,
The network switches 104 are configured to bridge network segments and, in the example of
The processing device 200 can comprise a microprocessor that is configured to execute instructions stored in memory 202 of the switch 104. Alternatively, the processing unit 200 can include one or more application specific integrated circuits (ASICs). The memory 202 comprises one or more nonvolatile memory elements, such as solid-state memory elements (e.g., flash memory elements). Although nonvolatile memory elements have been specifically identified, the memory 202 can further or alternatively comprise volatile memory.
The various ports 1-n are used to transmit packet data from the switch 104 and receive packet data from other devices, such as the client devices 102 in
As further indicated in
The processing device 300 can include a central processing unit (CPU) or a semiconductor-based microprocessor. The memory 302 includes any one of a combination of volatile memory elements (e.g., RAM) and nonvolatile memory elements (e.g., hard disk, ROM, tape, etc.).
The user interface 304 comprises the components with which a user interacts with the computer 106. The user interface 304 may comprise, for example, a keyboard, mouse, and a display, such as a cathode ray tube (CRT) or liquid crystal display (LCD) monitor. The one or more I/O devices 306 are adapted to facilitate communications with other devices and may include one or more communication components, such as a wireless (e.g., radio frequency (RF)) transceiver, a network card, etc.
The memory 302 comprises various programs including an operating system 310, one or more user applications 312, and a file transfer mechanism 314. The operating system 310 controls the execution of other programs and provides scheduling, input-output control, file and data management, memory management, and communication control and related services. The user applications 312 can comprise substantially any application that executes on the computer 106, for example one or more of a word processing application, a spreadsheet application, an Internet browser, and the like. As described in greater detail in relation to
Various programs (i.e. logic) have been described herein. The programs can be stored on any computer-readable medium for use by or in connection with any computer-related system or method. In the context of this document, a computer-readable medium is an electronic, magnetic, optical, or other physical device or means that contains or stores a computer program for use by or in connection with a computer-related system or method. These programs can be embodied in any computer-readable medium for use by or in connection with an instruction execution system, apparatus, or device, such as a computer-based system, processor-containing system, or other system that can fetch the instructions from the instruction execution system, apparatus, or device and execute the instructions.
Example systems having been described above, operation of the systems will now be discussed. In the discussions that follow, flow diagrams are provided. Process steps or blocks in the flow diagrams may represent modules, segments, or portions of code that include one or more executable instructions for implementing specific logical functions or steps in the process. Although particular example process steps are described, alternative implementations are feasible. Moreover, steps may be executed out of order from that shown or discussed, including substantially concurrently or in reverse order, depending on the functionality involved.
In addition to the above-described configuration, the packet collector can be configured to manage the switch's packet repository in which packets will be stored. Such management can include the deletion of packets to clear space for new packets to be stored. Various rules or other criteria can be used to determine which packets to delete and which to retain. In some embodiments, packets can be deleted in a first-in-first-out (FIFO) scheme such that the oldest packets in the repository are deleted first. In other embodiments, packets can be deleted in relation to policies specified by one or more of the access control lists. In still other embodiments, deletion may not be performed at all. For example, the packet collector can be configured to simply fill the packet repository and then halt further storage of packets until such time when the repository is cleared, for example by a command input by a network administrator.
Once the packet collector has been configured, it can receive packets, as indicated in block 502. With reference to block 504, the packet collector can, optionally, filter the packets according to its configuration. The packet collector can then store any packets that were not filtered out in the packet repository, as indicated in block 506. In some embodiments, entire packets are stored. In other embodiments, packet “slicing” is performed such that only portions of the packets are stored, to improve space utilization. In some embodiments, the repository simply comprises a file in which the packet information is stored. In other embodiments, the repository comprises a directory of separate files, for example, each file pertaining to a different packet type.
Turning to decision block 508, the packet collector can determine if the packet repository capacity has been reached. For example, it can be determined whether the packet repository or switch memory is actually full, or whether the repository or switch memory is at or near a maximum permissible fill level. In such a case, it may not be possible to store further packets in the packet repository. If the packet repository capacity has not been reached, flow returns to blocks 502-506 at which further packets are received and stored in the manner described above. However, if the packet repository capacity has been reached, the packet collector determines whether to delete packets, as indicated in decision block 510. If the packet collector has been configured not to delete packets, flow for the packet capture session is terminated and no further packets are stored. If, on the other hand, the packet collector has been configured to delete packets, flow continues to block 512 at which the packet collector deletes packets from the packet repository according to policies specified by the packet collector configuration. Once such deletion has been performed, new storage space will be available in the packet repository and, therefore, flow can again return to blocks 502-506 at which new packets can be received and stored.
As mentioned above, packets stored on a switch can be retrieved using a file transfer mechanism that, for example, executes on a client computer that is connected to the network. For instance, if a problem occurs on the network, packets can be retrieved from one or more of the network switches to investigate the source of the problem. Optionally, however, the retrieval process can be automated for the user (e.g., network administrator). For example, packet retrieval can be automatically performed on a periodic basis. In such a case, the packets that are retrieved from the switch can be deleted from switch memory. Assuming that the device that retrieved the packets (e.g., client computer) has greater storage capacity than the switch, a longer history of packet traffic can be archived. The period for packet retrieval in such an embodiment can be configurable to suit the particular environment of the customer's network. For example, if a first customer's switch handles a relatively large number of packets and a second customer's switch handles a relatively small number of packets, the frequency of packet retrieval may be greater for the first customer as compared to the second customer.
In other embodiments, the packet collector can be configured to automatically transmit stored packets to the client computer or another storage device when its associated packet repository nears capacity or contains a maximum permissible amount of data. In such a case, “retrieval” actually comprises intermittent receipt by the client computer of packets. In yet another embodiment, the packet collector can signal the client computer that its packet repository is nearing capacity to indicate that packet retrieval is necessary to avoid packet deletion or continue storage of new packets.
As can be appreciated from the foregoing, packet capture from network switches can be greatly simplified by storing the packets on the switch and retrieving them as desired. In such a scenario, network problems can be diagnosed and remedied without the need to physically access a network switch and capture packet data with an independent packet capture device.
Although various embodiments of systems and methods for network packet capture have been described herein, those embodiments are mere example implementations of the disclosed systems and methods. Therefore, alternative embodiments are possible, each of which is intended to fall within the scope of this disclosure. In one such alternative embodiment, the switch comprises a decoder process or program in switch memory that translates the packet data from machine code to human-readable information, thereby obviating the need for a decoder to be present on a separate computer that retrieves the packets from the switch.
