Solucionar problemas do Azure Route Server
Saiba como solucionar alguns dos problemas comuns do Azure Route Server.
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 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 enviado pelo NVA de volta para o próprio NVA. Para obter mais informações, consulte Rotas definidas pelo usuário.
| Rota | Próximo salto |
|---|---|
| 0.0.0.0/0 | Internet |
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 (uma tabela de rotas associada à GatewaySubnet que tem a UDR). 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 esse problema, você precisa adicionar outro UDR à tabela de rotas GatewaySubnet para excluir o tráfego do plano de controle de ser forçado ao firewall (caso a adição de uma regra BGP ao firewall não seja desejada/possível):
| Rota | Próximo salto |
|---|---|
| 10.0.0.0/16 | 10.0.2.1 |
| 10.0.1.0/27 | VirtualNetwork |
10.0.0.0/16 é o espaço de endereço da rede virtual e 10.0.1.0/27 é o espaço de endereço de RouteServerSubnet. 10.0.2.1 é o endereço IP do firewall.
Por que não consigo fazer ping TCP do meu NVA para o IP de peer BGP do Servidor de Rotas depois de configurar o emparelhamento BGP entre eles?
Em alguns NVAs, você precisa adicionar uma rota estática à sub-rede do Servidor de Rotas para poder executar ping TCP no Servidor de Rotas a partir do NVA e evitar o batimento 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 | Próximo salto |
|---|---|
| 10.0.255.0/27 | 10.0.1.1 |
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 meu NVA não recebe rotas do Route Server 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 da rota possa acontecer automaticamente. Certifique-se de ativar "multi-hop" em sua configuração BGP porque seu NVA e o Route Server estão em sub-redes diferentes na rede virtual.
O emparelhamento BGP entre meu NVA e o Route Server está ativo. Vejo 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 são hospedados em duas VMs 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 as duas VMs 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 do NVA, poderá anunciar caminhos AS diferentes para a mesma rota de instâncias NVA diferentes se quiser designar uma instância NVA como ativa e a outra 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 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 em 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 você implanta o Servidor de Rota, as informações de vários caminhos são perdidas na troca de BGP entre a Rota Expressa e o Servidor de Rotas e, consequentemente, o tráfego do Azure atravessará apenas uma das conexões da Rota Expressa.
Próximo passo
Para saber como criar e configurar o Azure Route Server, consulte: