Por qué las comunidades BGP son mejores que los prefijos de ruta de AS

Internet, en su forma más pura, es un gráfico débilmente conectado de redes independientes (también llamado Sistemas autónomos (AS para abreviar)). Estas redes utilizan un protocolo de señalización llamado BGP (Border Gateway Protocol, Protocolo de puerta de enlace) para informar a sus vecinos (también denominados pares) sobre la accesibilidad de los prefijos IP (un grupo de direcciones IP) en y a través de su red. Parte de este intercambio contiene metadatos útiles sobre el prefijo IP que se utilizan para informar las decisiones de enrutamiento de la red. Un ejemplo de los metadatos es la ruta completa de AS, que consta de los diferentes sistemas autónomos por los que debe pasar un paquete IP para llegar a su destino.

Como todos queremos que nuestros paquetes lleguen a su destino lo más rápido posible, es una buena idea seleccionar la ruta de AS más corta para un prefijo determinado. Aquí es donde entra en juego algo que se conoce como añadir un prefijo.

Hablemos brevemente sobre cómo funciona Internet en su nivel más fundamental, antes de profundizar en algunos detalles esenciales.

Internet es, en esencia, una red interconectada masivamente de miles de redes. Cada red tiene dos cosas que son esenciales:

1. Un Número de sistema autónomo (ASN): un número entero de 32 bits que identifica de forma única una red. Por ejemplo, uno de los ASN de Cloudflare (tenemos varios) es 13335.

2. Prefijos IP: un prefijo IP es un rango de direcciones IP, agrupadas en potencias de dos. En el espacio IPv4, dos direcciones forman un prefijo /31, cuatro forman un /30, y así sucesivamente, hasta /0, que es la abreviatura de "todos los prefijos de IPv4". Lo mismo aplica para IPv6, pero en lugar de agregar 32 bits como máximo, puede agregar hasta 128 bits. La siguiente figura muestra esta relación entre los prefijos IP, a la inversa: un /24 contiene dos /25 que contienen dos /26 y así sucesivamente.

Para comunicarse en Internet, debe poder llegar a su destino y ahí es donde entran en juego los protocolos de enrutamiento. Permiten que cada nodo en Internet sepa a dónde enviar su mensaje (y que el receptor le devuelva un mensaje).

Como se mencionó anteriormente, estos destinos se identifican mediante direcciones IP y los rangos contiguos de direcciones IP se expresan como prefijos de IP. Usamos prefijos de IP para el enrutamiento como una optimización de la eficiencia: hacer un seguimiento de a dónde ir para cuatro mil millones (232) de direcciones IP en IPv4 sería increíblemente complejo y requeriría una gran cantidad de recursos. Cumplir con los prefijos reduce ese número a aproximadamente un millón.

Ahora recuerde que los Sistemas autónomos son operados y controlados de manera independiente. En la red de redes de Internet, ¿cómo le digo a la fuente A en alguna otra red que hay una ruta disponible para llegar al destino B en (o a través de) mi red? ¡Llega el BGP! BGP es el protocolo de puerta de enlace de frontera y se utiliza para señalar información de accesibilidad. Los mensajes de señal generados por el ASN de origen se denominan "anuncios" porque declaran a Internet que las direcciones IP en el prefijo están en línea y son accesibles.

Eche un vistazo a la figura anterior. ¡La fuente A ahora debería saber cómo llegar al Destino B a través de 2 redes diferentes!

Así es como se vería un mensaje de BGP real:

Como puede ver, los mensajes BGP contienen más que solo el prefijo IP (el bit NLRI) y la ruta, sino también muchos otros metadatos que proporcionan información adicional sobre la ruta. Otros campos incluyen comunidades (más información sobre esto posteriormente), así como MED o código de origen. MED es una sugerencia para otras redes conectadas directamente sobre qué ruta se debe tomar, si hay varias opciones disponibles, y gana el valor más bajo. El código de origen puede ser uno de tres valores: IGP, EGP o incompleto. IGP se establecerá si origina el prefijo a través de BGP, EGP ya no se usa (es un protocolo de enrutamiento antiguo) y se establece incompleto cuando distribuye un prefijo en BGP desde otro protocolo de enrutamiento (como IS-IS u OSPF).

BGP Message
    Type: UPDATE Message
    Path Attributes:
        Path Attribute - Origin: IGP
        Path Attribute - AS_PATH: 64500 64496
        Path Attribute - NEXT_HOP: 198.51.100.1
        Path Attribute - COMMUNITIES: 64500:13335
        Path Attribute - Multi Exit Discriminator (MED): 100
    Network Layer Reachability Information (NLRI):
        192.0.2.0/24

Ahora que la fuente A sabe cómo llegar al destino B a través de dos redes diferentes, ¡hablemos de la ingeniería de tráfico!

La ingeniería de tráfico es parte fundamental de la gestión diaria de cualquier red. Al igual que en el mundo físico, los operadores pueden implementar desviaciones para optimizar los flujos de tráfico de entrada (entrante) y de salida (saliente) de su red. La ingeniería de tráfico saliente es significativamente más fácil que la ingeniería de tráfico entrante porque los operadores pueden elegir entre redes vecinas e incluso priorizar un tráfico sobre otros. Por el contrario, la ingeniería de tráfico entrante requiere influir en una red que es operada por otra persona por completo. La autonomía y el autogobierno de una red son esenciales, por lo que los operadores utilizan las herramientas disponibles para informar o dar forma a los flujos de paquetes entrantes desde otras redes. La comprensión y el uso de esas herramientas es complejo y puede ser un desafío.

El conjunto disponible de herramientas de ingeniería de tráfico, tanto de entrada como de salida, se basa en la manipulación de los atributos (metadatos) de una ruta dada. Como estamos hablando de ingeniería de tráfico entre redes independientes, manipularemos los atributos de una ruta aprendida por EBGP. El BGP se puede dividir en dos categorías:

1. EBGP: comunicación BGP entre dos ASN diferentes

2. IBGP: comunicación BGP dentro del mismo ASN.

Si bien el protocolo es el mismo, se pueden intercambiar ciertos atributos en una sesión de IBGP que no se intercambian en una sesión de EBGP. Uno de estos es la preferencia local. Más información sobre esto en un momento.

Cuando una red está conectada a muchas otras redes y proveedores de servicio, puede recibir información de ruta al mismo prefijo IP de muchas de esas redes, cada una con atributos ligeramente diferentes. Luego, depende de la red receptora de esa información usar un algoritmo de selección de la mejor ruta BGP para elegir el "mejor" prefijo (y ruta), y usarlo para reenviar el tráfico IP. He puesto "mejor" entre comillas, ya que lo mejor es un requisito subjetivo. "Mejor" suele ser el más corto, pero lo que puede ser mejor para mi red, puede no ser el mejor resultado para otra red.

BGP considerará varios atributos de prefijo al filtrar las opciones recibidas. Sin embargo, en lugar de combinar todos esos atributos en un solo criterio de selección, la selección de la mejor ruta de BGP utiliza los atributos en niveles. En cualquier nivel, si los atributos disponibles son suficientes para elegir la mejor ruta, entonces el algoritmo termina con esa elección.

El algoritmo de selección de la mejor trayectoria BGP es extenso y contiene 15 pasos discretos para seleccionar la mejor trayectoria disponible para un prefijo dado. Dados los numerosos pasos, a la red le interesa decidir la mejor trayectoria lo antes posible. Los primeros cuatro pasos son los más utilizados e influyentes y se representan en la siguiente figura como tamices.

Elegir la ruta más corta posible suele ser una buena idea, por lo que la "longitud de la ruta AS" es un paso que se ejecuta al principio del algoritmo. Sin embargo, viendo la figura anterior, la "longitud de la ruta AS" aparece en segundo lugar, a pesar de ser el atributo para encontrar la ruta más corta. Así que hablemos del primer paso: la preferencia local.

Preferencia localLa preferencia local es una de las favoritas de los operadores porque les permite seleccionar manualmente una combinación de ruta+trayectoria de su elección. Es el primer atributo en el algoritmo porque es único para cualquier combinación de trayectoria dada de ruta+vecino+AS.

Una red establece la preferencia local al importar una ruta (después de conocer la ruta de una red vecina). Al ser una propiedad no transitiva, significa que es un atributo que nunca se envía en un mensaje EBGP a otras redes. Esto significa intrínsecamente, por ejemplo, que el operador de AS 64496 no puede establecer la preferencia local de las rutas a sus propios prefijos de IP (o en tránsito) dentro del vecino AS 64511. La incapacidad de hacerlo es en parte la razón por la que la ingeniería de tráfico entrante a través de EBGP es tan difícil.

La adición de prefijos aumenta artificialmente la longitud de la trayectoria ASDado que ninguna red puede establecer directamente la preferencia local para un prefijo dentro de otra red, la primera oportunidad de influir en las elecciones de otras redes es modificar la trayectoria AS. Si los siguientes saltos son válidos y la preferencia local para todas las diferentes rutas para una ruta dada es la misma, modificar la trayectoria AS es una opción obvia para cambiar la ruta que tomará el tráfico hacia su red. En un mensaje BGP, la adición de prefijos se ve así:

Antes:

Después:

BGP Message
    Type: UPDATE Message
    Path Attributes:
        Path Attribute - Origin: IGP
        Path Attribute - AS_PATH: 64500 64496
        Path Attribute - NEXT_HOP: 198.51.100.1
        Path Attribute - COMMUNITIES: 64500:13335
        Path Attribute - Multi Exit Discriminator (MED): 100
    Network Layer Reachability Information (NLRI):
        192.0.2.0/24

Específicamente, los operadores pueden agregar prefijos de la trayectoria AS. Al anteponer la trayectoria AS, un operador agrega sistemas autónomos adicionales a la ruta (por lo general, el operador usa su propio AS, pero eso no se aplica en el protocolo). De esta forma, una trayectoria AS puede ir desde una longitud de 1 hasta una longitud de 255. Como la longitud ahora ha aumentado drásticamente, no se elegirá esa trayectoria específica para la ruta. Al cambiar la trayectoria AS anunciada a diferentes pares, un operador puede controlar los flujos de tráfico que ingresan a su red.

BGP Message
    Type: UPDATE Message
    Path Attributes:
        Path Attribute - Origin: IGP
        Path Attribute - AS_PATH: 64500 64496 64496
        Path Attribute - NEXT_HOP: 198.51.100.1
        Path Attribute - COMMUNITIES: 64500:13335
        Path Attribute - Multi Exit Discriminator (MED): 100
    Network Layer Reachability Information (NLRI):
        192.0.2.0/24

Desafortunadamente, agregar prefijos tiene un problema: para ser el factor decisivo, todos los demás atributos deben ser iguales. Esto rara vez es cierto, especialmente en redes grandes que pueden elegir entre muchas rutas posibles hacia un destino.

BGP también se conoce coloquialmente como un motor de política comercial: no selecciona la mejor trayectoria desde el punto de vista del rendimiento. En cambio, y la mayoría de las veces, seleccionará la mejor trayectoria desde un punto de vista comercial. Los criterios comerciales pueden ser cualquier cosa, desde la eficiencia de la inversión (puerto) hasta el aumento de los ingresos y más. Esto puede sonar extraño pero, ya sea que lo crea o no, ¡esto es para lo que está diseñado el BGP! El poder (y la complejidad) del BGP es que permite que un operador de red tome decisiones de acuerdo con las necesidades, los contratos y las políticas del operador, muchas de las cuales no pueden reflejarse en las nociones convencionales del rendimiento de ingeniería.

Muchas redes (incluida Cloudflare) asignan una preferencia local según el tipo de conexión que se utilice para enviarnos las rutas. Un valor más alto es una preferencia más alta. Por ejemplo, las rutas aprendidas de las conexiones de la red de tránsito obtendrán una preferencia local más baja de 100 porque son las más costosas de usar. Las rutas aprendidas de red troncal serán de 150, las rutas de intercambio de Internet (IX) obtendrán 200 y, por último, las rutas de interconexión privada (PNI) obtendrán 250. Esto significa que para el tráfico de salida (saliente), la red de Cloudflare, de forma predeterminada, preferirá una ruta aprendida de PNI, incluso si hay disponible una trayectoria AS más corta a través de un vecino de tránsito o IX.

Parte de la razón por la que se prefiere un PNI a un IX es la confiabilidad, porque no hay una plataforma de conmutación de terceros involucrada que esté fuera de nuestro control, lo cual es importante porque operamos bajo la suposición de que todo el hardware puede interrumpirse y eventualmente lo hará. Otra parte de la razón es por motivos de eficiencia del puerto. Aquí, la eficiencia se define por el coste por megabit transferido en cada puerto. En términos generales, el coste se calcula de la siguiente manera:

((cost_of_switch / port_count) + transceiver_cost)

que se combina con el coste de conexión cruzada (puede ser mensual recurrente (MRC) o una tarifa única). El PNI es preferible porque ayuda a optimizar el valor al reducir el coste total por megabit transferido, ya que el precio unitario disminuye con una mayor utilización del puerto.

Este razonamiento es similar para muchas otras redes y es muy frecuente en las redes de tránsito. El BGP tiene que ver tanto con el coste y la política comercial como con el rendimiento.

Para simplificar, cuando me refiero a tránsitos, me refiero a las redes de tránsito tradicionales de nivel 1. Debido a la naturaleza de estas redes, tienen dos conjuntos distintos de pares de red:

1. Clientes (como Cloudflare)2. Pares sin liquidación (como otras redes de nivel 1)

En circunstancias normales, a los clientes de tránsito se les asignará una preferencia local más alta que la preferencia local utilizada para sus pares sin liquidación. Esto significa que, sin importar cuánto anteponga un prefijo, si el tráfico ingresa a esa red de tránsito, el tráfico siempre aterrizará en su interconexión con esa red de tránsito, no se descargará a otro par.

Aún se puede utilizar un prefijo si desea cambiar/descargar el tráfico de un solo enlace con un tránsito si tiene varios enlaces distinguidos con ellos o si la fuente de tráfico es un host múltiple detrás de varios tránsitos (y no tienen su propio libro de jugadas de preferencia local que prefiera un tránsito más que otro). Sin embargo, el tráfico de entrada que dirige el tráfico de un puerto de tránsito a otro a través de la adición de prefijos de la trayectoria AS tiene rendimientos decrecientes significativos: una vez que haya pasado tres prefijos, es poco probable que cambie mucho, si es que cambia, en ese punto.

Ejemplo

En el escenario anterior, sin importar el ajuste que haga Cloudflare en su trayectoria AS hacia AS 64496, el tráfico seguirá fluyendo a través de la interconexión Tránsito B <> Cloudflare, aunque la ruta Origen A → Tránsito B → Tránsito A → Cloudflare sea más corta desde el punto de vista de la trayectoria AS.

En este escenario, no ha cambiado mucho, pero el Origen A ahora es un host múltiple detrás de los dos proveedores de tránsito. En este caso, la adición de prefijos de ruta AS fue eficaz, ya que las rutas que se ven en el lado del origen A son tanto la trayectoria con prefijo y sin prefijo. Siempre que el Origen A no lleve a cabo ninguna ingeniería de tráfico de salida y trate ambas redes de tránsito por igual, la ruta elegida será Origen A → Tránsito A → Cloudflare.

Así que ahora hemos identificado un problema bastante importante dentro del ecosistema de Internet para los operadores: con las herramientas mencionadas anteriormente, no siempre es posible (algunos incluso dirían que es completamente imposible) dictar con precisión las trayectorias por las que el tráfico puede ingresar a su propia red, lo que reduce el control que el sistema autónomo tiene sobre su propia red. Afortunadamente, hay una solución para este problema: la preferencia local basada en la comunidad.

Algunos proveedores de tránsito permiten que sus clientes influyan en la preferencia local en la red de tránsito mediante el uso de comunidades de BGP. Las comunidades de BGP son un atributo transitivo opcional para un anuncio de ruta. Las comunidades pueden ser informativas ("Aprendí este prefijo en Roma"), pero también se pueden utilizar para desencadenar acciones en el lado receptor. Por ejemplo, Cogent publica las siguientes comunidades de acción:

Comunidad

Community	Local preference
174:10	10
174:70	70
174:120	120
174:125	125
174:135	135
174:140	140

Preferencia local

174:10

10

174:70

term ADV-SITELOCAL {
    from {
        prefix-list SITE-LOCAL;
        route-type internal;
    }
    then {
        as-path-prepend "13335 13335";
        accept;
    }
}

70

term ADV-SITELOCAL {
    from {
        prefix-list SITE-LOCAL;
        route-type internal;
    }
    then {
        community add COGENT_LPREF70;
        accept;
    }
}

174:120

120

174:125

125

174:135

135

174:140

140

Cuando sabe que Cogent utiliza las siguientes preferencias locales predeterminadas en su red:

Pares → Preferencia local 100Clientes → Preferencia local 130

Es fácil ver cómo podríamos usar las comunidades proporcionadas para cambiar la ruta utilizada. Sin embargo, es importante tener en cuenta que, dado que no podemos establecer la preferencia local de una ruta en 100 (o 130), la adición de la trayectoria AS sigue siendo en gran medida irrelevante, ya que la preferencia local nunca será la misma.

Por ejemplo, la siguiente configuración:

Estamos añadiendo prefijos al ASN de Cloudflare dos veces, lo que da como resultado una trayectoria AS total de tres. Sin embargo, seguíamos experimentando mucho (demasiado) tráfico en nuestro enlace de Cogent. En ese momento, un ingeniero podría agregar otro prefijo, pero para una red bien conectada como Cloudflare, si dos prefijos no lograron mucho, o tres, entonces cuatro o cinco tampoco harán mucho. En cambio, podemos aprovechar las comunidades de Cogent documentadas anteriormente para cambiar el enrutamiento dentro de Cogent:

La configuración anterior cambia el flujo de tráfico a esto:

¡Lo cual es exactamente lo que queríamos!

El prefijo de ruta AS sigue siendo útil y se usa como parte de la cadena de herramientas para que los operadores hagan ingeniería de tráfico, pero debe usarse con moderación. La preparación excesiva abre una red a secuestros de rutas más amplios, lo cual debe evitarse a toda costa. Como tal, se prefiere (y se recomienda) el uso de ingeniería de tráfico de ingreso basada en la comunidad. En los casos en que las comunidades no estén disponibles (o no estén disponibles para dirigir el tráfico de clientes), se pueden aplicar prefijos, pero motivo a los operadores a monitorear activamente sus efectos y que puedan revertirlos si no son efectivos.

Como nota al margen, P Marcos et al. ha publicado un artículo interesante sobre la adición de trayectorias AS, y analizo algunas de las tendencias observadas en relación con la adición de prefijos, por lo que realmente recomiendo que lo lea.: https://www.caida.org/catalog/papers/2020_aspath_prepending/aspath_prepending.pdf