802.1Q Tunneling (Q-in-Q) Configuration Example

Hi Laz,
You are very welcome. Thank you too!

1 Like

You are right Adrian, thanks for notifying us. I just fixed it.

1 Like

Hi Lagapides

Are customers with multiple tags transported or just all customers use only one VLAN?

Hi Samit,

Typically, the SP will use a different VLAN ID for each customer. When you have two customers, you could use VLAN 10 for customer A and VLAN 20 for customer B.


A post was merged into an existing topic: EtherChannel over 802.1Q Tunneling

What happen if we have two customers, customer X and Y and use the same SVLAN (outer vlan) 123 and we segregate traffic using different cvlans (cvlan 12 for customer x and cvlan 13 for customer y). So, we have customer x site 1 and site 2, both sites using lan switches connected to the metro ethernet service provider lan switch and the same for customer y.
If customer X Lan Switch sends a BPDU towards the ISP, this BPDU will be carried on the inner vlan ? or should I have to configure the “l2protocol stp” on the interface configuration mode on the ISP edge interface between customer and the ISP ?

Hello Juan,

It’s no problem when two customers use the same VLANs since everything is separated by the provider VLANs (inner VLAN) which is different for each customer.

The protocols that you need to use the l2-protocol command for are also encapsulated with the provider VLAN. If you want BPDUs to be encapsulated, you’ll have to configure that otherwise they are not transported…

I just added two captures that might be helpful:

802.1Q tunneling - ICMP: https://www.cloudshark.org/captures/18478cfbdbc0

802.1Q tunneling - CDP: https://www.cloudshark.org/captures/7935f25a4fb4


Hi Rene,

I don’t fully understand the MTU problem in Q-in-Q tunneling. How is it that you were able to ping (earlier in the article, before the MTU problem was explained)??

Based on my understanding from reading the article, because the service provider’s switch has to add an addition tag the MTU will increase to 1504 bytes. Since most switches by default only allow an MTU of 1500, this will cause problems.

So How was it that you were able to ping without adding the “system mtu 1504” command earlier in the article?


Hello Vern

The MTU problem will only occur when the frames that are being sent are of a size of 1501 bytes or greater. The pings sent in the original test are of a size of 100 bytes by default, so the MTU issue doesn’t come into play.

I hope this has been helpful!


Hi Lagapides,

Your response was definitely helpful.


1 Like

Hi Rene

I think i could not ask my question clearly, i am talking about double tag, suppose there ar two customers A (vlan 10) and B (vlan 10), and also we have a metro ethernet switch, will both A and B will be tagged by he same VLAN in CX network ? like vlan 30 , are CX vlans visible in ISP networks ?

1 Like

thank you so much Rene, i studied the topic again and understood, here the cx means all the buddies in an company.

1 Like

Hello Samit

Great to hear that you cleared up the issue. Let me respond just for completeness within the forum.

From the ISP’s perspective, each customer is given a separate VLAN with a unique VLAN ID. So all sites belonging to customer A are assigned to VLAN 80 for example, and all sites belonging to customer B are assigned to VLAN 90. The customers don’t see these IDs, they are just given what looks to them like a pipe through which all of their internal VLANs can be passed.

Within VLAN 80, customer A will pass all of its internal VLANs. These VLANs can be the full range of IDs and do not conflict with those IDs on the ISP’s network. The same goes for customer B with VLAN 90. So there will be no conflicting of VLAN IDs as they must only be unique within each company.

I hope this has been helpful!


in video, you have added mtu 4 bytes on all switches but 2 vlans adding (4+4=8 B), then how switch can forward the frame of 1508B.

Hello Sourabh

The system MTU is the MTU that is used for all access ports. Whenever a port is set to function as a trunk, it automatically allows the extra 4 bytes of data for the tag.

So, the increase of 4 bytes is there to accommodate the incoming frame from the router to the switch. Specifically, the frame coming from R1 and entering the Fa0/1 interface of SW1 will have a size of 1504, and this is where the system MTU must match. Once this frame is sent from SW1 to SW3 it is sent over a trunk link which takes into account the additional 4 bytes of the second tag.

I hope this has been helpful!


This lesson - 802.1Q Tunneling (Q-in-Q) - is this 802.1ad ?

Hello Jason

Yes you are correct, this is indeed 802.1ad. It is actually an amendment to IEEE 802.1Q-1998 and is commonly referred to as Q-in-Q because it allows one to place an 802.1Q VLAN “inside” of another 802.1Q VLAN.

I hope this has been helpful!


Hi Rene, this is little confused

I understand that system MTU 1500 means Ethernet frame’s payload, so Q-in-Q happens in L2 Ethernet frames, it doesn’t have to affect the system System MTU. I share an image.


Hello Carlo

When the system MTU is set to 1500, this means that it takes into account the additional 14 bytes for the Ethernet Header. So really, a system MTU of 1500 allows frames up to 1514 bytes in size including the header. If you add the second tag of four bytes, then the full size of the frame being sent is 1518, but again, a system MTU of 1500 allows frames up to 1514 bytes including the header, so any such frames are dropped. By making the system MTU 1504, then you are allowing frames of up to 1504+14=1518 bytes including the header which is sufficient for QinQ frames to pass.

So when we say “the header is not included” in the MTU size, what we mean is that a header of 14 bytes is assumed and added to the 1500. Anything larger would still be dropped, even if the increase in size comes just from a tag in the header itself.

I hope this has been helpful!


1 Like

Hi everyone!

Could anyone give an example of N:1 QinQ configuration (when several C vlans are mapped to one S vlan).
Thanks in advance.