Troubleshooting Lab: Configure Microsoft Peering
Diagnostic Scenarios
Scenario 1 — Root Cause
A company's network team reports that the ExpressRoute circuit was successfully provisioned by the carrier and that Microsoft peering shows as Provisioned in the Azure portal. A Route Filter was created and associated with the peering three days ago. The circuit operates at 1 Gbps bandwidth and the physical link is stable, with no packet loss reported by the provider.
Despite this, the on-premises router does not receive any BGP routes from Microsoft via the circuit. The engineer executes the following command on the router:
show bgp neighbors 192.0.2.1 routes
BGP neighbor is 192.0.2.1, remote AS 8075
BGP state = Established, up for 2d 04:11:32
Prefixes received: 0
Prefixes advertised: 2
The engineer observes that the BGP session is established and that the router is advertising 2 prefixes to Microsoft. The provider confirmed that no filters are applied on their side.
What is the root cause of the problem?
A) The BGP session is established, but remote AS 8075 indicates that the connection was made with the wrong peer; Microsoft peering requires connection with a different AS.
B) The Route Filter is associated with the peering, but does not contain any BGP community rules, therefore Microsoft does not advertise routes to the circuit.
C) The router is advertising only 2 prefixes, when Microsoft peering requires a minimum of 5 advertised prefixes to activate route reception.
D) The 1 Gbps circuit does not support Microsoft peering; this functionality requires circuits of at least 2 Gbps.
Scenario 2 — Action Decision
The operations team identified that the Microsoft peering of a production ExpressRoute circuit has been in ValidationNeeded state since morning. The circuit is responsible for access to Exchange Online and SharePoint Online for approximately 3,000 users who are currently using the public internet as an alternative path, with noticeable performance degradation.
The investigation confirmed that the prefix advertised in the AdvertisedPublicPrefixes field does not have a route object registered in the IRR declared under the customer's ASN. The responsible engineer has access to the IRR portal and can register the prefix immediately. He also has permission to edit the peering configuration in the Azure portal.
A colleague suggests recreating the peering from scratch to force a faster new validation. Another suggests opening a support ticket with Microsoft to request manual approval.
What is the correct action to take at this time?
A) Recreate the peering from scratch, as recreation forces an immediate new validation cycle and solves the problem faster than correcting the IRR registration.
B) Register the prefix in the IRR under the correct ASN and, after registration propagation, edit the peering configuration to trigger a new validation cycle.
C) Open a support ticket with Microsoft requesting manual prefix approval, as it is the only mechanism available when the IRR is not configured correctly.
D) Change the RoutingRegistryName field to RADB in the existing peering, as RADB has faster propagation and will solve the problem without needing to register the prefix.
Scenario 3 — Root Cause
An organization configured Microsoft peering on an ExpressRoute circuit six months ago and the environment works correctly for Exchange Online. This week, the team added a new rule to the existing Route Filter to include Azure SQL Database from a specific region. After the change, the engineer checks the BGP table on the on-premises router:
show ip bgp
Network Next Hop Metric LocPrf Weight Path
40.64.0.0/10 192.0.2.1 0 100 0 8075 i
13.96.0.0/13 192.0.2.1 0 100 0 8075 i
104.40.0.0/13 192.0.2.1 0 100 0 8075 i
The engineer confirms that the prefixes above correspond to Exchange Online routes received previously. No new routes related to Azure SQL Database appear in the table. The Route Filter in the portal shows the following state:
Route Filter: RF-PROD
Status : Active
Rules:
- Community: 12076:5010 (Exchange Online) [Active]
- Community: 12076:5021 (Azure SQL - East US) [Provisioning]
The circuit and peering are in Provisioned state. The physical link is stable. The carrier has not performed any recent maintenance.
What is the root cause of the absence of new routes?
A) The prefix 12076:5021 is not a valid BGP community for Azure SQL Database; the correct value requires a different community number for PaaS services.
B) The new Route Filter rule is still in Provisioning state and the corresponding routes have not yet been advertised by Microsoft to the circuit.
C) The on-premises router is applying an inbound filter that blocks prefixes not explicitly listed in the local configuration, preventing reception of new routes.
D) The Route Filter with multiple active rules requires the peering to be deprovisioned and reprovisioned for new rules to take effect.
Scenario 4 — Diagnostic Sequence
An engineer receives a report that traffic to Microsoft 365 is not passing through the ExpressRoute circuit, even though Microsoft peering was working correctly the previous week. No scheduled maintenance was performed on the circuit. Traffic is flowing through the public internet as an alternative path.
Available investigation steps are:
- Step P: Check if the Route Filter associated with the peering still contains the expected BGP community rules.
- Step Q: Check the current state of the peering in the Azure portal (if it is
Provisioned,ValidationNeededor other). - Step R: Check in the on-premises router BGP table if Microsoft 365 routes are being received through the circuit.
- Step S: Check if there is a default route (
0.0.0.0/0) advertisement or more specific route via internet that is overriding ExpressRoute routes on the router. - Step T: Confirm with the carrier if the physical circuit and primary and secondary links are operational.
Which sequence represents the correct diagnostic reasoning, from most comprehensive to most specific?
A) T, Q, R, P, S
B) R, P, Q, T, S
C) Q, T, P, R, S
D) P, R, Q, S, T
Answer Key and Explanations
Answer Key — Scenario 1
Answer: B
The decisive clue is in the command output: Prefixes received: 0, with the BGP session in Established state. An established BGP session means that connectivity and authentication between peers are working. The problem is exclusively in advertisement policy: Microsoft is not sending routes.
When a Route Filter is associated with the peering but does not contain any BGP community rules, Microsoft's behavior is not to advertise any prefixes. The filter exists, but is empty of rules, resulting in exactly zero routes received, which is the observed symptom.
The irrelevant information in the scenario is the 1 Gbps bandwidth, included purposely to induce alternative D. Circuit capacity has no relationship to Microsoft peering support.
Alternative A represents a classic error of confusing AS 8075 with something wrong: this is Microsoft's legitimate ASN used in Microsoft peering sessions and does not indicate incorrect configuration. Alternative C is an invented distractor; there is no minimum requirement for advertised prefixes to receive routes. The most dangerous distractor is A, because it leads the engineer to look for a non-existent problem in connectivity with the correct peer, wasting valuable time.
Answer Key — Scenario 2
Answer: B
The cause was identified with precision: absence of the route object in the IRR. The correct path is to fix exactly what is wrong, in logical order: first register the prefix in the IRR, wait for registration propagation between IRR servers, and then trigger a new validation cycle by editing the peering configuration in the portal.
Alternative A represents a correct action in the wrong context: recreating the peering does not accelerate validation if the prefix is still not registered in the IRR. Recreation without correcting the registration would result in the same ValidationNeeded state. Additionally, in production, recreating the peering would cause service interruption during reprovisioning.
Alternative C ignores the availability of a direct and customer-controllable solution. Manual approval by Microsoft is a last resort path, not the standard procedure. Alternative D is technically incorrect: changing the declared IRR without registering the prefix in that IRR does not solve the problem; it only shifts the failure point.
Answer Key — Scenario 3
Answer: B
The evidence is visible in the statement itself: the new rule state in the Route Filter is Provisioning, not Active. When a rule is added to an existing Route Filter, it needs to be provisioned by the Azure platform before becoming effective. During this interval, Microsoft does not yet advertise the prefixes corresponding to the new community.
Exchange Online routes continue to arrive normally because rule 12076:5010 has Active state, confirming that the Route Filter mechanism works correctly.
The irrelevant information in this scenario is the fact that the physical link is stable and the carrier has not performed maintenance. This data diverts attention to physical infrastructure when the problem is entirely in the routing policy layer.
Alternative C represents a serious diagnostic error: attributing the cause to a filter on the on-premises router without any evidence that this filter exists or was changed. The most dangerous distractor is D, because it could lead the engineer to unnecessarily deprovision and reprovision the peering in production, causing real service interruption.
Answer Key — Scenario 4
Answer: A
The correct sequence is T, Q, R, P, S, which follows the progressive diagnostic principle: confirm the most fundamental layers before investigating higher layers.
T checks the physical layer with the carrier, as without physical connectivity no other investigation makes sense. Q checks the peering state in the Azure control plane, establishing if the problem is in the platform. R examines the router BGP table, determining if routes are being received through the circuit. P inspects Route Filter rules, verifying if the advertisement policy is correct. S checks if there is a route preference problem on the local router that is overriding ExpressRoute routes, which would be the most subtle and specific cause.
Alternative B starts with the BGP table (R) before confirming if the physical circuit and peering are operational, which inverts the progressive elimination logic. Alternative C starts with the peering state before confirming the physical layer, missing the opportunity to quickly rule out an infrastructure failure. Alternative D starts with the Route Filter, which is a configuration detail investigated only after confirming that lower layers are functional.
Troubleshooting Tree: Configure Microsoft Peering
Color Legend:
| Color | Node Type |
|---|---|
| Dark blue | Initial symptom (entry point) |
| Blue | Diagnostic question (decision based on observation) |
| Red | Identified cause |
| Green | Recommended action or resolution |
| Orange | Intermediate verification or validation |
To use this tree when facing a real problem, start with the root node (dark blue) and answer each question from blue nodes based on what is directly observed in the environment: Azure portal, router command output, and carrier confirmations. Each answer eliminates a branch of hypotheses and directs to the next level of specificity. When reaching a red node, the cause is identified. The green node immediately below indicates the corresponding corrective action. Orange nodes signal that additional verification is needed before concluding the diagnosis of that branch.