Azure Multi-VNET Topologies in the ARM Era (Part 1)

If you have visited before on the pages of this blog, you may have seen this article : “Azure VNET to VNET VPN, across regions and data centers: not so complicated”. At that point, I wrote about how to put in place a connection between multiple Azure Virtual Networks, in particular a VNET-to-VNET-to-VNET relationship. All based on PowerShell scripting and classic deployment in Azure.

Today is the time to write again about this subject, but this time under a new cover related to several aspects: ARM (Azure Resource Manager) deployment,  usage of the new Azure Portal, and application of new networking concepts in Azure, like VNET Peering.

This is a two-part series of articles on these aspects. The series is related to the publication of a dedicated MS Experiences Online recording. In the recording we speak about these concepts, so I will focus here mainly on detailing and documenting the forenamed recording.

The first article includes the business case, the networking concepts and topologies and their applicability in Azure, and the technical solution we propose for the given use case.

Business Case

We propose to make communicating multiple environments (or resources) between each-other, in a IaaS (networking) context. That may be within the same Azure data center or region, or across regions. For this, we are required to put in place network connectivity between these environments.

To put it even more concrete, we chose to facilitate the deployment of a SQL Server AlwaysOn Cluster (available with SQL Server 2012 editions and later ones), cluster to be deployed as follows:

- 1 primary replica in Dublin (North Europe region)
- 1 secondary replica in Dublin
- 1 secondary replica in Amsterdam (West Europe region)

The solution will be focused on the network connectivity aspects, and not on the network security ones.

Azure Technical Concepts and Services

The following concepts will be used in the next lines, so we need to reference first the corresponding definitions in the Azure documentation:

- VNET – Virtual Network, Subnet [https://docs.microsoft.com/fr-fr/azure/virtual-network/]
- Public IP [https://docs.microsoft.com/fr-fr/azure/virtual-network/virtual-network-ip-addresses-overview-arm]
- Network Interface Card [https://docs.microsoft.com/fr-fr/azure/virtual-network/virtual-network-network-interface-overview]
- VPN Gateway [https://docs.microsoft.com/fr-fr/azure/vpn-gateway/]
- ExpressRoute [https://docs.microsoft.com/fr-fr/azure/expressroute/]
- VNET Peering [https://docs.microsoft.com/fr-fr/azure/virtual-network/virtual-network-peering-overview]
- Network Security Group [https://docs.microsoft.com/fr-fr/azure/Virtual-Network/virtual-networks-overview]
- Virtual Appliances [https://docs.microsoft.com/fr-fr/azure/virtual-network/virtual-networks-overview]
- User Defined Routes [https://docs.microsoft.com/fr-fr/azure/virtual-network/virtual-networks-udr-overview]

Most of these are already known and used from some time. I will insist on one concept only: the VNET Peering. As stated in the documentation, it practically allows you to join 2 VNETs located in the same region, by passing directly through the local backbone without needing a VPN gateway. This is very practical, as the VMs across the 2 VNETs will communicate with each-other on a bandwidth limited by the VMs’ network cards only.

Initial Environment

Let’s take a look at the networking structure of the original environment as we assumed it in our scenario.

The first VNET, named “net1dublin”, based in Dublin DC (North Europe): a classical VNET configuration, with a 10.0.1.0/24 range and composed from a single subnet named “default” having 10.0.1.0/25 range.

clip_image002_thumb[1]_thumb

There is a single virtual machine deployed in this subnet, named “vm1net1”, having attached one network card with the IP address 10.0.1.4. As remark, the access to the VM is controlled via the Network Security Group “nsg1net1”.

Similarly, we have a second VNET in Dublin, “net2dublin”, range 10.0.2.0/24, containing the VM “vm2net2” with the IP address 10.0.2.4.

clip_image003_thumb[1]_thumb

Finally, the third VNET, deployed in Amsterdam DC (West Europe), is named “net3amsterdam”, has an IP range of 10.0.3.0/24 and contains the VM “vm3net3” having the IP address 10.0.3.4.

clip_image004_thumb[1]_thumb

In our scenario – a SQL Server AlwaysOn cluster – we would have:

- “vm2net2” : primary replica (“master”) in Dublin
- “vm1net1” : a synchronous secondary replica in the same region
-“ vm3net3” : an asynchronous secondary replica in Amsterdam.

Networking Architectures and Topologies

1. Simple hybrid topology

First of all, will remind the simple topologies, starting with the “classical” hybrid Azure-VNET-to-On-premises-Network:

image

This “point-to-point” topology es at the base of all coming ones. The connection is made either over public internet (IPSec Site-to-Site VPN Azure, via an VPN Gateway in Azure and a network gateway device on-premises), or over private infrastructure (Azure ExpressRoute + typical MPLS infrastructure put in place for you by the provider of your choice and availability). You can have – if you need, for example, in a HA / DR architecture – both S2S VPN and ExpressRoute working at once.

2. Simple cloud-only topology

Now we’ll apply the same concepts for S2S VPN, but this time between 2 VNETs (in the same region or across regions):

image

So the solution is quite similar, but you will simply pass through the Microsoft backbone infrastructure. Note that you can make profit of your hybrid ExpressRoute circuit – if any – to put in connection Azure VNETs also. In that case, the S2S VPN Gateways will be replaced by ExpressRoute ones.

Under the same simple cloud-only topology, you may have this time a VNET Peering put in place (if the VNETs are in the same region):

image

Note that you can connect either ARM-to-ARM VNETs or ARM-to-Classic VNETs. This is a perfect solution for Azure “legacy” infrastructure” (a bit strange to speak about “legacy” in Azure Smile ) deployed on classic networks, in order to avoid their migration to ARM if not absolutely necessary, while still let them communicate with all the new [ARM] deployments.

3. Complex topologies: Hub & Spoke

When the requirements become more complicated, we will use adapted connectivity patterns to cover them. Here is the “Hub & Spoke” topology.

Cases are when there is a central system which needs to communicate with “satellite” systems. In the case of an SQL Server AlwaysOn cluster with multiple replicas for higher availability and throughput, the VNET of the master replica will be “surrounded” by the VNETs corresponding of secondary replicas.

image

In this case, we will configure simple bidirectional communications between the master VNET end the satellite VNETs. Any of the direct connectivity options described before (IPSec VPN, ExpressRoute if the case, or Peering) can be used here.

Note that the Hub & Spoke topology doesn’t imply connectivity transitivity : the left VNET won’t (necessarily) communicate with the right one.

4. Complex topologies: Daisy Chain

The transitivity comes into the game in the Daisy Chain topology. The left VNET will communicate with the right one via specific routing configuration set up in the middle VNET:image

This can be achieved in Azure via User Defined Routes functionality. But you will find another solution out a bit later in the article.

If the Daisy Chain topology has the advantage of getting profit of a connection already established (e.g. center with right) for the usage of another VNET (left one), you may have surely seen its inconvenient also: if the VNET on the center (or its gateway) loses its connectivity, it will also affect the connectivity between the lateral VNETs.

5. Complex topologies: (Full) Mesh

The Full Mesh let you master with precision the direct connectivity between various VNETs, without having dependencies on intermediate VNETs or their gateways :

image

On the other side, definitely there is much more work to getting it done; also, the complexity increases exponentially with each new VNET you want to add to the topology.
You may remark, by the way, that the picture reflects a Mesh which is not “full” actually; it’s up to you to decide if you want the left VNET communicate with the right VNET.

How do you implement a topology like this in Azure? The VPN gateways let you create this type of connectivity, but you can put it in place very quickly with multiple VNET peerings.

 

Technical Solution for the Given Scenario

Let’s depict the technical solution we propose for our business case:

image

So, recall that we have a primary replica in VNET2, and we need a secondary replica in VNET1 and another one in VNET3.

The solution is composed of 3 main segments:
1. VNET Peering between VNET2 and VNET1 (both VNETs being in the same region)
2. Site-to-Site VPN connection between VNET1 (Dublin) and VNET3 (Amsterdam), with VPN Gateways deployed in both VNETs
3. Transitivity for the VNET2 to VNET3 through the VPN Gateway 1. This connection transitivity will be configured in the VNET Peering settings directly.

Implementation

You will find the implementation of this solution in the next (and last) article of this series: http://blog.lecampusazure.net/2016/11/azure-multi-vnet-topologies-in-arm-era.html.

Azure Multi-VNET Topologies in the ARM Era (Part 2)

This article is the second (and the last) one of the series dedicated to Azure Multi-VNET Topologies in ARM implementation. You may find the first article here: http://blog.lecampusazure.net/2016/11/azure-multi-vnet-topologies-in-arm-era-1.html .

We will continue with the implementation of the technical solution as it was defined in the first article.

Technical Solution for the Given Scenario

The diagram for the technical solution we proposed is below:

image_thumb3

The solution is composed of 3 main segments:
1. VNET peering between VNET2 and VNET1 (both VNETs being in the same datacenter)
2. Site-to-Site VPN connection between VNET1 (Dublin) and VNET3 (Amsterdam), with VPN Gateways deployed in both VNETs
3. Transitivity for the VNET2 to VNET3 through the VPN Gateway 1, configured in the VNET Peering settings directly.

 

Implementation

a. VNET Peering configuration

The first part of our implementation consists in putting in place the NET Peering configuration between VNET1 and VNET2.

For this, in the “net1dublin” Settings, section Peerings, we will add a new peering, by giving it a name, selecting the corresponding VNET (“vnet2dublin” in our case):

clip_image005_thumb[1] 
Keep all other values by default (for the moment).
You should have the successful message right after that:

clip_image006_thumb 

Then you will see the peering listed in the Peerings list:

clip_image001

See that the Peering status is “Initiated” at this stage.

Similarly, let’s add a peering in the other way – “net2dublin” to “net1dublin”:

clip_image008_thumb[1]

Here it is, listed in “net2dublin” ‘s Peerings list:

image

Quickly, both Peerings pass in the Connected state. You can see it if go back  in “net1dublin” ’s Peerings list:

clip_image009_thumb[1]

And that’s all for the VNET Peerings part Smile

Testing the VNET Peering

At this point, you can already test the connectivity between the two virtual machines deployed across the networks. Download the proposed RDP file for the first VM (click “Connect” in the VM blade), connect via RDP to the VM, “vm1net” (private IP identified as 10.0.1.4), and then ping the second one, “vm2net2” (private address 10.0.2.4):

clip_image016_thumb[2]

In the same way, test the connectivity from vm2net2 to vm1net1:

clip_image017_thumb[2]

You may remark the very fast response time between the two VMs (and the underlying networks).

 

b. VNET-to-VNET VPN configuration

Now let’s add the VNET-to-VNET VPN configuration. We will start by creating a first VPN Gateway, “gw1net1”, for “net1dublin”. From the Azure portal, add a new Virtual Network Gateway as follows:

clip_image010_thumb[1]

Note the main steps during this configuration:
- selection of the gateway type: VPN
- selection of the VPN type: route-based (known also as “dynamic” gateway)
- selection of the SKU (which will give you the expected performance level)
- selection of the VNET
- configuration of the IP address range for the gateway instances (which will create behind a dedicated subnet in our VNET)
- configuration of the Public IP Address (newly created, by default, or select an existing one).

The result (after 30-45 min, the gateway provisioning is quite long) will look as follows:

image

The same steps will be followed for the second VPN Gateway, “gw3net3”:

clip_image011_thumb[1] 

And here is the result for this configuration:

image

After creating the gateways, we will create the connections between the gateways. We need to create 2 VNET-to-VNET connections, that is one connection from the first gateway to the second, and another way around.

From the gateway “gw1net1” Settings, Connections, add a new Connection “conn-net1-net3”:

image

Configure it as follows:
- type: VNet-to-VNet
- second gateway: “gw3net3”
- shared PSK key (a string to your choice).

Here is the result:

clip_image015_thumb 

The connection is created, but the status either “Unknown” or  “Not connected” at this stage:

clip_image019_thumb[2]

The connection with its details:

image 
Going to the second gateway, we will see that the connection is also listed here:

clip_image018_thumb[4]

Proceed in the same way to create a connection “conn-net3-net1”, from “gw3net3” to “gw1net1”. After a few seconds (52, to be precise Smile ), we have the result :

clip_image021_thumb[1] 

At this stage, you will see the 2 connections in both “gw1net1” and “gw3net3” settings.

After a few minutes of attempts, you will see the 2 connections passing in “Connected” status:

image

Testing the VPN connection

If you connect remotely to “vm3net3”, from there you will be able to ping the VM “vm1net1”:

clip_image023_thumb[1]

Note the ~25ms response time between the 2 datacenters at a few hundreds kilometers distance, which is a very good performance indeed.

c. Connection Transitivity

There is one last piece missing from the assembly : connectivity between “vnet2dublin” and “vnet3amsterdam”.

Due to the awesome implementation of the Peering feature, this will be solved by 2 clicks configuration only:

1. In the “net1dublin” settings, “net1-net2-peer” peering, under Configuration, check “Allow gateway transit” checkbox:

clip_image024_thumb[1]
(note that the service detects the existence of a VPN gateway in the VNET and predefines the options accordingly)

2. In the “net2dublin” settings, “net2-net1-peer”, under Configuration, check “Use remote gateways” checkbox:

clip_image025_thumb[1]

And that’s it. Really!

Testing the connection transitivity

As you may expect, the ping from “vm2net2” to “vm3net3” will start working:

clip_image026_thumb[1] 

And the same thing in the other way:

clip_image027_thumb[1]

 

Conclusion

We have seen together the essential networking concepts and architectures to be able to implement simple or complex topologies in the Cloud, depending on our needs.

You have seen demonstrated the implementation of a relatively complex VNET-to-VNET-to-VNET topology, within the same Azure region and across regions.

With the switch to the Azure Resource Manager (ARM) deployment model in Azure, the previously existing functionalities in classic model were ported and published in the new Azure portal, but also simplified enormously. The new features like VNET Peering are equally configurable in a simple manner and are integrated seamlessly, permitting the connection transitivity via adjacent VPN gateways, or more advanced scenarios like IP forwarding for the usage of VPN appliances.

Scripting and Automation

As the ARM deployment model is based on ARM templates, you can have the complete solution implemented as ARM template which can be used in automation scenarios.

Here is for conformity a screenshot showing the resource group of the demo implementation:

image

For automating the deployment, you can either develop the ARM template in your preferred tooling (like Visual Studio or VS Code), or export it directly from the portal (from the resource group level).

Please note that as of today not all the resources are exportable as is from the portal; some of them are not yet available. However, you can still go to Resource Explorer (http://resources.azure.com) and extract the template elements from there.

Resources

The “MS Experiences Online” corresponding video (in French, named: “Architecture et topologie Azure multi-VNet”) is available on https://experiences.microsoft.fr/.

A “From-Zero-to-Hero” white-paper on this subject (in French also) is available on Cellenza’s blog.

A demo ARM template of this technical solution is available on GitHub: https://github.com/LeCampusAzure/demo-assets.

CloudBrew.be - December 3, 2016

After Cloud Expo Europe, I will head to Belgium on December 3rd, 2016, for one of the famous conferences in the region, CloudBrew:

image

There, I will speak about “Azure Networking - innovative features and Multi-VNET topologies” :

“Are you looking to deploy a more complex structure of resources in Azure, all secured and segregated by precise boundaries while closely communicating with each other? Following the arrival of the advanced IaaS networking features in Azure (network security groups, routing, multi-NIC,…) and their maturation in the last months, here is the moment for you to find a modern architectural vision of networking in Azure, with focus on multi-VNET / VPN topologies, and based on ARM deployment model”

If it sounds interesting to you, link to http://cloudbrew.be/ and check the organizers’ web site.

Cloud Expo Europe – November 29-30, 2016 !

On November 29th and 30th, at the Exhibition Center Porte de Versailles Paris, will take place the conference Cloud Expo Europe & Data Centre World 2016.

Within this conference I have the honor to be speaker in a session dedicated to Cloud governance and identity : “Gouvernance unifiée et sécurisation de vos ressources Cloud avec Azure Active Directory”. This session will be held on November 30th at 15h, on Hall 6, and will include Q&A on the subject.

If you are interested by these problematics as well as by Microsoft Azure services and Cloud architectures, or if you want to simply meet me, you will be welcomed.

Here is for reference a link to the session, on the organizers’ web site.