In reply to a post by MHC:

That sounds about right ... from what I understand the DNS request is sent and only when that is returned does it actually send the Ping request.

Unless the ping tool was coded poorly, and starts the timer prior the DNS lookup.

The routing theory sounds more plausible though (edit: especially given the ping to an IP address).

Edited by Oliver341 (Mon 08-Feb-16 13:33:31)

In reply to a post by caffn8me:

It likely to be routers along the way determining which way to route for the next hop - the results of which are then cached in a routing table so subsequent pings are quicker unless there's a problem with the route chosen and then it will change.

Time to build the NAT table entry on the home router. There is no need to determine the route, just to look one up from the RIB in RAM. The only time a route needs determining is when the routing table converges due to a topology change.

In reply to a post by Ignitionnet:

Time to build the NAT table entry on the home router.

Another good reason to put an end to NAT (as if one was needed).

@All

Which explains why it's quite normal and happens to all of us all the time, including the OP up until recently.

Not!

It's a huge difference.

I don't recall ever seeing this effect in the thousands of pings we see on these forums.

In reply to a post by RobertoS:

@All

Which explains why it's quite normal and happens to all of us all the time, including the OP up until recently.

Foible of the Netgear D7000 OP just purchased that it takes so long perhaps?

EDIT: I've seen this behaviour before from a router that might have been a Netgear, either way that's the most likely cause, it takes a little while to build the session before forwarding the flow.

Doesn't have to be done in serial, can fire the packet out and build the session later to ensure the response gets through if desired.

If it's a router with some weird and wonderful outbound DPI filtering as my RT-AC87U has that may also explain some delay on the flow set up.

Edited by deleted (Mon 08-Feb-16 14:26:53)

No, the routing changes and cache I'm referring to are those on intermediate routers between the source and the target. The CPE has no control over that.

Bear in mind that intermediate routers may load balance between several different external routes and routes do drop due to outages. The whole point about the internet is that it doesn't rely on routes set in stone.

In reply to a post by caffn8me:

No, the routing changes and cache I'm referring to are those on intermediate routers between the source and the target. The CPE has no control over that.

Bear in mind that intermediate routers may load balance between several different external routes and routes do drop due to outages. The whole point about the internet is that it doesn't rely on routes set in stone.

I'm aware of what you were referring to, I was just pointing out that it was wrong.

Unless you're suggesting that routers take 10ms+ to search their tables, and that the only time said routers are routing to Google is when this guy kicks off a ping of course, hence they've nothing in their FIB and have to do a full RIB lookup before punting to FIB.

In which case if you could explain why we all don't see the issue that'd be awesome.

PING www.google.co.uk (216.58.198.99) 56(84) bytes of data.
64 bytes from lhr25s07-in-f3.1e100.net (216.58.198.99): icmp_seq=1 ttl=54 time=13.3 ms
64 bytes from lhr25s07-in-f3.1e100.net (216.58.198.99): icmp_seq=2 ttl=54 time=13.0 ms

PING www.keycom.net (50.116.37.169) 56(84) bytes of data.
64 bytes from ronaldmcdonaldhouseorlando.org (50.116.37.169): icmp_seq=1 ttl=54 time=98.2 ms
64 bytes from ronaldmcdonaldhouseorlando.org (50.116.37.169): icmp_seq=2 ttl=54 time=98.0 ms

PING www.dslreports.com (64.91.255.98) 56(84) bytes of data.
64 bytes from www.dslreports.com (64.91.255.98): icmp_seq=1 ttl=51 time=109 ms
64 bytes from www.dslreports.com (64.91.255.98): icmp_seq=2 ttl=51 time=109 ms

Edited by deleted (Mon 08-Feb-16 15:09:31)

In reply to a post by RobertoS:

Ping the IP address instead of the domain name. See if it does the same. I don't like the DNS suggestion.

As you say, it isn't normal, and it couldn't issue the ping until it had the DNS reply anyway.

Well here is my connection pinging google.com and their IP...

ping google.com

Pinging google.com [216.58.198.206] with 32 bytes of data:
Reply from 216.58.198.206: bytes=32 time=22ms TTL=51
Reply from 216.58.198.206: bytes=32 time=22ms TTL=51
Reply from 216.58.198.206: bytes=32 time=23ms TTL=51
Reply from 216.58.198.206: bytes=32 time=23ms TTL=51

Ping statistics for 216.58.198.206:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 22ms, Maximum = 23ms, Average = 22ms

ping 216.58.198.206

Pinging 216.58.198.206 with 32 bytes of data:
Reply from 216.58.198.206: bytes=32 time=22ms TTL=51
Reply from 216.58.198.206: bytes=32 time=22ms TTL=51
Reply from 216.58.198.206: bytes=32 time=22ms TTL=51
Reply from 216.58.198.206: bytes=32 time=22ms TTL=51

Ping statistics for 216.58.198.206:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 22ms, Maximum = 22ms, Average = 22ms

And now for a traceroute...

tracert google.com

Tracing route to google.com [216.58.198.206]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms BTHUB4 [192.168.2.253]
2 57 ms 52 ms 21 ms 217.32.146.xxx
3 24 ms 19 ms 20 ms 217.32.146.126
4 21 ms 20 ms 20 ms 217.32.147.234
5 21 ms 21 ms 21 ms 213.120.178.65
6 21 ms 21 ms 21 ms 217.41.168.107
7 21 ms 21 ms 21 ms acc1-10GigE-0-2-0-4.l-far.21cn-ipp.bt.net [109.159.249.97]
8 21 ms 21 ms 21 ms core4-te0-9-0-18.faraday.ukcore.bt.net [109.159.249.11]
9 24 ms 24 ms 23 ms peer5-BE6.telehouse.ukcore.bt.net [213.121.193.175]
10 21 ms 41 ms 22 ms 109.159.253.67
11 23 ms 22 ms 22 ms 216.239.56.227
12 22 ms 23 ms 22 ms 216.58.215.195
13 23 ms 22 ms 22 ms lhr26s03-in-f14.1e100.net [216.58.198.206]

Trace complete.

tracert google.com

Tracing route to google.com [216.58.198.206]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms BTHUB4 [192.168.2.253]
2 20 ms 19 ms 20 ms 217.32.146.xxx
3 20 ms 20 ms 22 ms 217.32.146.126
4 21 ms 20 ms 20 ms 217.32.147.234
5 65 ms 97 ms 22 ms 213.120.178.65
6 21 ms 21 ms 21 ms 217.41.168.107
7 21 ms 21 ms 21 ms acc1-10GigE-0-2-0-4.l-far.21cn-ipp.bt.net [109.159.249.97]
8 22 ms 21 ms 21 ms core4-te0-9-0-18.faraday.ukcore.bt.net [109.159.249.11]
9 23 ms 22 ms 22 ms peer5-BE6.telehouse.ukcore.bt.net [213.121.193.175]
10 22 ms 22 ms 21 ms 109.159.253.67
11 23 ms 23 ms 23 ms 216.239.56.227
12 23 ms 22 ms 22 ms 216.58.215.195
13 22 ms 22 ms 23 ms lhr26s03-in-f14.1e100.net [216.58.198.206]

Trace complete.

I normally do 2 or 3 tracert's to get an average.

Seems to be ok for me at the moment, it wasn't earlier this morning, however we have lost connection twice today due to the wind and rain

My latency has always been a bit fubar, roll on FTTP.

Paul

Hi RobertoS

Tracerts are fine, I think Ignitionnet is onto something, please see his reply about Netgear.

Kev

Hi Ignitionnet

Ahh as you know I have the Netgear D7000l, wondered why it only just started happening, I only recently got it.

Thank You

Kev

Edited by blueboy (Mon 08-Feb-16 21:01:44)