Microsoft Azure ExpressRoute
Azure ExpressRoute ports
Customers need to first request an ExpressRoute circuit via the Microsoft Azure portal, using their Azure subscription. Customers will need to select an ExpressRoute PoP (e.g. Amsterdam, London or Dublin) and a ER circuit bandwidth (50Mbps-10Gbps).
The ExpressRoute circuit bandwidth determines the maximum bandwidth of the On Demand connection – for example, a 100Mbps ER circuit supports connection speeds up to 2 x 100Mbps (connectivity into Microsoft Azure is based on twin circuits).
When the requested is placed via the Azure portal, customers will receive a Service Key. Note that the Microsoft billing starts as soon as the Service Key is generated.
Microsoft ExpressRoute On Demand cloud ports are created by simply entering the Service Key and allocating a port name.
Azure ExpressRoute connections
Microsoft Azure ExpressRoute connections are always based on twin circuits in a 1+1 resilient configuration. This requires two separate ports at the A end site – a single A end port configuration is NOT supported.
For additional resilience, customers can select ports at two separate locations within the same physical building or for maximum resilience two separate physical buildings in the same country (for example, two separate data centres).
The cloud B end site is ALWAYS based on QinQ double tagged VLANs* – this is automatically configured when the “cloud port” option is selected. Microsoft allocate the outer VLAN at the handover with Colt, but this VLAN is not relevant to the customer configuration (Colt remove this VLAN on ingress).
* The handover is based on a 8100 (C-VLAN) Ethertype in a QinQ configuration, although this is not visible to customers
Multiple pairs of connections to a Microsoft port is NOT a supported configuration – the Microsoft ExpressRoute model is based on a single ExpressRoute instance per circuit connection.
The standard VLAN modes apply at both customer A end ports, which is summarised in the below table:
|Application||Open port||Circuit 1 / 2 occupies whole A end port||Port based handover, 3 Microsoft “inner” VLANs are passed transparently across the Colt network to the Microsoft ExpressRoute PoP. Customer is responsible for allocating inner VLANs|
|Add VLAN||Customer uses QinQ to wrap the three “inner” VLANs in a single “outer” VLAN||VLAN added on egress, towards customer (in translation mode). VLAN can be S-VLAN (88a8) or C-VLAN (8100). Standard H&S config. VLAN contains three “inner” VLANs. Customer needs to map inner VLANs to “outer” tag. Inner VLANs must use 8100 Ethertype|
The below diagram summarises the configuration, which is identical for both circuit connections in the 1+1 resilient pair.
Each On Demand circuit connection supports the three ExpressRoute BGP peerings (Private, Public, Microsoft), each peering is identified by an “inner VLAN” .
It is important to note the following:
- The outer VLAN at the Microsoft NNI is assigned by Microsoft when the customer requests a Service Key, and independent of the VLAN at the A end site
- The inner VLANs are the customer’s responsibility and are not assigned or modified by Colt. The customer must assign the same inner VLAN ID for both the primary and secondary peerings (for example, private peering VLAN 801 for primary & secondary., public peering 802, etc.)
- For Office 365 (Microsoft) peering, the customer MUST gain approval from Microsoft before this peering is activated
End-to-end customer journey
The customer journey to establish end to end connectivity to a Microsoft ExpressRoute is illustrated below:
Microsoft Azure Dedicated Ports
Connections to 10Gbps & 100Gbps ExpressRoute Direct (dedicated) ports can be supported via a standard DCNet On Demand port – providing a DC cross connect is requested via the On Demand portal (the Microsoft LOA should be attached to the cross connect request).