5 ms·

That's because for all the talk about Google its network engineering drives networks like a buzzed 19 year old drives his fathers Porsche. Google does not beli

That's because for all the talk about Google its network engineering drives networks like a buzzed 19 year old drives his fathers Porsche. Google does not believe in BGP filtering. They just don't. When someone brings up a BGP peering with Google that someone announces any prefixes to Google without first registering it. When asked "Huh? How do you ensure that I do not announce someone else's address space to you" Google's response becomes something akin to "We are Google, we have a very complicated system that prevents that from happening. It will detect the issue and address it automatically. We would build your filter lists based on those announcements" At the same time, the same people say that prefixes advertised to Google over PNIs take hours to propagate across the entire Google network. BGP filtering of prefixes to the address space registered to the peer is a basic hygiene, something that Google simply does not believe it has to do.

fach 9y ago
Based on the article, you probably should be s/Google/Verizon here. Yes, Google's export policy was misconfigured towards Verizon but Verizon blindly accepted and propagated these prefixes.
- notyourday 9y ago
  Since Google does not register or filter routes it receives it is impossible for VZ or anyone else to know what are the "correct" routes that Google advertises v. what should be filtered. Look, we have been though this before, in 1994, 1995, 1996, 1997, etc. Sprint (1239) used to filter based on AS_PATH. They stopped after FLIX incident.
  - fach 9y ago
    They don't?: https://pastebin.com/5ngq1cJi https://pastebin.com/5ngq1cJi
    - notyourday 9y ago
      Right now Google announces slightly more than 440 IPv4 routes over PNIs. The list in radb is : whois -h whois.radb.net '!oMAINT-AS15169' | grep ^route | awk '{print $2}' | grep -v "::" | wc -l 6180 I picked four prefixes. 3 were in RADB. 1 was not.
      - fach 9y ago
        Doing a 1:1 comparison between what you're currently receiving on import and RADB isn't completely fair given most folks who preallocate address blocks will register route objects long before they are actually used. What is preventing you from crafting your import policies based on this data? Google is clearly creating route objects for most of their prefixes and rejecting a handful of prefixes vs. the risk of accepting at worst a full table seems like a reasonable tradeoff. This is something Verizon could have done, and something other folks like Level3 have done for some time.
        notyourday 9y ago
        1) It is missing routes that they are advertising. 2) When asked "Are you using RADB/Altdb entries to filter routes/should we use those?" being told "No". If Google used that basic hygiene then it would not be announcing routes it does transit.
        fach 9y ago
        There's an important aspect of BGP you're overlooking: mutual acceptance. If one party exports a prefix, the other party can choose to either reject or accept the prefix. If the former party does not advertise the prefix or the latter party does not accept the prefix, no unidirectional forwarding path is established. Yes, Google could have derived their export policy based on their RADB entries, which would have prevented this issue. But Verizon could have also derived their import policy based on their RADB entries, which would have prevented this. While Google is at blame for fucking up their export policy, Verizon is at blame for simply accepting these prefixes.
bitmapbrother 9y ago
>Google does not believe in BGP filtering Doesn't the following indicate that neither does Verizon? In this case it appears Verizon had little or no filters, and accepted most if not all BGP announcements from Google which lead to widespread service disruptions. At the minimum Verizon should probably have a maximum-prefix limit on their side and perhaps some as-path filters which would have prevented the wide spread impact.
- notyourday 9y ago
  It accepts it from Google because Google does not register its prefixes. If I do not know what you should announce to me I have two choices: filter everything our making PNI useless or presume you are not a dolt and that you are only going to announce what you should transit which would work if you filter your peers. Except that Google does not believe in filtering its peers either which means that effectively whoever peers with Google has to presume that whatever Google announces is fine.
trapperkeeper74 9y ago
Many of these supercorporate web shops exhibit false-invincibility, amateurish hubris. IIRC don't most folks lock down their BGP routes to prevent many classes of failures?

fach 9y ago

Based on the article, you probably should be s/Google/Verizon here. Yes, Google's export policy was misconfigured towards Verizon but Verizon blindly accepted and propagated these prefixes.

notyourday 9y ago
Since Google does not register or filter routes it receives it is impossible for VZ or anyone else to know what are the "correct" routes that Google advertises v. what should be filtered. Look, we have been though this before, in 1994, 1995, 1996, 1997, etc. Sprint (1239) used to filter based on AS_PATH. They stopped after FLIX incident.
- fach 9y ago
  They don't?: https://pastebin.com/5ngq1cJi https://pastebin.com/5ngq1cJi
  - notyourday 9y ago
    Right now Google announces slightly more than 440 IPv4 routes over PNIs. The list in radb is : whois -h whois.radb.net '!oMAINT-AS15169' | grep ^route | awk '{print $2}' | grep -v "::" | wc -l 6180 I picked four prefixes. 3 were in RADB. 1 was not.
    - fach 9y ago
      Doing a 1:1 comparison between what you're currently receiving on import and RADB isn't completely fair given most folks who preallocate address blocks will register route objects long before they are actually used. What is preventing you from crafting your import policies based on this data? Google is clearly creating route objects for most of their prefixes and rejecting a handful of prefixes vs. the risk of accepting at worst a full table seems like a reasonable tradeoff. This is something Verizon could have done, and something other folks like Level3 have done for some time.
      - notyourday 9y ago
        1) It is missing routes that they are advertising. 2) When asked "Are you using RADB/Altdb entries to filter routes/should we use those?" being told "No". If Google used that basic hygiene then it would not be announcing routes it does transit.
        fach 9y ago
        There's an important aspect of BGP you're overlooking: mutual acceptance. If one party exports a prefix, the other party can choose to either reject or accept the prefix. If the former party does not advertise the prefix or the latter party does not accept the prefix, no unidirectional forwarding path is established. Yes, Google could have derived their export policy based on their RADB entries, which would have prevented this issue. But Verizon could have also derived their import policy based on their RADB entries, which would have prevented this. While Google is at blame for fucking up their export policy, Verizon is at blame for simply accepting these prefixes.

bitmapbrother 9y ago

>Google does not believe in BGP filtering Doesn't the following indicate that neither does Verizon? In this case it appears Verizon had little or no filters, and accepted most if not all BGP announcements from Google which lead to widespread service disruptions. At the minimum Verizon should probably have a maximum-prefix limit on their side and perhaps some as-path filters which would have prevented the wide spread impact.

notyourday 9y ago
It accepts it from Google because Google does not register its prefixes. If I do not know what you should announce to me I have two choices: filter everything our making PNI useless or presume you are not a dolt and that you are only going to announce what you should transit which would work if you filter your peers. Except that Google does not believe in filtering its peers either which means that effectively whoever peers with Google has to presume that whatever Google announces is fine.

trapperkeeper74 9y ago

Many of these supercorporate web shops exhibit false-invincibility, amateurish hubris. IIRC don't most folks lock down their BGP routes to prevent many classes of failures?