- Set up an ExpressRoute circuit in the Azure console When deployed, you get a service key. When you validate a service key, you are presented with primary and secondary ports and can choose the port for the connection. You can use the key a second time and create another connection to the unused port. For more information, see the Microsoft help topic Tutorial: Create and modify an ExpressRoute circuit.
- With the service key, create and deploy your VXC As part of the VXC configuration, you can choose the peering type. The peering type can be either private or Microsoft. A defined peering type results in automatically configured peering with peers matched on both the Azure and Megaport sides and a deployed system with a known working configuration. You can modify the configuration once deployed.
Validate the service key
When you use the API to validate an Azure service key, the response includes ExpressRoute details of the associated ports and peers. You need the port details to create the VXCs. To validate the service key in the Postman collection- In Postman, expand Cloud Connectivity > MCR > Azure in the left navigation and select GET Look Up Azure Service Key.
- Add the service key to the endpoint.
-
Click Send to make a GET request to the API server.
Ordering a VXC with peering options
With the details from the service key, create a VXC to the primary port and another VXC to the secondary port. Make sure that you select an MCR in the same region as the Azure ports from the service key lookup request. If you specify the peering type in the API request for the VXC, Megaport will set up the IP addressing and BGP details on both the MCR and the Azure side to ensure a working BGP setup. To specify the peering type, add a peering type to the peers array in thepartnerConfig section. If a peers array does not exist, peers are retrieved from Azure. If peers are not specified when creating the VXC and there are no peers in Azure (which is normally the case for new service keys), the MCR peering will not be autoconfigured.
The MCR creates a VLAN for each configured peering type. If both private and Microsoft peering options are specified, the MCR configures two inner VLANs.
The peering types are remembered and cannot be changed if a key has been previously used.
-
Create a request with the POST Create VXC to Azure (v3) endpoint:
-
Update the Body of the request with the
productUidof the MCR, the name of the VXC, theproductUidof the Azure port, and the service key. Include the appropriate peering option. The maximum speed (rateLimit) is defined in the bandwidth value of the service key response. In this case, it is 200. The Azure VLAN (if specified) is the outer tag VLAN for Q-in-Q. If you don’t specify the VLAN, it will be autoprovisioned.
productUid of the secondary Azure port (change the productName and the bEnd: productUid).