Question

Difficulty: Very hardVirtual Network Connectivity and Routing

An enterprise is designing a high-availability hybrid network topology in Azure to support dynamic routing and traffic inspection. The design includes the following components:

* A hub virtual network named `vnet-hub-useast` (10.10.0.0/1610.10.0.0/16) containing an Azure Route Server in the `RouteServerSubnet` (10.10.1.0/2410.10.1.0/24) and two active-active Network Virtual Appliances (NVAs) in `subnet-nva` (10.10.2.0/2410.10.2.0/24).
* A spoke virtual network named `vnet-spoke-prod` (10.20.0.0/1610.20.0.0/16) containing `subnet-web` (10.20.1.0/2410.20.1.0/24).
* A spoke virtual network named `vnet-spoke-data` (10.30.0.0/1610.30.0.0/16) containing `subnet-db` (10.30.1.0/2410.30.1.0/24).

The NVAs establish BGP sessions with the Azure Route Server. The Route Server is configured with Branch-to-Branch enabled to exchange routes between the NVAs and an ExpressRoute Gateway in the hub.

You need to design a routing solution that meets the following requirements:
1. Subnets in `vnet-spoke-prod` and `vnet-spoke-data` must dynamically receive the on-premises routes advertised by the NVAs via BGP.
2. All spoke-to-spoke traffic (between `vnet-spoke-prod` and `vnet-spoke-data`) must be directed through the NVAs for security inspection.
3. Local traffic within `vnet-spoke-prod` (destined within 10.20.0.0/1610.20.0.0/16) must not be sent to the NVAs.

Which two configurations should you include in the design? (Select two.)

  1. Configure a User-Defined Route (UDR) on the route table for subnet-web with the address prefix 10.30.0.0/1610.30.0.0/16 and the next hop set to the internal load balancer IP of the NVAs.Answer
  2. Configure virtual network peering between vnet-hub-useast and vnet-spoke-prod with 'Allow gateway transit' enabled on the hub side and 'Use the remote virtual network's gateway or Route Server' enabled on the spoke side.Answer
  3. C
    Configure a User-Defined Route (UDR) on the route table for subnet-web with the address prefix 0.0.0.0/00.0.0.0/0 and the next hop set to the internal load balancer IP of the NVAs.
  4. D
    Configure a User-Defined Route (UDR) on the route table for subnet-web with the address prefix 10.20.0.0/1610.20.0.0/16 and the next hop set to the internal load balancer IP of the NVAs.

Answer

To meet the requirements, you must configure virtual network peering with 'Allow gateway transit' enabled on the hub side and 'Use the remote virtual network's gateway or Route Server' enabled on the spoke side, and configure a User-Defined Route (UDR) on the route table for subnet-web with the address prefix 10.30.0.0/16 and the next hop set to the internal load balancer IP of the NVAs.
The design requires two key elements: first, ensuring the spoke virtual networks can dynamically receive BGP routes from the Azure Route Server. This is achieved by enabling gateway transit on the hub virtual network peering and using the remote virtual network's gateway or Route Server on the spoke side. Second, spoke-to-spoke traffic must be forced through the NVAs. Because the automatic peering system route is 10.30.0.0/16, a UDR matching that exact prefix (10.30.0.0/16) must be configured on the spoke route table. Since UDRs have priority over system routes of the same prefix length, this forces the traffic to the NVAs' internal load balancer.

Step-by-Step Solution

1
Determine how to propagate dynamically learned routes from the Azure Route Server in the hub to the spoke virtual networks.
Identify that default virtual network peering does not transit routes. You must enable 'Allow gateway transit' on the hub peering and 'Use the remote virtual network's gateway or Route Server' on the spoke peering.
This establishes transit capability, allowing the Azure Route Server to inject BGP routes directly into the spoke subnet route tables.
2
Analyze spoke-to-spoke routing behavior under default system routes.
A system-defined peering route is automatically created for 10.30.0.0/16 with the next hop set to VNet Peering.
Traffic destined for the peered spoke will use this route by default.
3
Evaluate the impact of using a default route (0.0.0.0/0) to inspect traffic.
A route of 0.0.0.0/0 is overridden by the more specific system route of 10.30.0.0/16 under Longest Prefix Match (LPM).
To intercept spoke-to-spoke traffic, the UDR must have a prefix equal to or more specific than the peered virtual network range.
4
Assess the impact of overriding the local virtual network prefix.
Overriding 10.20.0.0/16 with the next hop NVA breaks local routing and causes routing loops.
Local traffic must remain untouched to route via the default 'Virtual Network' system route.

Key Concept

Azure Route Server transit and route table precedence rules under Longest Prefix Match (LPM)
Estimated Time:3m 0s
Rate this question