blog/ posts/ Using ping for traceroute-IP option 7 Record Route
← Using linux NBD module to change GNS3 appliance default output method | posts | Ansible-lint playbooks sanitizer →
  1. OS Support
    1. IOS
    2. JUNOS
    3. EXOS
    4. Linux
      1. help and manual
      2. IP configuration
      3. symmetric routing example
      4. asymmetric routing example
    5. Windows
      1. native Windows
      2. pwsh-bin on linux
  2. Summary

Thanks to my employer and to my boss, chief of the networking department, I have been a networking class for a week. More than 10 networking engineers and technicians has been attending. During a discussion of traceroute and IP, one engineer, a "IP veteran", a person with decades of operating IP and routing experience, who worked for a carrier back then, mentioned something very interesting. This is a citation from what I remember, as best as I can:

...major Linux distributions, from what I know at least Kali, (using it now), but any other major Linux distrubution should have this, UNIX supports this, IOS, JUNOS and other networking platfroms I have been working with, ship the ping route-record or record-route utility. This is particulary helpful if it is needed to record the route IP packet takes on its path. Particulary if dealing for example with asymmetric routing... It has only limited count of hops, 9 hops...

There is a RFC for this called RFC 791 . Published in September 1981. Record Route is the IP option 7. Verify with the IANA website

To be honest, I was not aware there actually is the IP option 7. Now exploring this particular, very specific IP protocol option.

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:

  • IOS
  • JUNOS
  • EXOS
  • UNIX/Linux (iputils)
  • Microsoft Windows (ping)

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:

R1# ping

Enable extended commands. by default this is disabled , Press the y key:

...
Extended commands [n]: y
...

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.

📘 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.

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

Ping 192.0.2.1 record-route

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: <BROADCAST,MULTICAST,UP,LOWER_UP> 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="PING 10.255.255.200 (10.255.255.200) 56(124) bytes of data.
64 bytes from 10.255.255.200: icmp_seq=1 ttl=254 time=1.79 ms
RR:     10.4.10.53
        10.0.3.2
        10.0.3.2
        10.4.10.53

64 bytes from 10.255.255.200: icmp_seq=2 ttl=254 time=2.10 ms   (same route)
64 bytes from 10.255.255.200: icmp_seq=3 ttl=254 time=2.17 ms   (same route)

--- 10.255.255.200 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2007ms
rtt min/avg/max/mdev = 1.786/2.016/2.165/0.165 ms
📘 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.

IP record route only records the route_. It will show you nothing more but the recorded route, 9 recorded hops maximum. in TX (transmission) and RX (receiving). The analysis of the recorded output is up to the reader, The girls and guys sitting in front of the command line.

asymmetric routing example

Ping route-record example, this is asymmetric routing example. Compare this output carefully with the shown above and count the HOPS, point on which HOP in the shown below record, the IP packet gets back to the sender.

node [~]$ ping -R 10.255.255.203
PING 10.255.255.203 (10.255.255.203) 56(124) bytes of data.
64 bytes from 10.255.255.203: icmp_seq=1 ttl=254 time=2.30 ms
RR:     10.4.10.53
        10.0.2.2
        10.0.0.21
        10.0.2.5
        10.0.2.6
        10.0.3.6
        10.4.10.53

64 bytes from 10.255.255.203: icmp_seq=2 ttl=254 time=1.82 ms   (same route)
64 bytes from 10.255.255.203: icmp_seq=3 ttl=254 time=2.62 ms   (same route)
64 bytes from 10.255.255.203: icmp_seq=4 ttl=254 time=2.63 ms   (same route)

--- 10.255.255.203 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 1.821/2.341/2.629/0.328 ms

Notice the RR: prefix shown in the output. Same route refers in the output to same route as the upper output. It literally means: the IP packet has taken the (same route) as in previous display, i will not show it to you to not clutter the output and make it unreadable. It is the same as above, just you know it.

Windows

native Windows

The ping utility used in windows has the Record Route IP option. Verify the windows-commands/ping official reference.

...
/r <count>  Specifies the Record Route option in the IP header is used to record the 
path taken by the echo Request message and corresponding echo Reply 
message (available on IPv4 only). Each hop in the path uses an entry in the 
Record Route option. If possible, specify a count equal to or greater than 
the number of hops between the source and destination. The count must 
be a minimum of 1 and a maximum of 9.
...

A usage example taken from the document linked, to ping the destination 10.255.255.100 and record the route for 4 hops, type:

ping /r 4 10.255.255.100

No access to Windows nodes. Verify with the reference URL to the knowledge-base or vendor learn platform on your own.

pwsh-bin on linux

Was unsure where to put this, linux or windows, so now it it in the Windows section. I could imagine pwsh-bin for Linux uses the operating systems TCP/IP stack and has somehow limited IP features. Well without even knowing it just installed this pwsh-bin. There you have it:

PS /home/pbogusze> ping -h
...
For more details see ping(8).

Microsoft's pwsh-bin for Linux uses iputils. But does not have limited features, it is fully usable. At least according to the depicted documentation.

PS /home/pbogusze> ping -R -n fritz.box
PING fritz.box (10.0.249.1) 56(124) bytes of data.
64 bytes from 10.0.249.1: icmp_seq=1 ttl=64 time=0.334 ms
RR:     10.0.249.20
        10.0.249.1
        10.0.249.1
        10.0.249.20

64 bytes from 10.0.249.1: icmp_seq=2 ttl=64 time=0.346 ms       (same route)
64 bytes from 10.0.249.1: icmp_seq=3 ttl=64 time=0.348 ms       (same route)
^C
--- fritz.box ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2001ms
rtt min/avg/max/mdev = 0.334/0.342/0.348/0.006 ms
PS /home/pbogusze>

Technically, this might be only easy way to do this. And if the TCP/IP stack of linux is more powerful then add specific linux features into that powershell implementation on linux. Imagine for example crafting IPv6 packets using pwsh-bin and putting it immediately on the wire.

Summary

This option will not work in every network environment. In most small to middle enterprise networks MIGHT block this IP option and probably will. But in big network ( ~50 and up to hundreds of routers) and very big networks (more than thousand routers) this might be helpful. Environments where

  • ping
  • traceroute
  • telnet

are the only tools at hand to troubleshoot an networking issue and the only thing on e have at hand: is a router.

Well you might ask yourself, why bother to write a article about a IP legacy option. The truth is, it might help someone who is troubleshooting a networking problem, and has limited tools access. IP and a router are the only tools. There you go.

📗 Hint

Challenge yourself! Troubleshoot a networking problem using only a router, ping, traceroute, telnet

With limited tooling need to explore the used protocol and its implementation on a platform, You need to get creative in a different environment.