An enterprise is designing a hub-and-spoke network topology in Azure with the following re… — Microsoft Azure Solutions Architect (AZ-305)

An enterprise is designing a hub-and-spoke network topology in Azure with the following resource configurations:

* Hub VNet (`vnet-hub-weur`): Address space $10.200.0.0/16$ . Contains an Azure VPN Gateway in the `GatewaySubnet` and a Network Virtual Appliance (NVA) at IP $10.200.1.4$ in `subnet-nva`.
* Spoke A VNet (`vnet-prod-weur`): Address space $10.201.0.0/16$ . Contains application servers in `subnet-app` ( $10.201.1.0/24$ ).
* Spoke B VNet (`vnet-shared-weur`): Address space $10.202.0.0/16$ . Contains shared services in `subnet-data` ( $10.202.1.0/24$ ).

Virtual network peering is established between `vnet-prod-weur` and `vnet-hub-weur`, and between `vnet-shared-weur` and `vnet-hub-weur`. There is no direct peering between the two spokes.

A route table named `rt-prod-app` is associated with `subnet-app` and has the following User Defined Routes (UDRs) configured:
* Destination: $0.0.0.0/0$ , Next hop: Virtual appliance ( $10.200.1.4$ )
* Destination: $10.0.0.0/8$ , Next hop: Virtual network gateway

The on-premises network uses the address space $10.0.0.0/8$ . All traffic from `subnet-app` to Spoke B must go through the NVA for inspection. During testing, administrators observe that servers in `subnet-app` can reach the internet and on-premises resources, but cannot communicate with `subnet-data` in Spoke B.

Which of the following routing configurations will resolve the connectivity issue to Spoke B while maintaining all other security and routing requirements?

Add a route to `rt-prod-app` with the destination $10.202.0.0/16$ and the next hop set to the Virtual appliance ( $10.200.1.4$ ).Cevap
B
Change the next hop of the $10.0.0.0/8$ route in `rt-prod-app` to the Virtual appliance ( $10.200.1.4$ ).
C
Add a route to `rt-prod-app` with the destination $10.200.0.0/16$ and the next hop set to the Virtual appliance ( $10.200.1.4$ ).
D
Enable gateway transit on the peering connection between `vnet-hub-weur` and `vnet-prod-weur` and configure the spoke peering to use the remote virtual network's gateway.

Cevap

Add a route to the route table with the destination of the Spoke B address space (

10.202.0.0/16

) and the next hop set to the Virtual appliance (

10.200.1.4

Adding a route for the Spoke B address space (

10.202.0.0/16

) with the next hop set to the NVA (

10.200.1.4

) resolves the issue. Because Azure uses the Longest Prefix Match (LPM) algorithm, the more specific

/16

route for Spoke B takes precedence over the broader

10.0.0.0/8

route (which points to the Virtual network gateway). This ensures that traffic destined for Spoke B is routed through the NVA for security inspection, while traffic to on-premises (

10.0.0.0/8

excluding the Spoke B range) still goes to the Virtual network gateway.

Adım Adım Çözüm

Analyze the destination IP space for Spoke B traffic.

The destination address space for Spoke B is

10.202.0.0/16

We need to understand what IP ranges are matched when a packet is sent to Spoke B.

Evaluate the routing table rules using the Longest Prefix Match (LPM) algorithm.

The destination

10.202.x.x

matches both

0.0.0.0/0

and

10.0.0.0/8

. Since

10.0.0.0/8

is a longer prefix match than

0.0.0.0/0

(8 bits vs 0 bits), Azure routes this traffic to the Virtual network gateway.

This explains why the traffic is currently failing to reach the NVA.

Determine if any system routes override this behavior.

No system route exists for

10.202.0.0/16

because VNet peering is non-transitive. The only system routes are for the local VNet (

10.201.0.0/16

) and the directly peered Hub VNet (

10.200.0.0/16

Confirming that Azure does not automatically insert a route for indirect spokes.

Formulate a more specific UDR to redirect the traffic to the NVA.

Add a route for

10.202.0.0/16

pointing to the NVA (

10.200.1.4

). This

/16

route is more specific than the

/8

route, ensuring Spoke B traffic is sent to the NVA, while on-premises traffic (matching the rest of

10.0.0.0/8

) still goes to the gateway.

This solves the problem by overriding the broad UDR for Spoke B destinations only.

Anahtar Kavram

Azure routing precedence and Longest Prefix Match (LPM) in a hub-and-spoke topology.

Alternatif Yöntem

Instead of adding a static UDR for the entire Spoke B range, you could also configure Azure Route Server in the Hub VNet to dynamically exchange routes between the NVA and the spoke VNets, provided the NVA supports BGP and is configured to advertise the Spoke B prefix to Route Server.

Tahmini Süre:2m 0s

Soru

Cevap

Adım Adım Çözüm

Anahtar Kavram

Sık Yapılan Hatalar

Alternatif Yöntem

Konular

Bu konudan daha fazla soru