An organization deploys three virtual networks in the East US region: * **VNet-Hub** (10.2… — Microsoft Azure Administrator (AZ-104)

An organization deploys three virtual networks in the East US region:

* VNet-Hub ( $10.200.0.0/16$ ): Contains a virtual machine named VM-NVA ( $10.200.1.4$ ) in the firewall subnet.
* VNet-Spoke1 ( $10.201.0.0/16$ ): Contains a virtual machine named VM-Spoke1 in the web subnet.
* VNet-Spoke2 ( $10.202.0.0/16$ ): Contains a virtual machine named VM-Spoke2 in the database subnet.

Bidirectional virtual network peering is established between VNet-Hub and VNet-Spoke1, and between VNet-Hub and VNet-Spoke2. All peering connections currently use default settings:
* Traffic to remote virtual network: Allow
* Traffic forwarded from remote virtual network: Block
* Virtual network gateway: None

A route table is associated with the web subnet of VNet-Spoke1 with a route to ` $10.202.0.0/16$ ` via Next Hop Type `Virtual appliance` at IP address ` $10.200.1.4$ `. A route table is also associated with the database subnet of VNet-Spoke2 with a route to ` $10.201.0.0/16$ ` via Next Hop Type `Virtual appliance` at IP address ` $10.200.1.4$ `. IP forwarding is enabled on the Azure network interface (NIC) and within the operating system of VM-NVA.

You need to ensure that VM-Spoke1 can communicate with VM-Spoke2 through VM-NVA.

Which of the following configurations should you perform?

Change the 'Traffic forwarded from remote virtual network' setting to Allow on the peering connections between VNet-Hub and both spoke virtual networks.Answer
B
Enable the 'Use remote gateways' option on the peering connections in VNet-Spoke1 and VNet-Spoke2, and enable 'Allow gateway transit' on VNet-Hub.
C
Modify the route tables in VNet-Spoke1 and VNet-Spoke2 to change the Next Hop Type of the routes to Virtual Network Gateway.
D
Deploy an Azure Virtual Network Gateway in VNet-Hub and configure the spoke peering links to use remote gateways.

Answer

Change the 'Traffic forwarded from remote virtual network' setting to Allow on the peering connections between VNet-Hub and both spoke virtual networks.

The correct option is changing the 'Traffic forwarded from remote virtual network' setting to Allow on the peering connections. This is because packets sent from VM-Spoke1 to VM-Spoke2 via VM-NVA maintain their original source IP address. When these packets are forwarded by VM-NVA in VNet-Hub over the peering link to VNet-Spoke2, they are identified as forwarded traffic (since the source IP is in VNet-Spoke1, not VNet-Hub). By default, Azure virtual network peering blocks forwarded traffic. Enabling 'Traffic forwarded from remote virtual network' allows VNet-Hub to forward these packets and the spoke VNets to accept them.

Step-by-Step Solution

Analyze the flow of packets from the source to the destination virtual network.

Packets from VM-Spoke1 (

10.201.0.0/16

) targeting VM-Spoke2 (

10.202.0.0/16

) are routed to the NVA (

10.200.1.4

) in VNet-Hub.

Establishing the data path requires determining how packets transit the network topology.

Determine the role of VNet Peering in traffic forwarding.

When VM-NVA forwards the packets to VM-Spoke2, the source IP is still from VNet-Spoke1. Thus, the traffic arriving at VNet-Spoke2 from VNet-Hub has a source IP external to VNet-Hub.

Azure classifies any packet whose source IP does not match the virtual network it is arriving from as forwarded traffic.

Identify the required peering link settings.

Enable 'Traffic forwarded from remote virtual network' (Allow forwarded traffic) on the peering links to permit the transit of packets that did not originate from the direct peering partner.

By default, Azure blocks forwarded traffic, which stops the NVA from successfully passing traffic between the peered spokes.

Key Concept

Transit routing and forwarded traffic configurations in Azure Virtual Network Peering

Estimated Time:2m 0s

Question

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Topics

More questions from this topic