Solucionar problemas do Servidor de Rota do Azure

Este artigo ajuda você a diagnosticar e resolver problemas comuns ao trabalhar com o Servidor de Rota do Azure. Use as diretrizes neste artigo para solucionar problemas de conectividade, problemas de plano de controle e preocupações operacionais.

Problemas de conectividade

Por que minha NVA (solução de virtualização de rede) perde a conectividade com a Internet depois de anunciar a rota padrão (0.0.0.0/0) para o Servidor de Rota?

Quando a NVA anuncia a rota padrão, o Servidor de Rota a programa para todas as VMs (máquinas virtuais) na rede virtual, incluindo a própria NVA. Essa rota padrão define a NVA como o próximo salto para todo o tráfego associado à Internet. Se a sua NVA precisar de conectividade com a Internet, você precisará configurar uma UDR (rota definida pelo usuário) para substituir essa rota padrão da NVA e anexar a UDR à sub-rede na qual a NVA está hospedada. Caso contrário, o computador host NVA continuará enviando o tráfego associado à Internet, incluindo o tráfego enviado pela NVA, de volta para a própria NVA.

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

Configuração de UDR necessária:

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

Se você quiser inspecionar o tráfego local usando um firewall, poderá forçar todo o tráfego local para o firewall usando uma UDR (rota definida pelo usuário) no GatewaySubnet. No entanto, essa UDR pode interromper a comunicação entre o Servidor de Rota e o gateway ao forçar o tráfego do plano de controle (BGP) para o firewall. Esse problema ocorrerá se você estiver inspecionando o tráfego destinado à rede virtual que tem o Servidor de Rota.

Para evitar esse problema, adicione outra UDR à tabela de rotas GatewaySubnet para excluir que o tráfego do painel de controle seja forçado ao firewall (caso a adição de uma regra BGP ao firewall não seja desejada ou possível):

Exemplo de configuração de 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

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

Sim, esse comportamento é esperado. Não há suporte para as rotas definidas pelo usuário com o tipo de próximo salto Gateway de Rede Virtual para sub-redes na rede virtual do Servidor de Rota e redes virtuais emparelhadas. No entanto, se você quiser configurar seu próximo salto para ser uma NVA (solução de virtualização de rede) ou internet, poderá adicionar uma rota definida pelo usuário com o tipo de próximo salto 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 Servidor de Rota que seja uma correspondência exata de prefixo com 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 como inválida é exibida como uma rota definida 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 para o Azure?

Se você planeja remover comunidades BGP do Azure da rede virtual e 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 para o Azure.

Por que perco a conectividade depois de associar uma política de endpoint de serviço à sub-rede RouteServer ou à sub-rede Gateway?

Se você associar uma política de ponto de extremidade de serviço a RouteServerSubnet ou GatewaySubnet, a comunicação poderá ser interrompida entre a plataforma de gerenciamento subjacente do Azure e esses respectivos serviços do Azure (Servidor de Rota e gateway de VPN/do ExpressRoute). Isso pode fazer com que esses recursos do Azure entrem em um estado problemático, resultando em perda de conectividade entre suas cargas de trabalho locais e as do Azure.

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

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

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

Por que não posso executar ping TCP da minha NVA para o IP do par no nível de protocolo BGP no Servidor de Rota depois de configurar o emparelhamento via protocolo BGP entre eles?

Em algumas NVAs, você precisa adicionar uma rota estática à sub-rede do Servidor de Rota para poder executar ping TCP no Servidor de Rota da NVA e evitar oscilações de emparelhamento via protocolo BGP. Por exemplo, se o Servidor de Rota 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 em que sua NVA (ou mais precisamente, uma das NICs) está hospedada.

Por que eu perco a conectividade com minha rede local por meio do ExpressRoute e/ou da VPN do Azure quando estou implantando o Servidor de Rota em uma rede virtual que já tem o gateway do ExpressRoute e/ou de VPN do Azure?

Quando você implanta o Servidor de Rota 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 em que as VMs na rede virtual perdem a conectividade com a rede local. É altamente recomendável que você agende manutenção para implantar o Servidor de Rota no seu ambiente de produção.

Problemas de painel 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 Rota?

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

Por que minha NVA não recebe rotas do Servidor de Rota, embora o emparelhamento via protocolo BGP esteja ativo?

O ASN que o Servidor de Rota usa é 65515. Configure um ASN diferente para sua NVA para que uma sessão eBGP possa ser estabelecida entre o NVA e o Servidor de Rota para que a propagação de rota possa ocorrer automaticamente. Certifique-se de habilitar o multi-hop na configuração do BGP, porque seu NVA e o Servidor de Rota estão em sub-redes diferentes na rede virtual.

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

O Servidor de Rota do Azure 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 via protocolo BGP entre minha NVA e o Servidor de Rota está ativo. Posso ver 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 Servidor de Rota expõe dois IPs de par no nível de protocolo BGP, que compartilham a responsabilidade de enviar as rotas para todas as outras VMs em execução na 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 par BGP para que suas VMs na rede virtual possam obter informações de roteamento consistentes do Servidor de Rotas do Azure.

Se você tiver duas ou mais instâncias da NVA, poderá anunciar diferentes caminhos de sistema autônomo para a mesma rota de diferentes instâncias de NVA se quiser designar uma instância de NVA como ativa e outra passiva.

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

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

Por que o ECMP (roteamento de vários caminhos de custo igual) do meu ExpressRoute é desligado depois que eu implanto o Servidor de Rota na rede virtual?

Quando você anuncia as mesmas rotas da sua rede local para o Azure em várias conexões do ExpressRoute, normalmente o ECMP é habilitado por padrão para o tráfego destinado a essas rotas do Azure de volta para a sua rede local. Atualmente, quando você implanta o Servidor de Rota, as informações de vários caminhos são perdidas na troca de BGP entre o ExpressRoute e o Servidor de Rota e, consequentemente, o tráfego do Azure passa apenas em uma das conexões do ExpressRoute.

Problemas operacionais

Por que vejo um erro sobre escopo e autorização inválidos para executar operações do Servidor de Rota?

Se você vir um erro no seguinte formato, verifique se você tem as seguintes permissões configuradas: Funções e permissões do Servidor de Rota.

Formato da mensagem de erro: "O cliente com id {} de objeto não tem autorização para executar a ação {} por escopo {} ou o escopo é inválido. Se o acesso foi concedido recentemente, atualize suas credenciais."

Próxima etapa

Para saber como criar e configurar o Servidor de Rota do Azure, confira: