ICM / conectividad / BGP Multi-homing: ¿qué es este servicio?

BGP Multi-homing: ¿qué es este servicio?

1 octubre 2019 | Pablo Gómez

BGP Multi-homing es un protocolo de anuncio de prefijos de direcciones IP (IPv4 e IPv6), hacia operadores de tránsito de manera que esos anuncios de direcciones IP (redes) se van propagando a todos aquellos operadores de tránsito que tienen sus routers hablando BGP. Entre todos estos operadores y routers, se forma una red mallada de conexiones BGP. De este modo, podemos encontrar diversos caminos diferentes para llegar de un extremo al otro de forma automática, y por tanto tendremos un HA (alta disponibilidad), desde un punto de vista de caminos disponibles en Internet entre dos extremos.

Cada operador de tránsisto y cada site remoto final (por ejemplo ICM), dispone de un número de sistema autónomo. Este va ligado a un grupo determinado de direcciones de red IP. El protocolo BGP decide como mejor camino (en una de sus decisiones de routing). El camino más corto es el más óptimo, es decir, que para llegar a una red destino, elegirá aquel camino con el número de saltos de sistemas autónomos más corto. Sirva como ejemplo siguiente, desde un “looking glass” de Telia, la red 77.73.87.0/24:

En negrita podemos ver ese camino entre sistemas autónomos hasta llegar a esa red, la cual pertenece al sistema autónomo “1978786”.

BGP routing table entry for 77.73.87.0/24 Last Modified: Sep 19 12:18:54.413 for 5d21h Paths: (2 available, best #1)
Path #1: Received by speaker 0
3356 197876 62.115.58.254 from 62.115.58.254 (4.69.175.194)

Evidentemente, BGP tiene muchísimas más implicaciones en temas de decisiones de routing, no solo número de saltos de AS (Sistemas Autónomos). Pero para entenderlo de una forma sencilla, partimos de esta base.

Para más información al respecto, se puede consultar en Internet el algoritmo de decisión de mejor ruta en BGP.

¿Qué es BGP Multi-Homing?

Si anunciamos nuestros prefijos solo por un operador de tránsito, que evidente que hay un único punto de fallo. Ya sea porque pueda caer el interface físico de la conexión con el operador, o un fallo local de nuestro router. O incluso un fallo de routing en el backbone del operador. Si hay problemas en esa conexión BGP, los problemas de conectividad están asegurados. Para solventar este inconveniente, es tan fácil como poner otro enlace BGP Multi-homing con otro operador. También lo conveniente es poner otro equipo independiente del otro operador. Así la redundancia es completa. En un esquema aclaratorio (una imagen vale más que mil palabras):

BGP_Multihoming

Una aportación importante de BGP Multi-homing

Al estar propagando nuestra redes directamente, ¿existe una mayor vulnerabilidad a ataques? Si bien es cierto que las operadoras, cuando gestionan el BGP Multi-homing son responsables en alguna medida en proteger cualquier ataque desmesurado hacia nuestros servicios, en raras ocasiones actúan a no ser que les impacte directamente a sus backbones de tránsito. Así pues, se debe disponer de alguna solución frente a este tipo de situaciones.

En ICM disponemos de un sistema AntiDDoS en el operador de tránsito que nos avisa frente a tráficos inusuales. Entonces nosotros podemos activar las mitigaciones necesarias para evitar que nos lleguen esos ataques. Aún así, disponemos de antiDDoS en los Firewalls, pero además, BGP dispone de una herramienta llamada Community.

Las Communities

Las ”Communities “ nos permiten realizar muchas acciones sobre nuestros prefijos. La “Community” que ICM tiene implementada y preparada para actuar de una forma muy rápida es la que se denomina Blackhole. En un caso hipotético de un ataque hacia una dirección IP, la cual nos esté impactando al servicio de uno o varios clientes, nosotros mismos podemos añadir esa IP (puede ser una red o una IP concreta), a esa “Community”. De esta manera, estamos propagando al operador de tránsito que en todas sus conexiones BGP, si llega tráfico a esa dirección/es concreta, hace un drop a ese tráfico y por tanto protegemos en primera instancia de ese ataque.

Esto puede parecer algo normal, pero desde un punto de vista de rapidez de actuación, no lo es. Es muy distinto detectar un ataque, abrir un ticket al operador y esperar que la cola se vacíe hasta llegar la incidencia a alguien que lo entienda, y que probablemente tenga que escalar con el consiguiente retraso, que no que ICM lo detecte y en un minuto podamos bloquear el ataque.

En resumen, tecnológicamente es un salto importante pero en calidad de servicio es también un salto más importante todavía.