3 ms·

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

by fach 9y ago

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.
      - notyourday 9y ago
        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.
- fundabulousrIII 9y ago
  whois -h whois.radb.net '!oMAINT-AS15169' | awk '/^route/ { if ($0 !~ /::/) {a++}} END {print a}' Fixed that for you.

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

by fach 9y ago

They don't?: https://pastebin.com/5ngq1cJi 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.

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.
    - notyourday 9y ago
      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.
fundabulousrIII 9y ago
whois -h whois.radb.net '!oMAINT-AS15169' | awk '/^route/ { if ($0 !~ /::/) {a++}} END {print a}' Fixed that for you.