An organization has a hub-and-spoke network topology in Azure. The hub virtual network, `v… — Microsoft Azure Solutions Architect (AZ-305)

An organization has a hub-and-spoke network topology in Azure. The hub virtual network, `vnet-weur-hub` ( $10.200.0.0/16$ ), contains a Network Virtual Appliance (NVA) at IP address $10.200.1.4$ in a subnet named `snet-nva`. The spoke virtual network, `vnet-weur-spoke1` ( $10.201.0.0/16$ ), contains a subnet named `snet-app` ( $10.201.1.0/24$ ).

To meet security compliance, you associate a route table named `rt-spoke-app` with `snet-app`. The route table contains the following user-defined routes (UDRs):
* Route 1: Prefix $10.200.0.0/16$ , Next hop: Virtual Appliance ( $10.200.1.4$ )
* Route 2: Prefix $10.201.0.0/16$ , Next hop: Virtual Appliance ( $10.200.1.4$ )
* Route 3: Prefix $0.0.0.0/0$ , Next hop: Virtual Appliance ( $10.200.1.4$ )

After applying `rt-spoke-app`, virtual machines in `snet-app` cannot communicate with other virtual machines located in the same spoke virtual network, `vnet-weur-spoke1`.

You need to restore intra-spoke communication while ensuring that all internet-bound and hub-bound traffic continues to be routed through the NVA.

What should you do?

Remove the route with the $10.201.0.0/16$ prefix from the route table.Cevap
B
Change the next hop type of the route with the $10.201.0.0/16$ prefix to Virtual Network Gateway.
C
Change the address prefix of the route pointing to the NVA from $10.201.0.0/16$ to $10.201.1.0/24$ .
D
Associate a Network Security Group (NSG) to `snet-app` that contains individual inbound and outbound security rules for every virtual machine IP address in the spoke VNet instead of using Service Tags.

Cevap

Remove the route with the

10.201.0.0/16

prefix from the route table.

Removing the route with the

10.201.0.0/16

prefix allows the system-defined route for the local virtual network to take over. Azure automatically creates a system route for the local VNet address space with the next hop type 'Virtual Network'. Since User-Defined Routes (UDRs) override system routes for the same prefix, the custom route was forcing local traffic to the NVA. Removing this route restores local communication. The remaining routes for

10.200.0.0/16

and

0.0.0.0/0

ensure that hub-bound and internet-bound traffic continue to route through the NVA.

Adım Adım Çözüm

Analyze the precedence of Azure routing tables and identify why intra-spoke communication failed.

Azure evaluates routes based on longest prefix match (LPM). However, User-Defined Routes (UDRs) always override system-defined routes of the same prefix. The custom route for

10.201.0.0/16

(Route 2) overrides the default system route for the local virtual network (next hop: Virtual Network).

Understanding why traffic is incorrectly redirected is the first step in troubleshooting virtual network routing.

Determine the impact of removing the custom route for

10.201.0.0/16

Removing the UDR for

10.201.0.0/16

allows the default system route for the local VNet to handle intra-spoke traffic, directing it straight to the local virtual network next hop without going to the NVA.

This restores local connectivity since local traffic no longer hairpins through the NVA.

Verify that the remaining requirements (routing hub-bound and internet-bound traffic through the NVA) are still met.

Traffic destined for the hub virtual network matches the UDR for

10.200.0.0/16

(Route 1), and internet-bound traffic matches the default UDR for

0.0.0.0/0

(Route 3). Both routes direct traffic to the NVA at

10.200.1.4

Ensures compliance with the security requirements while restoring local spoke traffic flow.

Anahtar Kavram

Azure routing priority and the override of local system routes by User-Defined Routes (UDRs).

Tahmini Süre:1m 30s

Soru

Cevap

Adım Adım Çözüm

Anahtar Kavram

Sık Yapılan Hatalar

Konular

Bu konudan daha fazla soru