The Unix command traceroute traces the IP addresses of the nodes from a source node to a destination node. Every node in between has an incoming and an outgoing interface.


Executing traceroute -n dst on src will show the IP addresses of src, dst and all incoming interfaces of the hops in between.

But how to trace the outging IP addresses?


I tried the ping -R suggestion but it does not seem to work. This is the traceroute to a public web server:

$ ping -n -c 1 -R
PING ( 56(124) bytes of data.
64 bytes from icmp_req=1 ttl=57 time=47.4 ms

--- ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 47.441/47.441/47.441/0.000 ms

And this is the IP address of my dial-up connection.

$ curl -s https://toolbox.googleapps.com/apps/browserinfo/info/ | jq -r .remoteAddr

But it has not been recorded by the ping command. What can be the reason?

  • Tip: the quickest way to get your public IP is curl ifconfig.me. Simplest thing on the internet. Hands down.
    – Ryan Foley
    Oct 8, 2014 at 20:06
  • 1
    ICMP will never give you the information you are looking to get accurately. The default behavior is to use the egress interface of the ICMP message, but it can generally be configured to be sourced from other interfaces. Let's say I have an internet router that is using RFC1918 addressing between router interfaces within my own network, but I don't want to provide those addresses to the public, I can assign a public IP to a loopback interface and source all ICMP traffic from that interface. You are getting neither the "incoming" nor the "outgoing" interfaces and never will from that device.
    – YLearn
    Oct 8, 2014 at 20:34
  • @RyanFoley ifconfig.me is not reliable (1 error in 5 tests) and it is slow: a query takes 2.8s. Google's toolbox needs 0.7s.
    – ceving
    Oct 9, 2014 at 7:57
  • Did any answer help you? if so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you could post and accept your own answer.
    – Ron Maupin
    Jan 3, 2021 at 19:08

2 Answers 2


I's not exactly the answer at your question, but that a simple (but limited) way to do (in certain case) what you want. I'm coping-post the option -R of ping man page:

-R Record route. Includes the RECORD_ROUTE option in the ECHO_REQUEST packet and displays the route buffer on returned packets. Note that the IP header is only large enough for nine such routes. Many hosts ignore or discard this option.

So you can see also the return path of the ECHO_REQUEST, that is not the exit interface (that you are asking about) unless the outgoing path is the same of the come back path. Only in this case, the returning path is the IP address of the outgoing interface you are asking for.

That's an real example on my internet provider net, maybe not so clear, but I don't have just now some router to link each other :) dest

traceroute to (, 30 hops max, 60 byte packets
 1 (  3.418 ms  3.575 ms  4.021 ms
 2 (  11.237 ms * *
 3 (  15.235 ms * *

ping -R PING ( 56(124) bytes of data.

64 bytes from icmp_req=5 ttl=253 time=74.1 ms NOP RR:


64 bytes from icmp_req=6 ttl=253 time=13.0 ms NOP RR: ##change every time, Idon't know why##

  • I am not sure if I understood correctly what RECORD_ROUTE does, but it does not seem to be, what I need. I tried it with a dial-up connection. I know the public address of my dial-up router and I have a route of nine hops to a public web server. For each of the hops I tried the -R option. The fourth hop was the first, who answered the request. But the answer does not contain my public address. And although it was only the fourth hop the answer contains 9 addresses.
    – ceving
    Oct 8, 2014 at 10:26
  • just a moment, I'm preparing an exemple
    – feligiotti
    Oct 8, 2014 at 11:07
  • The ping -R shall be useful only for very limited hop. I say before that is a restricted way
    – feligiotti
    Oct 8, 2014 at 12:16
  • The same example does not work for my dial-up network. I have no idea why. Maybe NAT?
    – ceving
    Oct 8, 2014 at 13:51
  • Hi @Ceving, do a traceroute and then do a ping -R to the third hop you found in the traceroute. In that way you have the same schema I did to read the response. The nine route total mean go and come back, so if you do ping -R you can't see the full path, but only the last part
    – feligiotti
    Oct 8, 2014 at 15:47

According to RFC1812 the source address of ICMP message generated by the router should be that of the egress interface over which the packet would normally return to the sender.

In reality, it is very likely that you will face non-standard behavior where router will source the ICMP reply with the source of ingress interface. This usually make the traceroute much easier to read.

As a follow-up to YLearn's question I'm posting a network diagram and some outputs. Sample topology to illustrate how traceroute works

Let's assume we are souring the traceroute from R5's loopback to R1's loopback As you can see, the forward path is via R4-R2, while reverse path is R3-R4.

R4#sh ip route
Routing entry for
Known via "bgp 4", distance 20, metric 0
Tag 2, type external
Last update from 00:02:42 ago
Routing Descriptor Blocks:
*, from, 00:02:42 ago
  Route metric is 0, traffic share count is 1
  AS Hops 2

R1#sh ip route
Routing entry for
Known via "bgp 1", distance 20, metric 0
Tag 3, type external
Last update from 00:14:18 ago
Routing Descriptor Blocks:
*, from, 00:14:18 ago
  Route metric is 0, traffic share count is 1
  AS Hops 2
  Route tag 3
  MPLS label: none

The traceroute output from R5 looks as following:

Protocol [ip]:
Target IP address:
Source address:
Numeric display [n]:
Timeout in seconds [3]:
Probe count [3]:
Minimum Time to Live [1]:
Maximum Time to Live [30]:
Port Number [33434]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Type escape sequence to abort.
Tracing the route to
VRF info: (vrf in name/id, vrf out name/id)
1 208 msec 140 msec 100 msec
2 96 msec 44 msec 104 msec
3 224 msec 220 msec 112 msec

So while the actual ICMP traffic generated by R1 is going back to R5 via R3, the IP header of ICMP Unreachable message will have the source of ingress interface

In my experience this how Cisco and Juniper routers behave, I'm not sure about other vendors.

  • Probably just me, but the second sentence has me a bit confused. Are you saying it is common for a device on the internet to respond using the ingress interface of the traffic that caused the generation of the ICMP message? So if the traffic is received on Int1, and the ICMP message goes out Int2, it is sourced from Int1? Or are you referring to a different ingress interface (and if so, which)? In my experience, most routers work as the RFC states, using the egress interface of the message by default, and that in most cases this is the same interface the traffic was received on.
    – YLearn
    Oct 8, 2014 at 20:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.