An enterprise designs a hub-and-spoke virtual network topology in Azure to connect cloud w… — Microsoft Azure Solutions Architect (AZ-305)

An enterprise designs a hub-and-spoke virtual network topology in Azure to connect cloud workloads with their on-premises datacenter. The hub virtual network, `vnet-hub-core` ( $10.100.0.0/16$ ), contains an Azure Firewall deployed at $10.100.4.4$ and an ExpressRoute virtual network gateway. The spoke virtual network, `vnet-spoke-prod` ( $10.110.0.0/16$ ), contains a subnet named `snet-app` ( $10.110.1.0/24$ ). Virtual network peering is established between `vnet-hub-core` and `vnet-spoke-prod` with gateway transit enabled. The ExpressRoute gateway dynamically learns the on-premises database subnet prefix $172.20.100.0/24$ and the summary prefix $172.16.0.0/12$ via BGP. A custom Route Table is associated with `snet-app` and has gateway route propagation enabled. To ensure all traffic to the on-premises environment is inspected by the firewall, a User-Defined Route (UDR) is added with a destination prefix of $172.16.0.0/12$ and next hop address of $10.100.4.4$ . During auditing, network administrators discover that traffic destined for the database servers at $172.20.100.50$ bypasses the Azure Firewall and is sent directly to the ExpressRoute gateway. Which of the following explains this behavior?

The dynamically learned BGP route for $172.20.100.0/24$ has a longer prefix match than the User-Defined Route for $172.16.0.0/12$ , causing Azure to prioritize the BGP route.Answer
B
User-Defined Routes are always evaluated after BGP-propagated routes when there is any overlap in the destination IP address ranges.
C
Enabling gateway route propagation on the route table automatically disables User-Defined Routes that overlap with any BGP-learned routes.
D
The VNet peering transit configuration is missing the 'Allow gateway transit' setting on the spoke virtual network, forcing BGP routes to bypass the UDR.

Answer

The dynamically learned BGP route for

172.20.100.0/24

has a longer prefix match than the User-Defined Route for

172.16.0.0/12

, causing Azure to prioritize the BGP route.

In Azure routing, Longest Prefix Match (LPM) is the primary algorithm used to select a route. The destination IP

172.20.100.50

matches both the User-Defined Route (

172.16.0.0/12

) and the BGP-learned route (

172.20.100.0/24

). Because the BGP route has a longer prefix length (/24 vs. /12), Azure selects it. The rule where UDRs take precedence over BGP is only applied as a tie-breaker when the prefix lengths are identical.

Step-by-Step Solution

Analyze the destination IP address of the database traffic.

The destination is

172.20.100.50

, which matches both the UDR prefix

172.16.0.0/12

and the BGP prefix

172.20.100.0/24

Identifying all matching routes in the subnet's routing table is the first step in determining path selection.

Evaluate the routes based on Azure's Longest Prefix Match (LPM) rule.

The prefix

172.20.100.0/24

has a length of 24, which is longer (more specific) than the UDR prefix

172.16.0.0/12

with a length of 12.

Azure always evaluates prefix length first; a longer prefix match takes precedence over any other route selection criteria, including route source type.

Determine the routing outcome.

Azure selects the /24 BGP route, directing traffic directly to the ExpressRoute gateway and bypassing the firewall next hop specified in the /12 UDR.

This explains the bypass behavior observed by the network administrators.

Key Concept

Azure route selection order and Longest Prefix Match (LPM)

Question

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Topics

More questions from this topic