ping request timed out

[user4879]

HI, I am newbie trying to see if I have packet loss,  I did ping google.co.uk -n 5 -l 1500

It says timed out but when I replace the bytes with 1400 instead of 1500, I get returns of 11 ms and no packet loss.

Should that mean I should set my mtu to also be 1400?

[user4879]

Could it just be the sky router? IF I ping google.co.uk -n 5

it returns normal and no packet loss, its only when I do ping google.co.uk -n 5 - l 1500

it says fragmentation 100% packet loss

[jamesn123]

@user4879 

It depends on whats set on your PC and any other devices between your PC & router such as a switches. Also some routers run at 1492MTU rather than 1500

[Eeeps]

The MTU includes both the IP header and the header of the protocol.

For ICMP packets (ping), the IP header is 20 bytes and the ICMP header 8 bytes.

Thus the maximum payload that an ICMP packet can transfer without fragmentation is MTU-20-8.

So if your MTU is 1500 then the maximum value for the payload is 1472 (-l parameter).

Normally you have to specify -f on the ping command to prevent fragmentation

.

ping ntp1.isp.sky.com -f -l 1472

Pinging ntp1.isp.sky.com [90.207.238.105] with 1472 bytes of data:
Reply from 90.207.238.105: bytes=1472 time=8ms TTL=249
Reply from 90.207.238.105: bytes=1472 time=8ms TTL=249
Reply from 90.207.238.105: bytes=1472 time=9ms TTL=249
Reply from 90.207.238.105: bytes=1472 time=8ms TTL=249

ping ntp1.isp.sky.com -f -l 1473

Pinging ntp1.isp.sky.com [90.207.238.105] with 1473 bytes of data:
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set

[IHateSteps]

 I must admit that when i first started out in 'professional' (eg paid for) networking the MTU size was only relevant in the context that there were numerous different LAN types and protocols on our 'multiprotocol' network.  Token Ring and ethernet were serious contenders (any guesses where I worked?).

However while MTU and packet sizes are relevant I looked back at your original post and questioned why you were using such large packet sizes to prove, or disprove, packet loss .  What you have discovered is that some part of the network between you and Google (not

[IHateSteps]

Oops... sorry...

As I was saying , you've discovered that a router or device between you and the server acting for google.co.uk dislikes packets more than a specific size.  That's not uncommon and for reasons quite rightly and correctly described above.

You will have noticed my use of the phrase 'acting for' above - you should be aware that few popular web sites nowadays actually connect directly to the internet, or at least serve their content to all users on the internet.  Most popular services nowadays use 'content delivery networks' and other technologies that make  their servers much more reachable by us 'common masses',  I won't mention CDNs any further - you can Google them.

When it comes to packlet loss, you need a quite structured approach to find the cause of the problem, and you can achieve this often using ping (with normal packet sizes) and tracerooute - a plan of identifying each 'hop' between you and the destination and then running pings (3-500 pings each) to them will give you a much better idea IF you have packet loss, and then where it lies.

However, unless you can show it is on the first 1-3 hops, it is likely you can do/or get sky to do much about it.