Como posso influenciar meu caminho de tráfego de rede de conexão do Direct Connect para on-premises em vários circuitos?

Breve descrição

Você pode usar vários circuitos do Direct Connect em diferentes regiões da AWS para aumentar a largura de banda e a alta disponibilidade. Dependendo da distribuição dos circuitos entre as regiões, é possível influenciar o tráfego do Direct Connect anunciando tags de comunidade do protocolo BGP com prefixos on-premises.

As configurações comuns para várias conexões do Direct Connect incluem:

• Interfaces virtuais privadas criadas nas conexões do Direct Connect conectadas aos mesmos gateways privados virtuais (VGW) na mesma região.
• Interfaces virtuais privadas criadas nas conexões do Direct Connect conectadas ao mesmo Direct Connect Gateway (DXGW) e associadas a vários VGWs em qualquer região.
• Interfaces virtuais de trânsito criadas nas conexões do Direct Connect conectadas ao mesmo DXGW e associadas a vários gateways de trânsito em qualquer região.

Resolução

Siga estas instruções para influenciar o caminho de tráfego de rede da conexão do Direct Connect com base no seu caso de uso.

Comportamento padrão para interfaces virtuais privadas e de trânsito e como influenciá-lo

Para influenciar o comportamento padrão, é prática recomendada usar o caminho precedente do Sistema Autônomo (AS) e as seguintes tags de comunidade BGP de preferência local:

• 7224:7100 – Preferência baixa
• 7224:7200 – Preferência média
• 7224:7300 – Preferência alta

As tags da comunidade BGP de preferência local são avaliadas em ordem, da preferência mais baixa para a mais alta (em que a preferência mais alta é preferida). Para cada prefixo que você anuncia em uma sessão BGP, você pode aplicar uma tag de comunidade para indicar a prioridade do caminho associado para retornar o tráfego.

Para obter mais informações, consulte Como posso usar as comunidades BGP para influenciar o caminho de roteamento preferencial nos links do Direct Connect da AWS para minha rede?

Cenário 1

Você tem uma conexão do Direct Connect (DX1) na região us-east-1 e uma segunda conexão (DX2) na região eu-west-1. Uma interface virtual privada (VIF) é criada em DX1 e DX2 com os mesmos prefixos anunciados nos dispositivos on-premises. As VIFs de DX1 e DX2 são conectadas com um DXGW associado a três VGWs nas regiões us-east-1, eu-west-1 e ap-southeast-1.

Se você anunciar tags BGP 7224:7300 na VIF em DX1, o tráfego da Amazon Virtual Private Cloud (Amazon VPC) da região us-east-1 permanece inalterado. O tráfego das regiões eu-west-1 e ap-southeast-1 prefere DX1 porque a mesma preferência de região é substituída pela comunidade BGP.

Se você anunciar tags BGP 7224:7300 nas VIFs em DX1 e DX2, a carga do tráfego de todas as Amazon VPCs em diferentes regiões é balanceada entre DX1 e DX2. Isso ocorre porque a mesma preferência de região é substituída pela comunidade BGP.

Se você anunciar tags BGP 7224:7300 em ambas as VIFs com AS precedente em DX1, o tráfego de todas as Amazon VPCs em todas as regiões preferirá DX2. Isso ocorre porque as preferências da região são substituídas como iguais. Em seguida, a AWS executa a validação no comprimento do caminho AS, descobrindo que o prefixo do caminho para DX2 é menor que DX1.

Se você anunciar apenas um AS precedente em VIF em DX1 sem tags de comunidade BGP, o tráfego das Amazon VPCs nas regiões us-east-1 e eu-west-1 permanecerá inalterado. O tráfego da região ap-southeast-1 prefere DX2. Isso ocorre porque a preferência de região tem uma prioridade mais alta do que o comprimento do caminho AS.

Cenário 2

Você tem conexões DX1 e DX2 do Direct Connect na região us-east-1 com interfaces virtuais privadas usando o mesmo prefixo anunciado em dispositivos on-premises. As interfaces virtuais privadas são anexadas ao DXGW associado a três VGWs nas regiões us-east-1 e eu-west-1.

Se você anunciar tags BGP 7224:7300 na VIF em DX1, o tráfego das regiões us-east-1 e eu-west-1 preferirá DX1 porque a mesma preferência de região será substituída pela comunidade BGP.

Se você anunciar tags BGP 7224:7300 em ambas as VIFs em DX1 e DX2, o tráfego de VPCs em diferentes regiões permanecerá inalterado. Isso ocorre porque a preferência de região é substituída pela tag da comunidade BGP para balanceamento de carga.

Se você anunciar tags BGP 7224:7300 em ambas as VIFs com AS precedente em DX1, o tráfego das Amazon VPCs em todas as regiões preferirá DX2. Isso ocorre porque a preferência de região é substituída como igual. Em seguida, a AWS executa a validação no comprimento do caminho AS, descobrindo que o prefixo do caminho para DX2 é menor que DX1.

Se você anunciar apenas um AS precedente na VIF em DX1 sem tags de comunidade BGP, o tráfego das Amazon VPCs nas regiões us-east-1 e eu-west-1 preferirá DX2. Isso ocorre porque as regiões us-east-1 e eu-west-1 têm a mesma preferência de região e um caminho AS mais curto para DX2.

Cenário 1 e Cenário 2

Se você anunciar prefixos locais sem fatores de influência, o comportamento padrão de saída de tráfego será o seguinte:

• O tráfego originado da Amazon VPC na região us-east-1 será preferido para DX1 porque está na mesma região. O tráfego proveniente da Amazon VPC na região eu-west-1 será preferido para DX2 porque está na mesma região. Como ap-southeast-1 é uma região remota, a carga do tráfego originado da Amazon VPC será balanceada entre DX1 e DX2.
• A carga do tráfego originado da Amazon VPC na região us-east-1 será balanceada entre DX1 e DX2 porque estão na mesma região. A carga do tráfego proveniente da Amazon VPC na região eu-west-1 tem balanceamento de carga entre X1 e DX2.

Comportamento padrão para interfaces virtuais públicas e como influenciá-lo

No cenário a seguir, você tem duas conexões do Direct Connect na mesma região que usam a mesma interface virtual pública e o mesmo prefixo anunciado em dispositivos locais.

A carga do tráfego de saída da direção da AWS é balanceada entre VIFs públicas sem fatores de influência. Para influenciar o comportamento padrão, recomenda-se usar o Sistema Autônomo (AS) precedente com um ASN público. Se você só puder usar um ASN privado, recomenda-se anunciar prefixos mais específicos da VIF pública preferencial para que a correspondência de prefixo mais longa determine o caminho de roteamento.

Cenários comuns de roteamento assimétrico para interfaces virtuais públicas

Você pode usar os seguintes prefixos BGP com o Direct Connect:

• 7224:9100 – Região local da AWS
• 7224:9200 – Todas as regiões da AWS para um continente
• 7224:9300 – Global (todas as regiões da AWS públicas)

Para obter mais informações, consulte as comunidades BGP do escopo.

No cenário a seguir, você tem uma conexão do Direct Connect na região us-east-1 com uma interface virtual pública. Você está anunciando o mesmo prefixo público on-premises com a tag de comunidade 7224:9100 na conexão do Direct Connect e no provedor local de serviços de Internet.

Se você estiver acessando um bucket do Amazon Simple Storage Service (Amazon S3) na região us-east-1, o tráfego de entrada e saída será feito pela conexão do Direct Connect.

Se você estiver acessando um bucket do Amazon S3 na região eu-west-1, o tráfego de entrada será feito pela conexão do Direct Connect e o tráfego de saída pelo provedor local de serviços de Internet. Isso ocorre porque o prefixo não é propagado para a região eu-west-1, causando roteamento assimétrico.

Se você estiver acessando um bucket do Amazon S3 na região us-east-1 e o tráfego de entrada on-premises estiver usando o provedor local de serviços de Internet, haverá um roteamento assimétrico. Isso ocorre porque a AWS prefere enviar tráfego de saída pela conexão do Direct Connect em vez do provedor local de serviços de Internet quando os mesmos prefixos são recebidos.

Informações relacionadas

Configurar conexões redundantes com o AWS Direct Connect

Como configuro uma conexão ativa/ativa ou ativa/passiva do Direct Connect para a AWS a partir de uma interface virtual pública? 

Tipos de interfaces virtuais do AWS Direct Connect

---