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

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

Rene

1 Like

Hi Rene,

I don’t fully understand the MTU problem in Q-in-Q tunneling. How is it that you were able to ping 192.168.12.2 (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?

-Vern

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!

Laz

Hi Lagapides,

Your response was definitely helpful.

Thanks

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!

Laz

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!

Laz

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

1 Like

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!

Laz

1 Like

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.

20070601_108905_image001_201175_57_0

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!

Laz

2 Likes

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.

Hello Dimitriy

In order to take a look at such an example, the routers in the lesson need to be replaced with switches. This allows the customer equipment to send multiple customer VLANs over a single service provider VLAN. An example of such a configuration follows.

Imagine that R1 is replaced with SW4 in the topology. The configuration of Fa0/1 of SW1 remains the same:

SW1(config)#interface fastEthernet 0/1
SW1(config-if)#switchport access vlan 123
SW1(config-if)#switchport mode dot1q-tunnel

It’s the switchport mode dot1q-tunnel command that makes all the difference here.

Now the Fa0/1 interface of SW4 (connected to SW2) will be configured like so:

SW4(config)#interface fastEthernet 0/1
SW4(config-if)#switchport mode trunk
SW4(config-if)#swichport trunk allowed vlan 10,11,12,15

Notice that there’s no special configuration on SW4’s end, it just configures it as a normal trunk. So the result is that SW4 will send VLANs 10, 11, 12, and 15 each with their respective VLAN tags, and SW1 will receive them and add a second VLAN tag (QinQ tag) with a VLAN ID of 123.

This is the only situation where you can have one end of the link configured as an access port and the other end configured as a trunk port.

I hope this has been helpful!

Laz

Hi Laz,

Thank you for explanation.
One more question:
This command on SW4 “switchport mode tunnel”. Shouldn’t it be “switchport mode trunk” to configure a regular trunk interface?

Thanks again.

Hi Dmitriy

Yes, you’re absolutely correct. Sorry about the typo, I’ve fixed it.

Laz

Hi All,

Based on the lesson and comments in this thread, it seems like Q-in-Q can allow a vlan or vlans to essentially live at two different sites at once.

Can Q-in-Q tunneling be used as a data center interconnection method similar to stretching a vlan across a layer 2 link?

Hello Ramsey

Yes you are correct, you can use QinQ to span one or more VLANs over multiple sites, however, the mechanisms used are much different.

With QinQ, you already have a Layer 2 infrastructure (such as metro ethernet) between the sites that you are connecting that belongs to the ISP. The ISP assigns a single VLAN to be the VLAN that carries all of the traffic for a particular customer, and in that single ISP VLAN, the customer can send its own tagged frames belonging to multiple internal VLANs.

Another way to span a single VLAN across multiple sites is using the L2TP protocol which is what I believe you are referring to in your post. This is different than QinQ because L2TP allows you to span a VLAN over a Layer 3 infrastructure. You can find out more about L2TP in this lesson:

So QinQ spans multiple VLANs across multiple sites over an in inherently layer 2 infrastructure, while L2TP spans a single VLAN across sites over an inherently layer 3 infrastructure.

I hope this has been helpful!

Laz

1 Like