High loss pinging Cloudflare but not Google and only during the day

SOLVED
Ahoste
Getting noticed

High loss pinging Cloudflare but not Google and only during the day

Hi,

 

I recently added Cloudflare address to test the connectivity of some networks.

We have this one network where users say they occasionally are without internet, I figured probably the provider.

Looking at the ping history of this network with 8.8.8.8 as destination it all seems well within normal numbers.

Looking at the 1.1.1.1 destination however I see huge spikes/waves of around 20% loss between 08:00h and 00:00h.

 

Since the google ping history seems fine I can't blame the intermittent drops on the provider.

Anyone that has seen this before? Or should I try with a different destination address and see what that gives?

 

Screen Shot 2021-07-19 at 12.29.14 PM.pngScreen Shot 2021-07-19 at 12.29.08 PM.pngScreen Shot 2021-07-19 at 12.28.51 PM.png

1 ACCEPTED SOLUTION

Accepted Solutions
PhilipDAth
Kind of a big deal

Re: High loss pinging Cloudflare but not Google and only during the day

>But how would you explain that it doesn't have this with Google? 

 

They will have multiple transit links.

The one that goes to Google has sufficient capacity.

The one that goes to CloudFlare does not.

 

You could consider buying Meraki Insight and doing application performance tracking - but it won't fix the problem.  99.99% it's your service provider.

https://meraki.cisco.com/products/meraki-insight/ 

View solution in original post

7 REPLIES 7
jbright
Getting noticed

Re: High loss pinging Cloudflare but not Google and only during the day

I like to use the Cisco Umbrella DNS addresses at 208.67.222.222 and 208.67.220.220

They tend to be very reliable.

 

Ahoste
Getting noticed

Re: High loss pinging Cloudflare but not Google and only during the day

Just added these, let's wait and see.

Cheers

PhilipDAth
Kind of a big deal

Re: High loss pinging Cloudflare but not Google and only during the day

This is almost certainly an issue with the ISP running out of transit capacity.

Ahoste
Getting noticed

Re: High loss pinging Cloudflare but not Google and only during the day

But how would you explain that it doesn't have this with Google? 

 

A rule to priorities traffic to Google's DNS?

Would I need to have some packet generator + packet capture to actually see what's going on? 

Or is there a way via Meraki dashboard to find what's happening?

 

thanks for your insight.

PhilipDAth
Kind of a big deal

Re: High loss pinging Cloudflare but not Google and only during the day

>But how would you explain that it doesn't have this with Google? 

 

They will have multiple transit links.

The one that goes to Google has sufficient capacity.

The one that goes to CloudFlare does not.

 

You could consider buying Meraki Insight and doing application performance tracking - but it won't fix the problem.  99.99% it's your service provider.

https://meraki.cisco.com/products/meraki-insight/ 

View solution in original post

Ahoste
Getting noticed

Re: High loss pinging Cloudflare but not Google and only during the day

Hmm thanks.

 

I wonder if the ISP would want or be able to do something about that when I provide them with some of these details.

 

I had insight a while ago running as a trial but never had the time to set it up properly and dig into it.

I'll check with our rep. and maybe give it another shot to get some more info.

 

Thanks for you help and ... insight! lol

PhilipDAth
Kind of a big deal

Re: High loss pinging Cloudflare but not Google and only during the day

>I wonder if the ISP would want or be able to do something about that when I provide them with some of these details.

 

You should do that.  It will cost them money (bigger link) to resolve.  So they probably won't do anything till enough customers complain.

Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.