Encryption over ExpressRoute ​

This section shows you how to use Azure Virtual WAN to establish an IPsec/IKE VPN connection from your on-premises network to Azure over the private peering of an Azure ExpressRoute circuit.

This technique can provide an encrypted transit between the on-premises networks and Azure virtual networks over ExpressRoute, without going over the public internet or using public IP addresses.

Topology and routing

The following diagram shows an example of VPN connectivity over ExpressRoute private peering:

The diagram shows a network within the on-premises network connected to the Azure hub VPN gateway over ExpressRoute private peering. The connectivity establishment is straightforward:

• Establish ExpressRoute connectivity with an ExpressRoute circuit and private peering.
• Establish the VPN connectivity.

An important aspect of this configuration is routing between the on-premises networks and Azure over both the ExpressRoute and VPN paths.

Traffic from on-premises networks to Azure

For traffic from on-premises networks to Azure, the Azure prefixes (including the virtual hub and all the spoke virtual networks connected to the hub) are advertised via both the ExpressRoute private peering BGP and the VPN BGP. This results in two network routes (paths) toward Azure from the on-premises networks:

• One over the IPsec-protected path
• One directly over ExpressRoute without IPsec protection

To apply encryption to the communication, you must make sure that for the VPN-connected network in the diagram, the Azure routes via on-premises VPN gateway are preferred over the direct ExpressRoute path.

Traffic from Azure to on-premises networks

The same requirement applies to the traffic from Azure to on-premises networks. To ensure that the IPsec path is preferred over the direct ExpressRoute path (without IPsec), you have two options:

• Advertise more specific prefixes on the VPN BGP session for the VPN-connected network.
  • You can advertise a larger range that encompasses the VPN-connected network over ExpressRoute private peering, then more specific ranges in the VPN BGP session.
  • For example, advertise 10.0.0.0/16 over ExpressRoute, and 10.0.1.0/24 over VPN.
• Advertise disjoint prefixes for VPN and ExpressRoute.
  • If the VPN-connected network ranges are disjoint from other ExpressRoute connected networks, you can advertise the prefixes in the VPN and ExpressRoute BGP sessions, respectively.
  • For example, advertise 10.0.0.0/24 over ExpressRoute, and 10.0.1.0/24 over VPN.

In both examples, Azure will send traffic to 10.0.1.0/24 over the VPN connection rather than directly over ExpressRoute without VPN protection.

ExpressRoute and S2S coexisting connections ​

This section helps you configure ExpressRoute and Site-to-Site VPN connections that coexist.

Having the ability to configure Site-to-Site VPN and ExpressRoute has several advantages.

• You can configure Site-to-Site VPN as a secure failover path for ExpressRoute
• Use Site-to-Site VPNs to connect to sites that are not connected through ExpressRoute.

You can configure either gateway first. Typically, you will incur no downtime when adding a new gateway or gateway connection.

Network Limits and limitations ​

• Only route-based VPN gateway is supported
  • You must use a route-based VPN gateway.
  • You also can use a route-based VPN gateway with a VPN connection configured for 'policy-based traffic selectors'.
• The ASN of Azure VPN Gateway must be set to 65515
  • Azure VPN Gateway supports the BGP routing protocol
  • For ExpressRoute and Azure VPN to work together, you must keep the Autonomous System Number of your Azure VPN gateway at its default value, 65515.
    • If you previously selected an ASN other than 65515 and you change the setting to 65515, you must reset the VPN gateway for the setting to take effect.
• The gateway subnet must be /27 or a shorter prefix
  • (such as /26, /25), or you will receive an error message when you add the ExpressRoute virtual network gateway.
• Coexistence in a dual stack VNet is not supported
  • If you are using ExpressRoute IPv6 support and a dual-stack ExpressRoute gateway, coexistence with VPN Gateway will not be possible.

Zone redundant VNet gateway in Azure availability zones ​

You can deploy VPN and ExpressRoute gateways in Azure Availability Zones.

• This brings resiliency, scalability, and higher availability to virtual network gateways.
• Deploying gateways in Azure Availability Zones physically and logically separates gateways within a region, while protecting your on-premises network connectivity to Azure from zone-level failures.

Zone-redundant gateways ​

To automatically deploy your virtual network gateways across availability zones, you can use zone-redundant virtual network gateways. With zone-redundant gateways, you can benefit from zone-resiliency to access your mission-critical, scalable services on Azure.

Zonal gateways ​

To deploy gateways in a specific zone, you can use zonal gateways. When you deploy a zonal gateway, all instances of the gateway are deployed in the same Availability Zone.

Gateway SKUs ​

Zone-redundant and zonal gateways are available as gateway SKUs. There is a new virtual network gateway SKUs in Azure AZ regions. These SKUs are like the corresponding existing SKUs for ExpressRoute and VPN Gateway, except that they are specific to zone-redundant and zonal gateways. You can identify these SKUs by the "AZ" in the SKU name.

Public IP SKUs ​

Zone-redundant gateways and zonal gateways both rely on the Azure public IP resource Standard SKU. The configuration of the Azure public IP resource determines whether the gateway that you deploy is zone-redundant, or zonal. If you create a public IP resource with a Basic SKU, the gateway will not have any zone redundancy, and the gateway resources will be regional.

Zone-redundant gateways

• When you create a public IP address using the Standard public IP SKU without specifying a zone, the behavior differs depending on whether the gateway is a VPN gateway, or an ExpressRoute gateway.
• For a VPN gateway, the two gateway instances will be deployed in any 2 out of these three zones to provide zone-redundancy.
• For an ExpressRoute gateway, since there can be more than two instances, the gateway can span across all the three zones.

Zonal gateways

• When you create a public IP address using the Standard public IP SKU and specify the Zone (1, 2, or 3), all the gateway instances will be deployed in the same zone.

Regional gateways

• When you create a public IP address using the Basic public IP SKU, the gateway is deployed as a regional gateway and does not have any zone-redundancy built into the gateway.

Site-to-Site VPN failover path for ExpressRoute ​

You can configure a Site-to-Site VPN connection as a backup for ExpressRoute. This connection applies only to virtual networks linked to the Azure private peering path.

There is no VPN-based failover solution for services accessible through Azure Microsoft peering. The ExpressRoute circuit is always the primary link. Data flows through the Site-to-Site VPN path only if the ExpressRoute circuit fails.

To avoid asymmetrical routing, your local network configuration should also prefer the ExpressRoute circuit over the Site-to-Site VPN. You can prefer the ExpressRoute path by setting higher local preference for the routes received the ExpressRoute.

ExpressRoute peering ​

Configure peering for an ExpressRoute deployment

An ExpressRoute circuit has two peering options associated with it: Azure private, and Microsoft.

Each peering is configured identically on a pair of routers (in active-active or load sharing configuration) for high availability. Azure services are categorized as Azure public and Azure private to represent the IP addressing schemes.

Create Peering configuration

• You can configure Azure private peering and Microsoft peering for an ExpressRoute circuit.
  • Peering's can be configured in any order you choose. However, you must make sure that you complete the configuration of each peering one at a time.
• You must have an active ExpressRoute circuit.
  • Have the circuit enabled by your connectivity provider before you continue. To configure peering(s), the ExpressRoute circuit must be in a provisioned and enabled state.
• If you plan to use a shared key/MD5 hash, be sure to use the key on both sides of the tunnel.
  • The limit is a maximum of 25 alphanumeric characters.
  • Special characters are not supported.
• This only applies to circuits created with service providers offering Layer 2 connectivity services.
  • If you are using a service provider that offers managed Layer 3 services (typically an IPVPN, like MPLS), your connectivity provider configures and manages the routing for you.

Azure private peering / Microsoft peering ​

Choose between private peering only, Microsoft peering only, or both

The following table compares the two peering. Public peering is deprecated for new peering.

Summary: ​

Max. # prefixes supported per peering

• Private Peering
  • 4000 by default
  • 10,000 with ExpressRoute Premium
• Microsoft Peering
  • 200

IP address ranges supported

• Private Peering
  • Any valid IP address within your WAN.
• Microsoft Peering
  • Public IP addresses owned by you or your connectivity provider.

AS Number requirements

• Private Peering
  • Private and public AS numbers. You must own the public AS number if you choose to use one.
• Microsoft Peering
  • Private and public AS numbers. However, you must prove ownership of public IP addresses.

IP protocols supported

• Private Peering
  • IPv4, IPv6 (preview)
• Microsoft Peering
  • IPv4, IPv6

Routing Interface IP addresses

• Private Peering
  • RFC1918 and public IP addresses
• Microsoft Peering
  • Public IP addresses registered to you in routing registries.

MD5 Hash support

• Private Peering
  • Yes
• Microsoft Peering
  • Yes

You may enable one or more of the routing domains as part of your ExpressRoute circuit. You can choose to have all the routing domains put on the same VPN if you want to combine them into a single routing domain. The recommended configuration is

• Private peering is connected directly to the core network
• Public and Microsoft peering links are connected to your DMZ.

Each peering requires separate BGP sessions (one pair for each peering type). The BGP session pairs provide a highly available link. If you are connecting through layer 2 connectivity providers, you are responsible for configuring and managing routing.

Configure private peering ​

Azure compute services, namely virtual machines (IaaS) and cloud services (PaaS), that are deployed within a virtual network can be connected through the private peering domain.

The private peering domain is a trusted extension of your core network into Microsoft Azure. You can set up bi-directional connectivity between your core network and Azure virtual networks (VNets). This peering lets you connect to virtual machines and cloud services directly on their private IP addresses.

You can connect more than one virtual network to the private peering domain.

Configure Microsoft peering ​

Microsoft 365 was created to be accessed securely and reliably via the Internet. Because of this, it is recommended to use ExpressRoute for specific scenarios.

Connectivity to Microsoft online services (Microsoft 365 and Azure PaaS services) occurs through Microsoft peering.

You can enable bidirectional connectivity between your WAN and Microsoft cloud services through the Microsoft peering routing domain. You must connect to Microsoft cloud services only over public IP addresses that are owned by you or your connectivity provider and you must adhere to all the defined rules.

Configure route filters for Microsoft Peering ​

Route filters are a way to consume a subset of supported services through Microsoft peering.

Microsoft 365 services such as Exchange Online, SharePoint Online, and Skype for Business, are accessible through the Microsoft peering. When Microsoft peering gets configured in an ExpressRoute circuit, all prefixes related to these services gets advertised through the BGP sessions that are established. A BGP community value is attached to every prefix to identify the service that is offered through the prefix.

Connectivity to all Azure and Microsoft 365 services causes many prefixes to gets advertised through BGP.

The large number of prefixes significantly increases the size of the route tables maintained by routers within your network. If you plan to consume only a subset of services offered through Microsoft peering, you can reduce the size of your route tables in two ways. You can:

• Filter out unwanted prefixes by applying route filters on BGP communities. Route filtering is a standard networking practice and is used commonly within many networks.

• Define route filters and apply them to your ExpressRoute circuit.

  • A route filter is a new resource that lets you select the list of services you plan to consume through Microsoft peering.
  • ExpressRoute routers only send the list of prefixes that belong to the services identified in the route filter.

About route filters ​

When Microsoft peering gets configured on your ExpressRoute circuit, the Microsoft Edge routers establish a pair of BGP sessions with your edge routers through your connectivity provider.

No routes are advertised to your network.

• To enable route advertisements to your network, you must associate a route filter.

A route filter lets you identify services you want to consume through your ExpressRoute circuit's Microsoft peering.

It is essentially an allowed list of all the BGP community values. Once a route filter resource gets defined and attached to an ExpressRoute circuit, all prefixes that map to the BGP community values gets advertised to your network.

To attach route filters with Microsoft 365 services, you must have authorization to consume Microsoft 365 services through ExpressRoute. If you are not authorized to consume Microsoft 365 services through ExpressRoute, the operation to attach route filters fails.

Create a route filter and a filter rule ​

A route filter can have only one rule, and the rule must be of type 'Allow'. This rule can have a list of BGP community values associated with it.

1. Select Create a resource then search for Route filter

2. Place the route filter in a resource group.

   • Ensure the location is the same as the ExpressRoute circuit.
   • Select Review + create and then Create.

Create a filter rule ​

To add and update rules, select the manage rule tab for your route filter.

• Select the services you want to connect to from the drop-down list and save the rule when done.

Attach the route filter to an ExpressRoute circuit ​

• Attach the route filter to a circuit by selecting the + Add Circuit button and selecting the ExpressRoute circuit from the drop-down list.

• If the connectivity provider configures peering for your ExpressRoute circuit, refresh the circuit from the ExpressRoute circuit page before you select the + Add Circuit button.

Common tasks ​

To get the properties of a route filter

• You can view properties of a route filter when you open the resource in the portal.

To update the properties of a route filter

• You can update the list of BGP community values attached to a circuit by selecting the Manage rule button.
  • Select the service communities you want and then select Save.

To detach a route filter from an ExpressRoute circuit

• To detach a circuit from the route filter, right-click on the circuit and select Disassociate.

Clean up resources

• You can delete a route filter by selecting the Delete button. Ensure the Route filter is not associate to any circuits before doing so.

Reset peering ​

Sign into the Azure portal

• From a browser, go to the Azure portal, and then sign in with your Azure account.

Reset a peering

• You can reset the Microsoft peering and the Azure private peering on an ExpressRoute circuit independently.

1. Choose the circuit that you want to change.
2. Choose the peering configuration that you want to reset.
3. Clear the Enable Peering check box, and then select Save to disable the peering configuration.
4. Select the Enable Peering check box, and then select Save to re-enable the peering configuration.

Connect an ExpressRoute circuit to a virtual network ​

An ExpressRoute circuit represents a logical connection between your on-premises infrastructure and Microsoft cloud services through a connectivity provider.

You can order multiple ExpressRoute circuits. Each circuit can be in the same or different regions and can be connected to your premises through different connectivity providers.

ExpressRoute circuits do not map to any physical entities. A circuit is uniquely identified by a standard GUID called as a service key (s-key).

Connect a virtual network to an ExpressRoute circuit ​

• You must have an active ExpressRoute circuit.

• Ensure that you have Azure private peering configured for your circuit.

• Ensure that Azure private peering gets configured and establishes BGP peering between your network and Microsoft for end-to-end connectivity.

• Ensure that you have a virtual network and a virtual network gateway created and fully provisioned. A virtual network gateway for ExpressRoute uses the GatewayType 'ExpressRoute', not VPN.

• You can link up to 10 virtual networks to a standard ExpressRoute circuit.

  • All virtual networks must be in the same geopolitical region when using a standard ExpressRoute circuit.

• A single VNet can be linked to up to 16 ExpressRoute circuits.

  • Use the following process to create a new connection object for each ExpressRoute circuit you are connecting to.
  • The ExpressRoute circuits can be in the same subscription, different subscriptions, or a mix of both.

• If you enable the ExpressRoute premium add-on, you can link virtual networks outside of the geopolitical region of the ExpressRoute circuit.

  • The premium add-on will also allow you to connect more than 10 virtual networks to your ExpressRoute circuit depending on the bandwidth chosen.

• To create the connection from the ExpressRoute circuit to the target ExpressRoute virtual network gateway, the number of address spaces advertised from the local or peered virtual networks needs to be equal to or less than 200.

  • Once the connection has been successfully created, you can add additional address spaces, up to 1,000, to the local or peered virtual networks.

Add a VPN to an ExpressRoute deployment ​

This section helps you configure secure encrypted connectivity between your on-premises network and your Azure virtual networks (VNets) over an ExpressRoute private connection.

You can use Microsoft peering to establish a site-to-site IPsec/IKE VPN tunnel between your selected on-premises networks and Azure VNets. Configuring a secure tunnel over ExpressRoute allows for data exchange with confidentiality, anti-replay, authenticity, and integrity.

For high availability and redundancy, you can configure multiple tunnels over the two MSEE-PE pairs of an ExpressRoute circuit and enable load balancing between the tunnels.

VPN tunnels over Microsoft peering can be terminated either using VPN gateway or using an appropriate Network Virtual Appliance (NVA) available through Azure Marketplace.

You can exchange routes statically or dynamically over the encrypted tunnels without exposing the route exchange to the underlying Microsoft peering. In this section, BGP (different from the BGP session used to create the Microsoft peering) is used to dynamically exchange prefixes over the encrypted tunnels.

Steps

• Configure Microsoft peering for your ExpressRoute circuit.
• Advertise selected Azure regional public prefixes to your on-premises network via Microsoft peering.
• Configure a VPN gateway and establish IPsec tunnels
• Configure the on-premises VPN device.
• Create the site-to-site IPsec/IKE connection.
• (Optional) Configure firewalls/filtering on the on-premises VPN device.
• Test and validate the IPsec communication over the ExpressRoute circuit.

Connect geographically dispersed networks with ExpressRoute global reach ​

Use cross-region connectivity to link multiple ExpressRoute locations ​

There are various ways of designing and implementing ExpressRoute based on specific organizational requirements.

ExpressRoute connections enable access to the following services:

• Microsoft Azure services
• Microsoft 365 services

Connectivity to all regions within a geopolitical region

You can connect to Microsoft in one of the peering locations and access regions within the geopolitical region.

For example, if you connect to Microsoft in Amsterdam through ExpressRoute, you will have access to all Microsoft cloud services hosted in Northern and Western Europe.

Global connectivity with ExpressRoute Premium

You can enable ExpressRoute Premium to extend connectivity across geopolitical boundaries. For example, if you connect to Microsoft in Amsterdam through ExpressRoute, you will have access to all Microsoft cloud services hosted in all regions across the world. You can also access services deployed in South America or Australia the same way you access North and West Europe regions.

• National clouds are excluded.

Local connectivity with ExpressRoute Local

You can transfer data cost-effectively by enabling the Local SKU. With Local SKU, you can bring your data to an ExpressRoute location near the Azure region you want. With Local, Data transfer is included in the ExpressRoute port charge.

Across on-premises connectivity with ExpressRoute Global Reach

You can enable ExpressRoute Global Reach to exchange data across your on-premises sites by connecting your ExpressRoute circuits. For example, if you have a private data center in California connected to an ExpressRoute circuit in Silicon Valley and another private data center in Texas connected to an ExpressRoute circuit in Dallas. With ExpressRoute Global Reach, you can connect your private data centers together through these two ExpressRoute circuits. Your cross-data-center traffic will traverse through Microsoft's network.

Rich connectivity partner ecosystem

ExpressRoute has a constantly growing ecosystem of connectivity providers and systems integrator partners. You can refer to ExpressRoute partners and peering locations.

Connectivity to national clouds

Microsoft operates isolated cloud environments for special geopolitical regions and customer segments.

ExpressRoute Direct

ExpressRoute Direct provides customers the opportunity to connect directly into Microsoft’s global network at peering locations strategically distributed across the world. ExpressRoute Direct provides dual 100-Gbps connectivity, which supports Active/Active connectivity at scale.

ExpressRoute is a private and resilient way to connect your on-premises networks to the Microsoft Cloud. You can access many Microsoft cloud services such as Azure and Microsoft 365 from your private data center or your corporate network. For example, you may have a branch office in San Francisco with an ExpressRoute circuit in Silicon Valley and another branch office in London with an ExpressRoute circuit in the same city. Both branch offices have high-speed connectivity to Azure resources in US West and UK South. However, the branch offices cannot connect and send data directly with one another. In other words, 10.0.1.0/24 can send data to 10.0.3.0/24 and 10.0.4.0/24 network, but NOT to 10.0.2.0/24 network.

Choose when to use ExpressRoute global reach ​

ExpressRoute Global Reach is designed to complement your service provider’s WAN implementation and connect your branch offices across the world.

For example, if your service provider primarily operates in the United States and has linked all your branches in the U.S., but the service provider does not operate in Japan and Hong Kong SAR, with ExpressRoute Global Reach you can work with a local service provider and Microsoft will connect your branches there to the ones in the U.S. using ExpressRoute and the Microsoft global network.

Configure ExpressRoute global reach ​

These steps show you how to configure ExpressRoute Global Reach using Azure portal.

Before you begin ​

Before you start configuration, confirm the following criteria:

• You understand ExpressRoute circuit provisioning workflows.
• Your ExpressRoute circuits are in a provisioned state.
• Azure private peering is configured on your ExpressRoute circuits.
• If you want to run PowerShell locally, verify that the latest version of Azure PowerShell is installed on your computer.

Identify circuits

Identify the ExpressRoute circuits that you want use. You can enable ExpressRoute Global Reach between the private peering of any two ExpressRoute circuits, if they are in the supported countries/regions. The circuits are required to be created at different peering locations.

• If your subscription owns both circuits, you can choose either circuit to run the configuration in the following sections.

• If the two circuits are in different Azure subscriptions, you need authorization from one Azure subscription.

  • Then you pass in the authorization key when you run the configuration command in the other Azure subscription.

Enable connectivity

Enable connectivity between your on-premises networks. There are separate sets of instructions for circuits that are in the same Azure subscription, and circuits that are different subscriptions.

ExpressRoute circuits in the same Azure subscription

1. Select the Azure private peering configuration.

2. Select Add Global Reach to open the Add Global Reach configuration page.

3. On the Add Global Reach configuration page, give a name to this configuration.
   • Select the ExpressRoute circuit you want to connect this circuit to and enter in a /29 IPv4 for the Global Reach subnet.
   • Azure uses IP addresses in this subnet to establish connectivity between the two ExpressRoute circuits.
   • Do not use the addresses in this subnet in your Azure virtual networks, or in your on-premises network. Select Add to add the circuit to the private peering configuration.

4. Select Save to complete the Global Reach configuration. When the operation completes, you will have connectivity between your two on-premises networks through both ExpressRoute circuits.

Verify the configuration

Verify the Global Reach configuration by selecting Private peering under the ExpressRoute circuit configuration. When configured correctly your configuration should look as followed:

Disable connectivity

To disable connectivity between an individual circuit, select the delete button next to the Global Reach name to remove connectivity between them. Then select Save to complete the operation.

Improve data path performance between networks with ExpressRoute FastPath ​

ExpressRoute virtual network gateway is designed to exchange network routes and route network traffic.

FastPath is designed to improve the data path performance between your on-premises network and your virtual network. When enabled, FastPath sends network traffic directly to virtual machines in the virtual network, bypassing the gateway.

Circuits FastPath is available on all ExpressRoute circuits.

Gateways FastPath still requires a virtual network gateway to be created to exchange routes between virtual network and on-premises network.

Gateway requirements for ExpressRoute FastPath ​

To configure FastPath, the virtual network gateway must be either:

• Ultra-Performance
• ErGw3AZ

Limitations While FastPath supports most configurations, it does not support the following features:

• UDR on the gateway subnet:

  • This UDR has no impact on the network traffic that FastPath sends directly from your on-premises network to the virtual machines in Azure virtual network.

• VNet Peering:

  • If you have other virtual networks peered with the one that is connected to ExpressRoute, the network traffic from your on-premises network to the other virtual networks (i.e., the so-called "Spoke" VNets) will continue to be sent to the virtual network gateway.
  • The workaround is to connect all the virtual networks to the ExpressRoute circuit directly.

• Basic Load Balancer:

  • If you deploy a Basic internal load balancer in your virtual network or the Azure PaaS service you deploy in your virtual network uses a Basic internal load balancer, the network traffic from your on-premises network to the virtual IPs hosted on the Basic load balancer will be sent to the virtual network gateway.
  • The solution is to upgrade the Basic load balancer to a Standard load balancer.

• Private Link:

  • If you connect to a private endpoint in your virtual network from your on-premises network, the connection will go through the virtual network gateway.

Configure ExpressRoute FastPath ​

To enable FastPath, connect a virtual network to an ExpressRoute circuit using the Azure portal.

This section shows you how to create a connection to link a virtual network to an Azure ExpressRoute circuit using the Azure portal. The virtual networks that you connect to your Azure ExpressRoute circuit can either be in the same subscription or be part of another subscription.

Prerequisites

• Review the routing requirements, and workflows before you begin configuration.

• You must have an active ExpressRoute circuit.

• Follow the instructions to create an ExpressRoute circuit and have the circuit enabled by your connectivity provider.

• Ensure that you have Azure private peering configured for your circuit.

• Ensure that Azure private peering gets configured and establishes BGP peering between your network and Microsoft for end-to-end connectivity.

• Ensure that you have a virtual network and a virtual network gateway created and fully provisioned.

  • A virtual network gateway for ExpressRoute uses the GatewayType 'ExpressRoute', not VPN.

• You can link up to 10 virtual networks to a standard ExpressRoute circuit.

  • All virtual networks must be in the same geopolitical region when using a standard ExpressRoute circuit.

• A single VNet can be linked to up to 16 ExpressRoute circuits.

  • Use the following process to create a new connection object for each ExpressRoute circuit you are connecting to.
  • The ExpressRoute circuits can be in the same subscription, different subscriptions, or a mix of both.

• If you enable the ExpressRoute premium add-on, you can link virtual networks outside of the geopolitical region of the ExpressRoute circuit.

  • The premium add-on will also allow you to connect more than 10 virtual networks to your ExpressRoute circuit depending on the bandwidth chosen.

• To create the connection from the ExpressRoute circuit to the target ExpressRoute virtual network gateway, the number of address spaces advertised from the local or peered virtual networks needs to be equal to or less than 200.

  • Once the connection has been successfully created, you can add additional address spaces, up to 1,000, to the local or peered virtual networks.

Connect a VNet to a circuit - same subscription ​

1. To create a connection Ensure that your ExpressRoute circuit and Azure private peering have been configured successfully. Your ExpressRoute circuit should look like the following image:

2. You can now start provisioning a connection to link your virtual network gateway to your ExpressRoute circuit. Select Connection > Add to open the Add connection page.

3. Enter a name for the connection and then select Next: Settings >.

4. Select the gateway that belongs to the virtual network that you want to link to the circuit and select Review + create. Then select Create after validation completes.

5. After your connection has been successfully configured, your connection object will show the information for the connection.

Administration - About circuit owners and circuit users

The 'circuit owner' is an authorized Power User of the ExpressRoute circuit resource.

The circuit owner can create authorizations that can be redeemed by 'circuit users'. Circuit users are owners of virtual network gateways that are not within the same subscription as the ExpressRoute circuit. Circuit users can redeem authorizations (one authorization per virtual network).

The circuit owner has the power to modify and revoke authorizations at any time. Revoking an authorization results in all link connections being deleted from the subscription whose access was revoked.

Circuit owner operations ​

To create a connection authorization ​

The circuit owner creates an authorization, which creates an authorization key to be used by a circuit user to connect their virtual network gateways to the ExpressRoute circuit. An authorization is valid for only one connection.

1. In the ExpressRoute page, select Authorizations and then type a name for the authorization and select Save.

2. Once the configuration is saved, copy the Resource ID and the Authorization Key.

To delete a connection authorization

You can delete a connection by selecting the Delete icon for the authorization key for your connection.

If you want to delete the connection but retain the authorization key, you can delete the connection from the connection page of the circuit.

Circuit user operations ​

The circuit user needs the resource ID and an authorization key from the circuit owner.

To redeem a connection authorization

1. Select the + Create a resource button. Search for Connection and select Create.

2. Make sure the Connection type is set to ExpressRoute.
   • Select the Resource group and Location, then select OK in the Basics page.

3. In the Settings page, Select the Virtual network gateway and check the Redeem authorization check box.
   • Enter the Authorization key and the Peer circuit URI and give the connection a name. Select OK.

4. Review the information in the Summary page and select OK.

Clean up resources

• You can delete a connection and unlink your VNet to an ExpressRoute circuit by selecting the Delete icon on the page for your connection.