One needs to work really hard to do that if one does not re-invent the wheel:

Tag routes that you transit (or originate) with a community. Do not ever announce routes that do not have that community.

The issue is that Google insists on re-inventing a wheel, in process making it square.

That's certainly true. Generally speaking though, it's up to one's own network to know which ASs Google are routing for - and filter ranges not owned by any of those ASs. At worst you should route out of your known transit networks and (for the time google is being stupid) simply get non-optimal routing. Ideally your PNI agreement will include cost recovery for bad-acts like advertising non-owned space (but they probably won't) causing session drops and thus making your transit bill go up. Google being stupid (or any PNI, non-transit peer) should never cause your network to drop customer packets on the floor due to completely invalid routing.

They can't. Google refuses to register its routes!

If true, WTF Google...

That's the point. Google trying to be special instead of playing nicely with other kids.

Hmm, looking into radb via the following:

whois -h whois.radb.net '!iAS-GOOGLE,1' | head -n2 | tail -n1 | sed 's/ /\n/g' | xargs -n1 -i{} whois -h whois.radb.net '!oMAINT-{}' | tee google-radb

cat google-radb | grep '^route:' | grep -v '::' | sort | uniq | awk '{print $2}' | wc -l

yields 7762 announced unique IPV4 routes at least 10% of which (100% of checked routes) have a suitable reverse route query listed in radb via:

cat google-radb | grep '^route:' | grep -v '::' | awk '{print $2}' | shuf | head -n770 | xargs -n1 -i{} whois -h whois.radb.net '!r{},o' | tee google-radb.routesample.lookup | grep '^C' | wc -l

What are they announcing that's missing from information gathered there?

Edit: Hrmn... looking at http://thyme.rand.apnic.net data and comparing it with what google have registered in radb (among their various AS numbers)... they do indeed have a number of advertisements that are unregistered or are at least more specific than their registration (no exact match)

Results of the comparison at https://pastebin.com/raw/P9KMG0ri

Nice analysis. Passed along to the folks working on the (internal) postmortem for this outage.

Since I've had a moment to clean this up, here's a more accurate grepcidr (amazing tool for this -- aggregation is an awful hack and actually adds more noise than it takes away; sorry to your post mortem team) and some analysis/histo -- this is much clearer:

https://pastebin.com/raw/96sXXEe1

may want to change the grep on the data-raw-table to grep -wF '{}' ... the other might miss google AS in the middle of a multi-hop route.

Glad to be of some assistance. Please note that the aggregation (in the diff, to reduce extraneous noise from deaggregated announcements) may have introduced some artifacts -- but on the whole it should be accurate (assuming lookups were comprehensive, and that no google AS transits for third party networks). Would appreciate any feedback as to the methods. Cheers.

My eyes.

Shield them or be turned to stone, mere mortal! :D