Skip to main content
This topic describes ways to connect your on-premises network equipment to a Cloud Service Provider (CSP) that uses , 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 overview

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.
To differentiate the VLAN tags under the 802.1ad standard, the inner commonly uses EtherType 0x8100 and the outer uses 0x88a8. The default configuration for most network vendors’ Q-in-Q is for both inner and outer EtherTypes to be 0x8100. The Megaport specification of double-tagged frames is for both inner and outer tags to be 0x8100.
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. For more information about Q-in-Q, see Connecting a VXC and the Megaport blog post Q & A for Q-in-Q: Part 1. For more information about configuring Q-in-Q for Azure, see the Megaport blog post Q & A for Q-in-Q: Part 2.

​
Understanding Q-in-Q with Megaport VXCs

A Virtual Cross Connect (VXC) 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 image 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. 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. 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.

​
Single Azure peering VLAN

For Microsoft Azure ExpressRoute connections, Megaport uses a Microsoft Service Key (and associated primary and secondary target endpoint selection) and provides the ability to break out the encapsulated C-Tag for a specified Azure peering type. You enable this functionality by enabling 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.
We recommend using the Single Azure Peering VLAN option. This option provides full functionality and the simplest implementation. With Single Azure VLAN, you can use both private or Microsoft peering with a single ER circuit without the need for Q-in-Q capable equipment, an MCR, or an untagged port. Note, you can have only one peering type (private or Microsoft) per VXC with this option so you need two VXCs to use both peering types.
By enabling the Single Azure VLAN Peering VLAN functionality, you can specify a single Azure peering VLAN that will match with the value that you configure (in a future step) for the selected Peering type configuration for the Azure ExpressRoute configuration (via Microsoft Azure portal or other configuration method). For more information, 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 mapped transparently 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 recommend 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 more information about Azure ExpressRoute SLA, see SLA for Azure ExpressRoute. With this method, 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 in the following sections, 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 might specify or require Q-in-Q 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

Using this method means that the customer Port 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 Port. 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 tags as defined on the Azure portal under the specified peering type at the A-End customer port. For more information, 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 will require two ports from Megaport in this configuration. The Azure VNET VLAN tags 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 multicloud, 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 image 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.
Last modified on August 21, 2026