cancel
Showing results for 
Search instead for 
Did you mean: 

XOS ping with record-route

XOS ping with record-route

M_Nees
Contributor III
What is the use-case for an ping the option "with record-route" ? How can use it reasonable? Command line reference do not tell anything deeper.

If i try it, i will get following output:

Slot-1 cnsha1sw001.24 # ping vr "VR-Default" continuous 10.0.8.44 from 10.64.4.1 with record-route

Ping(ICMP) 10.0.8.44: continuous packets, 8 data bytes, interval 1 second(s).
16 bytes from 10.0.8.44: icmp_seq=0 ttl=118 time=195 ms
RR:

16 bytes from 10.0.8.44: icmp_seq=1 ttl=118 time=190 ms
(same route)
16 bytes from 10.0.8.44: icmp_seq=2 ttl=118 time=185 ms
(same route)
16 bytes from 10.0.8.44: icmp_seq=3 ttl=118 time=189 ms
(same route)
^C
--- 10.0.8.44 ping statistics ---

Regards

10 REPLIES 10

M_Nees
Contributor III
i think these information should be part of the recent XOS command line reference. Can you arrange that?

Prashanth_KG
Extreme Employee
Matthias,

Glad we could help! Explanation is documented under the article https://gtacknowledge.extremenetworks.com/articles/Q_A/How-is-PING-with-record-route-option-better-t...

M_Nees
Contributor III
Thanks for your rich explanation, now i am fully understand the use-case!

Prashanth_KG
Extreme Employee
I think ping with record-route option would be extremely useful when you have an asymmetric routing to a specific destination where the traffic from the source to the destination takes one path and the return traffic takes another.

Prashanth_KG
Extreme Employee
Key points about Record-route option:

- When a record-route option is enabled while sending an ICMP request, the internet module of the routers in the path should include its interface address in which this packet is received.
- Since the record route option is enabled in the ICMP echo request, even while forwarding the ICMP echo replies, back to the source, the routers should include their IP interfaces along the path.
- so, with record route option, we will have a round trip path unlike trace route where we know only the intermediate hops to reach the destination.

For example, consider this setup:

SRC address(10.2.1.2) RTR1 (Egress interface 10.2.0.2) -------- Ingress interface(10.2.0.1) RTR2 (egress interface 10.2.0.21)----------- ingress interface(10.2.0.22) RTR3 (Destination address 10.2.1.1)

In the above path, if I do a ping with record route from 10.2.1.2 to 10.2.1.1 without specifying the source-address, the following is the response.

ping 10.2.1.1 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=9.536 ms
RR: 10.2.0.2
10.2.0.21
10.2.1.1
10.2.1.1
10.2.0.1
10.2.0.2

If I specify the record route from a specific source, I also see that the specified source-address is included in the recorded path.

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

If I do a traceroute, i see only the hops to reach the destination.

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

Hope this clarifies!
GTM-P2G8KFN