Laboratório Técnico: Diagnose and Resolve ExpressRoute Connection Issues
Questões
Questão 1 — Múltipla Escolha
Uma equipe de rede reporta que o circuito ExpressRoute aparece com status "Provider status: Not Provisioned" no portal do Azure, mesmo após a conclusão do pedido ao provedor de conectividade. O engenheiro responsável verifica que a chave de serviço foi enviada corretamente ao provedor.
Qual é a interpretação técnica mais precisa desse estado?
A) O circuito foi provisionado pelo provedor, mas o Microsoft side ainda não concluiu a configuração do peering.
B) O provedor ainda não completou o provisionamento do circuito no lado dele, tornando qualquer configuração de peering prematura.
C) O BGP está estabelecido, mas o roteamento para o Microsoft side está falhando por ausência de rota anunciada.
D) O gateway de rede virtual ainda não foi associado ao circuito, o que impede a transição para o estado provisionado.
Questão 2 — Cenário Técnico
Um administrador configura o Microsoft Peering em um circuito ExpressRoute para acessar o Microsoft 365. Após a configuração, o peering aparece como "Enabled", mas nenhum tráfego destinado ao Microsoft 365 flui pelo circuito. A rota padrão está sendo anunciada via BGP pelo ambiente on-premises.
Considere o trecho de configuração abaixo:
Peering Type : MicrosoftPeering
PeeringState : Enabled
AzureASN : 12076
PeerASN : 65100
PrimarySubnet : 192.168.100.0/30
SecondarySubnet : 192.168.100.4/30
VlanId : 200
RouteFilter : Not Configured
Qual é a causa mais provável do problema?
A) O VLAN ID 200 é inválido para Microsoft Peering; apenas VLANs acima de 1000 são aceitas.
B) O Route Filter não está configurado, o que impede que os prefixos do Microsoft 365 sejam anunciados ao ambiente on-premises.
C) O PeerASN 65100 está no intervalo privado e não pode ser usado em Microsoft Peering.
D) As sub-redes /30 são insuficientes para Microsoft Peering, que exige blocos /29 no mínimo.
Questão 3 — Verdadeiro ou Falso
Um circuito ExpressRoute com SKU Local permite acesso a todas as regiões do Azure globalmente, desde que o peering privado esteja configurado corretamente e o gateway de rede virtual suporte o tipo de SKU adequado.
Verdadeiro ou Falso?
Questão 4 — Cenário Técnico
Uma empresa utiliza ExpressRoute com Private Peering e nota que máquinas virtuais em uma VNet spoke, conectada via VNet Peering à VNet hub (onde está o gateway ExpressRoute), não conseguem alcançar recursos on-premises. A VNet hub alcança os recursos on-premises normalmente.
Qual configuração ausente explica diretamente esse comportamento?
A) O BGP não está habilitado no gateway de rede virtual da VNet hub.
B) A opção "Allow Gateway Transit" não está habilitada no VNet Peering do lado da VNet hub, ou "Use Remote Gateways" não está habilitada no lado da VNet spoke.
C) O circuito ExpressRoute precisa de uma segunda conexão dedicada para cada VNet spoke participante.
D) A VNet spoke precisa de seu próprio gateway de rede virtual configurado com o mesmo circuito ExpressRoute.
Questão 5 — Múltipla Escolha
Ao diagnosticar falhas de conectividade em um circuito ExpressRoute, um engenheiro executa o seguinte comando:
Get-AzExpressRouteCircuitARPTable `
-ResourceGroupName "rg-network" `
-ExpressRouteCircuitName "erc-prod" `
-PeeringType "AzurePrivatePeering" `
-DevicePath "Primary"
A tabela ARP retornada mostra o IP do lado Microsoft, mas não mostra o endereço MAC do lado do provedor/cliente.
O que essa ausência indica com maior precisão?
A) O BGP está estabelecido, mas há um problema de roteamento assimétrico entre os caminhos primário e secundário.
B) Há um problema na camada 2 entre o edge do provedor e o Microsoft Edge Router, pois o ARP não completou a resolução do endereço físico do peer.
C) O prefixo anunciado pelo cliente está sendo rejeitado pela política de roteamento do Microsoft side por não atender aos requisitos de prefixo público.
D) O gateway de rede virtual está em estado de manutenção, o que bloqueia temporariamente a atualização da tabela ARP.
Gabarito e Explicações
Gabarito — Questão 1
Resposta: B
O status "Provider status: Not Provisioned" indica especificamente que o provedor de conectividade ainda não concluiu o provisionamento do circuito no lado dele. O ciclo de vida do circuito ExpressRoute possui dois lados independentes: o Microsoft side e o Provider side. Enquanto o Provider side não transitar para "Provisioned", qualquer tentativa de configurar peerings será prematura e pode falhar ou não ter efeito real de conectividade.
A alternativa A descreve um estado diferente, onde o provedor já concluiu e o Microsoft side estaria pendente. A alternativa D confunde a responsabilidade: a associação do gateway é uma etapa posterior, totalmente independente do status de provisionamento do circuito. A alternativa C pressupõe uma camada de conectividade (BGP ativo) que sequer pode existir se o provisionamento não foi concluído.
Gabarito — Questão 2
Resposta: B
O Route Filter é um requisito obrigatório para o Microsoft Peering. Sem ele, nenhuma comunidade BGP de serviços Microsoft (incluindo Microsoft 365 e Azure PaaS) é anunciada ao ambiente on-premises. O peering pode aparecer como "Enabled" porque a sessão BGP está estabelecida, mas o plano de controle não distribui os prefixos sem o filtro configurado.
A alternativa A é falsa: não há restrição de faixa de VLAN ID para Microsoft Peering. A alternativa C é um equívoco comum: ASNs privados são aceitos em Microsoft Peering desde que devidamente validados no processo de configuração. A alternativa D também é incorreta: /30 é o tamanho de sub-rede correto e documentado para os links ponto a ponto do Microsoft Peering.
Gabarito — Questão 3
Resposta: Falso
O SKU Local do ExpressRoute é restrito ao acesso de regiões Azure geograficamente próximas ao local de peering (a mesma área metropolitana ou região emparelhada definida pela Microsoft). Ele não permite acesso global a todas as regiões do Azure. Essa é justamente a distinção central entre os SKUs: Local oferece transferência de dados ilimitada, mas com escopo geográfico restrito; Standard e Premium ampliam progressivamente o alcance regional e global. Assumir que a configuração correta do peering e do gateway basta para superar essa limitação é um erro de diagnóstico comum.
Gabarito — Questão 4
Resposta: B
O gateway ExpressRoute, por padrão, não propaga rotas aprendidas via ExpressRoute para VNets conectadas por VNet Peering, a menos que duas configurações estejam presentes simultaneamente: "Allow Gateway Transit" habilitado no peering do lado da VNet hub, e "Use Remote Gateways" habilitado no peering do lado da VNet spoke. A ausência de qualquer uma delas quebra o caminho de roteamento.
A alternativa A é irrelevante porque BGP no gateway refere-se ao protocolo interno entre o gateway e a rede on-premises, não ao trânsito entre VNets. A alternativa C é incorreta: o ExpressRoute não exige conexões separadas por spoke. A alternativa D contradiz a própria arquitetura hub-and-spoke, que existe precisamente para compartilhar um único gateway entre múltiplas spokes.
Gabarito — Questão 5
Resposta: B
A tabela ARP no contexto do ExpressRoute opera na camada 2. Ela mapeia endereços IP dos peers aos seus endereços MAC correspondentes. Se o IP do lado Microsoft aparece, mas o endereço MAC do peer (provedor ou cliente) está ausente, significa que o processo de resolução ARP não foi completado, o que indica um problema na camada de enlace entre os dispositivos envolvidos. Isso pode decorrer de má configuração de VLAN, encapsulamento incorreto ou falha física/lógica no segmento L2.
A alternativa A pressupõe que o BGP está estabelecido, o que é impossível sem que a camada 2 esteja funcionando. A alternativa C descreve um problema de política de roteamento (camada 3/controle), que se manifestaria de forma diferente na tabela BGP, não na tabela ARP. A alternativa D é um distrator plausível, mas manutenção do gateway não afeta a tabela ARP do circuito, que é mantida na infraestrutura do Microsoft Edge Router.