[c-nsp] VTP and Vlan 1

Tue Aug 26 08:33:07 EDT 2008

Hi Michel,

Appologies for confusing the issue. You are of course correct about VTP,
which does use vlan 1.

UDLD is not sent with a dot1q tag, but is associated with vlan 1 on ISL
trunks.  Changing the (dot1q) native vlan on the trunk has no effect on
how UDLD is sent over ISL, it is still sent on vlan 1.

Paul.

Michel Grossenbacher wrote:
> 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.
>>
> 

-- 
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.