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

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.

New Member

Ping size question

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
New Member

Re: Ping size question

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 ....

Gold

Re: Ping size question

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.

2064
Views
0
Helpful
2
Replies
CreatePlease login to create content