Troubleshooting Lab: Configure Virtual Hub Routing
Diagnostic Scenarios
Scenario 1 — Root Cause
An operations team reports that VMs in VNet-Prod cannot reach VMs in VNet-Shared, both connected to the same Virtual WAN hub in the East US region. The hub has two Route Tables configured: RT-Prod and defaultRouteTable.
The team reports that the problem started right after a connection reorganization performed last night. They also mention that the peering between VNet-Prod and the hub was recreated during the maintenance window, and that the connection status in the portal shows as Succeeded. The security team confirms that the NSGs applied to the VMs were not changed and that the rules allow traffic on port 443.
Inspection of the current configuration reveals:
VNet-Prod connection:
Association: RT-Prod
Propagation: RT-Prod
VNet-Shared connection:
Association: defaultRouteTable
Propagation: defaultRouteTable
RT-Prod does not contain learned routes from VNet-Shared. defaultRouteTable contains the route for the VNet-Prod prefix.
What is the root cause of the connectivity failure?
A) The NSGs on VNet-Prod VMs are blocking return traffic from VNet-Shared, even though no changes were declared by the security team.
B) The VNet-Shared connection does not propagate its routes to RT-Prod, therefore VNet-Prod never learns the VNet-Shared prefix.
C) The VNet-Prod connection only propagates to RT-Prod, which prevents other resources from learning the return route to VNet-Prod.
D) The Succeeded connection status only indicates that the object was created, but peering may still be in an incomplete synchronization state causing route loss.
Scenario 2 — Action Decision
The cause of the problem has been identified: Routing Intent with private traffic policy was enabled on the production hub during an approved change, but the Azure Firewall configured as the next hop has not yet completed provisioning. The Firewall status in the portal is Updating.
The environment has the following restrictions:
- Approximately 40 VNet connections are associated with the hub
- All Site-to-Site VPN connections from branches depend on the hub to route traffic between each other
- The environment availability SLA is 99.9% and the incident has been open for 22 minutes
- The network team has Contributor permission on the hub but does not have permission to modify Firewall Manager policies
- Reverting the Routing Intent requires write permission on the Routing Intent resource, which the team has
What is the correct action to take at this moment?
A) Wait for the Azure Firewall provisioning to complete, as the Routing Intent stabilizes automatically once the Firewall becomes available, without requiring intervention.
B) Remove the Routing Intent immediately to restore previous routing and open a ticket for the Firewall Manager responsible team to complete provisioning in a next controlled window.
C) Create manual static routes in each hub Route Table pointing RFC 1918 prefixes directly to destination connections, bypassing the Routing Intent without removing it.
D) Request the Firewall Manager team to force reprovisioning of the Azure Firewall via portal, as this action does not impact existing connections and resolves the Updating state in less than 5 minutes.
Scenario 3 — Root Cause
A senior architect receives an alert: VMs in VNet-App (Hub-A, Brazil South region) cannot reach VMs in VNet-DB (Hub-B, East US region). Both hubs belong to the same Virtual WAN.
The architect verifies the following:
Hub-A:
Status: Succeeded
VNet-App connection: Associated=defaultRouteTable, Propagates=defaultRouteTable
defaultRouteTable learned routes:
10.10.0.0/16 --> VNet-App connection
10.30.0.0/16 --> Hub-B (inter-hub)
Hub-B:
Status: Succeeded
VNet-DB connection: Associated=defaultRouteTable, Propagates=defaultRouteTable
defaultRouteTable learned routes:
10.20.0.0/16 --> VNet-DB connection
10.10.0.0/16 --> Hub-A (inter-hub)
The architect also confirms that there are no custom Route Tables in either hub, that peering between hubs is active, and that no configuration changes have been made in the last 7 days. A colleague suggests that the problem might be the VNet-DB prefix (10.20.0.0/16) not appearing in Hub-A's defaultRouteTable.
The architect executes the following command:
az network vhub route-table route list \
--resource-group rg-vwan \
--vhub-name Hub-A \
--name defaultRouteTable
Output:
[
{ "destinations": ["10.10.0.0/16"], "nextHopType": "ResourceId", "nextHops": ["...VNet-App-connection"] },
{ "destinations": ["10.30.0.0/16"], "nextHopType": "ResourceId", "nextHops": ["...Hub-B-connection"] }
]
What is the root cause of the problem?
A) The 10.20.0.0/16 prefix from VNet-DB is not being propagated from Hub-B to Hub-A, indicating that the VNet-DB connection is not propagating its routes to Hub-B's defaultRouteTable.
B) Inter-hub peering is active but operating in read-only mode due to a pending synchronization state, preventing route exchange between hubs.
C) The absence of the 10.20.0.0/16 prefix in Hub-A's defaultRouteTable is caused by an inter-hub propagation bug that requires opening a Microsoft support ticket.
D) The 10.30.0.0/16 route present in Hub-A's defaultRouteTable represents a different prefix from the VNet-DB prefix, indicating that the address space configured in the VNet-DB connection at Hub-B is incorrect or does not match the actual VNet prefix.
Scenario 4 — Diagnostic Sequence
An engineer receives the following report: traffic from branches connected via Site-to-Site VPN to a Virtual WAN hub is correctly reaching the hub, but is not reaching VMs in a spoke VNet connected to the same hub. The hub does not have Routing Intent enabled and there are no NVAs in the environment.
The following investigation steps are available, out of order:
- Verify if the branch VPN connection is propagating routes to the Route Table to which the spoke VNet connection is associated.
- Confirm if the spoke VNet connection status in the hub is Succeeded and if peering is provisioned correctly.
- Verify if there are learned routes from the branch prefix in the Route Table associated to the spoke VNet connection.
- Execute an end-to-end connectivity test (e.g., ping or traceroute) from a VM in the branch to confirm where traffic stops.
- Check if the Route Table associated to the spoke VNet connection contains the return route to the branch prefix.
What is the correct investigation sequence?
A) 4 → 2 → 3 → 1 → 5
B) 2 → 4 → 1 → 3 → 5
C) 4 → 2 → 1 → 3 → 5
D) 2 → 3 → 1 → 4 → 5
Answer Key and Explanations
Answer Key — Scenario 1
Answer: B
The decisive clue is in the configuration table: VNet-Shared only propagates to defaultRouteTable, and VNet-Prod is associated with RT-Prod. Since VNet-Prod only learns what is propagated to RT-Prod, and VNet-Shared never propagates to RT-Prod, the VNet-Shared prefix never appears in the effective routing table of VNet-Prod. The result is the absence of a route to the destination, which causes silent packet dropping.
The irrelevant information in the scenario is the NSG status. The NSGs were not changed and the security team confirmed the rules: this data exists to divert reasoning to layer 4, but the problem is routing at the hub control layer.
Distractor C describes the inverse impact: VNet-Prod propagation to RT-Prod affects what others learn about VNet-Prod, not what VNet-Prod learns about others. Distractor D is technically possible in theory, but contradicts the information that the status is Succeeded, which in Virtual WAN indicates complete peering provisioning.
Answer Key — Scenario 2
Answer: B
The critical restriction is the 99.9% SLA and the incident already ongoing for 22 minutes, combined with the fact that the team has permission to revert the Routing Intent. Removing the Routing Intent is the action that immediately restores the previous routing behavior for all 40 connections and for VPN branches, without depending on a permission that the team does not have (Firewall Manager).
Distractor A ignores the active operational impact: waiting is acceptable only when there is no service degradation, which is not the case. Distractor C is technically invalid because creating manual static routes coexisting with an enabled Routing Intent can generate unpredictable routing conflicts and does not resolve the root cause. Distractor D assumes the team has action permission on Firewall Manager and that the operation is safe and fast, none of which is confirmed by the scenario.
Answer Key — Scenario 3
Answer: A
The command output shows that Hub-A's defaultRouteTable contains only two prefixes: VNet-App itself and 10.30.0.0/16, which does not correspond to the VNet-DB prefix (10.20.0.0/16). The VNet-DB prefix simply does not exist in Hub-A's table.
Inter-hub propagation logic works as follows: Hub-B only announces to Hub-A the prefixes that were propagated to its defaultRouteTable. If the VNet-DB connection at Hub-B is not propagating to defaultRouteTable, Hub-B does not have the prefix to announce to Hub-A.
The irrelevant information is the colleague's suggestion: it correctly describes the symptom (missing prefix in Hub-A), but does not point to the cause. The symptom is already visible in the command output; what matters is why the prefix did not arrive.
Distractor D is the most dangerous: it proposes that the address space is wrong in Hub-B, which would divert the engineer to verify the VNet itself, when the cause is in the connection propagation configuration.
Answer Key — Scenario 4
Answer: A
The correct sequence is: 4 → 2 → 3 → 1 → 5
Progressive diagnostic reasoning starts from the observable symptom to control layers:
- Step 4 first: confirm where traffic actually stops before assuming any hypothesis. A traceroute reveals if traffic even leaves the branch, reaches the hub, or stops before the spoke VNet.
- Step 2: confirm that the spoke VNet connection is provisioned correctly. If peering is not active, no route will work regardless of configuration.
- Step 3: verify if the Route Table associated to the spoke VNet contains routes to the branch prefix. If there is no route, the hub drops traffic before forwarding it.
- Step 1: identify if the VPN connection is propagating to the correct Route Table. This is the most likely cause if the route is missing in step 3.
- Step 5: verify the return route, which is relevant to confirm bidirectionality after the other steps.
Distractor B inverts steps 4 and 2, starting with connection verification before confirming observed network behavior, which can lead to hasty conclusions about the cause. Distractor D completely omits the end-to-end connectivity test, removing the empirical anchor of the diagnosis.
Troubleshooting Tree: Configure Virtual Hub Routing
Legend:
| Color | Node Type |
|---|---|
| Dark blue (navy) | Initial symptom, investigation entry point |
| Blue | Diagnostic question, binary or verifiable decision |
| Red | Identified cause or direct corrective action |
| Orange | Validation or intermediate verification before concluding |
To use this tree in a real incident, always start with the root node describing the connectivity loss symptom. Answer each question based on what you observe in the portal or via CLI, never based on assumptions. Each answer eliminates a set of hypotheses and leads to the next verification level. When you reach a red node, you have the identified cause and recommended action. When you reach an orange node, execute the described verification before concluding the diagnosis, as it may reveal a different path in the tree.