Extended ping vs regular ping

[nicholas-lang]

Im trying to understand the difference between these two pings below on my cisco 8200. 

xxxxxxxxxx#ping ip
Target IP address: x.x.x.41
Repeat count [5]: 2500
Datagram size [100]: 1500
Timeout in seconds [2]:
Extended commands [n]: y
Ingress ping [n]:
Source address or interface: x.x.x.42
DSCP Value [0]:
Type of service [0]:
Set DF bit in IP header? [no]: yes
Validate reply data? [no]:
Data pattern [0x0000ABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 2500, 1500-byte ICMP Echos to x.x.x.41, timeout is 2 seconds:
Packet sent with a source address of x.x.x.42
Packet sent with the DF bit set
!!!!OMMITTED FOR SPACE!!!!!!
Success rate is 100 percent (2500/2500), round-trip min/avg/max = 9/9/26 ms

But my standard ping

XXXXX#ping x.x.x.41 source x.x.x.42 size 1500 df-bit repeat 2500
Type escape sequence to abort.
Sending 2500, 1500-byte ICMP Echos to x.x.x.41, timeout is 2 seconds:
Packet sent with a source address of x.x.x.42
Packet sent with the DF bit set
.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!.!!!.!..!!!!!.!!!!!.!.!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!.!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!..!!!!!!!!!!!!!!!!!!!!!!!!.!!!
!!!.!!!!!!.!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!.!!!!..!!!..!.
Success rate is 90 percent (253/279), round-trip min/avg/max = 9/10/15 ms

I have discovered the issue here is with Verizon having faulty conega perkins and one other time they said it was a clean and scope of fiber required. But what i want to understand, why would the first extended ping not show any issues but the standard ping shows issues. What is the difference between the two above pings that would allow the ping to complete on one, but drop on the other. It appears i set the exact same setting on each but they act differently. I know its a issue with verizon circuit but doesnt quite make sense. 

[balaji.bandi]

I'm unsure why that is missed; I expect both outputs to be identical. or when you do the first time there was not issue, or the issue developed second time if assume that scenario

more you can find difference cisco already documented between these 2 ping type :

https://www.cisco.com/c/en/us/support/docs/ip/routing-information-protocol-rip/13730-ext-ping-trace.html#:~:text=The%20extended%20ping%20is%20used,and%20the%20privileged%20EXEC%20mode.

[Flavio Miranda]

@nicholas-lang 

 The difference is that on the second ping you set "df-bit" which means dont fragment.  And you set the packet size as 1500.

In the first ping you omitted the dont fragment and you did not set the packet size. Ping should be a very small packet and usually dont need to be fragmented. Unless you change this, as you did on the second ping.

 This means that between your router and the destination "Target IP address: x.x.x.41" there are devices in which the MTU does not support 1500 bytes and need to fragment. Ethernet link for example, supports MTU of 1500 but not all link does.

It should be nice to capture this traffic and look with Wireshark.

Try to ping with

ping x.x.x.41 source x.x.x.42 size 1460 df-bit repeat 2500

[nicholas-lang]

Hey Flavio Miranda,

On the first ping i do believe i had df-bit and a packet size set:

Datagram size [100]: 1500 = Should be setting the packet size to 1500

Set DF bit in IP header? [no]: yes = Setting the dont fragment option. 

But even if i remove the do not fragment out of the equation. i still get the similar issue. There has to be some other config that the extended ping is using that the standard ping is not:

xxxxxxx#ping x.x.x.41 source x.x.x.42 size 1500 repeat 2500
Type escape sequence to abort.
Sending 2500, 1500-byte ICMP Echos to x.x.x.41, timeout is 2 seconds:
Packet sent with a source address of x.x.x.x.42
!!!!!!!!!!!!!!!!.!!!!!!!!!!.!.!!!!!!!!!!!!!!!!!!!!!.!.!.!!!.!!.!!!!!.!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!.!!!!.!!!!!!!!!!.!!.!!
!!.!.!!!!!!!!!.!.!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!.!!!!!!!.!!
!!!!!!.!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!.!!!!!!!!!.!!!!!!
!!!!!!.!!!!!!.!.!!!.!.!!!!.!!!!!!!.!!!!!!!!.!!!!!!!!!!!!!!.!!!!!!!!!!!
!!.!..!!!!!!!!!.!!!.!!!!!!.!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.
Success rate is 90 percent (413/456), round-trip min/avg/max = 9/9/15 ms

So i started playing with some of the values in the extended ping. It seems setting this to yes, allows an additional set of options:

Extended commands [n]:

As the new "extended ping" if extended should even be used as i set it to no to extended commands this time, im seeing the same results with packet drops:

xxxxx#ping ip
Target IP address: x.x.x.41
Repeat count [5]: 2500
Datagram size [100]: 1500
Timeout in seconds [2]:
Extended commands [n]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 2500, 1500-byte ICMP Echos to x.x.x.41, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!.!!!!.
Success rate is 93 percent (41/44), round-trip min/avg/max = 10/10/11 ms

I think i will need to play around with this more, but it has to be one of these values that is different from the regular ping command that is allowing the extended pings to work vs standard:

DSCP Value [0]:
Type of service [0]:
Set DF bit in IP header? [no]: y
Validate reply data? [no]:
Data pattern [0x0000ABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:

So if i just press enter on this value Type of service [0]:  I would assume it would enter a TOS of 0. But i cannot set tos to 0 when doing standard pings. Maybe this is the culprit?

xxxxxxx#ping x.x.x.41 source x.x.x.42 size 1500 df-bit repeat 2500 tos ?
<1-255> Type of service

[Flavio Miranda]

I got it. In fact, the first is also fragmented.

What if you ping and not define the packet size to 1500? Just a normal ping?

[nicholas-lang]

Standard ping without MTU size works fine. But im not trying to troubleshoot the circuit, i know what the issue is. Im just trying to learn why this extended ping is working vs the regular ping i used so i can advance my troubleshooting knowledge. 

[Flavio Miranda]

this can easilly be a Bug on the IOS and the ping utility is actully sending normal ping instead setting the parameters.

 As I said, it would be nice to capture both traffic and see on Wireshark.  Chances are the first ping is going as default ping.

[MHM Cisco World]

I am not full sure But I think 

there is nothing different except I guess the number of ping per round 

first command make device send 2500 ping per round and if you have PO or hash or asymmetric the traffic will flow same path

second send 5 per round and total is 2500.

MHM

[nicholas-lang]

From my understanding, if i dont enter any value here, it should not be setting any values for these setting, correct? So its not sending a ping with dscp 0 and TOS 0.

DSCP Value [0]:
Type of service [0]:

If this is the case, then your answer is the only valid explanation i can see. With this circuit potentially being a bug in a conega perkins, as our RFC tests and ping going to this device from the other direction work with 1526 MTU. It must be something to do with pushing too much traffic at one time which with the higher mtu size, causes a bigger "jam" in the traffic. 

Also, when you mean the extended command sends 5 per round. You do not mean this section correct?

Repeat count [5]: 2500

[MHM Cisco World]

From my understanding, if i dont enter any value here, it should not be setting any values for these setting, correct? So its not sending a ping with dscp 0 and TOS 0.

DSCP Value [0]:
Type of service [0]:

Yes and No' some value like data size if you not add value the device use it defualt.

For dscp and type yes if yoh not set value the device will not use it.

MHM

[nicholas-lang]

Hmm, the dscp and TOS must not be the contributing factor here. I did edit my post on your previous answer, i dont believe you may have saw it:

Also, when you mean the extended command sends 5 per round. You do not mean this section, correct? You mean the functionality of extended vs standard ping?

Repeat count [5]: 2500

The only other section would possibly be Data pattern [0x0000ABCD]: . If standard pings use a different data pattern than this. 

[MHM Cisco World · Accepted solution]

let close topic one by one 

1- for number of ping per round I run lab and I will share result with you, I will send to you PM
2- for dscp if you not set the device use default value, I check this in lab also
3- what is pattern? the ping have two parts header abd data, data not send empty the device by default use random value like what you see 0x0000ABCD which is one bytes and send.

what can make pattern effect result try ping with verify and not verify data
what this will do, if the L1/L2 effect pattern the device will drop ping 

MHM

[nicholas-lang]

New update: After playing around with all the values. I believe the data pattern is the culprit. I am unsure what the standard ping data values are but when i modified the extended ping to Data pattern [0x0000ABCD]: 0x0000. I started getting packet loss again. I believe the standard data pattern is  The default is [0xABCD]  but i am not certain. To be honest, im not entirely sure what these values mean until i do more research. 

[nicholas-lang · Accepted solution]

I found the cause. It was in fact the data patterns. When i do a standard ping as above but with data AAAA, the pings pass successfully. I have been researching about data patterns and have yet to fully understand the exact reasoning on what exactly this does or how it handles the traffic differently. If anyone have any further information, i would greatly appreciate it.

xxxxxxxxxxxx#ping x.x.x.41 source x.x.x..42 size 1500 df-bit repeat 2500 data AAAA
Type escape sequence to abort.
Sending 2500, 1500-byte ICMP Echos to x.x.x.41, timeout is 2 seconds:
Packet sent with a source address of x.x.x.42
Packet sent with the DF bit set
Packet has data pattern 0xAAAA
!!!!!!!Omited for space
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (2500/2500), round-trip min/avg/max = 9/10/29 ms

xxxxxxxxxxxx#ping x.x.x.41 source x.x.x.42 size 1500 df-bit repeat 2500
Type escape sequence to abort.
Sending 2500, 1500-byte ICMP Echos to x.x.x.41, timeout is 2 seconds:
Packet sent with a source address of x.x.x.42
Packet sent with the DF bit set
!!!!!!!!!!!!!!.!!!!!.!!.!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.
!!!!!!!!!!!!!!!!!!!!!!.!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!.!!!!!
!!!!!!!!!.
Success rate is 93 percent (140/150), round-trip min/avg/max = 9/10/17 ms

[Flavio Miranda · Accepted solution]

Yet to find a doc deep diving on it but there are a few discussions here in the forum and on the internet. And probably people will provide more information here on your thread.

https://www.m00nie.com/ios-ping-with-random-data-patternpayload/

https://community.cisco.com/t5/other-network-architecture-subjects/back-to-back-t-1/m-p/385407

https://community.cisco.com/t5/routing/t1-test-patterns/td-p/650734

https://community.cisco.com/t5/routing/extended-ping-data-patterns-defined/td-p/555823