Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

Ping Record option


does anybody have a detailed experience with the Extended Ping, especially the Record option?

My understanding is:

When a router receives an ICMP Echo Request packet with this option (and the router OS supports the record option), it adds it's (outgoing?) interface IP address to the record in the packet header.

When the target device receives the Echo Request packet, it replies with an Echo Reply packet copying all the recorded addresses from the original Request packet to the Reply packet header when sent.

And the routers on the path back keep updating the Reply packet header with their interface addresses.

I used this feature while checking routing within my network.

But it seems to bring an interesting feature:

When sending several Ping packets I noticed all the routers behaving like per-packet load-balancing were configured.

But it's not!

Does the Record option force each router to use CPU switching for each of those packets? (I think yes.)

And to apply the "packets originated by the router itself are always per-packet load-balanced" rule?

But those packets are not originated by the router ifself, in fact.

Am I missing something?



Everyone's tags (3)
Hall of Fame Super Gold

Re: Ping Record option

I'm not sure how various routers handle the record route option.

However, each ping is classified as a different flow, consequently you will see behaving as per-packet load balancing.

Re: Ping Record option


why would each ping be classified as a different flow when the source and destination IP address is still the same?

(I might have forgotten to say this clearly in my original question.)

I just found in the Ciscopress CEF book:

"...sending an ICMP echo with the record option forces all routers along the path to use the process-switching method of forwarding a frame. If an ICMP echo with the record option is successful and a standard ICMP echo is not, you can assume with some certainity that CEF is indeed a cause of your IP connectivity issue somewhere along the path."

And process-switching is using per-packet load balancing, isn't it?

It makes sense now.



Hall of Fame Super Gold

Re: Ping Record option

why would each ping be classified as a different flow when the source and destination IP address is still the same?

Because flows are indentified not with addresses only, but using protocol ports also.

Now it happens that ICMP doesn't have ports to do that, a consequence is the useful diagnostic property you ran into.

Re: Ping Record option


so far I understood CEF was using source/destination IP addresses only for load-sharing hash function by default?

And only some platforms were allowing  "mls ip cef load-sharing full" command to use L4 info?



Hall of Fame Super Gold

Re: Ping Record option

I may be wrong about ports use, in fact is a different calculation. In any case, ICMP is not "flowed" by design.

EDIT: Here's the option to include Layer 4 info in hash calculation:

Hall of Fame Super Silver

Re: Ping Record option

Hello Milan,

I do agree that CEF,is not used, because the packet needs deep inspection in order to add local node next-hop IP address as requested by the ping record option.

So the packet is punted to main CPU to use CEF terminology.

The fact that  it is process switched, also on devices on the path, ìis really interesting, and you see the effects of per packet load balancing that is the load balancing method used by process switching.

The note that using ICMP with record route option allows to find out a CEF "black hole" is useful: I usually use an ACL with an entry with log option to get the same result (to bypass a CEF entry that might be corrupted).

Hope to help


CreatePlease login to create content