From: Scott Vermillion (scott_ccie_list@it-ag.com)
Date: Wed Nov 21 2007 - 02:00:48 ART
Hey Scott,
We had a brief thread about this a few weeks back or so. I really struggled
with the DocCD example of the whole tagged/untagged thing where q-in-q is
concerned (and apparently I wasn't alone). If I finally figured this out
once and for all, then it seems that tagging your native VLAN on the
enterprise switches poses something of a minor risk, while it solves nothing
(I'm prepared to be told that I'm wrong, just laying out my understanding of
it all). The main threat is for the carrier to assign you a "customer VLAN"
that also happens to be the native VLAN of their internal core-facing trunk
bearing your traffic. If that's the case, then the metro tag will not be
applied to your traffic by the carrier. At the other end of the core or
possibly within the core, the carrier switch(es) simply look at the top
(only in this case) tag and send traffic accordingly. So if they assign
VLAN 100 to the port facing you, then also make that the native VLAN on the
trunk facing the core that bears your traffic, you don't get a metro tag but
the various enterprise tags you assign remain. Thus, your traffic fans out
to multiple clients. If you tag your own native VLAN, then that traffic too
gets misrouted to whatever client has been assigned that "customer VLAN."
If you don't tag native, then at least that traffic in theory possibly makes
it to the other end of your tunnel service (depending on what the core looks
like and whether or not a consistent native VLAN is used throughout the
core). Receiving only native traffic across the tunnel would seem a better
troubleshooting indication than receiving no traffic at all.
To avoid any of this from ever coming to pass, the *carrier* should either
tag native or use ISL. Then there is never any risk of not tagging a
client's inbound traffic and fanning it out to the world.
Do I still have this whole q-in-q native VLAN thing hosed or does that sound
about right to you?
Regards,
Scott
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Scott Morris
Sent: Tuesday, November 20, 2007 12:55 PM
To: 'Julio Carrasco'; ccielab@groupstudy.com
Subject: RE: vlan dot1q tag native
It is recommended that you DO tag the native VLAN. Otherwise, untagged
packets may become "confused" with the access vlan that your SP is using and
things may not work the way you want them to.
So while you may find in your lab you have some basic connectivity the way
you expect, as you start doing more and more things (or your SP connects
more and more devices) the behavior may change.
I believe this is listed as part of Cisco's recommendations or requirements.
HTH,
Scott Morris, CCIE4 (R&S/ISP-Dial/Security/Service Provider) #4713, JNCIE-M
#153, JNCIS-ER, CISSP, et al.
CCSI/JNCI-M/JNCI-ER
VP - Technical Training - IPexpert, Inc.
IPexpert Sr. Technical Instructor
A Cisco Learning Partner - We Accept Learning Credits!
Telephone: +1.810.326.1444
Fax: +1.810.454.0130
http://www.ipexpert.com
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Julio Carrasco
Sent: Tuesday, November 20, 2007 1:49 PM
To: ccielab@groupstudy.com
Subject: vlan dot1q tag native
Hi there,
I am redoing the internetwork expert labs for R/S (IEWB VOL2 ver 4.1), and I
have seen that in task 1.5 of lab 8 the have configured dot1q tunneling, for
connectivity between R2 and R6 (tunneling for vlan 26), and they have added
the command "vlan dot1q tag native" to the solution, but I have configured
the tunneling ewithout it, and seems to work well (I have connectivity
between R2 and R6).
Do you know if it4s necessary to configure the tag for the native vlan to
configure this ? and why it is ?
Thanks in advance,
Julio.
This archive was generated by hypermail 2.1.4 : Sat Dec 01 2007 - 06:37:30 ART