Protocolo de puerta de enlace de frontera (BGP)

Border Gateway Protocol (BGP) o protocolo de puerta de enlace de frontera es un protocolo de puerta de enlace exterior estandarizado diseñado para intercambiar información de enrutamiento y accesibilidad entre sistemas autónomos (AS) en Internet. BGP se clasifica como un protocolo de enrutamiento de vector de ruta y toma decisiones de enrutamiento basadas en rutas, políticas de red o conjuntos de reglas configurados por un administrador de red.

El BGP utilizado para el enrutamiento dentro de un sistema autónomo se denomina Protocolo de puerta de enlace de borde interior, BGP interno (iBGP). Por el contrario, la aplicación de Internet del protocolo se denomina Protocolo de puerta de enlace de borde exterior, BGP externo (eBGP).

Historia

El protocolo Border Gateway fue esbozado en 1989 por ingenieros en la parte posterior de "tres servilletas manchadas de ketchup", y todavía se conoce como el protocolo de las tres servilletas. Se describió por primera vez en 1989 en RFC 1105 y ha estado en uso en Internet desde 1994. IPv6 BGP se definió por primera vez en RFC 1654 en 1994 y se mejoró a RFC 2283 en 1998.

La versión actual de BGP es la versión 4 (BGP4), que se publicó como RFC 4271 en 2006. RFC 4271 corrigió errores, aclaró ambigüedades y actualizó la especificación con prácticas comunes de la industria. La principal mejora fue la compatibilidad con el enrutamiento entre dominios sin clases (CIDR) y el uso de la agregación de rutas para reducir el tamaño de las tablas de enrutamiento. El nuevo RFC permite que BGP4 transporte una amplia gama de "familias de direcciones" IPv4 e IPv6. También se denomina Extensiones multiprotocolo, que es BGP multiprotocolo (MP-BGP).

Operación

Los vecinos BGP, llamados pares, se establecen mediante configuración manual entre los enrutadores para crear una sesión TCP en el puerto 179. Un altavoz BGP envía mensajes de mantenimiento de actividad de 19 bytes cada 30 segundos (valor predeterminado del protocolo, ajustable) para mantener la conexión. Entre los protocolos de enrutamiento, BGP es único en el uso de TCP como protocolo de transporte.

Cuando BGP se ejecuta entre dos pares en el mismo sistema autónomo (AS), se denomina BGP interno (iBGP o Interior Border Gateway Protocol). Cuando se ejecuta entre diferentes sistemas autónomos, se denomina BGP externo (eBGP o Exterior Border Gateway Protocol). Los enrutadores en el límite de un AS que intercambian información con otro AS se denominan enrutadores de borde o borde o simplemente pares eBGP y generalmente están conectados directamente, mientras que los pares iBGPpueden interconectarse a través de otros enrutadores intermedios. También son posibles otras topologías de implementación, como ejecutar eBGP peering dentro de un túnel VPN, lo que permite que dos sitios remotos intercambien información de enrutamiento de manera segura y aislada.

La principal diferencia entre iBGP y eBGP peering está en la forma en que las rutas que se recibieron de un par generalmente se propagan de manera predeterminada a otros pares:

• Las nuevas rutas aprendidas de un par eBGP se vuelven a anunciar a todos los pares iBGP y eBGP.
• Las nuevas rutas aprendidas de un par iBGP se vuelven a anunciar solo a todos los pares eBGP.

Estas reglas de propagación de rutas requieren efectivamente que todos los pares iBGP dentro de un AS estén interconectados en una malla completa con sesiones iBGP.

La forma en que se propagan las rutas se puede controlar en detalle a través del mecanismo de mapas de ruta. Este mecanismo consiste en un conjunto de reglas. Cada regla describe, para las rutas que coinciden con algunos criterios dados, qué acción se debe tomar. La acción podría ser descartar la ruta, o podría ser modificar algunos atributos de la ruta antes de insertarla en la tabla de enrutamiento.

Negociación de extensiones

Durante el protocolo de enlace de interconexión, cuando se intercambian mensajes ABIERTOS, los hablantes de BGP pueden negociar las capacidades opcionales de la sesión, incluidas las extensiones multiprotocolo y varios modos de recuperación. Si las extensiones multiprotocolo de BGP se negocian en el momento de la creación, el hablante de BGP puede prefijar la información de accesibilidad de la capa de red (NLRI) que anuncia con un prefijo de familia de direcciones. Estas familias incluyen IPv4 (predeterminado), IPv6, redes privadas virtuales IPv4/IPv6 y BGP de multidifusión. Cada vez más, BGP se usa como un protocolo de señalización generalizado para transportar información sobre rutas que pueden no ser parte de Internet global, como las VPN.

Para tomar decisiones en sus operaciones con pares, un par BGP utiliza una máquina de estados finitos (FSM) simple que consta de seis estados: inactivo; Conectar; Activo; AbrirEnviado; AbrirConfirmar; y Establecido. Para cada sesión entre pares, una implementación de BGP mantiene una variable de estado que rastrea en cuál de estos seis estados se encuentra la sesión. El BGP define los mensajes que cada par debe intercambiar para cambiar la sesión de un estado a otro.

El primer estado es el estado inactivo. En estado inactivo, BGP inicializa todos los recursos, rechaza todos los intentos de conexión BGP entrantes e inicia una conexión TCP con el par. El segundo estado es Conectar. En el estado Conectar, el enrutador espera a que se complete la conexión TCP y pasa al estado OpenSent si tiene éxito. Si no tiene éxito, inicia el temporizador ConnectRetry y pasa al estado Activo al expirar. En el estado Activo, el enrutador restablece el temporizador ConnectRetry a cero y vuelve al estado Conectar. En el estado OpenSent, el enrutador envía un mensaje Open y espera uno a cambio para pasar al estado OpenConfirm. Los mensajes de actividad se intercambian y, una vez recibidos con éxito, el enrutador pasa al estado Establecido. En el estado Establecido, el enrutador puede enviar y recibir: Keepalive; Actualizar;

• Estado inactivo:
  • Rechace todas las conexiones BGP entrantes.
  • Inicie la inicialización de los disparadores de eventos.
  • Inicia una conexión TCP con su par BGP configurado.
  • Escucha una conexión TCP de su par.
  • Cambia su estado a Conectar.
  • Si se produce un error en cualquier estado del proceso de FSM, la sesión BGP finaliza inmediatamente y vuelve al estado inactivo. Algunas de las razones por las que un enrutador no progresa desde el estado inactivo son:
    • El puerto TCP 179 no está abierto.
    • Un puerto TCP aleatorio sobre 1023 no está abierto.
    • Dirección de pares configurada incorrectamente en cualquiera de los enrutadores.
    • Número AS configurado incorrectamente en cualquiera de los enrutadores.
• Estado de conexión:
  • Espera una negociación TCP exitosa con el par.
  • BGP no pasa mucho tiempo en este estado si la sesión TCP se ha establecido correctamente.
  • Envía un mensaje abierto al compañero y cambia el estado a OpenSent.
  • Si ocurre un error, BGP pasa al estado Activo. Algunas razones del error son:
    • El puerto TCP 179 no está abierto.
    • Un puerto TCP aleatorio sobre 1023 no está abierto.
    • Dirección de pares configurada incorrectamente en cualquiera de los enrutadores.
    • Número AS configurado incorrectamente en cualquiera de los enrutadores.
• Estado activo:
  • Si el enrutador no pudo establecer una sesión TCP exitosa, entonces termina en el estado Activo.
  • BGP FSM intenta reiniciar otra sesión TCP con el par y, si tiene éxito, envía un mensaje de apertura al par.
  • Si vuelve a fallar, el FSM se restablece al estado inactivo.
  • Las fallas repetidas pueden ocasionar que el enrutador pase de los estados inactivo a activo. Algunas de las razones para esto incluyen:
    • El puerto TCP 179 no está abierto.
    • Un puerto TCP aleatorio sobre 1023 no está abierto.
    • Error de configuración de BGP.
    • Congestión en la red.
    • Interfaz de red de aleteo.
• Estado de envío abierto:
  • BGP FSM escucha un mensaje abierto de su par.
  • Una vez que se ha recibido el mensaje, el enrutador comprueba la validez del mensaje Abierto.
  • Si hay un error, se debe a que uno de los campos en el mensaje Abrir no coincide entre los pares, por ejemplo, la versión de BGP no coincide, el enrutador de emparejamiento espera un Mi AS diferente, etc. El enrutador luego envía un mensaje de notificación al par. indicando por qué ocurrió el error.
  • Si no hay ningún error, se envía un mensaje Keepalive, se configuran varios temporizadores y el estado cambia a OpenConfirm.
• Estado de confirmación abierta:
  • El par está escuchando un mensaje Keepalive de su par.
  • Si se recibe un mensaje Keepalive y no ha expirado ningún temporizador antes de la recepción del Keepalive, BGP pasa al estado Establecido.
  • Si un temporizador expira antes de que se reciba un mensaje Keepalive, o si ocurre una condición de error, el enrutador vuelve al estado inactivo.
• Estado establecido:
  • En este estado, los pares envían mensajes de actualización para intercambiar información sobre cada ruta que se anuncia al par BGP.
  • Si hay algún error en el mensaje de actualización, se envía un mensaje de notificación al par y BGP vuelve al estado inactivo.

Conectividad de routers y rutas de aprendizaje

En el arreglo más simple, todos los enrutadores dentro de un solo AS y que participen en el enrutamiento BGP deben configurarse en una malla completa: cada enrutador debe configurarse como un par de todos los demás enrutadores. Esto provoca problemas de escalado, ya que la cantidad de conexiones requeridas crece cuadráticamente con la cantidad de enrutadores involucrados. Para paliar el problema, BGP implementa dos opciones: reflectores de ruta (RFC 4456) y confederaciones BGP (RFC 5065). La siguiente discusión sobre el procesamiento básico de actualizaciones asume una malla iBGP completa.

Un enrutador BGP dado puede aceptar actualizaciones de información de accesibilidad de la capa de red (NLRI) de varios vecinos y anunciar NLRI al mismo conjunto de vecinos o a uno diferente. Conceptualmente, BGP mantiene su propia tabla de enrutamiento maestra, denominada base de información de enrutamiento local (Loc-RIB), separada de la tabla de enrutamiento principal del enrutador. Para cada vecino, el proceso BGP mantiene una base de información de enrutamiento adyacente conceptual, entrante (Adj-RIB-In) que contiene el NLRI recibido del vecino, y una base de información conceptual saliente (Adj-RIB-Out) para que se envíe el NLRI. El vecino.

El implementador del código BGP decide el almacenamiento físico y la estructura de estas tablas conceptuales. Su estructura no es visible para otros enrutadores BGP, aunque generalmente se pueden interrogar con comandos de administración en el enrutador local. Es bastante común, por ejemplo, almacenar los dos Adj-RIB y Loc-RIB juntos en la misma estructura de datos, con información adicional adjunta a las entradas de RIB. La información adicional le dice al proceso BGP cosas tales como si las entradas individuales pertenecen a los Adj-RIB para vecinos específicos, si el proceso de selección de rutas entre pares hizo que las políticas recibidas fueran elegibles para Loc-RIB y si las entradas Loc-RIB son elegibles para enviarse al proceso de administración de la tabla de enrutamiento del enrutador local.

BGP envía las rutas que considera mejores al proceso de la tabla de enrutamiento principal. Dependiendo de la implementación de ese proceso, la ruta BGP no se selecciona necesariamente. Por ejemplo, generalmente se prefiere un prefijo conectado directamente, aprendido del propio hardware del enrutador. Siempre que la interfaz de esa ruta conectada directamente esté activa, la ruta BGP al destino no se incluirá en la tabla de enrutamiento. Una vez que la interfaz se cae y no hay más rutas preferidas, la ruta Loc-RIB se instalaría en la tabla de enrutamiento principal.

BGP transporta la información con la que las reglas dentro de los enrutadores que hablan BGP pueden tomar decisiones de política. Parte de la información transportada que está explícitamente destinada a ser utilizada en decisiones políticas son comunidades y discriminadores de salida múltiple (MED).

El estándar BGP especifica una serie de factores de decisión, más que los que utiliza cualquier otro proceso de enrutamiento común, para seleccionar NLRI para ir a Loc-RIB. El primer punto de decisión para evaluar NLRI es que su atributo de siguiente salto debe ser alcanzable (o resoluble). Otra forma de decir que el próximo salto debe ser accesible es que debe haber una ruta activa, ya en la tabla de enrutamiento principal del enrutador, al prefijo en el que se puede alcanzar la dirección del próximo salto.

A continuación, para cada vecino, el proceso BGP aplica varios estándares y criterios dependientes de la implementación para decidir qué rutas deben entrar conceptualmente en Adj-RIB-In. El vecino podría enviar varias rutas posibles a un destino, pero el primer nivel de preferencia está en el nivel de vecino. Solo se instalará una ruta a cada destino en el Adj-RIB-In conceptual. Este proceso también eliminará, del Adj-RIB-In, cualquier ruta que haya retirado el vecino.

Cada vez que cambia un Adj-RIB-In conceptual, el proceso BGP principal decide si alguna de las nuevas rutas del vecino se prefiere a las rutas que ya están en el Loc-RIB. Si es así, los reemplaza. Si un vecino retira una ruta determinada y no hay otra ruta hacia ese destino, la ruta se elimina de Loc-RIB y BGP ya no la envía al administrador de la tabla de enrutamiento principal. Si el enrutador no tiene una ruta a ese destino desde cualquier fuente que no sea BGP, la ruta retirada se eliminará de la tabla de enrutamiento principal.

Después de verificar que el siguiente salto es alcanzable, si la ruta proviene de un par interno (es decir, iBGP), la primera regla a aplicar, según el estándar, es examinar el atributo de preferencia local. Si hay varias rutas iBGP del vecino, se selecciona la que tiene la preferencia local más alta, a menos que haya varias rutas con la misma preferencia local. En este último caso, el proceso de selección de ruta pasa al siguiente desempate. Si bien la preferencia local es la primera regla en el estándar, una vez que se verifica la accesibilidad del siguiente salto, Cisco y varios otros proveedores primero consideran un factor de decisión llamado peso que es local para el enrutador (es decir, no transmitido por BGP). Se prefiere la ruta con mayor peso.

La preferencia local, el peso y otros criterios pueden manipularse mediante la configuración local y las capacidades del software. Tal manipulación, aunque comúnmente utilizada, está fuera del alcance de la norma. Por ejemplo, el atributo de comunidad (ver a continuación) no se utiliza directamente en el proceso de selección de BGP. Sin embargo, el proceso vecino de BGP puede tener una regla para establecer la preferencia local u otro factor basado en una regla programada manualmente para establecer el atributo si el valor de la comunidad coincide con algún criterio de coincidencia de patrones. Si la ruta se aprendió de un par externo, el proceso BGP por vecino calcula un valor de preferencia local a partir de las reglas de la política local y luego compara la preferencia local de todas las rutas del vecino.

En el nivel por vecino, ignorando los modificadores de políticas específicos de la implementación, el orden de las reglas de desempate es:

1. Prefiere la ruta con la ruta AS más corta. Una ruta AS es el conjunto de números AS que deben atravesarse para llegar al destino anunciado. AS1–AS2–AS3 es más corto que AS4–AS5–AS6–AS7.
2. Preferir rutas con el valor más bajo de su atributo ORIGEN.
3. Prefiere las rutas con el valor más bajo del discriminador de salida múltiple o MED.

Una vez que se reciben las rutas candidatas de los vecinos, el software Loc-RIB aplica desempates adicionales a las rutas al mismo destino.

1. Si se aprendió al menos una ruta de un vecino externo (es decir, la ruta se aprendió de eBGP), descarte todas las rutas aprendidas de iBGP.
2. Preferir la ruta con el costo interior más bajo al siguiente salto, de acuerdo con la tabla de enrutamiento principal. Si dos vecinos anunciaron la misma ruta, pero se puede acceder a un vecino a través de un enlace de tasa de bits baja y al otro a través de un enlace de tasa de bits alta, y el protocolo de enrutamiento interior calcula el costo más bajo en función de la tasa de bits más alta, la ruta a través del enlace de tasa de bits alta sería preferible y otras rutas descartadas.

Si todavía hay más de una ruta vinculada en este punto, varias implementaciones de BGP ofrecen una opción configurable para compartir la carga entre las rutas, aceptando todas (o todas hasta cierto número).

3. Prefiera la ruta aprendida del hablante de BGP con el identificador de BGP numéricamente más bajo
4. Prefiere la ruta aprendida del altavoz BGP con la dirección IP del par más baja

Comunidades

Las comunidades BGP son etiquetas de atributos que se pueden aplicar a los prefijos entrantes o salientes para lograr algún objetivo común.Si bien es común decir que BGP permite que un administrador establezca políticas sobre cómo los ISP manejan los prefijos, esto generalmente no es posible, estrictamente hablando. Por ejemplo, BGP de forma nativa no tiene un concepto que permita que un AS le diga a otro AS que restrinja la publicidad de un prefijo solo a los clientes de intercambio de tráfico de América del Norte. En cambio, un ISP generalmente publica una lista de comunidades conocidas o propietarias con una descripción para cada una, lo que esencialmente se convierte en un acuerdo sobre cómo se deben tratar los prefijos. RFC 1997 define tres comunidades bien conocidas que tienen un significado global; NO_EXPORTACIÓN, NO_PUBLICIDAD y NO_EXPORTACIÓN_SUBCONFED. RFC 7611 define ACCEPT_OWN. Los ejemplos de comunidades comunes incluyen ajustes de preferencias locales, restricciones geográficas o de tipo de pares, identificación de ataques de denegación de servicio y opciones de anteposición de AS. Un ISP puede indicar que cualquier ruta recibida de clientes con la comunidad XXX:500 se anunciará a todos los pares (predeterminado), mientras que la comunidad XXX:501 solo se anunciará a Norteamérica. El cliente simplemente ajusta su configuración para incluir la comunidad o comunidades correctas para cada ruta, y el ISP es responsable de controlar a quién se le anuncia el prefijo. El usuario final no tiene capacidad técnica para hacer cumplir las acciones correctas que está tomando el ISP, aunque los problemas en esta área generalmente son raros y accidentales. y el ISP es responsable de controlar a quién se anuncia el prefijo. El usuario final no tiene capacidad técnica para hacer cumplir las acciones correctas que está tomando el ISP, aunque los problemas en esta área generalmente son raros y accidentales. y el ISP es responsable de controlar a quién se anuncia el prefijo. El usuario final no tiene capacidad técnica para hacer cumplir las acciones correctas que está tomando el ISP, aunque los problemas en esta área generalmente son raros y accidentales.

Es una táctica común para los clientes finales usar comunidades BGP (generalmente ASN:70,80,90,100) para controlar la preferencia local que el ISP asigna a las rutas anunciadas en lugar de usar MED (el efecto es similar). El atributo de comunidad es transitivo, pero las comunidades aplicadas por el cliente muy rara vez se propagan fuera del AS del siguiente salto. No todos los ISP dan a conocer sus comunidades al público.

El atributo de comunidad extendido BGP se agregó en 2006, con el fin de ampliar el rango de dichos atributos y proporcionar una estructura de atributo de comunidad por medio de un campo de tipo. El formato ampliado consta de uno o dos octetos para el campo de tipo seguido de siete o seis octetos para el contenido del atributo de comunidad respectivo. La definición de este atributo de comunidad extendida está documentada en RFC 4360. La IANA administra el registro para los tipos de comunidades extendidas de BGP.El atributo de comunidades extendidas en sí mismo es un atributo BGP transitivo opcional. Sin embargo, un bit en el campo de tipo dentro del atributo decide si la comunidad extendida codificada es de naturaleza transitiva o no transitiva. Por lo tanto, el registro de la IANA proporciona diferentes rangos de números para los tipos de atributos. Debido al rango de atributos extendido, su uso puede ser múltiple. RFC 4360 define de manera ejemplar la "Comunidad extendida específica de AS de dos octetos", la "Comunidad extendida específica de dirección IPv4", la "Comunidad extendida opaca", la "Comunidad de destino de ruta" y la "Comunidad de origen de ruta". Varios borradores de QoS de BGP también utilizan esta estructura de atributo de comunidad extendida para la señalización de QoS entre dominios.

Con la introducción de números AS de 32 bits, algunos problemas se hicieron evidentes de inmediato con el atributo de comunidad que solo define un campo ASN de 16 bits, lo que impide la coincidencia entre este campo y el valor ASN real. Desde RFC 7153, las comunidades extendidas son compatibles con ASN de 32 bits. RFC 8092 y RFC 8195 introducen un atributo de Gran Comunidad de 12 bytes, divididos en tres campos de 4 bytes cada uno (AS:función:parámetro).

Discriminadores multisalida

Los MED, definidos en el estándar BGP principal, originalmente estaban destinados a mostrar a otro AS vecino la preferencia del AS publicitario en cuanto a cuál de varios enlaces se prefiere para el tráfico entrante. Otra aplicación de los MED es anunciar el valor, típicamente basado en la demora, de múltiples AS que tienen presencia en un IXP, que imponen para enviar tráfico a algún destino.

Formato de encabezado de mensaje

compensación de bits	0–15	16–23	24–31
0	Marcador
32
64
96
128	Longitud	Escribe

• Marcador: Incluido por compatibilidad, debe establecerse en todos.
• Longitud: Longitud total del mensaje en octetos, incluida la cabecera.
• Tipo: Tipo de mensaje BGP. Se definen los siguientes valores:
  • abierto (1)
  • Actualizar (2)
  • notificación (3)
  • mantener vivo (4)
  • Ruta-Actualizar (5)

Escalabilidad interna

BGP es "el más escalable de todos los protocolos de enrutamiento".

Un sistema autónomo con BGP interno (iBGP) debe tener todos sus pares iBGP conectados entre sí en una malla completa (donde todos hablan con todos directamente). Esta configuración de malla completa requiere que cada enrutador mantenga una sesión con todos los demás enrutadores. En redes grandes, esta cantidad de sesiones puede degradar el rendimiento de los enrutadores, ya sea por falta de memoria o por los altos requisitos de proceso de la CPU.

Reflectores de ruta

Los reflectores de ruta (RR) reducen el número de conexiones requeridas en un AS. Un solo enrutador (o dos para redundancia) se puede convertir en un RR: otros enrutadores en el AS solo necesitan configurarse como pares para ellos. Un RR ofrece una alternativa al requisito lógico de malla completa de iBGP. El objetivo del RR es la concentración. Múltiples enrutadores BGP pueden interconectarse con un punto central, el RR, que actúa como un servidor RR, en lugar de interconectarse con cualquier otro enrutador en una malla completa. Todos los demás enrutadores iBGP se convierten en clientes RR.

Este enfoque, similar a la función DR/BDR de OSPF, proporciona a las redes grandes una escalabilidad iBGP adicional. En una red iBGP completamente mallada de 10 enrutadores, se necesitan 90 declaraciones CLI individuales (distribuidas en todos los enrutadores en la topología) solo para definir el AS remoto de cada par: esto se convierte rápidamente en un dolor de cabeza para administrar. Una topología RR puede reducir estas 90 declaraciones a 18, ofreciendo una solución viable para las redes más grandes administradas por los ISP.

Un RR es un único punto de falla, por lo tanto, se puede configurar al menos un segundo RR para proporcionar redundancia. Como es un par adicional para los otros 10 enrutadores, duplica aproximadamente la cantidad de declaraciones CLI, lo que requiere 11 × 2 − 2 = 20 declaraciones adicionales en este caso. En un entorno de múltiples rutas BGP, el RR adicional también puede beneficiar a la red al agregar rendimiento de enrutamiento local si los RR actúan como enrutadores tradicionales en lugar de solo una función de servidor RR dedicado.

Normas

Los servidores RR propagan rutas dentro del AS según las siguientes reglas:

• Si se recibe una ruta de un par que no es cliente, refleje solo a los clientes y a los pares eBGP.
• Si se recibe una ruta de un cliente par, refleje a todos los pares no clientes y también a los clientes pares, excepto el originador de la ruta y refleje a los pares eBGP.

Grupo

RR y sus clientes forman un clúster. Luego, la ID del clúster se adjunta a cada ruta anunciada por RR a sus pares clientes o no clientes. Un ID de clúster es un atributo BGP acumulativo y no transitivo, y cada RR debe anteponer el ID de clúster local a la lista de clústeres para evitar bucles de enrutamiento. Los RR y las confederaciones reducen la cantidad de pares iBGP para cada enrutador y, por lo tanto, reducen la sobrecarga de procesamiento. Los RR son una técnica pura de mejora del rendimiento, mientras que las confederaciones también se pueden utilizar para implementar políticas más detalladas.

Confederación BGP

Las confederaciones son conjuntos de sistemas autónomos. En la práctica común, Internet solo ve uno de los números AS de la confederación en su totalidad. Las confederaciones se utilizan en redes muy grandes donde se puede configurar un AS grande para abarcar AS internos más pequeños y manejables.

El AS confederado se compone de varios AS. Cada AS confederado solo tiene iBGP totalmente interconectado y tiene conexiones con otros AS dentro de la confederación. Aunque estos AS tienen pares eBGP con AS dentro de la confederación, los AS intercambian enrutamiento como si usaran iBGP. De esta forma, la confederación conserva la información sobre el siguiente salto, la métrica y la preferencia local. Para el mundo exterior, la confederación parece ser un solo AS. Con esta solución, los problemas de AS de tránsito de iBGP se pueden resolver, ya que iBGP requiere una malla completa entre todos los enrutadores BGP: gran cantidad de sesiones TCP y duplicación innecesaria del tráfico de enrutamiento.

Las confederaciones se pueden utilizar junto con los reflectores de ruta. Tanto las confederaciones como los reflectores de ruta pueden estar sujetos a oscilaciones persistentes a menos que se sigan reglas de diseño específicas que afectan tanto a BGP como al protocolo de enrutamiento interior.

Sin embargo, estas alternativas pueden presentar sus propios problemas, incluidos los siguientes:

• oscilación de ruta
• enrutamiento subóptimo
• aumento del tiempo de convergencia BGP

Además, los reflectores de ruta y las confederaciones BGP no se diseñaron para facilitar la configuración del enrutador BGP. Sin embargo, estas son herramientas comunes para arquitectos de redes BGP experimentados. Estas herramientas pueden combinarse, por ejemplo, como una jerarquía de reflectores de ruta.

Estabilidad

Las tablas de enrutamiento administradas por una implementación de BGP se ajustan continuamente para reflejar los cambios reales en la red, como enlaces que se rompen y se restauran o enrutadores que caen y vuelven a funcionar. En la red como un todo, es normal que estos cambios sucedan casi continuamente, pero para cualquier enrutador o enlace en particular, se supone que los cambios son relativamente poco frecuentes. Si un enrutador está mal configurado o mal administrado, puede entrar en un ciclo rápido entre estados inactivos y activos. Este patrón de retiro y re-anuncio repetidos conocido como cambio de ruta puede causar una actividad excesiva en todos los otros enrutadores que conocen el enlace roto, ya que la misma ruta se inyecta y retira continuamente de las tablas de enrutamiento. El diseño de BGP es tal que la entrega de tráfico puede no funcionar mientras se actualizan las rutas. En Internet,

Una característica conocida como amortiguación de aleta de ruta(RFC 2439) está integrado en muchas implementaciones de BGP en un intento de mitigar los efectos del cambio de ruta. Sin amortiguación, la actividad excesiva puede causar una gran carga de procesamiento en los enrutadores, lo que a su vez puede retrasar las actualizaciones en otras rutas y, por lo tanto, afectar la estabilidad general del enrutamiento. Con la amortiguación, el aleteo de una ruta decae exponencialmente. En la primera instancia, cuando una ruta deja de estar disponible y reaparece rápidamente, la amortiguación no tiene efecto para mantener los tiempos normales de conmutación por error de BGP. En la segunda aparición, BGP evita ese prefijo durante un cierto período de tiempo; las ocurrencias posteriores se agotan exponencialmente. Una vez que han cesado las anomalías y ha pasado un período de tiempo adecuado para la ruta infractora, se pueden restablecer los prefijos y hacer borrón y cuenta nueva. La amortiguación también puede mitigar los ataques de denegación de servicio;

También se sugiere en RFC 2439 (en "Opciones de diseño -> Supresión sensible a la estabilidad del anuncio de ruta") que la amortiguación de aletas de ruta es una característica más deseable si se implementa en sesiones de protocolo de puerta de enlace de borde exterior (sesiones eBGP o simplemente llamadas pares exteriores) y no en sesiones de protocolo de puerta de enlace de borde interior (sesiones iBGP o simplemente llamados pares internos); Con este enfoque, cuando una ruta cambia dentro de un sistema autónomo, no se propaga a los AS externos; cambiar una ruta a un eBGP tendrá una cadena de cambios para la ruta en particular a lo largo de la red troncal. Este método también evita con éxito la sobrecarga de la amortiguación de la aleta de ruta para las sesiones iBGP.

Sin embargo, investigaciones posteriores han demostrado que la amortiguación de aletas puede prolongar los tiempos de convergencia en algunos casos y puede causar interrupciones en la conectividad incluso cuando los enlaces no están aleteando. Además, a medida que los enlaces troncales y los procesadores de los enrutadores se han vuelto más rápidos, algunos arquitectos de redes han sugerido que la amortiguación de aletas puede no ser tan importante como solía ser, ya que los enrutadores pueden manejar los cambios en la tabla de enrutamiento mucho más rápido.Esto ha llevado al Grupo de trabajo de enrutamiento de RIPE a escribir que "con las implementaciones actuales de amortiguación de flaps BGP, NO se recomienda la aplicación de amortiguación de flaps en las redes ISP... Si se implementa la amortiguación de flaps, el ISP que opera esa red causará problemas secundarios". -efectos para sus clientes y los usuarios de Internet del contenido y los servicios de sus clientes... Es muy probable que estos efectos secundarios sean peores que el impacto causado por simplemente no ejecutar la amortiguación de aletas". Mejorar la estabilidad sin los problemas de la amortiguación de flaps es el tema de la investigación actual.

Crecimiento de la tabla de enrutamiento

Uno de los mayores problemas que enfrenta BGP y, de hecho, la infraestructura de Internet en su conjunto, es el crecimiento de la tabla de enrutamiento de Internet. Si la tabla de enrutamiento global crece hasta el punto en que algunos enrutadores más antiguos y menos capaces no pueden hacer frente a los requisitos de memoria o la carga de la CPU para mantener la tabla, estos enrutadores dejarán de ser puertas de enlace efectivas entre las partes de Internet que conectan. Además, y quizás aún más importante, las tablas de enrutamiento más grandes tardan más en estabilizarse (ver arriba) después de un cambio de conectividad importante, lo que hace que el servicio de red no sea confiable o incluso no esté disponible en el ínterin.

Hasta fines de 2001, la tabla de enrutamiento global crecía exponencialmente, lo que amenazaba con un eventual colapso generalizado de la conectividad. En un intento por evitar esto, los ISP cooperaron para mantener la tabla de enrutamiento global lo más pequeña posible mediante el uso de enrutamiento entre dominios sin clases (CIDR) y la agregación de rutas. Si bien esto ralentizó el crecimiento de la tabla de enrutamiento a un proceso lineal durante varios años, con la mayor demanda de alojamiento múltiple por parte de las redes de usuarios finales, el crecimiento fue una vez más superlineal a mediados de 2004.

512k día

Un desbordamiento similar al Y2K se desencadenó en 2014 para aquellos modelos que no se actualizaron adecuadamente.

Si bien una tabla BGP IPv4 completa a partir de agosto de 2014 (512 000 días) superaba los 512 000 prefijos, muchos enrutadores más antiguos tenían un límite de 512 000 (512 000–524 288) entradas en la tabla de enrutamiento. El 12 de agosto de 2014, las interrupciones resultantes de mesas llenas afectaron a eBay, LastPass y Microsoft Azure, entre otros.Varios enrutadores Cisco de uso común tenían TCAM, una forma de memoria direccionable por contenido de alta velocidad, para almacenar rutas anunciadas de BGP. En los enrutadores afectados, la TCAM se asignó de manera predeterminada como rutas IPv4 de 512k y rutas IPv6 de 256k. Si bien la cantidad informada de rutas anunciadas de IPv6 fue solo de 20k, la cantidad de rutas IPv4 anunciadas alcanzó el límite predeterminado, lo que provocó un efecto indirecto ya que los enrutadores intentaron compensar el problema mediante el uso de enrutamiento de software lento (en lugar del enrutamiento de hardware rápido a través de TCAM).). El método principal para abordar este problema implica que los operadores cambien la asignación de TCAM para permitir más entradas de IPv4, reasignando algunas de las TCAM reservadas para rutas IPv6, lo que requiere un reinicio en la mayoría de los enrutadores. El problema de 512k fue predicho por varios profesionales de TI.

Las asignaciones reales que elevaron el número de rutas por encima de 512k fue el anuncio de unas 15 000 rutas nuevas en poco tiempo, a partir de las 07:48 UTC. Casi todas estas rutas eran para Verizon Autonomous Systems 701 y 705, creadas como resultado de la desagregación de bloques más grandes, introduciendo miles de nuevas rutas / 24 y haciendo que la tabla de enrutamiento alcanzara las 515,000 entradas. Las nuevas rutas parecen haberse vuelto a agregar en 5 minutos, pero la inestabilidad en Internet aparentemente continuó durante varias horas. Incluso si Verizon no hubiera causado que la tabla de enrutamiento excediera las 512k entradas en el pico corto, habría sucedido pronto de todos modos a través del crecimiento natural.

El resumen de ruta se usa a menudo para mejorar la agregación de la tabla de enrutamiento global BGP, lo que reduce el tamaño de tabla necesario en los enrutadores de un AS. Considere que a AS1 se le ha asignado el gran espacio de direcciones de 172.16.0.0 / 16, esto se contaría como una ruta en la tabla, pero debido a los requisitos del cliente o por motivos de ingeniería de tráfico, AS1 quiere anunciar rutas más pequeñas y específicas de 172.16.0.0 / 18, 172.16.64.0 / 18 y 172.16.128.0 / 18. El prefijo 172.16.192.0/18 no tiene ningún host por lo que AS1 no anuncia una ruta específica 172.16.192.0/18 _ Todo esto cuenta como AS1 anunciando cuatro rutas.

AS2 verá las cuatro rutas de AS1 (172.16.0.0 / 16, 172.16.0.0 / 18, 172.16.64.0 / 18 y 172.16.128.0 / 18) y depende de la política de enrutamiento de AS2 decidir si desea o no tome una copia de las cuatro rutas o, como 172.16.0.0 / 16 se superpone a todas las demás rutas específicas, para almacenar solo el resumen, 172.16.0.0 / 16.

Si AS2 desea enviar datos al prefijo 172.16.192.0/18 , se enviarán a los enrutadores de AS1 en la ruta 172.16.0.0/16. En el enrutador de AS1, se descartará o se devolverá un mensaje ICMP de destino inalcanzable, según la configuración de los enrutadores de AS1.

Si AS1 luego decide abandonar la ruta 172.16.0.0/16, dejando 172.16.0.0/18, 172.16.64.0/18 y 172.16.128.0/18 , AS1 reducirá la cantidad de rutas que anuncia a tres . AS2 verá las tres rutas y, según la política de enrutamiento de AS2, almacenará una copia de las tres rutas o agregará los prefijos 172.16.0.0/18 y 172.16.64.0 / 18 a 172.16.0.0 / 17, reduciendo así el número de rutas que AS2 almacena en solo dos: 172.16.0.0 / 17 y172.16.128.0 / 18.

Si AS2 desea enviar datos al prefijo 172.16.192.0/18, se descartarán o se enviará un mensaje ICMP de destino inalcanzable a los enrutadores de AS2 (no AS1 como antes), porque 172.16.192.0/18 no estaría en la tabla de enrutamiento.

Agotamiento de números AS y ASN de 32 bits

El RFC 1771 (A Border Gateway Protocol 4 (BGP-4)) planeó la codificación de números AS en 16 bits, para 64510 posibles AS públicos, ya que los ASN 64512 a 65534 estaban reservados para uso privado (0 y 65535 prohibidos). En 2011, solo 15000 números AS todavía estaban disponibles y las proyecciones preveían un agotamiento completo de los números AS disponibles en septiembre de 2013.

RFC 6793 amplía la codificación AS de 16 a 32 bits (manteniendo el rango de AS de 16 bits de 0 a 65535 y sus números AS reservados), lo que ahora permite hasta 4 mil millones de AS disponibles. También se define un rango AS privado adicional en RFC 6996 (de 4200000000 a 4294967294, 4294967295 está prohibido por RFC 7300).

Para permitir el cruce de grupos de enrutadores que no pueden administrar esos nuevos ASN, se usa el nuevo atributo OT AS4_PATH.

Las asignaciones de ASN de 32 bits comenzaron en 2007.

Balanceo de carga

Otro factor que causa este crecimiento de la tabla de enrutamiento es la necesidad de equilibrar la carga de las redes de conexión múltiple. No es una tarea trivial equilibrar el tráfico de entrada a una red multi-homed a través de sus múltiples rutas de entrada, debido a la limitación del proceso de selección de ruta BGP. Para una red de host múltiple, si anuncia los mismos bloques de red en todos sus pares BGP, el resultado puede ser que uno o varios de sus enlaces entrantes se congestionen mientras que los otros enlaces permanecen infrautilizados, porque todas las redes externas seleccionaron eso. conjunto de caminos congestionados como óptimo. Como la mayoría de los demás protocolos de enrutamiento, BGP no detecta la congestión.

Para solucionar este problema, los administradores de BGP de esa red de host múltiple pueden dividir un gran bloque de direcciones IP contiguas en bloques más pequeños y ajustar el anuncio de la ruta para que los diferentes bloques se vean óptimos en diferentes rutas, de modo que las redes externas elijan una ruta diferente para llegar a diferentes direcciones. bloques de esa red multi-homed. Dichos casos aumentarán el número de rutas como se ve en la tabla BGP global.

Un método cada vez más popular para abordar el problema del equilibrio de carga es implementar puertas de enlace BGP/LISP (Locator/Identifier Separation Protocol) dentro de un punto de intercambio de Internet para permitir la ingeniería de tráfico de entrada a través de múltiples enlaces. Esta técnica no aumenta el número de rutas vistas en la tabla BGP global.

Seguridad

Por diseño, los enrutadores que ejecutan BGP aceptan rutas anunciadas de otros enrutadores BGP de manera predeterminada. Esto permite el enrutamiento automático y descentralizado del tráfico a través de Internet, pero también deja a Internet potencialmente vulnerable a interrupciones accidentales o maliciosas, conocidas como secuestro de BGP. Debido a la medida en que BGP está integrado en los sistemas centrales de Internet y la cantidad de redes diferentes operadas por muchas organizaciones diferentes que colectivamente conforman Internet, corregir esta vulnerabilidad (por ejemplo, introduciendo el uso de claves criptográficas para verificar la identidad de los enrutadores BGP) es un problema técnica y económicamente desafiante.

Extensiones

Una extensión de BGP es el uso de rutas múltiples: esto generalmente requiere MED, peso, origen y ruta AS idénticos, aunque algunas implementaciones brindan la capacidad de relajar la verificación de la ruta AS para esperar solo una longitud de ruta igual en lugar de los números AS reales. en la ruta que se espera que coincida también. Luego, esto se puede ampliar aún más con funciones como dmzlink-bw de Cisco, que permite una proporción de tráfico compartido en función de los valores de ancho de banda configurados en enlaces individuales.

Las extensiones multiprotocolo para BGP (MBGP), a veces denominadas BGP multiprotocolo o BGP multidifusión y definidas en IETF RFC 4760, son una extensión para (BGP) que permite distribuir en paralelo diferentes tipos de direcciones (conocidas como familias de direcciones). Mientras que el BGP estándar solo admite direcciones de unidifusión IPv4, el BGP multiprotocolo admite direcciones IPv4 e IPv6 y admite variantes de unidifusión y multidifusión de cada una. El BGP multiprotocolo permite que la información sobre la topología de los enrutadores IP con capacidad de multidifusión se intercambie por separado de la topología de los enrutadores de unidifusión IPv4 normales. Por lo tanto, permite una topología de enrutamiento de multidifusión diferente de la topología de enrutamiento de unidifusión. Aunque MBGP permite el intercambio de información de enrutamiento de multidifusión entre dominios,

BGP multiprotocolo también se implementa ampliamente en el caso de MPLS L3 VPN, para intercambiar etiquetas de VPN aprendidas para las rutas desde los sitios de los clientes a través de la red MPLS, con el fin de distinguir entre diferentes sitios de clientes cuando el tráfico de los otros sitios de clientes llega al proveedor. Enrutador perimetral (enrutador PE) para enrutamiento.

Usos

BGP4 es estándar para el enrutamiento de Internet y se requiere de la mayoría de los proveedores de servicios de Internet (ISP) para establecer el enrutamiento entre ellos. Las redes IP privadas muy grandes utilizan BGP internamente. Un ejemplo es la unión de varias redes grandes de Open Shortest Path First (OSPF), cuando OSPF por sí solo no se escala al tamaño requerido. Otra razón para usar BGP es la multiconexión de una red para una mejor redundancia, ya sea a múltiples puntos de acceso de un solo ISP oa múltiples ISP.

Implementaciones

Los enrutadores, especialmente los pequeños diseñados para uso en oficinas pequeñas/oficinas domésticas (SOHO), pueden no incluir el software BGP. Algunos enrutadores SOHO simplemente no son capaces de ejecutar BGP o usar tablas de enrutamiento BGP de cualquier tamaño. Otros enrutadores comerciales pueden necesitar una imagen ejecutable de software específico que contenga BGP o una licencia que lo habilite. Los paquetes de código abierto que ejecutan BGP incluyen GNU Zebra, Quagga, OpenBGPD, BIRD, XORP y Vyatta. Es menos probable que los dispositivos comercializados como conmutadores de capa 3 admitan BGP que los dispositivos comercializados como enrutadores, pero los conmutadores de capa 3 de gama alta generalmente pueden ejecutar BGP.

Los productos comercializados como conmutadores pueden o no tener una limitación de tamaño en las tablas BGP, como 20 000 rutas, mucho más pequeñas que una tabla de Internet completa más rutas internas. Estos dispositivos, sin embargo, pueden ser perfectamente razonables y útiles cuando se utilizan para el enrutamiento BGP de una parte más pequeña de la red, como una confederación-AS que representa una de varias empresas más pequeñas que están conectadas, por una red troncal BGP de redes troncales, o una pequeña empresa que anuncia rutas a un ISP pero solo acepta una ruta predeterminada y quizás una pequeña cantidad de rutas agregadas.

Un enrutador BGP que se usa solo para una red con un único punto de entrada a Internet puede tener un tamaño de tabla de enrutamiento mucho más pequeño (y, por lo tanto, requisitos de RAM y CPU) que una red multitarjeta. Incluso el alojamiento múltiple simple puede tener un tamaño de tabla de enrutamiento modesto. Consulte RFC 4098 para conocer los parámetros de rendimiento independientes del proveedor para la convergencia de un solo enrutador BGP en el plano de control. La cantidad real de memoria requerida en un enrutador BGP depende de la cantidad de información BGP intercambiada con otros altavoces BGP y la forma en que el enrutador particular almacena la información BGP. Es posible que el enrutador deba conservar más de una copia de una ruta, por lo que puede administrar diferentes políticas para la publicidad y aceptación de rutas para un AS vecino específico. El término vista se usa a menudo para estas diferentes relaciones de políticas en un enrutador en funcionamiento.

Si la implementación de un enrutador requiere más memoria por ruta que otra implementación, esta puede ser una elección de diseño legítima, intercambiando velocidad de procesamiento por memoria. Una tabla BGP IPv4 completa a partir de agosto de 2015 supera los 590 000 prefijos. Los ISP grandes pueden agregar otro 50% para rutas internas y de clientes. Nuevamente, dependiendo de la implementación, se pueden mantener tablas separadas para cada vista de un AS par diferente.

Las implementaciones notables gratuitas y de código abierto de BGP incluyen:

• BIRD, un paquete de enrutamiento GPL para sistemas tipo Unix.
• FRRouting, una bifurcación de Quagga para sistemas tipo Unix.
• GNU Zebra, una suite de enrutamiento GPL compatible con BGP4. (fuera de servicio)
• OpenBGPD, una implementación con licencia BSD del equipo de OpenBSD.
• Quagga, una bifurcación de GNU Zebra para sistemas tipo Unix.
• XORP, la plataforma de enrutador abierta extensible, un conjunto de protocolos de enrutamiento con licencia BSD.

Los sistemas para probar la conformidad BGP, el rendimiento de la carga o el estrés provienen de proveedores como:

• Tecnologías Agilent
• Simulador de red de código abierto GNS3
• Ixia
• Comunicaciones espirituales

Documentos de normas

• RFC 1772, Aplicación del Border Gateway Protocol en el Protocolo de Internet (BGP-4) usando SMIv2
• RFC 1997, Atributo de comunidades BGP
• RFC 2439, Amortiguación de flaps de ruta BGP
• RFC 2918, capacidad de actualización de ruta para BGP-4
• RFC 3765, comunidad NOPEER para el control del alcance de la ruta del protocolo de puerta de enlace fronteriza (BGP)
• RFC 4271, un protocolo de puerta de enlace fronteriza 4 (BGP-4)
• RFC 4272, Análisis de vulnerabilidades de seguridad BGP
• RFC 4273, Definiciones de objetos administrados para BGP-4
• RFC 4274, análisis de protocolo BGP-4
• RFC 4275, Encuesta de implementación de BGP-4 MIB
• RFC 4276, Informe de implementación de BGP-4
• RFC 4277, Experiencia con el Protocolo BGP-4
• RFC 4278, Variación de madurez de estándares con respecto a la opción de firma TCP MD5 (RFC 2385) y la especificación BGP-4
• RFC 4360, Atributo de comunidades extendidas BGP
• RFC 4456, BGP Route Reflection: una alternativa al BGP interno de malla completa (iBGP)
• RFC 4724, Mecanismo de reinicio elegante para BGP
• RFC 4760, Extensiones multiprotocolo para BGP-4
• RFC 5065, Confederaciones del Sistema Autónomo para BGP
• RFC 5492, Anuncio de capacidades con BGP-4
• RFC 5575, Diseminación de Reglas de Especificación de Flujo
• RFC 5701, Atributo de comunidad extendida BGP específico de dirección IPv6
• RFC 6793, compatibilidad con BGP para el espacio numérico del sistema autónomo (AS) de cuatro octetos
• RFC 7153, Registros IANA para comunidades extendidas BGP
• RFC 7606, Manejo de errores revisado para mensajes de ACTUALIZACIÓN de BGP
• RFC 7752, Distribución norte de información de ingeniería de tráfico y estado de enlace mediante BGP
• RFC 7911, Anuncio de Rutas Múltiples en BGP
• RFC 8092, Atributo de grandes comunidades BGP
• RFC 8195, Uso de BGP Grandes Comunidades
• RFC 8642, Comportamiento de políticas para comunidades BGP conocidas
• draft-ietf-idr-custom-decision-08 – Proceso de decisión personalizada de BGP, 3 de febrero de 2017
• Actualización de ruta selectiva para BGP, borrador de IETF
• RFC 1105, obsoleto: protocolo de puerta de enlace fronteriza (BGP)
• RFC 1654, obsoleto: un protocolo de puerta de enlace fronteriza 4 (BGP-4)
• RFC 1655, Obsoleto – Aplicación del Border Gateway Protocol en Internet
• RFC 1657, obsoleto: definiciones de objetos administrados para la cuarta versión de Border Gateway
• RFC 1771, obsoleto: un protocolo de puerta de enlace fronteriza 4 (BGP-4)
• RFC 1965, Obsoleto – Confederaciones del Sistema Autónomo para BGP
• RFC 2796, Obsoleto – BGP Route Reflection – Una alternativa a Full Mesh iBGP
• RFC 2858, obsoleto: extensiones multiprotocolo para BGP-4
• RFC 3065, Obsoleto – Confederaciones del Sistema Autónomo para BGP
• RFC 3392, obsoleto: anuncio de capacidades con BGP-4
• RFC 4893, obsoleto: soporte BGP para espacio numérico AS de cuatro octetos