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

Great, thank you very much

1 Like

Hello,

TRUNK Q-in-Q is only between isp and customer ? for example can I double tag only my LAN side for more safety ?

It is good to tag VLAN NATIVE yes or no , why ?

If iI donā€™t allow vlan native between to two devices, it is possible that cdp, dtpā€¦ can communicate/negociate ?

In Advance thank you very much

Hello Moiuy

Typically this is done between the ISP and the customer, so that one ISP VLAN can carry multiple customer VLANs. The point here is to be able to convey multiple VLANs (trunks) from one customer site to another without the ISP needing to participate in trunking. It can recieve the tagged frames, add a second tag to it, so that all internal VLANs of the customer will be tagged with a single ISP tag to differentiate it from other customers on the ISP network.

You can configure QinQ on your own network internally, but thereā€™s no reason to do so. Double tagging your traffic on your LAN will not increase safety. It is not a security feature. More info about it can be found in the 802.1Q tunneling lesson.

Tagging the native VLAN will add a level of security by not allowing any untagged frames to be transmitted to a trunk port. In general if your network is otherwise secure, itā€™s not really necessary, however, it never hurts to add it in. You can see how it can be done at the end of the following lesson:

Take a look at this post: 802.1Q Native VLAN on Cisco IOS Switch - #131 by lagapidis

I hope this has been helpful!

Laz

Ok thanks,
For the last question.
So management protocoles stp,pagp,vtp and CDP use vlan 1, if I allow or not on trunk it will be work.
DTP uses native vlan with no tag.
It that correct ?

Thanks.

Hello Moiuy

Yes, that is correct. VLAN1 is always used for these. The switch will accept these control frames, even if VLAN1 is not allowed on a trunk. Only DTP uses untagged frames, taking advantage of the native VLAN.

I hope this has been helpful!

Laz

1 Like

Hi,

In the service provide network. Lets sat we have 3 switches and my question is on the switch in between, How the switch in between transfer the traffic and why we need to configure the vlans on it. Kindly have a look at the attached graph.

I am looking to get an answer soon and appreciated.

Hi, You need to configure VLANS on SW3 to allow customersā€™ vlans to pass through it.

If you have a single VLAN for each customer, you can configure SW3 to separate each flow by Tagging packets.

Hi,
would you pleas let me know what does the switch do when the traffic reaches port Fa0/19 with double tags. and how it forwards through the trunk.

Your response is highly appreciated.

Hi,

All switches not care about what are delivered on access ports, in the Reneā€™s Lesson you can see that the transported VLAN on all switches is the 123, it works because ports on SW1 and SW2 are in access mode, and switchport mode dot1q-tunnel provide to encapsulate the Vlan provided by R1 into vlan 123.
Also the command switchport mode trunk on Fa0/19 permit the traffic of all vlans because they are not filtered by the statement witchport trunk allowed vlan

1 Like

Hello Zana

@Giovanni is correct. In the Q-in-Q lesson, Rene has set up the switches to use VLAN 123 as the tunneling VLAN, or the service provider VLAN. This is the ā€œoutsideā€ VLAN tag in which all of the customer VLANs or the ā€œinsideā€ VLAN tags will be carried.

Q-in-Q is actually only really configured on SW1 and SW3. SW2 only knows that it must transmit frames on VLAN 123. The inner customer VLAN tags are never ā€œseenā€ by SW3. It doesnā€™t know that there are double tags. The only indication it has that something may be there is the fact that the Ethernet header is 4 bytes larger. So you may need to adjust the MTU settings of the interfaces, as mentioned in the lesson.

It may be a bit misleading that in the diagram we have R1 and R2 because theyā€™re routers. But in the lesson, Rene configures those interfaces as subinterfaces, so that frames reaching SW1 will indeed have customer (inner) tags on them.

I hope this has been helpful!

Laz

1 Like

thank you really appreciated. @Giovanni and @lagapidis

1 Like

hello Sir,

One question If router support max 1500mtu than is it possible to use Q in Q.
I am trying same configuration but unable to ping .

Hello Osama

If your switch only supports a maximum MTU of 1500 then it is likely that the switch has not been designed to function using Q-in-Q. However, you can still make it work. Instead of trying to make the MTU of the switches larger, make the MTU of the routers smaller. Specifically, make them 1496, so that the addition of the extra tag will make the maximum MTU 1496+4=1500.

This is not a recommended setup, as this can result in excessive fragmentation, and it does require a configuration change to the customer premises equipment. It can be done, but it shouldnā€™t be done in a production environment.

I hope this has been helpful!

Laz

Hi
Q1/ Fragmentation will be in Out or in or both direction for each packet?

Q2/if my mtu is 1500 and mss is also default which is 1460,if i used technologies and more headers added, will these headers reduce my mss? If yes, then should work but with low performance as I understand, why sometimes we need to change the mtu otherwise it wonā€™t work?? For example if we used qinq, can i keep the mtu 1500 and consider my mss be 1556?

Q3/can i say
L2MTU = L3MTU - Ethernet header (14 bytes )
??
If yea
Then Default L2MTU = 1500
Default L3MTU = 1514

Q4/
Default L3MTU = 1460 mss + 20 IP+20 TCP+14 Ethernet+ 4 FCS + 4 If there ia Tagging
= 1518
Is it right?
So why we say 1514?, it should be 1518

Also if we are using QinQ will be 1522
Right?

Hello Ali

IP fragmentation will occur when you encapsulate an IP packet into a frame that has a smaller payload size than the IP packet itself. This takes place at L3 devices like routers. That involves the IP MTU.

With QinQ tunneling, the MTU involved is the interface MTU, which is a Layer 2 concept. In this case, you wouldnā€™t have fragmentation, you would just see the frame be dropped. More info about this can be found in the following lesson:

Actually no. The MSS refers to the maximum payload size of the TCP segment. If you add more headers, youā€™re not changing the MSS, but you are changing the size of the packet and the frame.
That means that on the devices that are transmitting such packets/frames, you may need to change the Interface MTU or the IP MTU. Again, take a look at the lesson above on MTU for clarification on these topics.

Hmm, not quite. MTU does not refer to the number of bytes a particular packet or frame has, but it refers to the maximum size of frame or packet that a particular interface will accommodate, either on L2 (interface MTU) or L3 (IP MTU). Also, keep in mind that when you configure the interface MTU, whether or not the Ethernet header is included depends upon the Cisco IOS version you are using. IOS does not include the ethernet header while IOS XR does. Finally, remember the order of encapsulation. IP packets are encapsulated within Ethernet frames. So an IP packet may be 1500 bytes in length (L3), but the Ethernet frame that encapsulates it will be 1514 bytes in length.

Once again, it has to do with how we measure the MTU and how we describe the sizes of frames. In general, we can safely ignore the FCS as all systems take that into account, and yet donā€™t include it in the size of the frames. Again, for the interface MTU, we donā€™t include the header or the FCS. You must take the values in context whenever they are given. It can indeed get confusing at timesā€¦

I hope this has been helpful!

Laz

Hi Rane,
How the interface F0/1 on both SW1 and SW2 is sending CDP traffic while both F0/1 interfaces configured with no cdp enable ?

Hello Hazim

The CDP traffic that you are seeing is traffic between R1 and R2. These CDP messages are actually being tunneled through SW1 and SW2 in such a way so that R1 and R2 actually believe that they are directly connected. SW1 and SW2 donā€™t actually participate in the CDP exchange since, as you correctly stated, CDP is enabled. But in the lesson, the Fe0/1 interface of SW1 and the Fe0/2 interface of SW2 have been configured to tunnel CDP traffic using the following command:

SW1(config-if)#l2protocol-tunnel cdp

This makes the switches completely transparent, and the routers believe they are directly connected.

I hope this has been helpful!

Laz

Hi,
I was wondering how and what type of security could you use with Q in Q tunnels ?
For example our service provider currently supplies us with QinQ tunnels to link up services around different sites around the country and it all works really great but recently Iā€™ve been thinking about the security side of this.
I may be entirely wrong but from my understanding all this traffic will be unencrypted and basically the Dot1Q L2VPN is open to attacks.
Any ideas what would be good ways to improve security with a QinQ setup.
For example would it make sense to put a layer 2 firewall (transparent firewall) or firewall in bridging mode at each of our sites right before the handoff (demarc) point to the service provides layer2 switches at our sites ?
This could filter the traffic ? right ?
Also is there anyway we could encrypt this traffic going across this QinQ tunnel ?
Iā€™m just looking at ways to beef up our security on these QinQ tunnels.

Hello Sean

Thatā€™s an excellent question. To start with, you can encrypt your data at the upper layers using IPSec and associated encryption algorithms. That will keep the data you send over the service provider network safe.

To enable security mechanisms at Layer 2, you can use MACsec to authenticate and encrypt packets between two MACsec-capable switches. MACsec is the IEEE 802.1AE standard, and Cisco switches, in general, support it. Compared with upper-layer encryption such as IPSec, MACsec can protect ARP messages and all DHCP traffic. More info about MACsec and how to configure it can be found here.

Now does MACsec work over a QinQ link? According to Cisco, and to some other usersā€™ experience, it can be successfully implemented:

Now in cases where MACsec is not supported, you could use L2VPN as well as stated in this Cisco documentation, or L2TPv3 with IPSec for security.

There are many combinations that you can implement, but ultimately it really has to do with what threat you are trying to mitigate against. Layer 2 threats on the provider are unlikely to be a problem, as any self-respecting ISP will ensure security on their network, and you can ask them about sharing that information with you. I suggest you decide what threats you perceive to your data, and adjust the security policy/methodology accordingly.

I hope this has been helpful!

Laz

1 Like

Can a q-in-q tunnel be routed ? or is it only possible through a layer 2 network?