Resolver problemas do Azure Route Server

Este artigo ajuda você a diagnosticar e resolver problemas comuns ao trabalhar com o Azure Route Server. Use as orientações neste artigo para solucionar problemas de conectividade, problemas de plano de controle e problemas operacionais.

Problemas de conectividade

Por que meu dispositivo virtual de rede (NVA) perde a conectividade com a Internet depois de anunciar a rota padrão (0.0.0.0/0) para o servidor de rotas?

Quando o NVA anuncia a rota padrão, o Route Server a programa para todas as máquinas virtuais (VMs) na rede virtual, incluindo o próprio NVA. Essa rota padrão define o NVA como o próximo salto para todo o tráfego ligado à Internet. Se o seu NVA precisar de conectividade com a Internet, você precisará configurar uma rota definida pelo usuário (UDR) para substituir essa rota padrão do NVA e anexar o UDR à sub-rede onde o NVA está hospedado. Caso contrário, a máquina host NVA continua enviando o tráfego ligado à Internet, incluindo o tráfego enviado pelo NVA, de volta para o próprio NVA.

Para obter mais informações, consulte Rotas definidas pelo usuário.

Configuração UDR necessária:

Por que o NVA perde sua conectividade com o Route Server depois de forçar todo o tráfego para um firewall usando uma rota definida pelo usuário (UDR) na GatewaySubnet?

Se quiser inspecionar o tráfego local usando um firewall, você pode forçar todo o tráfego local para o firewall usando uma rota definida pelo usuário (UDR) na GatewaySubnet. No entanto, esse UDR pode interromper a comunicação entre o servidor de rotas e o gateway, forçando seu tráfego de plano de controle (BGP) para o firewall. Esse problema ocorre se você estiver inspecionando o tráfego destinado à rede virtual que tem o servidor de rota.

Para evitar este problema, adicione outra UDR à tabela de rotas da GatewaySubnet para evitar que o tráfego do plano de controle seja forçado a passar pelo firewall (caso não seja desejável ou possível adicionar uma regra BGP ao firewall):

Exemplo de configuração UDR:

Neste exemplo:

• 10.0.0.0/16 é o espaço de endereço da rede virtual
• 10.0.1.0/27 é o espaço de endereço de RouteServerSubnet
• 10.0.2.1 é o endereço IP do firewall

Eu adicionei uma rota definida pelo usuário (UDR) com o tipo de próximo salto como Gateway de Rede Virtual, mas essa UDR não está entrando em vigor. Isso é esperado?

Sim, este é um comportamento esperado. As rotas definidas pelo usuário com o tipo próximo salto Gateway de Rede Virtual não são suportadas para sub-redes dentro da rede virtual do Route Server e redes virtuais emparelhadas. No entanto, se você quiser configurar seu próximo salto para ser um dispositivo virtual de rede (NVA) ou a Internet, você pode adicionar uma rota definida pelo usuário com o próximo salto tipo VirtualAppliance ou Internet.

Nas rotas efetivas da interface de rede da minha VM, por que tenho uma rota definida pelo usuário (UDR) com o tipo de próximo salto definido como Nenhum?

Se você anunciar uma rota do seu NVA para o Route Server que seja uma correspondência de prefixo exata como outra rota definida pelo usuário, o próximo salto da rota anunciada deverá ser válido. Se o próximo salto anunciado for um balanceador de carga sem um pool de back-end configurado, essa rota inválida terá precedência sobre a rota definida pelo usuário. Nas rotas efetivas da interface de rede, a rota anunciada inválida é exibida como uma rota especificada pelo usuário com o tipo de próximo salto definido como Nenhum.

Por que enfrento problemas de conectividade depois de anunciar rotas do Azure de volta ao Azure?

Se você planeja remover as comunidades BGP do Azure da rede virtual e das rotas UDR, não anuncie essas rotas de volta para o Azure, pois isso causa problemas de roteamento. Não recomendamos anunciar rotas do Azure de volta ao Azure.

Por que é que perco a conectividade depois de associar uma política de ponto final de serviço à RouteServerSubnet ou à GatewaySubnet?

Se associar uma política de ponto de extremidade de serviço à RouteServerSubnet ou GatewaySubnet, a comunicação pode ser interrompida entre a plataforma de gestão subjacente do Azure e estes respetivos serviços do Azure (Roteador e gateway de VPN/ExpressRoute). Isso pode fazer com que esses recursos do Azure entrem em um estado não íntegro, resultando em perda de conectividade entre suas cargas de trabalho locais e do Azure.

Por que perco a conectividade depois de usar o DNS personalizado em vez do padrão (DNS fornecido pelo Azure) para a rede virtual do Route Server?

Para a rede virtual na qual o Route Server está implantado, se você não estiver usando o DNS padrão (fornecido pelo Azure), verifique se sua configuração de DNS personalizada pode resolver nomes de domínio público. Isso garante que os serviços do Azure (Servidor de Rotas e gateway VPN/Rota Expressa) possam se comunicar com o plano de gerenciamento subjacente do Azure.

Para mais informações, consulte a nota sobre regras curinga na documentação do Resolvedor Privado de DNS do Azure.

Porque não consigo executar um ping TCP a partir do meu NVA para o IP do par BGP do Servidor de Rotas após configurar o emparelhamento BGP entre eles?

Em alguns NVAs, precisa-se adicionar uma rota estática à sub-rede do servidor de encaminhamento para poder realizar uma verificação de TCP no servidor de encaminhamento a partir do NVA e evitar oscilações de emparelhamento BGP. Por exemplo, se o servidor de rotas estiver em 10.0.255.0/27 e seu NVA estiver em 10.0.1.0/24, você precisará adicionar a seguinte rota à tabela de roteamento no NVA:

Rota estática necessária:

Neste exemplo, 10.0.1.1 é o IP de gateway padrão na sub-rede onde seu NVA (ou, mais precisamente, uma das NICs) está hospedado.

Por que perco a conectividade com minha rede local pela Rota Expressa e/ou VPN do Azure quando estou implantando um Servidor de Rotas em uma rede virtual que já tem gateway de Rota Expressa e/ou gateway de VPN do Azure?

Quando você implanta um Route Server em uma rede virtual, precisamos atualizar o plano de controle entre os gateways e a rede virtual. Durante essa atualização, há um período de tempo em que as VMs na rede virtual perdem a conectividade com a rede local. É altamente recomendável que você agende a manutenção para implantar um Route Server em seu ambiente de produção.

Problemas no plano de controle

Por que minha rede local conectada ao gateway de VPN do Azure não recebe a rota padrão anunciada pelo Servidor de Rotas?

Embora o gateway de VPN do Azure possa receber a rota padrão de seus pares BGP, incluindo o Servidor de Rotas, ele não anuncia a rota padrão para outros pares.

Por que o meu NVA não recebe rotas do Servidor de Rotas, mesmo que o emparelhamento BGP esteja ativo?

O ASN que o servidor de rotas usa é 65515. Certifique-se de configurar um ASN diferente para seu NVA para que uma sessão eBGP possa ser estabelecida entre seu NVA e o Route Server para que a propagação de rota possa acontecer automaticamente. Certifique-se de ativar o multi-hop na configuração do BGP porque o NVA e o Servidor de Rotas estão em sub-redes diferentes na rede virtual.

Por que a conectividade não funciona quando anuncio rotas com um ASN de 0 no AS-Path?

O Azure Route Server descarta rotas com um ASN de 0 no AS-Path. Para garantir que essas rotas sejam anunciadas com êxito no Azure, o AS-Path não deve incluir 0.

O emparelhamento BGP entre meu NVA e o Route Server está ativo. Vejo as rotas trocadas corretamente entre eles. Por que as rotas NVA não estão na tabela de roteamento efetiva da minha VM?

Se a VM estiver na mesma rede virtual que o NVA e o Servidor de Rota:

O Route Server expõe dois IPs de mesmo nível BGP, que compartilham a responsabilidade de enviar as rotas para todas as outras VMs em execução em sua rede virtual. Cada NVA deve configurar duas sessões BGP idênticas (por exemplo, usar o mesmo número AS, o mesmo caminho AS e anunciar o mesmo conjunto de rotas) para os dois IPs de mesmo nível BGP para que suas VMs na rede virtual possam obter informações de roteamento consistentes do Servidor de Rotas do Azure.

Se tiver duas ou mais instâncias do NVA, poderá anunciar caminhos AS diferentes para a mesma rota, de diferentes instâncias NVA, se quiser designar uma instância NVA como ativa e outra como passiva.

Se sua VM estiver em uma rede virtual diferente daquela que hospeda seu NVA e o Servidor de Rota:

Verifique se o emparelhamento de rede virtual está habilitado entre as duas redes virtuais e se Usar Servidor de Rota Remota está habilitado na rede virtual da sua VM.

Por que a função ECMP (Equal-Cost Multi-Path) da minha Rota Expressa está desativada depois que implanto o Route Server na rede virtual?

Quando você anuncia as mesmas rotas de sua rede local para o Azure por meio de várias conexões de Rota Expressa, normalmente o ECMP é habilitado por padrão para o tráfego destinado a essas rotas do Azure de volta à sua rede local. Atualmente, quando implementa o Servidor de Rotas, as informações de múltiplos caminhos são perdidas na troca de BGP entre o ExpressRoute e o Servidor de Rotas e, consequentemente, o tráfego do Azure percorre apenas uma das ligações ExpressRoute.

Questões operacionais

Por que estou vendo um erro sobre escopo inválido e autorização para executar operações do Route Server?

Se vir um erro no seguinte formato, certifique-se de que tem as seguintes permissões configuradas: Funções e permissões do Route Server.

Formato da mensagem de erro: "O cliente com id {} de objeto não tem autorização para executar ações {} sobre o escopo {} ou o escopo é inválido. Se o acesso tiver sido concedido recentemente, atualize as credenciais.”

Próximo passo

Para saber como criar e configurar o Azure Route Server, consulte: