Public and Private Peering with #Azure ExpressRoute

January 12, 2015

Public and private peering with Azure ExpressRoute is a topic that has come up a lot in my recent conversations recently so I thought I would capture some thoughts here:

What is peering?

According to Wikipedia contributors, in computer networkingpeering is a voluntary interconnection of administratively separate Internet networks for the purpose of exchanging traffic between the users of each network. An agreement by two or more networks to peer is instantiated by a physical interconnection of the networks and an exchange of routing information through the Border Gateway Protocol (BGP) routing protocol.

In Azure, peering translates into a private, dedicated and high-throughput connection between Azure and an on-premises data center via ExpressRoute. Note that Azure does offer Virtual Network (point-to-site) and Virtual Network (site-to-site) connectivity options, but rather, the routing is static or dynamic VPN. In contrast, ExpressRoute is based on BGP routing. For a detailed comparison of these options with guidance to choose between them, please refer to Ganesh Srinivasan’s blog post.

Furthermore, peering can be private or public. Public peering, as the name suggests, is a peering arrangement where the interchange between the participating networks happens over a public exchange point. Likewise, a private peering is a peering arrangement where the interchange between participating networks happens over a private exchange point.

So what does private / public peering mean in terms of Azure?

Public and Private Peering with Azure

As stated earlier, ExpressRoute allows you to create a dedicated circuit between on-premises and Azure DC. As part of this dedicated circuit, you get two independent routing domains (shown in green and orange below).

The “orange” link depicts private IP-based traffic among a customer’s network and VNET and VMs running in Azure.  There is a NAT in the path. Since the exchange point is completely private, this link represents a private peering based connection.

The “green” link depicts traffic between a customer’s network with Azure-based services that have a public endpoint (such as Azure Storage). Since the exchange point in this instance is indeed public, this link represents a public peering based connection.  Now, since the traffic is originating from a private IP (on-premises) address, ExpressRoute will NAT the traffic before it delivers the packets to the public endpoint of a service such as Azure Storage (ExpressRoute will use MSFT address range for the NAT pool) This means customers don’t have to go through their internet edge (proxy, firewall, NAT) to reach public Azure services, and thus *not* taking up a chunk of their internet bandwidth to communicate with Azure.

ExpressRoute Public and Private Peering
Exceptions

Please note that not all Azure public services are accessible via ExpressRoute public peering. The following services are not supported over ExpressRoute public peering at the time of writing of this post.

http://msdn.microsoft.com/en-us/library/azure/2db6ef11-aa86-4091-adbd-21882e136f65#BKMK_ExpressRouteAzureServices

For more information please visit:

Express Route FAQ.

Extending Your On-Premises Network into Azure Securely

One Response to “Public and Private Peering with #Azure ExpressRoute”


  1. Thanks for this, have been trying to get a good answer on this for my customer regarding Azure Backup over ExpressRoute or public internet.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: