Cisco extended ping sweep command

Unanswered Question
Dec 1st, 2009

Can somebody explain a bit on how the extended ping sweep command works and how it works.

So far, all I can figured out is that it will ping the target ip with gradually larger ping sizes..

I'm also looking to see how the df-bit can help in determining mtu size. I know that setting it on means to set the packe to 'don't fragment'.

I have an issue in which regular pings ( all sizes work ) but after setting the df-bit to on, I now see ping packet drops and 'M'' responses. It usually have the dropped packets and M responses when the regular ping latency is over 80ms.. Target ip under 80ms or so have no packet drops or M responses.

Carrier claims this is normal.

http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080093f22.shtml

I'm specfially am interested in the following area.

Sweep min size [36]:
Sweep max size [18024]:
Sweep interval [1]:

Note the link have some explanations but not getting it..

Thanks all.

MK

!--- The count 179890 depends on the values of min sweep,
!--- max sweep, sweep interval and repeat count. Calculations are based on:

!--- 18024(high end of range) - 36(low end of range) = 17988(bytes in range)
!--- 17988(bytes in range) / 1(sweep interval) = 17988 (steps in range)
!--- 17988(bytes in range) + 1 (first value) = 17989(values to be tested)
!--- 17989(values to be tested) * 10(repeat count) = 179890 (pings to be sent)

!--- In order to decrease the value, increase the sweep interval or decrease
!--- the repeat count, or you can even decrease the difference between
!--- Minimum and Maximum sweep size.  Based on the previous example, the
!--- number 17890 is an expected value and tries to ping 17890 times.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 3 (2 ratings)
Loading.
mlund Fri, 12/04/2009 - 01:14

Hi

I'll give You an example

router#ping

Protocol [ip]:
Target IP address: 1.1.1.1
Repeat count [5]: 1    <<<<<<< this means, run the sweep one time
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]:
Sweep range of sizes [n]: y
Sweep min size [36]: 101    <<<<<<< this means, start with 101 bytes
Sweep max size [18024]: 110    <<<<<<< this means, end with 110 byte
Sweep interval [1]:     <<<<<<< this means,increase with one byte
Type escape sequence to abort.
Sending 10, [101..110]-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
!!!!!!!!!!    <<<<<<< this means, result is 10 packets ( 101byte, 102byte, 103byte and so on)
Success rate is 100 percent (10/10), round-trip min/avg/max = 8/9/12 ms

and now the same one except for sweep change

router#ping

Protocol [ip]:
Target IP address: 1.1.1.1
Repeat count [5]: 1
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]:
Sweep range of sizes [n]: y
Sweep min size [36]: 101
Sweep max size [18024]: 110
Sweep interval [1]: 2      <<<<<<< this means,increase with two byte
Type escape sequence to abort.
Sending 5, [101..110]-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
!!!!!    <<<<<<< this means, result is 5 packets ( 101byte, 103byte, 105byte 107byte, 109byte)
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/9/12 ms

df is used to set "don't fragment"

if you use it, be aware that it also stops the router from sending out packets that are bigger than the interface mtu.

example

roueter#sh int po2/0
POS2/0 is up, line protocol is up
  Hardware is Packet over SONET
  Internet address is 1.1.1.2/30
  MTU 4470 bytes, BW 155000 Kbit, DLY 100 usec, rely 255/255, load 1/255   <<<<<<<<<

router#ping

Protocol [ip]:
Target IP address: 1.1.1.1
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]:
Sweep range of sizes [n]: y
Sweep min size [36]: 4468
Sweep max size [18024]: 4472
Sweep interval [1]: 2
Type escape sequence to abort.
Sending 15, [4468..4472]-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
!!!!!!!!!!!!!!!
Success rate is 100 percent (15/15), round-trip min/avg/max = 8/10/12 ms

router#ping

Protocol [ip]:
Target IP address: 1.1.1.1
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface:
Type of service [0]:
Set DF bit in IP header? [no]: y    <<<<<<<<<<<<<<<<
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]: y
Sweep min size [36]: 4468
Sweep max size [18024]: 4472
Sweep interval [1]:
Type escape sequence to abort.
Sending 25, [4468..4472]-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
!!!..!!!..!!!..!!!..!!!.. <<<<<<<<<<<<<<<<<<<<<<<<<<   packet with 4471byte and 4472byte are not allowed to go out the interface
Success rate is 60 percent (15/25), round-trip min/avg/max = 8/9/12 ms

I can't explain the "M" response, it's not described in my document

/Mikael

neil.nolan Tue, 08/31/2010 - 11:46

I know this is a very old thread but after looking at the Jeff Doyle CCIE Routing TCP/IP book Vol II (page 11) regarding extended ping, he states a min MTU size of 1478 but the ping of 1500 bytes is returned and only the one packet of 2000 bytes isn't? Four packets are sent: 500, 1000, 1500 and 2000 bytes.

Does the packet sent also include IP and ICMP header information too and how does a 1500 byte packet get a response with a MTU limit of 1478 in the example (1-1).

Excerpt here: http://books.google.co.uk/books?id=JjdF2yWqJAwC&pg=PA10&lpg=PA10&dq=does+mtu+size+include+header+cisco+extended+ping&source=bl&ots=Cd_Ckj9Ewf&sig=ppUmVA7-SBB_pXMm5YTSW7sWj90&hl=en&ei=70t9TL2sIcKSjAesl-jSDg&sa=X&oi=book_result&ct=result&resnum=17&ved=0CFgQ6AEwEA#v=onepage&q&f=false]

Thanks

Julio Carvajal Fri, 03/08/2013 - 22:22

Hello Neil,

As you said:

I know this is a very old thread but I was reading the exact same thing and started to analize this and I got the answer for you .. At least that is what I think

As we already know the default MTU for an ethernet interface is 1500...

Now what about an ASDL connection ah? Here is what I got from an internet research

Let's fill all cells with data and avoid padding. 48 * 31 = 1488. One thing you are missing is that the last cell will have 8 bytes trailer (RFC 2364), so we need to reduce our data chunk by 8 bytes 1488 - 8 = 1480. Finally, 2 bytes PPP overhead gives us 1478 MTU

Just in case this helps someone as this did with me

Julio Carvajal

Peter Paluch Sat, 03/09/2013 - 01:52

Hello Neil and Julio,

@Neil, in Jeff Doyle's book, he sends four packets - 500B, 1000B, 1500B, 2000B, and each of these packets has DF bit set. Somewhere along the path towards the IP address he is pinging, there is a router whose outgoing interface's MTU is set to 1478. The first three packets can easily fit in, but the 2000B packet can not be transported through that interface without fragmentation - and that is prohibited thanks to the DF bit in the packet's header. So the router responds back to the sender with ICMP Unreachable message stating that the packet needed to be fragmented but the DF bit was set, and this ICMP Unreachable message also includes the maximum packet size (i.e. the MTU) that would still fit.

So in essence, this is the router that was forced to drop an oversized packet actively informing that packet's sender about the maximum size of packets which can pass through towards the same destination as the packet that was discarded. The size of 1478B was never indicated in the original ping packets - rather, it came back in the ICMP Unreachable response.

The MTU of 1478B seems to be arbitrary in the example in the book. There is no mention of any particular link-layer technology that was used between the routers. I assume that when creating this example, Jeff simply lowered the MTU on one of the links in the topology to the arbitrary chosen 1478B limit by command. I would not be making science out of it.

@Julio, would you mind discussing the MTU computation for ADSL? I believe the computation is different.

Assuming you are running PPPoE over ADSL, you are essentially carrying Ethernet frames over ATM. Focusing first on the Ethernet, its usual MTU is 1500B, and within these 1500B, you need to carry PPPoE header (6B) and PPP header (2B) so this reduces the remaining usable space for IP packets to 1500-6-2=1492B. This is also the IP MTU limit for a PPPoE session, and no lower.

The resulting Ethernet frame containing PPPoE+PPP+IP+higher protocols is then encapsulated into ATM AAL5 PDUs and the result is chopped into ATM cells. ATM cells are always of fixed size as you know, and in a sequence of ATM cells, you can carry transmission units of unlimited length, as the sequence of ATM cells themselves is not limited. However, in the case of PPPoE over ADSL (hence over ATM), the AAL5 PDU itself allows for at most 65535B in its payload, plus 8B AAL5 trailer and padding that does not count into the 65535B limit.

So to sum this up, ATM alone can carry PDUs of unlimited size, AAL5 can carry PDUs of at most 65535B, and PPPoE can carry PDUs (IP packets, for example) of at most 1492B. Hence, the resulting MTU of this entire transmission chain is still 1492B and not less.

You have mentioned RFC 2684 trailer - in fact, that trailer is the ATM AAL5 trailer and is just commented on, but not defined, by RFC 2684. What RFC 2684 defines, though, is an additional header that would be prepended before the Ethernet frame containing the PPPoE+PPP+IP+higher protocol, and would thus consume space in the AAL5 payload field. This additional RFC 2684 header would be 10B long is AAL5SNAP is used, or 2B if AAL5MUX is used. Still, this does not affect the MTU imposed by the PPPoE which is 1492B, deep below the limits of AAL5+RFC2684.

Of course I may be missing something so please feel free to discuss and disagree!

Best regards,

Peter

Julio Carvajal Tue, 03/12/2013 - 18:12

Hi Peter,

Hope you are doing fine. All that information has been great I really appreciate it,

As I said I just got it from a post on the internet related to the same question..

I just read that chapter and got the same question:

Is it a random value set on a router in the path or is there a specific technology that uses an MTU as 1478..

So while doing a google search I found that but based on your reply and the cases I have deal with regarding DSL connections my friend... I would say... You are right man

Regards,

Actions

This Discussion