NOTE: The central shared ExpressRoute is no longer available to new customers. 
This service will go away on: <date to be determined> 
Existing customers are encouraged to migrate to the new UW Azure Platform via a UW-IT managed subscription. 

The UW Azure Platform includes redundant ExpressRoute circuits homed in geo-redundant locations, 
simplified networking via Azure VWAN capabilities, DNS resolution that supports private links, 
stronger security standards, and a 10% discount on Azure costs.

This page will be removed when this service is retired 
but is left as a courtesy for existing customers.

UW customers may have a need to access Azure based resources directly from the UW network, without traversing the internet. This need is sometimes referred to a site-to-site VPN with Azure. Microsoft provides the ExpressRoute product to meet this need. The UW has setup an ExpressRoute provider and you can purchase your own connection via the Azure ExpressRoute service catalog entry. Alternatively, you can leverage a centrally provided shared ExpressRoute at no additional cost. This page generally describes guidelines about ExpressRoute usage and also describes the centrally provided ExpressRoute.

Is the central shared ExpressRoute the right fit for me?

A shared ExpressRoute circuit has been established to offer a persistent, shared, bidirectional communication between Azure and UW Networks. ExpressRoute is site-to-site VPN connection. ExpressRoute can enable customers to access Azure hosted VMs and resources without exposing resources to the internet with public IP addresses. It also can allow Azure VMs to access resources which are not in Azure. The shared ExpressRoute currently has a 1GB/s bandwidth. The UW-IT Shared ExpressRoute connection is a shared resource. UW-IT expects customers to be good neighbors by not abusing the limited bandwidth available to the ExpressRoute circuit. It is not intended for:

• Backups
• Device and sensor streams
• Frequent database replication and migration
• VM replicas
• Other large data transfers

UW-IT reserves the right to disable your use of the central shared ExpressRoute, if your use significantly impacts other UW customers. If you have questions, please don't hesitate to ask UW-IT for clarification via help@uw.edu.

What is involved in enabling the central shared ExpressRoute?

To enable use of the central shared ExpressRoute, you must peer the Azure VNet in your Azure subscription with the UW Hub VNet which has the shared ExpressRoute's gateway. Architecturally, this makes your VNet a spoke in a hub/spoke relationship. The VNet peering allows your VNet traffic to be routed to the hub VNet. In addition to peering to the UW hub VNet, you also ask for ExpressRoute gateway transit to be enabled on the peering relationship. This allows your VNet traffic to be routed to the hub VNet and then, if needed, routed through the gateway to the UW network. The network routing described above is transitive, so clients on the UW network can also reach your VNet. Routing between spoke VNets is *not* enabled by default. The UW Azure Hub VNet has NETID Active Directory domain controllers, the UW Azure Bridge DNS solution, and in the future may also have other broadly useful network services. See the UW Hub VNet for more details.

What problems should I be aware of when using ExpressRoute with Azure?

There are several key problems to design for. These include:

• You should request and use a UW private address block for your Azure VNet. UW-IT has set aside the 10.4.0.0/17 block for Azure use. Use of IP addresses within this address space is *required* in order to setup peering with the UW Hub VNet. Use of any other address space will be blocked at the UW network end of the ExpressRoute gateway. Request your UW private address space for your Azure VNet via help@uw.edu.
• The possibility of assymmetric routing, i.e. when there is more than one network path between two resources, if one of the resources uses a different path than the other, then the responding connection will be refused. This can be addressed with careful network routing design and is most likely when you have an Azure resource with both public and private IP addresses.
• Private DNS resolution. Hosts with private IP addresses on the UW network generally register their DNS hostname with the UW DNS servers and can only be resolved from the UW network. Azure native services with private links have private IP addresses on the Azure network, have their hostnames registered with the Azure DNS server, and can only be resolved from the Azure network. Any given network client can only use one DNS server for hostname resolution. These general facts form the basis for the problems in this area. UW-IT has provided a solution for these problems. See the UW Azure Bridge DNS solution for more details.