cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
4040
Views
0
Helpful
2
Replies

Ping size question

ciscoforum
Level 1
Level 1

Got a question about ping size from pc. Anybody can give a good explanation on this:

Getting timeout while the size getting bigger. I am thinking because the MTU is 1500, packets will be chopped at sender and re-assambled on the receiver. However the receiver may take longer to reassmle the packets than the icmp timeout value. So I increased the timeout value, but still timeout. Here is output:

This one is ok with size 25000 bytes

C:\Documents and Settings\ssun>ping -l 25000 10.220.1.119

Pinging 10.220.1.119 with 25000 bytes of data:

Reply from 10.220.1.119: bytes=25000 time=51ms TTL=125

Reply from 10.220.1.119: bytes=25000 time=51ms TTL=125

Reply from 10.220.1.119: bytes=25000 time=51ms TTL=125

Reply from 10.220.1.119: bytes=25000 time=51ms TTL=125

Ping statistics for 10.220.1.119:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

Minimum = 51ms, Maximum = 51ms, Average = 51ms

This one is not ok even increase the value to 500ms.

C:\Documents and Settings\ssun>ping -l 31001 -w 500 10.220.1.119

Pinging 10.220.1.119 with 31001 bytes of data:

Request timed out.

Request timed out.

Request timed out.

Request timed out.

Ping statistics for 10.220.1.119:

Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

2 Replies 2

sadasiva1
Level 1
Level 1

C:\>ping -l 65500 10.131.0.1

Pinging 10.131.0.1 with 65500 bytes of data:

Reply from 10.131.0.1: bytes=65500 time=17ms TTL=255

Reply from 10.131.0.1: bytes=65500 time=17ms TTL=255

Reply from 10.131.0.1: bytes=65500 time=16ms TTL=255

Reply from 10.131.0.1: bytes=65500 time=17ms TTL=255

Ping statistics for 10.131.0.1:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

Minimum = 16ms, Maximum = 17ms, Average = 16ms

C:\>

C:\>

C:\>

C:\>

C:\>

C:\>ping -l 65500 10.131.0.1 -w 500

Pinging 10.131.0.1 with 65500 bytes of data:

Reply from 10.131.0.1: bytes=65500 time=17ms TTL=255

Reply from 10.131.0.1: bytes=65500 time=16ms TTL=255

Reply from 10.131.0.1: bytes=65500 time=16ms TTL=255

Reply from 10.131.0.1: bytes=65500 time=16ms TTL=255

Ping statistics for 10.131.0.1:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

Minimum = 16ms, Maximum = 17ms, Average = 16ms

C:\>ping -l 65501 10.131.0.1 -w 500

Bad value for option -l, valid range is from 0 to 65500.

Its working fine for me ....

You issue is that something in the path is fragmenting and reassembling packets or maybe not reassembling. Hard to tell a device may just have a set maximum number of fragments it will allow.

Other than to generate large amounts of traffic it does little good to increase the packet above the smallest MTU in the path. Unless you are running gig with jumbo frames in the complete path you will seldom get more than 1500.

Since there are many issues with packet fragemntation in firewalls and even NAT it is not uncommon to have packet above a certain size that have issues. You many times see this even with smaller packets because of part of the data going via one path and other data going via another. Your goal should be to avoid packet fragmentation because of all the things in the path that can cause loss.

Short answer is some device in the path does not like these long packets.