An enterprise is designing a hub-and-spoke network topology in Azure to support dynamic ro… — Microsoft Azure Solutions Architect (AZ-305)

An enterprise is designing a hub-and-spoke network topology in Azure to support dynamic routing between on-premises branch offices and Azure resources. The topology consists of the following:

* A hub virtual network named `vnet-use-hub` ( $10.100.0.0/16$ ) containing:
* `GatewaySubnet` ( $10.100.0.0/24$ ) with an ExpressRoute gateway.
* `RouteServerSubnet` ( $10.100.1.0/24$ ) hosting an Azure Route Server.
* `subnet-nva` ( $10.100.2.0/24$ ) hosting a pair of SD-WAN Network Virtual Appliances (NVAs) that establish BGP sessions with the Azure Route Server.
* A spoke virtual network named `vnet-prod-spoke` ( $10.101.0.0/16$ ) containing application workloads in `subnet-app` ( $10.101.1.0/24$ ).

A virtual network peering connects `vnet-use-hub` and `vnet-prod-spoke` with gateway transit enabled on the hub side.

The design must satisfy these requirements:
* Application workloads in `subnet-app` must dynamically learn and route traffic to on-premises branch offices via the SD-WAN NVAs.
* You must minimize manual administrative effort by avoiding static user-defined routes (UDRs) in the spoke virtual network.
* Direct traffic between `vnet-prod-spoke` and the hub VNet `vnet-use-hub` must be maintained without routing through the SD-WAN NVAs to ensure optimal latency.
* The Azure Route Server must exchange routing information between the SD-WAN NVAs and the ExpressRoute gateway.

Which two actions should you include in the design?

Enable branch-to-branch routing on the Azure Route Server.Answer
Enable the 'Use the remote virtual network's gateway or Route Server' option on the peering from `vnet-prod-spoke` to `vnet-use-hub`.Answer
C
Configure a User Defined Route (UDR) on `subnet-app` with the address prefix `10.100.0.0/16` and next hop type `Virtual Appliance` pointing to the SD-WAN NVAs.
D
Configure a User Defined Route (UDR) on `subnet-app` with the address prefix `10.101.0.0/16` and next hop type `VnetLocal`.
E
Enable the 'Use the remote virtual network's gateway or Route Server' option on the peering from `vnet-use-hub` to `vnet-prod-spoke`.

Answer

Enable branch-to-branch routing on the Azure Route Server, and enable the 'Use the remote virtual network's gateway or Route Server' option on the peering from the spoke virtual network to the hub virtual network.

The correct configurations are enabling branch-to-branch routing on the Azure Route Server and configuring the peering from the spoke to the hub to use the remote gateway or Route Server. Enabling branch-to-branch routing is necessary for the Azure Route Server to propagate dynamically learned routes between the ExpressRoute gateway and the SD-WAN Network Virtual Appliances (NVAs). Enabling the 'Use the remote virtual network's gateway or Route Server' option on the peering from the spoke to the hub allows the spoke virtual network to dynamically receive the routes advertised by the Route Server. Direct traffic between the spoke and the hub is maintained because local virtual network and peered virtual network system routes are prioritized over dynamic BGP routes (which typically target on-premises address spaces).

Step-by-Step Solution

Configure the virtual network peering from the spoke virtual network to the hub virtual network to allow route consumption.

Setting 'Use the remote virtual network's gateway or Route Server' (useRemoteGateways = true) on the spoke-to-hub peering enables the spoke virtual network to dynamically learn routes from the Azure Route Server in the hub.

This satisfies the requirement to dynamically propagate on-premises routes to the spoke application subnet without configuring static user-defined routes.

Enable branch-to-branch routing on the Azure Route Server.

The Route Server will propagate BGP routes between the ExpressRoute gateway and the SD-WAN Network Virtual Appliances.

This allows on-premises branch offices connected via SD-WAN and datacenters connected via ExpressRoute to exchange routing information.

Validate local VNet and peering system routes to ensure latency requirements are met.

Default system routes for the peered hub virtual network (

10.100.0.0/16

) remain active on the spoke, ensuring direct spoke-to-hub communication.

Adding a static UDR for the hub range would override the system route and direct local traffic to the NVAs, violating latency goals.

Key Concept

Dynamic routing propagation and transit path selection using Azure Route Server in a hub-and-spoke topology.

Question

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Topics

More questions from this topic