Verificar conectividade do ExpressRoute
Este artigo ajuda você a verificar e solucionar problemas de conectividade do Azure ExpressRoute. O ExpressRoute estende uma rede local para o Microsoft Cloud por meio de uma conexão privada facilitada por um provedor de conectividade. A conectividade do ExpressRoute 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). Esse modelo inclui apenas sua rede e as zonas de rede da Microsoft.
Este artigo ajuda você a identificar problemas de conectividade e a buscar suporte da equipe apropriada para resolvê-los.
Importante
Este artigo busca ajudar você a diagnosticar e corrigir problemas simples. Não é uma substituição para o suporte da Microsoft. Se você não conseguir resolver um problema usando essas diretrizes, abra um tíquete de suporte com o 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.
No diagrama, os números indicam os principais pontos de rede:
- Dispositivo de computação do cliente (por exemplo, um servidor ou um computador).
- CEs (roteadores de borda do cliente).
- Roteadores/comutadores de borda do provedor (PEs) voltados para roteadores de borda do cliente.
- PEs voltados para MSEEs (roteadores do Microsoft Enterprise Edge ExpressRoute), chamados PE-MSEEs.
- MSEEs.
- Gateway de rede virtual.
- Dispositivo de computação na rede virtual do Azure.
Esses pontos de rede são referenciados pelo número associado ao longo do artigo.
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 são colocação de troca de nuvem, conexão Ethernet ponto a ponto ou IPVPN (qualquer para qualquer).
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 alta disponibilidade, a Microsoft estabelece conectividade paralela totalmente redundante entre pares MSEE e PE-MSEE. 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, consulte Projetando para 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 Criar e modificar um circuito do ExpressRoute.
Dica
Uma chave de serviço identifica exclusivamente um circuito do ExpressRoute. Se você precisar de assistência da Microsoft ou de um parceiro do ExpressRoute para solucionar um problema, forneça a chave de serviço para identificar prontamente o circuito.
Verificação por meio do Portal do Azure
No portal do Azure, navegue até a página do circuito do ExpressRoute. A seção 
da página lista as informações gerais do ExpressRoute como nesta captura de tela:
Nos itens essenciais do ExpressRoute, o Status do circuito indica o status do circuito no lado da Microsoft e o Status do provedor indica se o circuito foi provisionado pelo 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
Se o Status do circuito estiver travado em Não habilitado, entre em contato com o Suporte da Microsoft. Se o Status do provedor estiver preso em Não provisionado, entre em contato com seu 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
Para localizar o nome de um grupo de recursos, use o Get-AzResourceGroup comando para listar todos os grupos de recursos em sua assinatura.
Para obter detalhes de um circuito específico do ExpressRoute 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, verifique se os seguintes campos estão definidos corretamente:
CircuitProvisioningState : Enabled
ServiceProviderProvisioningState : Provisioned
Observação
Se o Status do circuito estiver travado em Não habilitado, entre em contato com o Suporte da Microsoft. Se o Status do provedor estiver preso em Não provisionado, entre em contato com seu provedor de serviços.
Validar configuração de emparelhamento
Depois que o provedor de serviços provisionar o circuito do ExpressRoute, você poderá criar várias configurações de roteamento usando BGP externo (eBGP) no circuito entre CEs/MSEE-PEs (2/4) e MSEEs (5). Cada circuito do ExpressRoute pode ter uma das seguintes configurações de emparelhamento, ou ambas:
- Emparelhamento privado do Azure: para tráfego para redes virtuais privadas no Azure
- Emparelhamento da Microsoft: para 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 configurações de roteamento, consulte 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). Se o emparelhamento estiver em branco no portal depois que o provedor de serviços o tiver configurado, tente atualizar a configuração do circuito usando 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 em sua página. A seção lista os emparelhamentos do ExpressRoute, conforme mostrado na seguinte captura de tela:
No exemplo anterior, o emparelhamento privado do Azure é provisionado, mas os emparelhamentos públicos e da Microsoft do Azure não são. Um contexto de emparelhamento provisionado com êxito também listará as sub-redes ponto a ponto primárias e secundárias. As sub-redes /30 são usadas para os endereços IP da interface dos MSEEs e CEs/PE-MSEEs. 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. Além disso, verifique se os valores VlanId, AzureASN e PeerASN nos MSEEs correspondem àqueles no CE/PE-MSEE vinculado.
Se o hash MD5 for escolhido, verifique se a chave compartilhada é a mesma em pares MSEE e CE/PE-MSEE. As chaves compartilhadas configuradas anteriormente não serã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 usará o segundo endereço IP utilizável para a interface MSEE. Verifique se o primeiro endereço IP utilizável está atribuído ao 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 lista os prefixos de endereço primário e secundário. As sub-redes /30 são usadas para os endereços IP da interface dos MSEEs e 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. Além disso, verifique se os valores VlanId, AzureASN e PeerASN nos MSEEs correspondem àqueles no CE/PE-MSEE vinculado.
Se o hash MD5 for escolhido, verifique se a chave compartilhada é a mesma em pares MSEE e CE/PE-MSEE. As chaves compartilhadas configuradas anteriormente não serã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 usará o segundo endereço IP utilizável para a interface MSEE. Verifique se o primeiro endereço IP utilizável está atribuído ao 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 recuperar a tabela de roteamento do MSEE no caminho primário para o contexto de roteamento privado, use o seguinte comando:
Get-AzExpressRouteCircuitRouteTable -DevicePath Primary -ExpressRouteCircuitName <CircuitName> -PeeringType AzurePrivatePeering -ResourceGroupName <ResourceGroupName>
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 emparelhamento eBGP entre um MSEE e um CE/PE-MSEE estiver Ativo ou Ocioso, verifique se as sub-redes par primárias e secundárias correspondem à configuração no CE/PE-MSEE vinculado. Verifique se os valores VlanId, AzureASN e PeerASN estão corretos nos MSEEs e correspondam aos do CE/PE-MSEE vinculado. Se o hash MD5 for usado, a chave compartilhada deverá ser a mesma em pares MSEE e CE/PE-MSEE. Para obter alterações de configuração em um roteador MSEE, consulte Criar e modificar o roteamento para um circuito do ExpressRoute.
Observação
Se determinados destinos estiverem inacessíveis em um emparelhamento, verifique a tabela de rotas MSEE para o contexto de emparelhamento correspondente. Se um prefixo correspondente estiver presente, verifique se nenhum firewall, grupos de segurança de rede ou ACLs estão bloqueando o tráfego.
Exemplo de resposta para um emparelhamento inexistente:
Get-AzExpressRouteCircuitRouteTable : The BGP Peering AzurePublicPeering with Service Key <ServiceKey> is not found.
StatusCode: 400
Confirmar o fluxo de tráfego
Para obter estatísticas de tráfego (bytes de entrada e saída) para um contexto de emparelhamento, use o seguinte comando:
Get-AzExpressRouteCircuitStats -ResourceGroupName <ResourceGroupName> -ExpressRouteCircuitName <CircuitName> -PeeringType 'AzurePrivatePeering'
Exemplo de saída:
PrimaryBytesIn PrimaryBytesOut SecondaryBytesIn SecondaryBytesOut
-------------- --------------- ---------------- -----------------
240780020 239863857 240565035 239628474
Saída de exemplo para um emparelhamento inexistente:
Get-AzExpressRouteCircuitRouteTable : The BGP Peering AzurePublicPeering with Service Key <ServiceKey> is not found.
StatusCode: 400
Teste de conectividade de emparelhamento do privado
Teste a conectividade de emparelhamento privado contando os pacotes que chegam e saem da borda da Microsoft do circuito do ExpressRoute nos dispositivos MSEE. Essa ferramenta de diagnóstico usa uma ACL para contar pacotes que atingem regras específicas, confirmando a conectividade.
Executar um teste
No portal do Azure, selecione Diagnosticar e resolver problemas no circuito do ExpressRoute.
SelecioneConectividade e Problemas de desempenho.
Na lista suspensa Diga-nos mais sobre o problema que você está enfrentando, selecione Problemas com o Emparelhamento privado.
Expanda a seção Testar conectividade de emparelhamento privado.
Execute o teste PsPing do SEU IP local para o IP do Azure e mantenha-o em execução durante o teste.
Preencha os campos de formulário com os mesmos endereços IP usados na etapa 5 e selecione Enviar e aguardar os resultados.
Interpretar os resultados
Examine os resultados dos dispositivos MSEE primários e secundários:
Correspondências enviadas e recebidas em ambos os MSEEs: indica tráfego íntegro de entrada e saída. Qualquer perda é downstream dos MSEEs.
Correspondências recebidas, mas sem correspondências enviadas: o tráfego está chegando ao Azure, mas não retornando. Verifique os problemas de roteamento de caminho de retorno.
Correspondências enviadas, mas sem correspondências recebidas: o tráfego está atingindo o local, mas não retornando ao Azure. Trabalhe com seu provedor para resolver.
Um MSEE não mostra correspondências, o outro mostra boas correspondências: indica que um MSEE não está recebendo ou passando tráfego. Pode estar offline.
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
Verificar a disponibilidade do gateway de rede virtual
O gateway de rede virtual do ExpressRoute gerencia a conectividade com serviços de link privado e IPs privados em uma rede virtual do Azure. A Microsoft gerencia essa infraestrutura e pode executar a manutenção, reduzindo o desempenho.
Para solucionar problemas de conectividade e verificar se há manutenção recente:
No portal do Azure, selecione Diagnosticar e resolver problemas no circuito do ExpressRoute.
Selecione Problemas de desempenho.
Aguarde a execução do diagnóstico e interprete os resultados.
Se a manutenção ocorreu durante a perda ou latência do pacote, ela pode ter contribuído para problemas de conectividade. Siga as etapas recomendadas e considere atualizar o SKU do gateway de rede virtual para dar suporte a uma taxa de transferência mais alta e evitar problemas futuros.
Próximas etapas
Para obter mais informações ou ajuda, confira os seguintes links: