[c-nsp] VTP and Vlan 1

[Michel Grossenbacher]

Paul, indeed DTP is sent over the native VLAN, but VTP is pretty sure still
over VLAN 1. I did a trace and mixed VTP with DTP, hence I said its using
the native VLAN. But after I did some more traces the VTP packets did not
show any VLAN informations "anymore" (actually they never did I only hit the
wrong line within wireshark ;) ).
So Im quite sure VTP and CDP are not sent via the native VLAN, after I
changed it from VLAN 1 to VLAN 10. Probably have to have a look with ISL
too.

Mike, I think I know what you mean, per definition (AFAIK) all VLANs get
encapsulated by ISL, while with dot1Q all but the native one get a Tag. But
within an ISL trunk Cisco defines a native VLAN (default is VLAN 1, same as
dot1Q) and you can configure it the same way as for a dot1Q one so I'd say
UDLD will use that one. I guess it will still be encapsulated but I did
never check that.
Do a *show interface trunk* if you configured an ISL trunk and you'll see it
at the top.

Michel

2008/8/25 Paul Cosgrove <paul.cosgrove at heanet.ie>

> Hi Michel,
>
> You may have been right the first time there.  I think VTP does indeed
> use the native vlan, not necessarily vlan 1.  DTP is also sent on the
> native vlan, untagged and tagged in its case.
>
> Paul.
>
> Michel Grossenbacher wrote:
> > A little correction on my answer, VTP does not use the Native VLAN :-)
> >
> > Here is what I found regarding the use of VTP and VLAN1:
> > The Case of VLAN 1
> >
> > You cannot apply VTP pruning to VLANs that need to exist everywhere and
> that
> > need to be allowed on all switches in the campus, in order to be able to
> > carry VTP, Cisco Discovery Protocol [CDP] traffic, and other control
> > traffic. However, there is a way to limit the extent of VLAN 1. The
> feature
> > is called VLAN 1 disable on trunk. The feature is available on Catalyst
> > 4500/4000, 5500/5000, and 6500/6000 series switches in CatOS software
> > release 5.4(x) and later. The feature allows you to prune VLAN 1 from a
> > trunk, as you do for any other VLAN. This pruning does not include all
> the
> > control protocol traffic that is still allowed on the trunk (DTP, PAgP,
> CDP,
> > VTP, and others). However, the pruning does block all user traffic on
> that
> > trunk. With this feature, you can keep the VLAN from spanning the entire
> > campus. STP loops are limited in extent, even in VLAN 1. Configure VLAN 1
> to
> > be disabled, as you would configure other VLANs to be cleared from the
> > trunk:
> >
> > UDLD uses native VLAN in order to talk to the neighbor. So, in a trunk
> port,
> > the native VLAN must not be pruned in order for UDLD to work properly.
> >
> http://www.cisco.com/en/US/tech/tk389/tk689/technologies_tech_note09186a0080890613.shtml
> >
> > Sorry for the confusion.
> >
> > best regards
> >
> > Michel
> >
> >
> > On 25/08/2008, Michel Grossenbacher <pashtuk at gmail.com> wrote:
> >> Hi Mike
> >> Actually VLAN 1 is not pruning-eligible so you can not prune VLAN 1 from
> a
> >> trunk. However you can remove it from the trunk.
> >> If you remove it from the trunk and change the native VLAN for the
> trunk,
> >> VTP will then use the new native VLAN for updates.
> >> best regards
> >>
> >> Michel
> >>
> >>
> >>  On 25/08/2008, Mike Louis <MLouis at nwnit.com> wrote:
> >>> List,
> >>>
> >>> I just read in a practice test for an upcoming cert that Vlan 1 is used
> to
> >>> carry VTP advertisements. However, it is possible to prune vlan 1 from
> trunk
> >>> links. Will VTP continue to function without Vlan 1 being enabled on
> the
> >>> link? Has this changed in more recent IOS releases?
> >>>
> >>> Note: This message and any attachments is intended solely for the use
> of
> >>> the individual or entity to which it is addressed and may contain
> >>> information that is non-public, proprietary, legally privileged,
> >>> confidential, and/or exempt from disclosure.  If you are not the
> intended
> >>> recipient, you are hereby notified that any use, dissemination,
> >>> distribution, or copying of this communication is strictly prohibited.
>  If
> >>> you have received this communication in error, please notify the
> original
> >>> sender immediately by telephone or return email and destroy or delete
> this
> >>> message along with any attachments immediately.
> >>>
> >>> _______________________________________________
> >>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> >>> https://puck.nether.net/mailman/listinfo/cisco-nsp
> >>> archive at http://puck.nether.net/pipermail/cisco-nsp/
> >>>
> >>
> > _______________________________________________
> > cisco-nsp mailing list  cisco-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at http://puck.nether.net/pipermail/cisco-nsp/
> >
>
>
> --
> HEAnet Limited
> Ireland's Education & Research Network
> 5 George's Dock, IFSC, Dublin 1, Ireland
> Tel:  +353.1.6609040
> Web:  http://www.heanet.ie
> Company registered in Ireland: 275301
>
> Please consider the environment before printing this e-mail.
>