VNet peering and gateway transit

Create three small test VMs, one in the hub and one in each spoke (about 5 minutes):

az group create --name rg-saat-l46 --location centralindia --tags course=saatvedha-azure lesson=46 -o none
$hubSub = az network vnet subnet show --resource-group rg-saat-hub --vnet-name vnet-hub --name snet-shared --query id -o tsv
$s1Sub = az network vnet subnet show --resource-group rg-saat-hub --vnet-name vnet-spoke1 --name snet-app --query id -o tsv
$s2Sub = az network vnet subnet show --resource-group rg-saat-hub --vnet-name vnet-spoke2 --name snet-app --query id -o tsv
az vm create --resource-group rg-saat-l46 --name vm-hub --image Canonical:ubuntu-24_04-lts:server:latest --size Standard_B1s --subnet $hubSub --public-ip-address '""' --nsg '""' --admin-username azureuser --generate-ssh-keys --tags course=saatvedha-azure lesson=46 -o none
az vm create --resource-group rg-saat-l46 --name vm-s1 --image Canonical:ubuntu-24_04-lts:server:latest --size Standard_B1s --subnet $s1Sub --public-ip-address '""' --nsg '""' --admin-username azureuser --generate-ssh-keys --tags course=saatvedha-azure lesson=46 -o none
az vm create --resource-group rg-saat-l46 --name vm-s2 --image Canonical:ubuntu-24_04-lts:server:latest --size Standard_B1s --subnet $s2Sub --public-ip-address '""' --nsg '""' --admin-username azureuser --generate-ssh-keys --tags course=saatvedha-azure lesson=46 -o none
az vm list-ip-addresses --resource-group rg-saat-l46 --query "[].{vm:virtualMachine.name, ip:virtualMachine.network.privateIpAddresses[0]}" -o table

You should see this:

Vm      Ip
------  ----------
vm-hub  10.40.10.4
vm-s1   10.41.1.4
vm-s2   10.42.1.4

Standard_B1s (1 vCPU) keeps three VMs inside a free account’s regional vCPU limit. Before peering, none of them can reach the others.

1Create one side of a peering

Peer the hub to spoke 1, and look at the state:

az network vnet peering create --resource-group rg-saat-hub --name hub-to-spoke1 --vnet-name vnet-hub --remote-vnet vnet-spoke1 --allow-vnet-access true --allow-forwarded-traffic true -o none
az network vnet peering list --resource-group rg-saat-hub --vnet-name vnet-hub --query "[].{name:name, state:peeringState, sync:peeringSyncLevel}" -o table

You should see this:

Name           State      Sync
-------------  ---------  ------------
hub-to-spoke1  Initiated  FullyInSync

Initiated means only one side exists. No traffic flows yet.

2Complete it, and add spoke 2

Run this:

az network vnet peering create --resource-group rg-saat-hub --name spoke1-to-hub --vnet-name vnet-spoke1 --remote-vnet vnet-hub --allow-vnet-access true --allow-forwarded-traffic true -o none
az network vnet peering create --resource-group rg-saat-hub --name hub-to-spoke2 --vnet-name vnet-hub --remote-vnet vnet-spoke2 --allow-vnet-access true --allow-forwarded-traffic true -o none
az network vnet peering create --resource-group rg-saat-hub --name spoke2-to-hub --vnet-name vnet-spoke2 --remote-vnet vnet-hub --allow-vnet-access true --allow-forwarded-traffic true -o none
az network vnet peering list --resource-group rg-saat-hub --vnet-name vnet-hub --query "[].{name:name, state:peeringState, sync:peeringSyncLevel}" -o table

You should see this:

Name           State      Sync
-------------  ---------  -----------
hub-to-spoke1  Connected  FullyInSync
hub-to-spoke2  Connected  FullyInSync

3Test: spoke to hub works, spoke to spoke doesn’t

Ping from vm-s1 to the hub, then to spoke 2:

az vm run-command invoke --resource-group rg-saat-l46 --name vm-s1 --command-id RunShellScript --scripts 'ping -c 2 -W 2 10.40.10.4 | tail -2' --query "value[0].message" -o tsv
az vm run-command invoke --resource-group rg-saat-l46 --name vm-s1 --command-id RunShellScript --scripts 'ping -c 2 -W 2 10.42.1.4 | tail -2' --query "value[0].message" -o tsv

You should see something like this:

[stdout]
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 1.102/1.215/1.328/0.113 ms
[stdout]
2 packets transmitted, 0 received, 100% packet loss, time 1013ms

Spoke 1 and spoke 2 are both connected to the hub, yet they can’t reach each other. That’s peering working exactly as designed.

4Read vm-s1’s effective routes

Run this:

az network nic show-effective-route-table --resource-group rg-saat-l46 --name vm-s1VMNic --query "value[?nextHopType!='None'].{prefix:addressPrefix[0], nextHop:nextHopType}" -o table

You should see something like this:

Prefix        NextHop
------------  -----------
10.41.0.0/16  VnetLocal
10.40.0.0/16  VNetPeering
0.0.0.0/0     Internet

There’s a route to the hub, none to 10.42.0.0/16, so traffic to spoke 2 falls to the default route and is lost. Lesson 47 adds a route that sends spoke-to-spoke traffic to the hub.

✅ Checkpoint: Both peerings are Connected, vm-s1 reaches the hub but not spoke 2, and the effective routes show why.