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.
No diagrama anterior, 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).
- PEs (roteadores/comutadores de borda do provedor) voltados aos roteadores de borda do cliente.
- PEs voltados aos roteadores do ExpressRoute do MSEE (Microsoft Enterprise Edge). Neste artigo eles se chamam PE-MSEEs.
- MSEEs.
- Gateway de rede virtual.
- 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 
da página lista as informações gerais do ExpressRoute como nesta captura de tela:
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 da página lista os emparelhamentos do ExpressRoute como nesta captura de tela:
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 público do Azure, use os seguintes comandos:
$ckt = Get-AzExpressRouteCircuit -ResourceGroupName "Test-ER-RG" -Name "Test-ER-Ckt"
Get-AzExpressRouteCircuitPeeringConfig -Name "AzurePublicPeering" -ExpressRouteCircuit $ckt
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. Veja uma resposta de exemplo, quando o emparelhamento indicado (emparelhamento público do Azure neste caso) não está configurado no circuito:
Get-AzExpressRouteCircuitPeeringConfig : Sequence contains no matching element
At line:1 char:1
+ Get-AzExpressRouteCircuitPeeringConfig -Name "AzurePublicPeering ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ 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
Para acessar a ferramenta de diagnóstico, selecione Diagnosticar e resolver problemas do circuito do ExpressRoute no portal do Azure.
SelecioneConectividade e Problemas de desempenho.
Na lista suspensa Conte-nos mais sobre o problema que você está enfrentando, selecione Problemas com Emparelhamento privado.
Role para baixo até a seção Testar sua conectividade de emparelhamento privado e expanda-a.
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.
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.
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:
Selecione Diagnosticar e resolver problemas do circuito ExpressRoute no portal do Azure.
Selecione a opção Problemas de Desempenho.
Aguarde a execução do diagnóstico e interprete os resultados.
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: