Introducing Subnet Peering in Azure

Subnet peering refers to a method of connecting two Virtual Networks (VNETs) by linking only the subnet address spaces rather than the entire VNET address spaces. It lets users specify which subnets are supposed to participate in the peering across the local and remote vnet.

It is an added flexibility built on top of VNET peering, where users get an option to choose specific subnets that need to be peered across VNETS. User can enter the list of subnets across the VNETS that they want to peer. In contrast, in the case of regular VNET peering, entire address space/subnets across the VNETS get peered.

Note: The feature is available in TF, CLI, API, ARM, PS across all regions. The feature is being rolled out to selected customers on need basis. To use it, you would need to allowlist your subscription. Please fill this form to get your subscription registered. 

Key customer use cases:

1.  Peering subnets across VNets having overlapping address space (given the subnets to be peered are having unique addresses and belong to unique address spaces – typical scenario below depicts a hub and spoke model). Refer the image below:

2. Peering subnets over IPv6 only in case of dual stack subnets - With subnet peering, users get an option to peer over IPv6 address space when they have dual stack subnets across the local and remote VNETS. This would enable customers to rely on IPv6 for peering connectivity. Refer image below:

3. Gateway scenarios related to on-prem connectivity, where admins would want to expose certain subnets only to the on-prem and not all. Refer the image below:

Subnet peering - Checks and Limitations

We would like to discuss few critical aspects wrt. subnet peering in the present release. For this consider the following setup of three VNETS, where VNET A is subnet peered with VNET B and with VNET C.

Subnet Peering illustration

Key points to note are:

1. The participating subnets must be unique and must belong to unique address spaces.
   For example, in the VNET A and VNET C peering illustrated in the above figure (black arrow headed line) VNET A cannot subnet peer over Subnet 1, Subnet 2 and Subnet 3 with any of the subnets in VNET C as VNET C, as these subnets of VNET A belong to 10.1.0.0/16 Address space which is also present in VNET C.
   However, VNET A’s Subnet 4 (10.0.1.0/24) can still subnet peer with Subnet 5 in VNET C (10.6.1.0/24) as these subnets are unique across the VNETS and they belong to unique address spaces across VNETS. Note that Subnet 4 belongs to 10.0.0.0/16 address space in VNET A and Subnet 5 belongs to 10.6.0.0/16 address space in VNET C.

2. There can be only one peering link between any two VNETS. If you want to add, remove subnets from the peering link, then the same peering link will be required to be updated. This also means multiple exclusive peering between set of subnets are not possible.
   Also, a given peering link type cannot be changed. That means, if there is a VNET peering between VNET A and VNET B, and user wants to change that to subnet peering, the existing VNET peering link needs to be deleted, and new peering needs to be created with the required parameters for subnet peering and vice versa.
3. Number of subnets that can be part of the peering link should be less than or equal to 400 (200 limit on each local and remote side). For example, in the VNET A and VNET B peering link (illustrated by blue arrow headed line), total number of subnets participating in the peering here is 4 (two from VNET A and two from VNET B side). This number should be <=400.

4. In the present release (Public preview and GA March 2025, feature will remain behind subscription flag), forward route from non-peered subnet to peered subnet exists- i.e. in the current scenario for VNET A and VNET B peering, even though Subnet 2 from VNET A side is not peered, but it will still have route for Subnet 1 and Subnet 2 in VNET B.
   
   To clarify more, in the subnet peering for VNET A and VNET B above, customer would expect only Subnet 1 and Subnet 3 from VNET A to have route for Subnet 1 and Subnet 2 in remote VNET B, however,  Subnet 2 and Subnet 4 (from local side VNET A which are not peered) also have route for Subnet 1 and Subnet 2 in remote side (VNET B), although the packet gets dropped and do not reach VM.

   This limitation will be removed in the post GA release. 

5. Subnet Peering and AVNM
   Connected Group
   Note that if two VNETs are connected in 'Connected Group', and if Subnet peering is configured over these two VNETS, subnet peering takes preference and the connectivity between non-peered subnets gets dropped.
   AVNM Connectivity Configuration
   AVNM today cannot differentiate between VNET peering and Subnet peering. So let's say if Subnet peering exists between VNET A and VNET B, and later an AVNM user tries to establish a VNET peering between VNET A and VNET B through some connectivity configuration (say Hub and Spoke deployment), AVNM would assume that peering between VNET A and VNET B already exists and would ignore the new peering request. We recommend users to exercise caution in such conflicting scenarios while using AVNM and Subnet peering
6. Subnet Peering and Virtual WAN: Currently Azure Virtual WAN does not support subnet peering. 

Note: The feature is being rolled out to selected customers on need basis.

To use it, you would need to allowlist your subscription. Please fill this form to get your subscription registered.

How to configure subnet peering?

In the existing vnet peering create process, few new optional parameters are introduced (refer A to D below).

Below is the description/reference of each:

A.

--peer-complete-vnet

This parameter would let user select subnet peering. By default, the value for this parameter is set to true, which means entire vnet is peered (all address spaces/subnets across the VNETS). To enable subnet peering, this parameter needs to be set to false (0/f/n/no)

accepted values: 0, 1, f, false, n, no, t, true, y, yes

default value: True

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}]  

B. --local-subnet-names

This parameter lets user enter local subnet names they want to peer with the remote subnets, in case subnet peering is enabled by setting “peer-complete-vnet’ parameter as 

C. --remote-subnet-names

This parameter would let user enter remote subnet names they want to peer with the remote subnets in case subnet peering is enabled by setting “peer-complete-vnet’ parameter as

Sample CLI input:

az network vnet peering create -g MyResourceGroup -n MyVnet1ToMyVnet2 --vnet-name MyVnet1 --remote-vnet MyVnet2Id --allow-vnet-access --peer-complete-vnet 0  --local-subnet-names subnet1 subnet2 --remote-subnet-names subnet1 subnet2

Subnet peering and IPv6 only peering

In addition to above, in case of dual stack subnets, you can also configure IPv6 only peering wherein the engaging subnets interact over IPv6 only.

In case of dual stack subnets, users can choose to peer the subnets over IPv6 address space only. Earlier, entire address spaces across VNETS used to get evaluated before peeing, and if the overlap check gets cleared, entire VNET address spaces get peered, i.e. both IPv4 and IPv6. However, with this release, we are providing an additional flexibility to users on top of Subnet peering, where they can specifically choose to peer over IPv6 address space only.

Note, currently this feature is built on top of subnet peering, and to use this, an additional parameter  'enable-only-ipv6' needs to be set to true in the VNET peering create experience.

D. --enable-only-ipv6

This parameter would let user exercise an option to select subnet peering with only IPv6 peering functionality. By default, the value for this parameter is set to false, which means peering would be done over IPv4 addresses by default. If set to true, peering would be done over IPv6 in case of dual stack subnets

Accepted values: 0, 1, f, false, n, no, t, true, y, yes

Sample CLI input:

az network vnet peering create -g MyResourceGroup -n MyVnet1ToMyVnet2 --vnet-name MyVnet1 --remote-vnet MyVnet2Id --allow-vnet-access --peer-complete-vnet 0 ---enable-only-ipv6 1  --local-subnet-names subnet1 subnet2 --remote-subnet-names subnet1 subnet2

In this case, if the subnets mentioned are dual stack (or IPv6 only subnets in future), then peering would be over IPv6 address space only.

Learn more:

• Azure Virtual Network- VNET peering
• How to configure subnet peering
• Allowlist your subscription- Fill the form to use the feature.
• Questions and concerns: amitmishra@microsoft.com