OS Support
Speaking out the obvious: This is only for IPv4. RR — record rouce has been implemented on most operating systems that deal with TCP/IP stack. Below just a list where I find out by using the -h —help command or just in the vendors documentation:
In fact if you look very deep into your operating systems TCP/IP implementation and its tools, there is a very good chance you will find this IP option implemented and most probably working using the ping utility. Read the friendly manual.
RR can record 9 hops, in RX and TX. So in best case your destination is only 2-3 or max 4 hops away. Yes, RR has limits.
IOS
This is a record route example on IOS. Notify you need to use the IOS ping assistant to get to the Record option. There is no one-liner to record-route on IOS. Use the ping command only and hit the enter button:
Enable extended commands. by default this is disabled , Press the y key:
Go through the options until using _Loose, Strict, Record.. Then hit the r key:
. Loose, Strict, Record, Timestamp, Verbose[none]: r . The source interface in the given example is loopback0 . Choose whatever IP interface you need as source IP in current troubleshooting situation.
This is how to get to Route Record option show with command output:
R4#sh run int lo0 | i ip.ad ip address 10.255.255.4 255.255.255.255 R4#ping Protocol [ip]: Target IP address: 128.255.255.101 Repeat count [5]: 2 Datagram size [100]: Timeout in seconds [2]: Extended commands [n]: y Source address or interface: loopback0 Type of service [0]: Set DF bit in IP header? [no]: Validate reply data? [no]: Data pattern [0xABCD]: Loose, Strict, Record, Timestamp, Verbose[none]: r Number of hops [ 9 ]: Loose, Strict, Record, Timestamp, Verbose[RV]: Sweep range of sizes [n]: Type escape sequence to abort. Sending 2, 100-byte ICMP Echos to 128.255.255.101, timeout is 2 seconds: Packet sent with a source address of 10.255.255.4 Packet has IP options: Total option bytes= 39, padded length=40 Record route: (0.0.0.0) (0.0.0.0) (0.0.0.0) (0.0.0.0) (0.0.0.0) (0.0.0.0) (0.0.0.0) (0.0.0.0) (0.0.0.0) Reply to request 0 (1 ms). Received packet has options Total option bytes= 40, padded length=40 Record route: (10.0.0.5) (10.0.0.33) (10.0.0.34) (10.0.0.34) (10.0.0.6) (10.0.0.5) (0.0.0.0) (0.0.0.0) (0.0.0.0) End of list Reply to request 1 (1 ms). Received packet has options Total option bytes= 40, padded length=40 Record route: (10.0.0.5) (10.0.0.33) (10.0.0.34) (10.0.0.34) (10.0.0.6) (10.0.0.5) (0.0.0.0) (0.0.0.0) (0.0.0.0) End of list Success rate is 100 percent (2/2), round-trip min/avg/max = 1/1/1 ms R4#sh ip route 128.255.255.101 Routing entry for 128.255.255.101/32 Known via "ospf 1", distance 110, metric 201, type intra area Last update from 10.0.0.6 on Ethernet0/0, 00:28:54 ago Routing Descriptor Blocks: * 10.0.0.6, from 128.255.255.101, 00:28:54 ago, via Ethernet0/0 Route metric is 201, traffic share count is 1 Notice using IOS the 1-st output for the record route is empty. or full or zero’s, the is at first point. In the RFC 791 there is a passage about some details:
. The originating host must compose this option with a large enough route data area to hold all the address expected. The size of the option does not change due to adding addresses. The intitial contents of the route data area must be zero. . The initial contents of the route data are must be zero. Not sure if this is the reason behind it. But it matches the output, and looks like the author of the code implemented this literally, as described in the RFC. If you know something about this, or find something explaining this output, write me an email.
JUNOS
This is a ping record-route example. Some JUNOS versions seems to use ‘iputils’:
JUNOS > ping record-route 192.168.1.2 PING 192.168.1.2 (192.168.1.2): 56 data bytes 64 bytes from 192.168.1.2: icmp_seq=0 ttl=63 time=1.477 ms RR: 192.168.1.2 192.168.1.2 172.16.16.105 64 bytes from 192.168.1.2: icmp_seq=1 ttl=63 time=1.017 ms (same route) 64 bytes from 192.168.1.2: icmp_seq=2 ttl=63 time=1.254 ms (same route) . I have no access to JUNOS ATM. A friendly IRC user in the #junos channel on Libera.chat generated this output, using his gear or netlab. Thanks to Olen in #junos channel on Libera.chat. o/
Compare the upper output with the Linux example output below, it looks exactly the same. Notify the RR: prefix.
Notify the (same route) refers to the packet path output depicted above. Same path as shown above. It does NOT mean: same route in both directions, rx and tx the IP packet has taken.
EXOS
On the Extreme’s website, there is an suggestive interesting question:
How is PING with record-route option better than traceroute and how it can be used?
To find out why it is better, read the explanation on the vendors website actually it is explained more generic and lists interesting facts. It is the IP option 7 .
Example usage command short version
Example usage command using the source-interface or source-ip
ping 192.0.2.1 from 192.0.2.2 with record-route Example record-route output:
R1# ping 10.2.1.1 from 10.2.1.2 with record-route Ping(ICMP) 10.2.1.1: 4 packets, 8 data bytes, interval 1 second(s). 16 bytes from 10.2.1.1: icmp_seq=0 ttl=63 time=10 ms RR: 10.2.1.2 10.2.0.21 10.2.1.1 10.2.1.1 10.2.0.1 10.2.1.2 
Now the careful and experienced IP output reader will recognise the output is almost exact the same as in iptuils ping. See more below in the Linux entry.
Example traceroute output for comparison that the above is «actually» better than the depicted below using traceroute
R1# traceroute 10.2.1.1 from 10.2.1.2 traceroute to 10.2.1.1, 30 hops max 1 10.2.0.1 1 ms 4 ms 4 ms 2 10.2.1.1 4 ms 0 ms 0 ms 
Now compare both outputs for yourself. Make up your own mind.
Linux
help and manual
ping -R record route. This option records the route IP packets take towards the destination and back:
Verify the ping -help command:
ping -h . IPv4 options: -4 use IPv4 -b allow pinging broadcast -R record route . Consult the ping manual, and read the description:
man ping . -R ping only. 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. . With this IP option it is possible to record up to 9 hops.
IP configuration
This is a example linux node in a routed network environment. Node IP address is 10.4.10.53/24
node [~]$ ip add show eth0 2: eth0: mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 0c:c1:2b:46:00:00 brd ff:ff:ff:ff:ff:ff inet 10.4.10.53/24 brd 10.4.10.255 scope global eth0 valid_lft forever preferred_lft forever inet6 fe80::ec1:2bff:fe46:0/64 scope link valid_lft forever preferred_lft forever The routing table of the node, only a default route and its prefix, and the default-gateway 10.4.10.254
node [~]$ ip route default via 10.4.10.254 dev eth0 metric 202 10.4.10.0/24 dev eth0 scope link src 10.4.10.53 The target IP address is reachable via IP:
node [~]$ ping 10.255.255.203 PING 10.255.255.203 (10.255.255.203) 56(84) bytes of data. 64 bytes from 10.255.255.203: icmp_seq=1 ttl=253 time=1.25 ms 64 bytes from 10.255.255.203: icmp_seq=2 ttl=253 time=1.70 ms 64 bytes from 10.255.255.203: icmp_seq=3 ttl=253 time=1.58 ms --- 10.255.255.203 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 1.254/1.511/1.697/0.187 ms symmetric routing example
Ping route-record example, this is symmetric routing example:
node [~]$ ping -R 10.255.255.200" output note">📘 Note
Notify the (same route) refers to the packet path output depicted above. Same path as shown above. It does NOT mean: same route in both directions, rx and tx the IP packet has taken.