Separating traffic by VLAN is nothing new. It may be separate departments, to provide boundaries, for security, or for a thousand other reasons.

The Tagged, Untagged, and Native VLANs article introduces how VLAN tags work. As shown below, a frame has a VLAN tag inserted to identify the VLAN it belongs to.

Service Providers need to keep customer traffic separated. There are different ways to achieve this, depending on the provider link type. To achieve this at layer 2, we can use Q-in-Q tagging to insert an extra VLAN tag. This results in VLAN tags being ‘stacked’ in the frame.

The result is a frame with two tags; the customer tag (AKA, the C-TAG) and the service-provider tag (AKA, S-TAG):

This can be called VLAN stacking, Q-in-Q tunnels, or dot1q tunnels. The ‘Q-in-Q’ comes from the 802.1Q VLAN specification.

Q-in-Q also helps providers to save money. When a provider gets a new customer, they have to provide a port into their core or aggregation network. These ports are likely to be 1Gbps, but the provider may be selling only 10Mbps services. The result is a waste of bandwidth. Instead, the provider could have an edge switch connected to the core port. Then, 100 10M customers could connect to the core port, separated by VLANs.

Another use for Q-in-Q is for a provider to pass traffic over an upstream provider’s network. For example, a small provider may have networks on the east and west coasts of a country. An upstream provider can bridge these two networks. Q-in-Q allows the smaller provider to pass layer-2 traffic over the intermediate provider.

Although usually associated with providers, enterprises may have a use for tunnels as well. Some examples include mergers between different companies with overlapping VLANs, or converging separate offices. One use case that’s becoming more popular is when connecting to the public cloud. If you want to connect a data centre to Azure or AWS, you will need a service provider. They provide the physical links, which would usually be deployed at layer-2. The links can be trunked, or they will likely offer you the option of running Q-in-Q.

To test this out, we’ll use the topology below. There’s no special config on the routers. They are just there as a place to ping from. They’re basically simulating hosts.

The Edge switches also use a standard config. The ports facing the routers are access ports. The ports facing the ISP equipment are trunk ports.

The configuration is quite simple. We’re using VLAN 123 as the S-TAG, so we start by defining that. We don’t need to define the customer VLANs on the ISP switches.

The link between the ISP’s is a normal trunk link. This has a slightly larger MTU to account for the extra VLAN tag.

The customer-facing port uses the S-TAG as the access VLAN. The switchport mode is set to dot1q-tunnel. When traffic arrives on this port, an extra VLAN tag is added, even if there is already one there.

But what about traffic that normally uses the native VLAN? CDP and STP for example?

These can be tunnelled across the network with a few simple commands