Some cloud service providers (CSPs) require Q-in-Q, but not all network devices support it. This article describes ways to connect your on-premises network equipment to a CSP that uses Q-in-Q, such as Azure ExpressRoute. The workarounds allow you to configure Q-in-Q on unsupported network devices.
Q-in-Q, also known as 802.1ad, is a protocol commonly used by network service providers (NSPs) to provide more Layer 2 flexibility by allowing multiple VLAN tags to be inserted into a single 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 transparently transferred throughout the service provider network.
With Q-in-Q, as a packet travels from an NSP VLAN to a service provider’s VLAN, inner VLAN tags (C-Tags) that identify the customer traffic are inserted inside of the outer VLAN tags (S-Tags) by the service provider. The S-Tag becomes a single VLAN that carries multiple VLANs within it. A single VXC carries the bundled 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.
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 private peering is running on VLAN 100 (C-Tag) and Microsoft Peering is running on VLAN 200 (C-Tag) to establish a Layer 3 connection and BGP peering with Azure.
What if my routers or switches don’t support Q-in-Q?
When the network equipment in your on-premises data center doesn’t support Q-in-Q, but you need to connect to a CSP that requires it, consider these workarounds:
- Workaround: 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.
- Workaround: Untag the outer VLAN for the VXC – You can use a VXC to deliver an untagged VLAN by selecting Untag when configuring the VXC at your end (the A-End VLAN). Untagging removes the VLAN tag for the outer connection. Be aware that using an untagged VLAN in a VXC limits that VXC to one port. Because you can’t deploy any other VXCs on the port, such as a secondary Azure VXC, we don’t recommend this workaround as a long-term solution. This figure shows a configuration using an untagged VXC:
- Workaround: Use a loopback cable – Configure a loopback cable on the edge switch, as shown in this figure: