Protocolo de puerta de enlace fronteriza

Protocolo de puerta de enlace fronteriza

Protocolo de comunicación
Máquina de estados BGP
Abreviatura	BGP
Objetivo	intercambiar información de enrutamiento del Protocolo de Internet
Introducción	1 de junio de 1989 ; hace 35 años [1] ( 1 de junio de 1989 )
Residencia en	EGP
Capa OSI	Capa de aplicación
Puerto(s)	tcp/179
RFC(s)	§ Documentos de normas

Border Gateway Protocol ( BGP ) 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 . ^[2] BGP se clasifica como un protocolo de enrutamiento de vector de ruta , ^[3] y toma decisiones de enrutamiento basadas en rutas, políticas de red o conjuntos de reglas configurados por un administrador de red .

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

El origen de BGP se remonta a 1989, cuando Kirk Lougheed, Len Bosack y Yakov Rekhter compartían una comida en una conferencia de la IETF . Hicieron un famoso boceto de su nuevo protocolo de enrutamiento en el reverso de unas servilletas, por lo que a menudo se lo denomina el “Protocolo de las dos servilletas”. ^{[4] [5] [6]}

Se describió por primera vez en 1989 en RFC 1105 y se ha utilizado en Internet desde 1994. ^[7] 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ó por primera vez como RFC 1654 en 1994, posteriormente actualizada por RFC 1771 en 1995 y RFC 4271 en 2006. ^[8] RFC 4271 corrigió errores, aclaró ambigüedades y actualizó la especificación con prácticas comunes de la industria. La principal mejora de BGP4 fue el soporte para Classless Inter-Domain Routing (CIDR) y el uso de agregación de rutas para disminuir el tamaño de las tablas de enrutamiento . RFC 4271 permite que BGP4 lleve una amplia gama de "familias de direcciones" IPv4 e IPv6. También se denomina Extensiones Multiprotocolo, que es BGP Multiprotocolo (MP-BGP).

Los vecinos BGP, llamados pares, se establecen mediante configuración manual entre enrutadores para crear una sesión TCP en el puerto 179. Un hablante BGP envía mensajes de mantenimiento de conexión de 19 bytes cada 30 segundos (valor predeterminado del protocolo, ajustable) para mantener la conexión. ^[9] Entre los protocolos de enrutamiento, BGP es único en usar TCP como su 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 simplemente pares eBGP y generalmente están conectados directamente, mientras que los pares iBGP pueden interconectarse a través de otros enrutadores intermedios. También son posibles otras topologías de implementación , como ejecutar peering eBGP 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 el peering iBGP y eBGP está en la forma en que las rutas recibidas de un peer se propagan normalmente de forma predeterminada a otros peers:

• 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 únicamente 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 mediante el mecanismo de mapas de rutas . Este mecanismo consta de un conjunto de reglas. Cada regla describe, para las rutas que coinciden con ciertos criterios dados, qué acción se debe tomar. La acción puede ser eliminar la ruta o modificar algunos atributos de la ruta antes de insertarla en la tabla de enrutamiento.

Durante el protocolo de enlace entre pares, cuando se intercambian mensajes OPEN, los hablantes de BGP pueden negociar capacidades opcionales de la sesión ^[10] , incluidas extensiones multiprotocolo ^[11] 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 anteponer a la información de accesibilidad de la capa de red (NLRI) que anuncia 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 utiliza 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 ^{[12] .}

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; Conectado; Activo; AbiertoEnviado; AbiertoConfirmado; y Establecido. Para cada sesión entre pares, una implementación 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 el 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 es exitosa. Si no es exitosa, inicia el temporizador ConnectRetry y pasa al estado Activo cuando expira. En el estado Activo, el enrutador restablece el temporizador ConnectRetry a cero y regresa al estado Conectar. En el estado OpenSent, el enrutador envía un mensaje Open y espera uno de regreso para pasar al estado OpenConfirm. Se intercambian mensajes Keepalive y, al recibirlos correctamente, el enrutador pasa al estado Establecido. En el estado Establecido, el enrutador puede enviar y recibir: mensajes Keepalive; Update; y Notification hacia y desde su par.

• Estado inactivo :
  • Rechazar todas las conexiones BGP entrantes.
  • Iniciar la inicialización de los activadores 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 FSM, la sesión BGP finaliza inmediatamente y vuelve al estado inactivo. Algunas de las razones por las que un enrutador no avanza desde el estado inactivo son:
    • El puerto TCP 179 no está abierto.
    • Un puerto TCP aleatorio superior a 1023 no está abierto.
    • La dirección de par está configurada incorrectamente en alguno de los enrutadores.
    • Número AS configurado incorrectamente en alguno de los enrutadores.
• Estado de conexión :
  • Espera la 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 par y cambia el estado a OpenSent.
  • Si se produce un error, BGP pasa al estado Activo. Algunas de las razones del error son:
    • El puerto TCP 179 no está abierto.
    • Un puerto TCP aleatorio superior a 1023 no está abierto.
    • La dirección de par está configurada incorrectamente en alguno de los enrutadores.
    • Número AS configurado incorrectamente en alguno 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 provocar que el enrutador pase del estado inactivo al estado activo. Algunas de las razones para esto incluyen:
    • El puerto TCP 179 no está abierto.
    • Un puerto TCP aleatorio superior a 1023 no está abierto.
    • Error de configuración de BGP.
    • Congestión de la red.
    • Interfaz de red de aleteo.
• Estado de OpenSent :
  • BGP FSM escucha un mensaje abierto de su par.
  • Una vez recibido el mensaje, el enrutador verifica la validez del mensaje de apertura.
  • Si hay un error es porque uno de los campos en el mensaje Abierto no coincide entre los pares, por ejemplo, falta de coincidencia de la versión BGP, el enrutador de intercambio espera un My 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 establecen varios temporizadores y el estado cambia a OpenConfirm.
• Estado de OpenConfirm :
  • El par está escuchando un mensaje Keepalive de su par.
  • Si se recibe un mensaje Keepalive y ningún temporizador ha expirado 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.

This section may be too technical for most readers to understand. Please help improve it to make it understandable to non-experts, without removing the technical details. (April 2021) (Learn how and when to remove this message)

En la disposición más simple, todos los enrutadores dentro de un único AS y que participan en el enrutamiento BGP deben configurarse en una malla completa: cada enrutador debe configurarse como un par de todos los demás enrutadores. Esto causa problemas de escalabilidad, ya que la cantidad de conexiones requeridas crece cuadráticamente con la cantidad de enrutadores involucrados. Para aliviar el problema, BGP implementa dos opciones: reflectores de ruta (RFC 4456) y confederaciones BGP (RFC 5065). La siguiente discusión del procesamiento básico de actualizaciones supone una malla iBGP completa.

Un enrutador BGP determinado puede aceptar actualizaciones de información de accesibilidad de capa de red (NLRI) de varios vecinos y anunciar NLRI al mismo conjunto de vecinos o a un conjunto diferente. El proceso BGP mantiene varias bases de información de enrutamiento :

• RIB:tabla base de información de enrutamiento principal de los enrutadores.
• Loc-RIB:La base de información de enrutamiento local BGP mantiene su propia tabla de enrutamiento maestra separada de la tabla de enrutamiento principal del enrutador.
• Adj-RIB-In:Para cada vecino, el proceso BGP mantiene una base de información de enrutamiento adyacente conceptual, entrante , que contiene el NLRI recibido del vecino.
• Adj-RIB-Out:Para cada vecino, el proceso BGP mantiene una base de información de enrutamiento adyacente conceptual, saliente , que contiene el NLRI enviado al 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 normalmente se pueden consultar con comandos de administración en el enrutador local. Es bastante común, por ejemplo, almacenar los y Adj-RIB-Injuntos en la misma estructura de datos, con información adicional adjunta a las entradas RIB. La información adicional le indica al proceso BGP cosas como si las entradas individuales pertenecen a los vecinos específicos, si el proceso de selección de ruta entre pares hizo que las políticas recibidas fueran elegibles para los y si las entradas son elegibles para ser enviadas al proceso de administración de la tabla de enrutamiento del enrutador local.Adj-RIB-OutLoc-RIBAdj-RIBsLoc-RIBLoc-RIB

BGP envía las rutas que considera mejores al proceso de la tabla de enrutamiento principal. Según la implementación de ese proceso, la ruta BGP no necesariamente se selecciona. Por ejemplo, un prefijo conectado directamente, aprendido del propio hardware del enrutador, suele ser el más preferido. Mientras la interfaz de esa ruta conectada directamente esté activa, la ruta BGP al destino no se colocará 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. Algunos de los datos transportados que están explícitamente destinados a usarse en decisiones de política son:

• Comunidades
• discriminadores de múltiples salidas (MED).
• sistemas autónomos (SA)

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 que entre en el 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 siguiente salto debe ser alcanzable 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 siguiente salto.

A continuación, para cada vecino, el proceso BGP aplica varios criterios estándar y dependientes de la implementación para decidir qué rutas conceptualmente deberían ir en el Adj-RIB-In. El vecino podría enviar varias rutas posibles a un destino, pero el primer nivel de preferencia está en el nivel del 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 retire el vecino.

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

Mientras haya desempate, el proceso de selección de ruta pasa al siguiente paso.

La preferencia local, el peso y otros criterios se pueden manipular mediante la configuración local y las capacidades del software. Dicha manipulación, aunque se utiliza comúnmente, está fuera del alcance del estándar. Por ejemplo, el atributo de comunidad (ver a continuación) no se utiliza directamente en el proceso de selección de BGP. El proceso de 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 de BGP por vecino calcula un valor de preferencia local a partir de las reglas de política local y luego compara la preferencia local de todas las rutas del vecino.

Las comunidades BGP son etiquetas de atributos que se pueden aplicar a prefijos entrantes o salientes para lograr un objetivo común. ^[15] Si bien es común decir que BGP permite a un administrador establecer 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 ningún concepto que permita que un AS le diga a otro AS que restrinja la publicidad de un prefijo solo a los clientes de peering 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.

Algunos ejemplos de comunidades comunes incluyen:

• ajustes de preferencias locales,
• geográfico
• restricciones de tipo de pares
• Identificación de ataques de denegación de servicio
• Opciones de anteposición de AS.

Un ISP podría indicar que cualquier ruta recibida de los clientes con los siguientes ejemplos:

• Para clientes de América del Norte (Costa Este) 3491:100
• Para clientes de América del Norte (Costa Oeste) 3491:200

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 anuncia el prefijo. El usuario final no tiene capacidad técnica para hacer que el ISP tome las medidas correctas, aunque los problemas en esta área son generalmente poco frecuentes y accidentales. ^{[17] [18]}

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

El atributo de comunidad extendida BGP se agregó en 2006, ^[20] con el fin de ampliar el rango de dichos atributos y proporcionar una estructuración de atributos de comunidad por medio de un campo de tipo. El formato extendido 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 BGP. ^[21] El atributo de comunidades extendidas en sí es un atributo BGP transitivo opcional. 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 atributo. Debido al rango de atributo extendido, su uso puede ser múltiple. RFC 4360 define a modo de ejemplo 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. ^[22]

Con la introducción de los números AS de 32 bits, se hicieron evidentes de inmediato algunos problemas 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 los ASN de 32 bits. RFC 8092 y RFC 8195 introducen un atributo de Comunidad grande de 12 bytes, dividido en tres campos de 4 bytes cada uno (AS:función:parámetro). ^[23]

Los MED, definidos en el estándar BGP principal, fueron originalmente pensados ​​para mostrar a otro AS vecino la preferencia del AS anunciante sobre cuál de varios enlaces es el preferido para el tráfico entrante. Otra aplicación de los MED es anunciar el valor, generalmente basado en el retardo, de múltiples AS que tienen presencia en un IXP , que imponen para enviar tráfico a algún destino.

Algunos enrutadores (como Juniper) utilizarán la métrica de OSPF para configurar MED.

Ejemplos de MED utilizados con BGP cuando se exportan a BGP en Juniper SRX

# run  show  ospf  route Topología predeterminada Tabla de rutas: Prefijo Ruta Ruta NH Métrica Próximo salto Tipo Próximo salto  Tipo Tipo Interfaz Dirección/LSP 10.32.37.0/24 Inter Descarte IP 16777215 10.32.37.0/26 Intra Network IP 101 ge-0/0/1.0 10.32.37.241 10.32.37.64/26 Intra Network IP 102 ge-0/0/1.0 10.32.37.241 10.32.37.128/26 Intra Network IP 101 ge-0/0/1.0 10.32.37.241 # mostrar  ruta  protocolo de publicidad  bgp 10 .32.94.169  Prefijo Próximo salto MED Lclpref Ruta AS * 10.32.37.0/24 Self 16777215 I * 10.32.37.0/26 Self 101 I * 10.32.37.64/26 Self 102 I * 10.32.37.128/26 Self 101 I 

• Marcador : incluido por compatibilidad, debe configurarse en todos los unos.
• Longitud : Longitud total del mensaje en octetos , incluido el encabezado.
• Tipo : tipo de mensaje BGP. Se definen los siguientes valores:
  • Abierto (1)
  • Actualización (2)
  • Notificación (3)
  • Mantenerse vivo (4)
  • Ruta-Actualizar (5)

Nota: "Marcador" y "Longitud" se omiten de los ejemplos.

Versión (8 bits)

Versión de BGP utilizada.

Mi AS (16 bits)

Número de sistema autónomo del remitente .

Tiempo de retención (16 bits)

Temporizador de tiempo de espera que se utiliza para calcular los mensajes KeepAlive. El valor predeterminado es 90 segundos.

Identificador BGP (32 bits)

Dirección IP del remitente.

Longitud de parámetros opcionales (8 bits): longitud total del campo de parámetros opcionales.

Ejemplo de mensaje abierto

Tipo: Mensaje abierto (1)Versión: 4Mi AS: 64496Tiempo de espera: 90Identificador BGP: 192.0.2.254Parámetros opcionales Longitud: 16Parámetros opcionales: Capacidad: Capacidad de extensiones multiprotocolo (1) Capacidad: Capacidad de actualización de ruta (2) Capacidad: Capacidad de actualización de ruta (Cisco) (128)

Solo se envían los cambios, después del intercambio inicial solo se envían las diferencias (agregar/cambiar/eliminar).

Ejemplo de mensaje de ACTUALIZACIÓN

Tipo: Mensaje de ACTUALIZACIÓN (2)Rutas retiradas Longitud: 0Longitud total del atributo de ruta: 25Atributos de ruta ORIGEN: IGP RUTA DEL AS: 64500 SIGUIENTE SALTO: 192.0.2.254 DISCO MULTI_SALIDA: 0Información de accesibilidad de la capa de red (NLRI) 192.0.2.0/27  192.0.2.32/27  192.0.2.64/27

Si hay un error es porque uno de los campos en el mensaje OPEN o UPDATE no coincide entre los pares, por ejemplo, falta de coincidencia de la versión BGP, el enrutador de intercambio espera un My AS diferente, etc. El enrutador luego envía un mensaje de notificación al par indicando por qué ocurrió el error.

Ejemplo de mensaje de NOTIFICACIÓN

Tipo: Mensaje de NOTIFICACIÓN (3)Error mayor Código: ABIERTO Mensaje de error (2)Código de error menor (mensaje abierto): AS de par incorrecto (2)AS de pares malos: 65200

Los mensajes KeepAlive se envían periódicamente para verificar que el par remoto aún está activo. Los mensajes KeepAlive se deben enviar a intervalos de un tercio del tiempo holdtime.

Ejemplo de mensaje KEEPALIVE

Tipo: Mensaje KEEPALIVE (4)

Definido en RFC 7313.

Permite la actualización suave de Adj-RIB-in, sin restablecer la conexión.

Ejemplo de mensaje ROUTE-REFRESH

Tipo: Mensaje ROUTE-REFRESH (5)Identificador de familia de direcciones (AFI): IPv4 (1)Subtipo: Solicitud de actualización de ruta normal [RFC2918] con/sin ORF [RFC5291] (0)Identificador de familia de direcciones subsiguientes (SAFI): Unicast (1)

BGP es "el más escalable de todos los protocolos de enrutamiento". ^[25]

Un sistema autónomo con BGP interno (iBGP) debe tener todos sus pares iBGP conectados entre sí en una malla completa (donde todos se comunican directamente con todos). 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 requisitos elevados de procesamiento de la CPU.

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

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 en malla de 10 enrutadores, se necesitan 90 instrucciones CLI individuales (distribuidas entre todos los enrutadores de 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 instrucciones a 18, lo que ofrece 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, aproximadamente duplica la cantidad de instrucciones CLI, lo que requiere 11 × 2 − 2 = 20 instrucciones 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.

Tanto los RR como las confederaciones reducen la cantidad de pares iBGP de cada enrutador y, por lo tanto, reducen la sobrecarga de procesamiento. Los RR son una técnica puramente de mejora del rendimiento, mientras que las confederaciones también se pueden utilizar para implementar políticas más específicas.

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

• Las rutas siempre se reflejan en los pares eBGP.
• Las rutas nunca se reflejan en el originador de la ruta.
• Si se recibe una ruta de un par que no es cliente, se refleja a los pares clientes.
• Si se recibe una ruta de un cliente par, se refleja en los pares clientes y no clientes.

Un RR y sus clientes forman un clúster . El ID del clúster se adjunta a cada ruta anunciada por el 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.

Las confederaciones son conjuntos de sistemas autónomos. En la práctica habitual, ^[27] Internet en su conjunto solo ve uno de los números de AS de la confederación. Las confederaciones se utilizan en redes muy grandes en las que un AS grande puede configurarse para abarcar AS internos más pequeños y más manejables.

El sistema autónomo confederado está compuesto por varios sistemas autónomos. Cada uno de ellos tiene iBGP completamente integrado y tiene conexiones con otros sistemas autónomos dentro de la confederación. Aunque estos sistemas autónomos tienen pares eBGP con los sistemas autónomos dentro de la confederación, los sistemas autónomos intercambian enrutamiento como si utilizaran iBGP. De esta manera, la confederación conserva la información de preferencias locales, métricas y el siguiente salto. Para el mundo exterior, la confederación parece ser un único sistema autónomo. Con esta solución, los problemas de tránsito iBGP de los sistemas autónomos 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. ^{[ aclaración necesaria ]}

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 afecten tanto a BGP como al protocolo de enrutamiento interno. ^[28]

Estas alternativas pueden introducir sus propios problemas, incluidos los siguientes:

• oscilación de ruta
• enrutamiento subóptimo
• Aumento del tiempo de convergencia BGP ^[29]

Además, los reflectores de ruta y las confederaciones BGP no fueron diseñados para facilitar la configuración de enrutadores BGP. No obstante, son herramientas comunes para arquitectos de redes BGP experimentados. Estas herramientas pueden combinarse, por ejemplo, como una jerarquía de reflectores de ruta.

Las tablas de enrutamiento administradas por una implementación BGP se ajustan continuamente para reflejar los cambios reales en la red, como enlaces o enrutadores que se caen y vuelven a funcionar. En la red en su conjunto, es normal que estos cambios ocurran casi continuamente, pero para cualquier enrutador o enlace en particular, se espera que los cambios sean 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 retirada y reanunciación repetida, conocido como inestabilidad de ruta, puede causar una actividad excesiva en todos los demás enrutadores que conocen la entidad cíclica, 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, un cambio de enrutamiento BGP puede causar interrupciones durante varios minutos.

Una característica conocida como amortiguación de flaps de ruta ( RFC  2439) está incorporada en muchas implementaciones de BGP en un intento de mitigar los efectos de la oscilación de ruta. Sin amortiguación, la actividad excesiva puede causar una carga de procesamiento pesada 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, la oscilación de una ruta se desintegra exponencialmente . En la primera instancia, cuando una ruta deja de estar disponible y reaparece rápidamente, la amortiguación no tiene efecto, a fin de mantener los tiempos de conmutación por error normales de BGP. En la segunda ocurrencia, BGP evita ese prefijo durante un cierto período de tiempo; las ocurrencias posteriores se ignoran exponencialmente durante más tiempo. Una vez que las anomalías han cesado y ha transcurrido un período de tiempo adecuado para la ruta infractora, los prefijos se pueden restablecer con un borrón y cuenta nueva. La amortiguación también puede mitigar los ataques de denegación de servicio .

^{En la RFC 2439 : Sección 4} también se sugiere que la amortiguación de oscilaciones 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 llamadas pares internos). Con este enfoque, cuando una ruta oscila dentro de un sistema autónomo, no se propaga a los AS externos; la oscilación de una ruta a un eBGP provocará una cadena de oscilaciones 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 oscilaciones de ruta para las sesiones iBGP.

Investigaciones posteriores han demostrado que la amortiguación de flaps puede, en realidad, alargar los tiempos de convergencia en algunos casos, y puede causar interrupciones en la conectividad incluso cuando los enlaces no están vibrando. ^{[30] [31]} 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 flaps 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. ^[32] Esto ha llevado al Grupo de Trabajo de Enrutamiento RIPE a escribir: "Con las implementaciones actuales de amortiguación de flaps BGP, NO se recomienda la aplicación de amortiguación de flaps en redes ISP. ... Si se implementa la amortiguación de flaps, el ISP que opera esa red causará efectos secundarios a sus clientes y a los usuarios de Internet del contenido y los servicios de sus clientes... Estos efectos secundarios probablemente serían peores que el impacto causado por simplemente no ejecutar la amortiguación de flaps en absoluto". ^[33] Mejorar la estabilidad sin los problemas de la amortiguación de flaps es el tema de la investigación actual. ^{[34] [ necesita actualización ]}

Uno de los mayores problemas a los que se 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 CPU que supone mantener la tabla, estos enrutadores dejarán de ser puertas de enlace eficaces entre las partes de Internet que conectan. Además, y quizás esto sea aún más importante, las tablas de enrutamiento más grandes tardan más en estabilizarse después de un cambio importante de conectividad, lo que hace que el servicio de red no sea fiable o incluso no esté disponible mientras tanto.

Hasta finales de 2001, la tabla de enrutamiento global crecía exponencialmente , lo que amenazaba con provocar una ruptura generalizada de la conectividad. En un intento por evitarlo, 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 agregación de rutas . Si bien esto desaceleró el crecimiento de la tabla de enrutamiento hasta convertirla en 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 volvió a ser superlineal a mediados de 2004.

En 2014 se desencadenó un desbordamiento similar al del Y2K para aquellos modelos que no se actualizaron adecuadamente.

Mientras que una tabla BGP IPv4 completa a partir de agosto de 2014 ^[update](512k día) ^{[35] [36]} superaba los 512.000 prefijos, ^[37] muchos enrutadores más antiguos tenían un límite de 512k (512.000–524.288) ^{[38] [39]} entradas de tabla de enrutamiento. El 12 de agosto de 2014, las interrupciones resultantes de tablas llenas afectaron a eBay , LastPass y Microsoft Azure , entre otros. ^[40] Varios enrutadores Cisco de uso común tenían TCAM , una forma de memoria direccionable por contenido de alta velocidad , para almacenar rutas anunciadas por BGP. En los enrutadores afectados, la TCAM se asignó de forma predeterminada como 512k rutas IPv4 y 256k rutas IPv6. Si bien el número informado de rutas IPv6 anunciadas fue de solo 20k, el número de rutas IPv4 anunciadas alcanzó el límite predeterminado, lo que provocó un efecto de derrame ya que los enrutadores intentaron compensar el problema mediante el uso de enrutamiento de software lento (en lugar de enrutamiento de hardware rápido a través de TCAM). El método principal para lidiar con este problema implica que los operadores cambien la asignación de TCAM para permitir más entradas IPv4, reasignando parte del TCAM reservado 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. ^{[41] [42] [43]}

Las asignaciones reales que impulsaron el número de rutas por encima de 512k fue el anuncio de alrededor de 15.000 nuevas rutas en poco tiempo, a partir de las 07:48 UTC. Casi todas estas rutas eran para los Sistemas Autónomos de Verizon 701 y 705, creados como resultado de la desagregación de bloques más grandes, introduciendo miles de nuevas rutas / 24 y haciendo que la tabla de enrutamiento alcance 515.000 entradas. Las nuevas rutas parecen haber sido reagregadas en 5 minutos, pero la inestabilidad en Internet aparentemente continuó durante varias horas. ^[44] Incluso si Verizon no hubiera hecho que la tabla de enrutamiento superara las 512k entradas en el breve pico, pronto habría sucedido a través del crecimiento natural.

El resumen de ruta se utiliza a menudo para mejorar la agregación de la tabla de enrutamiento global BGP, reduciendo así 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 propósitos de ingeniería de tráfico, AS1 desea 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 tomar o no una copia de las cuatro rutas o, como 172.16.0.0 / 16 se superpone a todas las demás rutas específicas, solo almacenar 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 AS1, se descartarán o se enviará un mensaje ICMP de destino inalcanzable , según la configuración de los enrutadores de AS1 .

Si más tarde AS1 decide descartar la ruta 172.16.0.0 / 16 y dejar 172.16.0.0 / 18 , 172.16.64.0 / 18 y 172.16.128.0 / 18 , la cantidad de rutas que anuncia AS1 se reduce a tres. Según la política de enrutamiento de AS2, almacenará una copia de las tres rutas o agregará 172.16.0.0 / 18 y 172.16.64.0 / 18 a 172.16.0.0 / 17 , lo que reduce la cantidad de rutas que almacena AS2 a dos ( 172.16.0.0 / 17 y 172.16.128.0 / 18 ).

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

La especificación RFC 1771 BGP-4 codificó los números AS en 16 bits, para 64.510 posibles números AS públicos. ^[a] En 2011, solo 15.000 números AS todavía estaban disponibles, y las proyecciones ^[45] preveían un agotamiento total de los números AS disponibles en septiembre de 2013.

RFC 6793 amplía la codificación AS de 16 a 32 bits, ^[b] lo que ahora permite hasta 4 mil millones de AS disponibles. También se define un rango de AS privado adicional en RFC 6996. ^[c] Para permitir el cruce de grupos de enrutadores que no pueden administrar esos nuevos ASN, se utiliza el nuevo atributo AS4_PATH (transitivo opcional) y el ASN especial de 16 bits AS_TRANS (AS23456). ^[46] Las asignaciones de ASN de 32 bits comenzaron en 2007.

Otro factor que contribuye al crecimiento de la tabla de enrutamiento es la necesidad de equilibrar la carga de las redes multi-homed . No es una tarea sencilla equilibrar el tráfico entrante 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. En el caso de una red multi-homed, 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 demás enlaces permanecen infrautilizados, porque todas las redes externas eligieron ese conjunto de rutas congestionadas como óptimas. Al igual que 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 multiproveedor pueden dividir un bloque grande de direcciones IP contiguas en bloques más pequeños y modificar el anuncio de ruta para que los diferentes bloques parezcan óptimos en diferentes rutas, de modo que las redes externas elijan una ruta diferente para llegar a los diferentes bloques de esa red multiproveedor. Estos casos aumentarán la cantidad de rutas, como se ve en la tabla BGP global.

Un método para abordar el problema de la tabla de enrutamiento asociado con el equilibrio de carga es implementar puertas de enlace de protocolo de separación de localizador/identificador (BGP/LISP) dentro de un punto de intercambio de Internet para permitir la ingeniería del tráfico de entrada a través de múltiples enlaces. Esta técnica no aumenta la cantidad de rutas que se ven en la tabla BGP global.

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. ^[47]

Las extensiones multiprotocolo para BGP (MBGP), a veces denominadas BGP multiprotocolo o BGP de multidifusión y definidas en RFC  4760, son una extensión de BGP que permite distribuir en paralelo distintos 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 de ellas. El BGP multiprotocolo permite intercambiar información sobre la topología de los enrutadores con capacidad de multidifusión IP 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, se necesitan otros protocolos, como la familia de multidifusión independiente del protocolo, para crear árboles y reenviar tráfico de multidifusión.

El BGP multiprotocolo también se implementa ampliamente en el caso de MPLS L3 VPN, para intercambiar etiquetas VPN aprendidas para las rutas de los sitios del cliente a través de la red MPLS, con el fin de distinguir entre diferentes sitios del cliente cuando el tráfico de los otros sitios del cliente llega al enrutador de borde del proveedor para su enrutamiento.

Otra extensión de BGP es el enrutamiento por múltiples rutas . Esto normalmente 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 que los números AS reales en la ruta que se espera que coincidan también. Esto se puede ampliar aún más con funciones como dmzlink-bw de Cisco, que permite una proporción de uso compartido del tráfico basada en valores de ancho de banda configurados en enlaces individuales.

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

Es posible que los enrutadores, especialmente los pequeños destinados a oficinas pequeñas o en el hogar (SOHO), no incluyan la capacidad BGP. Es posible que otros enrutadores comerciales necesiten una imagen ejecutable de software específica que admita BGP o una licencia que lo habilite. Es menos probable que los dispositivos comercializados como conmutadores de capa 3 admitan BGP que los dispositivos comercializados como enrutadores , pero muchos conmutadores de capa 3 de alta gama pueden ejecutar BGP.

Los productos comercializados como conmutadores pueden tener una limitación de tamaño en las tablas BGP que es mucho menor que una tabla de Internet completa más las rutas internas. Estos dispositivos pueden ser perfectamente razonables y útiles cuando se utilizan para el enrutamiento BGP de una parte más pequeña de la red, como un AS de confederación que representa una de varias empresas más pequeñas que están conectadas por una red troncal de redes BGP, 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 utilizado únicamente para una red con un único punto de entrada a Internet puede tener un tamaño de tabla de enrutamiento mucho menor (y, por lo tanto, un requisito de RAM y CPU) que una red multihoming. Incluso una red multihoming simple puede tener un tamaño de tabla de enrutamiento modesto. La cantidad real de memoria requerida en un enrutador BGP depende de la cantidad de información BGP intercambiada con otros interlocutores BGP y de la forma en que el enrutador en particular almacena la información BGP. Es posible que el enrutador deba mantener más de una copia de una ruta, de modo que pueda administrar diferentes políticas para la publicidad y aceptación de rutas en 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 una implementación de enrutador utiliza más memoria por ruta que otra implementación, esta puede ser una opción de diseño legítima, que sacrifica velocidad de procesamiento por memoria. Una tabla BGP IPv4 completa a agosto de 2015 ^[update]tiene más de 590.000 prefijos. ^[37] 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 de pares diferente.

Entre las implementaciones notables de BGP, libres y de código abierto, se incluyen:

• BIRD , un paquete de enrutamiento GPL para sistemas tipo Unix.
• FRRouting , una bifurcación de Quagga para sistemas tipo Unix ; y sus antecesores:
  • Quagga , una bifurcación de GNU Zebra para sistemas tipo Unix (ya no se desarrolla).
  • GNU Zebra , una suite de enrutamiento GPL compatible con BGP4 (fuera de servicio). ^[48]
• OpenBGPD , una implementación con licencia BSD del equipo de OpenBSD .
• XORP , la plataforma de enrutador abierto extensible, un conjunto de protocolos de enrutamiento con licencia BSD.

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

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

• Interrupción de Facebook en 2021  : interrupción que afecta a todos los servicios operados por Facebook
• Incidente AS 7007  : importante interrupción de Internet el 25 de abril de 1997
• Autoridad de Números Asignados de Internet  : organización de estándares que supervisa las direcciones IP
• Reenvío de paquetes  : retransmisión de paquetes de un segmento de red a otro
• IP privada
• QPPB  – Mecanismo de ingeniería de tráfico
• Registro regional de Internet  : organización encargada de gestionar la numeración de la red
• Infraestructura de clave pública de recursos  : marco de seguridad de enrutamiento de Internet
• Filtrado de rutas  : proceso de exclusión de determinadas rutas de red
• Base de datos de activos de enrutamiento  : registro de enrutamiento para redes de Internet

• "Border Gateway Protocol (BGP)", Manual de tecnología IOS , Cisco Systems , archivado desde el original el 8 de julio de 2011

• RFC 1772, Aplicación del protocolo de puerta de enlace de frontera en el protocolo de Internet (BGP-4) utilizando 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, Protocolo de puerta de enlace fronteriza 4 (BGP-4)
• RFC 4272, Análisis de vulnerabilidades de seguridad de BGP
• RFC 4273, Definiciones de objetos administrados para BGP-4
• RFC 4274, Análisis del protocolo BGP-4
• RFC 4275, Encuesta de implementación de MIB BGP-4
• RFC 4276, Informe de implementación de BGP-4
• RFC 4277, Experiencia con el protocolo BGP-4
• RFC 4278, Variación de madurez de los estándares con respecto a la opción de firma MD5 de TCP (RFC 2385) y la especificación BGP-4
• RFC 4360, Atributo de comunidades extendidas de BGP
• RFC 4456, Reflexión de ruta BGP: 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 de sistemas autónomos para BGP
• RFC 5492, Publicidad de capacidades con BGP-4
• RFC 5701, Atributo de comunidad extendida BGP específico de dirección IPv6
• RFC 6793, Compatibilidad de BGP con espacio numérico de sistema autónomo (AS) de cuatro octetos
• RFC 7153, Registros de la IANA para comunidades extendidas de BGP
• RFC 7606, Manejo de errores revisado para mensajes BGP UPDATE
• RFC 7911, Publicación de múltiples rutas en BGP
• RFC 8092, Atributo de comunidades grandes de BGP
• RFC 8195, Uso de comunidades grandes de BGP
• RFC 8642, Comportamiento de políticas para comunidades BGP reconocidas
• RFC 8955, Difusión de reglas de especificación de flujo
• RFC 9552, Distribución de información de ingeniería de tráfico y estado de enlace mediante BGP
• Proceso de decisión personalizado de BGP, borrador de IETF, 3 de febrero de 2017
• Actualización de ruta selectiva para BGP, borrador de IETF, 7 de noviembre de 2015
• RFC 1105, obsoleto: Protocolo de puerta de enlace fronteriza (BGP)
• RFC 1654, obsoleto: Protocolo de puerta de enlace fronteriza 4 (BGP-4)
• RFC 1655, obsoleto: aplicación del protocolo de puerta de enlace fronteriza en Internet
• RFC 1657, obsoleto: definiciones de objetos administrados para la cuarta versión de Border Gateway
• RFC 1771, obsoleto: Protocolo de puerta de enlace fronteriza 4 (BGP-4)
• RFC 1965, obsoleto: Confederaciones de sistemas autónomos para BGP
• RFC 2796, obsoleto: reflexión de ruta BGP: una alternativa a iBGP de malla completa
• RFC 2858, obsoleto: extensiones multiprotocolo para BGP-4
• RFC 3065, obsoleto: Confederaciones de sistemas autónomos para BGP
• RFC 3392, obsoleto: publicidad de capacidades con BGP-4
• RFC 4893, obsoleto: compatibilidad de BGP con espacio numérico AS de cuatro octetos

• Recursos de enrutamiento BGP (incluye una sección dedicada a BGP y seguridad básica de ISP)
• Estadísticas de la tabla BGP