This topic describes ways to connect your on-premises network equipment to a cloud service provider (CSP) that uses Q-in-Q, such as Azure ExpressRoute. In addition, because some CSPs require Q-in-Q, but not all network devices support it, or the mixing of single and multiple tags on a single physical interface (“selective Q-in-Q”), this topic includes ways to configure multiple layer VLAN tag handling on network devices without native Q-in-Q support.
Q-in-Q, also known as 802.1ad, is a protocol commonly used by network service providers (NSPs) to provide more Layer 2 flexibility. Q-in-Q allows multiple VLAN tags to be inserted into a single Ethernet frame. Stacking multiple VLAN tags in a frame allows isolation of routing domains, because the additional tags identify and separate customer traffic. By using a different VLAN tag for each customer, the traffic is identified within the frame and is transferred throughout the service provider network.
With Q-in-Q, as a packet travels from an NSP or carrier network to a cloud (or other) service provider’s VLAN, inner VLAN tags (C-Tags) that identify the customer traffic are inserted inside of the outer VLAN tags (S-Tags) provided by the service provider. The S-Tag provides a single VLAN that encapsulates multiple VLANs within it. In this configuration, a single VXC may carry the multiple VLAN tags between the two network endpoints.
Understanding Q-in-Q with Megaport VXCs
A VXC (Virtual Cross Connect) is a point-to-point Layer 2 circuit between two endpoints that is mapped with a VLAN ID on each end, optionally with A and B-End VLAN tags being independently mapped across the Megaport network.
This figure shows an Azure ExpressRoute with private peering and Microsoft Peering enabled. A VXC connects a customer edge to a Microsoft edge on VLAN 1000 (S-Tag). The customer edge supports Q-in-Q. The private peering is running on VLAN 100 (C-Tag) and Microsoft Peering is running on VLAN 200 (C-Tag) to establish Layer 3 connections and BGP peering with Azure.
What if my routers or switches don’t support Q-in-Q?
This section describes ways to connect to a B-End service that requires Q-in-Q even when the network equipment terminating your Megaport connection doesn’t natively support it.
|Q-in-Q breakout for Azure ExpressRoute||You can configure the VXC so that Megaport removes the Q-in-Q requirement by remapping one of the B-End VLAN IDs for Private Peering or Microsoft Peering to the customer Megaport-facing VLAN (A-End).||You can only use a single Microsoft peering type per VXC.|
|Untag the VXC attached to the customer Port||You can configure the VXC as untagged to automatically remove the S-Tag.||Untagging a VLAN limits the Port to a single VXC connection. Employing this method means that your Port will only be able to configure a single B-End target, although it will receive all inner/C-Tags from that peer as single/dot1q tagged.|
|Deploy a Megaport Cloud Router||You can deploy a Megaport Cloud Router (MCR) to automatically manage the Q-in-Q requirements for one or both peering types.||Additional cost of the MCR and additional VXC to MCR.|
A VXC connecting to Microsoft ExpressRoute may contain one or two inner VLAN tags. These are the C-tags configured in the Microsoft Azure console for the specified peering type/s. Note that Q-in-Q is a requirement in this scenario, even if only a single Microsoft edge device (primary or secondary) or peering type (private or Microsoft) is employed. Network equipment that supports Q-in-Q is able to access these inner tags by stripping the outer VLAN tag (S-Tag). If your network equipment does not support Q-in-Q, it cannot access the inner tags.
Other Q-in-Q workarounds exist, such as handling at the customer side via multiple devices to de-encapsulate the Q-in-Q frames, or using loopback cables within a single device to manage this via cascading through multiple ports with different VLAN configurations for inner and outer tags. However, this is generally not recommended in production networks.
Q-in-Q breakout for Azure ExpressRoute
For Microsoft Azure ExpressRoute connections, the Megaport optimized experience in presenting a Microsoft Service Key (and associated primary and secondary target endpoint selection) provides an ability to break out the encapsulated C-Tag for a specified Azure peering type. This functionality is enabled by toggling on the Configure single Azure peering VLAN in the Connection Details panel of a new ExpressRoute connection, after selecting a primary or secondary target B-End port.
By enabling the Azure VLAN breakout functionality, you are requested to input an Azure peering VLAN that will match with the value that you configure (in a future step) upon the selected Peering type configuration from the Azure ExpressRoute configuration (via Microsoft Azure portal or other configuration method). For details, see Tutorial: Create and modify peering for an ExpressRoute circuit using the Azure portal.
If you leave the Preferred A-End VLAN field blank, a randomly chosen VLAN will be assigned for your VXC when you place the order, otherwise enter a VLAN and a validation check will be performed to ensure this VLAN is available.
This example shows that an Azure C-tag value of 200 (for either a Private or Microsoft peering type on the associated ExpressRoute circuit) is being transparently mapped to a single-tagged VXC VLAN value of 3001. That is, the customer device attached to the physical Megaport interface need not be configured for any Q-in-Q settings, as dot1q VLAN 3001 will be conferred to the associated Microsoft facing B-End edge device as correctly labelled.
In this configuration it is possible to use both the primary and secondary Microsoft ExpressRoute endpoints on a given ExpressRoute circuit to map to different VLAN tags on a single customer-side port. This is compliant for the purposes of the Azure ExpressRoute Service Level Agreement (SLA). However, we recommended that you employ either single site port and device (zonal) diversity, or split the primary/secondary ExpressRoute connections across two Megaport-enabled locations to ensure no single point of failure exists with the configuration.
For details on Azure ExpressRoute SLA, see SLA for Azure ExpressRoute.
With the method featured above it is not possible to use more than one peering type across either of the primary or secondary ExpressRoute facing VXCs, as this tag translation may only occur once per VXC circuit path. Further workarounds are detailed below should this be desired, however, note that segmentation of bandwidth between multiple peering types on a single ExpressRoute circuit pair is not currently supported by Microsoft. In most cases it is preferred to deploy two ExpressRoute pairs to achieve this configuration goal.
The following sections describe workarounds that continue with the Microsoft ExpressRoute example. Note that these workarounds are not unique to Azure endpoints and may also be used for other connections across Megaport where the B-End may specify or require Q-in-Q to be used to carry multiple C-Tag/inner VLANs within a single S-Tag/outer VXC VLAN. The Microsoft ExpressRoute example is used for continuity of the customer scenario.
Configure the VXC as untagged to automatically manage the S-Tag
Employing this method means that the customer Megaport will only be able to configure a single B-End target, though it will receive all inner/C-tags from that peer as single/dot1q tagged.
You can configure the VXC so Megaport removes the outer VLAN (S-Tag) and presents one or both of the inner VLAN (C-Tag/s) for Private Peering, Microsoft Peering, or both, to the customer Megaport. Currently, this process allows only one VXC per ExpressRoute Circuit Connection (selecting from Primary or Secondary port presentation), although both peering types can be supported across this VXC as they will be presented to the customer port as one or two dot1q VLANs (Private, Microsoft Peering, or both).
The customer port will receive the inner VLAN tag/s as defined on the Azure portal under the specified peering type/s at the A-End customer port. For details, see Connecting to Microsoft Azure ExpressRoute.
Each ExpressRoute subscription includes two port targets at the chosen Microsoft edge location. To take delivery of both the primary and secondary ExpressRoute circuits, you’ll require two Ports from Megaport in this configuration. The Azure VNET VLAN tag/s are the same across both Ports. Megaport cannot change the VLAN tag on the primary and secondary circuits and it cannot deliver the same VLAN twice on the same physical interface.
If you configure only private or public peering on the Azure ExpressRoute configuration, only the VLAN associated with the ExpressRoute service key will be available on the configured VXC, mapped one-to-one with the customer port.
Deploy a Megaport Cloud Router
The Megaport Cloud Router (MCR) supports multi-cloud, multi-region enablement, including support for Q-in-Q to connect to multiple cloud destinations. The S-Tags, or outer tags, belong to the A-End VLAN associated with your MCR and will transparently carry your C-Tags. The S-Tags are automatically configured when provisioning your private and public peering to Azure Cloud in the Megaport Portal. This figure shows an example configuration:
When multiple Azure VXCs on an MCR populate the same VLAN 100 tag (private peering) and the same VLAN 200 tag (public peering), MCR manages the Q-in-Q tunnel for each Azure VXC that terminates on the MCR. Each Azure VLAN is still a separate logical interface.
Choosing a Q-in-Q method
This flowchart shows a decision path to assist in selecting the best Q-in-Q method for your environment. It lists options 1 through 5 in order of preference. The Microsoft Azure ExpressRoute SLA requires a redundant Layer 3 connectivity configuration. Options 1 through 4 provide this redundancy, and option 5 can provide it if you use two Ports.