Skip to content

Commit 93dedfc

Browse files
authored
Merge pull request #295286 from Abhisht18/main
Added and Updated articles for Subnet Peering
2 parents c02a92c + e0fb973 commit 93dedfc

File tree

5 files changed

+236
-1
lines changed

5 files changed

+236
-1
lines changed
Lines changed: 222 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,222 @@
1+
---
2+
title: Configure subnet peering - Preview
3+
titleSuffix: Azure Virtual Network
4+
description: Learn how to configure subnet peering for an Azure virtual network.
5+
author: amit916new
6+
ms.author: amitmishra
7+
ms.service: azure-virtual-network
8+
ms.topic: how-to
9+
ms.date: 12/03/2024
10+
11+
#customer intent: As a network administrator, I want to configure subnet peering between two virtual networks in azure
12+
13+
---
14+
15+
# How to configure subnet peering - Preview
16+
17+
Subnet peering refers to a method of connecting two virtual networks by linking the subnet address spaces rather than the entire virtual network address spaces. It lets users specify which subnets are supposed to participate in the peering across the local and remote virtual networks.
18+
19+
Subnet peering is an added flexibility built on top of virtual network peering. Users get an option to choose specific subnets that need to be peered across virtual networks. Users can specify or enter the list of subnets across the virtual networks that they want to peer. In contrast, in regular virtual network peering, entire address space/subnets across the virtual networks get peered.
20+
21+
> [!IMPORTANT]
22+
> Subnet peering is currently in public preview.
23+
> This preview version is provided without a service level agreement, and it isn't recommended for production workloads. Certain features might not be supported or might have constrained capabilities.
24+
> For more information, see [Supplemental Terms of Use for Microsoft Azure Previews](https://azure.microsoft.com/support/legal/preview-supplemental-terms/).
25+
26+
The following limitations apply during the public preview:
27+
28+
- Subscription allowlisting: To use this feature, you must have the subscription on which you want to configure subnet peering be registered. Fill this [form](https://forms.office.com/r/99J2fSfd9L) to get your subscription registered. For more information about registering preview features in your subscription, see [Set up preview features in Azure subscription](/azure/azure-resource-manager/management/preview-features).
29+
30+
- Availability: The feature is available in all regions, however, it can be configured via Terraform, PowerShell, API, CLI, and ARM template only.
31+
32+
## Prerequisites
33+
34+
- An Azure account with an active subscription. [Create an account for free](https://azure.microsoft.com/free/?WT.mc_id=A261C142F).
35+
36+
- Register your subscription as per the process mentioned to allowlist the subscription to access the feature.
37+
38+
## Configure subnet peering
39+
40+
- The how-to article requires version 2.31.0 or later of the Azure CLI. If using Azure Cloud Shell, the latest version is already installed.
41+
42+
In the existing virtual network peering create process, few new optional parameters are introduced. This is the description/reference of each:
43+
44+
### New optional parameters introduced:
45+
46+
- **--peer-complete-vnet**
47+
This parameter would let users exercise an option to select subnet peering. By default the value for this parameter is set to true, which means entire virtual networks are peered (all address spaces/subnets). To use subnet peering, this parameter needs to be set to false.
48+
Accepted values: 0, 1, f, false, n, no, t, true, y, yes
49+
Default value: True
50+
51+
- **--local-subnet-names**
52+
This parameter lets users enter local subnet names they want to peer with the remote subnets when subnet peering is enabled by setting “peer-complete-vnet’ parameter as 0
53+
54+
- **--remote-subnet-names**
55+
This parameter would let users enter remote subnet names they want to peer with the local subnets when subnet peering is enabled by setting “peer-complete-vnet’ parameter as 0
56+
57+
- **--enable-only-ipv6**
58+
This parameter would let users exercise an option to 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.
59+
Accepted values: 0, 1, f, false, n, no, t, true, y, yes
60+
61+
```azurecli
62+
az network vnet peering create --name
63+
--remote-vnet
64+
--resource-group
65+
--vnet-name
66+
[--allow-forwarded-traffic {0, 1, f, false, n, no, t, true, y, yes}]
67+
[--allow-gateway-transit {0, 1, f, false, n, no, t, true, y, yes}]
68+
[--allow-vnet-access {0, 1, f, false, n, no, t, true, y, yes}]
69+
[--no-wait {0, 1, f, false, n, no, t, true, y, yes}]
70+
[--use-remote-gateways {0, 1, f, false, n, no, t, true, y, yes}]
71+
[--peer-complete-vnet {0, 1(default), f, false, n, no, t, true, y, yes}]
72+
[--enable-only-ipv6 {0(default), 1, f, false, n, no, t, true, y, yes}]
73+
[--local-subnet-names]
74+
[--remote-subnet-names]
75+
76+
```
77+
78+
1. Use [az group create](/cli/azure/group#az_group_create) to create a resource group named **test-rg** in the **eastus2** location.
79+
80+
```azurecli
81+
az group create \
82+
--name test-rg \
83+
--location eastus2
84+
```
85+
86+
1. Use [az network vnet create](/cli/azure/network/vnet#az_network_vnet_create) to create two virtual networks vnet-1 and vnet-2.
87+
88+
```azurecli
89+
az network vnet create \
90+
--name vnet-1 \
91+
--resource-group test-rg \
92+
--location eastus2 \
93+
--address-prefix 10.0.0.0/16 && \
94+
az network vnet create \
95+
--name vnet-2 \
96+
--resource-group test-rg \
97+
--location eastus2 \
98+
--address-prefix 10.1.0.0/16
99+
```
100+
101+
1. Use [az network vnet subnet create](/cli/azure/network/vnet/subnet#az_network_vnet_subnet_create) to create a subnet with multiple prefixes.
102+
103+
```azurecli
104+
az network vnet subnet create \
105+
--name subnet-1 \
106+
--resource-group test-rg \
107+
--vnet-name vnet-1 \
108+
--address-prefix 10.0.1.0/24 && \
109+
az network vnet subnet create \
110+
--name subnet-2 \
111+
--resource-group test-rg \
112+
--vnet-name vnet-1 \
113+
--address-prefix 10.0.2.0/24 && \
114+
az network vnet subnet create \
115+
--name subnet-3 \
116+
--resource-group test-rg \
117+
--vnet-name vnet-2 \
118+
--address-prefix 10.1.1.0/24 && \
119+
az network vnet subnet create \
120+
--name subnet-4 \
121+
--resource-group test-rg \
122+
--vnet-name vnet-2 \
123+
--address-prefix 10.1.2.0/24
124+
```
125+
126+
1. After creating the required subnets, let's say we want to connect only subnet-1 from vnet-1 and subnet-3 from vnet-2, instead of peering the entire virtual network. For this, we use the optional parameters described above to achieve this.
127+
For this, we run the virtual network peering create command with the optional parameters.
128+
```azurecli
129+
az network vnet peering create --name vnet-1_to_vnet-2
130+
--resource-group test-rg
131+
--vnet-name vnet-1
132+
--remote-vnet vnet-2
133+
--allow-forwarded-traffic
134+
--allow-gateway-transit
135+
--allow-vnet-access
136+
--peer-complete-vnet false
137+
--local-subnet-names subnet-1
138+
--remote-subnet-names subnet-3
139+
az network vnet peering create --name vnet-2_to_vnet-1
140+
--resource-group test-rg
141+
--vnet-name vnet-2
142+
--remote-vnet vnet-1
143+
--allow-forwarded-traffic
144+
--allow-gateway-transit
145+
--allow-vnet-access
146+
--peer-complete-vnet false
147+
--local-subnet-names subnet-3
148+
--remote-subnet-names subnet-1
149+
```
150+
**Add a new subnet to peering**
151+
```azurecli
152+
az network vnet peering update --name vnet-1_to_vnet-2
153+
--resource-group test-rg
154+
--vnet-name vnet-1
155+
--local-subnet-names subnet-1 subnet-2
156+
az network vnet peering update --name vnet-2_to_vnet-1
157+
--resource-group test-rg
158+
--vnet-name vnet-2
159+
--remote-subnet-names subnet-3 subnet-4
160+
```
161+
**Remove subnets from peering**
162+
```azurecli
163+
az network vnet peering update --name vnet-1_to_vnet-2
164+
--resource-group test-rg
165+
--vnet-name vnet-1
166+
--local-subnet-names subnet-1
167+
az network vnet peering update --name vnet-2_to_vnet-1
168+
--resource-group test-rg
169+
--vnet-name vnet-2
170+
--remote-subnet-names subnet-3
171+
```
172+
**Sync peerings**
173+
```azurecli
174+
az network vnet peering sync --name vnet-1_to_vnet-2
175+
--resource-group test-rg
176+
--vnet-name vnet-1
177+
az network vnet peering sync --name vnet-2_to_vnet-1
178+
--resource-group test-rg
179+
--vnet-name vnet-2
180+
```
181+
**Show peerings**
182+
```azurecli
183+
az network vnet peering show --name vnet-1_to_vnet-2
184+
--resource-group test-rg
185+
--vnet-name vnet-1
186+
az network vnet peering show --name vnet-2_to_vnet-1
187+
--resource-group test-rg
188+
--vnet-name vnet-2
189+
```
190+
191+
## Subnet peering checks and limitations
192+
193+
The following diagram displays the checks performed while configuring subnet peering and current limitations.
194+
195+
:::image type="content" source=".\media\how-to-configure-subnet-peering\subnet-peering.png" alt-text="Diagram that shows subnet peering.":::
196+
197+
1. The participating subnets **must be unique** and **must belong to unique address spaces**.
198+
- 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.
199+
- 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.
200+
201+
1. 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 the same peering link is required to be updated. **Multiple exclusive peering between set of subnets are not possible**.<br>
202+
**A given peering link type cannot be changed**. If there's a virtual network peering between virtual network A and virtual network B, and the user wants to change that to subnet peering, the existing virtual network peering link must be deleted, and a new peering must be created with the required parameters for subnet peering and vice versa.
203+
204+
1. **Number of subnets that can be part of a peering link should be less than or equal to 400 (200 limit from each local and remote side).**
205+
- For example, in the virtual network A and virtual network B peering link (illustrated by blue arrow headed line), total number of subnets participating in the peering here's 4 (two from virtual network A and two from virtual network B side). This number should be <=400.
206+
207+
1. In the present release (Public preview, 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, but it will still have route for Subnet 1 and Subnet 2 in virtual network B.
208+
- In the subnet peering for virtual network A and virtual network B, customer 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 which 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.
209+
210+
- It's recommended that users apply NSGs on the participating subnets to allow traffic from only peered subnets/address spaces. This limitation will be removed in the post GA release.
211+
212+
1. Subnet Peering and AVNM
213+
- Connected Group<br>
214+
If two virtual networks are connected in 'Connected Group', and if Subnet peering is configured over these two virtual networks, subnet peering takes preference and the connectivity between nonpeered subnets gets dropped.
215+
- AVNM Connectivity Configuration<br>
216+
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 would assume that peering between virtual network A and virtual network B already exists and would ignore the new peering request. We recommend that users exercise caution in such conflicting scenarios while using AVNM and Subnet peering
217+
218+
## Next steps
219+
220+
Subnet peering helps you have better conservation of IPv4 space, by letting you reuse address spaces across subnets that need not be peered. It also prevents unnecessary exposure of entire virtual network address space through gateways to on-premises environments. With IPv6 only peering, you can further configure peering over IPv6 only for dual-stack subnets or IPv6 only subnets. Explore these capabilities and let us know if you have feedback and suggestions here.
221+
222+
To learn more about peering, see [Virtual network peering](./virtual-network-peering-overview.md).

articles/virtual-network/index.yml

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -138,6 +138,8 @@ landingContent:
138138
url: /azure/virtual-network/how-to-multiple-prefixes-subnet
139139
- text: Update address space for a virtual network peer
140140
url: /azure/virtual-network/update-virtual-network-peering-address-space
141+
- text: Configure subnet peering
142+
url: /azure/virtual-network/how-to-configure-subnet-peering
141143
# Card
142144
- title: Network foundation
143145
linkLists:
52.7 KB
Loading

articles/virtual-network/toc.yml

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -134,6 +134,8 @@
134134
href: virtual-network-manage-peering.md
135135
- name: Update the address space for a peered virtual network
136136
href: update-virtual-network-peering-address-space.yml
137+
- name: Configure subnet peering
138+
href: how-to-configure-subnet-peering.md
137139
- name: Routing
138140
items:
139141
- name: Manage route tables

articles/virtual-network/virtual-network-peering-overview.md

Lines changed: 10 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -33,6 +33,15 @@ The benefits of using virtual network peering, whether local or global, include:
3333

3434
Network traffic between peered virtual networks is private. Traffic between the virtual networks is kept on the Microsoft backbone network. No public internet, gateways, or encryption are required in the communication between the virtual networks.
3535

36+
We recently introduced an added flexibility on top of virtual network peering - '**Subnet peering**'.
37+
38+
It's an added flexibility built on top of virtual network peering, where users get an option to choose specific subnets that need to be peered across virtual networks. Users can specify/enter the list of subnets across the virtual networks that they want to peer. In contrast, in regular virtual network peering, entire address space/subnets across the virtual networks get peered. For more information, see [How to configure Subnet Peering](how-to-configure-subnet-peering.md).
39+
40+
> [!IMPORTANT]
41+
> Subnet peering is currently in preview.
42+
> This preview version is provided without a service level agreement, and it's not recommended for production workloads. Certain features might not be supported or might have constrained capabilities.
43+
> For more information, see [Supplemental Terms of Use for Microsoft Azure Previews](https://azure.microsoft.com/support/legal/preview-supplemental-terms/).
44+
3645
## Connectivity
3746

3847
For peered virtual networks, resources in either virtual network can directly connect with resources in the peered virtual network.
@@ -117,7 +126,7 @@ A nominal fee is charged for ingress and egress traffic that uses a virtual netw
117126
Gateway transit is a peering property that enables a virtual network to use a virtual private network or an ExpressRoute gateway in a peered virtual network. Gateway transit works for both cross-premises and network-to-network connectivity. Traffic to the gateway (ingress or egress) in the peered virtual network incurs virtual network peering charges on the spoke virtual network (or virtual network without a VPN gateway). For more information, see [Azure VPN Gateway pricing](https://azure.microsoft.com/pricing/details/vpn-gateway/) for VPN gateway charges and ExpressRoute gateway charges.
118127

119128
>[!NOTE]
120-
> A previous version of this document stated that virtual network peering charges would not apply on the spoke virtual network (or non-gateway virtual network) with gateway transit. It now reflects accurate pricing per the pricing page.
129+
> A previous version of this document stated that virtual network peering charges wouldn't apply on the spoke virtual network (or nongateway virtual network) with gateway transit. It now reflects accurate pricing per the pricing page.
121130
122131
## Related content
123132

0 commit comments

Comments
 (0)