In ExpressRoute you establish a connection between your on-premises infrastructure and the Microsoft cloud with the help of a connectivity provider. The ExpressRoute circuit represents this connection. You can deploy multiple circuits as per your requirements, and these circuits can be connected to your on-premises with the help of different providers.
A service key is used to represent each circuit. This service is not a secret rather a standard GUID used to identify the circuit by the on-premises connectivity provider and Microsoft. If you are setting up ExpressRoute, this key will be shared with you and will be known to Microsoft and the connectivity provider. Each service key is mapped to an ExpressRoute circuit to preserve the uniqueness.
ExpressRoute has multiple peering options available. New ExpressRoute circuits include two independent peerings: private peering and Microsoft peering. However, existing peering may contain three peerings: Azure Private, Azure Public, and Microsoft. Independent BGP sessions and redundancy are implemented for each circuit. Between ExpressRoute and peering, the mapping is in the ratio 1:N where the value of N is from 1 to 3. This implies that each ExpressRoute circuit may have one, two, or all three peerings enabled. The bandwidth you opt for is shared across all the routing domains. Since we are discussing the routing domain, let’s take a quick look at the peering in an ExpressRoute circuit.
ExpressRoute Peering
As mentioned in the previous section, each ExpressRoute circuit will have multiple peering or routing domains linked with it. Redundancy is incorporated into all the routing domains using an identical pair of routers; thus, high availability is ensured. You have three types of routing domains: Azure Private, Azure Public (not available in new circuits), and Microsoft.
Let’s understand the differences between these routing domains.
Azure Private Peering As the name suggests, Azure private peering is for services that are using Azure private IP addresses. In other words, resources that are in the deployed Azure virtual network can be accessed using Azure private peering. This helps in the extension of on-premises network to the cloud and communication using the private IP addresses. The connectivity is established in a bidirectional way, which means that the IaaS or PaaS solutions deployed in the virtual networks can communicate with on-premises resources on their private IP addresses. If you take a close look at Figure 4.16, you can see the private peering (blue color) is directed toward the virtual network resources.
Azure Public Peering (Deprecated) In Figure 4.16, the red line represents Microsoft peering for O365, D365, and Azure public services. As stated earlier, Azure public peering is available only in the existing ExpressRoute circuits; any new circuits will have only Azure private and Microsoft peering. This is the reason why you are not able to see public peering in Figure 4.16.
Azure public peering is responsible for establishing connectivity between on-premises and Azure services that have public IP addresses (for example, Azure Storage). As this peering is dependent on the public endpoint, we call this Azure public peering.
In public peering, the traffic originated from the on-premises private IP address will be NAT by ExpressRoute before it reaches the public endpoint of Azure service. ExpressRoute uses its own NAT pool for providing IP addresses for the traffic coming from on-premises. Since this is not available for new ExpressRoute circuits, you will be using Microsoft peering to establish connectivity to Azure public services.
Microsoft Peering Microsoft peering can be leveraged to enable connectivity from the on-premises infrastructure to Microsoft online services, which includes Azure PaaS services, Microsoft 365, and Dynamics 365. Though Microsoft 365 was created to be accessed securely over the Internet, rerouting the traffic over ExpressRoute is quite beneficial. The benefits include 99.95 percent SLA and predictability of the networking components. A dedicated connection to Microsoft 365 can be created with the help of ExpressRoute.
Since Azure public peering is not available for new ExpressRoute circuits, you can use Microsoft peering to establish connections to Azure PaaS solutions and services that have a public endpoint. In Figure 4.16, you can see that the Microsoft peering (red color) is connected to O365, D365, Azure Storage, Azure SQL, Azure Cosmos DB, etc. You can only connect to services that have public IP addresses; any resources that are deployed to a virtual network and have private IP addresses can use Azure private peering.
You can create a connection from on-premises to the Microsoft cloud in different ways. The connection type is determined depending on which connection model of ExpressRoute you are using. Let’s shift your focus to connection models in ExpressRoute.
Leave a Reply