Perguntas Frequentes da AWS (FAQs)

Clique em qualquer uma das FAQs na navegação à direita para sugestões e resolução.

Como posso configurar uma VPN como backup para minha conexão Direct Connect?

Quero configurar uma conexão VPN de backup para failover com minha conexão AWS Direct Connect. Alguma recomendação e melhores práticas?

Resolução

Para configurar a VPN por hardware como backup para sua conexão Direct Connect:

Certifique-se de usar o mesmo gateway privado virtual (gateway privado virtual) tanto para o Direct Connect quanto para a conexão VPN com a VPC.
Se você estiver configurando uma VPN com BGP, anuncie o mesmo prefixo para o Direct Connect e para a VPN.
Se você estiver configurando uma VPN estática, adicione os mesmos prefixos estáticos à conexão VPN que você está anunciando com a interface virtual do Direct Connect.
Se você estiver anunciando as mesmas rotas para a VPC da AWS, o caminho pelo Direct Connect sempre será preferido, independentemente de AS path prepending.

Importante

Certifique-se de que o Direct Connect seja a rota preferida do seu lado, e não a VPN, quando a interface virtual do Direct Connect estiver ativa, para evitar roteamento assimétrico; isso pode fazer com que o tráfego seja descartado. Sempre preferimos uma conexão Direct Connect em vez de rotas de VPN. Para informações sobre prioridade de rota e opções de roteamento, consulte o tópico da AWS Route Priority.

Nota

Se você quiser uma solução de curto prazo ou de menor custo, considere configurar uma VPN por hardware como opção de failover para uma conexão Direct Connect. As conexões VPN não são projetadas para fornecer o mesmo nível de largura de banda disponível para a maioria das conexões Direct Connect. Garanta que seu caso de uso ou aplicação tolere uma largura de banda menor se você estiver configurando uma VPN como backup para uma conexão Direct Connect.

Como habilitar BFD para uso com o Direct Connect?

A Detecção de Encaminhamento Bidirecional (BFD) é um protocolo de detecção de falhas de rede que detecta quaisquer falhas de caminho entre vizinhos BGP diretamente conectados. O BFD fornece tempos rápidos de detecção de falhas, o que facilita um tempo de reconvergência mais rápido para protocolos de roteamento dinâmico, como o BGP. É independente de mídia, protocolo de roteamento e dados.

Recomendamos habilitar BFD ao configurar várias conexões AWS Direct Connect ou ao configurar uma conexão AWS Direct Connect única e uma conexão VPN como backup para garantir detecção e failover rápidos. O BFD detecta falhas de link ou caminho e atualiza o roteamento dinâmico à medida que o Direct Connect encerra rapidamente o peering BGP para que as rotas de backup possam entrar em ação. Isso garante que a relação de vizinhança BGP seja rapidamente derrubada em vez de esperar por 3 keep-alives falharem em um hold-down de 90 segundos.

Resolução

O intervalo do BFD especifica com que frequência enviamos pacotes BFD, o min_rx indica com que frequência um roteador espera receber os pacotes e o multiplier define quantos podemos perder antes que a relação de vizinhança BGP seja considerada down.

O BFD assíncrono é habilitado automaticamente para cada interface virtual do Direct Connect no lado da AWS, mas não entra em vigor até que esteja configurado no seu roteador. O padrão do Direct Connect define o intervalo mínimo de detecção de vivacidade do BFD em 300 milissegundos e o multiplicador de detecção de vivacidade do BFD em 3.

Antes de usar o modo de eco do BFD no seu dispositivo de rede, você deve desabilitar o envio de mensagens Internet Control Message Protocol (ICMP) e de redirecionamento com o comando no ip redirect para evitar alta utilização de CPU.

Como configurar uma conexão Direct Connect Ativa/Passiva?

Ao usar AWS Direct Connect para transportar cargas de trabalho de produção de e para a AWS, recomenda-se usar Circuitos Virtuais do Direct Connect duplos, seja a partir de uma única Port, de um par de conexões físicas de Port (discretas ou LAG/LACP) em um único DC, ou distribuídos em vários locais de DC.

Você pode configurar o seguinte:

Dois roteadores para encerrar as conexões DX primária e secundária, evitando um ponto único de falha de dispositivo.
Uma interface virtual privada em cada um dos roteadores DX que terminam na mesma VPC. Protocolos de roteamento HA (como HSRP, VRRF, GLBP, etc.) em dois roteadores para permitir que servidores locais usem vários roteadores que atuam como um único roteador virtual, mantendo a conectividade mesmo se o roteador primário falhar, pois o roteador secundário assumirá e se tornará ativo, ou executar um protocolo de roteamento interno como iBGP que aprenderá rotas do EBGP do Direct Connect e distribuirá prefixos para gateways iBGP internos.
Ativa/Passiva (failover). Uma conexão está tratando o tráfego e a outra está em standby. Se a conexão ativa ficar indisponível, todo o tráfego será roteado pela conexão passiva. Você precisará fazer AS path prepend nas rotas de um dos seus links para que ele seja o link passivo. Para mais informações, consulte Configure Redundant Connections with AWS Direct Connect.

O atributo local preference identifica um ponto de saída preferido do sistema autônomo (AS) local. Se houver vários pontos de saída do AS, o atributo local preference seleciona o ponto de saída para uma rota específica.

Influenciando o tráfego de saída da AWS usando AS Path prepending

O algoritmo Best Path do BGP decide como é selecionado o melhor caminho para um sistema autônomo. Um valor comum para determinar o melhor caminho é o comprimento do AS Path. Quando existem duas ou mais rotas para alcançar um prefixo, o padrão no BGP é preferir a rota com o AS path mais curto.

O roteador secundário anunciará um AS path mais longo, de modo que o tráfego da VPC para sua rede sempre passará pelo roteador primário.

Minha interface virtual pública está presa no estado “verifying”. O que posso fazer?

Quando você cria uma interface virtual pública e especifica os endereços IP de peer públicos, isso requer aprovação da equipe AWS Direct Connect (VIFs/VXCs privadas não exigem essa autorização e ficam disponíveis em minutos). Antes de aprovar prefixos de IP públicos ou ASNs públicos, a equipe do AWS Direct Connect precisa verificar a propriedade dos prefixos de IP públicos e do ASN BGP. A equipe do AWS Direct Connect verifica a propriedade confirmando que o registro regional pertence ao nome da organização listado na sua conta da AWS.

Resolução

Se o estado da interface virtual pública estiver em verifying por mais de 72 horas, verifique o endereço de e-mail registrado na sua conta da AWS. Você pode ter recebido um e-mail da equipe do AWS Direct Connect se o proprietário do ASN BGP ou uma de suas rotas anunciadas não corresponder aos detalhes da sua conta.

Se o ASN BGP ou uma rota anunciada não corresponder à sua conta, você pode:

Pedir ao proprietário do endereço IP que envie um e-mail para directconnect-requests@amazon.com informando que autoriza a aprovação dos prefixos de IP públicos para a interface virtual pública dxvif-xxx.

—ou—
Pedir ao proprietário do endereço IP que envie uma carta de autorização em papel timbrado da empresa ou que envie um e-mail autorizando o uso do prefixo de IP público para a interface virtual pública dxvif-xxx com a sua conta da AWS. Em seguida, acesse a conta proprietária da interface virtual pública do Direct Connect, abra um caso e anexe a carta de autorização ao seu caso.

O status BGP da interface virtual está down no console da AWS. O que devo fazer?

O status da sua interface virtual pode estar down devido a problemas de configuração com a OSIA Interconexão de Sistemas Abertos (OSI) é um modelo que caracteriza e padroniza as funções de comunicação de um sistema de telecomunicações ou de computação. A maioria dos produtos Megaport é de Camada 2 (ou L2), com alguns dos conceitos do OSI avançando para a Camada 3 (L3), onde são trocadas informações de endereçamento IP, o que é conhecido como um serviço L2/L3.
Camada 2 ou Border Gateway Protocol (BGP)Border Gateway Protocol (BGP) é um protocolo de roteamento padronizado projetado para trocar informações de rotas e de alcançabilidade entre sistemas autônomos (AS) na internet.
.

Configuração da Camada 2 do OSI

Primeiro, verifique se sua camada 2 do OSI está configurada corretamente. Verifique os seguintes detalhes:

Você configurou o VLAN ID correto com encapsulamento dot1Q no seu dispositivo (como um roteador ou switch). O VLAN ID aparece na guia Informações do Portal como o serviço A-End do seu VXC.
A configuração do endereço IP de peer é idêntica no seu dispositivo, pelo Portal, e no console do AWS Direct Connect.
Quaisquer dispositivos intermediários estão configurados para VLAN tagging com o VLAN ID apropriado, e o tráfego com marcação de VLAN é preservado no endpoint do AWS Direct Connect.
Seu dispositivo está aprendendo o endereço de media access control (MAC) do endpoint do AWS Direct Connect para o VLAN ID configurado a partir da tabela Address Resolution Protocol (ARP).
Seu dispositivo consegue dar ping no IP de peer da Amazon usando como origem seu IP de peer.

Configuração de BGP

Se os resultados do teste da camada 2 do OSI forem positivos, confirme a configuração de BGP no seu dispositivo. Verifique o seguinte:

O ASN local e o ASN remoto conforme fornecidos na guia Informações do Portal como serviço A-End para o seu VXC.
O endereço IP do vizinho e a senha MD5 do BGP conforme fornecidos na guia Informações do Portal como serviço A-End para o seu VXC.
Seu dispositivo não está bloqueando entrada ou saída na porta TCP 179 (BGP) e outras portas efêmeras apropriadas.
Seu dispositivo não está anunciando mais de 100 prefixos para a AWS via BGP. Por padrão, a AWS aceita apenas até 100 prefixos usando uma sessão BGP no AWS Direct Connect.

Depois de confirmar essas configurações, o status BGP da sua interface virtual deve estar up.