The peering can be intra-region (the one that we are going to work on in this article) but can also be configured between different regions, also known as Global VNet Peering, which allows any medium to larger enterprise to rely on Azure backbone to connect two distant datacenters anywhere on the globe. If you are planning to take the AZ-300 exam, then you should be acquainted with this topic and be able to create your peering settings using Azure Portal because that exam has lab included
In a distant past, when configuring interoperability among your virtual networks in Azure, the only way to connect them was by using a VPN gateway, which would increase costs and complexity because additional resources and infrastructure were required. Nowadays, Azure offers several options to make a connection between your virtual networks, and Microsoft peering has become the first option because it has a lower cost compared with all other options, it does not require additional resources, and uses Microsoft backbone to transfer data between any given two VNets.
The peering can be intra-region (the one that we are going to work on this article) but can also be configured between different regions, also known as Global VNet Peering, which allows any medium to larger enterprise to rely on Azure backbone to connect two distant datacenters in the globe. If you are planning to take the AZ-300 exam, then you should be acquainted with this topic and be able to create your peering settings using Azure Portal because that exam has lab included.
Before going to the technical details to get our Microsoft peering working, I would like to highlight some of the critical points about peering, as follows:
We are going to create a typical design in Azure: the hub and spoke topology. In this scenario, we have a VNet and shared infrastructure, and one or more “spokes,” which could be a specific workload/application, and they will have their VNet as well. All the items in orange will be the ones that we are going to introduce to get Microsoft peering and DNS resolution working among the virtual networks.
We created three resource groups, one for the hub and two to be used as spoke. A virtual network was created for each spoke and hub. Here is a summary of the virtual networks being used in this article, as well an image showing the VNet creation.
|Address Range||Resource Group|
Logged on the Azure Portal, click on Virtual Networks, and a list of all VNets in the current subscription will be listed. Select the Hub VNet (in our example is AP-VNet-Hub), and click on Peering located on the left side.
In the new blade, a list of any existent peering will be listed, click on Add to get a new blade that will contain all the required information to create the peering.
In a single blade, we will be able to configure the Microsoft peering on both sides (source and target). Keep in mind that we are checking properties of the HUB VNet. In the first item (item 1) we define the peering name that will be hosted in our current VNet (AP-VNet-Hub), in the item 3 we describe the name on the other side (from the Application1 VNet to Hub), and that is the reason that we switched the names at the end of the string, because they are based on the source VNet.
In item 2, we select the VNet that we are going to be peering with our existent VNet. Items 4 and 5, give us options to enable the peering and allow forwarded traffic.
Having a VM running on the hub network, we can ping a VM in the Application1 VNet as soon as the peering is established.
Now that we have the VNet peering working, we need to resolve the name resolution for VMs in different VNetS, we tested, and they can communicate.
The first step is to create a Private DNS zone, the feature is still in preview, but it is in working conditions for the vast majority of the scenarios. We are going to create an internal zone called PEnterprise.local to place all the VMs in our environment.
The following cmdlet can be used to create the zone, and the result will be a new DNS Zone resource being listed in the Resource Group that we defined during the creation of the DNZ zone.
New-AZDNSZone -Name PEnterprise.local -ResourceGroupName <RGName> -ZoneType Private
We could configure the Private DNS Zone manually. However, we can assign VNet as registration which automatically registers new VMs in the DNS, and resolution where VMs on that VNet can search DNS automatically and retrieve information.
There are some restrictions in the current preview of this feature, as follows:
Note: We are still in preview, and the registration and resolution parameters only work with empty VNets, and at this point, there is no support for existent networks. The team that takes care of the feature is aware of it and working on it.
Although we cannot associate more than a single VNet in the automatic registration feature at this time, we can always add entries in the DNS Zone (if you have time, you can create a RunBook to do just that, I see another topic for an upcoming article).
In the following cmdlets, we are going to associate the Application6 VNet with registering automatically, and the remaining Spoke, and Hub will be associated to the Resolution.
$dns = Get-AzDnsZone -Name <ZoneName> -ResourceGroupName <Resource-Group-Name> Get-AZVirtualNetwork | fl Name,ID $dns.RegistrationVirtualNetworkIds.Add(‘VNet-ID’) $dns.ResolutionVirtualNetworkIds.Add(‘VNet-ID’) $dns | set-AzDNSZone
The final result of the DNS Zone properties is depicted in the image below.
Time to test the solution, we are going to create a couple of VMs and associate to our Application6 VNet and Application1 VNet.
After provisioning the test VMs (the OS doesn’t matter for this exercise), we will try to ping from a VM located in the Application1 to a VM located in the Application6. We can see that the name resolution worked without any manual steps, which means that the automatic registration worked and the resolution parameters worked as expected.
Another way to see the VNet peering in action is by looking at Effective routes at the interface level. We should have an entry for each VNet peering configured with the VNet where the VM resides, as depicted in the image below.
Featured image: Shutterstock
Managed Service Providers are in the crosshairs of hackers because the bad guys know MSPs hold a lot of sensitive…
Here’s a Quick Tip that will show you how to link an Azure Automation and Log Analytics workspace even if…
Expedite the process of creating several virtual machines with a PowerShell script that builds VMs based on the contents of…
Do you provision VMs regularly? This step-by-step guide shows you a way to do it quickly that will save you…
While Kubernetes is already the No. 1 container orchestration tool, a custom resource definition, or CRD, adds incredible custom features…
Here’s another in our popular Quick Tips series. This one focuses on PowerShell and how it can help you get…