Examkin

Question

Difficulty: HardConfigure Virtual Network Peering

An Azure administrator configures a hub-and-spoke network topology. The hub virtual network is named VNet-Hub (10.10.0.0/1610.10.0.0/16) and contains an active VPN gateway. Two spoke virtual networks, named VNet-Spoke1 (10.20.0.0/1610.20.0.0/16) and VNet-Spoke2 (10.30.0.0/1610.30.0.0/16), have virtual machines deployed in their respective subnets. The administrator configures bidirectional virtual network peering between VNet-Spoke1 and VNet-Hub, enabling 'Allow gateway transit' on the VNet-Hub side and 'Use remote gateways' on the VNet-Spoke1 side. Similarly, bidirectional virtual network peering is configured between VNet-Spoke2 and VNet-Hub, enabling 'Allow gateway transit' on the VNet-Hub side and 'Use remote gateways' on the VNet-Spoke2 side. There is no direct peering between VNet-Spoke1 and VNet-Spoke2, and no network virtual appliances (NVAs) are deployed.

Statement: Under this configuration, a virtual machine in VNet-Spoke1 can communicate directly with a virtual machine in VNet-Spoke2 by routing traffic through the VNet-Hub gateway.

Answer: Answer

Answer

The statement is false. Virtual network peering in Azure is non-transitive, and configuring gateway transit does not enable routing of traffic between two peered spoke networks through the hub gateway.
The statement is false because Azure virtual network peering is strictly non-transitive. Configuring 'Allow gateway transit' and 'Use remote gateways' allows the spokes to share the hub's VPN gateway to communicate with on-premises networks, but it does not route traffic between spokes. Spoke-to-spoke communication requires direct peering between the spokes or a custom routing solution using a Network Virtual Appliance (NVA) and User-Defined Routes (UDRs).

Step-by-Step Solution

1
Analyze the network topology and peering connections.
VNet-Spoke1 is peered to VNet-Hub, and VNet-Spoke2 is peered to VNet-Hub. There is no direct peering between VNet-Spoke1 and VNet-Spoke2.
To determine the available physical or logical network paths.
2
Evaluate the transit behavior of Azure Virtual Network Peering.
Peering is non-transitive. Traffic from VNet-Spoke1 cannot transit through VNet-Hub to reach VNet-Spoke2 unless an NVA or Azure Firewall is deployed in VNet-Hub to route the traffic.
To determine if hub-and-spoke peering enables automatic spoke-to-spoke connectivity.
3
Determine the function of the 'Allow gateway transit' and 'Use remote gateways' settings.
These settings only permit peered virtual networks to share a VPN or ExpressRoute gateway in VNet-Hub to reach on-premises networks; they do not facilitate routing between spokes.
To assess if the gateway configuration overrides the non-transitive nature of peering for inter-spoke traffic.

Key Concept

Azure Virtual Network Peering non-transitivity and gateway transit configuration.
Rate this question

Topics

Configure Virtual Network Peering

More questions from this topic