From: Scott M Vermillion (scott_ccie_list@it-ag.com)
Date: Sun Mar 08 2009 - 18:15:10 ARST
>I have a very small but quite significant doubt on the use of Native
Vlan in a Dot1q tunnel.
Hi Ravi,
This is one area where the documentation is very confusing and not
easily digested in a single pass. I have forwarded the below on a
couple of times and people have generally found it useful to clear up
some of the confusion. Hope it helps you too...
(and just FYI, I think we can safely ignore the part I wrote about
using ISL in the carrier core as a "best practice" at this point in
time)
Regards,
Scott
Begin forwarded message:
> From: Dave Mumford <Dave.Mumford@telindus.co.uk>
> Date: November 2, 2007 3:20:01 MDT
> To: "'scott_ccie_list@it-ag.com'" <scott_ccie_list@it-ag.com>, "'SimonG@pcsystems.gr
> '" <SimonG@pcsystems.gr>, "'ccielab@groupstudy.com'" <ccielab@groupstudy.com
> >
> Subject: Re: vlan dot1q tag native
>
> Scott, I don't even need to look at the link, I had to read it half
> a dozen times and yes your right its confusing to say the least.
> Certainly makes more sense with your explanation.
>
> Cheers, Dave.
> Dave Mumford
>
>
> ----- Original Message -----
> From: Scott Vermillion <scott_ccie_list@it-ag.com>
> To: Dave Mumford; 'Simon Grace' <SimonG@pcsystems.gr>; ccielab@groupstudy.com
> <ccielab@groupstudy.com>
> Sent: Thu Nov 01 22:11:56 2007
> 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 clients 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 customers 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
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
> Of Dave
> Mumford
> Sent: Thursday, November 01, 2007 3:01 PM
> To: Simon Grace; ccielab@groupstudy.com
> Subject: RE: vlan dot1q tag native
>
> Anyone know of a reason why you should not enable it globally , if not
> although an optional command I would say yes it is best practice. My
> understanding is that if the customer dot1q trunk native vlan
> matches the
> Service provider tunnel port vlan, then packets exiting a dot1q
> trunk port
> on the same switch as the tunnel port do not have the metro tag
> applied ,
> therefore the "inner " tag is used and would be switched down the
> wrong
> path.
>
>
> Dave.
>
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
> Of
> Simon Grace
> Sent: 01 November 2007 18:49
> To: ccielab@groupstudy.com
> Subject: vlan dot1q tag native
>
> Quick question,
>
>
>
> When configuring dot1q tunnels is it best practice to configure vlan
> dot1q tag native in the global config?
>
>
>
> Cheers,
>
>
>
> Simon
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
> _______________________________________________________________________
> 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 : Mon Apr 06 2009 - 06:44:04 ART