You have an Azure subscription that contains the virtual networks shown in the following table: | Virtual Network | Address Space | Resources Deployed | | :--- | :--- | :--- | | `VNet-Hub` | 10.10.0.0/16 | `VPNGW1` (VPN Gateway), `NVA1` (Network Virtual Appliance at 10.10.1.4) | | `VNet-Spoke1` | 10

You have an Azure subscription that contains the virtual networks shown in the following t… — Microsoft Azure Administrator (AZ-104)

You have an Azure subscription that contains the virtual networks shown in the following table:

Virtual Network	Address Space	Resources Deployed
`VNet-Hub`	$10.10.0.0/16$	`VPNGW1` (VPN Gateway), `NVA1` (Network Virtual Appliance at $10.10.1.4$ )
`VNet-Spoke1`	$10.20.0.0/16$	`VM1` (Virtual Machine at $10.20.1.4$ )
`VNet-Spoke2`	$10.30.0.0/16$	`VM2` (Virtual Machine at $10.30.1.4$ )

An on-premises network ( $192.168.1.0/24$ ) is connected to `VPNGW1` via a Site-to-Site VPN connection. IP forwarding is enabled on the network interface of `NVA1`.

You configure the following virtual network peering connections:
1. `Peering-Hub-Spoke1` between `VNet-Hub` and `VNet-Spoke1`
2. `Peering-Hub-Spoke2` between `VNet-Hub` and `VNet-Spoke2`

The peerings are currently configured with the following settings:
- On both peerings, the hub-side settings have 'Traffic forwarded from remote virtual network' set to Block, and 'Use this virtual network's gateway or Route Server' set to Block (disabled).
- On both peerings, the spoke-side settings have 'Traffic forwarded from remote virtual network' set to Block, and 'Use the remote virtual network's gateway or Route Server' set to Allow (enabled).

You associate route tables to the subnets in `VNet-Spoke1` and `VNet-Spoke2` to route traffic destined for the opposite spoke to `NVA1` ( $10.10.1.4$ ).

You need to ensure that:
1. `VM1` and `VM2` can communicate with each other through `NVA1`.
2. Both `VM1` and `VM2` can access the on-premises network through `VPNGW1`.

Which configuration changes should you perform?

Enable 'Use this virtual network's gateway or Route Server' on the hub-side peerings, and enable 'Traffic forwarded from remote virtual network' on the spoke-side peerings.Cevap
B
Create a direct virtual network peering between `VNet-Spoke1` and `VNet-Spoke2`, and configure both sides to allow gateway transit.
C
Enable 'Traffic forwarded from remote virtual network' on the hub-side peerings, and enable 'Use this virtual network's gateway or Route Server' on the spoke-side peerings.
D
Enable 'Traffic forwarded from remote virtual network' on both the hub-side and spoke-side peerings, and disable 'Use the remote virtual network's gateway or Route Server' on the spoke-side peerings.

Cevap

Enable 'Use this virtual network's gateway or Route Server' on the hub-side peerings, and enable 'Traffic forwarded from remote virtual network' on the spoke-side peerings.

To satisfy both requirements, you must first enable 'Use this virtual network's gateway or Route Server' on the hub-side peerings so that the spokes can transit traffic through the hub gateway to the on-premises network. Second, because traffic between the spokes is routed through the Network Virtual Appliance (NVA1) in the hub, the packets entering the spokes from the hub originate from the other spoke's IP space. This makes it forwarded traffic from the spokes' perspective. Thus, you must enable 'Traffic forwarded from remote virtual network' on the spoke-side peerings so they do not drop these forwarded packets.

Adım Adım Çözüm

Analyze the gateway transit configuration.

To allow the spokes to route on-premises traffic through the hub's VPN Gateway (VPNGW1), the hub-side peering must allow gateway transit (Use this virtual network's gateway or Route Server) and the spoke-side peering must use the remote gateway.

By default, virtual network gateway sharing is disabled on peerings.

Trace the spoke-to-spoke network path via the NVA.

Traffic from VM1 (

10.20.1.4

) to VM2 (

10.30.1.4

) is sent to NVA1 (

10.10.1.4

). NVA1 forwards the packet to VM2. For VNet-Spoke2, the incoming packet originates from the

10.20.0.0/16

address space, which is external to VNet-Hub.

Azure classifies packets delivered over a peering that originate outside the peered virtual network as forwarded traffic.

Determine the required forwarded traffic settings.

To prevent VM1's forwarded packets from being dropped when they enter VNet-Spoke2, the spoke-side peering on VNet-Spoke2 must allow forwarded traffic. The same applies to VNet-Spoke1 for the return traffic.

Peering links block forwarded traffic by default if the option is disabled, preventing transit routing via NVAs.

Anahtar Kavram

Configuring Virtual Network Peering settings for gateway transit and transit routing through a hub NVA.

Soru

Cevap

Adım Adım Çözüm

Anahtar Kavram

Sık Yapılan Hatalar

Konular

Bu konudan daha fazla soru