Q-in-Q w/o Native VLAN tag question

[jordan.bean]

Let's assume that we have Q-in-Q setup between 2 service provider switches.  To run Q-in-Q we want to terminate a trunk into each tunnel port and enable native VLAN tagging to ensure that all customer VLAN's are tagged.  In some cases we may have a customer that wants to connect their own equipment into the tunnel port on our switch, so it wouldn't actually be a trunk - it would be an access port.  If this occurs then there is no inner VLAN tag, only an outer VLAN tag.  Will tunnelling still function properly in this scenario?

[Kishore Chennupati]

AFAIK, when you configure the q-in-q, the dot1q tunnel port is expecting a tagged frame ,so when it sees no tagged frame then it drops it. Hence the other port should always be a trunk port. The whole idea of q-in-q is to have more than 4096 vlans across the SP metro ethernet and to provide uniqueness to the customer vlans.

HTH

Kishore

[rsimoni]

actually this is not true... sorry Kishore 

Tunneling still works and traffic within the SP core will be singled tagged (with the SP tag only).

However when you do this you need to be extremely careful specially if you use dot1q trunks in the core with native vlan within the customer range. You might end up in unexpected result in this case.

See an exmple of a possible issue you might see in this case:

http://www.cisco.com/en/US/docs/switches/lan/catalyst3750/software/release/12.2_58_se/configuration/guide/swtunnel.html#wp1008635

The solution would be to tag native vlan in the SP core or use ISL trunks or use native vlans outside customer range or (logically) use trunk ports on CE device (still paying attention to native vlan though).

Riccardo

[jordan.bean]

Actually, our SP is providing the Q-in-Q service for us.  When we did our original provisioning we connected an access layer port to their tunnel port and used a trunk on the other side.  So, the SP is receiving non-tagged frames from us and adding the SP VLAN ID.  When we see the packet come into our trunk it has only the SP VLAN ID.  We're able to terminate it on an SVI just fine. 

We're wondering what happens if we then trunk into a tunnel port at a second location and then the SP adds their SP VLAN ID (a different outer tag than the one above).  I've read online that an SVI on a Cat 3560 can't terminate that double tagged packet.  I'm wondering if instead we can setup a tunnel port on our switch to pop off the outer tag, which would just leave us with a regular trunk, then terminate that as usual (i.e. into a second 3560 with an SVI).

[Kishore Chennupati]

Thanks Ricardo for the clarification

[Mark Pace Balzan]

Hi Riccardo,

I came across this post and I'm having the same issue and not fully understanding the mechanics of the issue.

When you say we use native vlan in the dot1q trunk in the core which should be outside the customer range, does customer range refer to the outer svlan so the access port vlan I'd of the customer facing tunnel port on the SP switch or does customer range refer to the vlans used by the customer, so the inner cvlan ?

Does the customer traffic not get tagged with the svlan if the sp switch core trunk native vlan matches the svlan, or if the sp switch core trunk native vlan matches the customer to sp trunk native vlan ?

As I understand it the sp switch core trunk native vlan should never be used as an outer svlan on a tunnel port. Not sure however if the cvlan and native vlan of the customer to sp trunk affects ?

Thanks

Mark