Live data from Hacker News

Route Leak Impacting Cloudflare

cloudflarestatus.com

121–130 of 164 posts

Re: Route Leak Impacting Cloudflare

#122

Earlier quoted context omitted.

You are right, accidents happen to anyone. I cannot really be prepared for Cloudflare to go down though. What are my alternatives? Turn it off and route traffic to our servers directly? The DNS propagation takes longer than it just took for our website to be available again.

It shouldn't - Cloudflare keeps the TTL for their cache-enabled records very low (like 300 seconds). If you just log in to Cloudflare and click the "orange cloud" icon on the DNS tab, which points the domain back directly to your origin, you'll see the site up within a couple minutes.

Is 300 very low? I've occasionally seen 60 in the wild.

Re: Route Leak Impacting Cloudflare

#123

Earlier quoted context omitted.

It shouldn't - Cloudflare keeps the TTL for their cache-enabled records very low (like 300 seconds). If you just log in to Cloudflare and click the "orange cloud" icon on the DNS tab, which points the domain back directly to your origin, you'll see the site up within a couple minutes.

Is 300 very low? I've occasionally seen 60 in the wild.

It's very low compared to 24 hours, which is what used to be the most common setting and that (among other factors) was a big part of the "DNS propagation takes forever" mentality

Re: Route Leak Impacting Cloudflare

#125

What's weird is that 8.8.8.8 is also intermittently down for me. Are other people having issues with Google DNS too? https://i.imgur.com/3ySmVLW.png

Google rate limits ICMP to 8.8.8.8. It’s not meant to be used as your personal “is the internet up” test.

Seriously? If true that's an awfully quick bait and switch, even for Google.

Re: Route Leak Impacting Cloudflare

#126

Earlier quoted context omitted.

Google rate limits ICMP to 8.8.8.8. It’s not meant to be used as your personal “is the internet up” test.

Seriously? If true that's an awfully quick bait and switch, even for Google.

How is it bait and switch?

8.8.8.8 was never marketed as a "ping me to see if the Internet is up" service, as far as I know. Just as a fast, public DNS server.

Re: Route Leak Impacting Cloudflare

#127

Earlier quoted context omitted.

Seriously? If true that's an awfully quick bait and switch, even for Google.

How is it bait and switch? 8.8.8.8 was never marketed as a "ping me to see if the Internet is up" service, as far as I know. Just as a fast, public DNS server.

An important use of well known easy to type IP addresses is when you're mucking around to figure out if your upstream network isn't working. I could see if they attempted to set a new standard by just not responding to ICMP at all (although turning around an icmp echo takes less work than a DNS lookup...), but responding intermittently is actively harmful.

Re: Route Leak Impacting Cloudflare

#128
post #104

“AS396531 "Allegheny Technologies Incorporated" is leaking a better-reachable route for AS13335 "Cloudflare, Inc." towards AS701 "Verizon Business/UUnet" explaining the current LSE going on.” https://twitter.com/OhNoItsFusl/status/1143117619106652160

> AS396531 - Allegheny Technologies Incorporated That appears to be a steel/alloys company. Why are they operating BGP equipment?

Pittsburgh is a town that (used to be) run by steel. Even a few decades after that dominance, this particular company is still a $4B one on the S&P 400. I'm pretty sure this is the company that my grandfather worked at for decades; his brother did from high school to retirement (except during World War II). They apparently significantly polluted the air in the high school district next to mine ten years ago.

It doesn't surprise me at all that they are still a part of infrastructure, somehow.

Re: Route Leak Impacting Cloudflare

#130

Earlier quoted context omitted.

It has authentication and requires explicit configuration to form a neighbor relationship. BGP was designed for operators to implement a routing policy. In most implementations it allows everything by default with no modifications to route metadata, so if you do not set up your policy correctly you'll have issues like this.

It has authentication for only one hop , if routes propagated all the way up the chain with signatures, it would be much easier to block/limit bad AS behavior.

Your peering relationship is only for one hop. What it lacks is prefix/path validation, not authentication.
Post reply on HN