Descripción general del BGP

En esta sección se analizan los siguientes temas:

• Sistemas autónomos
• Rutas y atributos del AS
• BGP externo e interno
• Varias instancias de BGP
• Permitir tráfico de protocolo para interfaces en una zona de seguridad

BGP externo e interno

El BGP admite dos tipos de intercambios de información de enrutamiento: intercambios entre diferentes AS e intercambios dentro de un único AS. Cuando se utiliza en AS, el BGP se denomina BGP externo (EBGP) y las sesiones de BGP realizan enrutamiento entre AS. Cuando se utiliza en un AS, el BGP se denomina BGP interno (IBGP) y las sesiones de BGP realizan enrutamiento intraAS. Figura 1 ilustra las AS, IBGP y EBGP.

Figura 1: AS, EBGP e IBGP

Un sistema BGP comparte información de accesibilidad de red con sistemas BGP adyacentes, a los que se les conoce como vecinos o pares.

Los sistemas BGP se organizan en grupos. En un grupo de IBGP, todos los pares del grupo ( denominados pares internos) están en el mismo AS. Los pares internos pueden estar en cualquier parte del AS local y no tienen que estar conectados directamente entre sí. Los grupos internos usan rutas desde un IGP para resolver direcciones de reenvío. También propagan rutas externas entre todos los otros enrutadores internos que ejecutan IBGP, calculando el siguiente salto tomando el BGP siguiente salto recibido con la ruta y resolviendolo usando la información de uno de los protocolos de puerta de enlace interior.

En un grupo EBGP, los pares del grupo ( denominados pares externos) se encuentran en AS diferentes y normalmente comparten una subred. En un grupo externo, el siguiente salto se calcula con respecto a la interfaz que se comparte entre el par externo y el enrutador local.

Una ruta BGP es un destino, descrito como un prefijo de dirección IP, e información que describe la ruta al destino.

La siguiente información describe la ruta:

• Ruta del AS, que es una lista de números de los AS por los que una ruta pasa para llegar al enrutador local. El primer número de la ruta es el del último AS de la ruta: el AS más cercano al enrutador local. El último número de la ruta es el más alejado del enrutador local, que generalmente es el origen de la ruta.

• Atributos de ruta, que contienen información adicional acerca de la ruta del AS que se utiliza en la política de enrutamiento.

Los pares del BGP anuncian rutas entre sí en mensajes de actualización.

El BGP almacena sus rutas en la tabla de enrutamiento de Junos OS (inet.0). La tabla de enrutamiento almacena la siguiente información acerca de las rutas BGP:

• Información de enrutamiento aprendida de los mensajes de actualización recibidos de los pares

• Información de enrutamiento local que el BGP aplica a las rutas debido a políticas locales

• Información que el BGP anuncia a sus pares en los mensajes de actualización

Para cada prefijo de la tabla de enrutamiento, el proceso de protocolo de enrutamiento selecciona una única mejor ruta, denominada ruta activa. A menos que configure el BGP para anunciar varias rutas al mismo destino, el BGP anuncia solo la ruta activa.

El enrutador BGP que primero anuncia una ruta le asigna uno de los siguientes valores para identificar su origen. Durante la selección de ruta, se prefiere el valor de origen más bajo.

• 0— El enrutador aprendió originalmente la ruta a través de un IGP (OSPF, IS-IS o una ruta estática).

• 1— El enrutador aprendió originalmente la ruta a través de un EGP (probablemente BGP).

• 2— Se desconoce el origen de la ruta.

Una ruta interna de BGP (IBGP) con una dirección de salto siguiente a un vecino de BGP remoto (protocolo de salto siguiente) debe tener su siguiente salto resuelto mediante alguna otra ruta. El BGP agrega esta ruta al módulo de resolución rpd para la resolución del próximo salto. Si se utiliza RSVP en la red, el siguiente salto del BGP se resuelve mediante la ruta de entrada RSVP. Esto da como resultado que la ruta del BGP apunte a un siguiente salto indirecto y que el siguiente salto indirecto apunte a un siguiente salto de reenvío. El siguiente salto de reenvío se deriva del salto siguiente de la ruta RSVP. A menudo hay un gran conjunto de rutas de BGP internas que tienen el mismo protocolo siguiente salto, y en tales casos, el conjunto de rutas BGP haría referencia al mismo salto indirecto siguiente.

Antes de la versión 17.2R1 de Junos OS, el módulo de resolución del proceso de protocolo de enrutamiento (rpd) resolvió las rutas recibidas dentro del IBGP de las siguientes maneras:

1. Resolución de ruta parcial: el siguiente salto del protocolo se resuelve en función de rutas auxiliares, como rutas RSVP o IGP. Los valores de la métrica se derivan de las rutas del ayudante y el siguiente salto se denomina salto siguiente como el salto siguiente de reenvío de resolución heredado de las rutas del ayudante. Estos valores métricos se utilizan para seleccionar rutas en la base de información de enrutamiento (RIB), también conocida como tabla de enrutamiento.

2. Resolución de ruta completa: se deriva el último salto siguiente y se denomina tabla de enrutamiento de kernel (KRT) que se reenvía al siguiente salto según la política de exportación de reenvío.

A partir de Junos OS versión 17.2R1, el módulo de resolución de rpd está optimizado para aumentar la transferencia de datos del flujo de procesamiento entrante, acelerando la velocidad de aprendizaje de RIB y FIB. Con esta mejora, la resolución de ruta se ve afectada de la siguiente manera:

• Los métodos de resolución de ruta parcial y completa se activan para cada ruta ibgp, aunque es posible que cada ruta herede el mismo reenvío resuelto en el próximo salto o en krT próximos saltos.

• La selección de ruta del BGP se posterga hasta que se realice la resolución completa de la ruta para la información de accesibilidad de la capa de red (NLRI) recibida de un vecino del BGP, que puede no ser la mejor ruta en el RIB después de la selección de ruta.

Los beneficios de la optimización de la resolución rpd incluyen:

• Menor costo de búsqueda de resolución RIB: el resultado de la ruta resuelta se guarda en una caché de resolución, de modo que se puedan heredar los mismos valores de métrica y salto siguiente derivados a otro conjunto de rutas que compartan el mismo comportamiento de ruta en lugar de realizar un flujo de resolución de ruta parcial y completo. Esto reduce el costo de búsqueda de resolución de ruta al mantener solo el estado de resolución más frecuente en una caché con profundidad limitada.

• Optimización de la selección de rutas del BGP: el algoritmo de selección de ruta del BGP se activa dos veces por cada ruta ibgp recibida; en primer lugar, mientras se agrega la ruta en el RIB con el siguiente salto como inutilizable y, en segundo lugar, se agrega la ruta con un salto siguiente resuelto en el RIB (después de la resolución de ruta). El resultado es seleccionar la mejor ruta dos veces. Con la optimización de resolución, el proceso de selección de ruta se activa en el flujo de recepción solo después de obtener la información del siguiente salto del módulo de resolución.

• Caché interna para evitar búsquedas frecuentes: la caché de resolución mantiene el estado de resolución más frecuente y, como resultado, la funcionalidad de búsqueda, como la búsqueda del siguiente salto y la búsqueda de ruta se realiza desde la caché local.

• Grupo de equivalencia de rutas: cuando diferentes rutas comparten el mismo estado de reenvío o se reciben del mismo protocolo siguiente salto, las rutas pueden pertenecer a un grupo de equivalencia de ruta. Este enfoque evita la necesidad de realizar una resolución completa de rutas para dichas rutas. Cuando una nueva ruta requiere una resolución de ruta completa, se busca por primera vez en la base de datos del grupo de equivalencias de ruta, que contiene el resultado de la ruta resuelta, como el salto siguiente indirecto y el salto siguiente de reenvío.

En esta sección se analizan los siguientes temas:

• Mensajes abiertos
• Mensajes de actualización
• Mensajes de keepalive
• Mensajes de notificación
• Mensajes de actualización de ruta

El procesamiento de ruta del BGP generalmente tiene varias etapas de canalización, como recepción de actualización, análisis de actualización, creación de ruta, resolución del salto siguiente, aplicación de la política de exportación de un grupo par de BGP, formación de actualizaciones por par y envío de actualizaciones a pares.

La fragmentación RIB del BGP divide un RIB de BGP unificado en varias sub-RIB y cada sub-RIB maneja un subconjunto de rutas BGP. El subproceso RPD denominado subproceso de fragmentación BGP sirve a cada sub-RIB para lograr la simultaneidad. Los subprocesos de fragmentación del BGP son responsables de todas las etapas de la canalización de ruta del BGP, con la excepción de formar actualizaciones por par y enviar actualizaciones a pares. Los subprocesos de partición del BGP reciben las actualizaciones enviadas por los pares desde los subprocesos de E/S de BGP Update con los subprocesos de E/S de BGP Update que hashan los prefijos de las actualizaciones y las envía a los subprocesos de fragmentos del BGP correspondientes según el cálculo hash. El subproceso de partición del BGP procesa la configuración de la misma manera que el subproceso principal RPD, crea pares, grupos, tablas de ruta y utiliza la información de configuración para el procesamiento de rutas del BGP.

Los subprocesos de E/S de actualización del BGP son responsables del extremo final de esta canalización de BGP, lo que implica generar actualizaciones por par para grupos de BGP individuales y enviarlos a los pares. Un subproceso de actualización puede servir a uno o más grupos de BGP. Los subprocesos de E/S de actualización del BGP construyen actualizaciones para grupos en paralelo e independientes de otros grupos a los que otros subprocesos de actualización están siendo atendidos. Esto podría ofrecer una mejora significativa de la convergencia en una carga de trabajo con mucha escritura, que implica publicidad a muchos pares repartidos en muchos grupos. Los subprocesos de E/S de BGP Update también se encargan de escribir y leer desde los sockets TCP de los pares del BGP, que anteriormente proporcionaban los subprocesos BGPIO (de ahí el sufijo IO en BGP Update IO).

Los subprocesos de E/S de la actualización del BGP se pueden configurar independientemente de la función de fragmentación RIB, pero son obligatorios para su uso con la fragmentación rib, con el fin de lograr una mejor eficiencia de embalaje de prefijos en el mensaje de actualización del BGP saliente. La fragmentación del BGP divide el RIB en varias sub RIB que se sirven mediante subprocesos RPD. Por lo tanto, los prefijos que podrían haber entrado en una sola actualización saliente terminan en fragmentos diferentes. Para poder construir actualizaciones de BGP con prefijos con el mismo atributo de salida que podrían pertenecer a subprocesos de partición RPD diferentes, todos los subprocesos de partición envían información publicitaria compacta de los prefijos que se anunciarán a una actualización de subproceso que sirve a ese grupo par del BGP. Esto permite que el subproceso de actualización, que sirve a este grupo par del BGP, empaquetara prefijos con los mismos atributos, que potencialmente pertenecen a diferentes fragmentos en el mismo mensaje de actualización saliente. Esto minimiza la cantidad de actualizaciones que se anunciarán y, por lo tanto, ayuda a mejorar la convergencia. Actualizar el hilo de E/S administra las cachés locales de los contenedores de par, grupo, prefijo, TSI y RIB.

El subproceso de actualización del BGP y la fragmentación RIB de BGP están deshabilitados de forma predeterminada. Si configura update-threading y rib-sharding en un motor de enrutamiento, RPD crea subprocesos de actualización. De forma predeterminada, la cantidad de subprocesos de actualización y subprocesos de fragmentación creados es el mismo que el número de núcleos de CPU en el motor de enrutamiento. La actualización de subprocesos solo se admite en un proceso de protocolo de enrutamiento (rpd) de 64 bits. Opcionalmente, puede especificar el número de subprocesos que desea crear mediante el uso set update-threading <number-of-threads> y set rib-sharding <number-of-threads> las instrucciones en el [edit system processes routing bgp] nivel de jerarquía. En el caso del subproceso de actualización del BGP, el rango es actualmente del 1 al 128 y para el particionamiento RIB del BGP, el rango es actualmente del 1 al 31.

Cuando configure NSR para las funciones de fragmentación RIB de BGP y actualización de E/S del BGP, el RPD de copia de seguridad crea la misma cantidad de subprocesos de E/S de BGP y actualización de BGP en el motor de enrutamiento de respaldo. Los subprocesos de actualización del BGP de RPD de copia de seguridad leen la actualización del BGP replicada, otros mensajes recibidos de los pares, así como la actualización del BGP replicada, y otros mensajes enviados a los pares. Según el hash de los prefijos, los subprocesos de EO de actualización del BGP rpd de copia de seguridad envían estos mensajes de BGP a los subprocesos principales de BGP y RPD correspondientes. El fragmento del BGP y los subprocesos principales de RPD en el RPD de copia de seguridad crean el estado de la ruta recibida y anunciada mediante estos mensajes de BGP replicados. Cuando el motor de enrutamiento principal falla, el motor de enrutamiento de respaldo se convierte en el motor de enrutamiento principal y el RPD de respaldo se convierte en el RPD principal sin problemas sin afectar las sesiones de BGP con los pares.

Para cada prefijo de la tabla de enrutamiento, el proceso de protocolo de enrutamiento selecciona una única mejor ruta. Después de seleccionar la mejor ruta, la ruta se instala en la tabla de enrutamiento. La mejor ruta se convierte en la ruta activa si un protocolo no aprende el mismo prefijo con un valor de preferencia global más bajo (más preferido), también conocido como distancia administrativa. El algoritmo para determinar la ruta activa es el siguiente:

1. Compruebe que se puede resolver el siguiente salto.

2. Elija la ruta con el valor de preferencia más bajo (preferencia de proceso de protocolo de enrutamiento).

   Las rutas que no son elegibles para ser utilizadas para el reenvío (por ejemplo, porque la política de enrutamiento las rechazó o porque un salto siguiente no es accesible) tienen una preferencia de –1 y nunca se eligen.

3. Prefiera la ruta con mayor preferencia local.

   Para rutas que no son del BGP, elija la ruta con el valor más bajo preference2 .

4. Si el atributo del protocolo de puerta de enlace interior acumulado (AIGP) está habilitado, agregue la métrica IGP y prefiera la ruta con el atributo AIGP inferior.

5. Prefiera la ruta con el valor de ruta de sistema autónomo (AS) más corto (omitido si la as-path-ignore instrucción está configurada).

   Un segmento de confederación (secuencia o conjunto) tiene una longitud de ruta de 0. Un conjunto de AS tiene una longitud de ruta de 1.

6. Prefiera la ruta con el código de origen inferior.

   Las rutas aprendidas de un IGP tienen un código de origen menor que las aprendidas de un protocolo de puerta de enlace exterior (EGP), y ambas tienen códigos de origen más bajos que las rutas incompletas (rutas cuyo origen se desconoce).

7. Prefiera la ruta con la métrica discriminatoria de salida múltiple (MED) más baja.

   Dependiendo de si se configura un comportamiento de selección de ruta de tabla de enrutamiento no determinista, hay dos casos posibles:

   • Si el comportamiento de selección de rutas de la tabla de enrutamiento no determinista no está configurado (es decir, si la path-selection cisco-nondeterministic instrucción no está incluida en la configuración del BGP), en el caso de las rutas con los mismos números de AS vecinos en la parte frontal de la ruta del AS, prefiera la ruta con la métrica MED más baja. Para comparar siempre los MED, ya sea que el par de AS de las rutas comparadas sea o no el mismo, incluya la path-selection always-compare-med instrucción.

   • Si se configura un comportamiento de selección de ruta de tabla de enrutamiento no determinista (es decir, la path-selection cisco-nondeterministic instrucción se incluye en la configuración del BGP), prefiera la ruta con la métrica MED más baja.

   Las confederaciones no se tienen en cuenta a la hora de determinar los AS vecinos. Una métrica MED faltante se trata como si un MED estuviera presente pero cero.

   Nota:

   La comparación de MED funciona para la selección de una sola ruta dentro de un AS (cuando la ruta no incluye una ruta de AS), aunque este uso es poco común.

   De forma predeterminada, solo se comparan los MED de las rutas que tienen los mismos sistemas autónomos par (AS). Puede configurar las opciones de selección de rutas de la tabla de enrutamiento para obtener diferentes comportamientos.

8. Prefiera rutas estrictamente internas, que incluyen rutas IGP y rutas generadas localmente (estáticas, directas, locales, etc.).

9. Prefiera las rutas estrictamente externas de BGP (EBGP) sobre las rutas externas aprendidas a través de sesiones de BGP internas (IBGP).

10. Prefiere la ruta cuyo siguiente salto se resuelve mediante la ruta IGP con la métrica más baja. Se prefieren las rutas BGP que se resuelven mediante IGP a las rutas no accesibles o rechazadas.

    Nota:

    Una ruta se considera una ruta de costo igual de BGP (y se utilizará para el reenvío) si se realiza un desempate después del paso anterior. Se consideran todas las rutas con el mismo AS vecino aprendidas por un vecino del BGP habilitado para varias rutas.

    La multiruta del BGP no se aplica a rutas que comparten el mismo costo MED-plus-IGP, pero difieren en el costo de IGP. La selección de rutas multiruta se basa en la métrica de costo del IGP, incluso si dos rutas tienen el mismo costo med-plus-IGP.

11. Si ambas rutas son externas, prefiera la ruta más antigua, es decir, la ruta que aprendió primero. Esto se hace para minimizar el aleteo de rutas. Esta regla no se utiliza si se cumple alguna de las condiciones siguientes:

    • path-selection external-router-id está configurado.

    • Ambos pares tienen el mismo ID de enrutador.

    • Cualquiera de los dos es un par de confederación.

    • Ninguna de las rutas es la ruta activa actual.

12. Prefiera una ruta principal en lugar de una ruta secundaria. Una ruta principal es aquella que pertenece a la tabla de enrutamiento. Una ruta secundaria es aquella que se agrega a la tabla de enrutamiento mediante una política de exportación.

13. Prefiera la ruta del par con el ID de enrutador más bajo. Para cualquier ruta con un atributo id. de origen, sustituya el ID del originador por el ID de enrutador durante la comparación del ID del enrutador.

14. Prefiera la ruta con la longitud de la lista de clústeres más corta. La longitud es 0 para ninguna lista.

15. Prefiera la ruta del par con la dirección IP del par más bajo.

• Selección de ruta de tabla de enrutamiento
• Selección de ruta de tabla BGP
• Efectos de anunciar varias rutas a un destino

Junos OS admite sustancialmente las siguientes RFC y borradores de Internet, que definen estándares para BGP de IP versión 4 (IPv4).

Para obtener una lista de estándares de BGP de ip versión 6 (IPv6) compatibles, consulte Estándares IPv6 compatibles.

Junos OS BGP admite autenticación para intercambios de protocolos (autenticación MD5).

• RFC 1745, BGP4/IDRP para interacción IP—OSPF

• RFC 1772, Aplicación del protocolo de puerta de enlace de borde en Internet

• RFC 1997, Atributo de comunidades BGP

• RFC 2283, Extensiones multiprotocolo para BGP-4

• RFC 2385, Protección de sesiones de BGP mediante la opción de firma TCP MD5

• RFC 2439, Atenuación de solapa de ruta BGP

• RFC 2545, Uso de extensiones multiprotocolo BGP-4 para enrutamiento entre dominios IPv6

• RFC 2796, Reflexión de ruta del BGP: una alternativa al IBGP de malla completa

• RFC 2858, Extensiones multiprotocolo para BGP-4

• RFC 2918, Capacidad de actualización de ruta para BGP-4

• RFC 3065, Confederaciones De Sistema Autónomo para BGP

• RFC 3107, Información de etiquetas de transporte en BGP-4

• RFC 3345, Condición de oscilación persistente de ruta del Protocolo de puerta de enlace de borde (BGP)

• RFC 3392, Anuncio de capacidades con BGP-4

• RFC 4271, Protocolo de puerta de enlace de borde 4 (BGP-4)

• RFC 4273, Definiciones de objetos administrados para BGP-4

• RFC 4360, Atributo de comunidades extendidas del BGP

• RFC 4364, Redes privadas virtuales IP BGP/MPLS (VPN)

• RFC 4456, Reflexión de ruta del BGP: Una alternativa al BGP interno de malla completa (IBGP)

• RFC 4486, Subcódigos para mensaje de notificación de cese del BGP

• RFC 4659, Extensión de red privada virtual (VPN) IP BGP-MPLS para VPN IPv6

• RFC 4632, Enrutamiento entre dominios sin clase (EISC): El plan de asignación y agregación de direcciones de Internet

• RFC 4684, Distribución de ruta restringida para protocolo de puerta de enlace de borde/conmutación de etiquetas multiprotocolo (BGP/MPLS) Protocolo de Internet (IP) Redes privadas virtuales (VPN)

• RFC 4724, Mecanismo de reinicio elegante para BGP

• RFC 4760, Extensiones multiprotocolo para BGP-4

• RFC 4781, Mecanismo de reinicio agraciado para BGP con MPLS

• RFC 4798, conexión de islas IPv6 a través de MPLS IPv4 mediante enrutadores de borde de proveedor IPv6 (6PE)

  No se admite la opción 4b (redistribución de eBGP de rutas IPv6 etiquetadas del AS al AS vecino).

• RFC 4893, Soporte del BGP para espacio de número del AS de cuatro octetos

• RFC 5004, Evite las transiciones de la mejor ruta del BGP de un externo a otro

• RFC 5065, Confederaciones del Sistema Autónomo para BGP

• RFC 5082, el mecanismo de seguridad TTL generalizado (GTSM)

• RFC 5291, Capacidad de filtrado de ruta saliente para BGP-4 (soporte parcial)

• RFC 5292, Filtro de ruta de salida basado en prefijos de dirección para BGP-4 (soporte parcial)

  Los dispositivos que ejecutan Junos OS pueden recibir mensajes ORF basados en prefijos.

• RFC 5396, Representación textual de números de sistema autónomo (AS)

• RFC 5492, Anuncio de capacidades con BGP-4

• RFC 5512, El identificador de familia de direcciones posteriores de encapsulación del BGP (SAFI) y el atributo de encapsulación de túnel BGP

• RFC 5549, Anunciar información de accesibilidad de la capa de red IPv4 con un próximo salto IPv6

• RFC 5575, Difusión de reglas de especificación de flujo

• RFC 5668, Comunidad extendida específica del AS de 4 octetos

• RFC 6286, Identificador de BGP único para todo el sistema autónomo para BGP-4, totalmente compatible con

• RFC 6368, BGP interno como el protocolo de borde de proveedor/cliente para redes privadas virtuales (VPN) IP BGP/MPLS

• RFC 6810, La infraestructura de clave pública de recursos (RPKI) al protocolo de enrutador

• RFC 6811, Validación de origen del prefijo BGP

• RFC 6996, Reserva de sistema autónomo (AS) para uso privado

• RFC 7300, Reserva de números del último sistema autónomo (AS)

• RFC 7611, BGP ACCEPT_OWN atributo de comunidad

  Apoyamos la RFC al permitir que los enrutadores de Juniper acepten rutas recibidas de un reflector de ruta con el valor de la accept-own comunidad.

• RFC 7752, Distribución en dirección norte de información de estado de vínculo y de ingeniería de tráfico (TE) mediante BGP

• RFC 7854, Protocolo de monitoreo BGP (BMP)

• RFC 7911, Anuncio de varias rutas en el BGP

• RFC 8212, Comportamiento predeterminado de propagación de ruta del BGP externo (EBGP) sin políticas: completamente compatibles con las políticas

  Excepciones:

  Los comportamientos en RFC 8212 no se implementan de forma predeterminada para evitar la interrupción de la configuración existente del cliente. El comportamiento predeterminado se mantiene para aceptar y anunciar todas las rutas con respecto a los pares de EBGP.

• RFC 8326, Apagado elegante de la sesión del BGP

• RFC 9069, Soporte para RIB local en el protocolo de monitoreo del BGP (BMP)

• Borrador de Internet draft-idr-rfc8203bis-00, Comunicación de cierre administrativo del BGP (caduca en octubre de 2018)

• Borrador de Internet draft-ietf-grow-bmp-adj-rib-out-01, Soporte para Adj-RIB-Out en el protocolo de monitoreo del BGP (BMP) (vence el 3 de septiembre de 2018)

• Borrador de Internet draft-ietf-idr-aigp-06, El atributo de métrica de IGP acumulado para BGP (caduca en diciembre de 2011)

• Borrador de Internet draft-ietf-idr-as0-06, Codificación del procesamiento del AS 0 (caduca en febrero de 2013)

• Borrador de Internet draft-ietf-idr-link-bandwidth-06.txt, BGP Link Bandwidth Extended Community (caduca en julio de 2013)

• Borrador de Internet draft-ietf-sidr-origin-validation-signaling-00, Prefijo BGP Validación de origen Estado extendido comunidad (soporte parcial) (caduca en mayo de 2011)

  La comunidad extendida (estado de validación de origen) se admite en la política de enrutamiento de Junos OS. No se admite el cambio especificado en el procedimiento de selección de ruta.

• Borrador de Internet draft-kato-bgp-ipv6-link-local-00.txt, emparejamiento BGP4+ usando dirección de enlace IPv6

Los siguientes RFC y borradores de Internet no definen estándares, sino que proporcionan información sobre BGP y tecnologías relacionadas. El IETF los clasifica de varias formas como "experimentales" o "informativos".

• RFC 1965, Confederaciones de Sistema Autónomo para BGP

• RFC 1966, Reflexión de ruta del BGP: una alternativa al IBGP de malla completa

• RFC 2270, Uso de un AS dedicado para sitios albergados a un único proveedor

• Borrador de Internet draft-ietf-ngtrans-bgp-tunnel-04.txt, Conexión de islas IPv6 a través de nubes IPv4 con BGP (caduca en julio de 2002)