¿Cómo puedo influir en la ruta del tráfico de red de conexión de Direct Connect dirigido a las instalaciones locales a través de varios circuitos?

Última actualización: 11/01/2022

Quiero influir en la ruta del tráfico de red de conexión de AWS Direct Connect dirigido a las instalaciones locales a través de varios circuitos.

Descripción corta

Puede utilizar varios circuitos de Direct Connect en diferentes regiones de AWS para aumentar el ancho de banda y lograr una alta disponibilidad. Según la distribución de los circuitos en las regiones, puede influir en el tráfico de Direct Connect al anunciar etiquetas de comunidad de protocolo de puerta de enlace fronteriza (BGP) con prefijos locales.

Las configuraciones comunes para varias conexiones de Direct Connect incluyen:

  • Interfaces virtuales privadas creadas en las conexiones Direct Connect adjuntas a las mismas puertas de enlace privadas virtuales (VGW) en la misma región.
  • Interfaces virtuales privadas creadas en las conexiones de Direct Connect adjuntas a la misma puerta de enlace de Direct Connect (DXGW) y asociadas a varias VGW en cualquier región.
  • Interfaces virtuales de tránsito creadas en las conexiones de Direct Connect adjuntas a la misma DXGW y asociadas a varias puertas de enlace de tránsito en cualquier región.

Resolución

Siga estas instrucciones para influir en la ruta de tráfico de la red de conexión de Direct Connect en función de su caso de uso.

Comportamiento predeterminado para interfaces virtuales privadas y de tránsito y cómo influir en él

Para influir en el comportamiento predeterminado, se recomienda utilizar la anteposición de ruta del Sistema autónomo (AS) y las siguientes etiquetas de comunidad de BGP de preferencia local:

  • 7224:7100 – Preferencia baja
  • 7224:7200 – Preferencia media
  • 7224:7300 – Preferencia alta

Las etiquetas de comunidad de BGP de preferencia local se evalúan en orden desde la preferencia más baja hasta la más alta (donde se prefiere la más alta). Para cada prefijo que publique en una sesión de BGP, puede aplicar una etiqueta de comunidad a fin de indicar la prioridad de la ruta asociada para el tráfico de retorno.

Para más información, consulte ¿Cómo puedo utilizar las comunidades de BGP para influir en la ruta de enrutamiento preferida de los enlaces de Direct Connect desde AWS a mi red?

Situación 1

Tiene una conexión de Direct Connect (DX1) en la región us-east-1 y una segunda conexión (DX2) en la región eu-west-1. Se crea una interfaz virtual privada (VIF) en DX1 y DX2 con los mismos prefijos anunciados desde los dispositivos locales. Las VIF DX1 y DX2 se adjuntan a una DXGW asociada a tres VGW en las regiones us-east-1, eu-west-1 y ap-southeast-1.

Si anuncia la etiqueta BGP 7224:7300 a través de la VIF en DX1, el tráfico de Amazon Virtual Private Cloud (Amazon VPC) de la región us-east-1 no cambia. El tráfico de las regiones eu-west-1 y ap-southeast-1 prefiere DX1 porque la comunidad de BGP sobrescribe la misma preferencia de región.

Si anuncia la etiqueta BGP 7224:7300 a través de la VIF en DX1 y DX2, el tráfico de todas las Amazon VPC en diferentes regiones tiene equilibrio de carga en DX1 y DX2. Esto se debe a que la comunidad de BGP sobrescribe la misma preferencia de región.

Si anuncia la etiqueta BGP 7224:7300 a través de ambas VIF con AS antepuesto en DX1, el tráfico de todas las Amazon VPC en todas las regiones prefiere DX2. Esto se debe a que las preferencias de región se sobrescriben como iguales. A continuación, AWS realiza la validación de la longitud de la ruta de AS y descubre que el prefijo de ruta para DX2 es más corto que el de DX1.

Si solo anuncia un AS antepuesto en la VIF en DX1 sin etiquetas de comunidad de BGP, el tráfico de las Amazon VPC en las regiones us-east-1 y eu-west-1 permanece sin cambios. El tráfico de la región ap-southeast-1 prefiere DX2. Esto se debe a que la preferencia de región tiene una prioridad más alta que la longitud de la ruta AS.

Situación 2

Tiene conexiones Direct Connect DX1 y DX2 en la región us-east-1 con interfaces virtuales privadas que utilizan el mismo prefijo anunciado desde los dispositivos locales. Las interfaces virtuales privadas están adjuntas a la DXGW asociada a tres VGW en las regiones us-east-1 y eu-west-1.

Si anuncia la etiqueta BGP 7224:7300 a través de la VIF en DX1, el tráfico de las regiones us-east-1 y eu-west-1 prefiere DX1 porque la comunidad BGP sobrescribe la misma preferencia de región.

Si anuncia la etiqueta BGP 7224:7300 a través de ambas VIF en DX1 y DX2, el tráfico de las VPC en diferentes regiones permanece sin cambios. Esto se debe a que la etiqueta de comunidad de BGP sobrescribe la preferencia de región para el balanceador de carga.

Si anuncia la etiqueta BGP 7224:7300 a través de ambas VIF con AS antepuesto en DX1, el tráfico de las Amazon VPC en todas las regiones prefiere DX2. Esto se debe a que la preferencia de región se sobrescribe como igual. A continuación, AWS realiza la validación de la longitud de la ruta de AS y descubre que el prefijo de ruta para DX2 es más corto que el de DX1.

Si anuncia un AS antepuesto en la VIF en DX1 sin etiquetas de comunidad de BGP, el tráfico de las Amazon VPC en las regiones us-east-1 y eu-west-1 prefiere DX2. Esto se debe a que las regiones us-east-1 y eu-west-1 tienen la misma preferencia de región y una ruta AS más corta para DX2.

Escenario 1 y escenario 2

Si anuncia prefijos locales sin factores influyentes, el comportamiento de salida de tráfico predeterminado es el siguiente:

  • El tráfico procedente de Amazon VPC en la región us-east-1 se prefiere para DX1 porque se encuentra en la misma región. El tráfico procedente de Amazon VPC en la región eu-west-1 se prefiere para DX2 porque se encuentra en la misma región. Como ap-southeast-1 es una región remota, el tráfico procedente de la Amazon VPC tiene un equilibrio de carga en DX1 y DX2.
  • El tráfico procedente de Amazon VPC en la región us-east-1 tiene equilibrio de carga en DX1 y DX2 porque se encuentran en la misma región. El tráfico procedente de Amazon VPC en la región eu-west-1 tiene equilibrio de carga en DX1 y DX2.

Comportamiento predeterminado de las interfaces virtuales públicas y cómo influir en él

En el siguiente escenario, tiene dos conexiones de Direct Connect en la misma región que utilizan la misma interfaz virtual pública y el mismo prefijo anunciados desde dispositivos locales.

El tráfico de salida desde la dirección de AWS se equilibra en la carga en las VIF públicas sin factores influyentes. Para influir en el comportamiento predeterminado, se recomienda utilizar un sistema autónomo (AS) antepuesto a un ASN público. Si solo puede usar un ASN privado, se recomienda anunciar prefijos más específicos de la VIF pública preferida, de modo que la coincidencia de prefijo más larga determine la ruta de enrutamiento.

Escenarios de enrutamiento asimétrico comunes para interfaces virtuales públicas

Puede usar los siguientes prefijos de BGP con Direct Connect:

  • 7224:9100 —Región local de AWS
  • 7224:9200 —Todas las regiones de AWS de un continente
  • 7224:9300 —Global (todas las regiones públicas de AWS)

Para obtener más información, consulte el ámbito de las comunidades de BGP.

En el siguiente escenario, tiene una conexión de Direct Connect en la región us-east-1 con una interfaz virtual pública. Está anunciando el mismo prefijo público local con la etiqueta de comunidad 7224:9100 a través de la conexión de Direct Connect y el proveedor local de servicios de Internet.

Si accede a un bucket de Amazon Simple Storage Service (Amazon S3) en la región us-east-1, el tráfico entrante y saliente se realiza a través de la conexión de Direct Connect.

Si accede a un bucket de Amazon S3 en la región eu-west-1, el tráfico entrante se realiza a través de la conexión de Direct Connect y el tráfico saliente a través del proveedor local de servicios de Internet. Esto se debe a que el prefijo no se propaga a la región eu-west-1, lo que provoca un enrutamiento asimétrico.

Si accede a un bucket de Amazon S3 en la región us-east-1 y el tráfico entrante que proviene de las instalaciones locales usa el proveedor local de servicios de Internet, se produce un enrutamiento asimétrico. Esto se debe a que AWS prefiere enviar tráfico saliente a través de la conexión de Direct Connect en lugar del proveedor local de servicios de Internet cuando se reciben los mismos prefijos.


¿Le resultó útil este artículo?


¿Necesita asistencia técnica o con la facturación?