Azure Network Connectivity and Name Resolution
The course is part of these learning pathsSee 1 more
Learn how to configure Microsoft Azure connectivity and name resolution with this expertly instructed course from Cloud Academy.
In this course, you will learn two different ways to connect virtual networks together. The course starts by teaching you how to set up peering between virtual networks and then moves on to showing you how to connect two VNets using a virtual network gateway. Once you have mastered network connections, you will learn how to use Azure DNS to configure custom domain names for the resources in your VNets. Finally, we will move on to learning how to set up both public and private DNS zones.
This course is essential for those looking to train enterprise teams since, by default, Azure virtual networks are isolated from each other and only have a rudimentary form of name resolution. To build useful networks in Azure, you will need to connect these virtual networks together. To make them easier to manage, you will need to implement custom name resolution.
This course is made up 7 lectures with an introduction and conclusion to aid in reviewing what you have learned throughout the course.
Configure Azure virtual network peering
Create a virtual network gateway and use it to connect two VNets
Configure Azure DNS to handle name resolution
Those looking to become Azure cloud architects
Those preparing for Microsoft’s AZ-100 or AZ-102 exam
- Basic knowledge of Azure virtual networks
- The GitHub repository for this course is at https://github.com/cloudacademy/azure-networks-and-dns
If you have multiple virtual networks, then they’ll be isolated from each other by default. There are two ways to connect them: using VNet peering or using a virtual network gateway. VNet peering is by far the easiest method, so we’ll start with that. I’m not going to show you the process of creating the two VNets, though, because I’m assuming you already know how to do that. Just make sure you don’t give them overlapping IP address spaces.
Go into one of the virtual networks in the portal, select Peerings from the menu, and click Add. Give it a name. I’ll use the name of the first virtual network dash and the name of the second virtual network. Then choose the subscription where the second virtual network resides, and finally, choose the second VNet. To complete the connection, you also need to create a peering in the other direction in the second virtual network.
“Allow virtual network access” is enabled, which is what we want. Otherwise, the peering wouldn’t allow traffic between the VNets, which would make it kind of useless. There are a few other configuration options as well, but I’ll tell you more about those later.
Okay, it’s done. The peering from vnet1 to vnet2 is showing a status of “Connected”. Let’s check the second peering as well. It’s connected, too. Once the status of both peerings is “Connected”, instances in the two VNets will be able to communicate with each other as if they were in the same VNet.
You can even do this with virtual networks that are in different regions, which is known as global VNet peering, or across subscriptions, as long as they’re associated with the same Azure Active Directory tenant. Traffic between them still goes through the Microsoft backbone network rather than through the internet, so the connection is private and has high bandwidth and low latency.
There are a couple of restrictions to keep in mind when you’re designing your networks. First, you can only peer two VNets if they have non-overlapping IP address spaces. That makes sense because otherwise you could end up with duplicate IP addresses, which would wreak havoc on your networks. Also, once you’ve peered two VNets, you can’t add or remove any of their address ranges. The only way to do it is to delete the peerings, make the change, and then create the peerings again.
Another restriction is that peerings are not transitive. That is, even though vnet1 is connected to vnet2 and vnet2 is connected to vnet3, vnet1 is not connected to vnet3. If you do want them to be connected, then there are a couple of ways to do it.
The most obvious way is to create a peering between vnet1 and vnet3. Although that would work, you may want to use a different method for a couple of reasons. First, if you add more networks to this mesh, then your network topology would get pretty complicated. Second, you might want to have more control over the traffic between networks.
An alternative to peering all of the networks together is to use a hub-and-spoke topology, with the hub acting as a router. In this configuration, the only way for two spokes to communicate with each other is through the hub. One big advantage of this architecture is that you could put shared services in the hub that could be used by all of the spokes. Some examples are firewalls, DNS servers, and intrusion detection systems.
One option for creating a router in the hub network is to deploy a simple Linux VM that can route traffic. To make this work, you also need to add route tables with user-defined routes so the spokes will know to send their external traffic to the hub. In addition, you need to check the “Allow forwarded traffic” option when you’re creating the peerings. This means to allow traffic from the hub VNet that was forwarded from another spoke VNet.
An alternative to deploying a virtual machine as a router is to deploy a virtual network gateway. If you do this, then you’ll still have to create route tables, but instead of checking the “Allow forwarded traffic” option, you’ll have to check the “Allow gateway transit” option on the peering connections from the hub. Then you’ll have to check the “Use remote gateways” option on the peering connections from the spokes to the hub. If you don’t enable both of those settings, then traffic won’t flow through the gateway in the hub.
There’s one restriction to keep in mind with this setup. It only works if the virtual networks are in the same region. You can’t enable gateway transit or remote gateways if the VNets are in different regions.
And that’s it for virtual network peering.
Guy launched his first training website in 1995 and he's been helping people learn IT technologies ever since. He has been a sysadmin, instructor, sales engineer, IT manager, and entrepreneur. In his most recent venture, he founded and led a cloud-based training infrastructure company that provided virtual labs for some of the largest software vendors in the world. Guy’s passion is making complex technology easy to understand. His activities outside of work have included riding an elephant and skydiving (although not at the same time).