MCR Connections to Microsoft Azure using ExpressRoute
To connect to ExpressRoute using MCR, you will firstly require a Microsoft ExpressRoute service key obtained via the Azure Resource Manager (ARM) portal. Follow the steps in our Azure KnowledgeBase article to obtain this.
As of 1 May 2018, the steps to configure manually the peering types and VLAN tags as well as manual IP assignments are no longer required. You will be able to choose Private (vNet) peering, Microsoft Peering (including previously Public peering addresses) or a combination of both when you establish your ExpressRoute connection from an MCR.
It is still a requirement to note that the CIDR address ranges you receive from the Private peering type should be unique from any others that are advertised into your MCR from any other connections to other locations on the Megaport network. Megaport will automatically assign APIPA (169.254.0.0/16) IP addresses for the Private BGP peering setup (a /29 or 8 individual IP addresses) and a corresponding range of public IP addresses for the Microsoft peering type (if selected), this can be NAT’ed back towards your MCR with private ranges if required. Megaport will automatically filter any exisiting cloud provider public routes that are advertised to your MCR from being advertised downstream to Azure.
Establishing peering types (Private and/or Microsoft)
We start by selecting “+Connection” on the MCR to add a new VXC, and the Destination type will be Cloud:
In the next step, you will be asked to provide the connection type (in this case ExpressRoute) and the Service Key obtained earlier:
Once you have selected your desired target connection point, you will be required to select either or both of the Private and Microsoft peering types:
In the next screen ‘3) Connection Details’ you will be asked the name of the connection (for display in the Megaport dashboard) and the rate limit. Note that the rate limit for the VXC will be capped at the maximum allowable as per that queried from the interrogation of the ExpressRoute service key.
No other details will be required in the following screens, continue following through with ‘Next‘ until you have added the item to your cart and then Check Out and Deploy.
Setup of the required elements will take around 5 minutes to completely deploy and configure the required peering types.
Inspecting the configuration
Once the VXC connection is deployed successfully you will see it attached to the MCR on the Megaport Portal dashboard:
In the ‘Configure A End’ tab of the VXC detail to Azure, you will see the following information populated:
- VLANs are set as 100 and 200 by default – 100 for Private peering and 200 for Microsoft
- Local ASN: 133937 – this is the default Megaport ASN
- Peer ASN: For Microsoft Azure via ExpressRoute this will be 12076 for all peering types
- Local IP and Peer IP: Will reflect the APIPA range for BGP peering (auto-configured) on Private peering, Microsoft peering will display a Megaport assigned public IP range (within 126.96.36.199/21).
- BGP Auth: This value is blank by default and is not a mandatory field for ExpressRoute connections as they traverse a private (non Internet) path. However if you do wish to enter one here, you will need to update it manually on the ExpressRoute configuration page to match as for security reasons the values do not synchronise automatically.
Confirming ExpressRoute configuration details
The corresponding ExpressRoute details screen on the ARM portal will show that the L2 connection is up (Provider Status = Provisioned) and Layer 3 for the Private (and/or Microsoft) peering is similarly configured:
By clicking on the Azure private peering type (red box above), you will be presented with the Private peering configuration blade
Values for both Primary and Secondary subnets are provided, regardless of whether only one of these peering locations is established. If you proceed to add a second ExpressRoute VXC using this service key, it will inherit the same peering types and automatically configure for the next available IP address allocation within that peering type.
Creation and linkage of Virtual Network Gateway
In addition to the ExpressRoute circuit you will be required to create a Virtual Network Gateway (VNG) and associate it to both your vNet(s) used for private peering, as well as linking the VNG to your ExpressRoute circuit to provide routing on the Azure side towards the MCR.
Be aware that creation of the VNG can take approximately 45 minutes, although this is a one time requirement.
Please follow the steps at Configure a virtual network gateway for ExpressRoute using the Azure portal to create the VNG (be aware, Microsoft charges will apply as per the ExpressRoute Gateways section of the Azure VPN gateway pricing page).
After the above operation is completed, you will also need to associate the ExpressRoute VNG to the ExpressRoute circuit above by following Connect a virtual network to an ExpressRoute circuit using the portal guidance.
To confirm that BGP/Layer 3 has successfully come up, you can return to the Azure private peering blade by clicking on the detail line above, and at click on ‘Get ARP records’. This function will take about one minute to populate data, but for a successful connection you should see a display similar to the following indicating MAC addresses resolved on both the ‘On-Prem’ and ‘Microsoft’ sides of the connection:
Switching to secondary, it is noted that this currently only shows a value for the Microsoft side of the connection, due to the VXC to the secondary target not yet being built:
(To configure this, you may return to the top of this guide and create another VXC from your MCR with the same ExpressRoute service key, however this time targeting the secondary router presentation).
Once Layer 3 BGP is active and confirmed by the above, you may also view the Route Table as seen by the Microsoft edge devices by clicking on ‘Get route table’ in the Private peering pane. It will display the next hop, weighting and AS path for the network values seen. This can also be toggled to view the secondary path route table, and you will see similar to the below when both primary and secondary VXCs are active:
Additional useful links: