dot1q tunneling questions

[christian.pinedo]

Hello,

I posted this message to LAN forum and I didn't get a response. I supposed that the question is more related to WAN forum so I resend it.

I'm new to dot1q-tunneling and I must select hardware to it. I have two very basic questions:

-  Cisco Catalyst 2960 supports "switchport mode dot1q-tunnel" ? I think  that 3750 yes... but I'm not sure. The support of "dot1q-tunnel" is  related to IOS version or to the platform??

- If a switch doesn't  support dot1q-tunnel, will it be able to forward Q-in-Q traffic? I think  so, I think that dot1q-tunnel support is needed for the access layer but not for the transport layer. A transport switch without Q-in-Q support would have provideer-VLANs configured and it won't realize that  it's forwarding Q-in-Q traffic.. obviously it couldn't have ports for ingress or egress traffic, it would be only valid for transport. Am I right??

Thanks,

Christian

[John Blakley]

My understanding is that dot1q tunneling will only need to be configured on your 2 endpoint devices (edge switches) that you'll be connecting. For example:

host -> CER -> ISP switch (dot1q tunnel) -> P Sw -> P Sw -> P Sw -> ISP Switch (dot1q tunnel) -> CER -> host

So, the 2 switches on the edge will need to be configured. They attach to a vlan that's internal to the ISP, so the other switches only need to know about that vlan (almost like MPLS and the PEs needing to know about VRF but the P routers don't).

As far as equipment, I'm not sure I doubt it's hardware based but it could be. I'd search on IOS versions to see what's supported, but I would imaging that it deals more with the IOS than hardware.

John

[Kishore Chennupati]

Hi christian,

I would recommend you to look up the cisco feature navigator if you want to know what platform and IOS supports dot1 tunneling.

http://tools.cisco.com/ITDIT/CFN/jsp/index.jsp

Now in terms of the dot1q tunneling technology.

As john  suggested the dot1q tunneling is done at the edge switches. There is a little difference between Q-in-Q and dot1 tunneling in terms of implementation. I worked for an ISP and have setup and worked on it for a while hence I will give you the practical scenario.

1. Q in Q (aka double tagging): This is where the customer vlans are encapsulated within ISP vlans and shipped across. The service provider will not be able to see customer mac address at all. The ISP vlans are trunked approprately  so that the vlans dont go all over the place and then they reach the destination edge switch they get stripped off and the customer vlans are sent out

Very hard to troubleshoot from an ISP point of view

2. dot1q tunneling:  This is where the customer vlans are again sort of encapsulated but in reality they get translated

so if the customer vlan is 400 it will be translated to say 600 within the ISP and shipped across where it will be translated back to whatever the customer vlan is and shipped out. There are some terms called inner vlan , translated vlan when you talk about dot1 tunneling .

In this case the ISP will be able to see the customer mac addreses in the vlan and in fact I used to toubleshoot by creating a SVI on the ISP switch to create a point to point link and ping across to see if the issue with the vlan mapping etc.

Hope this gives some idea.

Regards,

Kishore

[christian.pinedo]

Thanks for your answers :-D

Kishore: I thought that dot1q tunneling and Q-in-Q was  the same technology and it was only a name difference. In this  documment [1] that is focused on dot1q tunnel configuration in Cisco  seems to be the same as Q-in-Q: an VLAN (customer VLAN) that is inserted  in other VLAN (provideer VLAN). It doesn't seem to be a translation of  VLAN. For that I think that there is another solution "VLAN mapping" or  VLAN translation or something similar...

[1]

http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SXF/native/configuration/guide/dot1qtnl.html

[Kishore Chennupati]

Hi Christian,

I agree with you.

Thats why I mentioned it that my explanatino was more in terms of how I have seen it getting used. .You are right when you say both of them encapsulate and these terms are used interchangebly. With q-in-q what I have seen is using access ports at the SP end and in dot1q tunneling the ports are tunnel ports.I have seen dot1q tunnel ports being vlan mapped andl also work as q-in-q.

HTH

Note: Thanks for the ratings :-)

Regards,

Kishore

[maayre]

Kishore & Christian and for those interested in the semantics of it,

There are slightly different implementations which achieve the same effect but use a different ethertype and can be incompatible.

I believe the first implementation (Cisco) used regular 802.1Q ethertypes in multiple tags with the value of

0x8100. The disadvantage with this is that the switches can't tell the difference between a stacked tag and a regular tag as they all have the same value (although it is arguably not always a necessary thing to know).

When the IEEE standardised the feature they defined a new ethertype (0x9100). I think there are some other vendors using different ones too. Generally if you are using inter-vendor QinQ you would have a look into what kind of ethertype they will recognise to pop at the edge of the QinQ domain.

Often the ethertype you want to use is also configurable in modern switches.

Switch(config-if)#switchport dot1q ethertype ?

  <600-FFFF>  Ethertype value in hex

So in answer to your question what is the difference between these terms I would say that;

• dot1q-tunnel  - the name of the command for on Cisco devices which defaults to ethertype 0x8100
• QinQ - more generally can be used to mean stacking tags but also the IEEE QinQ standard which uses ethertype 0x9100

Futher I would say that VLAN translation is a feature in it's own right and not really related to QinQ although it can be used in similar architectures to solve some of the same problems.

Regards,

Matt