Prefijos de Google en DE-CIX desagregados por los proveedores de tránsito IP

Prefijos de Google en DE-CIX desagregados por los proveedores de tránsito IP

Tras algunas conversaciones con nuestros clientes de DE-CIX, publicamos esta entrada del blog acerca de los prefijos del AS 15169, es decir, Google.  Estos prefijos engloban servicios no solo muy populares, sino imprescindibles hoy en día, con lo que la opción de utilizar el peering de DE-CIX parece sin duda la más acertada. Sin embargo, un número importante de los prefijos anunciados por los route-servers de DE-CIX se anuncian desagregados por todos los proveedores de tránsito IP que tienen peering directo con Google. No es que sea muy complicado tener peering directo con Google, tan sólo hay que solicitarlo en: https://isp.google.com/iwantpeering, pero puede darse el caso de que nos lo denieguen. Con un breve análisis de nuestras tablas de enrutamiento podemos ver que al menos los siguientes prefijos son anunciados por los principales operadores de tránsito con la longitud indicada, y al mismo tiempo total o parcialmente desagregados en prefijos /24:

  • 66.102.0.0/20
  • 74.125.0.0/16
  • 108.177.0.0/17
  • 173.194.0.0/16
  • 209.85.128.0/17
  • 216.58.192.0/19
  • 216.239.32.0/19
  • 66.102.0.0/20
  • 172.102.8.0/21
  • 172.217.0.0/16
  • 216.252.220.0/22

En este escenario, nuestro proceso BGP seleccionará el prefijo más específico y utilizará las rutas que anuncian los prefijos desagregados en /24, y nunca los prefijos que nos anuncia DE-CIX. El tráfico que estábamos esperando utilizara DE-CIX preferentemente se enrutará, por tanto, por las conexiones de tránsito de nuestros proveedores.

Para evitar esta situación se pueden implementar diversas soluciones, una de las cuales es filtrar los prefijos /24 que estamos recibiendo de manera que no se incluyan en nuestra tabla de enrutamiento BGP. El proceso BGP en este caso, seleccionará preferentemente las rutas anunciadas por DE-CIX por tener el AS-PATH más corto; al fin y al cabo para esto estamos haciendo peering en DE-CIX, no?

Una posible implementación del filtrado de prefijos en equipos CISCO es la siguiente:

Creamos una prefix-list que identifique dentro de cada prefijo los prefijos con máscara /24, /23…. Por ejemplo:

ip prefix-list 24GOOGLE seq 10 permit 66.102.0.0/20 ge 24
ip prefix-list 24GOOGLE seq 20 permit 74.125.0.0/16 ge 24
ip prefix-list 24GOOGLE seq 30 permit 108.177.0.0/17 ge 24
ip prefix-list 24GOOGLE seq 40 permit 173.194.0.0/16 ge 24
ip prefix-list 24GOOGLE seq 50 permit 209.85.128.0/17 ge 24
ip prefix-list 24GOOGLE seq 60 permit 216.58.192.0/19 ge 24
ip prefix-list 24GOOGLE seq 70 permit 216.239.32.0/19 ge 24
ip prefix-list 24GOOGLE seq 80 permit 66.102.0.0/20 ge 24
ip prefix-list 24GOOGLE seq 90 permit 172.102.8.0/21 ge 23
ip prefix-list 24GOOGLE seq 100 permit 172.217.0.0/16 ge 24
ip prefix-list 24GOOGLE seq 110 permit 216.252.220.0/22 ge 24

 

…………
neighbor X.X.X.X route-map TRANSIT1_IN in
neighbor X.X.X.X route-map TRANSIT1_OUT out
…………….

 

Añadimos un filtro previo a nuestra configuración actual en la que se deniegan en entrada los prefijos que concuerdan con los criterios de la lista de prefijos anterior:

route-map TRANSIT1_IN deny 10
match ip address prefix-list 24GOOGLE

route-map TRANSIT1_IN permit 20

…….

El resultado será que veremos desaparecer las rutas BGP con prefijos /24 – los que hayamos indicado en el listado de prefijos – y volveremos a ver el tráfico enrutado por el peering de DE-CIX sin perder redundancia por los operadores de trásito que, recordemos, también anuncian los prefijos comentados sin desagregar.