Pursuant to 35 U.S.C. 119(b) and C.F.R. 1.55(a), the present application corresponds to and claims the priority of Indian Patent Application No. 1678/CHE/2009, filed on Jul. 15, 2009, the disclosure of which is incorporated herein by reference in its entirety.
In a communications network, the path between a transmitter and a destination may involve several intermediate routers and switches that convey data packets and other information through the network to the destination. On occasion, one or more of these routers or switches may fail to move the packets and other data towards the destination. In situations in which the router fails to transport any data packets, existing network management products can be used to detect the faulty element and to reroute data packets around the failed element.
However, when a router is able to transport some data packets but unable to transport other data packets, determining the precise nature of the problem can be much more challenging. In these instances, existing network tools, though useful under conditions in which no packets are transported through the router, are not effective.
In the context of the present invention the term “routing element” is intended to encompass a large variety of network devices such as routers and network hubs. Thus, a routing element may take the form of a router, which connects two or more networks, and may include routing devices that can be programmed to filter out some packets and to dynamically change the route through which packets are routed. A routing element may also take the form of a device that interfaces two or more separate media on the same network, such as a network hub that might include an Ethernet port as well as an Integrated Services Digital Network (ISDN) port and may convey data between these two media.
In one example in which embodiments of the present invention may be useful, consider a network wherein a File Transfer Protocol is operating without incident; meanwhile, other services, such as Secure Shell, have become problematic in that data packets from the Secure Shell transmitter are not reaching the destination server. In this instance, conventional troubleshooting tools may be ineffective in determining that an incorrect firewall rule is being enforced at either the destination server or at a routing element in between the transmitter and the destination server. The incorrect rule enforcement is responsible for prohibiting the delivery of Secure Shell packets while allowing File Transfer Protocol packets to pass through the firewall.
In another example in which locating a fault in a communications network may be useful, consider an instance in which a Network File System file transfer results in a nonresponsive client. In this example, a Network File System client has issued a read request to a Network File System server for a large file. After the request is issued, the complete response for the request never arrives at the requesting client. Meanwhile, other Network File System commands operate without incident. In this instance, it is entirely possible that when the read request was issued to the Network File System server, the destination server responded with a very large Internet protocol (IP) packet that became fragmented into multiple (perhaps as many as 32) smaller Internet protocol packets. When these packets arrived at an intermediate routing element, the network element was not able to forward all of the Internet Protocol packets that had been received. Accordingly, the client that initiated the request had never received a complete response from the destination server. Subsequently, the requesting client remained non-responsive for an indefinite period of time.
In an embodiment of the present invention, a “time-to-live” (TTL) engine operating at the kernel layer (15) modifies the TTL value in the IP header of a first data packet. In this embodiment, a utility program which may be initiated at user layer 12, takes on the faulty program or service as an argument. In one example, the syntax used to invoke such a program might be “nwtusc {192.168.0.100}”, in which 192.168.0.100 corresponds to an exemplary Internet protocol address of destination server 60. In another embodiment of the invention in which it may be important to target packets of a particular application session, it can be useful to additionally include a port number (such as “nwtusc {192.168.0.100, [21]}”) when invoking the program. When the faulty program is run by way of the exemplary “nwtusc” program, the faulty program is spawned as a child process which passes the process ID, destination IP address, and perhaps the port number to the TTL engine operating at kernel layer 15.
The nwtusc program finds the path (which may be a list of intermediate routers, hubs, or other network elements) taken by a packet to reach a destination server using a utility such as “traceroute”. By way of traceroute (for example), the individual routing elements and the number of hops to each routing element are passed to the TTL engine. In this embodiment, the process identification, destination Internet protocol address, and destination port number are used to identify the Internet protocol packets of the particular program experiencing the faults. The identified Internet protocol data packets are stored in a queue by the TTL engine. Thus, the TTL engine can either increment or decrement the TTL value to “tune” the time-to-live of each packet. Through this “tuning”, each routing element in between the transmitting and destination server can be tested, as will be discussed with reference to
The method continues at step 110 in which in the TTL engine operating at the kernel layer determines whether an Internet Control Message Protocol (ICMP) TTL-exceeded packet has been received. In the embodiment of
In the event that the outcome of step 110 indicates that the transmitting entity has not received an ICMP TTL-exceeded packet, step 120 is executed in which the TTL engine waits for a predetermined length of time. This waiting period allows for packet delays caused by temporary problems such as network congestion, router resets, and so forth. After waiting a predetermined period of time, step 125 is performed in which a decision is made as to whether the TTL engine has received an ICMP TTL-exceeded packet. If an ICMP TTL-exceeded packet has been received, the method returns to step 105, in which the previously-transmitted packet is transmitted a second time. By transmitting a second time, it can be determined whether or not the network is still experiencing temporary problems.
In the event that the decision of step 125 indicates that the TTL engine has not received an ICMP TTL-exceeded packet, step 135 is performed in which the value of the TTL is decreased (such as, for this example, from 4 to 3.) The method then continues at step 105 in which the packet is retransmitted using the new value for TTL.
To briefly illustrate how the method of
Continuing with the example of
Returning now to decision block 110 of
After step 170 is performed, step 175 can be performed in which the packet is removed from the queue of the TTL engine. The removal of this packet from the queue of the TTL engine follows from the assumption that the packet has been successfully transmitted to the destination server, as in step 170. After performing step 175, step 180 can be performed in which the next packet in the queue of the TTL engine is selected. The method then returns to step 100 in which the TTL value for the IP header of the next packet is set to the maximum number of routing elements in the network path (which, in this example, might be 4).
In the event that the decision of step 115 indicates that the TTL value is not equal to the number of routing elements in the path of the data packet, step 115 is performed in which the TTL engine is informed that the packets are being dropped at the routing element corresponding to the previous hop count. Thus, in this example, if a transmitted message having a TTL value of 3 has not resulted in the TTL engine receiving an ICMP TTL-exceeded packet (outcome of step 110 is “no”) but a TTL value of 2 resulted in a “yes” outcome of step 110, then the TTL engine would recognize that the fault is occurring at the routing element corresponding to the previous TTL value (3), as in step 165.
When the method of
An advantage of the method of
An additional advantage of the method of
The method of
It is noteworthy to indicate that the embodiments of the invention disclosed herein may not be useful in determining why particular message packets are being dropped by the various routing elements between the transmitting and destination servers. In the embodiments of the invention, the only determination that has been made is the location along the path at which packets have been dropped. Accordingly, embodiments of the invention may be used in conjunction with other diagnostic tools that determine why particular routing elements are not allowing packets to proceed in the direction of the destination server.
In conclusion, while the present invention has been particularly shown and described with reference to various embodiments, those skilled in the art will understand that many variations may be made therein without departing from the spirit and scope of the invention as defined in the following claims. This description of the invention should be understood to include the novel and non-obvious combinations of elements described herein, and claims may be presented in this or a later application to any novel and non-obvious combination of these elements. The foregoing embodiments are illustrative, and no single feature or element is essential to all possible combinations that may be claimed in this or a later application. Where the claims recite “a” or “a first” element or the equivalent thereof, such claims should be understood to include incorporation of one or more such elements, neither requiring nor excluding two or more such elements.
Number | Date | Country | Kind |
---|---|---|---|
1678/CHE/2009 | Jul 2009 | IN | national |