Networking to and within the Azure Cloud, part 2

This is the second blog post of a three-part series. Before you begin reading, I would suggest reading the first post Networking to and within the Azure Cloud, part 1.

Hybrid networking is a nice thing, but the question then is how do we define hybrid networking? For me, in the context of the connectivity to virtual networks, ExpressRoute’s private peering or VPN connectivity, it is the ability to connect cross-premises resources to one or more Virtual Networks (VNets). While this all works nicely, and we know how to connect to the cloud, how do we network within the cloud? There are at least 3 Azure built-in ways of doing this. In this series of 3 blog posts, my intent is to briefly explain:

1. Hybrid networking connectivity options
2. Intra-cloud connectivity options
3. Putting all these concepts together

Background

Before we go deeper into networking within the cloud, let’s try and understand why you could typically have more than one VNet, or even what is a VNet?

We have a great article that describes what it is, but we could summarize it this way : it is an isolated network that you create within Azure for your own needs. This is going to be required if and when you start moving virtual machines from on premises to Azure, for example. You choose your IP address space. Therefore, planning IP addressing is important before you move to the cloud. Think of Azure as an extension of your own data center, your virtual data center, so maybe you should plan for a block of IP addresses. Or maybe more than one, perhaps one block of IP address space (also known as CIDR block, or classless inter-domain routing… it’s a network engineer thing).

Now that we understand slightly better what a VNet is (reading and experience will help too), why would we have multiple VNets? For one thing, it could be because you have multiple lines of businesses that need these resources to be independent. That could be because of invoicing to a different business unit (using different Azure Subscriptions that you can create here), or that could also be because it will be a different team that will manage the other virtual network and its associated elements (network security groups, user-defined routes, etc.).

Intra-Cloud Connectivity Options

Once you created your virtual networks, and that you’ve made the connection to the cloud, what are the native options to communicate within the Azure cloud? In other words, if these lines of business needs to exchange data, or you need to enable IP connectivity between the virtual networks and there are 3 native options that Azure offers:

1. VNet to VNet via VPN (VNet-to-VNet connection)
2. VNet to VNet via ExpressRoute
3. VNet to VNet via Virtual Network Peering (VNet peering) and VNet transit

My intent here is to compare these methods, what they allow, and the kind of topologies you can achieve with these.

VNet-to-VNet via VPN

As exposed in the below picture, when 2 VNets are connected together using VNet-to-VNet via VPN, this is what routing tables look like for both virtual networks:

This is interesting with 2 VNets, but it can grow by some measure:

If you notice, the route tables for VNet4 and VNet5 indicate how to reach VNet3. However, VNet4 is not able to reach VNet5. Despite this being the case, there are 2 methods to achieve this:

1. Full Mesh VNet-to-VNet
2. Using BGP enabled VPNs

With both of these methods, all 3 VNets know how to reach each VNet. Obviously this could scale to many more VNets, assuming the limits of the VPN Gateways are respected (maximum number of tunnels, etc.).

VNet-to-VNet via ExpressRoute

While maybe not everyone realizes, linking a VNet to an ExpressRoute circuit has an interesting side-effect when you are linking more than one VNet to the same ExpressRoute circuit. For example, when you have 2 VNets linked to the same ExpressRoute circuit, this is what the route table looks like:

Interestingly, both VNets are able to communicate with each other, without going outside of the Microsoft Enterprise Edge (MSEE) router, in other words, without leaving the Microsoft backbone. Why is that important? For one thing, it allows you to communicate without any additional charges between the VNets. In short, it is possible to communicate between VNets that are either within the same geopolitical region or globally, except on National Clouds, if this is an ExpressRoute Premium circuit. This means you can use the world wide Microsoft backbone, to connect multiple VNets together. Again, that VNet-to-VNet traffic is free of charge, as long as you can connect these VNets to the same ExpressRoute circuit. In the example below, you would have 3 VNets connected to the same ExpressRoute circuit:

You also see in the picture above the different routes that appear in each VNet’s subnet’s Effective Route Table (read that, it’s very useful to understand why routing doesn’t work like you expect, if that ever happens).

VNet-to-VNet with Virtual Network Peering

The final option to connect multiple VNets together is to use Virtual Network Peering, which is constrained within one Azure region. This peering arrangement between 2 VNets makes the VNets behave essentially like if this were 1 big virtual network, but you can govern/control these communications with NSGs and route tables. For an illustration of what this means, see below:

So taking that to the next level, you could imagine a topology where you would have a hub and spoke topology like this:

Peering is non-transitive, therefore in that case, HR VNet cannot talk directly to Marketing VNet, however they can all three, HR, marketing, and engineering, talk to the Hub VNet, that would contain shared resources, like Domain Controllers, Monitoring Systems, Firewalls, or other Network Virtual Appliances (NVA). Using a combination of User-Defined-Routes applied on subnets within the spoke VNets and NVA deployed in the centralized Hub VNet, you can still achieve communications between all the peered VNets, or limit communications to those VNets that actually need it.

However, like in the case of VPN, if for some reason you would need each VNet to be able to talk to each other, you could create a topology similar to this as well. It is not fully meshed in the interest of clarity (HR VNet cannot talk directly to Engineering VNet in this case), but you get the idea:

When using VNet peering, one of the great resource that can be shared is the Gateways, both VPN and ExpressRoute gateways. That would look something like this:

This way, you do not have to deploy an ExpressRoute or VPN Gateway in every spoke VNet, but can centralize the security stamp and Gateway access into the Hub Vnet.

Please make sure to check out the next post when it comes out to put all these concepts together!