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??
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.
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.
Kishore: I thought that dot1q tunneling and Q-in-Q was the same technology and it was only a name difference. In this documment  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...
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.
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.
We have 3 identical switches configured by someone else and would like to claim some of the Gigabit ports(G1/G2/G3/G4) for use on servers. When we try to change the wiring and configuration, we run in to connectivity issues. Attached is a des...
This is actually a pretty cool feature, i didn't even know it existed until I was looking for a solution to advertise a subnet (prefix in BGP talk), only if a certain condition existed. This is exactly what conditional advertisements does
j ai une question j ai achete un routeur cisco 887VA-k9 , je le configuré avec la configuration ci- dessous
si je le lier avec mon pc portable sur l un de ses ports directement ça marche toute est bien ( la connexion internet + m...