Technical Lab: Diagnose and Resolve ExpressRoute Connection Issues
Questions
Question 1 — Multiple Choice
A network team reports that the ExpressRoute circuit shows status "Provider status: Not Provisioned" in the Azure portal, even after completing the order with the connectivity provider. The responsible engineer verifies that the service key was correctly sent to the provider.
What is the most precise technical interpretation of this state?
A) The circuit was provisioned by the provider, but the Microsoft side has not yet completed the peering configuration.
B) The provider has not yet completed circuit provisioning on their side, making any peering configuration premature.
C) BGP is established, but routing to the Microsoft side is failing due to missing advertised routes.
D) The virtual network gateway has not yet been associated with the circuit, which prevents transition to the provisioned state.
Question 2 — Technical Scenario
An administrator configures Microsoft Peering on an ExpressRoute circuit to access Microsoft 365. After configuration, the peering appears as "Enabled", but no traffic destined for Microsoft 365 flows through the circuit. A default route is being advertised via BGP from the on-premises environment.
Consider the configuration excerpt below:
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
What is the most likely cause of the problem?
A) VLAN ID 200 is invalid for Microsoft Peering; only VLANs above 1000 are accepted.
B) The Route Filter is not configured, which prevents Microsoft 365 prefixes from being advertised to the on-premises environment.
C) The PeerASN 65100 is in the private range and cannot be used in Microsoft Peering.
D) The /30 subnets are insufficient for Microsoft Peering, which requires /29 blocks at minimum.
Question 3 — True or False
An ExpressRoute circuit with Local SKU allows access to all Azure regions globally, provided that private peering is configured correctly and the virtual network gateway supports the appropriate SKU type.
True or False?
Question 4 — Technical Scenario
A company uses ExpressRoute with Private Peering and notices that virtual machines in a spoke VNet, connected via VNet Peering to the hub VNet (where the ExpressRoute gateway is located), cannot reach on-premises resources. The hub VNet reaches on-premises resources normally.
What missing configuration directly explains this behavior?
A) BGP is not enabled on the virtual network gateway of the hub VNet.
B) The "Allow Gateway Transit" option is not enabled in the VNet Peering on the hub VNet side, or "Use Remote Gateways" is not enabled on the spoke VNet side.
C) The ExpressRoute circuit needs a second dedicated connection for each participating spoke VNet.
D) The spoke VNet needs its own virtual network gateway configured with the same ExpressRoute circuit.
Question 5 — Multiple Choice
When diagnosing connectivity failures on an ExpressRoute circuit, an engineer executes the following command:
Get-AzExpressRouteCircuitARPTable `
-ResourceGroupName "rg-network" `
-ExpressRouteCircuitName "erc-prod" `
-PeeringType "AzurePrivatePeering" `
-DevicePath "Primary"
The returned ARP table shows the IP on the Microsoft side, but does not show the MAC address from the provider/customer side.
What does this absence indicate most precisely?
A) BGP is established, but there is an asymmetric routing problem between the primary and secondary paths.
B) There is a Layer 2 problem between the provider edge and the Microsoft Edge Router, as ARP has not completed address resolution of the peer's physical address.
C) The prefix advertised by the customer is being rejected by the Microsoft side routing policy for not meeting public prefix requirements.
D) The virtual network gateway is in maintenance state, which temporarily blocks ARP table updates.
Answer Key and Explanations
Answer Key — Question 1
Answer: B
The status "Provider status: Not Provisioned" specifically indicates that the connectivity provider has not yet completed circuit provisioning on their side. The ExpressRoute circuit lifecycle has two independent sides: the Microsoft side and the Provider side. While the Provider side has not transitioned to "Provisioned", any attempt to configure peerings will be premature and may fail or have no real connectivity effect.
Alternative A describes a different state, where the provider has already completed and the Microsoft side would be pending. Alternative D confuses responsibility: gateway association is a later step, completely independent of circuit provisioning status. Alternative C assumes a connectivity layer (active BGP) that cannot even exist if provisioning has not been completed.
Answer Key — Question 2
Answer: B
The Route Filter is a mandatory requirement for Microsoft Peering. Without it, no Microsoft service BGP communities (including Microsoft 365 and Azure PaaS) are advertised to the on-premises environment. The peering may appear as "Enabled" because the BGP session is established, but the control plane does not distribute prefixes without the configured filter.
Alternative A is false: there is no VLAN ID range restriction for Microsoft Peering. Alternative C is a common misconception: private ASNs are accepted in Microsoft Peering as long as they are properly validated in the configuration process. Alternative D is also incorrect: /30 is the correct and documented subnet size for Microsoft Peering point-to-point links.
Answer Key — Question 3
Answer: False
The ExpressRoute Local SKU is restricted to accessing Azure regions geographically close to the peering location (the same metropolitan area or paired region defined by Microsoft). It does not allow global access to all Azure regions. This is precisely the central distinction between SKUs: Local offers unlimited data transfer, but with restricted geographical scope; Standard and Premium progressively expand regional and global reach. Assuming that correct peering and gateway configuration is sufficient to overcome this limitation is a common diagnostic error.
Answer Key — Question 4
Answer: B
The ExpressRoute gateway, by default, does not propagate routes learned via ExpressRoute to VNets connected by VNet Peering, unless two configurations are present simultaneously: "Allow Gateway Transit" enabled on the peering from the hub VNet side, and "Use Remote Gateways" enabled on the peering from the spoke VNet side. The absence of either breaks the routing path.
Alternative A is irrelevant because BGP on the gateway refers to the internal protocol between the gateway and the on-premises network, not transit between VNets. Alternative C is incorrect: ExpressRoute does not require separate connections per spoke. Alternative D contradicts the hub-and-spoke architecture itself, which exists precisely to share a single gateway among multiple spokes.
Answer Key — Question 5
Answer: B
The ARP table in the ExpressRoute context operates at Layer 2. It maps peer IP addresses to their corresponding MAC addresses. If the Microsoft side IP appears, but the peer's (provider or customer) MAC address is absent, it means the ARP resolution process was not completed, indicating a data link layer problem between the involved devices. This can result from VLAN misconfiguration, incorrect encapsulation, or physical/logical failure in the L2 segment.
Alternative A assumes BGP is established, which is impossible without Layer 2 functioning. Alternative C describes a routing policy problem (Layer 3/control), which would manifest differently in the BGP table, not the ARP table. Alternative D is a plausible distractor, but gateway maintenance does not affect the circuit's ARP table, which is maintained in the Microsoft Edge Router infrastructure.