Hacker News Reader

Comment by notyourday | Hacker News Reader

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.

View on HN

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.

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.

They don't?: https://pastebin.com/5ngq1cJi

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.

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.

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.

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.

This is 2017. We have had this debate in 1994.

We have also had this debate when smd proxy aggregated routes because certain network was announcing every /24s instead of /12s causing certain routers to run out of memory ( I'm pretty sure those were AGS+ ). It came known as "you will aggregate or I will aggregate it for you and you won't like it". While it was done just for a few hours the consequences were rather unforeseen.

Right around that time it was determined that no one outside the AS knows why the AS is choosing to announce routes in a specific way and those outside it were better not be "smart" over it. That was also around the time it was decided that one simply registered everything correctly and announced only what was registered and announced it the way it was registered.

whois -h whois.radb.net '!oMAINT-AS15169' | awk '/^route/ { if ($0 !~ /::/) {a++}} END {print a}' Fixed that for you.

>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.

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.

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?

Reply on news.ycombinator.com