Troubleshooting Lab: Choose between Azure private peering only, Microsoft peering only, or both
Diagnostic Scenarios
Scenario 1 — Root Cause
A company configured a 1 Gbps ExpressRoute circuit with Azure private peering three weeks ago. The on-premises environment has confirmed physical connectivity with the circuit provider, and the circuit status in the Azure portal shows as Provisioned. The network team reports that private peering BGP sessions are established and stable.
Last week, the security team enabled a new set of firewall rules on-premises to block outbound traffic on ports 443 and 80 to IP ranges not internally cataloged. No changes were made in Azure.
Application engineers report the following behavior:
Test 1: Ping from on-premises server to Azure VM (10.10.1.4) -> SUCCESS
Test 2: RDP access from on-premises server to Azure VM (10.10.1.4) -> SUCCESS
Test 3: Access to Azure Storage portal (storage-account.blob.core.windows.net) -> FAILURE
Test 4: Access to Exchange Online (outlook.office365.com) -> FAILURE
Test 5: Access to another blob storage via private endpoint (10.10.2.8) -> SUCCESS
The infrastructure manager suggests that the problem is intermittency in the ExpressRoute circuit, since "some accesses work and others don't".
What is the root cause of the failures observed in Tests 3 and 4?
A) ExpressRoute circuit intermittency causing selective packet loss to specific destinations
B) Firewall rules are blocking traffic because public IPs of Microsoft services are not internally cataloged
C) The circuit does not have Microsoft peering configured, therefore public Microsoft service prefixes are not advertised by this routing domain
D) Azure private peering does not support traffic to endpoints with public DNS names, requiring private DNS resolution for all destinations
Scenario 2 — Action Decision
A company's engineering team identified the cause of a connectivity problem: the ExpressRoute circuit is configured with Microsoft peering only, but the architecture requires private access to VMs in multiple Azure VNets. The production environment is active and the circuit is being used by dozens of users accessing Microsoft 365 through ExpressRoute at this time.
The team has the following documented restrictions:
- Available maintenance window: next Friday, 10 PM to 2 AM
- ExpressRoute circuit: provisioned and in active use
- VNet Gateway: not yet created in Azure
- BGP communities for Microsoft peering: configured and in use
- Acceptable impact outside maintenance window: none
What is the correct action to take at this moment?
A) Reconfigure the existing Microsoft peering to operate as private peering, leveraging the already established BGP session and avoiding any interruption
B) Enable Azure private peering immediately, as it operates in an independent routing domain and its configuration does not affect the Microsoft peering in use
C) Wait for the maintenance window, because although private peering can be added independently, creating the VNet Gateway and associating it to the circuit may impact existing connectivity
D) Request the connectivity provider to create a second ExpressRoute circuit dedicated to private peering, as the two types of peering cannot coexist on the same circuit
Scenario 3 — Root Cause
A manufacturing company has an ExpressRoute circuit with Azure private peering and Microsoft peering configured. The network team just migrated the on-premises environment to a new IP address block: from 192.168.0.0/16 to 172.20.0.0/14. The migration was completed and on-premises equipment is operational.
After the migration, the following behavior is observed:
BGP private peering status : Established
BGP Microsoft peering status : Established
Routes advertised to Azure : 172.20.0.0/14 (new block)
Routes received from Azure : 10.10.0.0/16 (main VNet)
Test: Azure VM (10.10.1.5) -> on-premises server (172.20.10.1) : FAILURE
Test: On-premises server (172.20.10.1) -> Azure VM (10.10.1.5) : SUCCESS
Test: On-premises server -> Exchange Online : SUCCESS
The responsible technician verifies that the on-premises firewall has no rules blocking return traffic. They also confirm that the new 172.20.0.0/14 block has no overlap with any addresses in Azure. Circuit bandwidth is below 10% utilization.
What is the root cause of the failure in the first test?
A) The ExpressRoute circuit has a capacity problem and is selectively dropping return packets
B) The Azure VNet still has routes pointing to the old 192.168.0.0/16 block, and return traffic is being dropped due to absence of valid route to 172.20.0.0/14
C) Microsoft peering is interfering with private peering by advertising overlapping routes to the VNet gateway
D) The on-premises firewall is blocking traffic initiated from Azure, even without explicit rules configured for the new block
Scenario 4 — Diagnostic Sequence
An engineer receives the following report: "We configured Microsoft peering today and expected to access Microsoft 365 services through ExpressRoute, but traffic is still going out through the internet."
The engineer has the following investigation steps available, listed out of order:
Step P: Verify if routes received via Microsoft peering are being
installed in the routing table of on-premises equipment
Step Q: Confirm that Microsoft peering BGP status shows as Established
in the Azure portal and on-premises equipment
Step R: Verify if there is an on-premises routing policy (route policy
or route map) that is accepting and preferring routes received via
ExpressRoute over the default internet route
Step S: Confirm if Microsoft 365 service public IP prefixes are
being advertised by the Microsoft peering BGP session
Step T: Verify if the ExpressRoute circuit is in Provisioned status and if
the provider completed provisioning on their side
What is the correct progressive diagnostic sequence?
A) T -> Q -> S -> P -> R
B) Q -> T -> R -> S -> P
C) S -> P -> Q -> T -> R
D) T -> S -> Q -> P -> R
Answer Key and Explanations
Answer Key — Scenario 1
Answer: C
The decisive clue lies in the test results: successful accesses (Tests 1, 2, and 5) have one common element: all destinations are private IP addresses, whether a VM directly or a service accessed via Private Endpoint. Tests 3 and 4 fail because their destinations have public IP addresses, whose prefixes are advertised exclusively by Microsoft peering. Since only private peering is configured, these prefixes simply don't exist in the BGP routing table available for on-premises traffic.
The information about firewall rules is irrelevant for Tests 3 and 4 in this diagnosis: traffic doesn't even get routed through ExpressRoute to these destinations because the route doesn't exist. Route absence precedes packet filtering.
The manager's diagnostic error (circuit intermittency) is the most dangerous distractor: it diverts the team to investigate the provider and hardware, delaying identification of a simple and objective configuration gap. Alternative D is technically incorrect: private peering routes based on IP addresses, not DNS names.
Answer Key — Scenario 2
Answer: C
The cause is identified and the technical solution is clear: add Azure private peering to the circuit. The critical point in this scenario is the zero impact restriction outside the maintenance window.
Although the private peering BGP session can be configured independently without interrupting Microsoft peering, creating the VNet Gateway and associating it to the ExpressRoute circuit involves VNet data plane operations that may impact existing connectivity. Since the circuit is in active use by dozens of users, the correct action is to plan complete execution for the available maintenance window.
Alternative B is the most dangerous distractor: it's partially correct (private peering is independent of Microsoft peering) but ignores that the VNet Gateway step is a necessary part of the solution and is not risk-free in active production. Alternative A is technically invalid: the two peerings are distinct domains and one cannot be reconverted to the other. Alternative D is false: both peerings normally coexist on the same circuit.
Answer Key — Scenario 3
Answer: B
The symptom is asymmetric: traffic from on-premises to Azure works, but traffic from Azure to on-premises fails. This asymmetry is the central diagnostic clue.
Traffic initiated in Azure seeks a route in the VNet's effective routing table to reach 172.20.0.0/14. If this route wasn't updated after the on-premises addressing migration (still points to 192.168.0.0/16 or simply doesn't exist for the new block), return packets are dropped in Azure before reaching the circuit. The fact that BGP shows the new block is being advertised by on-premises doesn't guarantee that the VNet has already updated its effective routes or that the gateway propagated correctly.
The bandwidth information (below 10%) is irrelevant and was included to induce capacity investigation, which has no relation to the observed asymmetric pattern. The most dangerous distractor is D: it seems plausible because it involves firewall and remotely initiated traffic, but the statement itself confirms there are no rules blocking return traffic.
Answer Key — Scenario 4
Answer: A
The correct sequence is T -> Q -> S -> P -> R, following progressive diagnostic logic from most fundamental to most specific:
| Order | Step | Reason |
|---|---|---|
| 1 | T | Without a provisioned circuit, no other verification makes sense |
| 2 | Q | Without an established BGP session, no routes are exchanged |
| 3 | S | Confirms if correct prefixes are being advertised by the active session |
| 4 | P | Verifies if routes arrived and were installed in the local table |
| 5 | R | Only after confirming routes exist, verify if equipment is preferring them over the default internet route |
The error represented by incorrect alternatives is skipping infrastructure validation steps and going directly to routing policy configurations (R) before confirming the control plane is functional. Executing Step R before Step Q, for example, would be investigating routing policies on a BGP session that might not even be established, consuming time without possibility of valid conclusion.
Troubleshooting Tree: Choose between Azure private peering only, Microsoft peering only, or both
Color legend:
- Dark blue: initial symptom or diagnostic entry point
- Medium blue: objective diagnostic question with yes or no answer
- Red: identified cause
- Green: recommended action or resolution
To use this tree when facing a real problem, start with the root node describing the ExpressRoute connectivity failure. Answer each diagnostic question based on what is observable in the environment: Azure portal status, BGP command output on on-premises equipment, and connectivity test results. Follow the path corresponding to your answer until reaching a red cause identification node, which points directly to the resolution action in the subsequent green node. The diagram covers both private peering and Microsoft peering scenarios, as well as failures involving both simultaneously.