Nordlicht Reisen GmbH, a fictional travel agency, has two virtual networks: a network hub with shared services and a network spoke-buchung with the booking portal. Both should reach each other over private addresses without using the internet. In addition, the portal's traffic should pass through a device in the hub before it leaves the network. The exam calls this: create and configure virtual network peering and configure user-defined network routes.
Prior knowledge: Lesson 4.1 creates address spaces and subnets. It also states that address ranges must not overlap. What networks and subnets are is covered in "AZ-900 compact", lesson 2.4. Filters for traffic (NSGs) follow in lesson 4.3.
Virtual network peering
Peering connects two virtual networks so that, for the connection, they appear as one network. Traffic runs over the Microsoft backbone and only over private IP addresses, without the internet and without a gateway. Microsoft names these advantages: low latency, high bandwidth, and no downtime for the resources during setup.
| Kind | The networks are located |
|---|---|
| Peering | in the same region |
| Global peering | in different regions |
The networks may be in different subscriptions and even in different Microsoft Entra tenants. For peering you need the Network Contributor role in both subscriptions. For networks in other subscriptions or groups, you give the full resource ID of the partner network in the CLI and PowerShell.
Two links, one state
A peering consists of two links, one per direction. When you add a peering, the portal creates both; with the CLI you run the command twice, with the networks swapped.
| State | Meaning |
|---|---|
| Initiated | only the first link exists; create the second |
| Connected | both links exist, traffic flows |
| Disconnected | one link was deleted; delete the remaining one and create both again |
$hub = az network vnet show --resource-group rg-az104-peering --name vnet-hub --query id --output tsv
$spoke = az network vnet show --resource-group rg-az104-peering --name vnet-spoke --query id --output tsv
az network vnet peering create --resource-group rg-az104-peering --vnet-name vnet-hub --name hub-to-spoke --remote-vnet $spoke --allow-vnet-access
az network vnet peering create --resource-group rg-az104-peering --vnet-name vnet-spoke --name spoke-to-hub --remote-vnet $hub --allow-vnet-access
az network vnet peering show --resource-group rg-az104-peering --vnet-name vnet-hub --name hub-to-spoke --query peeringState
Azure PowerShell: Add-AzVirtualNetworkPeering. In the portal: in the virtual network under Peerings, the entry Add (the portal's wording differs depending on the language setting).
The settings
Each link has four settings. The first two apply to traffic, the others to gateways:
| Setting (CLI switch) | Default | Meaning |
|---|---|---|
Access to the partner network (--allow-vnet-access) |
on in the portal; in the CLI you name the switch explicitly | resources of this network reach those of the partner network |
Allow forwarded traffic (--allow-forwarded-traffic) |
off | the network accepts traffic that did not originate in the partner network but is forwarded from there (for example through a device) |
Gateway transit (--allow-gateway-transit) |
off | the partner network may use this network's gateway |
Use remote gateways (--use-remote-gateways) |
off | this network uses the partner network's gateway; possible only with one peering of the network, and not if the network has a gateway of its own |
The "forwarded traffic" setting creates no routes and no devices. You create routes and devices yourself (see below). Each side configures its own link: if forwarded traffic should flow in both directions, turn the setting on for both links (Microsoft's tutorial sets it on both sides).
Limits
- The networks must have non-overlapping address spaces. Otherwise creating the peering fails.
- Peering is not transitive: if A is peered with B and B with C, A and C are not connected. Every pair needs its own peering, or you route the traffic through a device in the hub (see below).
- A network that is part of a peering cannot be moved to another group or another subscription. Delete the peering first.
- If you change the address space of a peered network, you must then synchronize the peering (
az network vnet peering sync); otherwise it can fall into the Disconnected state. - Over global peering, resources behind a Basic load balancer are not reachable; a Standard load balancer works.
- The charges for peering are on the Virtual Network pricing page.