Border Gateway Protocol ( BGP ) es un protocolo de gateway exterior estandarizado diseñado para intercambiar información de enrutamiento y accesibilidad entre sistemas autónomos (AS) en Internet . [2] BGP se clasifica como un protocolo de enrutamiento de vector de ruta , [3] y toma decisiones de enrutamiento basadas en rutas, políticas de red o conjuntos de reglas configurados por un administrador de red .
El BGP utilizado para el enrutamiento dentro de un sistema autónomo se denomina Protocolo de puerta de enlace de frontera interior ( IBGP ). Por el contrario, la aplicación del protocolo en Internet se denomina Protocolo de puerta de enlace de fronteras exteriores ( EBGP ).
El protocolo Border Gateway fue esbozado en 1989 por ingenieros en el reverso de "tres servilletas manchadas de ketchup" y todavía se conoce como el protocolo de las tres servilletas . [4] Se describió por primera vez en 1989 en RFC 1105 y se ha utilizado en Internet desde 1994. [5] IPv6 BGP se definió por primera vez en RFC 1654 en 1994 y se mejoró a RFC 2283 en 1998.
La versión actual de BGP es la versión 4 (BGP4), que se publicó por primera vez como RFC 1654 en 1994, posteriormente actualizada por RFC 1771 en 1995 y RFC 4271 en 2006. [6] RFC 4271 corrigió errores, aclaró ambigüedades y actualizó la especificación con prácticas comunes de la industria. La principal mejora de BGP4 fue la compatibilidad con el enrutamiento entre dominios sin clases (CIDR) y el uso de agregación de rutas para disminuir el tamaño de las tablas de enrutamiento . RFC 4271 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).
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 19 bytes cada 30 segundos (valor predeterminado del protocolo, ajustable) para mantener la conexión. [7] Entre los protocolos de enrutamiento, BGP es el único que utiliza 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 frontera 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 enrutadores de borde o de borde o simplemente pares eBGP y generalmente están conectados directamente, mientras que los pares iBGP pueden interconectarse a través de otros enrutadores intermedios. También son posibles otras topologías de implementación , como ejecutar emparejamiento eBGP dentro de un túnel VPN , lo que permite que dos sitios remotos intercambien información de enrutamiento de manera segura y aislada.
La principal diferencia entre el emparejamiento iBGP y eBGP está en la forma en que las rutas que se recibieron de un interlocutor normalmente se propagan de forma predeterminada a otros interlocutores:
Estas reglas de propagación de rutas requieren efectivamente que todos los pares iBGP dentro de un AS estén interconectados en una malla completa con sesiones iBGP.
La forma en que se propagan las rutas se puede controlar en detalle mediante el mecanismo de mapas de ruta . Este mecanismo consta de un conjunto de reglas. Cada regla describe, para las rutas que coinciden con algunos criterios determinados, 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 .
Durante el protocolo de enlace, cuando se intercambian mensajes OPEN, los hablantes BGP pueden negociar capacidades opcionales de la sesión, [8] incluidas extensiones multiprotocolo [9] 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 utiliza como protocolo de señalización generalizado para transportar información sobre rutas que pueden no ser parte de Internet global, como las VPN. [10]
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; Abierto enviado; AbrirConfirmar; y Establecido. Para cada sesión de igual a igual, 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 igual debe intercambiar para cambiar la sesión de un estado a otro.
El primer estado es el estado inactivo. En el estado inactivo, BGP inicializa todos los recursos, rechaza todos los intentos de conexión BGP entrantes e inicia una conexión TCP con el par. El segundo estado es Conectar. En el estado Conectar, el enrutador espera a que se complete la conexión TCP y pasa al estado OpenSent si tiene éxito. Si no tiene éxito, inicia el temporizador ConnectRetry y pasa al estado Activo al vencimiento. 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 Keepalive se intercambian y, tras su recepción exitosa, 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.
En la disposición más simple, todos los enrutadores dentro de un único AS y que participan en el enrutamiento BGP deben configurarse en una malla completa: cada enrutador debe configurarse como un par de todos los demás enrutadores. Esto causa problemas de escala, 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 determinado puede aceptar actualizaciones de información de accesibilidad de la capa de red (NLRI) de múltiples 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: tabla base de información de enrutamiento principal del enrutador .Loc-RIB: la base de información de enrutamiento local BGP mantiene su propia tabla de enrutamiento maestra separada de la tabla de enrutamiento principal del enrutador.Adj-RIB-In: Para cada vecino, el proceso BGP mantiene una base conceptual de información de enrutamiento adyacente , entrante , que contiene el NLRI recibido del vecino.Adj-RIB-Out: Para cada vecino, el proceso BGP mantiene una base conceptual de información de enrutamiento adyacente , saliente , que contiene el envío NLRI al 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 pueden interrogarse con comandos de administración en el enrutador local. Es bastante común, por ejemplo, almacenar Adj-RIB-In, Adj-RIB-Outy the Loc-RIBjuntos en la misma estructura de datos, con información adicional adjunta a las entradas RIB. La información adicional le indica al proceso BGP aspectos tales como si las entradas individuales pertenecen a Adj-RIBsvecinos específicos, si el proceso de selección de ruta entre pares-vecinos hizo que las políticas recibidas fueran elegibles para Loc-RIBy si Loc-RIBlas entradas son elegibles para enviarse a la administración de la tabla de enrutamiento del enrutador local. proceso.
BGP envía las rutas que considera mejores al proceso de la tabla de enrutamiento principal . Dependiendo de la implementación de ese proceso, no necesariamente se selecciona la ruta BGP. Por ejemplo, normalmente se prefiere un prefijo conectado directamente, aprendido del propio hardware del enrutador. Mientras la interfaz de esa ruta conectada directamente esté activa, la ruta BGP al destino no se incluirá en la tabla de enrutamiento. Una vez que la interfaz se caiga y no haya más rutas preferidas, la ruta Loc-RIB se instalará 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 políticas. Parte de la información transportada que está explícitamente destinada a ser utilizada en decisiones políticas es:
El estándar BGP especifica una serie de factores de decisión, más que los utilizados por cualquier otro proceso de enrutamiento común, para seleccionar NLRI para ingresar al Loc-RIB. El primer punto de decisión para evaluar NLRI es que su atributo de siguiente salto debe ser alcanzable (o resoluble). Otra forma de decir que el siguiente salto debe ser 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 siguiente salto.
A continuación, para cada vecino, el proceso BGP aplica varios criterios estándar y dependientes de la implementación para decidir qué rutas deberían entrar conceptualmente en Adj-RIB-In. El vecino podría enviar varias rutas posibles a un destino, pero el primer nivel de preferencia es 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 retirada por el vecino.
Siempre que cambia un Adj-RIB-In conceptual, el proceso BGP principal decide si alguna de las nuevas rutas del vecino se prefiere a las rutas que ya están en el Loc-RIB. Si es así, los reemplaza. Si un vecino retira una ruta determinada y no hay otra ruta a 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.
Mientras haya desempate, el proceso de selección de ruta pasa al siguiente paso.
La preferencia local, el peso y otros criterios pueden manipularse mediante la configuración local y las capacidades del software. Dicha manipulación, aunque se utiliza comúnmente, está fuera del alcance de la norma. Por ejemplo, el atributo de comunidad (ver más abajo) no se utiliza directamente en el proceso de selección de BGP. El proceso vecino 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 política local y luego compara la preferencia local de todas las rutas del vecino.
Las comunidades BGP son etiquetas de atributos que se pueden aplicar a prefijos entrantes o salientes para lograr algún objetivo común. [13] Si bien es común decir que BGP permite a un administrador establecer políticas sobre cómo los ISP manejan los prefijos, esto generalmente no es posible, estrictamente hablando. Por ejemplo, BGP no tiene ningún concepto nativo que permita a un AS decirle a otro AS que restrinja la publicidad de un prefijo sólo a clientes peering de América del Norte. En cambio, un ISP generalmente publica una lista de comunidades conocidas o propietarias con una descripción para cada una, lo que esencialmente se convierte en un acuerdo sobre cómo se deben tratar los prefijos.
Ejemplos de comunidades comunes incluyen:
Un ISP podría indicar que cualquier ruta recibida de los clientes con los siguientes ejemplos:
El cliente simplemente ajusta su configuración para incluir la comunidad o comunidades correctas para cada ruta, y el ISP es responsable de controlar a quién se anuncia el prefijo. El usuario final no tiene capacidad técnica para hacer cumplir las acciones correctas que está tomando el ISP, aunque los problemas en esta área son generalmente raros y accidentales. [15] [16]
Es una táctica común para los clientes finales utilizar comunidades BGP (normalmente ASN:70,80,90,100) para controlar la preferencia local que el ISP asigna a las rutas anunciadas en lugar de utilizar MED (el efecto es similar). El atributo de comunidad es transitivo, pero las comunidades aplicadas por el cliente rara vez se propagan fuera del AS del siguiente salto. No todos los ISP dan a conocer sus comunidades al público. [17]
El atributo de comunidad extendido BGP se agregó en 2006, [18] para ampliar el rango de dichos atributos y proporcionar un atributo de comunidad estructurado 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 BGP. [19] El atributo de comunidades extendidas en sí es un atributo BGP opcional transitivo. 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 múltiple. RFC 4360 define de manera ejemplar la "Comunidad extendida específica de AS de dos octetos", la "Comunidad extendida específica de dirección IPv4", la "Comunidad extendida opaca", la "Comunidad de destino de ruta" y la "Comunidad de origen de ruta". Varios borradores de QoS de BGP también utilizan esta estructura de atributos de comunidad extendidos para la señalización de QoS entre dominios. [20]
Con la introducción de los números AS de 32 bits, algunos problemas se hicieron inmediatamente obvios 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 comunidad grande de 12 bytes, dividido en tres campos de 4 bytes cada uno (AS:función:parámetro). [21]
Los MED, definidos en el estándar principal BGP, originalmente estaban destinados a mostrarle a otro AS vecino la preferencia del AS publicitario sobre cuál de varios enlaces es el preferido para el tráfico entrante. Otra aplicación de los MED es anunciar el valor, generalmente basado en el retraso, de múltiples AS que tienen presencia en un IXP , que imponen para enviar tráfico a algún destino.
Algunos enrutadores (como Juniper) utilizarán la métrica de OSPF para configurar MED.
Ejemplos de MED utilizados con BGP cuando se exportan a BGP en Juniper SRX
# run show ospf route Topología predeterminada Tabla de ruta: Prefijo Ruta Ruta NH Métrica NextHop Nexthop Tipo Tipo Tipo Dirección de interfaz/LSP 10.32.37.0/24 IP de descarte inter 16777215 10.32.37.0/26 IP de red intra 101 ge-0/0/1.0 10.32 .37.241 10.32.37.64/26 IP intrared 102 ge-0/0/1.0 10.32.37.241 10.32.37.128/26 IP intrared 101 ge-0/0/1.0 10.32.37.241 # mostrar ruta protocolo publicitario bgp 10 .32.94.169 Prefijo Nexthop MED Lclpref AS ruta * 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 Yo 101 Yo nota: "Marcador" y "Longitud" se omiten en los ejemplos.
Ejemplo de mensaje abierto
Tipo: Mensaje abierto (1)Versión: 4Mi AS: 64496Tiempo de espera: 90Identificador BGP: 192.0.2.254Parámetros opcionales Longitud: 16Parámetros opcionales: Capacidad: Capacidad de extensiones multiprotocolo (1) Capacidad: capacidad de actualización de ruta (2) Capacidad: Capacidad de actualización de ruta (Cisco) (128)Solo se envían los cambios, después del intercambio inicial, solo se envían las diferencias (agregar/cambiar/eliminar).
Ejemplo de mensaje de ACTUALIZACIÓN
Tipo: Mensaje de ACTUALIZACIÓN (2)Longitud de rutas retiradas: 0Longitud total del atributo de ruta: 25Atributos de ruta ORIGEN: IGP AS_PATH: 64500 SIGUIENTE_HOP: 192.0.2.254 MULTI_EXIT_DISC: 0Información de accesibilidad de la capa de red (NLRI) 192.0.2.0/27 192.0.2.32/27 192.0.2.64/27
Si hay un error, es porque uno de los campos en el mensaje ABRIR o ACTUALIZAR no coincide entre los pares, por ejemplo, la versión de BGP no coincide, el enrutador de emparejamiento espera un Mi AS diferente, etc. Luego, el enrutador envía un mensaje de notificación a el par indica por qué ocurrió el error.
Ejemplo de mensaje de NOTIFICACIÓN
Tipo: Mensaje de NOTIFICACIÓN (3)Código de error mayor: Error de mensaje ABIERTO (2)Código de error menor (mensaje abierto): AS de igual incorrecto (2)Mal par AS: 65200
Los mensajes KeepAlive se envían periódicamente para verificar que el par remoto todavía esté vivo. Los keepalives deben enviarse a intervalos de un tercio del holdtime.
Ejemplo de mensaje KEEPALIVE
Tipo: Mensaje KEEPALIVE (4)
Definido en RFC 7313.
Permite la actualización suave de Adj-RIB-in, sin restablecer la conexión.
Ejemplo de mensaje ROUTE-REFRESH
Tipo: Mensaje ROUTE-REFRESH (5)Identificador de familia de direcciones (AFI): IPv4 (1)Subtipo: Solicitud de actualización de ruta normal [RFC2918] con/sin ORF [RFC5291] (0)Identificador de familia de direcciones posteriores (SAFI): Unicast (1)
BGP es "el más escalable de todos los protocolos de enrutamiento". [23]
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, debido a la falta de memoria o a los altos requisitos de proceso de la CPU.
Los reflectores de ruta (RR) reducen la cantidad de conexiones requeridas en un AS. Un solo enrutador (o dos para redundancia) se puede convertir en 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 conectarse con un punto central, el RR, que actúa como un servidor RR, en lugar de conectarse con todos los demás enrutadores en una malla completa. Todos los demás enrutadores iBGP se convierten en clientes RR. [24]
Este enfoque, similar a la función DR/BDR de OSPF , proporciona a las redes grandes una escalabilidad iBGP adicional. En una red iBGP completamente interconectada de 10 enrutadores, se necesitan 90 declaraciones CLI individuales (repartidas en todos los enrutadores de la topología) solo para definir el AS remoto de cada par: esto rápidamente se convierte en un dolor de cabeza de 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, aproximadamente duplica la cantidad de declaraciones CLI, lo que requiere 11 × 2 − 2 = 20 declaraciones adicionales en este caso. En un entorno de rutas múltiples BGP, el RR adicional también puede beneficiar a la red al agregar rendimiento de enrutamiento local si los RR actúan como enrutadores tradicionales en lugar de solo una función de servidor RR dedicado.
Tanto los RR como las confederaciones reducen la cantidad de pares iBGP en cada enrutador y, por lo tanto, reducen la sobrecarga de procesamiento. Los RR son una técnica pura para mejorar el desempeño, mientras que las confederaciones también pueden usarse para implementar políticas más detalladas.
Los servidores RR propagan rutas dentro del AS según las siguientes reglas:
Un RR y sus clientes forman un cluster . Luego, el ID del clúster se adjunta a cada ruta anunciada por el RR a sus pares clientes o no clientes. Un ID de clúster es un atributo BGP acumulativo y no transitivo, y cada RR debe anteponer el ID del clúster local a la lista de clústeres para evitar bucles de enrutamiento.
Las confederaciones son conjuntos de sistemas autónomos. En la práctica común, [25] 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 manejables.
El AS confederado se compone de múltiples AS. Cada AS confederado por sí solo tiene iBGP completamente integrado y tiene conexiones con otros AS dentro de la confederación. Aunque estos AS tienen pares eBGP con los AS dentro de la confederación, los AS intercambian rutas como si usaran iBGP. De esta manera, la confederación conserva la información del próximo 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. [ se necesita aclaración ]
Las confederaciones se pueden utilizar 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 afecten tanto a BGP como al protocolo de enrutamiento interior. [26]
Estas alternativas pueden presentar sus propios problemas, incluidos los siguientes:
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 se pueden combinar, por ejemplo, como una jerarquía de reflectores de ruta.
Las tablas de enrutamiento administradas por una implementación BGP se ajustan continuamente para reflejar los cambios reales en la red, como enlaces o enrutadores que caen y vuelven a funcionar. En la red en su conjunto, es normal que estos cambios ocurran casi continuamente, pero para cualquier enrutador o enlace en particular, se espera que los cambios sean relativamente poco frecuentes. Si un enrutador está mal configurado o administrado mal, puede entrar en un ciclo rápido entre estados inactivo y activo. Este patrón de retiro y reanuncio repetido, conocido como cambio de ruta , puede provocar una actividad excesiva en todos los demás 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 es posible que la entrega de tráfico no funcione 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 aleteo de ruta ( RFC 2439) está integrada en muchas implementaciones de BGP en un intento de mitigar los efectos del aleteo 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 disminuye exponencialmente . En el primer caso, cuando una ruta deja de estar disponible y reaparece rápidamente, la amortiguación no surte efecto para mantener los tiempos de conmutación por error normales de BGP. En la segunda aparición, BGP evita ese prefijo durante un cierto período de tiempo; las ocurrencias posteriores se ignoran exponencialmente por más tiempo. Una vez que las anomalías han cesado y ha transcurrido un período de tiempo adecuado para la ruta infractora, los prefijos se pueden restablecer desde cero. La amortiguación también puede mitigar los ataques de denegación de servicio .
También se sugiere en RFC 2439 : Sección 4 que la amortiguación de aletas de ruta es una característica más deseable si se implementa en sesiones de protocolo de puerta de enlace de frontera 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 oscila dentro de un sistema autónomo, no se propaga a los AS externos; la oscilación de una ruta hacia un eBGP provocará una cadena de oscilaciones 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 los flaps de ruta para las sesiones iBGP.
Investigaciones posteriores han demostrado que la amortiguación de las aletas puede en realidad alargar los tiempos de convergencia en algunos casos y puede causar interrupciones en la conectividad incluso cuando los enlaces no están aleteando. [28] [29] Además, a medida que los enlaces troncales y los procesadores de enrutadores se han vuelto más rápidos, algunos arquitectos de redes han sugerido que la amortiguación de flaps puede no ser tan importante como solía ser, ya que los enrutadores pueden manejar los cambios en la tabla de enrutamiento mucho más rápido. . [30] Esto ha llevado al Grupo de Trabajo de Enrutamiento RIPE a escribir: "Con las implementaciones actuales de amortiguación de aletas BGP, NO se recomienda la aplicación de amortiguación de aletas en redes ISP... Si se implementa la amortiguación de aletas, el ISP que opera esa red causará efectos secundarios a sus clientes y a los usuarios de Internet del contenido y 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." [31] Mejorar la estabilidad sin los problemas de amortiguación de los flaps es el tema de la investigación actual. [32] [ necesita actualización ]
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 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 después de un cambio importante en la conectividad, lo que hace que el servicio de red no sea confiable o incluso no esté disponible mientras tanto.
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 clase (CIDR) y agregación de rutas . Si bien esto desaceleró el crecimiento de la tabla de enrutamiento hasta convertirlo en un proceso lineal durante varios años, con la mayor demanda de multihoming por parte de las redes de usuarios finales, el crecimiento volvió a ser superlineal a mediados de 2004.
En 2014 se desencadenó un desbordamiento similar al del año 2000 para aquellos modelos que no se actualizaron adecuadamente.
Si bien una tabla BGP IPv4 completa en agosto de 2014 [update](512k días) [33] [34] superaba los 512 000 prefijos, [35] muchos enrutadores más antiguos tenían un límite de enrutamiento de 512 k (512 000–524 288) [36] [37] entradas de la tabla. El 12 de agosto de 2014, las interrupciones resultantes de tablas llenas afectaron a eBay , LastPass y Microsoft Azure, entre otros. [38] Varios enrutadores Cisco comúnmente utilizados tenían TCAM , una forma de memoria direccionable por contenido de alta velocidad , para almacenar rutas anunciadas por BGP. En los enrutadores afectados, el TCAM se asignó de forma predeterminada como rutas IPv4 de 512 k y rutas IPv6 de 256 k. Si bien el número informado de rutas IPv6 anunciadas fue solo de aproximadamente 20 000, el número de rutas IPv4 anunciadas alcanzó el límite predeterminado, lo que provocó un efecto indirecto ya que los enrutadores intentaron compensar el problema utilizando un enrutamiento de software lento (a diferencia del enrutamiento rápido de hardware 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 parte del TCAM reservado para rutas IPv6, lo que requiere un reinicio en la mayoría de los enrutadores. El problema de 512k fue predicho por varios profesionales de TI. [39] [40] [41]
Las asignaciones reales que elevaron el número de rutas por encima de los 512.000 fueron el anuncio de unas 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 , creados como resultado de la desagregación de bloques más grandes, introduciendo miles de nuevas rutas / 24 y haciendo que la tabla de enrutamiento alcance 515.000 entradas. Las nuevas rutas parecen haber sido reagregadas en 5 minutos, pero la inestabilidad en Internet aparentemente continuó durante varias horas. [42] Incluso si Verizon no hubiera provocado que la tabla de enrutamiento excediera las 512.000 entradas en el breve pico, pronto habría sucedido a través del crecimiento natural.
El resumen de rutas se utiliza a menudo para mejorar la agregación de la tabla de enrutamiento global BGP, reduciendo así el tamaño de tabla necesario en los enrutadores de un AS. Considere que a AS1 se le ha asignado el gran espacio de direcciones de 172.16.0.0 / 16 , esto se contaría como una ruta en la tabla, pero debido a 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 ningún host por lo que AS1 no anuncia una ruta específica 172.16.192.0/18 . Todo esto cuenta como AS1 que anuncia 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 hacerlo o no . tome una copia de las cuatro rutas o, como 172.16.0.0/16 se superpone a todas las demás rutas específicas, solo almacene el resumen , 172.16.0.0/16 .
Si AS2 quiere enviar datos al prefijo 172.16.192.0/18 , se enviarán a los enrutadores de AS1 en la ruta 172.16.0.0/16 . En AS1, se descartará o se devolverá un mensaje ICMP de destino inalcanzable, según la configuración de los enrutadores de AS1.
Si AS1 decide posteriormente eliminar la ruta 172.16.0.0/16 , dejando 172.16.0.0/18 , 172.16.64.0/18 y 172.16.128.0/18 , el número de rutas que AS1 anuncia se reduce a tres . Dependiendo de la política de enrutamiento de AS2, almacenará una copia de las tres rutas, o agregará 172.16.0.0/18 y 172.16.64.0/18 a 172.16.0.0/17 , reduciendo así el número de rutas que AS2 almacena a dos ( 172.16 .0.0 / 17 y 172.16.128.0/18 ) .
Si AS2 ahora quiere enviar datos al prefijo 172.16.192.0/18 , se descartará o se enviará un mensaje ICMP de destino inalcanzable a los enrutadores de AS2 (no a AS1 como antes), porque 172.16.192.0/18 no está en la tabla de enrutamiento.
La especificación RFC 1771 BGP-4 codificó números AS en 16 bits, para 64.510 posibles números AS públicos. [a] En 2011, solo 15.000 números AS todavía estaban disponibles, y las proyecciones [43] 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, [b] lo que ahora permite hasta 4 mil millones de AS disponibles. También se define un rango de AS privado adicional en RFC 6996. [c] Para permitir el recorrido de grupos de enrutadores que no pueden administrar esos nuevos ASN, se utiliza el nuevo atributo AS4_PATH (transitivo opcional). Las asignaciones de ASN de 32 bits comenzaron en 2007.
Otro factor que contribuye al crecimiento de la tabla de enrutamiento es la necesidad de equilibrar la carga de las redes multitarjeta . No es una tarea trivial equilibrar el tráfico entrante a una red multitarjeta 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 de múltiples servidores, si anuncia los mismos bloqueos 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 demás protocolos de enrutamiento, BGP no detecta congestión.
Para solucionar este problema, los administradores BGP de esa red multitarjeta pueden dividir un gran bloque de direcciones IP contiguas en bloques más pequeños y modificar el anuncio de ruta para que diferentes bloques parezcan óptimos en diferentes rutas, de modo que las redes externas elijan una ruta diferente para llegar a diferentes rutas. bloques de esa red multitarjeta. Tales casos aumentarán la cantidad de rutas como se ve en la tabla BGP global.
Un método para abordar el problema de la tabla de enrutamiento asociado con el equilibrio de carga es implementar puertas de enlace del Protocolo de separación de localizador/identificador (BGP/LISP) dentro de un punto de intercambio de Internet para permitir la ingeniería de tráfico de ingreso a través de múltiples enlaces. Esta técnica no aumenta la cantidad de rutas que se ven en la tabla BGP global.
Por diseño, los enrutadores que ejecutan BGP aceptan rutas anunciadas de otros enrutadores BGP de 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 interrupciones accidentales o maliciosas, lo que se conoce como secuestro de BGP . Debido al grado en que BGP está integrado en los sistemas centrales de Internet y a la cantidad de redes diferentes operadas por muchas organizaciones diferentes que colectivamente componen 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. [44]
Las Extensiones multiprotocolo para BGP (MBGP), a veces denominadas BGP multiprotocolo o BGP de multidifusión y definidas en RFC 4760, son una extensión de BGP que permite distribuir en paralelo diferentes tipos de direcciones (conocidas como familias de direcciones). Mientras que el BGP estándar solo admite direcciones de unidifusión IPv4, el BGP multiprotocolo admite direcciones IPv4 e IPv6 y admite variantes de unidifusión y multidifusión de cada una. BGP multiprotocolo permite intercambiar información sobre la topología de los enrutadores con capacidad de multidifusión IP por separado de la topología de los enrutadores de unidifusión IPv4 normales. Por lo tanto, permite una topología de enrutamiento de multidifusión diferente de la topología de enrutamiento de unidifusión. Aunque MBGP permite el intercambio de información de enrutamiento de multidifusión entre dominios, se necesitan otros protocolos, como la familia Protocol Independent Multicast, para crear árboles y reenviar tráfico de multidifusión.
BGP multiprotocolo también se implementa ampliamente en el caso de MPLS L3 VPN, para intercambiar etiquetas VPN aprendidas para las rutas de los sitios del cliente a través de la red MPLS, con el fin de distinguir entre diferentes sitios del cliente cuando el tráfico de los otros sitios del cliente llega al proveedor. enrutador de borde para enrutar.
Otra extensión de BGP es el enrutamiento multiruta . Por lo general, esto requiere MED, peso, origen y ruta AS idénticos, aunque algunas implementaciones brindan la capacidad de relajar la verificación de la ruta AS para esperar solo una longitud de ruta igual en lugar de que también se espere que coincidan los números AS reales en la ruta. Esto luego 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.
BGP4 es un estándar para el enrutamiento de Internet y es un requisito para que la mayoría de los proveedores de servicios de Internet (ISP) establezcan enrutamiento entre sí. Las redes IP privadas muy grandes utilizan BGP internamente. Un caso de uso de ejemplo es la unión de varias redes grandes, Abrir primero la ruta más corta (OSPF) cuando OSPF por sí solo no escala al tamaño requerido. Otra razón para utilizar BGP es la conexión múltiple de una red para obtener una mejor redundancia, ya sea a múltiples puntos de acceso a un único ISP o a múltiples ISP.
Los enrutadores, especialmente los pequeños destinados a uso en pequeñas oficinas/oficinas domésticas (SOHO), pueden no incluir capacidad BGP. Otros enrutadores comerciales pueden necesitar una imagen ejecutable de software específica que admita BGP o una licencia que lo permita. Es menos probable que los dispositivos comercializados como conmutadores de capa 3 admitan BGP que los dispositivos comercializados como enrutadores , pero muchos conmutadores de capa 3 de alta gama pueden ejecutar BGP.
Los productos comercializados como conmutadores pueden tener una limitación de tamaño en las tablas BGP que es mucho más pequeña 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 alguna parte más pequeña de la red, como una confederación-AS que representa una de varias empresas más pequeñas que están conectadas por una red troncal BGP de redes troncales, o una pequeña empresa que anuncia enruta a un ISP pero solo acepta una ruta predeterminada y quizás una pequeña cantidad de rutas agregadas.
Un enrutador BGP utilizado sólo 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 un multihoming simple puede tener un tamaño de tabla de enrutamiento modesto. La cantidad real de memoria requerida en un enrutador BGP depende de la cantidad de información BGP intercambiada con otros altavoces BGP y de la forma en que el enrutador en particular almacena información BGP. Es posible que el enrutador deba conservar más de una copia de una ruta, de modo que pueda administrar diferentes políticas para la publicidad y aceptación de la ruta en un AS vecino específico. El término vista se utiliza a menudo para estas diferentes relaciones de políticas en un enrutador en ejecución.
Si la implementación de un 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 agosto de 2015 [update]supera los 590.000 prefijos. [35] Los grandes ISP pueden añadir otro 50% para rutas internas y de clientes. Nuevamente, dependiendo de la implementación, se pueden mantener tablas separadas para cada vista de un AS par diferente.
Las implementaciones notables gratuitas y de código abierto de BGP incluyen:
Los sistemas para probar la conformidad BGP, el rendimiento de carga o estrés provienen de proveedores como:
Ante la perspectiva de un colapso del sistema, los hombres comenzaron a garabatear ideas para una solución en el dorso de una servilleta manchada de ketchup.
Luego un segundo.
Luego un tercero.
El "protocolo de las tres servilletas", como lo llamaron en broma sus inventores, pronto revolucionaría Internet.
Y aunque había problemas persistentes, los ingenieros vieron su creación como un "truco" o "torpeza", jerga para referirse a una solución a corto plazo que debía ser reemplazada tan pronto como llegara una alternativa mejor.
Mostramos que el diseño de amortiguación actual conduce al comportamiento deseado sólo bajo un aleteo persistente de ruta.
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.