XOS ping with record-route
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Get Direct Link
- Report Inappropriate Content
‎08-19-2015 09:18 AM
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
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
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Get Direct Link
- Report Inappropriate Content
‎08-21-2015 05:26 AM
i think these information should be part of the recent XOS command line reference. Can you arrange that?
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Get Direct Link
- Report Inappropriate Content
‎08-21-2015 02:38 AM
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...
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...
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Get Direct Link
- Report Inappropriate Content
‎08-20-2015 07:14 AM
Thanks for your rich explanation, now i am fully understand the use-case!
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Get Direct Link
- Report Inappropriate Content
‎08-20-2015 07:08 AM
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.
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Get Direct Link
- Report Inappropriate Content
‎08-20-2015 07:05 AM
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!
- 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!
