An enterprise is designing a hub-and-spoke network topology in Azure for a multi-tier appl… — Microsoft Azure Solutions Architect (AZ-305)

An enterprise is designing a hub-and-spoke network topology in Azure for a multi-tier application. The architecture includes:

* A hub virtual network named `vnet-prod-hub` with an address space of $10.150.0.0/16$ .
* `AzureFirewallSubnet` ( $10.150.1.0/24$ ) containing an Azure Firewall with private IP $10.150.1.4$ .
* `GatewaySubnet` ( $10.150.2.0/24$ ) containing a Virtual Network Gateway connected to on-premises via ExpressRoute.
* A spoke virtual network named `vnet-prod-spoke` with an address space of $10.160.0.0/16$ .
* Subnet `snet-compute` ( $10.160.10.0/24$ ) hosting virtual machines.

The hub and spoke virtual networks are peered. The peering is configured to allow gateway transit on the hub and use remote gateways on the spoke.

The security requirements are:
1. All traffic from `snet-compute` destined for the internet must be routed through the Azure Firewall.
2. All traffic from `snet-compute` destined for the on-premises network ( $172.16.0.0/12$ ) must be routed through the Virtual Network Gateway.
3. All traffic from `snet-compute` destined for the hub virtual network (`vnet-prod-hub`) must be routed through the Azure Firewall for security inspection.

To implement these requirements, a network architect creates a route table named `rt-spoke-routing` with the following user-defined routes (UDRs):
* Route 1: $0.0.0.0/0$ $\rightarrow$ Next hop: Virtual appliance ( $10.150.1.4$ )
* Route 2: $10.150.0.0/16$ $\rightarrow$ Next hop: Virtual appliance ( $10.150.1.4$ )

The architect associates `rt-spoke-routing` with the `snet-compute` subnet. To ensure symmetric inspection for return traffic, the architect also associates the same `rt-spoke-routing` route table with the `AzureFirewallSubnet`.

During post-deployment validation, VMs in `snet-compute` can successfully access the internet, but they cannot establish any connections to resources in the hub virtual network, and the Azure Firewall fails to pass traffic to the Gateway Subnet.

Which configuration change should the architect perform to resolve the connectivity issue while satisfying all design requirements?

A
Modify the `rt-spoke-routing` route table to change the next hop for the $10.150.0.0/16$ prefix to Virtual Network.
Remove the association of the `rt-spoke-routing` route table from the `AzureFirewallSubnet`, and allow the firewall to use default system routes for local hub destinations.Cevap
C
Disable BGP route propagation on the `rt-spoke-routing` route table associated with the `AzureFirewallSubnet`.
D
Create a separate route table for the `AzureFirewallSubnet` and add a UDR for $10.150.2.0/24$ pointing to the Virtual Network Gateway.

Cevap

Remove the association of the `rt-spoke-routing` route table from the `AzureFirewallSubnet`, allowing the firewall to rely on default system routes for local hub destinations.

The correct option is the one suggesting to remove the association of the route table from the firewall subnet. In Azure, User-Defined Routes (UDRs) override system-defined routes of the same prefix length. By applying the route table containing the

10.150.0.0/16

prefix (pointing to the firewall itself as a virtual appliance) to the firewall's own subnet, a routing loop is created. Any packet the firewall attempts to forward to other subnets in the hub virtual network matches the UDR and is routed back to the firewall. Removing this association allows the firewall to use the default system route (

10.150.0.0/16

-> Virtual Network) to successfully route traffic to other hub subnets, while the spoke still routes hub-bound traffic to the firewall.

Adım Adım Çözüm

Analyze the route table configuration and its associations.

The route table `rt-spoke-routing` contains a route for

10.150.0.0/16

pointing to the firewall at

10.150.1.4

. This route table is associated with both the spoke subnet `snet-compute` and the hub `AzureFirewallSubnet`.

Understanding which subnets are bound to the routing rules determines how next hops are resolved for transit traffic.

Determine the impact of the UDR on the firewall's own subnet.

The firewall subnet resides within the

10.150.0.0/16

VNet range. When the firewall tries to forward traffic to a hub destination (like the gateway at

10.150.2.x

), the matching route is the UDR

10.150.0.0/16

pointing to

10.150.1.4

Azure evaluates User-Defined Routes (UDRs) over default system routes of the same prefix length, which overrides the local VNet system route.

Identify the routing loop.

The next hop for the destination in the hub is resolved to the firewall itself (

10.150.1.4

), creating a loop where the packet repeatedly routes back to the firewall and is eventually dropped.

This explains why VMs in the spoke cannot communicate with resources in the hub and why firewall traffic fails to reach the gateway.

Select the correct remediation strategy.

Dissociate the `rt-spoke-routing` route table from the `AzureFirewallSubnet`. The firewall will now use default system routing, which contains a system route for

10.150.0.0/16

pointing to 'Virtual Network'.

This allows the firewall to successfully forward traffic to other hub subnets while maintaining the required traffic inspection on the spoke subnet where the route table remains associated.

Anahtar Kavram

Azure User Defined Routes (UDR) precedence and routing loops in firewall subnets.

Tahmini Süre:3m 0s

Soru

Cevap

Adım Adım Çözüm

Anahtar Kavram

Sık Yapılan Hatalar

Konular

Bu konudan daha fazla soru