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 networking, peering 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.
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.
For more information please visit: