8

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.

traceroute

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?

Update

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 212.227.222.9
PING 212.227.222.9 (212.227.222.9) 56(124) bytes of data.
64 bytes from 212.227.222.9: icmp_req=1 ttl=57 time=47.4 ms
RR:     192.168.2.111
        169.254.1.1
        87.186.224.94
        62.154.76.34
        62.154.12.175
        212.227.117.13
        212.227.117.8
        10.71.3.253
        212.227.222.9


--- 212.227.222.9 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
93.192.75.247

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 '14 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 '14 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 '14 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 provide and accept your own answer. – Ron Maupin Aug 10 '17 at 15:54
6

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 10.2.105.178

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

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

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

192.168.1.133

10.189.51.61

10.2.105.177

10.2.105.178

10.2.105.178

10.189.48.1

192.168.1.254

192.168.1.133

----omitted----

64 bytes from 10.2.105.178: icmp_req=6 ttl=253 time=13.0 ms NOP RR:

192.168.1.133

10.189.51.61

10.2.105.177

10.2.105.178

10.2.105.218 ##change every time, Idon't know why##

10.189.48.1

192.168.1.254

192.168.1.133

  • 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 '14 at 10:26
  • just a moment, I'm preparing an exemple – feligiotti Oct 8 '14 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 '14 at 12:16
  • The same example does not work for my dial-up network. I have no idea why. Maybe NAT? – ceving Oct 8 '14 at 13:51
  • Hi @Ceving, do a traceroute 212.227.222.9 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 212.227.222.9 you can't see the full path, but only the last part – feligiotti Oct 8 '14 at 15:47
5

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 5.5.5.5 to R1's loopback 1.1.1.1. As you can see, the forward path is via R4-R2, while reverse path is R3-R4.

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

R1#sh ip route 5.5.5.5
Routing entry for 5.5.5.5/32
Known via "bgp 1", distance 20, metric 0
Tag 3, type external
Last update from 10.1.13.3 00:14:18 ago
Routing Descriptor Blocks:
* 10.1.13.3, from 10.1.13.3, 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:

R5#traceroute
Protocol [ip]:
Target IP address: 1.1.1.1
Source address: 5.5.5.5
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 1.1.1.1
VRF info: (vrf in name/id, vrf out name/id)
1 10.1.45.4 208 msec 140 msec 100 msec
2 10.1.24.2 96 msec 44 msec 104 msec
3 10.1.12.1 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 10.1.12.1.

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 '14 at 20:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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