How to configure subnet peering
Subnet peering connects two virtual networks by linking specific subnets instead of entire virtual network address spaces. This approach gives you granular control over which subnets participate in the peering relationship between local and remote virtual networks. Subnet peering adds flexibility to
1h ago
Subnet peering connects two virtual networks by linking specific subnets instead of entire virtual network address spaces. This approach gives you granular control over which subnets participate in the peering relationship between local and remote virtual networks.
Subnet peering adds flexibility to virtual network peering. You can choose specific subnets to peer across virtual networks. You specify or enter the list of subnets across the virtual networks that you want to peer. In contrast, regular virtual network peering connects entire address spaces and subnets across the virtual networks.
The following limitations apply when using subnet peering:
Subscription allowlisting: To use this feature, you must register the subscription on which you want to configure subnet peering. Fill this form to get your subscription registered.
Availability: The feature is available in all regions. However, you can configure it only through Terraform, PowerShell, API, CLI, and ARM template.
Prerequisites
An Azure account with an active subscription. Create an account for free.
To enable access to this feature, register your subscription through the allowlisting process
Configure subnet peering
- This article requires version 2.31.0 or later of the Azure CLI. If you use Azure Cloud Shell, the latest version is already installed.
In the existing virtual network peering creation process, a few new optional parameters are introduced. This section describes each parameter:
New optional parameters
--peer-complete-vnet
Select subnet peering. By default, the value for this parameter is set to true, which means the entire virtual networks are peered (all address spaces and subnets). To use subnet peering, set this parameter to false.
Accepted values: 0, 1, f, false, n, no, t, true, y, yes
Default value: True--local-subnet-names
Enter local subnet names you want to peer with the remote subnets when subnet peering is enabled by setting thepeer-complete-vnetparameter to 0.--remote-subnet-names
Enter remote subnet names you want to peer with the local subnets when subnet peering is enabled by setting thepeer-complete-vnetparameter to 0.--enable-only-ipv6
Configure subnet peering over IPv6 address space only (for dual stack subnets). By default, the value for this parameter is set to false. Peering is done over IPv4 addresses by default. If set to true, peering is done over IPv6 in dual stack subnets.
Accepted values: 0, 1, f, false, n, no, t, true, y, yes
az network vnet peering create --name
--remote-vnet
--resource-group
--vnet-name
[--allow-forwarded-traffic {0, 1, f, false, n, no, t, true, y, yes}]
[--allow-gateway-transit {0, 1, f, false, n, no, t, true, y, yes}]
[--allow-vnet-access {0, 1, f, false, n, no, t, true, y, yes}]
[--no-wait {0, 1, f, false, n, no, t, true, y, yes}]
[--use-remote-gateways {0, 1, f, false, n, no, t, true, y, yes}]
[--peer-complete-vnet {0, 1(default), f, false, n, no, t, true, y, yes}]
[--enable-only-ipv6 {0(default), 1, f, false, n, no, t, true, y, yes}]
[--local-subnet-names]
[--remote-subnet-names]
Use az group create to create a resource group named test-rg in the eastus2 location.
az group create \ --name test-rg \ --location eastus2Use az network vnet create to create two virtual networks named vnet-1 and vnet-2.
az network vnet create \ --name vnet-1 \ --resource-group test-rg \ --location eastus2 \ --address-prefix 10.0.0.0/16 && \ az network vnet create \ --name vnet-2 \ --resource-group test-rg \ --location eastus2 \ --address-prefix 10.1.0.0/16Use az network vnet subnet create to create a subnet with multiple prefixes.
az network vnet subnet create \ --name subnet-1 \ --resource-group test-rg \ --vnet-name vnet-1 \ --address-prefix 10.0.1.0/24 && \ az network vnet subnet create \ --name subnet-2 \ --resource-group test-rg \ --vnet-name vnet-1 \ --address-prefix 10.0.2.0/24 && \ az network vnet subnet create \ --name subnet-3 \ --resource-group test-rg \ --vnet-name vnet-2 \ --address-prefix 10.1.1.0/24 && \ az network vnet subnet create \ --name subnet-4 \ --resource-group test-rg \ --vnet-name vnet-2 \ --address-prefix 10.1.2.0/24After creating the required subnets, you might want to connect only subnet-1 from vnet-1 and subnet-3 from vnet-2, instead of peering the entire virtual network. To achieve this configuration, use the optional parameters described earlier.
Run the virtual network peering create command with the optional parameters.az network vnet peering create --name vnet-1_to_vnet-2 --resource-group test-rg --vnet-name vnet-1 --remote-vnet vnet-2 --allow-forwarded-traffic --allow-gateway-transit --allow-vnet-access --peer-complete-vnet false --local-subnet-names subnet-1 --remote-subnet-names subnet-3 az network vnet peering create --name vnet-2_to_vnet-1 --resource-group test-rg --vnet-name vnet-2 --remote-vnet vnet-1 --allow-forwarded-traffic --allow-gateway-transit --allow-vnet-access --peer-complete-vnet false --local-subnet-names subnet-3 --remote-subnet-names subnet-1Add a new subnet to peering
az network vnet peering update --name vnet-1_to_vnet-2 --resource-group test-rg --vnet-name vnet-1 --local-subnet-names subnet-1 subnet-2 az network vnet peering update --name vnet-2_to_vnet-1 --resource-group test-rg --vnet-name vnet-2 --remote-subnet-names subnet-3 subnet-4Remove subnets from peering
az network vnet peering update --name vnet-1_to_vnet-2 --resource-group test-rg --vnet-name vnet-1 --local-subnet-names subnet-1 az network vnet peering update --name vnet-2_to_vnet-1 --resource-group test-rg --vnet-name vnet-2 --remote-subnet-names subnet-3Sync peerings
az network vnet peering sync --name vnet-1_to_vnet-2 --resource-group test-rg --vnet-name vnet-1 az network vnet peering sync --name vnet-2_to_vnet-1 --resource-group test-rg --vnet-name vnet-2Show peerings
az network vnet peering show --name vnet-1_to_vnet-2 --resource-group test-rg --vnet-name vnet-1 az network vnet peering show --name vnet-2_to_vnet-1 --resource-group test-rg --vnet-name vnet-2
Subnet peering checks and limitations
The following diagram displays the checks performed while configuring subnet peering and current limitations.
Open diagram: Diagram that shows subnet peering.
The participating subnets must be unique and must belong to unique address spaces across all peering links.
- For example, in the virtual network A and virtual network C peering (illustrated in the figure by black arrow headed line) virtual network A can't subnet peer over Subnet 1, Subnet 2, and Subnet 3 with any of the subnets in virtual network C, as these subnets of virtual network A belong to the 10.1.0.0/16 address space, which is also present in virtual network C.
- However, virtual network A’s Subnet 4 (10.0.1.0/24) can subnet peer with Subnet 5 in virtual network C (10.6.1.0/24) as these subnets are unique across the virtual networks and they belong to unique address spaces across virtual networks. Subnet 4 belongs to 10.0.0.0/16 address space in virtual network A and Subnet 5 belongs to 10.6.0.0/16 address space in virtual network C.
- With the subnet peering configuration in the diagram above, virtual network B's subnet 3 (10.2.3.0./24) can't subnet peer over Subnet 1 in virtual network C, because the latter overlaps with subnet 1 in virtual network A that is already subnet peered with virtual network B, regardless virtual network B's subnet 3 is not parcipating in the subnet peering with virtual network A.
There can be only one peering link between any two virtual networks. If you want to add or remove subnets from the peering link, then you need to update the same peering link. Multiple exclusive peering between set of subnets aren't possible.
You can't change a given peering link type. If there's a virtual network peering between virtual network A and virtual network B, and you want to change that peering to subnet peering, you must delete the existing virtual network peering link and create a new peering with the required parameters for subnet peering and vice versa.The number of subnets participating in a single peering link is limited to 200 per side (200 from the local virtual network and 200 from the remote virtual network). Additionally, the total number of subnets that can be peered across all peering links for a given virtual network shouldn't exceed 1,000.
- For example, in the virtual network A and virtual network B peering link (illustrated by blue arrow headed line), the total number of subnets participating in the peering from VNET A should be <=200 and likewise from the VNET B side should be <= 200.
- The total number of subnets across all the spokes (VNET B and VNET C) that can be peered with VNET A should be <= 1000. In the figure above it's 3 in total (2 from VNET B side, 1 from VNET C side)
In the present release (feature remains behind subscription flag), forward route from non-peered subnet to peered subnet exists - In the current scenario virtual network A and virtual network B peering, even though Subnet 2 from virtual network A side isn't peered, it still has route for Subnet 1 and Subnet 2 in virtual network B.
In the subnet peering for virtual network A and virtual network B, you would expect only Subnet 1 and Subnet 3 from virtual network A to have route for Subnet 1 and Subnet 2 in remote virtual network B. However, Subnet 2 and Subnet 4 (from local side virtual network A isn't peered) also have route for Subnet 1 and Subnet 2 in remote side (virtual network B), meaning the nonpeered subnets can send packet to destination node in the peered subnet, although the packet is dropped and doesn't reach the virtual machine.
We recommend that you apply NSGs on the participating subnets to allow traffic from only the peered subnets and address spaces. This limitation is removed in the post GA release.
Delegated subnets: over-advertisement of routes for certain delegated subnets
In addition to peered subnets, routes associated with the following delegated subnet types might be over-advertised. As a result, the route prefixes for these delegated subnets can appear in the effective route tables of VMs located in peered subnets, even when the delegated subnet itself isn't directly participating in the peering relationship.
This behavior might lead to unexpected route visibility and routing outcomes in subnet peering scenarios.
The following delegated subnet types are affected:
Microsoft.NetApp/volumesMicrosoft.HardwareSecurityModules/dedicatedHSMsMicrosoft.BareMetal/CrayServersMicrosoft.BareMetal/MonitoringServersMicrosoft.BareMetal/AzureHostedServiceMicrosoft.BareMetal/AzureVMwareMicrosoft.BareMetal/AzureHPCMicrosoft.BareMetal/AzurePaymentHSMMicrosoft.Apollo/npuMicrosoft.Singularity/accounts/npuOracle.Database/networkAttachments
Example: If a virtual network contains one of the preceding delegated subnet types, the delegated subnet's address prefixes might be propagated to the route tables of VMs in a remotely peered subnet, even though that delegated subnet isn't explicitly peered. This results in the delegated subnet being effectively over-advertised across the peering boundary.
Subnet Peering and AVNM
- Connected Group
If two virtual networks are connected in 'Connected Group', and if you configure Subnet peering over these two virtual networks, subnet peering takes preference and the connectivity between nonpeered subnets gets dropped. - AVNM Connectivity Configuration
AVNM today can't differentiate between virtual network peering and subnet peering. If Subnet peering exists between virtual network A and virtual network B, and later an AVNM user tries to establish a virtual network peering between virtual network A and virtual network B through some AVNM connectivity configuration (Hub and Spoke deployment), AVNM assumes that peering between virtual network A and virtual network B already exists and ignores the new peering request. Exercise caution in such conflicting scenarios while using AVNM and Subnet peering.
- Connected Group
Hard limitation: If you are planning to use the feature in production, you must use Intel based V5 SKUs/migrate to V5 SKUs (Intel based 5th generation of VM SKUs, or AMD Genoa or Cobalt 100 based SKUs) to avoid possible outage due to a bug seen on older gen SKUs.
azure