Sunday, March 8, 2015

Improve your Azure Virtual Network

How can I improve the speed on my Azure virtual networks? 


In this article I'll be taking you through configuring the encryption type on your Azure Virtual Network to improve your throughput. And I'll conclude with a comparison to see the benefit of removing the encryption.

The ability to do so was announced by Microsoft in December in the following article. http://azure.microsoft.com/blog/2014/12/02/azure-virtual-network-gateway-improvements/

Some of the key changes noted are the ability to change to a high performance gateway, and  changing the encryption type on the gateway of an Azure VPN. As noted below.

More Custom Options for IPsec/IKE VPNs

We added two more custom options for configuring your IPsec/IKE S2S VPN tunnels – PFS (Perfect Forward Secrecy) and No Encryption.
With this feature, now you can specify PFS with IKE on a per tunnel basis. No Encryption is a new option for the S2S VPN tunnel. This is targeted at the VNet-to-VNet communication within Azure. The traffic between Azure Virtual Network gateways will stay within the Microsoft operated networks, including cross-region communication. This traffic today is encrypted by default. For customers that would like better throughput, we offer the No Encryption option that removes the encryption and decryption overhead. Please note that for traffic that is going through the Internet, this option is not recommended as it will cause the packets to be sent without encryption. It is only recommended for Azure VNet-to-VNet communication.
We are working on the PowerShell cmdlet support to enable these two features. Please stay tuned.

No article followed with the actual cmdlets, and for those like myself who are keen to test NoEncryption encryption type would have found that there is no information available. So I've followed up with Microsoft and have been able to get the command. Given that there is no additional information availably I thought why not compare the speeds so we actually know what "better throughput" is like?

So before we go ahead and configure the NoEncryption setting, be aware of the following. Do not configure a Site-to-Site VPN which traverses the public internet with the NoEncryption option. This makes perfect sense and is mentioned in the article of Microsoft, but it is well worth repeating. You do not want your VPN traffic to traverse the public internet without any encryption.

So what can we use it for? Well for your Azure VNet-to-VNet connectivity, this traffic does not traverse the public internet. Removing the encryption from the tunnel will enhance the throughput of VPN by removing the encryption and decryption overhead. Which can be quite critical when you run multiple VNet-to-VNet connections across multiple subscriptions, and regions like I do.

The command?

So that PowerShell cmdlet that we are looking for to configure NoEncryption, what is it? The command is:

Set-AzureVNetGatewayIPsecParameters

If you look for this command on MSDN you won't find a lot of information, but using the latest Microsoft Azure PowerShell cmdlet you'll be able to run a get-help. Which will provide you the following information. What we are looking at for this article is the parameter -EncryptionType with the following string values RequireEncryption and NoEncryption.

PS C:\> Get-Help Set-AzureVNetGatewayIPsecParameters -Full
NAME
    Set-AzureVNetGatewayIPsecParameters
 SYNTAX
    Set-AzureVNetGatewayIPsecParameters [-VNetName] <string> [-LocalNetworkSiteName] <string> [[-EncryptionType]
    <string>] [[-PfsGroup] <string>] [[-SADataSizeKilobytes] <int>] [[-SALifetimeSeconds] <int>]  [<CommonParameters>]
 PARAMETERS
    -EncryptionType <string>
        The type of encryption that will be used for the connection between the virtual network gateway and the local network.
 Valid values are RequireEncryption and NoEncryption.
        Required?                    false
        Position?                    2
        Accept pipeline input?       false
        Parameter set name           (All)
        Aliases                      None
        Dynamic?                     false 
    -LocalNetworkSiteName <string>

        The local network site name.   
        Required?                    true
        Position?                    1
        Accept pipeline input?       false
        Parameter set name           (All)
        Aliases                      None
        Dynamic?                     false
    -PfsGroup <string>
        The PFS gruop that will be used for the connection between the virtual network gateway and the local network.
        Valid values are RequireEncryption and NoEncryption.
        Required?                    false
        Position?                    3
        Accept pipeline input?       false
        Parameter set name           (All)
        Aliases                      None
        Dynamic?                     false
    -SADataSizeKilobytes <int>
        The SA Data Size Kilobytes value is used to determine how many kilobytes of traffic can be sent before the SA for theconnection will be renegotiated.
        Required?                    false
        Position?                    4
        Accept pipeline input?       false
        Parameter set name           (All)
        Aliases                      None
        Dynamic?                     false
    -SALifetimeSeconds <int>
        The SA Lifetime Seconds value is used to determine how long (in seconds) this connection's SA will be valid before a new SA will be negotiated.
        Required?                    false
        Position?                    5
        Accept pipeline input?       false
        Parameter set name           (All)
        Aliases                      None
        Dynamic?                     false
    -VNetName <string>
        The virtual network name.
        Required?                    true
        Position?                    0
        Accept pipeline input?       false
        Parameter set name           (All)
        Aliases                      None
        Dynamic?                     false
    <CommonParameters>
        This cmdlet supports the common parameters: Verbose, Debug,
        ErrorAction, ErrorVariable, WarningAction, WarningVariable,
        OutBuffer, PipelineVariable, and OutVariable. For more information, see
        about_CommonParameters (http://go.microsoft.com/fwlink/?LinkID=113216).
INPUTS
    None
OUTPUTS
    Microsoft.WindowsAzure.Management.Network.Models.GatewayGetOperationStatusResponse
ALIASES
    None

REMARKS
    None



So there you go, that's the cmdlet and with all the syntax that can be used to configure the EncryptionType on the Site-to-Site or VNet-to-VNet VPN. You will probably noticed that there are a bunch of typo's in the get-help file. Let's assume they get fixed by Microsoft anytime soon.

Changing the type, and what is the throughput difference like?

So how about we start looking at changing the type, and compare the speed with, and without encryption.

To start of the test I'll first explain my setup. I myself have a number of subscriptions and have connected a virtual network in Australia East (Sydney) to Europe West (Amsterdam). So I basically have a VNet-to-VNet connection from Sydney to Amsterdam. I have virtual machines on both sides which i'll use for my test. My setup is pretty much as indicated below.


Scenario - VNet-to-VNet Sydney to Amsterdam












The configuration that applies is as follows.

Virtual NetworkLocalNetworkSiteNameSubscription
Ate-VNET1 Ate-VNET4 Projects Lab
Ate-VNET4 Ate-VNET1-FUJ Ate Lab


To retrieve the current configuration run the following commands.

Get-AzureVNetGatewayIPsecParameters -Vnetname Ate-VNET4 -LocalNetworkSiteName Ate-VNET1-FUJ | fl
Get-AzureVNetGatewayIPsecParameters -Vnetname Ate-VNET1 -LocalNetworkSiteName Ate-VNET4 | fl

In my case it returns me with the following results. As you can see the encryption type for both connections are set to RequireEncryption.

Get-AzureVNetGatewayIPsecParameters

To change this run the following command. Run them on both virtual networks, in my case Ate-VNET1 and Ate-VNET2, as you want to change the Encryption type both ways, not one way.

Set-AzureVNetGatewayIPsecParameters -Vnetname Ate-VNET1 -EncryptionType NoEncryption -LocalNetworkSiteName Ate-VNET4 
Set-AzureVNetGatewayIPsecParameters -Vnetname Ate-VNET4 -EncryptionType NoEncryption -LocalNetworkSiteName Ate-VNET1-FUJ

Set-AzureVnetGatewayIPsecParameters

The command takes a few minutes per connection, and will briefly interrupt your connectivity as indicated below. Run the command against both virtual networks.

Briefly interrupted

After changing the type quickly run the Get-AzureVnetGatewayIPsecParameters command to confirm that the changes have applied.

EncryptionType has changed to NoEncryption

Once you've completed this on both virtual networks you will have updated both tunnel to use the EncryptionType NoEncryption.

How much 'better' is the throughput?

As indicated at the start of the article, the goal of changing the connection type to NoEncryption is to remove the overhead caused by encryption and decryption of data going through the Azure IPSec VPN tunnel. So how much "better" is the throughput as mentioned in the Microsoft article.

To find out what the difference is I ran a robocopy of a file of 1GB from Ate-AZR401 to Ate-AZR101. Below the results of my test.


Encryption TypeTime Taken (m)Speed (MB/s)
Encryption12:001.4
NoEncryption8:441.9

That's an increase of throughput of 36%! These are obviously point in time measurements and can vary throughout the day. I am planning to over the next few days run a couple of more tests but was excited to share these results.

My conclusion is, removing the encryption truly improves the throughput on your connection. So if you run a lab, and use Vnet-to-Vnet connections, change the encryptiontype to NoEncryption! Your throughput could improve to 36%!

Hope you enjoyed this post, please feel free to provide feedback or ask any questions.

No comments:

Post a Comment