ExpressRoute Circuit Design and Routing

Azure ExpressRoute lets you extend your on-premises networks into the Microsoft cloud over a private connection facilitated by a connectivity provider. This connection is more reliable, more secure, offers lower latencies, and provides higher bandwidth than typical internet-based connections. ExpressRoute connections do not go over the public internet, so they are not subject to internet latency, packet loss, or security risks. This makes ExpressRoute ideal for scenarios like disaster recovery, large-scale data migration, hybrid applications, and regulatory compliance where data cannot traverse the public internet.

An ExpressRoute circuit is a logical connection between your on-premises infrastructure and Microsoft's cloud. It is established through a connectivity provider (e.g., AT&T, Verizon, Equinix) that provisions a physical or virtual connection from your location to a Microsoft Enterprise Edge (MSEE) router at a peering location. The circuit is identified by a service key (a GUID) that you use to link the circuit to your Azure subscription.

Once the circuit is provisioned, you create two BGP sessions between your router and the MSEE routers: one for private peering (to access Azure VNets) and one for Microsoft peering (to access Microsoft SaaS services like Office 365, Dynamics 365, and Azure PaaS services). Each peering uses a /30 subnet for BGP peering IP addresses. Private peering uses VLAN ID 0 (default) or a custom VLAN ID, and Microsoft peering uses a public VLAN ID. BGP communities are used to control route advertisement and redistribution.

Every ExpressRoute circuit consists of two redundant connections from the MSEE devices at the peering location to your provider's edge routers. These two connections are active/active by default, meaning both carry traffic simultaneously. For higher availability, you can create two ExpressRoute circuits (one primary, one secondary) connected to different MSEE devices at different peering locations. This is known as ExpressRoute Resiliency. The exam expects you to know that a single circuit provides redundancy within the same location, but for full resiliency, you need two circuits from different providers or locations.

BGP (Border Gateway Protocol) is used to exchange routes between your on-premises network and Azure. For private peering, you advertise your on-premises prefixes to Azure, and Azure advertises the VNet address spaces back to you. For Microsoft peering, you advertise public IP prefixes that you own (or that are assigned to you), and Azure advertises Microsoft public IP prefixes. BGP timers: Keepalive interval is 60 seconds, hold timer is 180 seconds by default. You can configure custom BGP timers but the exam focuses on default values.

Route limits: For private peering, you can advertise up to 1000 routes from on-premises (200 with a standard circuit). For Microsoft peering, the limit is 200 routes. Azure will not accept more than the limit; excess routes are ignored. You can request a route limit increase by opening a support ticket.

To connect a VNet to an ExpressRoute circuit, you need an ExpressRoute gateway (a virtual network gateway) in the VNet. The gateway is deployed in a dedicated subnet called GatewaySubnet. The gateway SKU determines throughput and performance: Standard (1 Gbps), High Performance (2 Gbps), Ultra Performance (10 Gbps). For cross-region connectivity, you use ExpressRoute Global Reach, which allows you to connect two ExpressRoute circuits from different on-premises locations to each other through Azure's backbone, enabling private connectivity between your sites.

ExpressRoute Direct gives you the ability to connect directly to Microsoft's global network at a peering location with two 10 Gbps or 100 Gbps ports. This bypasses the connectivity provider, giving you more control and potentially lower costs for high-bandwidth scenarios. It supports both active/active and active/passive configurations. The exam may ask about ExpressRoute Direct as a solution for large-scale data ingestion or when a provider is not an option.

To create an ExpressRoute circuit using Azure CLI:

az network express-route create --resource-group myRG --name myCircuit --bandwidth 1000 --provider "Equinix" --peering-location "Silicon Valley" --sku-family MeteredData --sku-tier Standard

To configure private peering:

az network express-route peering create --resource-group myRG --circuit-name myCircuit --peering-type AzurePrivatePeering --peer-asn 65001 --primary-peer-subnet 10.0.0.0/30 --secondary-peer-subnet 10.0.1.0/30 --vlan-id 100

To verify the circuit status:

az network express-route list --resource-group myRG -o table
az network express-route show --resource-group myRG --name myCircuit

ExpressRoute integrates with Azure VPN Gateway for site-to-site VPN as a backup (ExpressRoute + VPN failover). It also works with Azure Virtual WAN, where you can connect ExpressRoute circuits to a Virtual WAN hub for centralized networking. ExpressRoute Global Reach allows interconnection of circuits across regions. For monitoring, you can use Azure Monitor and Network Performance Monitor to track circuit health and performance.

A large financial services company has a primary data center in New York and a secondary in Chicago. They need to extend their on-premises network to Azure for disaster recovery and burst capacity. They order two ExpressRoute circuits: one from Equinix NY to Azure East US, and another from Equinix Chicago to Azure Central US. Both circuits are configured with private peering. They use BGP ASN 65001 on-premises. They advertise their on-premises /16 supernet to Azure. The circuits are active/active, with traffic load-balanced. They also enable ExpressRoute Global Reach to connect the two on-premises sites via Azure's backbone, eliminating the need for MPLS. Misconfiguration: If they forget to enable Global Reach on both circuits, the on-premises sites cannot communicate through Azure, and they must rely on their own WAN.

A global retail chain uses Office 365 and Dynamics 365. They want to ensure reliable, low-latency access for their employees. They deploy ExpressRoute circuits in each major region with Microsoft peering. They advertise their public IP prefixes (e.g., 203.0.113.0/24) to Azure. They configure route filters to control which Microsoft services are accessible over the ExpressRoute. They also set up a VPN gateway as a backup in case the ExpressRoute circuit fails. Performance: Each circuit provides 1 Gbps, and they use BGP communities to prioritize traffic. Common issue: If they advertise a prefix that overlaps with a Microsoft public prefix, BGP may reject the route, causing connectivity loss.

A media company needs to upload petabytes of video content to Azure Blob Storage daily. They use ExpressRoute Direct with 10 Gbps ports at a peering location. They connect their on-premises storage arrays directly to the Microsoft edge without a provider. They configure private peering to access VNets hosting the storage accounts. They use multiple circuits for load balancing and failover. Monitoring: They use Azure Monitor to track circuit utilization and set alerts for >80% utilization. Misconfiguration: If they use the wrong VLAN ID or BGP ASN, the peering will not establish, delaying the data transfer.