Protocolo de puerta de enlace fronteriza

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. BGP se clasifica como un protocolo de enrutamiento de vector de ruta y toma decisiones de enrutamiento basadas en rutas, políticas de red o conjuntos de reglas configurados por un administrador de red.

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

Historia

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

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

Operación

Los vecinos BGP, llamados pares, se establecen mediante configuración manual entre enrutadores para crear una sesión TCP en el puerto 179. Un altavoz 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. Entre los protocolos de enrutamiento, BGP es único en el uso de TCP como protocolo de transporte.

Cuando BGP se ejecuta entre dos pares en el mismo sistema autónomo (AS), se denomina BGP interno (iBGP o Protocolo de puerta de enlace de borde interior). 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 border o enrutadores de borde o simplemente eBGP peers y normalmente se conectan directamente, mientras que Los pares iBGP se pueden interconectar a través de otros enrutadores intermedios. También son posibles otras topologías de implementación, como ejecutar eBGP peering dentro de un túnel VPN, lo que permite que dos sitios remotos intercambien información de enrutamiento de manera segura y aislada.

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

• Las nuevas rutas aprendidas de un par eBGP son re-advertidas a todos los pares iBGP y eBGP.
• Las nuevas rutas aprendidas de un par iBGP son re-advertidas a todos los pares de EBGP.

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

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

Negociación de extensiones

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

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

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

• Idle State:
  • Rechazar todas las conexiones BGP entrantes.
  • Iniciar la inicialización de los desencadenantes del evento.
  • Inicia una conexión TCP con su par BGP configurado.
  • Escucha una conexión TCP de su par.
  • Cambia su estado para conectarse.
  • Si se produce un error en cualquier estado del proceso FSM, la sesión BGP se termina inmediatamente y regresa al estado Idle. Algunas de las razones por las que un router no progresa desde el estado Idle son:
    • El puerto TCP 179 no está abierto.
    • Un puerto TCP al azar sobre 1023 no está abierto.
    • Dirección Peer configurada incorrectamente en cualquiera de los router.
    • El número AS configurado incorrectamente en cualquiera de los router.
• Estado de conexión:
  • Espera una exitosa negociación TCP con pares.
  • BGP no pasa mucho tiempo en este estado si se ha establecido con éxito la sesión TCP.
  • Sends El mensaje abierto a pares y cambios de estado a OpenSent.
  • Si se produce un error, BGP se traslada al estado activo. Algunas razones para el error son:
    • El puerto TCP 179 no está abierto.
    • Un puerto TCP al azar sobre 1023 no está abierto.
    • Dirección Peer configurada incorrectamente en cualquiera de los router.
    • El número AS configurado incorrectamente en cualquiera de los router.
• Activo:
  • Si el router no pudo establecer una sesión TCP exitosa, entonces termina en el estado activo.
  • BGP FSM intenta reiniciar otra sesión de TCP con el par y, si tiene éxito, envía un mensaje abierto al par.
  • Si no tiene éxito de nuevo, el FSM se reinicia al estado de Idle.
  • Los fallos repetidos pueden resultar en un ciclismo de router entre los estados Idle y Active. Algunas de las razones son:
    • El puerto TCP 179 no está abierto.
    • Un puerto TCP al azar sobre 1023 no está abierto.
    • Error de configuración BGP.
    • Congestión de redes.
    • Interfaz de red ondeante.
• OpenSent State:
  • BGP FSM escucha un mensaje abierto de su par.
  • Una vez recibido el mensaje, el router 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 BGP desajuste, el router de pares espera un Mi AS diferente, etc. El router envía un mensaje de notificación al par que indica por qué ocurrió el error.
  • Si no hay error, se envía un mensaje guardián, se establecen varios temporizadores y el estado se cambia a OpenConfirm.
• OpenConfirm State:
  • El par está escuchando un mensaje guardián de su par.
  • Si se recibe un mensaje guardián y ningún temporizador ha expirado antes de la recepción del Keepalive, BGP pasa al estado establecido.
  • Si un temporizador expira antes de recibir un mensaje guardián, o si se produce una condición de error, el router vuelve al estado ocioso.
• 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, entonces se envía un mensaje de notificación al par, y BGP vuelve al estado de Idle.

Conectividad del router y rutas de aprendizaje

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

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

• RIB: routers main routing information base table.
• Loc-RIB: base de información de enrutamiento local BGP mantiene su propia mesa de enrutamiento maestro separada de la mesa de enrutamiento principal del router.
• Adj-RIB-In: Para cada vecino, el proceso BGP mantiene un concepto base de información de enrutamiento adyacente, entrada, que contiene la NLRI recibida del vecino.
• Adj-RIB-Out: Para cada vecino, el proceso BGP mantiene un concepto base de información adyacente, salida , que contiene la NLRI enviar 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 generalmente se pueden interrogar con comandos de administración en el enrutador local. Es bastante común, por ejemplo, almacenar Adj-RIB-In, Adj-RIB-Out y Loc-RIB juntos en la misma estructura de datos, con información adicional adjunta a las entradas RIB. La información adicional le dice al proceso BGP cosas tales como si las entradas individuales pertenecen a los Adj-RIBs para vecinos específicos, si el proceso de selección de rutas entre vecinos hizo que las políticas recibidas fueran elegibles para Loc-RIB y si las entradas de Loc-RIB son elegibles para enviarse al proceso de administración de la tabla de enrutamiento del enrutador local.

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

BGP transporta la información con la que las reglas dentro de los enrutadores que hablan BGP pueden tomar decisiones de política. Parte de la información transportada que está explícitamente destinada a ser utilizada en las decisiones de política son:

• Comunidades
• multi-exit discriminators (MED).
• sistemas autónomos (AS)

Proceso de selección de ruta

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

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

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

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

Pasos para determinar el mejor camino, con el fin de romper la corbata:

Paso	Ámbito	Nombre	Default	Preferencia:	BGP field	NOTA
1	Local a router	Peso local	"Off"	Superior		Parámetro específico de Cisco
2	Interno a AS	Preferencias locales	"Off", todo listo a 100.	Superior	LOCAL_PREF	Si hay varias rutas de iBGP del vecino, se selecciona el que tiene la preferencia local más alta a menos que haya varias rutas con la misma preferencia local.
3		Protocolo de puerta de entrada del interior acumulado (AIGP)	"Off"	Más bajo	AIGP	rfc7311
4	Externo a AS	sistema autónomo (AS) salta	"On", saltado si ignorado en la configuración	Más bajo	AS-path	n AS path es el conjunto de números AS que deben ser atravesados para llegar al destino anunciado. El AS1–AS2–AS3 es más corto que el AS4–AS5–AS6–AS7.
5		Tipo de origen	"IGP"	Más bajo	ORIGIN	0 = IGP 1 = EGP 2 = Incompleta
6		multi-exit discriminator (MED)	"on", importado de IGP	Más bajo	MULTI_EXIT_DISC	Por defecto sólo se compara la ruta con el mismo sistema autónomo (AS). Se puede establecer para ignorar el mismo sistema autónomo (AS). Por defecto IGP interno no se añade. Se puede configurar para añadir métrica IGP. antes de la edición más reciente del estándar BGP, si una actualización no tenía valor MED, varias implementaciones crearon un MED con el valor más alto posible. El estándar actual especifica que los MED desaparecidos se tratan como el valor más bajo posible. Dado que la regla actual puede causar diferentes comportamientos que las interpretaciones de proveedores, las implementaciones BGP que utilizaron el valor predeterminado no estándar tienen una función de configuración que permite seleccionar la regla vieja o estándar.
7	Local a router (Loc-RIB)	eBGP sobre IBGP pats	"on"			Directamente conectado, más indirectamente
8		IGP metic to BGP next hop	"on", importado de IGP	Más bajo		Continúe, incluso si el bestpath ya está seleccionado. Preferir la ruta con el coste interior más bajo a la siguiente placa, según la tabla principal de enrutamiento. Si dos vecinos anunciaron la misma ruta, pero un vecino es alcanzable a través de un enlace de bajo contenido y el otro por un enlace de alto nivel, y el protocolo de enrutamiento interior calcula el costo más bajo basado en el bitrate más alto, la ruta a través del enlace de alto contenido sería preferida y otras rutas bajadas.
9		camino que se recibió primero	"on"	mayor		Solía ignorar los cambios en los pasos 10+
10		router ID	"on"	Más bajo
11		longitud de la lista de grupos	"on"	Más bajo
12		Dirección del vecino	"on"	Más bajo

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

Comunidades

Las comunidades BGP son etiquetas de atributos que se pueden aplicar a los prefijos entrantes o salientes para lograr un objetivo común. Si bien es común decir que BGP permite que un administrador establezca políticas sobre cómo los ISP manejan los prefijos, esto generalmente no es posible, estrictamente hablando. Por ejemplo, BGP de forma nativa no tiene un concepto que permita que un AS le diga a otro AS que restrinja la publicidad de un prefijo solo a los clientes de intercambio de tráfico de América del Norte. En cambio, un ISP generalmente publica una lista de comunidades conocidas o propietarias con una descripción para cada una, lo que esencialmente se convierte en un acuerdo sobre cómo se deben tratar los prefijos.

conocer las comunidades BGP

Attribute Value	Attribute	descripción	Referencia
0x00000000-0x0000FF	Reservado		RFC 1997
0x00010000-0xFFFF	Reservado para Privado Uso		RFC 1997
0xFFFF0000	GRACEFUL_SHUTDOWN	En el vecino AS-peer, establecer LOCAL_PREF, inferior a la ruta lejos de la fuente.	RFC 8326
0xFFFF0001	ACCEPT_OWN	Se utiliza para modificar cómo una ruta originada dentro de un VRF se importa en otros VRFs	RFC 7611
0xFFFF0002	ROUTE_FILTER_TRANSLATED_v4		RFC draft-l3vpn-legacy-rtc
0xFFFF0003	ROUTE_FILTER_v4		RFC draft-l3vpn-legacy-rtc
0xFFFF0004	ROUTE_FILTER_TRANSLATED_v6		RFC draft-l3vpn-legacy-rtc
0xFFFF0005	ROUTE_FILTER_v6		RFC draft-l3vpn-legacy-rtc
0xFFFF0006	LLGR_STALE		RFC draft-uttaro-idr-bgp-persistence
0xFFFF0007	NO_LLGR		RFC draft-uttaro-idr-bgp-persistence
0xFFFF0008	accept-own-nexthop		RFC draft-agrewal-idr-accept-own-nexthop
0xFFFF0009	Standby PE	Permitir una recuperación más rápida de conectividad en diferentes tipos de fallas, con multicast en BGP/MPLS VPNs.	RFC 9026
0xFF000A-0xFF0299	No asignados
0xFFFF029A	BLACKHOLE	Proteger temporalmente contra el ataque de denegación de servicio, permitiendo agujero negro en el vecino AS-peer	RFC 7999
0xFF029B-0xFFFF00	No asignados
0xFFFF01	NO_EXPORT	límite a un límite de confederación BGP	RFC 1997
0xFFFF02	NO_ADVERTISE	limit to a BGP peer	RFC 1997
0xFFFF03	NO_EXPORT_SUBCONFED	límite al sistema autónomo	RFC 1997
0xFFFF04	NOPEER	limitar el número de rutas específicas a todo internet. Para AS multi-hogar, que tienen 2 o más vecinos, que les gusta cargar el equilibrio, donde especificarán una ruta más detallada.	RFC 3765
0xFFFF05-0xFFFF	No asignados

Ejemplos de comunidades comunes incluyen:

• ajustes locales de preferencia,
• geográfica
• restricciones de tipo par
• denegación del servicio de identificación
• Como opciones previas.

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

• A los clientes de América del Norte (Costa Este) 3491:100
• A Clientes 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 le anuncia el prefijo. El usuario final no tiene capacidad técnica para hacer cumplir las acciones correctas que está tomando el ISP, aunque los problemas en esta área generalmente son raros y accidentales.

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

Atributo de comunidad extendida de BGP

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

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

Discriminadores de salida múltiple

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

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

Ejemplos de MED utilizado con BGP cuando se exporta a BGP en Juniper SRX

# Run show ospf route
Por defecto de topología Tabla de ruta:
Ruta del sendero de prefijo NH Metric Next Hop Nexthop
Tipo Tipo Tipo Interfaz Dirección/LSP
10.32.37.0/24 Inter Discard 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

#show route advertising-protocol bgp 10.32.94.169
Prefijo Nexthop MED Lclpref AS path
* 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

Formato de paquete

Formato de encabezado de mensaje

BGP versión 4 formato de encabezado de mensaje

offset	0 a 15																16 a 23								24 a 31
0	Marcador (siempre: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff)
32
64
96
128	Duración																Tipo

• Marker: Incluido para compatibilidad, debe establecerse a todos.
• Duración: Longitud total del mensaje en octets, incluyendo el encabezado.
• Tipo: Tipo de mensaje BGP. Se definen los siguientes valores:
  • Abierto (1)
  • Actualización (2)
  • Notificación (3)
  • KeepAlive (4)
  • Route-Refresh (5)

nota: "Marcador" y "Longitud" se omite de los ejemplos.

Paquete abierto

Versión (8bit)

Versión de BGP utilizada.

Mi AS (16bit)

Número de sistema autónomo.

Tiempo de espera (16bit)

Timeout timer, utilizado para calcular los mensajes de KeepAlive. Predeterminado 90 segundos.

BGP Identifier (32bit)

Dirección IP del remitente.

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

Ejemplo de mensaje abierto

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

Paquete de actualización

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

Ejemplo de mensaje ACTUALIZAR

Tipo: Mensaje de UPDATE (2)
Rutas retiradas Longitud: 0
Sendero Total Atributo Longitud: 25
Atributos de ruta
ORIGIN: IGP
AS_PATH: 64500
NEXT_HOP: 192.0.2.254
MULTI_EXIT_DISC: 0
Network Layer Reachability Information (NLRI)
 192.0.2.0/26 192.0.2.32/26 192.0.2.64/26

Notificación

Si hay un error, se debe a que uno de los campos en el mensaje OPEN o UPDATE no coincide entre los pares, por ejemplo, la versión de BGP no coincide, el enrutador de emparejamiento espera un Mi AS diferente, etc. El enrutador luego envía un Mensaje de notificación al par que indica por qué ocurrió el error.

Códigos de error

Código de error	Nombre	subcódigos
		Código	Nombre
1	Error del encabezado del mensaje	1	Conexión no sincronizada
		2	Duración del mensaje
		3	Tipo de mensaje malo
2	OPEN Error de mensaje	1	Número de versión sin soporte.
		2	Mal Peer AS.
		3	Mal identificador BGP.
		4	Código de autenticación sin apoyo.
		5	Fallo de autenticación.
		6	Tiempo de espera inaceptable.
3	UPDATE Error de mensaje	1	Lista de atributos malformados.
		2	Atributo bien conocido no reconocido.
		3	Desaparecido Atributo bien conocido.
		4	Attribute Flags Error.
		5	Atribuir el error de longitud.
		6	ORIGIN inválido Attribute
		7	Como Bucle de Routing.
		8	Inválido NEXT_HOP Atributo.
		9	Error de atributo opcional.
		10	Invalid Network Field.
		11	Malformed AS_PATH.
4	Hold Timer Expired
5	Error de máquina de estado finito
6	Cese

Ejemplo de mensaje de NOTIFICACIÓN

Tipo: NOTIFICACIÓN Mensaje (3)
Código de error importante: Error de mensaje abierto (2)
Código de error menor (Mensaje abierto): Mal Peer AS (2)
Pegado malo AS: 65200

Mantener vivo

Los mensajes KeepAlive se envían periódicamente para verificar que el par remoto todavía está activo. los mensajes de mantenimiento deben enviarse a intervalos de un tercio del tiempo de espera.

Ejemplo de mensaje KEEPALIVE

Tipo: Mensaje KEEPALIVE (4)

Actualización de ruta

Definido en RFC7313.

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

Ejemplo de mensaje ROUTE-REFRESH

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

Escalabilidad interna

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

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

Reflectores de ruta

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

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

Un RR es un único punto de falla, por lo tanto, se puede configurar al menos un segundo RR para proporcionar redundancia. Como es un par adicional para los otros 10 enrutadores, duplica aproximadamente la cantidad de declaraciones CLI, lo que requiere declaraciones 11 × 2 − 2 = 20 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.

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

Reglas

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

• Las rutas siempre se reflejan en los pares de EBGP.
• Las rutas nunca se reflejan en el iniciador de la ruta.
• Si se recibe una ruta de un par no cliente, reflexione a los pares clientes.
• Si se recibe una ruta de un par de clientes, reflexione a los pares cliente y no cliente.

Clúster

Un RR y sus clientes forman un cluster. Luego, el ID de 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.

Confederación

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

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

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

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

• ruta oscilación
• suboptimal routing
• aumento del tiempo de convergencia BGP

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

Estabilidad

Las tablas de enrutamiento administradas por una implementación de BGP se ajustan continuamente para reflejar los cambios reales en la red, como enlaces o enrutadores que caen y vuelven a funcionar. En la red como un todo, es normal que estos cambios sucedan casi continuamente, pero para cualquier enrutador o enlace en particular, se 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 retiro y re-anuncio repetidos conocido como cambio de ruta puede causar una actividad excesiva en todos los otros enrutadores que conocen la entidad ciclista, 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.

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

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

La investigación posterior ha 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 están fluctuando. Además, a medida que los enlaces troncales y los procesadores de los enrutadores se han vuelto más rápidos, algunos arquitectos de redes han sugerido que la amortiguación de aletas puede no ser tan importante como solía ser, ya que los enrutadores pueden manejar los cambios en la tabla de enrutamiento mucho más rápido. Esto ha llevado al Grupo de trabajo de enrutamiento de RIPE a escribir: "Con las implementaciones actuales de amortiguación de flaps BGP, NO se recomienda la aplicación de amortiguación de flaps en las redes de 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 de sus clientes' contenido y servicios.... Es muy probable que estos efectos secundarios sean peores que el impacto causado por simplemente no ejecutar la amortiguación de aletas en absoluto." Mejorar la estabilidad sin los problemas de la amortiguación de flaps es el tema de la investigación actual.

Crecimiento de la tabla de enrutamiento

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

Hasta finales de 2001, la tabla de enrutamiento global crecía exponencialmente, lo que amenazaba con una eventual interrupción 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 la agregación de rutas. Si bien esto ralentizó el crecimiento de la tabla de enrutamiento a un proceso lineal durante varios años, con la mayor demanda de alojamiento múltiple por parte de las redes de usuarios finales, el crecimiento fue una vez más superlineal a mediados de 2004.

512k día

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

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

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

El resumen de rutas se usa a menudo para mejorar la agregación de la tabla de enrutamiento global BGP, lo que reduce el tamaño de tabla necesario en los enrutadores de un AS. Considere que a AS1 se le ha asignado el gran espacio de direcciones de 172.16.0.0/16, esto se contaría como una ruta en la tabla, pero debido a requisitos del cliente o fines 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 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 superpone todas las demás rutas específicas, para almacenar solo el resumen, 172.16.0.0/16.

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

Si AS1 luego decide 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á los prefijos 172.16.0.0/18 y 172.16.64.0/18 a 172.16.0.0/17, lo que reduce el número de rutas que almacena AS2 a solo dos: 172.16.0.0/17 y 172.16.128.0/18.

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

Agotamiento de números AS y ASN de 32 bits

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

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

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

Las asignaciones de ASN de 32 bits comenzaron en 2007.

Equilibrio de carga

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

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

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

Seguridad

Por diseño, los enrutadores que ejecutan BGP aceptan rutas anunciadas de otros enrutadores BGP de manera predeterminada. Esto permite el enrutamiento automático y descentralizado del tráfico a través de Internet, pero también deja a Internet potencialmente vulnerable a 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 colectivamente conforman Internet, corregir esta vulnerabilidad (por ejemplo, introduciendo el uso de claves criptográficas para verificar la identidad de los enrutadores BGP) es un problema técnica y económicamente desafiante.

Extensiones

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

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

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

Usos

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

Implementaciones

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

Los productos comercializados como conmutadores pueden o no tener un límite de tamaño en las tablas BGP, como 20 000 rutas, mucho más pequeñas que una tabla de Internet completa más rutas internas. Estos dispositivos 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 BGP de redes troncales, o una pequeña empresa que anuncia enruta a un ISP pero solo acepta una ruta predeterminada y quizás una pequeña cantidad de rutas agregadas.

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

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

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

• BIRD, un paquete de enrutamiento GPL para sistemas similares a Unix.
• FRRouting, un tenedor de Quagga para sistemas similares a Unix; y sus antepasados:
  • Quagga, un tenedor de GNU Zebra para sistemas similares a Unix (ya no desarrollados).
  • GNU Zebra, una suite de enrutamiento de GPL que soporta BGP4 (decomisado).
• OpenBGPD, una implementación con licencia BSD por el equipo OpenBSD.
• XORP, el eXtensible Open Router Platform, una suite con licencia BSD de protocolos de enrutamiento.

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

• Tecnologías ágiles
• GNS3 simulador de red de código abierto
• Ixia
• Spirent Communications

Documentos de normas

• RFC 1772, Application of the Border Gateway Protocol in the Internet Protocol (BGP-4) using SMIv2
• RFC 1997, BGP Communities Attribute
• RFC 2439, BGP Route Flap Damping
• RFC 2918, Capacidad de referencia de la ruta para BGP-4
• RFC 3765, NOPEER Community for Border Gateway Protocol (BGP) Route Scope Control
• RFC 4271, A Border Gateway Protocol 4 (BGP-4)
• RFC 4272, BGP Security Vulnerabilities Analysis
• RFC 4273, Definiciones de objetos gestionados para BGP-4
• RFC 4274, BGP-4 Protocol Análisis
• RFC 4275, BGP-4 MIB Implementation Survey
• RFC 4276, BGP-4 Implementation Informe
• RFC 4277, Experiencia con el Protocolo BGP-4
• RFC 4278, Standards Maturity Variance Regarding the TCP MD5 Signature Option (RFC 2385) and the BGP-4 Specification
• RFC 4360, BGP Extended Communities Attribute
• RFC 4456, BGP Route Reflection – Una alternativa a Full Mesh Internal BGP (iBGP)
• RFC 4724, mecanismo de reinicio de excelencia para BGP
• RFC 4760, Multiprotocol Extensiones para BGP-4
• RFC 5065, Confederacións del Sistema Autónomo para BGP
• RFC 5492, Capacidades Anuncio con BGP-4
• RFC 5575, Difusión de reglas de especificación de flujo
• RFC 5701, IPv6 Dirección específica BGP Atributo comunitario ampliado
• RFC 6793, BGP Support for Four-Octet Autonomous System (AS) Number Space
• RFC 7153, IANA Registries for BGP Extended Communities
• RFC 7606, Control de Errores revisado para Mensajes UPDATE BGP
• RFC 7752, North-Bound Distribution of Link-State and Traffic Engineering Information Using BGP
• RFC 7911, Anuncio de múltiples caminos en BGP
• RFC 8092, Atributo de las grandes comunidades BGP
• RFC 8195, Use of BGP Large Communities
• RFC 8642, Policy Behavior for Well-Known BGP Comunidades
• proyecto-ietf-idr-custom-decision-08 – BGP Custom Decision Process, Feb 3, 2017
• Ruta selectiva Refresh para BGP, proyecto IETF
• RFC 1105, Obsolete – Protocolo de la puerta de la frontera (BGP)
• RFC 1654, obsoleto – Protocolo de la puerta de la frontera 4 (BGP-4)
• RFC 1655, Obsolete – Aplicación del Protocolo de la Puerta de la Frontera en Internet
• RFC 1657, Obsoleto – Definiciones de objetos manejados para la cuarta versión de la puerta de la frontera
• RFC 1771, Obsolete – A Border Gateway Protocol 4 (BGP-4)
• RFC 1965, Obsolete – Confederacións del Sistema Autónomo para BGP
• RFC 2796, Obsolete – BGP Route Reflection – Una alternativa a Full Mesh iBGP
• RFC 2858, Obsolete – Multiprotocolo Prórrogas para BGP-4
• RFC 3065, Obsolete – Confederacións del Sistema Autónomo para BGP
• RFC 3392, Obsolete – Capacidades Anuncio con BGP-4
• RFC 4893, obsoleto – BGP Support for Four-octet AS Number Space