Part 6: Connect Azure VNets with Peering

Peer two Azure VNets and prove private routing with ping and effective routes.

Introduction

30 Second Summary

Two buildings can share a city while their private hallways stay completely separate. A useful connection gives them a private path between both buildings.

In this project, you will connect two non-overlapping Azure Virtual Networks through regional VNet peering. Your before-and-after evidence will show exactly when private IP connectivity gains a route across the Microsoft backbone.

What You'll Build

You will watch the same private packet test from vm-1 to 10.30.1.4 transform from total packet loss into four replies after peering.

By the end of this project, you'll have:

  • A recoverable network lab that adapts to whichever Part 5 resources remain in your subscription.
  • A before-and-after private connectivity test that captures the isolated failure. The repeated test captures successful replies once both peering links show Connected.
  • A two-way private connection with lab-to-spoke and spoke-to-lab both showing Connected. Clear route-level evidence shows 10.30.0.0/16 through Virtual network peering on vm-1-nic.
  • Secret Mission: Expand the spoke with 10.31.0.0/16. Synchronize the peering. Prove the new route propagated to vm-1-nic.

Are there any prerequisites?

You'll need an active Azure subscription with permission to create virtual networks, Azure Virtual Machines, Azure NAT Gateway resources, and VNet peerings. This project builds on your Azure portal experience from Parts 1 through 5.

Before We Start

Before any Azure resources change, this step locks in the private connectivity result you are about to prove. The before-and-after test shows failure without peering followed by success after bidirectional regional VNet peering creates the required system routes.

Inspect and Restore the Lab Baseline

Your peering test only means something when both endpoint VMs have known private addresses. An incomplete baseline could make the planned connectivity failure prove the wrong thing.

The subscription may contain all, some, or none of the earlier resources. In this step, you will inventory the existing lab before using an Azure Resource Manager template to restore the exact starting state.

In this step, get ready to:
  • Inventory the existing networking lab without deleting unrelated resources.
  • Deploy the Part 6 template with the correct baseline setting.
  • Start both VMs and verify their private network configuration.
Inventory the existing lab

The NextWork-Networking resource group determines which deployment path you use. A complete Part 5 baseline can stay in place, while a partial disposable baseline needs a clean rebuild.

  • Open the Azure portal in your browser.
  • Sign in with the account connected to your active Azure subscription.
  • Select Resource groups from the Azure portal.
  • Open NextWork-Networking if it exists.
  • Review every resource in the group before choosing your baseline path.

What counts as an intact baseline?

The source baseline is intact when vnet-nextwork-lab contains snet-web at 10.20.1.0/24. The vm-1 network interface must use 10.20.1.4.

The snet-web subnet also needs working outbound connectivity through the existing NAT Gateway. These checks protect the before-and-after test from an unrelated baseline fault.

Baseline intact

Keep the existing source resources because they already provide the known-good Part 5 baseline.

  • Confirm vnet-nextwork-lab uses address space 10.20.0.0/16.
  • Confirm snet-web uses address prefix 10.20.1.0/24.
  • Confirm vm-1 uses private IP 10.20.1.4.
  • Confirm the existing NAT Gateway provides outbound connectivity for snet-web.
  • Use false for the deployment parameter.

Partial disposable baseline

Deleting the group is permanent. This path is safe only after every listed resource has been identified as disposable NextWork lab work.

  • Confirm that NextWork-Networking contains no unrelated resources.
  • Select Delete resource group from the resource group page.
  • Type NextWork-Networking when the portal asks for the resource group name.
  • Confirm the deletion.
  • Wait until NextWork-Networking no longer appears under Resource groups.
  • Use true for the deployment parameter.

No baseline exists

The template can create the minimum source baseline and the new spoke resources in one deployment.

  • Confirm that NextWork-Networking does not appear under Resource groups.
  • Use true for the deployment parameter.
  • Record the value you selected for Deploy Source Baseline: false or true.
Deploy the Part 6 lab template

The template uses the baseline value you selected to preserve or recreate the source network. It always creates the separate spoke network and its private VM.

  • Prepare the exact part6-lab.json template by checking the full-file reference below.

✔️ Awesome, I've got everything!

Great. Keep the complete part6-lab.json template ready for the custom template editor.

ⓧ I'd like to double check the full code

Compare your part6-lab.json against this complete template:

Part 1: Network foundation

Start with the template metadata, parameters, variables, and network resources.

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "location": {
      "type": "string",
      "defaultValue": "centralus"
    },
    "deploySourceBaseline": {
      "type": "bool",
      "defaultValue": true
    },
    "adminUsername": {
      "type": "string",
      "defaultValue": "azureuser"
    },
    "adminPassword": {
      "type": "secureString"
    },
    "vmSize": {
      "type": "string",
      "defaultValue": "Standard_B1s",
      "allowedValues": [
        "Standard_B1s",
        "Standard_B1ms"
      ]
    }
  },
  "variables": {
    "sourceVnetName": "vnet-nextwork-lab",
    "sourceSubnetName": "snet-web",
    "sourceNicName": "vm-1-nic",
    "sourceVmName": "vm-1",
    "sourceOsDiskName": "vm-1-osdisk",
    "sourcePublicIpName": "pip-nextwork-nat",
    "sourceNatGatewayName": "nat-nextwork-outbound",
    "spokeVnetName": "vnet-nextwork-spoke",
    "spokeSubnetName": "snet-spoke",
    "spokeNicName": "vm-spoke-nic",
    "spokeVmName": "vm-spoke",
    "spokeOsDiskName": "vm-spoke-osdisk"
  },
  "resources": [
    {
      "condition": "[parameters('deploySourceBaseline')]",
      "type": "Microsoft.Network/publicIPAddresses",
      "apiVersion": "2025-01-01",
      "name": "[variables('sourcePublicIpName')]",
      "location": "[parameters('location')]",
      "sku": {
        "name": "Standard",
        "tier": "Regional"
      },
      "properties": {
        "publicIPAddressVersion": "IPv4",
        "publicIPAllocationMethod": "Static"
      }
    },
    {
      "condition": "[parameters('deploySourceBaseline')]",
      "type": "Microsoft.Network/natGateways",
      "apiVersion": "2025-01-01",
      "name": "[variables('sourceNatGatewayName')]",
      "location": "[parameters('location')]",
      "sku": {
        "name": "Standard"
      },
      "dependsOn": [
        "[resourceId('Microsoft.Network/publicIPAddresses', variables('sourcePublicIpName'))]"
      ],
      "properties": {
        "idleTimeoutInMinutes": 10,
        "publicIpAddresses": [
          {
            "id": "[resourceId('Microsoft.Network/publicIPAddresses', variables('sourcePublicIpName'))]"
          }
        ]
      }
    },
    {
      "condition": "[parameters('deploySourceBaseline')]",
      "type": "Microsoft.Network/virtualNetworks",
      "apiVersion": "2025-01-01",
      "name": "[variables('sourceVnetName')]",
      "location": "[parameters('location')]",
      "properties": {
        "addressSpace": {
          "addressPrefixes": [
            "10.20.0.0/16"
          ]
        }
      }
    },
    {
      "condition": "[parameters('deploySourceBaseline')]",
      "type": "Microsoft.Network/virtualNetworks/subnets",
      "apiVersion": "2025-01-01",
      "name": "[format('{0}/{1}', variables('sourceVnetName'), variables('sourceSubnetName'))]",
      "dependsOn": [
        "[resourceId('Microsoft.Network/virtualNetworks', variables('sourceVnetName'))]",
        "[resourceId('Microsoft.Network/natGateways', variables('sourceNatGatewayName'))]"
      ],
      "properties": {
        "addressPrefix": "10.20.1.0/24",
        "defaultOutboundAccess": false,
        "natGateway": {
          "id": "[resourceId('Microsoft.Network/natGateways', variables('sourceNatGatewayName'))]"
        }
      }
    },
    {
      "condition": "[parameters('deploySourceBaseline')]",
      "type": "Microsoft.Network/networkInterfaces",
      "apiVersion": "2025-01-01",
      "name": "[variables('sourceNicName')]",
      "location": "[parameters('location')]",
      "dependsOn": [
        "[resourceId('Microsoft.Network/virtualNetworks/subnets', variables('sourceVnetName'), variables('sourceSubnetName'))]"
      ],
      "properties": {
        "enableAcceleratedNetworking": false,
        "enableIPForwarding": false,
        "ipConfigurations": [
          {
            "name": "ipconfig1",
            "properties": {
              "primary": true,
              "privateIPAddress": "10.20.1.4",
              "privateIPAddressVersion": "IPv4",
              "privateIPAllocationMethod": "Static",
              "subnet": {
                "id": "[resourceId('Microsoft.Network/virtualNetworks/subnets', variables('sourceVnetName'), variables('sourceSubnetName'))]"
              }
            }
          }
        ]
      }
    },

Part 2: Virtual machines and outputs

Continue with the virtual machines, spoke resources, outputs, and closing structure.

    {
      "condition": "[parameters('deploySourceBaseline')]",
      "type": "Microsoft.Compute/virtualMachines",
      "apiVersion": "2025-04-01",
      "name": "[variables('sourceVmName')]",
      "location": "[parameters('location')]",
      "dependsOn": [
        "[resourceId('Microsoft.Network/networkInterfaces', variables('sourceNicName'))]"
      ],
      "properties": {
        "hardwareProfile": {
          "vmSize": "[parameters('vmSize')]"
        },
        "osProfile": {
          "computerName": "[variables('sourceVmName')]",
          "adminUsername": "[parameters('adminUsername')]",
          "adminPassword": "[parameters('adminPassword')]",
          "allowExtensionOperations": true,
          "linuxConfiguration": {
            "disablePasswordAuthentication": false,
            "provisionVMAgent": true
          }
        },
        "storageProfile": {
          "imageReference": {
            "publisher": "Canonical",
            "offer": "ubuntu-24_04-lts",
            "sku": "server",
            "version": "latest"
          },
          "osDisk": {
            "name": "[variables('sourceOsDiskName')]",
            "createOption": "FromImage",
            "caching": "ReadWrite",
            "deleteOption": "Delete",
            "managedDisk": {
              "storageAccountType": "Standard_LRS"
            }
          }
        },
        "networkProfile": {
          "networkInterfaces": [
            {
              "id": "[resourceId('Microsoft.Network/networkInterfaces', variables('sourceNicName'))]",
              "properties": {
                "primary": true,
                "deleteOption": "Delete"
              }
            }
          ]
        },
        "diagnosticsProfile": {
          "bootDiagnostics": {
            "enabled": true
          }
        }
      }
    },
    {
      "type": "Microsoft.Network/virtualNetworks",
      "apiVersion": "2025-01-01",
      "name": "[variables('spokeVnetName')]",
      "location": "[parameters('location')]",
      "properties": {
        "addressSpace": {
          "addressPrefixes": [
            "10.30.0.0/16"
          ]
        }
      }
    },
    {
      "type": "Microsoft.Network/virtualNetworks/subnets",
      "apiVersion": "2025-01-01",
      "name": "[format('{0}/{1}', variables('spokeVnetName'), variables('spokeSubnetName'))]",
      "dependsOn": [
        "[resourceId('Microsoft.Network/virtualNetworks', variables('spokeVnetName'))]"
      ],
      "properties": {
        "addressPrefix": "10.30.1.0/24",
        "defaultOutboundAccess": false
      }
    },
    {
      "type": "Microsoft.Network/networkInterfaces",
      "apiVersion": "2025-01-01",
      "name": "[variables('spokeNicName')]",
      "location": "[parameters('location')]",
      "dependsOn": [
        "[resourceId('Microsoft.Network/virtualNetworks/subnets', variables('spokeVnetName'), variables('spokeSubnetName'))]"
      ],
      "properties": {
        "enableAcceleratedNetworking": false,
        "enableIPForwarding": false,
        "ipConfigurations": [
          {
            "name": "ipconfig1",
            "properties": {
              "primary": true,
              "privateIPAddress": "10.30.1.4",
              "privateIPAddressVersion": "IPv4",
              "privateIPAllocationMethod": "Static",
              "subnet": {
                "id": "[resourceId('Microsoft.Network/virtualNetworks/subnets', variables('spokeVnetName'), variables('spokeSubnetName'))]"
              }
            }
          }
        ]
      }
    },
    {
      "type": "Microsoft.Compute/virtualMachines",
      "apiVersion": "2025-04-01",
      "name": "[variables('spokeVmName')]",
      "location": "[parameters('location')]",
      "dependsOn": [
        "[resourceId('Microsoft.Network/networkInterfaces', variables('spokeNicName'))]"
      ],
      "properties": {
        "hardwareProfile": {
          "vmSize": "[parameters('vmSize')]"
        },
        "osProfile": {
          "computerName": "[variables('spokeVmName')]",
          "adminUsername": "[parameters('adminUsername')]",
          "adminPassword": "[parameters('adminPassword')]",
          "allowExtensionOperations": true,
          "linuxConfiguration": {
            "disablePasswordAuthentication": false,
            "provisionVMAgent": true
          }
        },
        "storageProfile": {
          "imageReference": {
            "publisher": "Canonical",
            "offer": "ubuntu-24_04-lts",
            "sku": "server",
            "version": "latest"
          },
          "osDisk": {
            "name": "[variables('spokeOsDiskName')]",
            "createOption": "FromImage",
            "caching": "ReadWrite",
            "deleteOption": "Delete",
            "managedDisk": {
              "storageAccountType": "Standard_LRS"
            }
          }
        },
        "networkProfile": {
          "networkInterfaces": [
            {
              "id": "[resourceId('Microsoft.Network/networkInterfaces', variables('spokeNicName'))]",
              "properties": {
                "primary": true,
                "deleteOption": "Delete"
              }
            }
          ]
        },
        "diagnosticsProfile": {
          "bootDiagnostics": {
            "enabled": true
          }
        }
      }
    }
  ],
  "outputs": {
    "sourcePrivateIp": {
      "type": "string",
      "value": "10.20.1.4"
    },
    "spokePrivateIp": {
      "type": "string",
      "value": "10.30.1.4"
    },
    "nextAction": {
      "type": "string",
      "value": "Run ping -c 4 10.30.1.4 from vm-1 before creating peering."
    }
  }
}

What does this template create?

The deploySourceBaseline condition controls the source VNet, subnet, NIC, VM, NAT Gateway, and public IP. Its default value is true, so a clean resource group receives the complete source baseline.

Use false only when you have verified that the intact Part 5 baseline still exists. The spoke VNet, subnet, NIC, and VM are created on every deployment.

  • Search the Azure portal for deploy a custom template.
  • Select Deploy a custom template from the results.
  • Select Build your own template in the editor.
  • Replace the blank template with the complete contents of part6-lab.json.
  • Select Save.
  • Select your active subscription in the deployment form.
  • Select or create NextWork-Networking as the resource group.
  • Set Location to centralus.
  • Set Deploy Source Baseline to true for an empty resource group or false for a verified intact Part 5 baseline.
  • Set Admin Username to azureuser.
  • Enter a new administrator password that meets the portal validation rules in Admin Password.
  • Set VM Size to Standard_B1s.

Review the resources before deployment

This deployment creates billable Azure resources, including up to two virtual machines and managed OS disks. A recreated baseline also includes a NAT Gateway and a Standard public IP.

Check the live cost estimate before you continue. The cleanup section later gives you options to deallocate or remove these resources.

  • Select Review + create.
  • Resolve any validation issue shown by the portal.
  • Select Create after validation passes.

Expect the deployment to take several minutes while Azure creates the network and compute resources. A quiet progress screen during this wait is normal.

  • Wait for the deployment status to show Succeeded.

That is the longest wait complete. Your source and spoke environments now share one repeatable baseline for the connectivity test.

Deployment not succeeding?

  • Recheck that Location is centralus.
  • Recheck that VM Size is Standard_B1s.
  • Review the deployment details for a quota, capacity, or password validation issue.

Help me diagnose my Azure ARM template deployment failure.

Verify and start the test resources

A successful deployment confirms that Azure accepted the template. The final baseline check confirms that the actual VM addresses and network ranges match the test design.

  • Open NextWork-Networking from Resource groups.
  • Select vm-1 from the resource list.
  • Select Start if vm-1 is deallocated.
  • Return to NextWork-Networking.
  • Select vm-spoke from the resource list.
  • Select Start if vm-spoke is not running.

Why both VMs must be running

The next step sends a private packet from vm-1 to vm-spoke. Running both VMs keeps the test focused on the missing inter-VNet route.

Before the final check, which two private IP addresses do you expect to find on the VM network interfaces?

  • Return to NextWork-Networking.
  • Confirm the resource list includes vnet-nextwork-lab, vm-1, vnet-nextwork-spoke, and vm-spoke in Central US.
  • Select vm-1.
  • Open its Networking section.

You should see vm-1-nic with private IP 10.20.1.4. You should not see a VM-level public IP.

  • Return to NextWork-Networking.
  • Select vm-spoke.
  • Open its Networking section.

You should see vm-spoke-nic with private IP 10.30.1.4. You should not see a VM-level public IP.

  • Return to NextWork-Networking.
  • Open vnet-nextwork-lab.
  • Inspect its address space and subnet details.

You should see address space 10.20.0.0/16 with snet-web at 10.20.1.0/24.

  • Return to NextWork-Networking.
  • Open vnet-nextwork-spoke.
  • Inspect its address space and subnet details.

You should see address space 10.30.0.0/16 with snet-spoke at 10.30.1.0/24.

What does the finished baseline prove?

  • The source VNet and spoke VNet use non-overlapping address spaces.
  • The two VMs use the planned static private IP addresses.
  • Neither VM depends on a VM-level public IP.
  • The template creates no VNet peering, so the networks remain isolated for the planned failure test.

Your baseline is now consistent across both private networks. Next, you will run the first packet test and capture the isolation failure before any peering exists.

Prove the VNets Are Isolated

The Part 6 baseline is ready. Both test VMs are running in separate Azure Virtual Networks.

Independent VNets do not exchange private traffic by default. A missing VNet peering relationship gives this test its deliberate before-state.

In this step, get ready to:
  • Check the peering state on each VNet.
  • Run a private-IP ping from vm-1 to vm-spoke.
  • Capture the failed output as before-peering evidence.
Confirm there is no peering yet

A VNet's Peerings page lists its configured peering relationships. Empty lists on both VNets establish a clean baseline for the packet test.

  • Return to the NextWork-Networking resource group in the Azure portal.
  • Select vnet-nextwork-lab from the resource list.
  • Select Peerings under Settings in the VNet menu.
  • Confirm that no peering to vnet-nextwork-spoke is listed.

The source VNet has no configured connection to the spoke VNet.

  • Return to the NextWork-Networking resource group.
  • Select vnet-nextwork-spoke from the resource list.
  • Select Peerings under Settings in the VNet menu.
  • Confirm that no peering to vnet-nextwork-lab is listed.

Neither VNet lists a peering relationship to the other. The private networks are still isolated.

Run the planned failure

The source VM can execute a shell command through Azure Run Command without a VM-level public IP. The packet test targets vm-spoke at 10.30.1.4.

  • Return to the NextWork-Networking resource group.
  • Select vm-1 from the resource list.
  • Select Run command under Operations in the VM menu.
  • Choose RunShellScript.
  • Enter the planned four-packet test in the RunShellScript editor by copying this command:
ping -c 4 10.30.1.4

What does this command test?

  • The ping command sends ICMP echo requests from vm-1.
  • The -c 4 option limits the test to four packets.
  • The destination 10.30.1.4 is the private IP address of vm-spoke.

Before you select Run, do you expect any echo replies while both peering lists are empty?

  • Select Run.
  • Wait for the Run Command output to finish.

You'll see no successful echo replies. The result may report packet loss instead.

That's a useful failure. It proves the isolated VNets have no route for private traffic between 10.20.1.4 and 10.30.1.4.

Run Command not returning a result?

A completed ping result with no replies is the success state for this step. A blank or unfinished result means Run Command itself did not complete.

  • Confirm that vm-1 shows Running in the Azure portal.
  • Confirm that snet-web still has the working outbound path from your verified baseline.

Help me troubleshoot Azure Run Command on vm-1.

  • Save the output as your before-peering result by taking a screenshot of the completed RunShellScript output:

That planned failure has done its job. Next, you'll create the reciprocal VNet peering links that give private traffic a route.

Create the Two-Way VNet Peering

Your saved result from Azure Run Command proved that vm-1 cannot reach 10.30.1.4 while the VNets are isolated. That failure exposed the missing inter-VNet route.

Regional Azure Virtual Network peering creates a private relationship between the two networks. In this step, you'll create the reciprocal links that provide both routing directions.

In this step, get ready to:
  • Open the peering workflow from vnet-nextwork-lab.
  • Configure the reciprocal link names with virtual network access enabled.
  • Confirm the control-plane state on both VNets.
Open the peering workflow

The source VNet is where you begin the workflow. Your remote VNet selection tells Azure which private networks to connect.

Why VNet Peering?

VNet peering carries private traffic over the Microsoft backbone. It requires no public internet route or gateway.

An Azure VPN Gateway requires gateway resources. It also adds setup time plus an hourly pricing model.

  • Return to vnet-nextwork-lab from earlier.
  • Select Peerings under Settings.
  • Select + Add.
  • Select your active Azure subscription.
  • Choose vnet-nextwork-spoke as the remote virtual network.
Configure both directions

Azure stores one peering resource on each VNet. Directional names make each side of that relationship clear when you inspect it later.

  • Enter spoke-to-lab in Peering link name under Remote virtual network summary.
  • Enter lab-to-spoke in Peering link name under Local virtual network summary.
  • Keep both virtual-network-access options selected.
  • Leave forwarded traffic cleared.
  • Leave gateway forwarding cleared.
  • Leave remote gateway options cleared.
  • Select Add.

Expect the status to remain Updating for several seconds while Azure establishes both links.

Confirm the control-plane state

Before you refresh, do you think one direction or both directions must report a healthy peering state?

  • Select Refresh on the vnet-nextwork-lab Peerings page.
  • Return to vnet-nextwork-spoke from earlier.
  • Select Peerings under Settings.
  • Select Refresh.

On vnet-nextwork-lab, you'll see lab-to-spoke with status Connected. On vnet-nextwork-spoke, you'll see spoke-to-lab with status Connected.

You have the control plane locked in because both VNet peering links now recognize the reciprocal relationship.

Still Seeing Updating?

  • Wait briefly while Azure propagates the peering state.
  • Select Refresh again on the active Peerings page.
  • Confirm that the remote virtual network is vnet-nextwork-spoke from the lab VNet side.

Help me diagnose why my Azure VNet peering links are not reaching Connected.

The peering control plane is ready. Next, you'll test whether private packets now follow it.

Prove Private Traffic Uses the Peering

Your two Azure Virtual Network peering links now show Connected. That proves Azure accepted the bidirectional configuration.

A control plane status does not prove that vm-1 can reach vm-spoke. The exact private IP test supplies workload evidence.

An effective route then reveals the system path that makes the successful private traffic possible.

In this step, get ready to:
  • Repeat the private IP packet test after peering.
  • Inspect the active route to the spoke network.
  • Capture the evidence that links the peering to successful traffic.
Repeat the exact packet test

Azure Run Command runs a shell command inside vm-1 without a VM-level public IP. Reusing the exact command makes the peering the only changed condition.

  • Return to vm-1 in the Azure portal.
  • Select Run command under Operations.
  • Choose RunShellScript.

Before you run the test, predict whether the same private IP now returns replies.

  • Paste the exact packet test into the script box:
ping -c 4 10.30.1.4

What does this command do?

  • The ping command sends test packets to the spoke VM's private IP.
  • The -c 4 option limits the test to four packets.
  • The destination 10.30.1.4 is the static private IP assigned to vm-spoke.
  • Select Run.

You should see four successful replies. The summary should report 0% packet loss.

That is the packet-level proof you were working toward. Private traffic now reaches the spoke VM through the peering.

  • Save the output as your after-peering result.

Still seeing no replies?

  • Confirm vm-spoke is still running.
  • Confirm both peering links still show Connected.
  • Check that the command targets 10.30.1.4.

Help me diagnose why the after-peering ping still receives no replies.

Inspect the system route

The successful ping proves reachability. The source network interface provides route-level evidence for how Azure delivered that traffic.

  • Return to the vm-1 page.
  • Expand Networking in the left menu.
  • Select Network settings.
  • Select vm-1-nic.
  • Expand Help.
  • Select Effective routes.
  • Locate the active route for 10.30.0.0/16.
  • Check the Next hop type column.

You should see the active 10.30.0.0/16 route using Virtual network peering as its next hop.

That is the routing proof you were looking for. Azure now directs the entire spoke prefix through the peering.

Route not showing?

  • Confirm vm-1 is still running.
  • Refresh Effective routes after a brief wait.
  • Confirm both peering links remain Connected.

Help me find the missing peering route.

Capture the before-and-after proof

A strong network diagnosis connects configuration state to a route. It also connects that route to an observed packet result.

  • Return to the saved before-peering output.
  • Place it beside the current after-peering output.
  • Capture both outputs together as your before-and-after evidence.
  • Return to the Peerings page for vnet-nextwork-lab.
  • Capture lab-to-spoke showing Connected.
  • Return to the Peerings page for vnet-nextwork-spoke.
  • Capture spoke-to-lab showing Connected.
  • Add the effective-route screenshot to the same evidence set.

What does the evidence prove?

  • The failed result shows that the isolated VNets could not exchange private traffic.
  • The two Connected links show that the reciprocal peering relationship exists.
  • The active 10.30.0.0/16 route explains how Azure reaches the spoke network.
  • The successful result proves that packets now follow the peering route.

Before you review the evidence set, predict which single configuration change separates the failed test from the successful test.

  • Review your complete evidence set.

Your before-peering result should show no successful echo replies. Your after-peering result should show four replies with 0% packet loss.

Both links should show Connected. The network interface evidence should show the active remote prefix using Virtual network peering.

Strong finish. Your evidence now links the successful packet test to the peering route that enabled it.

Secret mission

Expand and Synchronize the Spoke

Expand the spoke with a second non-overlapping address range. Then synchronize the peering and prove the new prefix reaches vm-1-nic as an active private route.

Clean Up Your Resources

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. This project uses billable Azure resources, so your choice affects ongoing costs.

Cost warning

Azure Virtual Machines accrue compute charges while they are running. VM compute charges stop once the status reaches Stopped (deallocated).

Managed disks and networking resources can continue to incur charges after deallocation. The Azure NAT Gateway can continue billing while it exists. VNet peering charges apply to transferred data at both ends.

Resources you used:

  • Resource group NextWork-Networking containing the verified Part 6 lab resources.
  • Source network vnet-nextwork-lab with subnet snet-web.
  • Source VM vm-1 with NIC vm-1-nic and its managed OS disk.
  • Spoke network vnet-nextwork-spoke with address spaces 10.30.0.0/16 and 10.31.0.0/16.
  • Spoke subnet snet-spoke with address prefix 10.30.1.0/24.
  • Spoke VM vm-spoke with NIC vm-spoke-nic and managed OS disk vm-spoke-osdisk.
  • Connected peering links lab-to-spoke and spoke-to-lab.
  • Source outbound resources nat-nextwork-outbound and pip-nextwork-nat.

Keep everything running

No action is needed. Choose this option if you are starting the next playlist project immediately.

  • Leave vm-1 and vm-spoke running so the private connectivity lab remains ready.
  • Keep lab-to-spoke and spoke-to-lab connected so both peering routes remain active.
  • Keep 10.31.0.0/16 on vnet-nextwork-spoke so your synchronized route evidence remains reproducible.
  • Review the live Azure estimate because VM compute, managed disks, the NAT Gateway, the public IP, and peering data transfer can incur charges.

Pause - I'll come back to this later

Pausing deallocates both VMs while preserving the VNets and peerings. This stops VM compute charges until you start the VMs again.

  • Open vm-1 from NextWork-Networking.
  • Select Stop.
  • Wait for vm-1 to show Stopped (deallocated).
  • Return to NextWork-Networking.
  • Open vm-spoke.
  • Select Stop.
  • Wait for vm-spoke to show Stopped (deallocated).

Both VMs are now deallocated. Managed disks plus any existing NAT Gateway or public IP can still incur charges.

Delete - I don't want to use this again

Remove project resources when you no longer need this lab. The two cleanup scopes below protect anything you plan to keep.

Deletion is permanent, so confirm the cleanup scope before removing anything.

Delete Only the Part 6 Extension

This scope preserves the source network for the next playlist project. It removes the spoke network plus the reciprocal peering relationship.

  • Open vnet-nextwork-lab from NextWork-Networking.
  • Select Peerings under Settings.
  • Select lab-to-spoke.
  • Delete lab-to-spoke.

Deleting this peering also deletes spoke-to-lab on the remote VNet. The reciprocal connection is now removed.

  • Return to NextWork-Networking.
  • Open vm-spoke.
  • Delete vm-spoke.
  • Delete vm-spoke-nic from NextWork-Networking if it remains after the VM deletion.
  • Delete vm-spoke-osdisk from NextWork-Networking if it remains after the VM deletion.
  • Open vnet-nextwork-spoke.
  • Delete vnet-nextwork-spoke.

Removing vnet-nextwork-spoke also removes snet-spoke plus the 10.30.0.0/16 and 10.31.0.0/16 address spaces.

  • Return to NextWork-Networking.
  • Confirm vm-spoke no longer appears.
  • Confirm vm-spoke-nic no longer appears.
  • Confirm vm-spoke-osdisk no longer appears.
  • Confirm vnet-nextwork-spoke no longer appears.
  • Open vnet-nextwork-lab.
  • Confirm Peerings no longer lists lab-to-spoke.
Delete the Entire Lab

Full cleanup removes every resource inside NextWork-Networking. Use this scope only when the resource group contains disposable NextWork lab resources.

  • Return to Resource groups in the Azure portal.
  • Open NextWork-Networking.
  • Review every resource in the group.
  • Confirm every resource belongs to the disposable NextWork lab.
  • Use the resource group's deletion control to delete NextWork-Networking.
  • Return to Resource groups.
  • Confirm NextWork-Networking no longer appears.

Nice Work!

Nice Work!

You did it! You completed Part 6 by connecting two isolated Azure Virtual Networks through regional VNet peering.

What you learned:

  • Recovered a known-good lab baseline from an uncertain Azure subscription. You kept the intact Part 5 resources. You deployed the missing baseline from part6-lab.json when recovery was needed.
  • Captured before-and-after connectivity proof by testing 10.30.1.4 from vm-1. The first test showed isolation. The repeated test returned four replies with 0% packet loss.
  • Created the reciprocal peering links lab-to-spoke and spoke-to-lab. Confirmed both links reached Connected. Traced 10.30.0.0/16 to the Virtual network peering next hop in the vm-1-nic effective routes.
  • Secret Mission: Expanded vnet-nextwork-spoke with 10.31.0.0/16. Synchronized spoke-to-lab. Confirmed the new prefix reached vm-1-nic through Virtual network peering.

Ready to quiz yourself?