Q-in-Q Tunneling Question

[JohnNetEng]

Apologies for this being a rather lengthy setup preceding the question at the bottom. It pertains to the above topology.

Router R1 has three 802.1q sub-interfaces on Gig0/0 with the following addresses:

G0/0.10 - 192.168.10.1/24

G0/0.90 - 192.168.90.1/24

G0/0.200 - 192.168.200.1/24

These IP's are the default gateways to PC1 (192.168.10.2/24), PC2 (192.168.90.2/24) and PC3 (192.168.200.2/24) respectively on the right side of the topology.

SW1's Gig0/0 interface is configured with an 802.1q tunnel as follows

interface GigabitEthernet0/0
   switchport access vlan 66
   switchport mode dot1q-tunnel
   negotiation auto

SW3 is merely doing trunking between SW1 and SW2, and has VLAN 66 added on it as well.

SW2's Gig0/0 interface is configured with an 802.1q tunnel as follows:

interface GigabitEthernet0/0
   switchport access vlan 66
   switchport mode dot1q-tunnel
   negotiation auto

SW4 has the following config

vlan 10,90,200
!
interface GigabitEthernet0/0
switchport trunk encapsulation dot1q
switchport mode trunk
negotiation auto
!
interface GigabitEthernet0/1
switchport access vlan 10
negotiation auto
spanning-tree portfast edge
!
interface GigabitEthernet0/2
switchport access vlan 90
negotiation auto
spanning-tree portfast edge
!
interface GigabitEthernet0/3
switchport access vlan 200
negotiation auto
spanning-tree portfast edge

To get the topology working to the point where all three PCs were able to ping their default gateway, as well as each other, I had to add the following line of config to both SW2 and SW4

 vlan dot1q tag native

In practice, assuming SW1, SW2 and SW3 are a providers switches, and R1 is the client's router (and SW4 is this same client's switch), do we want clients to add the `vlan dot1q tag native` line in their configs, if they want VLAN's extended via a trunk across a provider's network? I'm just trying to determine what is the best practice to follow.

John 

[Giuseppe Larosa]

Hello John,

the command

vlan dot1q tag native

is used in real world implementations of QinQ to avoid to expose the inner vlan tags = customer vlan tags on a trunk link with a native vlan = to the tunnel port S Vlan.

In your case you have used Vlan 66 and this is not the default native Vlan on trunks (that is Vla n1)  so your setup should have worked also without the command.

If you are using an emulation environment what you see might be a limitation of that software.

The objective of the command is to have double vlan tag on all "provider" switches inter trunk links so that there is no risk of errors in frames treatment.

Hope to help

Giuseppe

[JohnNetEng]

Thanks, that's correct, I'm using IOSvL2 in GNS3. Are you asserting that in a real world scenario, if SW2 and SW4 were both say 3850's or 4500's, I would only need `vlan dot1q tag native` on the SW2 with the `switchport mode dot1q-tunnel` command on its Gig0/0 interface and not on the SW4 switch that has the client trunk on its G0/0 interface?

[Giuseppe Larosa · Accepted solution]

Hello @JohnNetEng ,

with real devices the command for tagging the native Vlan would not be needed at all in any device.

Hope to help

Giuseppe

[JohnNetEng]

Thank you!