I recently had a scenario where I wanted to add an address space to a Virtual Network and encountered an issue where it was not possible to modify the address space while VNet Peering was in use. This is likely due to the fact that the routes to the peered VNet that are applied through the peering only get updated at the time the peer is created and cannot be dynamically updated.
The following error detailed this.
Failed to save virtual network changes Failed to save address space changes to virtual network ‘vnet1’. Error: Address space of the virtual network /subscriptions/xxxxxxx/resourceGroups/rg1/providers/Microsoft.Network/virtualNetworks/vnet1 cannot change when virtual network has peerings.
On the surface this isn’t a big deal, just delete the peering, modify the address space and re-create the peering. While the actual requirements to achieve the changes is straight forward the VNet I was working with was a Hub VNet, as such there were multiple VNet peerings in place to spoke VNets. Additionally, there was no documentation available on all of the configurations specific to the peering.
I wanted to export all of the peering configurations so that I had a backup and record of the configurations so that they could be re-applied the same way after the address space was added to the Hub network.
Exporting VNet Peering Configuration
The following snippet, will export all of the peering configurations for the VNet specified to a file named “vnetname-peerings.csv”. The configurations recorded for the peering include:
Important Note: Removing the VNet peering will disrupt communication between the VNets. You should plan for and accommodate this within your change control processes.
Now that that all of the peering configurations were exported, we can proceed to delete the peering and then make the required modifications to the address space.
Re-create VNet Peering Configuration
After the modifications were applied to the VNet, we are ready to re-create the peering configuration using the exported configuration. You can do this from the portal or PowerShell. In my example, I simply re-added it from the Portal using the values recorded from the exported CSV. If you wanted to use PowerShell the Add-AzureRmVirtualNetworkPeering command can be used, substituting the values that were exported into the CSV.
However, when I saved the configuration the following error was produced:
Failed to add virtual network peering ‘peer1’. Error: Cannot create or update peering /subscriptions/xxxxxxx/resourceGroups/rg1/providers/Microsoft.Network/virtualNetworks/vnet1/virtualNetworkPeerings/peer1 because remote peering /subscriptions/xxxxxxx/resourceGroups/rg2/providers/Microsoft.Network/virtualNetworks/vnet3/virtualNetworkPeerings/peer1 referencing parent virtual network /subscriptions/xxxxxxx/resourceGroups/rg1/providers/Microsoft.Network/virtualNetworks/vnet1 is in Disconnected state. Update or re-create the remote peering to get it back to Initiated state. Peering gets Disconnected when remote vnet or remote peering is deleted and re-created.
The reason for this error is that the corresponding peering on the remote VNet was in a disconnected state.
As the error suggests you have 2 options to resolve this, update or re-create the peering to get it back into the initiated state. Once this is done we can then create the peering in the parent VNet. You could use the script snippet above to backup the peering configuration and then delete and re-create it. However the easiest option is just to update the peering using the following command:
Get-AzureRmVirtualNetworkPeering -VirtualNetworkName vnet3 -ResourceGroupName rg2 | Set-AzureRmVirtualNetworkPeering
Once this is done, if you check the remote peering you will see that it is back in the initiated state and ready for the remote peering to establish the connection.
We can now finish by creating the peering configuration and both sides of the peering will now show as connected.