tracert (Windows) or tracepath (Linux) will be what you'll want to run. Do you have access to a system at both locations? You will need to in order to find the return path.
Miftaul H
Extended ping can do that from a cisco device.
Don Johnston
Best way is to ping and use the record route function. But that only works up to 9 hops.
For example, for a windows PC, you can use "ping -r 9 10.2.3.4"
Tracert/Traceroute will give the path info from source to destination but will not give return path info from destination to source.
Cyclops3590
it also kind of depends on the path that your packet takes between the two locations and how much detail you want to know. you won't see every hop if it goes thru a tunnel of any kind (by design of how the technology works though) or MPLS networks (which is label switching, not IP so again by technology design).
Just something to be aware of anyway if you "know" there should be more in the trace list than you see. There could be technologies used that mask "real" hops due to encapsulation.
but yes, trace route is what you want as that is the most, from a purely clients perspective, way to tell the path your packet takes.
Akinsd
pathping <destination ip or hostname>
Using a PC. This does not show return path either but you will have to assume or hope that the to and fro paths are the same. May not be the same if there are alternate paths, especially if traffic conditions or policy exist
ping -r9 <IP Addresss> gives me the ping response with the path from source to destination.
I am not able to find out the reverse path for the ping reply to confirm if it the same path or diff path.
The traceroute also does the same. Any idea how to achieve this....
Cyclops3590
run the same commands from the other side. there's really no other way without having direct insight into the routing environment between the two points.
Akinsd
You can try the source route option with tracert. That will give you your return path but unfortunately, this is usually blocked as hackers take advantage of it.
Options:
-d Do not resolve addresses to hostnames.
-h maximum_hops Maximum number of hops to search for target. -j host-list Loose source route along host-list (IPv4-only).
-w timeout Wait timeout milliseconds for each reply. -R Trace round-trip path (IPv6-only).
-S srcaddr Source address to use (IPv6-only).
-4 Force using IPv4.
-6 Force using IPv6.
Options:
-t Ping the specified host until stopped.
To see statistics and continue - type Control-Break;
To stop - type Control-C.
-a Resolve addresses to hostnames.
-n count Number of echo requests to send.
-l size Send buffer size.
-f Set Don't Fragment flag in packet (IPv4-only).
-i TTL Time To Live.
-v TOS Type Of Service (IPv4-only. This setting has been deprecated
and has no effect on the type of service field in the IP Head
er).
-r count Record route for count hops (IPv4-only).
-s count Timestamp for count hops (IPv4-only). -j host-list Loose source route along host-list (IPv4-only). -k host-list Strict source route along host-list (IPv4-only).
-w timeout Timeout in milliseconds to wait for each reply. -R Use routing header to test reverse route also (IPv6-only).
Per RFC 5095 the use of this routing header has been
deprecated. Some systems may drop echo requests if
this header is used. -S srcaddr Source address to use.
-4 Force using IPv4.
-6 Force using IPv6.
Options: -g host-list Loose source route along host-list.
-h maximum_hops Maximum number of hops to search for target.
-i address Use the specified source address.
-n Do not resolve addresses to hostnames.
-p period Wait period milliseconds between pings.
-q num_queries Number of queries per hop.
-w timeout Wait timeout milliseconds for each reply.
-4 Force using IPv4.
-6 Force using IPv6.
source routing won't give reliable data though because you specify that list. So it only pertains to that trace route test. It's not the true return path for normal data.