Can the destination node determine which path the packet took in the network by looking at some field ? Trivial solution is to insert all the intermediate nodes while the packet is traversing the network but that is linear in size as the network grows large. Is there any prior research done in this space ?
In standard, best effort, non-VPN, non tunneled, non source-routed, non "record route" IP transfers? No, that's part of IP's charm. The closest way to determine this, that I know of, would be to assume that the reverse path is the same as the forward path, and the destination node can do an ICMP "traceroute" back to the source IP address.
Of course, if any router along the path goes down, from the time the packet is sent to the time the reverse traceroute is accomplished, you won't get the right answer.
See RFC 791, "strict source routing" and "record route" options, which can be used in the IP header "options" field.
IPv6 can do similar things. See RFC 2460 "routing header 0." But security concerns discourage source routing, and it has been deprecated in IPv6.
In standard, best effort, non-VPN, non tunneled, non source-routed, non "record route" IP transfers? No, that's part of IP's charm. The closest way to determine this, that I know of, would be to assume that the reverse path is the same as the forward path, and the destination node can do an ICMP "traceroute" back to the source IP address.
Of course, if any router along the path goes down, from the time the packet is sent to the time the reverse traceroute is accomplished, you won't get the right answer.
See RFC 791, "strict source routing" and "record route" options, which can be used in the IP header "options" field.
IPv6 can do similar things. See RFC 2460 "routing header 0." But security concerns discourage source routing, and it has been deprecated in IPv6.
I would say that I have to agree with Albert's answer. In addition,most Current Wan architectures in place today are dynamic in nature and can adjust due to Traffic load and/or loss of nodes,among other factors. One thing that can be done is to try to estimate the path given that you assume that traffic distribution and topology at the time of a traceroute is close enough. Given this conditions, then you could with probability X state that Y is the path used. Doing this calculation requires that you map the topology between the origin and destination enough to infer the underlying topology and its behavior under different loads and failures.
1. ICMP Protocol Can be used. Especially ICMP Trace Route Message can be used to detect the path. The disadvantage of this method is that the traceroute function will have to be put into the routers. But in IPv6 Version the problem is solved.
2. Another method includes generating a proxy trace message at the source node, transmitting the proxy trace message over the network path towards the destination node, and receiving the proxy trace message at the source node.
3. You can use Visual Trace Route Tool to Trace the path between source to Destination.
I slightly disagree with Albert and Arturo, due to the fact that the returning path may be fairly different. Why, because we know that every single sub-second traffic congestion changes and subsequently, metrics used in either IGP or EGP protocols will get changed as well. With that's said, routing tables of intermediary devices will definitely be changing on that calculation.
Have a look at this patent from Cisco about this topic in particular: http://www.google.com/patents/US8024478
And also, you use PathPing tool to help you with that.
Sashank - If you decide to use Visual Traceroute, I find the help file a bit meager. here is a nice link that augments the information with further details on configuration, usage, tips, etc.
https://4sysops.com/archives/free-visual-traceroute/
This will be quite difficult.
Traceroute commands from the destination may give wrong answers because there is no rule specifying that the return path (B=>A) be the complete reverse of the forward path (A=>B).
Traceroute commands may even fail to give the correct answer in general, because some networks may treat ICMP differently from other kinds of packets. They might be blocked, they might take a low-bandwidth path because they were directed that way by a load-balancing unit, or something else.
Most likely it will be difficult to do this on a per-packet basis, unless all your middleboxes cooperate. Maybe if you are using OpenFlow or other sort of SDN, you could have some more liberty in adding the intermediate nodes' address to your packets.
The most direct answer is NO, YOU CAN'T! (Even options such as "Record Route" are... optional and most times disabled)
Traceroute is not an option because: at most, you will be able to know the path taken for THAT ICMP packet (and even 3 packets in a row may use different routes); Internet routes are dynamic and many times asymmetric. Heuristics and try to guess, but you will never "know", for sure!
there are certain tools available that can be used to trace the path of packets at destination node, but most of them are proprietary tools particularly from fireeye network solutions.
And if the packet uses spoofed IP (as in the case of some DoS attacks), its hard to know the path using the current implementations. In literature, there are many `traceback' solutions, but none ubiquitously deployed yet.
The option called 'traceroute' in ICMP can be used to find the path that a packet has taken to reach the destination node.
- Badges
- Science topic