Source: http://www.google.com/patents/US8041804?dq=5,778,372
Timestamp: 2016-02-13 16:02:28
Document Index: 410928719

Matched Legal Cases: ['art 400', 'art 400', 'art 400', 'art 400', 'art 500', 'art 500', 'art 500', 'art 500', 'art 600', 'art 600', 'art 600', 'art 600']

Patent US8041804 - Utilizing captured IP packets to determine operations performed on packets ... - Google PatentsSearch Images Maps Play YouTube News Gmail Drive More »Sign inPatentsMethods and systems for utilizing captured packets to determine the operations performed on packets by a network device are described. One or more packets are captured and forwarded through the network device. Operations performed on the captured IP packets are logged....http://www.google.com/patents/US8041804?utm_source=gb-gplus-sharePatent US8041804 - Utilizing captured IP packets to determine operations performed on packets by a network deviceAdvanced Patent SearchPublication numberUS8041804 B2Publication typeGrantApplication numberUS 11/441,566Publication dateOct 18, 2011Filing dateMay 25, 2006Priority dateMay 25, 2006Fee statusPaidAlso published asUS8510436, US20070276938, US20120005339Publication number11441566, 441566, US 8041804 B2, US 8041804B2, US-B2-8041804, US8041804 B2, US8041804B2InventorsIqlas Maheen Ottamalika, David C. White, Jr., Madhusudan ChallaOriginal AssigneeCisco Technology, Inc.Export CitationBiBTeX, EndNote, RefManPatent Citations (25), Non-Patent Citations (1), Referenced by (3), Classifications (13), Legal Events (2) External Links: USPTO, USPTO Assignment, EspacenetUtilizing captured IP packets to determine operations performed on packets by a network device
US 8041804 B2Abstract
Methods and systems for utilizing captured packets to determine the operations performed on packets by a network device are described. One or more packets are captured and forwarded through the network device. Operations performed on the captured IP packets are logged.
capturing a plurality of Internet Protocol (IP) packets prior to the packets entering an ingress point of a network device wherein the plurality of captured IP packets form a network traffic stream having a pattern;
saving the captured IP packets, wherein the captured IP packets are saved in an order of the traffic stream;
wherein the saved IP packets contain a payload including application level information;
injecting the saved IP packets through the ingress point of the network device, in the order of the traffic stream;
logging operations performed on the saved IP packets, in order of performance, wherein the logging comprises adding one or more tags to the saved IP packets wherein each tag of the one or more tags indicates an operation performed on the saved IP packets by the network device;
inspecting the saved IP packets and corresponding tags to determine the operations performed and the order of performance of the operations as indicated by the one or more tags and an order of the one or more tags;
correlating network device configuration information corresponding to a network device configuration for the network device with the operations performed on the saved IP packets, wherein the operations performed each map to one or more corresponding lines in a configuration file; and
displaying the mapped operations with the correlated network device configuration information, wherein the mapped operations are shown inline with the corresponding lines in the configuration file.
2. The method of claim 1, wherein the operations comprise one or more of the following: an access filter operation, a route lookup operation, a network address translation (NAT) operation, an authentication or authorization operation, an advanced protocol filter operation, a quality of service operation, an encryption or decryption operation, a tunneling operation, an egress access filter, an egress interface, or a final action to transmit or drop operation.
3. The method of claim 1, further comprises correlating an operation of the operations performed on the saved IP packet with an associated entry from a set of configuration information entries corresponding to the configuration of the network device.
15. An apparatus comprising: one or more processors configured to:
capture and save a plurality of Internet Protocol (IP) packets at an ingress point of a first network device to generate a plurality of saved IP packets, wherein the plurality of saved IP packets form a network traffic stream having a pattern, and wherein the captured and saved packets include a payload including layer 7 data;
propagate the plurality of saved IP packets through the first network device, in an order of the traffic stream;
log first operations performed on the plurality of saved IP packets, wherein the logging of the first operations comprises adding one or more tags to at least one of the plurality of saved IP packets as the plurality of saved IP packets travel through a processing path of the first network device, wherein each tag indicates an operation performed by the first network device;
receive a corresponding first output from the first network device comprising descriptions of one or more actions performed on the saved IP packets, the one or more actions mapping to one or more corresponding lines in a configuration file;
propagate the plurality of saved IP packets through a second network device;
log second operations performed on the plurality of saved IP packets, wherein the logging of the second operations comprises adding one or more tags to at least one of the plurality of saved IP packets to indicate operations performed as the plurality of saved IP packets travel through a processing path of the second network device;
receive a corresponding second output from the second network device;
determine behavioral patterns of the first and second network devices by comparing the first output with the second output;
display the first and second operations mapped to corresponding lines of configuration data to confirm configuration compliance; and
execute troubleshooting or debugging, or combinations thereof based on the payload data.
17. A system for determining operations performed on IP packets by a network device, the system comprising:
means for copying Internet Protocol (IP) packets at an ingress point of a network device, wherein the copied IP packets form a network traffic stream having a pattern;
means for sending the IP packet copies through the ingress point of the network device in an order of the traffic stream, wherein the operations performed on the copied IP packets of the network traffic stream by the network device are under analysis, wherein the operations comprise on or more actions performed on the copied IP packets;
means for logging the actions performed on the IP packet copies in order of performance, wherein the means for logging comprises means for adding tags to the IP packet copies indicating corresponding actions were performed by the network device on the IP packet copies;
means for analyzing the actions performed on the IP packet copies and the order of performance of the actions as indicated by the one or more tags and an order of the one or more tags, wherein the means for analyzing comprises a means for inspecting the tags to determine a configuration of the operations performed on the IP packet copies;
means for generating an output wherein the output comprises descriptions of the one or more actions performed on the copied IP packets, the one or more actions mapping to one or more corresponding lines in a configuration file for a configuration of the network device; means for displaying the mapped actions inline with corresponding lines of the configuration file.
18. The system of claim 17 further comprises:
means for analyzing application level information associated with the IP packt copies; and
means for removing the IP packet copies from a data plane of the network device independent of an analysis performed on the IP packet copies.
The U.S. patent application Ser. No. 11/338,096, filed Jan. 23, 2006, entitled “A METHOD FOR DETERMINING THE OPERATIONS PERFORMED ON PACKETS BY A NETWORK DEVICE,” by Iqlas Ottamalika, David C. White, Jr., and Madhu Challa, assigned to the same assignee of the present Patent Application, is hereby incorporated by reference.
For a variety of reasons, a packet en route to its destination often passes through one or more networking device(s). For example, for security purposes, a packet may pass through a firewall, a router, or an Intrusion Prevention System (IPS). Once a networking device has received the packet it may perform a series of operations and actions on the packet before determining whether the packet should be allowed to be transmitted or dropped. For example, a firewall that has received a packet may perform a series of operations on the packet to determine whether the packet is valid and safe before transmitting it out the egress (output) interface.
With conventional approaches, the operations performed on the packet cannot be efficiently determined. For example, one traditional approach to analyzing the operations performed on the packet is by examining associated logs (syslogs) and debugs. The limitation of current logs and debugs is that they do not apply to a single packet, but instead to an entire feature or protocol. Because of this, trying to determine the operations performed on a packet by examining associated logs and/or debugs requires correlation of the logs/debugs back to the specific packet. This is very time consuming and inefficient.
This inefficiency causes problems for different network related operations. In one example, this inefficiency causes problems for the security operations group. The security operations group is responsible for ensuring a network device meets a set of network security guidelines. In order to accomplish this, security operations analyze both network traffic that is destined for the network device and network traffic that passes through the network device.
With conventional approaches, the network device's configuration is analyzed to determine the security posture. Logs (syslog) are then scrutinized to validate that the network device is denying traffic that is denied in the configuration, and permitting traffic that is permitted in the configuration. However, this approach is inefficient and painstakingly slow.
In another example, the network operations group is negatively affected by the lack of an efficient way to determine the operations performed on a packet as well. Network operations group verifies network connectivity between network users and resources, e.g., servers. In essence, the network operations group analyzes connectivity issues and determines why a user is unable to access a resource. With conventional approaches, a member of the network operations group frequently has to spend a significant amount of time to determine the operations performed on packets in order to troubleshoot the connectivity issue.
Specifically, a member of the network operations group may first analyze all the operations taken on the packet. Subsequently, an attempt is made to determine which operation is causing the connectivity to fail. If a cause is determined, the network operations agent may need to match the operation with an associated entry in the configuration to enable, disable, or modify the behavior. However, if the configuration is large, this approach becomes difficult, time-consuming, and without detailed knowledge of the network device one cannot effectively perform the troubleshooting.
FIG. 5 illustrates a flowchart of a method for applying a light weight trace on captured packets to determine the operations performed on packets by a network device upon which embodiments in accordance with the present claimed subject matter can be implemented.
Reference will now be made in detail to embodiments of the present claimed subject matter, examples of which are illustrated in the accompanying drawings. While the claimed subject matter will be described in conjunction with these embodiments, it will be understood that they are not intended to limit the claimed subject matter to these embodiments. On the contrary, the claimed subject matter is intended to cover alternatives, modifications and equivalents, which can be included within the spirit and scope of the claimed subject matter as defined by the appended claims. Furthermore, in the following detailed description of the present claimed subject matter, numerous specific details are set forth in order to provide a thorough understanding of the present claimed subject matter. However, it will be evident to one of ordinary skill in the art that the present claimed subject matter can be practiced without these specific details. In other instances, well known methods, procedures, components, and circuits have not been described in detail as not to unnecessarily obscure aspects of the claimed subject matter.
Under traditional approaches, it is often difficult to determine the operations taken on a packet. For example, scrutinizing logs (syslog) to validate if a network device is denying traffic that is denied in its corresponding configuration and permitting traffic that is permitted in the corresponding configuration is often time consuming and inefficient. Thus, an efficient way to determine the operations taken on a packet is desired.
One approach utilizes a simulated packet to determine operations taken on a packet. In one example, a simulated packet is input into a network device and the path taken by the simulated packet is recorded by adding tags to the simulated packet. Similarly, the operations performed on the simulated packet are recorded by adding additional tags indicating the operations performed. Further, if the simulated packet is dropped internally by an operation or has reached an egress interface and is ready to be transmitted, the tags are removed from the simulated packet and ordered for analysis. Upon removal, the tags are analyzed and the actions taken on the simulated packet are determined. However, although the simulated packet is an efficient way of determining operations taken on a packet in certain situations, it does not have the advantages provided by using one or more captured packets in other situations.
The present claimed subject matter focuses on utilizing one or more captured packets (e.g., captured Internet Protocol packets) to determine operations performed on packets by a network device (e.g., a router). In one embodiment, IP packets are captured and forwarded through the network device. Operations performed on the captured IP packets are logged. Different from using a simulated packet approach that require a user input key attributes of the simulated packet, the captured packet approach, in one example, automatically includes key attributes such as flags, Differentiated Services Code Point (DSCP) bits, and other Layer 5 (session layer) and Layer 4 (transport layer) header information.
Also, different from using a single simulated packet at a time, using captured packets means multiple packets can be sent at a time through a network device. As multiple data packets are needed in both directions to establish a TCP/IP session and pass data, captured packets may be easily adapted to establish and analyze TCP/IP sessions. Moreover, many TCP/IP related problems can only be debugged correctly if the stream of data packets is in order. In general, the simulated packets approach is unable to correctly debug TCP/IP issues. For example, with regards to diagnosing problems associated with the voice protocol context, TCP handshake context, FTP context, and/or HTTP web traffic context, multiple packets are needed for an effective evaluation.
In addition, a significant portion of Layer 7 (application layer) information is often needed for troubleshooting various protocols. For instance, information included in the control channel payload is of great importance to troubleshooting File Transfer Protocol (FTP). In general, captured packets include Layer 7 information and can be efficiently utilized in troubleshooting different protocols.
Furthermore, by utilizing a captured packets approach a client can capture the actual network traffic and save it in a “pcap” or “tcpdump” format. Subsequently, the client can replay the network traffic to analyze what in fact has occurred.
Additionally, the captured packets approach can be used to compare devices. Although the simulated packet approach can also be utilized to evaluate the behavior of network devices, it may not provide the complexity of real network traffic. By taking the captured packets approach, a highly complicated network traffic pattern can be sent through a first device and the corresponding first output saved. Subsequently, the complicated traffic pattern can be sent through a second device and a corresponding second output saved. By comparing the first output to the second output, the behavior of the first device can be compared with the behavior of the second device. Thus, the captured data packet approach can be utilized as an efficient diagnostic tool.
FIG. 1 illustrates a system 100 for utilizing captured packets to determine the operations performed on packets by a network device, in accordance with an embodiment of the present claimed subject matter. System 100 includes computing device 102, ingress interface 104, network device 106, egress interface 108, captured packet 110, captured packet 114, captured packet 118, tag 112, tag 116, and tag 120. In one embodiment, computing device 102 is a command line interface station where a user can perform post processing of captured packets.
Also, although system 100 is shown and described as having certain numbers and types of elements, the present claimed subject matter is not so limited; that is, system 100 can include elements other than those shown, and can include more than one of the elements that are shown. For example, system 100 can include a greater or fewer number of captured packets than the three captured packets (captured packets 110, 114, and 118) shown. Also, system 100 can include a greater number of tags in each of the captured packets. In one embodiment, captured packet 110 has other tags (not shown) in addition to tag 112. Also, in one embodiment, the captured packets include key attributes such as flags, Differentiated Services Code Point (DSCP) bits, Layer 5 header information, and Layer 4 header information.
In one embodiment, captured packets 110, 114, and 118 are sent through network device 106 and are utilized to trace the operations and actions taken on a packet as it passes through a network device. In one example, the captured packets 110, 114, and 118 are packets that were captured at an earlier point in time at the ingress interface. The captured packets 110, 114, and 118 are inputted into network device 106 via ingress interface 104 of network device 106. Network device 106 can be a firewall, a switch, a router, an Intrusion Prevention System (IPS), other types of network security devices, and/or other compatible devices.
Captured packets 110, 114, and 118 travels through the same processing paths of network device 106 as if it were packets of normal network traffic. However, in contrast to packets of normal network traffic, if operations are performed on the captured packets 110, 114, and 118, tags, such as tags 112, 116, and 120, are added to the captured packets 110, 114, and 118 to indicate the operation. In one example, multiple tags are added to each of the captured packets 110, 114, and 118 to record different operations performed on the captured packets. Similarly, the path (e.g., data path) taken by captured packets 110, 114, and 118 are indicated by additional tags.
Upon reaching either an egress interface, e.g., egress interface 108, of the network device 106 or being dropped internally by an operation, a captured packet (e.g., captured packet 114) is removed from its path. In one example, the tags, such as tag 116, are removed, ordered for processing, and analyzed to determine the actions and operations taken on the dropped packet (e.g., captured packet 114). In another example, the tags, such as tag 116, are saved with the captured packet (e.g., captured packet 114). In one embodiment, upon removal of the captured packet 114 from the data plane, actions taken on the captured packet 114 is presented to a user with the corresponding line in the configuration information that represents the given action. An action/operation taken on the captured packet 114 can be an ingress access filter operation, a route lookup operation, a network address translation (NAT) operation, an authentication and/or authorization operation, an advanced protocol filter operation, a quality of service operation, an encryption and/or decryption operation, a tunneling operation, an egress access filter, an egress interface, and/or a final action to transmit or drop operation.
FIG. 2 illustrates a block diagram of captured packets 202, 208, and 214 being analyzed, in accordance with an embodiment of the present claimed subject matter. Captured packet 202 includes tags 204 and 206. Captured packet 208 includes tags 210 and 212. Captured packet 214 includes tag 216 and 218. Also, configuration information 220 includes first entry 222, second entry 224, third entry 226, fourth entry 228, fifth entry 230, and sixth entry 232.
Also, although captured packets 202, 208, 214, and configuration information 220 are shown and described as having certain numbers and types of elements, the present claimed subject matter is not so limited; that is, captured packets 202, 208, 214, and configuration information 220 can include elements other than those shown, and can include more than one of the elements that are shown. In one example, captured packet 202 can include a greater or fewer number of tags than the two tags (tags 204 and 206) shown. In another example, configuration information 220 can include a greater or fewer number of entries than the six entries (first entry 222, second entry 224, third entry 226, fourth entry 228, fifth entry 230, and sixth entry 232) shown.
Once a captured packet, such as captured packet 202, is removed from its path, the associated tags, such as tags 204 and 206, in one embodiment, are saved with the captured packet (e.g., captured packet 202) and analyzed to determine the operations performed on the captured packet (e.g., captured packet 202). In one example, all actions performed on the captured packet 202 are recorded. The actions correlated directly to specific lines in the configuration information. Thus, a user can see the actions taken on captured packet 202 by a network device. Also, a user is informed which part of the configuration information needs to be modified to change an action.
In the present embodiment, tag 204 and tag 206 indicate the operations performed on the captured packets 202 and are removed. Upon removal, the operations indicated by tags 204 and 206 are correlated with its corresponding entries, e.g., first entry 222 and second entry 224, in the configuration information.
Specifically, the operation indicated in tag 204 is correlated to first entry 222 of configuration information 220 and the operation indicated in tag 206 is correlated to second entry 224 of configuration information 220. Once the process of correlation is complete, the results may be displayed to a user. Although in the present embodiment a tag only corresponds to one operation, the present claimed subject matter is not so limited. In other embodiments, a tag may indicate several separate operations performed on a captured packet (e.g., captured packet 202).
Similarly, tags 210 and 212 of captured packet 208 are correlated to third entry 226 and fourth entry 228 respectively. In the same way, tags 216 and 218 are correlated to fifth entry 230 and sixth entry 232. In one example, a captured packet, such as captured packet 208, can have more than two associated tags. Also, one or more tags may be correlated to the same entry of configuration information 220.
By automatically correlating operations to its associated entries in the configuration information, a user can easily match actions taken on captured packets (e.g., captured packets 202, 208, and 214) to the corresponding configuration. Thus, the present claimed subject matter allows a more time effective way for debugging, troubleshooting, or verification of configuration rules.
FIG. 3 illustrates a system 300 of utilizing captured packets to compare network devices. System 300 includes network device 301 and network device 303. Network device 301 includes ingress interface 305 and egress interface 335. Network device 303 includes ingress interface 331 and egress interface 333.
In the present embodiment, a network traffic pattern (e.g., captured packet 309 with tag 307, captured packet 313 with tag 311, and captured packet 317 with tag 315) is sent through network device 301. Also, captured packet 339 with tag 337, captured packet 343 with tag 341, and captured packet 347 with tag 345, represents the same network traffic pattern and is sent through network device 303. Although network traffic pattern is shown and described, in one example, as including captured packets 309, 313, and 317, the claimed subject matter is not so limited. In another embodiment, the network traffic pattern is more complex.
A corresponding first output from the network device 301 is saved. Also, a corresponding second output from the network device 303 is saved. The first output is compared with the second output to contrast the behavior of network device 301 with network device 303. Accordingly, captured packets (e.g., captured Internet Protocol packets) may be utilized as an efficient diagnostic tool.
FIG. 4 illustrates a flowchart 400 of a method for utilizing captured packets to determine the operations performed on packets by a network device upon which embodiments in accordance with the present claimed subject matter can be implemented. Although specific steps are disclosed in flowchart 400, such steps are exemplary. That is, embodiments of the present claimed subject matter are well suited to performing various other or additional steps or variations of the steps recited in flowchart 400. It is appreciated that the steps in flowchart 400 can be performed in an order different than presented.
At block 408, the captured IP packets forming a network traffic pattern are forwarded through the network device (e.g., a router). In one embodiment, the captured IP packets are injected into the ingress interface of the network device. Also, a network device can be a firewall, a router, an Intrusion Prevention System (IPS), a network security device, and/or other compatible network devices.
At block 410, operations performed on the captured IP packets are logged as the captured IP packets featuring the network traffic pattern pass through a network device. At block 412, tags are added to the captured IP packets. In one embodiment, an operation performed on the captured IP packets is logged by adding a tag indicating the operation onto the captured IP packet. In one embodiment, a plurality of tags is added to a captured IP packet to indicate a corresponding plurality of operations performed. In one embodiment, a tag indicates a plurality of operations taken on the captured IP packet. Also, in one embodiment, the path (e.g., data path) taken by the captured IP packet is traced. In one embodiment, the path taken by the captured IP packet is traced by adding tags indicating the path taken by the captured IP packet.
At block 414, it is determined whether a captured IP packet has been dropped or has reached an egress interface of the network device. Determining whether a captured IP packet has been dropped or has reached an egress interface of the network device can be implemented in a variety of ways. In one embodiment, a processor determines whether a captured IP packet has been dropped or has reached an egress interface of the network device. If it is determined that a captured IP packet has not been dropped or has not reached an egress interface of the network device, then operations performed on the captured IP packet continues to be logged.
At block 416, if the captured IP packet has been dropped internally or has reached an egress interface of the network device, then the captured IP packet is removed from the data path. In one embodiment, removal is implemented by deleting the captured IP packet. In another embodiment, removal is implemented by directing the captured IP packet away from its prior path. Also, removal can be immediate or time-delayed.
At block 418, operations performed on the captured IP packets are analyzed. In one embodiment, the tags from the captured IP packet are removed in order, and analyzed to determine the actions taken on the captured IP packet. In one embodiment; a user uses a command line interface (CLI) to perform post processing of the tags.
At block 420, the operations performed on the captured IP packets are determined. At block 422, an operation of the operations performed on the captured IP packets is correlated with an associated entry from a set of configuration information. In one embodiment, each tag is automatically correlated with its associated entry from the configuration information. In one embodiment, operations performed on the IP packets and associated configuration information is displayed to a user. At block 424, the process ends.
Accordingly, embodiments offer effective methods for a user to trace actions performed on packets without having to manually fabricate a packet. By utilizing captured packets and a light weight trace technique, the performance of the network device is negligibly impacted. Moreover, embodiments allow tagging of a time line of the life of packets in various modules, which allow a real time profile of network traffic through network devices. Consequently, embodiments can be utilized to debug modules that take a long time in processing packets.
FIG. 5 illustrates a flowchart 500 of a method for applying a light weight trace on captured packets to determine the operations performed on packets by a network device (e.g., a switch) upon which embodiments in accordance with the present claimed subject matter can be implemented. Although specific steps are disclosed in flowchart 500, such steps are exemplary. That is, embodiments of the present claimed subject matter are well suited to performing various other or additional steps or variations of the steps recited in flowchart 500. It is appreciated that the steps in flowchart 500 can be performed in an order different than presented.
At block 502, the process starts. At block 504, IP packets are captured. In one embodiment, the captured IP packets includes key attributes such as flags, Differentiated Services Code Point (DSCP) bits, and other Layer 5 (session layer) and Layer 4 (transport layer) header information.
At block 506, the IP packets are saved in a pcap (packet capture) format. At block 508, the captured IP packets are saved in a TCP dump format. In one embodiment, the IP packets are saved onto a non-volatile memory, such as Read-Only Memory (ROM), flash memory, hard disks, floppy disks, magnetic tapes, optical disk drives, and Magnetic Random Access Memory (MRAM). In another embodiment, the captured packets are saved onto a volatile memory, such as Random Access Memory (RAM), Dynamic Random Access Memory (DRAM), Static Random Access Memory (SRAM), Content Addressable Memory, dual-ported RAM, and/or other types volatile memory.
At block 510, the captured IP packets are forwarded through the network device. In one embodiment, the captured IP packets are injected into the ingress interface of the network device. Also, a network device can be a firewall, a router, an Intrusion Prevention System (IPS), a network security device, and/or other compatible network devices.
At block 512, operations performed on the captured IP packets are logged. In one embodiment, one or more tags are added to each of the captured IP packets to trace actions taken and/or operations performed on the captured IP packets. In one embodiment, each tag on the captured IP packet is subsequently correlated to an entry in configuration information.
At block 514, a light weight trace is utilized. In one embodiment, the light weight trace does not impact the data path and does not appreciably impact the performance of the network device. Hence, unlike conventional packet tracers, embodiments allow a user to analyze a network device without negatively impacting the proper functioning of the network device.
At block 516, security checks performed on the IP packets are logged. In one embodiment, every security check performed on a captured UP packet is recorded. At block 518, Layer 3 (transport layer) lookups on the captured IP packets are performed. At block 520, Layer 2 (data link layer) lookups on the captured IP packets are performed.
At block 522, a time line of the life of the captured IP packet is tagged to determine a real time profile of the network traffic through the network device. In one embodiment, time lines of the life of packets in various modules are tagged, which allow a real time profile of network traffic through network devices. Accordingly, embodiments can be utilized to debug modules that take a long time in processing packets.
At block 526, if the captured IP packet has been dropped internally or has reached an egress interface of the network device, then the captured IP packet is removed from the data path. In one embodiment, the removal is immediate. In another embodiment, the removal is time-delayed.
At block 528, operations performed on the captured IP packets are analyzed. In one embodiment, analysis of the operations performed on the captured IP packets takes place at a command line interface (CLI) station. In one embodiment, the analysis includes post processing of the trace buffer. In one embodiment, an operation of the operations performed on the captured IP packets is correlated with an associated entry from a set of configuration information. In one embodiment, each tag is automatically correlated with its associated entry from the configuration information. In one embodiment, operations performed on the IP packets and associated configuration information is displayed to a user. At block 530, the process ends. Accordingly, the present invention allows a more time effective way for debugging, troubleshooting, or verification of configuration rules.
FIG. 6 illustrates a flowchart 600 of a method for utilizing captured packets to compare the behavior pattern of network devices upon which embodiments in accordance with the present claimed subject matter can be implemented. Although specific steps are disclosed in flowchart 600, such steps are exemplary. That is, embodiments of the present claimed subject matter are well suited to performing various other or additional steps or variations of the steps recited in flowchart 600. It is appreciated that the steps in flowchart 600 can be performed in an order different than presented.
At block 602, the process starts. At block 604, IP packets forming a network traffic pattern are captured. In one embodiment, the network traffic pattern is highly complex. With the simulated packet approach, it may be inefficient for a user to manually define a network traffic pattern of equal complexity. Thus, the captured IP packets approach allow a more effective means for obtaining a complex network traffic pattern.
At block, 606, the captured packets are sent through a first network device. The network device can be a router, a firewall, and/or an Intrusion Prevention Device. At block 608, a corresponding first output from the first network device is received. At block 610, the first output is saved.
At block 612, the captured packets are sent through a second network device. At block 614, a corresponding second output is received from the second network device. At block 616, the second output is saved. Although in the present embodiment the captured packets are sent through a first network device and a second network device, the claimed subject matter is not so limited. The captured packets can be sent through any number of network devices in order to compare the behavior patterns of network devices.
At block 618, the first output is compared with the second output to determine the differences between the first network device and the second network device. At block 620, the process ends. Accordingly, embodiments allow a complicated network traffic pattern to be sent through different devices in order to compare the behavior patterns between the different devices.
Thus, embodiments set forth examples of using captured packets to determine the operations performed on packets by a network device. Because captured packets include payload information (e.g., layer 7 application level information), it can be utilized to perform effective troubleshooting where the information included in the payload is of appreciable significance (e.g., in the FTP context). Moreover, a number of TCP/IP related problems can only be debugged properly if the stream of data packets used for diagnosis is in order. By using captured packets, the entire stream can, in one example, be replayed in order. Further, embodiments provide an effective way to match actions taken on a captured IP packet with its associated configuration information. In one example, embodiments set forth a pro-active tool that allows network operators to verify configuration information. In another example, embodiments enable security operators to efficiently verify that a network device is denying traffic that is denied in the configuration, and permitting traffic that is permitted in the configuration.
Patent CitationsCited PatentFiling datePublication dateApplicantTitleUS5640394 *Jan 16, 1996Jun 17, 1997Microsoft CorporationSystem and method for running multiple incompatible network protocol stacksUS5696899 *Nov 18, 1992Dec 9, 1997Canon Kabushiki KaishaMethod and apparatus for adaptively determining the format of data packets carried on a local area networkUS5819042 *Feb 20, 1996Oct 6, 1998Compaq Computer CorporationMethod and apparatus for guided configuration of unconfigured network and internetwork devicesUS5850388 *Oct 31, 1996Dec 15, 1998Wandel & Goltermann Technologies, Inc.Protocol analyzer for monitoring digital transmission networksUS6137782 *Jun 17, 1999Oct 24, 2000Sharon; AzulaiAutomatic network traffic analysisUS6515967 *Jun 30, 1998Feb 4, 2003Cisco Technology, Inc.Method and apparatus for detecting a fault in a multicast routing infrastructureUS6539022Apr 26, 1999Mar 25, 2003Enterasys Networks, Inc.Network device with multicast forwarding dataUS7738403Jan 23, 2006Jun 15, 2010Cisco Technology, Inc.Method for determining the operations performed on packets by a network deviceUS7810041Apr 4, 2006Oct 5, 2010Cisco Technology, Inc.Command interfaceUS20020038379 *Jan 23, 2001Mar 28, 2002Fujitsu LimitedRouting apparatusUS20020071387 *Dec 11, 2001Jun 13, 2002Kabushiki Kaisha ToshibaInter-network relay unit and transfer scheduling method in the sameUS20030005145 *Jun 12, 2001Jan 2, 2003Qosient LlcNetwork service assurance with comparison of flow activity captured outside of a service network with flow activity captured in or at an interface of a service networkUS20030091042Oct 5, 2001May 15, 2003Broadcom CorporationMethod and apparatus for enabling access on a network switchUS20030187977 *Jan 31, 2003Oct 2, 2003At&T Corp.System and method for monitoring a networkUS20030236995 *Jun 21, 2002Dec 25, 2003Fretwell Lyman JeffersonMethod and apparatus for facilitating detection of network intrusionUS20040047349Aug 19, 2003Mar 11, 2004Nec CorporationPacket transfer equipment, packet transfer method resolution server, DNS server, network system and programUS20040103315 *Jun 7, 2001May 27, 2004Geoffrey CooperAssessment toolUS20040114590 *Mar 28, 2002Jun 17, 2004Stephen HarrisPacket switching networksUS20050099948 *Nov 12, 2003May 12, 2005Wakumoto Shaun K.Automated path tracing through switching meshUS20050169186Jun 30, 2004Aug 4, 2005Microsoft CorporationWhat-if analysis for network diagnosticsUS20050190758Mar 1, 2004Sep 1, 2005Cisco Technology, Inc.Security groups for VLANsUS20050259587May 20, 2004Nov 24, 2005Wakumoto Shaun KDirecting a path verification request along a specific path to a mesh network switch to test operability of the specific pathUS20060023638Jul 29, 2005Feb 2, 2006Solutions4NetworksProactive network analysis systemUS20060077964Jan 13, 2005Apr 13, 2006Santera Systems, Inc.Methods and systems for automatic denial of service protection in an IP deviceUS20070002769 *Jul 1, 2005Jan 4, 2007Eldad MatityahuActive packet content analyzer for communications network* Cited by examinerNon-Patent CitationsReference1USPTO; Office Action for U.S. Appl. No. 11/338,096; mailed Mar. 23, 2009.Referenced byCiting PatentFiling datePublication dateApplicantTitleUS8468394 *Mar 9, 2006Jun 18, 2013Arm LimitedMethod of tracing selected activities within a data processing system by tagging selected items and tracing the tagged itemsUS8510436Sep 15, 2011Aug 13, 2013Cisco Technology, Inc.Utilizing captured IP packets to determine operations performed on packets by a network deviceUS20090177928 *Mar 9, 2006Jul 9, 2009Daryl Wayne BradleyApparatus, Method and Computer Program Product for Generating Trace Data* Cited by examinerClassifications U.S. Classification709/224, 370/236, 370/255, 709/221, 370/392, 709/238International ClassificationG06F15/177, G06F15/173, H04L12/28, H04J1/16Cooperative ClassificationH04L63/02, H04L63/1425European ClassificationH04L63/14A2Legal EventsDateCodeEventDescriptionMay 25, 2006ASAssignmentOwner name: CISCO TECHNOLOGY, INC., CALIFORNIAFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:OTTAMALIKA, IGLAS MAHEEN;WHITE, DAVID C., JR.;CHALLA, MADHUSUDAN;REEL/FRAME:017939/0370Effective date: 20060525Apr 20, 2015FPAYFee paymentYear of fee payment: 4RotateOriginal ImageGoogle Home - Sitemap - USPTO Bulk Downloads - Privacy Policy - Terms of Service - About Google Patents - Send FeedbackData provided by IFI CLAIMS Patent Services