Protocolo de puerta de enlace fronteriza

Protocolo para comunicar información de enrutamiento en Internet

"BGP" vuelve a dirigir aquí. Para otros usos, consulte BGP (desambiguación) .

Conjunto de protocolos de internet
Capa de aplicación
BGP DHCP (v6) DNS FTP HTTP HTTPS IMAP LDAP MGCP MQTT NNTP NTP MÚSICA POP PTP ONC / RPC RTP RTSP ROTURA sorbo SMTP SNMP SSH Telnet TLS / SSL XMPP más...
Capa de transporte
TCP UDP DCCP SCTP RSVP más...
Capa de internet
IP IPv4 IPv6 ICMP (v6) ECN IGMP IPsec más...
Capa de enlace
ARP NDP OSPF Túneles L2TP PPP MAC Ethernet Wifi DSL RDSI FDDI más...
v t mi

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 . ^[1] BGP se clasifica como un protocolo de enrutamiento de vector de ruta , ^[2] 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 frontera 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 Border Gateway Protocol se describió por primera vez en 1989 en RFC 1105 y se ha utilizado en Internet desde 1994. ^[3] IPv6 BGP se definió por primera vez en RFC 1883 en 1995, 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. ^[4] 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 lleve una amplia gama de "familias de direcciones" IPv4 e IPv6 . También se le llama Extensiones Multiprotocolo, que es Multiprotocol BGP (MP-BGP).

Operación

Los vecinos BGP, llamados pares, se establecen mediante configuración manual entre enrutadores para crear una sesión TCP en el puerto 179. Un altavoz BGP envía mensajes de 19 bytes de mantenimiento de vida cada 60 segundos ^[5] para mantener la conexión. ^[6] 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 ( i-BGP o Protocolo de puerta de enlace de frontera interior ). Cuando se ejecuta entre diferentes sistemas autónomos, se denomina External BGP ( eBGP o Protocolo de puerta de enlace de borde exterior ). Routers en el límite de un AS intercambio de información con otros como son llamados fronterizas o encaminadores de borde o simplemente pares eBGP y típicamente se conectan directamente, mientras que los compañeros i-BGP se pueden interconectar a través de otros enrutadores intermedios. Otras topologías de implementaciónTambién son posibles, 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 el emparejamiento iBGP y eBGP está en la forma en que las rutas que se recibieron de un par se propagan a otros pares. Por ejemplo, las nuevas rutas aprendidas de un par de eBGP generalmente se redistribuyen a todos los pares de iBGP, así como a todos los demás pares de eBGP (si el modo de tránsito está habilitado en el enrutador). Sin embargo, si se aprenden nuevas rutas en un emparejamiento 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.

La forma en que se propagan las rutas se puede controlar en detalle mediante el mecanismo de mapas de ruta . Este mecanismo consta de 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 eliminar la ruta o modificar algunos atributos de la ruta antes de insertarla en la tabla de enrutamiento .

Negociación de extensiones

Máquina de estado BGP

Durante el apretón de manos de intercambio de tráfico, cuando se intercambian mensajes OPEN, los hablantes de BGP pueden negociar las capacidades opcionales de la sesión, ^[7] incluidas las extensiones multiprotocolo ^[8] 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 las redes privadas virtuales IPv4 (predeterminado), IPv6, 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. ^[9]

Para tomar decisiones en sus operaciones con pares, un par BGP utiliza una máquina de estado finito (FSM) simple que consta de seis estados: inactivo; Conectar; Activo; OpenSent; OpenConfirm; y establecido. Para cada sesión peer-to-peer, 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 peer 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 al 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 regresa 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 Keepalive se intercambian y, una vez recibidos correctamente, el enrutador se coloca en el estado establecido. En el estado establecido, el enrutador puede enviar y recibir: Keepalive; Actualizar;y mensajes de notificación hacia y desde su par.

• Estado inactivo :
  • Rechace todas las conexiones BGP entrantes.
  • Inicie 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 ocurre un error en cualquier estado del proceso FSM, la sesión BGP se termina inmediatamente y se devuelve 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 sobre 1023 no está abierto.
    • Dirección del mismo nivel configurada incorrectamente en cualquiera de los enrutadores.
    • Número de AS configurado incorrectamente en cualquiera de los enrutadores.
• Estado de conexión :
  • Espera una negociación de TCP exitosa con el par.
  • BGP no pasa mucho tiempo en este estado si la sesión TCP se ha establecido con éxito.
  • Envía un mensaje abierto a un par 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 del mismo nivel configurada incorrectamente en cualquiera de los enrutadores.
    • Número de 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 Open al par.
  • Si no tiene éxito nuevamente, el FSM se restablece al estado inactivo.
  • Las fallas repetidas pueden provocar que el enrutador cambie entre los estados inactivo y activo. Algunas de las razones de 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 intermitente.
• Estado de OpenSent :
  • BGP FSM escucha un mensaje abierto de su par.
  • Una vez que se ha recibido el mensaje, el enrutador verifica la validez del mensaje Abierto.
  • Si hay un error, es porque uno de los campos en el mensaje Abierto no coincide entre los pares, por ejemplo, la versión de BGP no coincide, el enrutador de intercambio de tráfico espera un Mi AS diferente, etc. El enrutador 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 se cambia el estado a OpenConfirm.
• Estado OpenConfirm :
  • El par está escuchando un mensaje de 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 de 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 del enrutador y rutas de aprendizaje

Esta sección puede ser demasiado técnica para que la entiendan la mayoría de los lectores . Ayude a mejorarlo para que sea comprensible para los no expertos , sin eliminar los detalles técnicos. ( Abril de 2021 ) ( Obtenga información sobre cómo y cuándo eliminar este mensaje de plantilla )

En la disposición más simple, todos los enrutadores dentro de un solo AS y que participan en el enrutamiento BGP deben configurarse en una malla completa: cada enrutador debe configurarse como un par para todos los demás enrutadores. Esto causa problemas de escala, 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 sobre el procesamiento básico de ACTUALIZACIÓN 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 o un conjunto diferente de vecinos. 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 el NLRI se envíe a El vecino.

El almacenamiento físico y la estructura de estas tablas conceptuales los decide el implementador del código BGP. 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 el 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 en Adj-RIB para vecinos específicos, si el proceso de selección de ruta entre pares y vecinos hizo que las políticas recibidas fueran elegibles para Loc-RIB y si las entradas Loc-RIB son elegibles para ser enviado al proceso de administración de la tabla de enrutamiento del enrutador local.

BGP enviará las rutas que considere 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, un prefijo conectado directamente, aprendido del propio hardware del enrutador, suele ser el más preferido. Mientras la interfaz de la ruta conectada directamente esté activa, la ruta BGP al destino no se incluirá en la tabla de enrutamiento. Una vez que la interfaz deja de funcionar y no hay más rutas preferidas, la ruta Loc-RIB se instalará en la tabla de enrutamiento principal.

Hasta hace poco, era un error común decir "BGP lleva políticas". BGP en realidad transportaba la información con la que las reglas dentro de los enrutadores que hablaban BGP podían tomar decisiones sobre políticas. Parte de la información transportada que está explícitamente destinada a ser utilizada en decisiones políticas son las comunidades y los discriminadores de múltiples salidas (MED).

El estándar BGP especifica una serie de factores de decisión, más que los que se utilizan en cualquier otro proceso de enrutamiento común, para seleccionar NLRI para entrar en Loc-RIB. El primer punto de decisión para evaluar el NLRI es que su atributo de siguiente salto debe ser alcanzable (o resoluble). Otra forma de decir que el siguiente salto debe ser accesible es que debe haber una ruta activa, ya en la tabla de enrutamiento principal del enrutador, hacia el 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 criterios estándar y 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 sea retirada por el vecino.

Siempre que cambia un Adj-RIB-In conceptual, el proceso principal de BGP decide si alguna de las nuevas rutas del vecino se prefiere a las rutas que ya están en 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 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 a ese destino desde ninguna 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 accesible, si la ruta proviene de un par interno (es decir, iBGP), la primera regla a aplicar, de acuerdo con el estándar, es examinar el atributo LOCAL_PREFERENCE. Si hay varias rutas iBGP del vecino, se selecciona la que tenga la LOCAL_PREFERENCE más alta, a menos que haya varias rutas con la misma LOCAL_PREFERENCE. En el último caso, el proceso de selección de ruta pasa al siguiente desempate . Si bien LOCAL_PREFERENCE es la primera regla en el estándar, una vez que se verifica la accesibilidad de NEXT_HOP, Cisco y varios otros proveedores primero consideran un factor de decisión llamado WEIGHT que es local al enrutador (es decir, no transmitido por BGP). Se prefiere la ruta con mayor PESO.

LOCAL_PREFERENCE, WEIGHT y otros criterios se pueden manipular mediante la configuración local y las capacidades del software. Tal manipulación, aunque se usa comúnmente, está fuera del alcance de la norma. Por ejemplo, el atributo COMMUNITY (ver más abajo) no es usado directamente por el proceso de selección de BGP. Sin embargo, el proceso vecino BGP puede tener una regla para establecer LOCAL_PREFERENCE u otro factor basado en una regla programada manualmente para establecer el atributo si el valor de 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 LOCAL_PREFERENCE de las reglas de política local y luego compara LOCAL_PREFERENCE 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. Prefiera la ruta con el AS_PATH más corto. Un AS_PATH es el conjunto de números de AS que se deben atravesar para llegar al destino anunciado. AS1-AS2-AS3 es más corto que AS4-AS5-AS6-AS7.
2. Prefiere rutas con el valor más bajo de su atributo ORIGIN.
3. Prefiera rutas con el valor más bajo de MULTI_EXIT_DISC (discriminador de salidas múltiples o MED).

Antes de la edición más reciente del estándar BGP, si una ACTUALIZACIÓN no tenía un valor MULTI_EXIT_DISC, varias implementaciones creaban una MED con el valor más alto posible. Sin embargo, el estándar actual especifica que los MED que faltan deben tratarse como el valor más bajo posible. Dado que la regla actual puede provocar un comportamiento diferente al de las interpretaciones del proveedor, las implementaciones de BGP que utilizaron el valor predeterminado no estándar tienen una función de configuración que permite seleccionar la regla anterior o estándar.

Una vez que se reciben las rutas candidatas de los vecinos, el software Loc-RIB aplica desempates adicionales a las rutas hacia el 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. Prefiera la ruta con el costo interior más bajo a la NEXT_HOP, de acuerdo con la tabla de enrutamiento principal. Si dos vecinos anunciaron la misma ruta, pero un vecino es accesible a través de un enlace de baja tasa de bits y el otro por un enlace de alta tasa de bits, y el protocolo de enrutamiento interior calcula el costo más bajo basado en la tasa de bits más alta, la ruta a través del enlace de alta tasa de bits 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).

1. Prefiera la ruta aprendida del hablante BGP con el identificador BGP numéricamente más bajo
2. Prefiera la ruta aprendida del altavoz BGP con la dirección IP de pares 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 (RFC 1997). 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 de cada una, que esencialmente se convierte en un acuerdo de cómo se deben tratar los prefijos. RFC 1997 también define tres comunidades bien conocidas que tienen importancia global; NO_EXPORT, NO_ADVERTISE y NO_EXPORT_SUBCONFED. RFC 7611 define ACCEPT_OWN.Ejemplos de comunidades comunes incluyen ajustes de preferencias locales, restricciones geográficas o de tipo de pares, evasión de DoS (agujeros negros) y opciones de antecedente de AS. Un ISP puede indicar que las rutas recibidas de los clientes con la comunidad XXX: 500 se anunciarán a todos los pares (predeterminado), mientras que la comunidad XXX: 501 restringirá la publicidad a América del Norte. 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 la capacidad técnica para hacer cumplir las acciones correctas que está tomando el ISP, aunque los problemas en esta área son generalmente raros y accidentales.Un ISP puede indicar que las rutas recibidas de los clientes con la comunidad XXX: 500 se anunciarán a todos los pares (predeterminado), mientras que la comunidad XXX: 501 restringirá la publicidad a América del Norte. 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 la capacidad técnica para hacer cumplir las acciones correctas que está tomando el ISP, aunque los problemas en esta área son generalmente raros y accidentales.Un ISP puede indicar que las rutas recibidas de los clientes con la comunidad XXX: 500 se anunciarán a todos los pares (predeterminado), mientras que la comunidad XXX: 501 restringirá la publicidad a América del Norte. 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 la capacidad técnica para hacer cumplir las acciones correctas que está tomando el ISP, aunque los problemas en esta área son generalmente raros y accidentales.El usuario final no tiene la capacidad técnica para hacer cumplir las acciones correctas que está tomando el ISP, aunque los problemas en esta área son generalmente raros y accidentales.El usuario final no tiene la capacidad técnica para hacer cumplir las acciones correctas que está tomando el ISP, aunque los problemas en esta área son generalmente 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 rara vez se propagan fuera del AS del siguiente salto. No todos los ISP dan a conocer sus comunidades al público, mientras que algunos otros lo hacen. ^[10]

El Atributo de Comunidad Extendido BGP se agregó en 2006, 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 de BGP. ^[11]El atributo de comunidades extendidas en sí mismo es un atributo de BGP opcional transitivo. 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 extendido de atributos, su uso puede ser variado. RFC 4360 define de manera ejemplar la "Comunidad extendida específica 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 ^[12] también utilizan esta estructura de atributo de comunidad ampliada para la señalización de QoS entre dominios.

Nota: desde RFC 7153, las comunidades extendidas son compatibles con ASN de 32 bits.

Con la introducción de los números AS de 32 bits, algunos problemas fueron inmediatamente obvios con el atributo de comunidad que solo define un campo ASN de 16 bits, lo que evita la coincidencia entre este campo y el valor ASN real. Es la razón por la que 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).

Discriminadores de múltiples salidas

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, generalmente basado en el retraso, de múltiples AS que tienen presencia en un IXP , que imponen para enviar tráfico a algún destino.

Formato de encabezado del mensaje

El siguiente es el formato de encabezado del mensaje BGP versión 4:

desplazamiento de bits	0-15																16-23								24–31
0	Marcador
32
64
96
128	Largo																Tipo

• Marcador : Incluido para compatibilidad, debe establecerse en todos.
• 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)
  • KeepAlive (4)
  • Ruta-Actualizar (5)

Escalabilidad interna

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

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, este número de sesiones puede degradar el rendimiento de los enrutadores, debido a la falta de memoria o a los altos requisitos del proceso de la CPU.

Reflectores de ruta

Los reflectores de ruta ^[14] reducen el número de conexiones necesarias en un AS. Un solo enrutador (o dos por redundancia) se puede convertir en un reflector de ruta: otros enrutadores en el AS solo necesitan configurarse como pares para ellos. Un reflector de ruta ofrece una alternativa al requisito lógico de malla completa del protocolo de puerta de enlace de borde interno (IBGP). Un RR actúa como un punto focal ^{[ aclarar ]} para las sesiones del IBGP. El propósito del RR es la concentración. Múltiples enrutadores BGP pueden emparejarse con un punto central, el RR, que actúa como un servidor reflector de ruta, en lugar de hacerlo con todos los demás enrutadores en una malla completa. Todos los demás enrutadores IBGP se convierten en clientes reflectores de ruta.

Este enfoque, similar a la función DR / BDR de OSPF , proporciona grandes redes con 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 de administrar. Una topología RR podría reducir estas 90 declaraciones a 18, ofreciendo una solución viable para las redes más grandes administradas por los ISP.

Un reflector de ruta es un único punto de falla , por lo tanto, se puede configurar al menos un segundo reflector de ruta para proporcionar redundancia. Como es un par adicional para los otros 10 enrutadores, viene con el recuento de declaraciones adicionales para duplicar menos 2 de la configuración del reflector de ruta única. En este caso, 11 * 2-2 = 20 declaraciones adicionales debido a la adición del enrutador adicional. Además, en un entorno de múltiples rutas de BGP, esto también puede beneficiarse al agregar un rendimiento de enrutamiento / conmutación local si los RR actúan como enrutadores tradicionales en lugar de solo como un rol de servidor reflector de ruta dedicado.

Reglas

Una configuración típica de la implementación del reflector de ruta BGP, según lo propuesto por la Sección 6, RFC 4456.

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

• Si se recibe una ruta de un par que no sea cliente, refleje solo en los clientes y los pares EBGP.
• Si se recibe una ruta de un par del cliente, refleje a todos los pares que no sean clientes y también a los pares del cliente, excepto al originador de la ruta y refleje a los pares EBGP.

Clúster

RR y sus clientes forman un "Cluster". El "Cluster-ID" se adjunta a cada ruta anunciada por RR a sus pares cliente o no cliente. Cluster-ID es un atributo BGP acumulativo, no transitivo y cada RR DEBE anteponer el CLUSTER_ID local a CLUSTER_LIST para evitar bucles de enrutamiento. Los reflectores de ruta y las confederaciones reducen el número de pares iBGP para cada enrutador y, por lo tanto, reducen la sobrecarga de procesamiento. Los reflectores de ruta son una técnica pura para mejorar el 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, ^[15] Internet en su conjunto sólo ve uno de los números AS de la confederación. Las confederaciones se utilizan en redes muy grandes donde se puede configurar un AS grande para abarcar AS internos más pequeños y más manejables.

El AS confederado está compuesto por múltiples AS. Cada AS confederado solo tiene iBGP completamente mallado y tiene conexiones con otros AS dentro de la confederación. Aunque estos AS tienen pares de eBGP a AS dentro de la confederación, los AS intercambian el enrutamiento como si usaran iBGP. De esta manera, la confederación conserva la información de preferencia local, métrica y de siguiente salto. Para el mundo exterior, la confederación parece ser un único 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 oscilación persistente a menos que se sigan reglas de diseño específicas que afecten tanto a BGP como al protocolo de enrutamiento interior. ^[dieciséis]

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

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

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 con experiencia. 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 que los enrutadores se desconectan y vuelven a subir. En la red en su conjunto, 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 los estados inactivo y activo. Este patrón de retiro repetido y re-anuncio conocido como aleteo de rutapuede causar una actividad excesiva en todos los demás 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, un cambio de enrutamiento BGP puede provocar interrupciones durante varios minutos.

En muchas implementaciones de BGP se incorpora una característica conocida como amortiguación de rutas ( RFC 2439 ) en un intento de mitigar los efectos de las rutas. 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 se deteriora 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 falla de BGP. En la segunda aparición, BGP evita ese prefijo durante un cierto período de tiempo; las apariciones posteriores se agotan exponencialmente. Una vez que hayan cesado las anomalías y haya transcurrido un período de tiempo adecuado para la ruta infractora, se pueden restablecer los prefijos y borrar la lista. La amortiguación también puede mitigar los ataques de denegación de servicio ; Los tiempos de amortiguación son altamente personalizables.

También se sugiere en RFC 2439 (en "Opciones de diseño -> Supresión sensible a la estabilidad de la publicidad de ruta") que la amortiguación de la aleta 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 frontera interior (sesiones iBGP o simplemente llamadas pares internos); Con este enfoque, cuando una ruta se aletea dentro de un sistema autónomo, no se propaga a los AS externos; aletear una ruta a un eBGP tendrá una cadena de aleteo para la ruta particular a lo largo de la red troncal. Este método también evita con éxito la sobrecarga de la amortiguación de flap de ruta para sesiones iBGP.

Sin embargo, investigaciones posteriores han demostrado que la amortiguación de flaps en realidad puede alargar los tiempos de convergencia en algunos casos y puede causar interrupciones en la conectividad incluso cuando los enlaces no se agitan. ^{[18] [19]} Además, como los enlaces troncales y los procesadores de enrutamiento 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 . ^[20]Esto ha llevado al RIPE Routing Working Group a escribir que "con las implementaciones actuales de la amortiguación de flaps BGP, NO se recomienda la aplicación de la amortiguación de flaps en las redes ISP. ... Si se implementa la -efectos para sus clientes y 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 aletas en absoluto ". ^[21] Mejorar la estabilidad sin los problemas de la amortiguación del colgajo es el tema de la investigación actual. ^[22]

Crecimiento de la tabla de enrutamiento

Crecimiento de la tabla BGP en Internet

Número de AS en Internet frente al número de AS registrados

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 a las que se 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 deja el servicio de red poco confiable o incluso no disponible en el ínterin.

Hasta finales de 2001, la tabla de enrutamiento global crecía exponencialmente , amenazando con una eventual ruptura generalizada 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 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 demanda expandida de multihoming por parte de las redes de usuarios finales, el crecimiento fue nuevamente superlineal a mediados de 2004.

512k día

Un desbordamiento similar al del año 2000 se desencadenó en 2014 para aquellos modelos que no se actualizaron adecuadamente.

Mientras que una mesa llena IPv4 BGP partir de agosto de 2.014 ^[actualizar](512k día) ^{[23] [24]} fue de más de 512.000 prefijos, ^[25] muchos routers mayores tenían un límite de 512 K (512,000-524,288) ^{[26] [27]} de enrutamiento entradas de la tabla. El 12 de agosto de 2014, las interrupciones resultantes de las mesas llenas afectaron a eBay , LastPass y Microsoft Azure, entre otros. ^[28] 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 rutas IPv4 de 512k y rutas IPv6 de 256k. Si bien la cantidad informada de rutas anunciadas IPv6 fue solo de aproximadamente 20k, la cantidad de rutas IPv4 anunciadas alcanzó el límite predeterminado, lo que provocó un efecto de desbordamiento ya que los enrutadores intentaron compensar el problema mediante el enrutamiento de software lento (a diferencia del 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 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. ^{[29] [30] [31]}

Las asignaciones reales que empujaron el número de rutas por encima de 512k fueron el anuncio de alrededor de 15,000 nuevas rutas en poco tiempo, a partir de las 07:48 UTC. Casi todas estas rutas fueron a los sistemas autónomos 701 y 705 de Verizon , 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 alcance las 515,000 entradas. Las nuevas rutas parecen haber sido reagrupadas en 5 minutos, pero la inestabilidad en Internet aparentemente continuó durante varias horas. ^[32] Incluso si Verizon no hubiera provocado que la tabla de enrutamiento supere las 512.000 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, 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 172.16.0.0 / 16 , esto se contabilizaría como una ruta en la tabla, pero debido a los requisitos del cliente o propósitos 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 hosts, 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 desde 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 tome una copia de las cuatro rutas o, ya que 172.16.0.0 / 16 se superpone a todas las demás rutas específicas, para simplemente 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 el enrutador de AS1, se descartará o se enviará un mensaje ICMP de destino inalcanzable , según la configuración de los enrutadores de AS1.

Si AS1 luego decide descartar 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á el número 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á 172.16.0.0/18 y 172.16.64.0 / 18 del prefijo a 172.16.0.0 / 17 , reduciendo así el número de rutas que AS2 almacena a 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 eliminará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) ) planificó la codificación de números AS en 16 bits, para 64510 posibles AS públicos, ya que ASN 64512 a 65534 estaban reservados para uso privado (0 y 65535 están prohibidos). En 2011, solo estaban disponibles 15.000 números de AS y las proyecciones ^[33] preveían un agotamiento completo de los números de AS disponibles en septiembre de 2013.

RFC 6793 extiende la codificación de AS de 16 a 32 bits (manteniendo el rango de AS de 16 bits de 0 a 65535, y sus números de AS reservados), lo que ahora permite hasta 4 mil millones de AS disponibles. Un rango de AS privado adicional también se define 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 utiliza el nuevo atributo OT AS4_PATH.

Las asignaciones de ASN de 32 bits comenzaron en 2007.

Equilibrio de carga

Otro factor que causa este crecimiento de la tabla de enrutamiento es la necesidad de equilibrar la carga de las redes con múltiples hosts. No es una tarea trivial equilibrar el tráfico entrante a una red multi-homed a través de sus múltiples rutas entrantes, debido a la limitación del proceso de selección de ruta BGP. Para 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 otros enlaces permanecen infrautilizados, porque todas las redes externas eligieron eso. conjunto de caminos congestionados como óptimo. Como la mayoría de los otros 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 modificar el anuncio de 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 bloques de esa red multi-homed. Tales casos aumentarán el número de rutas como se ve en la tabla BGP global.

Un método que está creciendo en popularidad para abordar el problema del equilibrio de carga es implementar puertas de enlace BGP / LISP ( Protocolo de separación de localizador / identificador ) 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 que se ven en la tabla BGP global.

Seguridad

Por diseño, los enrutadores que ejecutan BGP aceptan rutas anunciadas de otros enrutadores BGP de forma 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 una interrupción accidental o maliciosa, conocida 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 componen colectivamente Internet, se corrige esta vulnerabilidad (por ejemplo, mediante la introducción del uso de claves criptográficas para verificar la identidad de los enrutadores BGP) es un problema técnica y económicamente desafiante. ^[34]

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 ruta AS para esperar solo una longitud de ruta igual en lugar de los números AS reales. en el camino se espera que coincida también. Esto se puede ampliar aún más con funciones como dmzlink-bw de Cisco, que permite una proporción de tráfico compartido basada en valores de ancho de banda configurados en enlaces individuales.

Multiprotocol Extensions for BGP (MBGP), a veces denominado Multiprotocol BGP o Multicast BGP y definido en IETF RFC 4760, es una extensión de (BGP) que permite que diferentes tipos de direcciones (conocidas como familias de direcciones) se distribuyan en paralelo. Mientras que BGP estándar solo admite direcciones de unidifusión IPv4, Multiprotocol BGP admite direcciones IPv4 e IPv6 y admite variantes de unidifusión y multidifusión de cada una. Multiprotocol BGP 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 unicast 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 Protocol Independent Multicast, para construir árboles y reenviar tráfico de multidifusión.

Multiprotocol BGP 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 los diferentes sitios del cliente cuando el tráfico de los otros sitios del cliente llega al proveedor. Enrutador de borde (enrutador PE) para enrutamiento.

Usos

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

Implementaciones

Es posible que los enrutadores, especialmente los pequeños destinados al uso en pequeñas oficinas / oficinas en el hogar (SOHO), no incluyan software BGP. Algunos enrutadores SOHO simplemente no son capaces de ejecutar BGP / usar tablas de enrutamiento BGP de ningún tamaño. Otros enrutadores comerciales pueden necesitar una imagen ejecutable de software específica 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 . Los dispositivos comercializados como conmutadores de capa 3 tienen menos probabilidades de admitir 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 tener o no 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. Sin embargo, 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 una confederación-AS que representa una de varias empresas más pequeñas que están vinculadas, por una red troncal de BGP o una pequeña red troncal . 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 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, un requisito de RAM y CPU) que una red de host múltiple. Incluso un 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 de rutas y la aceptación de un AS vecino específico. El término vista se usa a menudo para estas diferentes relaciones de políticas en un enrutador en ejecución.

Si una implementación de enrutador consume más memoria por ruta que otra implementación, esta puede ser una opción de diseño legítima, intercambiar velocidad de procesamiento por memoria. Una tabla IPv4 BGP completa a agosto de 2015 ^[actualizar]supera los 590.000 prefijos. ^{[25] Los} grandes ISP pueden agregar otro 50% para las rutas internas y de los clientes. Nuevamente, dependiendo de la implementación, se pueden mantener tablas separadas para cada vista de un AS de pares diferente.

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

• BIRD Internet Routing Daemon , un paquete de enrutamiento GPL para sistemas similares a Unix.
• FRRouting , una bifurcación de Quagga para sistemas similares a Unix.
• GNU Zebra , una suite de enrutamiento GPL compatible con BGP4. (dado de baja) ^[35]
• OpenBGPD , una implementación con licencia BSD del equipo de OpenBSD .
• Quagga , una bifurcación de GNU Zebra para sistemas similares a Unix.
• XORP , la plataforma extensible de enrutador abierto, un conjunto de protocolos de enrutamiento con licencia BSD.

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

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

Documentos de normas

• Actualización de ruta selectiva para BGP , borrador IETF
• RFC 1772, Aplicación del Protocolo de puerta de enlace fronteriza en el Protocolo de Internet (BGP-4) usando SMIv2
• RFC 2439, amortiguación de aletas de ruta BGP
• RFC 2918, capacidad de actualización de ruta para BGP-4
• RFC 3765, NOPEER Community for Border Gateway Protocol (BGP) Control de alcance de ruta
• RFC 4271, A Border Gateway Protocol 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 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, Varianza de madurez de estándares con respecto a la opción de firma TCP MD5 (RFC 2385) y la especificación BGP-4
• 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 4893, BGP Soporte para espacio numérico AS de cuatro octetos
• RFC 5065, Confederaciones de sistemas autónomos para BGP
• RFC 5492, Anuncio de capacidades con BGP-4
• RFC 5575, Divulgación de reglas de especificación de flujo
• RFC 7752, Distribución norte de la información de ingeniería de tráfico y estado de enlace mediante BGP
• RFC 7911, Anuncio de varias rutas en BGP
• draft-ietf-idr-custom-decision-08  - Proceso de decisión personalizado de BGP, 3 de febrero de 2017
• RFC 3392, obsoleto - Anuncio de capacidades con BGP-4
• RFC 2796, obsoleto - Reflexión de ruta BGP - Una alternativa a iBGP de malla completa
• RFC 3065, obsoleto - Confederaciones de sistemas autónomos para BGP
• RFC 1965, Obsoleto - Confederaciones de sistemas autónomos para BGP
• RFC 1771, obsoleto: un protocolo de puerta de enlace fronteriza 4 (BGP-4)
• RFC 1657, obsoleto - Definiciones de objetos administrados para la cuarta versión de Border Gateway
• RFC 1655, obsoleto: aplicación del protocolo de puerta de enlace fronteriza en Internet
• RFC 1654, obsoleto: un protocolo de puerta de enlace fronteriza 4 (BGP-4)
• RFC 1105, obsoleto - Protocolo de puerta de enlace fronteriza (BGP)
• RFC 2858, obsoleto - Extensiones multiprotocolo para BGP-4

Ver también

• Incidente AS 7007
• Autoridad de asignación de números de Internet
• Reenvío de paquetes
• IP privada
• QPPB
• Registro regional de Internet
• Análisis de ruta
• Filtrado de ruta
• Base de datos de activos de enrutamiento

Referencias

1. "BGP: Explicación del protocolo de puerta de enlace fronteriza" . Orbit-Computer Solutions.Com . Archivado desde el original el 28 de septiembre de 2013 . Consultado el 8 de octubre de 2013 .
2. Sobrinho, João Luís (2003). "Enrutamiento de red con protocolos de vector de ruta: teoría y aplicaciones" (PDF) . Consultado el 16 de marzo de 2018 .
3. "La historia del protocolo Border Gateway" . blog.datapath.io .
4. Un protocolo de puerta de enlace fronteriza 4 (BGP-4) . RFC 4271 . 
5. "Mensajes de BGP Keepalive" . Tutoriales de TI de InetDaemon .
6. RFC 4274
7. R. Chandra; J. Scudder (mayo de 2000). Anuncio de capacidades con BGP-4 . doi : 10.17487 / RFC2842 . RFC 2842 .
8. T. Bates; et al. (Junio ​​de 2000). Extensiones multiprotocolo para BGP-4 . doi : 10.17487 / RFC2858 . RFC 2858 .
9. E. Rosen; Y. Rekhter (abril de 2004). VPN BGP / MPLS . doi : 10.17487 / RFC2547 . RFC 2547 .
10. "Guías de la comunidad BGP" . Consultado el 13 de abril de 2015 .
11. Registro IANA para tipos de comunidades extendidas BGP , IANA, 2008
12. Borradores de IETF en BGP señalizados QoS Archivado 2009-02-23 en Wayback Machine , Thomas Knoll, 2008
13. "Protocolo de puerta de enlace fronteriza (BGP)" . Cisco .com .
14. Reflexión de ruta BGP: una alternativa al BGP interno de malla completa (iBGP) , RFC 4456, T. Bates et al. , Abril de 2006
15. "Información" . www.ietf.org . Consultado el 17 de diciembre de 2019 .
16. "Información" . www.ietf.org . Consultado el 17 de diciembre de 2019 .
17. "Información" . www.ietf.org . Consultado el 17 de diciembre de 2019 .
18. "La amortiguación de la aleta de ruta exacerba la convergencia de enrutamiento de Internet" (PDF) . Noviembre de 1998.
19. Zhang, Beichuan; Pei Dan; Daniel Massey; Lixia Zhang (junio de 2005). "Interacción del temporizador en la amortiguación de flaps de ruta" (PDF) . IEEE 25th International Conference on Distributed Computing Systems . Consultado el 26 de septiembre de 2006 . Demostramos que el diseño de amortiguación actual conduce al comportamiento previsto solo bajo aleteo de ruta persistente. Cuando el número de flaps es pequeño, la dinámica de enrutamiento global se desvía significativamente del comportamiento esperado con un retraso de convergencia más largo.
20. "Amortiguación de solapa de ruta BGP" . Tools.ietf.org.
21. "Recomendaciones del grupo de trabajo de enrutamiento RIPE sobre amortiguación de flap de ruta" . Centro de Coordinación de la Red RIPE. 2006-05-10 . Consultado el 4 de diciembre de 2013 .
22. "draft-ymbk-rfd-usable-02 - Haciendo utilizable la amortiguación de la aleta de ruta" . Tools.ietf.org . Consultado el 4 de diciembre de 2013 .
23. partir del 12 de agosto de 2014, varios enrutadores de Internet , fabricados por Cisco y otros proveedores, encontraron un límite de software predeterminado de 512K (512,000 - 524,288) "Problema de conmutador de Cisco" .
24. "Rutas globales de Renesys 512k" .
25. "Informes de BGP" . potaroo.net .
26. "Procedimientos de ajuste de asignación de TCAM de conmutadores y enrutadores de las series CAT 6500 y 7600" . Cisco . 9 de marzo de 2015.
27. Jim Cowie. "Internet toca medio millón de rutas: interrupciones posibles la próxima semana" . Investigación Dyn .
28. Garside, Juliette; Gibbs, Samuel (14 de agosto de 2014). "La infraestructura de Internet 'necesita actualizarse o se producirán más apagones ' " . The Guardian . Consultado el 15 de agosto de 2014 .
29. "Informe BOF" (PDF) . www.nanog.org . Consultado el 17 de diciembre de 2019 .
30. Greg Ferro. "TCAM - una mirada más profunda y el impacto de IPv6" . EtherealMind .
31. "El sitio de agotamiento de IPv4" . ipv4depletion.com .
32. "Qué causó el hipo de Internet de hoy" . bgpmon.net .
33. Informe del sistema autónomo de 16 bits , Geoff Huston 2011 (archivo original en https://web.archive.org/web/20110906085724/http://www.potaroo.net/tools/asn16/ )
34. Craig Timberg (31 de mayo de 2015). "La solución rápida para un problema temprano de Internet vive un cuarto de siglo después" . The Washington Post . Consultado el 1 de junio de 2015 .
35. "GNU Zebra" .

Lectura adicional

• Capítulo "Border Gateway Protocol (BGP)" en el "Manual de tecnología IOS" de Cisco

Enlaces externos

• Recursos de enrutamiento de BGP (incluye una sección dedicada a BGP e ISP Core Security )
• Estadísticas de la tabla BGP