An enterprise is designing a hub-and-spoke virtual network topology in Azure. The hub virt… — Microsoft Azure Solutions Architect (AZ-305)

An enterprise is designing a hub-and-spoke virtual network topology in Azure. The hub virtual network, `vnet-hub-weur` ( $10.200.0.0/16$ ), contains a Virtual Network Gateway connected to an on-premises network. A spoke virtual network, `vnet-spoke-prod` ( $10.201.0.0/16$ ), contains a workload subnet named `snet-app` ( $10.201.1.0/24$ ). A pair of network virtual appliances (NVAs) is deployed in the hub and sits behind an internal load balancer at $10.200.4.100$ .

The Virtual Network Gateway receives BGP route advertisements from on-premises, including a summary route of $172.16.0.0/12$ and a specific database subnet prefix of $172.16.50.0/24$ . To inspect all on-premises bound traffic, you associate a route table named `rt-spoke-app` with the `snet-app` subnet and add a user-defined route (UDR) for $172.16.0.0/12$ pointing to the load balancer at $10.200.4.100$ . Gateway route propagation is enabled on `rt-spoke-app`.

During testing, you observe that traffic from `snet-app` to the database tier ( $172.16.50.10$ ) bypasses the NVAs and goes directly to the Virtual Network Gateway. Which action should you recommend to ensure all on-premises bound traffic is inspected by the NVAs?

Disable gateway route propagation on the `rt-spoke-app` route table.Cevap
B
Create a UDR for $172.16.50.0/24$ pointing to the Virtual Network Gateway in the `rt-spoke-app` route table.
C
Change the address prefix of the existing UDR in `rt-spoke-app` to $172.16.0.0/16$ .
D
Add a new UDR for $0.0.0.0/0$ pointing to the NVA load balancer in the `rt-spoke-app` route table.

Cevap

Disable gateway route propagation on the `rt-spoke-app` route table.

Disabling gateway route propagation on the spoke subnet's route table prevents the BGP-learned routes from on-premises from being dynamically injected into the spoke subnet. This removes the specific BGP route for the database tier. Consequently, traffic to the database subnet matches the user-defined route for the summarized prefix, forcing it to route through the network virtual appliance (NVA) first.

Adım Adım Çözüm

Analyze how BGP routes propagate to the spoke subnet.

Since gateway route propagation is enabled, the BGP routes

172.16.0.0/12

and

172.16.50.0/24

are dynamically added to the subnet's effective route table with the next hop set to Virtual Network Gateway.

This establishes the baseline routing table of the spoke subnet before user overrides.

Evaluate the route selection logic for database traffic (

172.16.50.10

The destination matches both the BGP route (

172.16.50.0/24

) and the UDR (

172.16.0.0/12

). In Azure, routes are evaluated using the Longest Prefix Match (LPM) rule. Because a /24 prefix is longer (more specific) than a /12 prefix, the BGP route takes precedence over the UDR, directing traffic directly to the gateway.

This identifies why the current routing configuration fails to meet the inspection requirement.

Determine the configuration change needed to force traffic through the NVA.

Disabling gateway route propagation on the spoke's route table removes the propagated BGP routes from its effective route table. Traffic to the on-premises database tier will then fall back to the UDR for

172.16.0.0/12

, sending it to the NVA load balancer. The NVAs, located in the hub, still have route propagation enabled and can forward the traffic to the gateway after inspection.

This establishes the correct architectural remediation path.

Anahtar Kavram

Azure Virtual Network routing precedence, BGP route propagation, and transit NVA design

Soru

Cevap

Adım Adım Çözüm

Anahtar Kavram

Sık Yapılan Hatalar

Konular

Bu konudan daha fazla soru