How to trace outgoing interfaces?

Question

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?

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?

Answer 1

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 :)

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

Answer 2

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.

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.