Perguntas Frequentes sobre AWS (FAQs)

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

Como posso configurar 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 o hardware VPN como backup para sua conexão Direct Connect:

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

Importante

Certifique-se de que Direct Connect é a rota preferida do seu lado, e não a VPN, quando a interface virtual Direct Connect estiver ativa para evitar roteamento assimétrico; isso pode causar a perda de tráfego. Preferimos sempre uma conexão Direct Connect em vez de rotas VPN. Para obter mais informações sobre prioridade de rotas e opções de roteamento, consulte o tópico da AWS Prioridade de Rotas.

Aviso

Se você quiser uma solução de curto prazo ou de menor custo, considere configurar uma VPN de hardware como uma opção de failover para uma conexão Direct Connect. 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. Certifique-se de que seu caso de uso ou aplicativo possa tolerar uma largura de banda menor ao configurar uma VPN como backup para uma conexão Direct Connect..

Como habilitar BFD para uso com Direct Connect?

Detecção de Encaminho Bidirecional (Bidirectional Forwarding Detection - BFD) é um protocolo de detecção de falhas de rede que fornece tempos rápidos de detecção de falhas, o que facilita um tempo de convergência mais rápido para protocolos de roteamento dinâmico. Ele é independente de mídia, protocolo de roteamento e dados. Recomendamos habilitar o BFD ao configurar múltiplas conexões AWS Direct Connect ou ao configurar uma única conexão AWS Direct Connect e uma conexão VPN como backup para garantir rápida detecção e failover. Você pode configurar o BFD para detectar falhas de link ou caminho e atualizar o roteamento dinâmico à medida que o Direct Connect encerra rapidamente o peering BGP, de modo que as rotas de backup possam entrar em ação. Isso garante que a relação de vizinhança do BGP seja rapidamente desfeita, em vez de esperar que três keep-alives falhem em um tempo de retenção de 90 segundos.

Resolução

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

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

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

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

Ao usar AWS Direct Connect para transportar cargas de trabalho de produção para a AWS e da AWS, é recomendado usar dois circuitos virtuais Direct Connect, seja a partir de uma única Porta, um par de conexões físicas de Porta (discretas ou LAG/LACP) em um único data center ou distribuídas entre múltiplos locais de data centers.

Você pode configurar o seguinte:

Dois roteadores para terminar as conexões DX primária e secundária para evitar um único ponto de falha de dispositivo.
Uma interface virtual privada em cada um dos roteadores DX que terminam na mesma VPC. Protocolos de roteamento de alta disponibilidade (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 execute um protocolo de roteamento interno como iBGP, que aprenderá rotas do Direct Connect EBGP e distribuirá prefixos para gateways internos iBGP.
Ativo/Passivo (failover). Uma conexão lida com o tráfego, e a outra fica em espera. Se a conexão ativa se tornar indisponível, todo o tráfego será roteado pela conexão passiva. Você precisará adicionar (prepend) o caminho AS nas rotas de um dos seus links para que ele seja o link passivo. Para mais informações, veja Configurar Conexões Redundantes com AWS Direct Connect..

O atributo de preferência local identifica um ponto de saída preferido do sistema autônomo local (AS). Se houver múltiplos pontos de saída do AS, o atributo de preferência local seleciona o ponto de saída para uma rota específica.

Influenciando o tráfego de saída da AWS usando a preparação (prepend) do caminho AS

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

O roteador secundário anunciará um caminho AS mais longo, de modo que o tráfego da VPC para sua rede será sempre através do roteador primário.

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

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

Resolução

Se o estado da interface virtual pública estiver no estado verificando por mais de 72 horas, verifique o endereço de e-mail registrado na sua conta AWS. Você pode ter recebido um e-mail da equipe AWS Direct Connect se o proprietário do ASN BGP ou de uma das 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 para enviar um e-mail para directconnect-requests@amazon.com afirmando que autoriza a aprovação dos prefixos IP públicos para a interface virtual pública dxvif-xxx.

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

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

O status da sua interface virtual pode estar inativo devido a problemas de configuração com a OSIOpen systems interconnection.
Um modelo que caracteriza e padroniza as funções de comunicação de um sistema de telecomunicações ou computação. A maioria dos produtos Megaport são Camada 2, com alguns dos construtos OSI avançando para a Camada 3, onde as informações de endereçamento IP são trocadas, conhecido como um serviço L2/L3. ou Border Gateway Protocol (BGP).

Configuração da Camada 2 OSI

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

ocê configurou o ID de VLAN correto com encapsulamento dot1Q em seu dispositivo (como um roteador ou switch). O ID de VLAN aparece na guia Informações do Portal como o serviço de terminação A para o seu VXC.
A configuração do endereço IP de peer é idêntica em seu dispositivo, através do Portal, e no console AWS Direct Connect.
Todos os dispositivos intermediários estão configurados para marcação de VLAN com o ID de VLAN apropriado, e o tráfego marcado com VLAN é preservado no ponto de extremidade AWS Direct Connect.
Seu dispositivo está aprendendo o endereço de controle de acesso de mídia (MAC) do ponto de extremidade AWS Direct Connect para o ID de VLAN configurado na tabela do Protocolo de Resolução de Endereço (Address Resolution Protocol - ARP).
Seu dispositivo pode pingar o IP do peer da Amazon a partir do seu IP de peer

Configuração BGP

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

O ASN local e o ASN remoto conforme fornecido na guia Informações do Portal como serviço de terminação A 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 a entrada ou saída da porta TCP 179 (BGP) e outras portas efêmeras apropriadas.
Seu dispositivo não está anunciando mais de 100 prefixos para 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 ativo.