VNet peering for connectivity in Azure - Step-by-Step Execution

Process Flow - VNet peering for connectivity

Create VNet A

↓

Create VNet B

↓

Request Peering from VNet A to VNet B

↓

Request Peering from VNet B to VNet A

↓

Peering Established

↓

VNets can now communicate directly

This flow shows creating two virtual networks, requesting peering from each side, and establishing a connection allowing direct communication.

Execution Sample

Azure

az network vnet create --resource-group RG --location eastus --name VNetA --address-prefixes 10.0.0.0/16
az network vnet create --resource-group RG --location eastus --name VNetB --address-prefixes 10.1.0.0/16
VNETA_ID=$(az network vnet show --resource-group RG --name VNetA --query id --output tsv)
VNETB_ID=$(az network vnet show --resource-group RG --name VNetB --query id --output tsv)
az network vnet peering create --resource-group RG --vnet-name VNetA --name VNetAtoB --remote-vnet $VNETB_ID --allow-vnet-access
az network vnet peering create --resource-group RG --vnet-name VNetB --name VNetBtoA --remote-vnet $VNETA_ID --allow-vnet-access

This code creates two VNets and sets up peering from each to the other to enable connectivity.

Process Table

Step	Action	Resource State	Result
1	Create VNet A with address 10.0.0.0/16	VNet A created	VNet A ready
2	Create VNet B with address 10.1.0.0/16	VNet B created	VNet B ready
3	Create peering from VNet A to VNet B	Peering request sent	Peering A->B pending
4	Create peering from VNet B to VNet A	Peering request sent	Peering B->A pending
5	Peering established both ways	Peering active	VNets connected
6	Test connectivity between VNets	Ping from VNet A to VNet B succeeds	Connectivity confirmed

💡 Peering established both ways, VNets can communicate directly

Status Tracker

Resource	Initial State	After Step 1	After Step 2	After Step 3	After Step 4	After Step 5
VNet A	Not created	Created with 10.0.0.0/16	Created	Peering A->B requested	Peering A->B requested	Peering active
VNet B	Not created	Not created	Created with 10.1.0.0/16	Created	Peering B->A requested	Peering active
Peering A->B	None	None	None	Requested	Requested	Active
Peering B->A	None	None	None	None	Requested	Active

Key Moments - 3 Insights

Why do we need to create peering from both VNets?

Peering must be created from both sides (see steps 3 and 4 in execution_table) because Azure requires mutual approval to establish the connection.

Can VNets with overlapping address spaces be peered?

No, VNets must have non-overlapping IP address ranges to peer successfully, otherwise routing conflicts occur.

What happens if only one peering is created?

If only one peering exists (see step 3 or 4 alone), connectivity is not established because peering is not mutual.

Visual Quiz - 3 Questions

Look at the execution_table, at which step is the peering from VNet B to VNet A requested?

A Step 3

B Step 4

C Step 5

D Step 2

💡 Hint

Check the 'Action' column for peering requests in execution_table rows

According to variable_tracker, what is the state of Peering A->B after Step 3?

A Requested

B None

C Active

D Pending Approval

💡 Hint

Look at the Peering A->B row under After Step 3 in variable_tracker

If the address spaces of VNet A and VNet B overlapped, what would happen to the peering?

A Peering would still be active

B Peering would be created but no connectivity

C Peering would fail due to IP conflict

D Peering would auto-correct address spaces

💡 Hint

Refer to key_moments about address space requirements

Concept Snapshot

VNet peering connects two Azure VNets for direct communication.
Create each VNet with unique IP ranges.
Set peering from both VNets to establish connection.
Peering allows resources to communicate privately.
Both sides must approve peering for it to be active.

Full Transcript

This lesson shows how to connect two Azure virtual networks using VNet peering. First, two VNets are created with distinct IP address spaces. Then, peering requests are created from each VNet to the other. Both peering requests must be active for the VNets to communicate. The execution table traces each step from creation to connectivity confirmation. Variable tracking shows the state changes of VNets and peering connections. Key moments clarify why peering must be mutual and why address spaces cannot overlap. The visual quiz tests understanding of peering steps and states. The concept snapshot summarizes the process simply.

Practice

1. What is the main purpose of Azure VNet peering?

easy

A. To connect two virtual networks for direct communication

B. To create a backup of virtual machines

C. To deploy applications faster

D. To monitor network traffic

Solution

1. Step 1: Understand VNet peering concept

   VNet peering allows two virtual networks to communicate directly without going through the internet.

2. Step 2: Identify the main use case

   This direct communication is the primary purpose, enabling resource sharing securely within Azure.

3. Final Answer:

   To connect two virtual networks for direct communication -> Option A

4. Quick Check:

   VNet peering = direct network connection [OK]

Hint: VNet peering links networks directly, not backups or monitoring [OK]

Common Mistakes:

• Confusing peering with VM backup
• Thinking peering speeds up app deployment
• Assuming peering is for traffic monitoring

2. Which of the following is the correct way to create a VNet peering in Azure Portal?

easy

A. Create a new VNet with peering enabled by default

B. Create peering from one VNet only

C. Create peering from both VNets involved

D. Enable peering in the subscription settings

Solution

1. Step 1: Review peering setup requirements

   VNet peering requires configuration from both virtual networks to allow full communication.

2. Step 2: Identify correct procedure

   Creating peering from both VNets ensures bidirectional connectivity and proper routing.

3. Final Answer:

   Create peering from both VNets involved -> Option C

4. Quick Check:

   Peering setup = both sides configured [OK]

Hint: Peering needs setup on both VNets, not just one [OK]

Common Mistakes:

• Configuring peering only on one VNet
• Assuming peering is automatic on new VNets
• Looking for peering in subscription settings

3. Given two VNets, VNetA and VNetB, peered correctly, what happens when a VM in VNetA tries to ping a VM in VNetB?

medium

A. The ping fails because VNets cannot communicate even if peered

B. The ping fails because peering blocks ICMP traffic

C. The ping succeeds only if both VMs are in the same subnet

D. The ping succeeds because peering allows direct communication

Solution

1. Step 1: Understand VNet peering behavior

   Peering connects VNets so resources can communicate directly, including ping (ICMP) traffic if allowed by NSGs.

2. Step 2: Analyze the ping scenario

   If no network security group blocks ICMP, ping from VM in VNetA to VM in VNetB will succeed due to peering.

3. Final Answer:

   The ping succeeds because peering allows direct communication -> Option D

4. Quick Check:

   Peering enables direct VM communication [OK]

Hint: Peering allows direct traffic unless blocked by security rules [OK]

Common Mistakes:

• Assuming peering blocks ping by default
• Thinking VMs must be in same subnet to communicate
• Believing peering does not enable VNet communication

4. You created VNet peering from VNetA to VNetB but forgot to create peering from VNetB to VNetA. What is the result?

medium

A. Full bidirectional communication between VNets

B. Unidirectional communication from VNetA to VNetB only

C. No communication between VNets

D. Peering automatically completes from both sides

Solution

1. Step 1: Understand peering directionality

   Peering must be created on both VNets for full bidirectional communication.

2. Step 2: Analyze partial peering effect

   With peering only from VNetA to VNetB, traffic flows from A to B but not from B to A.

3. Final Answer:

   Unidirectional communication from VNetA to VNetB only -> Option B

4. Quick Check:

   One-sided peering = one-way traffic [OK]

Hint: Peering one side = one-way connection only [OK]

Common Mistakes:

• Assuming peering is automatic both ways
• Expecting no communication at all
• Thinking peering creates full connection from one side

5. You have two VNets in different Azure regions and want to enable secure, low-latency communication between them. Which VNet peering type should you use?

hard

A. Global VNet peering

B. Local VNet peering

C. VPN Gateway peering

D. ExpressRoute peering

Solution

1. Step 1: Identify peering types and their use cases

   Local VNet peering works within the same region; global VNet peering connects VNets across regions.

2. Step 2: Choose peering for cross-region communication

   Global VNet peering enables secure, low-latency communication between VNets in different Azure regions.

3. Final Answer:

   Global VNet peering -> Option A

4. Quick Check:

   Cross-region VNet peering = global peering [OK]

Hint: Use global peering for cross-region VNet connection [OK]

Common Mistakes:

• Choosing local peering for different regions
• Confusing VPN Gateway with peering
• Selecting ExpressRoute which is for on-premises