Uncategorized

Author: John Savill

Date: 06/22/2014

Article…

Q: What are the Microsoft Azure data center pairings?

A: All Microsoft Azure data centers are paired with another data center that’s physically separated by hundreds of miles. Data is asynchronously replicated between the two data centers (when the storage account is enabled for georeplication) to protect against an Azure site failure. (Think about a hole-in-the-ground scenario, in which a data center is completely destroyed; you’d want the secondary site to be far enough away to ensure that it wasn’t also affected by the event that caused the primary data center to fail.) Azure data center pairings are as follows:

US West

Author: Yu-Shun Wang

Senior Program Manager, Azure Networking

Tuesday, June 17, 2014

Overview

At TechEd 2014, we released Multi-Site VPNs, in-region VNet-to-VNet, and cross-region VNet-to-VNet features. This blog is the first of a mini-series to walk you through the configuration steps and examples of how you can connect your virtual networks together using the VNet-to-VNet feature.

VNet-to-VNet connectivity utilizes the Azure VPN gateways to connect two or more virtual networks together securely with IPsec/IKE S2S VPN tunnels. Together with the Multi-Site VPNs, you can connect your virtual networks and on-premises sites together in a topology that suits your business need. The diagram below shows a simple example of a fully connected topology between virtual networks and on premises sites.

There are several scenarios this connectivity can enable. Below is just a partial list:

1. Cross region geo-redundancy and geo-presence; e.g., SQL AlwaysOn across different Azure regions
2. Cross subscription, inter-organization communication in Azure
3. Regional multi-tier applications with strong isolation boundary; or connecting existing workloads in different VNets together to form new applications

Considerations

There are a number requirements and considerations on the VNet-to-VNet feature documented here. Below is a short list of the key points:

1. You MUST create or use the Azure Dynamic Routing VPN gateways to connect your virtual networks. Static Routing VPN gateways are NOT supported for VNet-to-VNet.
2. For each virtual network, you can connect up to 10 “networks”; i.e., both virtual networks and on premises sites combined cannot exceed 10.
3. You need to ensure that the address prefixes don’t overlap among all the connected networks.
4. VNet-to-VNet feature works across regions and subscriptions – same or different regions, single or across subscriptions.

With that in mind, let’s build a simple example from scratch to connect the VNets!

Connecting Two VNets in the Same Subscription

From an Azure virtual network, connecting to another virtual network is essentially the same as connecting to an on premises network via site-to-site (S2S) VPN. In this blog, we will start from scratch to create the virtual networks, the VPN gateways, and then connect them together, all within the same Azure subscription. Below lists the steps you will go through:

1. Create the virtual networks and matching local networks with cross premises connectivity
2. Create the Azure Dynamic Routing VPN gateways for the virtual networks
3. Connect the virtual networks together

Using the following diagram as an example, we will create and connect the two virtual networks, VNet1 and VNet2, together:

• VNet1: Address Space = 10.1.0.0/16; Affinity Group = WestUS
• VNet2: Address Space = 10.2.0.0/16; Affinity Group = NorthEurope

In the example below, we will be using the Azure PowerShell cmdlets. Please refer to the Azure PowerShell instruction pages to install and configure your PowerShell environments:

• Azure PowerShell on MSDN: http://msdn.microsoft.com/en-us/library/azure/jj156055.aspx
• How to install and configure Windows Azure PowerShell: http://azure.microsoft.com/en-us/documentation/articles/install-configure-powershell/

Please note that for a simple VNet-to-VNet setup as described here, you can use the Azure Management Portal to carry out steps 1 and 2 below. We use PowerShell because as we continue to add more connections to the VNet (e.g., Multi-Site VPNs), Azure PowerShell cmdlets or REST APIs are the only options to configure these features currently.

[Step 1] Create VNet1 and VNet2 and the Corresponding Local Networks

The first step is to create the two virtual networks, and the matching local networks. From the perspective of each virtual network, e.g., VNet1, the other virtual network, VNet2, is just another VPN connection defined in the Azure platform. As a result, customers must create and define the following connections:

Please note that you will need to define each virtual network twice: first as an Azure virtual network, then as a local network site connected to the other virtual network. You must ensure the Address Space elements specified in both definitions are the same, or the communication will not work correctly between the two virtual networks. To make things easy to read, the example uses the same name for both definitions of the virtual network and the local network. This is not a requirement, but will make reading the definitions easier.

The following PowerShell cmdlets create the two Affinity Groups for the two virtual networks. Note that you can re-use existing Affinity Groups of the same regions if you prefer:

PS D:\> New-AzureAffinityGroup -Name WestUS -Location "West US"

PS D:\> New-AzureAffinityGroup -Name NorthEurope -Location "North Europe"

Once the Affinity Groups are created, you can export the current network configuration file (NETCFG.XML) with following cmdlet:

PS D:\> Get-AzureVNetConfig -ExportToFile "D:\MyCurrentNETCFG.XML"

To create the two new virtual networks and the corresponding local networks, use a text editor such as Notepad.exe to insert the following segment into the NETCFG file, in this case, MyCurrentNETCFG.XML:

<LocalNetworkSites>

 <LocalNetworkSite name="VNet1">

 <AddressSpace>

 <AddressPrefix>10.1.0.0/16</AddressPrefix>

 </AddressSpace>

 <VPNGatewayAddress>1.0.0.1</VPNGatewayAddress>

 </LocalNetworkSite>

 <LocalNetworkSite name="VNet2">

 <AddressSpace>

 <AddressPrefix>10.2.0.0/16</AddressPrefix>

 </AddressSpace>

 <VPNGatewayAddress>2.0.0.2</VPNGatewayAddress>

 </LocalNetworkSite>

</LocalNetworkSites>

<VirtualNetworkSites>

 <VirtualNetworkSite name="VNet1" AffinityGroup="WestUS">

 <AddressSpace>

 <AddressPrefix>10.1.0.0/16</AddressPrefix>

 </AddressSpace>

 <Subnets>

 <Subnet name="Subnet-1">

 <AddressPrefix>10.1.0.0/24</AddressPrefix>

 </Subnet>

 <Subnet name="GatewaySubnet">

 <AddressPrefix>10.1.200.0/29</AddressPrefix>

 </Subnet>

 </Subnets>

 <Gateway>

 <ConnectionsToLocalNetwork>

 <LocalNetworkSiteRef name="VNet2">

 <Connection type="IPsec" />

 </LocalNetworkSiteRef>

 </ConnectionsToLocalNetwork>

 </Gateway>

 </VirtualNetworkSite>

 <VirtualNetworkSite name="VNet2" AffinityGroup="NorthEurope">

 <AddressSpace>

 <AddressPrefix>10.2.0.0/16</AddressPrefix>

 </AddressSpace>

 <Subnets>

 <Subnet name="Subnet-1">

 <AddressPrefix>10.2.0.0/24</AddressPrefix>

 </Subnet>

 <Subnet name="GatewaySubnet">

 <AddressPrefix>10.2.200.0/29</AddressPrefix>

 </Subnet>

 </Subnets>

 <Gateway>

 <ConnectionsToLocalNetwork>

 <LocalNetworkSiteRef name="VNet1">

 <Connection type="IPsec" />

 </LocalNetworkSiteRef>

 </ConnectionsToLocalNetwork>

 </Gateway>

 </VirtualNetworkSite>

</VirtualNetworkSites>

The segment above defines two virtual networks, VNet1 and VNet2, and two local networks, also called VNet1 and VNet2. Please note the following before we proceed further:

1. For simplicity, there is only one subnet (“Subnet-1”) besides the “GatewaySubnet” in each virtual network, and the DNSServersRef element is skipped in the example above. We also skip the “VPNClientAddressPool” element. You can add those elements to your NETCFG as needed.
2. If you already have “LocalNetworkSites” and “VirtualNetworkSites” sections in your NETCFG, please copy the corresponding “LocalNetworkSite” elements and the “VirtualNetworkSite” elements into those two sections.
3. The “VPNGatewayAddress” for the LocalNetworkSite is the VIP (Public IP) address of the corresponding Azure VPN gateway for the virtual network. The actual address will not be available until the Azure VPN gateway is created. Right now, we use “1.0.0.1” and “2.0.0.2” as the temporary placeholders for the two addresses.

Once this is done, save the new NETCFG as “MyNewNETCFG.XML”, and use the following PowerShell cmdlet to upload the updated NETCFG file to your Azure subscription:

PS D:\> Set-AzureVNetConfig -ConfigurationPath D:\MyNewNETCFG.XML

This step will take a couple of minutes to complete. Once completed, you will be able to see the virtual networks and the local networks from the Azure Portal.

[Step 2] Create the Dynamic Routing VPN gateways for each virtual network

Once the virtual networks are created with the corresponding VPN connections, the next step is to create the Azure VPN gateway for each virtual network. This can be done through either Azure Management Portal, or Azure REST APIs. Only the Dynamic Routing gateway type is supported. Please note that currently, Azure PowerShell cmdlet “New-AzureVNetGateway” does NOT support creating a dynamic routing gateway. (We are working on filling this gap in Azure PowerShell. Please stay tuned …)

From the Azure Portal, navigate to the “Networks” page, then go to the “Dashboard” page of both VNet1 and VNet2. At the bottom of each page, click “Create Gateway” and select “Dynamic Routing” as shown below:

[Step 3] Connect the VPN gateways

After both gateways are created, you will be able to get the public IP addresses of these two VPN gateways either from the Portal or with the following cmdlets:

PS D:\> Get-AzureVNetGateway -VNetName VNet1 | ft VIPAddress

VIPAddress