5 ms·

What ever happened to network ops implementing RFC7454/BCP38! > Google is not a transit provider and traffic for 3rd party networks should never go through the

What ever happened to network ops implementing RFC7454/BCP38! > Google is not a transit provider and traffic for 3rd party networks should never go through the Google network. Why would you ever purposely configure your router to transit traffic via them?

toast0 9y ago
Google runs a couple different ASNs, so you might need to allow that as transit. BGP is notoriously easy to configure too open, but prefix limits might help; OTOH, dropping sessions to Google is going to cause a lot of headaches, so extra caution is required.
- justinjlynn 9y ago
  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.
  - notyourday 9y ago
    They can't. Google refuses to register its routes!
    - justinjlynn 9y ago
      If true, WTF Google...
      - trapperkeeper74 9y ago
        That's the point. Google trying to be special instead of playing nicely with other kids.
        justinjlynn 9y ago
        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 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 https://pastebin.com/raw/P9KMG0ri
        packetslave 9y ago
        Nice analysis. Passed along to the folks working on the (internal) postmortem for this outage.
        justinjlynn 9y ago
        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.
        justinjlynn 9y ago
- notyourday 9y ago
  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.

toast0 9y ago

Google runs a couple different ASNs, so you might need to allow that as transit. BGP is notoriously easy to configure too open, but prefix limits might help; OTOH, dropping sessions to Google is going to cause a lot of headaches, so extra caution is required.

justinjlynn 9y ago
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.
- notyourday 9y ago
  They can't. Google refuses to register its routes!
  - justinjlynn 9y ago
    If true, WTF Google...
    - trapperkeeper74 9y ago
      That's the point. Google trying to be special instead of playing nicely with other kids.
      - justinjlynn 9y ago
        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 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 https://pastebin.com/raw/P9KMG0ri
        packetslave 9y ago
        Nice analysis. Passed along to the folks working on the (internal) postmortem for this outage.
        justinjlynn 9y ago
        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.
        justinjlynn 9y ago
notyourday 9y ago
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.