From: Scott M Vermillion (scott_ccie_list@it-ag.com)
Date: Wed Oct 22 2008 - 13:54:31 ARST
> Never have chance to test it, anyone who lab it can commend on it.
Yes, I did battle with this about a year ago. I was very frustrated with
the Cisco documentation on the subject of Q-in-Q and native VLANs. Here's
some of the text from one of the threads we had on the matter:
-----Original Message-----
From: Scott Vermillion [mailto:scott_ccie_list@it-ag.com]
Sent: Thursday, November 01, 2007 4:12 PM
To: 'Dave Mumford'; 'Simon Grace'; 'ccielab@groupstudy.com'
Subject: RE: vlan dot1q tag native
Hey Dave,
I had some confusion on this a while back (perhaps we both read the same
crappy example on CCO?). Here's the link:
http://www.cisco.com/univercd/cc/td/doc/product/lan/cat3560/12240se/scg/swtu
nnel.htm
Here was my question:
> Under the "Native VLAN" discussion in the above link, it is explained
> that if the customer native VLAN happens to be the same as the tunnel
> port access VLAN, then no metro tags are added to any of that
> customer's traffic. In the example, VLAN 40 is native on the customer
> trunk and that is the access VLAN of the carrier tunnel port. VLAN 30
> traffic comes in and is not tagged. Is this something I'm just
> supposed to accept and not fully understand or is there a common-sense
> logic to this that I'm just plain missing?
And then here's the explanation that Eric Leung offered that cleared it all
up for me:
> Hi Scott,
> The native vlan of the tunneling port at the SP Edge SW should not be
> the same as the native vlan of the trunk between SP Edge switch and other
SP Core Switch. It's nothing related to the native vlan of the customer
switch.
> Thanks,
> Eric.
So this whole thing of tagging the native VLAN is a concern within the
carrier network; it really has nothing to do with the customer/enterprise
side at all or what VLAN they have assigned as native. If the carrier edge
switch tunnel port (the one facing the client) has its access/tunnel VLAN
set to 40 (as in the example of the link given) and that same carrier
switch's trunk into which it is pushing traffic for transit across the
carrier core has its native VLAN also set to 40, then no traffic at all
coming in from the enterprise gets its metro tag (because it views all of
the client's traffic as native and thus there is no need to apply a tag).
This applies to all customer VLANs for that particular q-in-q tunnel.
As an aside, it turns out that enabling the tagging of the native VLAN on
the enterprise side is actually pretty interesting. In the example given,
traffic tagged as VLAN 30 comes in from Customer X. The access/tunnel VLAN
that the carrier has assigned to this particular client is 40 (that's an
internal decision that means nothing to the enterprise). The problem is
that the carrier edge switch trunk port has native VLAN 40. Thus, no
tagging of that customer's traffic at all. The far-end carrier edge switch
knows that the top-most (only in this case) tag identifies to which client
the traffic belongs. It determines that the traffic belongs to Customer Y
(the VLAN 30 client). Traffic gets misrouted. So if you enable tagging of
your native VLAN on the enterprise side, all you've accomplished is that
you've dictated that your native traffic also be misrouted to whatever
Customer has been assigned that tunnel VLAN by the carrier!
So you're probably right, globally enabling the tagging of the native VLAN
is a "best practice" if you're the carrier and you are using dot1q in your
core (Cisco recommends ISL in the core in this case as the true best
practice). However, as Eric pointed out to me, it has nothing to do with
the native VLAN of the client trunk that's being tunneled. It all has to do
with not assigning a client the same tunnel VLAN number as what you're using
on your core-facing trunk that you're pushing their traffic over.
Regards,
Scott
On Wed, Oct 22, 2008 at 5:30 AM, stephen skinner
<stephenski@gmail.com>wrote:
> Hello,
>
> i was wondering if i could ask some opinions
>
> i have seen this command used in various dot1q Tunnel senario`s.
>
> But i am still a little sketchy as to when i should use the above command.
>
> a re-read of the CCO has made me non the wiser.
>
> from the CCO
> "You CAN use this command with the IEEE 802.1Q tunneling feature
> This feature operates on an edge switch of a service-provider network and
> expands VLAN space by using a VLAN-in-VLAN hierarchy and tagging the
tagged
> packets"
>
> Should i use this command eveytime i configure a QinQ tunnel ?.
>
> If not , what sort of statements should i be looking for in question to
> lead
> me towards using this command ?,
>
> any help would be greatly appreciated
>
> TIA
>
> --
> Only two things are infinite, the universe and human stupidity, and I'm
not
> sure about the former.
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
Blogs and organic groups at http://www.ccie.net
This archive was generated by hypermail 2.1.4 : Sat Nov 01 2008 - 15:35:22 ARST