Compartilhar via


Verificar conectividade do ExpressRoute

Este artigo ajuda você a verificar e solucionar problemas de conectividade do Azure ExpressRoute. O ExpressRoute estende uma rede local até o Microsoft Cloud por uma conexão privada normalmente é facilitada por um provedor de conectividade. A conectividade do ExpressRoute tradicionalmente envolve três zonas de rede distintas:

  • Rede de cliente
  • Rede do provedor
  • Datacenter da Microsoft

Observação

No modelo de conectividade do ExpressRoute Direct você pode se conectar diretamente à porta dos roteadores do Microsoft Enterprise Edge (MSEE). O modelo de conectividade direta inclui apenas as suas zonas de rede e as da Microsoft.

Este artigo ajuda você a identificar se e onde existe um problema de conectividade. Depois, você pode buscar suporte da equipe apropriada para resolver o problema.

Importante

Este artigo busca ajudar você a diagnosticar e corrigir problemas simples. Ele não substitui o suporte da Microsoft. Se você não conseguir resolver um problema seguindo as diretrizes neste artigo, abra um tíquete de suporte no Suporte da Microsoft.

Visão geral

O diagrama a seguir mostra a conectividade lógica de uma rede do cliente com a rede da Microsoft usando o ExpressRoute. 1

No diagrama anterior, os números indicam os principais pontos de rede:

  1. Dispositivo de computação do cliente (por exemplo, um servidor ou um computador).
  2. CEs (roteadores de borda do cliente).
  3. PEs (roteadores/comutadores de borda do provedor) voltados aos roteadores de borda do cliente.
  4. PEs voltados aos roteadores do ExpressRoute do MSEE (Microsoft Enterprise Edge). Neste artigo eles se chamam PE-MSEEs.
  5. MSEEs.
  6. Gateway de rede virtual.
  7. Dispositivo de computação na rede virtual do Azure.

Às vezes, este artigo faz referência a esses pontos de rede pelo número associado.

Dependendo do modelo de conectividade do ExpressRoute, os pontos de rede 3 e 4 podem ser comutadores (dispositivos da camada 2) ou roteadores (dispositivos da camada 3). Os modelos de conectividade do ExpressRoute são colocação de troca de nuvem, conexão Ethernet ponto a ponto ou qualquer para qualquer (IPVPN).

No modelo de conectividade direta, não existem os pontos de rede 3 e 4. Nesse caso, os CEs (2) são conectados diretamente aos MSEEs por meio de fibra óptica escura.

Se o modelo de colocação de troca de nuvem, de Ethernet ponto a ponto ou de conectividade direta for usado, os CEs (2) estabelecerão o emparelhamento Border Gateway Protocol (BGP) com os MSEEs (5).

Se for usado o modelo de conectividade IPVPN (qualquer para qualquer), os PE-MSEEs (4) estabelecerão o emparelhamento BGP com os MSEEs (5). Os PE-MSEEs propagam as rotas recebidas da Microsoft de volta para a rede do cliente por meio da rede do provedor de serviços IP VPN.

Observação

Para oferecer alta disponibilidade, a Microsoft estabelece uma conectividade paralela totalmente redundante entre os pares de MSEEs (5) e PE-MSEEs (4). Um caminho de rede paralelo totalmente redundante entre a rede do cliente e o par de PE/CEs também é recomendado. Para obter mais informações sobre alta disponibilidade, confira o artigo Como projetar visando a alta disponibilidade com o ExpressRoute.

As seções a seguir representam as etapas lógicas para a solução de problemas no circuito do ExpressRoute.

Verificar o estado e o provisionamento do circuito

O provisionamento de um circuito do ExpressRoute estabelece uma conexão de camada 2 redundante entre os CEs/PE-MSEEs (2/4) e os MSEEs (5). Para obter mais informações sobre como criar, modificar, provisionar e verificar um circuito do ExpressRoute, consulte o artigo Create and modify an ExpressRoute circuit (Criar e modificar um circuito do ExpressRoute).

Dica

Uma chave de serviço identifica exclusivamente um circuito do ExpressRoute. Caso você precise de assistência da Microsoft ou de um parceiro do ExpressRoute para solucionar problemas do ExpressRoute, forneça a chave de serviço para identificar prontamente o circuito.

Verificação por meio do Portal do Azure

No portal do Azure, abra a página do circuito do ExpressRoute. A seção 3 da página lista as informações gerais do ExpressRoute como nesta captura de tela:

4

Nas informações gerais do ExpressRoute, o Status do circuito indica o status do circuito no lado da Microsoft. Status do provedor indica se o circuito foi provisionado ou não no lado do provedor de serviços.

Para que um circuito do ExpressRoute esteja operacional, o Status do circuito deve ser Habilitado e o Status do provedor deve ser Provisionado.

Observação

Depois de configurar um circuito do ExpressRoute, se o Status do circuito estiver paralisado em Não habilitado, entre em contato com o Suporte da Microsoft. Se o Status do provedor estiver paralisado no status Não provisionado, entre em contato com o provedor de serviços.

Verificação por meio do PowerShell

Para listar todos os circuitos do ExpressRoute em um grupo de recursos, use o seguinte comando:

Get-AzExpressRouteCircuit -ResourceGroupName "Test-ER-RG"

Dica

Se você estiver procurando o nome de um grupo de recursos, liste todos os grupos de recursos da assinatura usando o comando Get-AzResourceGroup.

Para selecionar um circuito do ExpressRoute específico em um grupo de recursos, use o seguinte comando:

Get-AzExpressRouteCircuit -ResourceGroupName "Test-ER-RG" -Name "Test-ER-Ckt"

Eis uma resposta de exemplo:

Name                             : Test-ER-Ckt
ResourceGroupName                : Test-ER-RG
Location                         : westus2
Id                               : /subscriptions/***************************/resourceGroups/Test-ER-RG/providers/***********/expressRouteCircuits/Test-ER-Ckt
Etag                             : W/"################################"
ProvisioningState                : Succeeded
Sku                              : {
                                    "Name": "Standard_UnlimitedData",
                                    "Tier": "Standard",
                                    "Family": "UnlimitedData"
                                   }
CircuitProvisioningState         : Enabled
ServiceProviderProvisioningState : Provisioned
ServiceProviderNotes             :
ServiceProviderProperties        : {
                                    "ServiceProviderName": "****",
                                    "PeeringLocation": "******",
                                    "BandwidthInMbps": 100
                                   }
ServiceKey                       : **************************************
Peerings                         : []
Authorizations                   : []

Para confirmar se um circuito do ExpressRoute está operacional, preste atenção aos seguintes campos:

CircuitProvisioningState         : Enabled
ServiceProviderProvisioningState : Provisioned

Observação

Depois de configurar um circuito do ExpressRoute, se o Status do circuito estiver paralisado em Não habilitado, entre em contato com o Suporte da Microsoft. Se o Status do provedor estiver paralisado no status Não provisionado, entre em contato com o provedor de serviços.

Validar a configuração de emparelhamento

Depois que o provedor de serviços tiver concluído o provisionamento do circuito do ExpressRoute, várias configurações de roteamento poderão ser criadas com base no eBGP (BGP externo) no circuito do ExpressRoute entre os CEs/MSEE-PEs (2/4) e os MSEEs (5). Cada circuito do ExpressRoute pode ter uma das seguintes configurações de emparelhamento, ou ambas:

  • Emparelhamento privado do Azure: tráfego para redes virtuais privadas no Azure
  • Emparelhamento da Microsoft: tráfego para pontos de extremidade públicos de PaaS (plataforma como serviço) e SaaS (software como serviço)

Para obter mais informações sobre como criar e modificar a configuração de roteamento, consulte o artigo Create and modify routing for an ExpressRoute circuit (Criar e modificar o roteamento para um circuito do ExpressRoute).

Verificação por meio do Portal do Azure

Observação

Em um modelo de conectividade IPVPN, os provedores de serviços lidam com a responsabilidade de configurar os emparelhamentos (serviços da camada 3). Nesse modelo, depois que o provedor de serviços configurar um emparelhamento, se o emparelhamento ficar em branco no portal, atualize a configuração do circuito com o botão Atualizar no portal. Essa operação efetuará pull da configuração de roteamento atual do circuito.

No portal do Azure, você pode verificar o status de um circuito do ExpressRoute na página desse circuito. A seção 3 da página lista os emparelhamentos do ExpressRoute como nesta captura de tela:

5

No exemplo anterior, o emparelhamento privado do Azure é provisionado, mas os emparelhamentos públicos do Azure e da Microsoft não são. Um contexto de emparelhamento provisionado com êxito também teria as sub-redes primárias e secundárias ponto a ponto listadas. As sub-redes /30 são usadas para o endereço IP da interface dos MSEEs e dos CEs/PE-MSEEs. Nos emparelhamentos que são provisionados, a listagem também indica quem modificou a configuração pela última vez.

Observação

Se a habilitação de um emparelhamento falhar, verifique se as sub-redes primária e secundárias atribuídas correspondem à configuração no CE/PE-MSEE vinculado. Verifique também se os valores corretos de VlanId, AzureASN e PeerASN estão sendo usados nos MSEEs e se esses valores estão mapeados para os usados no CE/PE-MSEE vinculado.

Se o hash MD5 for escolhido, a chave compartilhada deverá ser a mesma nos pares MSEE e CE/PE-MSEE. As chaves compartilhadas já configuradas não são exibidas por motivos de segurança.

Caso você precise alterar uma dessas configurações em um roteador do MSEE, confira Criar e modificar o roteamento de um circuito do ExpressRoute.

Observação

Em uma sub-rede /30 atribuída à interface, a Microsoft escolherá o segundo endereço IP utilizável da sub-rede da interface do MSEE. Portanto, verifique se o primeiro endereço IP utilizável da sub-rede foi atribuído no CE/PE-MSEE emparelhado.

Verificação por meio do PowerShell

Para obter os detalhes de configuração do emparelhamento privado do Azure, use os seguintes comandos:

$ckt = Get-AzExpressRouteCircuit -ResourceGroupName "Test-ER-RG" -Name "Test-ER-Ckt"
Get-AzExpressRouteCircuitPeeringConfig -Name "AzurePrivatePeering" -ExpressRouteCircuit $ckt

Veja uma resposta de exemplo de um emparelhamento privado configurado:

Name                       : AzurePrivatePeering
Id                         : /subscriptions/***************************/resourceGroups/Test-ER-RG/providers/***********/expressRouteCircuits/Test-ER-Ckt/peerings/AzurePrivatePeering
Etag                       : W/"################################"
PeeringType                : AzurePrivatePeering
AzureASN                   : 12076
PeerASN                    : 123##
PrimaryPeerAddressPrefix   : 172.16.0.0/30
SecondaryPeerAddressPrefix : 172.16.0.4/30
PrimaryAzurePort           :
SecondaryAzurePort         :
SharedKey                  :
VlanId                     : 200
MicrosoftPeeringConfig     : null
ProvisioningState          : Succeeded

Um contexto de emparelhamento habilitado com êxito teria os prefixos dos endereços primário e secundário listados. As sub-redes /30 são usadas para o endereço IP da interface dos MSEEs e dos CEs/PE-MSEEs.

Para obter os detalhes de configuração do emparelhamento da Microsoft, use os seguintes comandos:

$ckt = Get-AzExpressRouteCircuit -ResourceGroupName "Test-ER-RG" -Name "Test-ER-Ckt"
Get-AzExpressRouteCircuitPeeringConfig -Name "MicrosoftPeering" -ExpressRouteCircuit $ckt

Se o emparelhamento não estiver configurado, você receberá uma mensagem de erro. Aqui está um exemplo de resposta quando o emparelhamento declarado não está configurado no circuito:

Get-AzExpressRouteCircuitPeeringConfig : Sequence contains no matching element
At line:1 char:1
    + Get-AzExpressRouteCircuitPeeringConfig -Name "MicrosoftPeering ...
    + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        + CategoryInfo          : CloseError: (:) [Get-AzExpr...itPeeringConfig], InvalidOperationException
        + FullyQualifiedErrorId : Microsoft.Azure.Commands.Network.GetAzureExpressRouteCircuitPeeringConfigCommand

Observação

Se a habilitação de um emparelhamento falhar, verifique se as sub-redes primária e secundárias atribuídas correspondem à configuração no CE/PE-MSEE vinculado. Verifique também se os valores corretos de VlanId, AzureASN e PeerASN estão sendo usados nos MSEEs e se esses valores estão mapeados para os usados no CE/PE-MSEE vinculado.

Se o hash MD5 for escolhido, a chave compartilhada deverá ser a mesma nos pares MSEE e CE/PE-MSEE. As chaves compartilhadas já configuradas não são exibidas por motivos de segurança.

Caso você precise alterar uma dessas configurações em um roteador do MSEE, confira Criar e modificar o roteamento de um circuito do ExpressRoute.

Observação

Em uma sub-rede /30 atribuída para a interface, a Microsoft escolherá o segundo endereço IP utilizável da sub-rede para a interface MSEE. Portanto, verifique se o primeiro endereço IP utilizável da sub-rede foi atribuído no CE/PE-MSEE emparelhado.

Validar ARP

A tabela do protocolo ARP fornece um mapeamento do endereço IP e do endereço MAC de um emparelhamento específico. A tabela ARP para um emparelhamento de circuito de ExpressRoute fornece as seguintes informações para cada interface (primária e secundária):

  • Mapeamento do endereço IP da interface do roteador local para o endereço MAC
  • Mapeamento do endereço IP da interface do roteador do ExpressRoute para o endereço MAC (opcional)
  • Idade do mapeamento

As tabelas ARP podem ajudar a validar a configuração da camada 2 e a solucionar problemas básicos de conectividade da camada 2.

Observação

Dependendo da plataforma de hardware, os resultados do ARP podem variar e exibir apenas a interface Local.

Para saber como exibir a tabela ARP de um emparelhamento do ExpressRoute e como usar as informações para solucionar problemas de conectividade da camada 2, confira Como obter as tabelas ARP no modelo de implantação do Resource Manager.

Validar BGP e rotas no MSEE

Para colocar a tabela de roteamento do MSEE no caminho primário do contexto de roteamento privado, use o seguinte comando:

Get-AzExpressRouteCircuitRouteTable -DevicePath Primary -ExpressRouteCircuitName ******* -PeeringType AzurePrivatePeering -ResourceGroupName ****

Eis uma resposta de exemplo:

Network : 10.1.0.0/16
NextHop : 10.17.17.141
LocPrf  :
Weight  : 0
Path    : 65515

Network : 10.1.0.0/16
NextHop : 10.17.17.140*
LocPrf  :
Weight  : 0
Path    : 65515

Network : 10.2.20.0/25
NextHop : 172.16.0.1
LocPrf  :
Weight  : 0
Path    : 123##

Observação

Se o estado de um emparelhamento eBGP entre um MSEE e um CE/PE-MSEE for Ativo ou Ocioso, verifique se as sub-redes pares primária e secundárias atribuídas correspondem à configuração no CE/PE-MSEE vinculado. Verifique também se os valores corretos de VlanId, AzureASN e PeerASN estão sendo usados nos MSEEs e se esses valores estão mapeados para os usados no CE/PE-MSEE vinculado. Se o hash MD5 for escolhido, a chave compartilhada deverá ser a mesma nos pares MSEE e CE/PE-MSEE. Caso você precise alterar uma dessas configurações em um roteador do MSEE, confira Criar e modificar o roteamento de um circuito do ExpressRoute.

Observação

Se determinados destinos não estiverem acessíveis por meio de um emparelhamento, verifique a tabela de rotas dos MSEEs para o contexto de emparelhamento correspondente. Se um prefixo correspondente (pode ser o IP NATed) estiver presente na tabela de roteamento, verifique se firewalls, grupos de segurança de rede ou ACLs (listas de controle de acesso) no caminho estão bloqueando o tráfego.

O exemplo a seguir mostra a resposta do comando para um emparelhamento que não existe:

Get-AzExpressRouteCircuitRouteTable : The BGP Peering AzurePublicPeering with Service Key ********************* is not found.
StatusCode: 400

Confirmar o fluxo de tráfego

Para obter as estatísticas de tráfego combinadas dos caminhos primário e secundário (bytes de entrada e de saída) de um contexto de emparelhamento, use o seguinte comando:

Get-AzExpressRouteCircuitStats -ResourceGroupName $RG -ExpressRouteCircuitName $CircuitName -PeeringType 'AzurePrivatePeering'

Veja um exemplo da saída do comando:

PrimaryBytesIn PrimaryBytesOut SecondaryBytesIn SecondaryBytesOut
-------------- --------------- ---------------- -----------------
     240780020       239863857        240565035         239628474

Veja um exemplo de saída do comando para um emparelhamento inexistente:

Get-AzExpressRouteCircuitRouteTable : The BGP Peering AzurePublicPeering with Service Key ********************* is not found.
StatusCode: 400

Teste de conectividade de emparelhamento do privado

Teste a conectividade do emparelhamento privado contando os pacotes que chegam e saem da borda da Microsoft do circuito do ExpressRoute, nos dispositivos do MSEE. Essa ferramenta de diagnóstico funciona aplicando uma ACL ao MSEE para contar o número de pacotes que atendem a regras específicas da ACL. O uso dessa ferramenta permite que você confirme a conectividade respondendo a perguntas como:

  • Meus pacotes estão chegando ao Azure?
  • Eles estão voltando ao ambiente local?

Executar um teste

  1. Para acessar a ferramenta de diagnóstico, selecione Diagnosticar e resolver problemas do circuito do ExpressRoute no portal do Azure.

    Captura de tela do botão para diagnosticar e resolver problemas do circuito do ExpressRoute.

  2. SelecioneConectividade e Problemas de desempenho.

    Captura de tela da opção para problemas de conectividade.

  3. Na lista suspensa Conte-nos mais sobre o problema que você está enfrentando, selecione Problemas com Emparelhamento privado.

    Captura de tela da opção suspensa para o problema que o usuário está enfrentando.

  4. Role para baixo até a seção Testar sua conectividade de emparelhamento privado e expanda-a.

    Captura de tela das opções para solucionar problemas de conectividade, com a opção de emparelhamento privado realçada.

  5. Execute o teste PsPing do endereço IP local para o endereço IP do Azure e mantenha-o em execução durante o teste de conectividade.

  6. Preencha os campos do formulário. Insira os mesmos endereços IP locais e do Azure usados na etapa 5. Depois, selecione Enviar e aguarde o carregamento dos resultados.

    Captura de tela do formulário para depurar uma ACL.

Interpretar os resultados

Quando os resultados estiverem prontos, eles estarão divididos em dois grupos: dispositivos MSEE primários e secundários. Examine o número de correspondências de entrada e saída e interprete os resultados de acordo com os seguintes cenários:

  • Você vê as correspondências de pacotes enviados e recebidos nos dois MSEEs: isso indica um tráfego íntegro de entrada e saída do MSEE no circuito. Se a perda estiver ocorrendo localmente ou no Azure, ela estará a downstream do MSEE.

  • Se você estiver tentando o PsPing do local para o Azure, os resultados recebidos mostrarem as correspondências, mas os resultados enviados não mostrarem nenhuma correspondência: isso indicará que o tráfego está chegando ao Azure, mas não está retornando ao local. Verifique se há problemas de roteamento de caminho de retorno. Por exemplo, você está apontando os prefixos apropriados para o Azure? Uma UDR (rota definida pelo usuário) está substituindo os prefixos?

  • Se você estiver testando o PsPing do Azure para o local, os resultados enviados mostrarem correspondências, mas os resultados recebidos não mostrarem correspondências: esse resultado indica que o tráfego está chegando ao local, mas não está retornando ao Azure. Trabalhe com seu provedor para descobrir por que o tráfego não está sendo encaminhado ao Azure por meio do circuito ExpressRoute.

  • Um MSEE não mostra nenhuma correspondência, mas o outro mostra boas correspondências: isso indica que um MSEE não está recebendo nem passando tráfego. Ele pode estar offline (por exemplo, o BGP/ARP está inativo).

    • Você pode executar testes adicionais para confirmar o caminho não íntegro anunciando uma rota local /32 exclusiva durante a sessão BGP nesse caminho.
    • Execute "Testar sua conectividade de emparelhamento privado" usando o /32 exclusivo anunciado como o endereço de destino local e examine os resultados para confirmar a integridade do caminho.

Os resultados do teste de cada dispositivo MSEE se parecem com o seguinte exemplo:

src 10.0.0.0 dst 20.0.0.0 dstport 3389 (received): 120 matches
src 20.0.0.0 srcport 3389 dst 10.0.0.0 (sent): 120 matches

Este resultado de teste tem as seguintes propriedades:

  • Porta IP: 3389
  • CIDR do endereço IP local: 10.0.0.0
  • CIDR do endereço IP do Azure: 20.0.0.0

Verificar a disponibilidade do gateway de rede virtual

O gateway de rede virtual ExpressRoute facilita o gerenciamento e a conectividade do painel de controle com os serviços de link privado e IPs privados implantados em uma rede virtual do Azure. A Microsoft gerencia a infraestrutura de gateway de rede virtual e, às vezes, executa manutenção.

Durante um período de manutenção, o desempenho do gateway de rede virtual pode ser reduzido. Para solucionar problemas de conectividade com a rede virtual e ver se um evento de manutenção recente causou redução da capacidade, siga estas etapas:

  1. Selecione Diagnosticar e resolver problemas do circuito ExpressRoute no portal do Azure.

    Captura de tela do botão para diagnosticar e resolver problema de um circuito do ExpressRoute.

  2. Selecione a opção Problemas de Desempenho.

    Captura de tela da seleção da opção para problemas de desempenho.

  3. Aguarde a execução do diagnóstico e interprete os resultados.

    Captura de tela dos resultados do diagnóstico.

    Se a manutenção foi feita no gateway de rede virtual durante um período em que você teve perda ou latência de pacotes. É possível que a capacidade reduzida do gateway tenha contribuído para os problemas de conectividade que você está enfrentando para a rede virtual de destino. Siga as etapas recomendadas. Para dar suporte a uma taxa de transferência de rede mais alta e evitar problemas de conectividade durante os próximos eventos de manutenção, considere atualizar o SKU do gateway de rede virtual.

Próximas etapas

Para obter mais informações ou ajuda, confira os seguintes links: