11-09-2010 07:46 PM - edited 03-06-2019 01:58 PM
For a lab we had use the extended ping command with the Record option.
Question.....the first set is always 0.0.0.0, why is that? Part of my output is below.
I have already checked out : http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080093f22.shtml, but that didnt yield any answers.
SanJose2# ping
Protocol [ip]:
Target IP address: 192.168.100.1
Repeat count [5]: 2
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: 172.16.32.1
Type of service [0]:
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]: record
Number of hops [ 9 ]:
Loose, Strict, Record, Timestamp, Verbose[RV]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.100.1, timeout is 2 seconds:
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 (48 ms). Received packet has options
Total option bytes= 40, padded length=40
Record route:
(172.16.1.2)
(192.168.1.6)
(192.168.100.1)
Thank you,
Jimmy
Solved! Go to Solution.
11-09-2010 11:10 PM
Hi Jimmy,
IP packets using the Record Route option contain extra fields in their IP headers to store the individual traversed IP addresses into (at most 9). RFC 791 is specific about this:
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.
In other words, sender of this IP packet extends its IP header with a sufficient number of bytes to hold the necessary count of traversed IP addresses, and they should be filled with zeros. This is why you see the first ping request being sent with all zeros.
The question is actually, why does the extended ping send subsequent ping requests with this area being non-zero and instead containing the list of IP addresses from the last reply (at least it says it is doing so), thereby conflicting the RFC 791. Nevertheless, the initial value of this field is actually uninteresting, as this field is simply overwritten each time the packet traverses a network, so I would personally find this a nuisance, not a real problem.
Best regards,
Peter
11-09-2010 11:10 PM
Hi Jimmy,
IP packets using the Record Route option contain extra fields in their IP headers to store the individual traversed IP addresses into (at most 9). RFC 791 is specific about this:
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.
In other words, sender of this IP packet extends its IP header with a sufficient number of bytes to hold the necessary count of traversed IP addresses, and they should be filled with zeros. This is why you see the first ping request being sent with all zeros.
The question is actually, why does the extended ping send subsequent ping requests with this area being non-zero and instead containing the list of IP addresses from the last reply (at least it says it is doing so), thereby conflicting the RFC 791. Nevertheless, the initial value of this field is actually uninteresting, as this field is simply overwritten each time the packet traverses a network, so I would personally find this a nuisance, not a real problem.
Best regards,
Peter
11-09-2010 11:17 PM
Good explanation, thank you.
11-10-2010 01:30 AM
Hi Pete,
Noted with Thanks.
Ever Friendly,
ThiyaguVG.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide