Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
New Member

Ugggh PVST native vlans running wild

Hello,

We recently migrated from another vendor to Cisco in our core (yay!) The migration seems to have gone on with out a hitch but one things seems to really bother me. We are now running PVST everwhere in the campus building up from MSt in the old setup. Vlan 1 has been disabled and Vlan 999 has been set as the native  VLAN for all uplink and interswitch trunks everywhere.

Which kinda brings me to the  problem. While Cores 1 and 2 are configured to be primary and secondary root switches (in that order) for all vlans (including 999), the command "show spanning-tree root" shows each device in the campus believes it is the root s/w for the spanning tree vlan 999.So for instance if an access switch on some floor has vlans 20,55 passing through the uplink trunks and vlan 999 is set as native, the "show spanning-tree root" command on this access switch will show that it has root ports for vlans 20 and 55 with the relevant cost (4 in this case since we are using 1gigs) but 0 cost  with the message "This switch is root" for vlan 999.  And since every switch believes it is root .... presto no blocking ports anywhere for vlan 999.

I'm not really passing anything untagged in my campus... so nothing seems to have gone awry so far but we all know theres a loop in there somewhere ... lurking ... waiting for the opportune time to strike ... bringing the entire campus down in the process ....

So any ideas anyone ? Suggestions  ? I  can post relevant parts of the configuration if required ...

Thanks a mill.

Everyone's tags (4)
1 ACCEPTED SOLUTION

Accepted Solutions
Hall of Fame Super Silver

Re: Ugggh PVST native vlans running wild

Hello Jon,

>> If you remove vlan 999 from each trunk link then each switch will think  it is root for vlan 999

I have seen this in our campuses

if there will be no port in vlan 999, and we are speaking  of PVST,  STP instance for vlan 999 would be not running.

Vlan 999 will be listed as vlan if we use VTP but no STP running for it.

if an STP instance for vlan 999 exist ( in PVST I mean ) then at least one port is in vlan 999 and that ports are likely the uplink L2 trunks or other trunks defined on the access layer switches.

As soon as we remove from trunk(s)  the vlan 999 the PVST instance is removed.

This is why the trunk allowed vlan has to be used on both sides of each trunk as you have noted many times about STP scalability.

Hope to help

Giuseppe

10 REPLIES
Hall of Fame Super Blue

Re: Ugggh PVST native vlans running wild

Have you cleared the native vlan off all the trunks ? If so then each switch will think it is the root for the native vlan which would explain what you are seeing

Jon

Hall of Fame Super Silver

Re: Ugggh PVST native vlans running wild

Hello TekJansen101,

as noted by Jon compare carefully the list of permitted vlans on core side and access layer switch side of each L2 trunk.

You have probably vlan 999 not permitted on core, but permitted on access layer switch

to fix this in case of IOS LAN switches you can use

switchport trunk allowed vlan remove 999

on each uplink on access layer switch

Hope to help

Giuseppe

Hall of Fame Super Blue

Re: Ugggh PVST native vlans running wild

giuslar wrote:

Hello TekJansen101,

as noted by Jon compare carefully the list of permitted vlans on core side and access layer switch side of each L2 trunk.

You have probably vlan 999 not permitted on core, but permitted on access layer switch

switchport trunk allowed vlan remove 999

on each uplink on access layer switch

Hope to help

Giuseppe

Giuseppe

If you remove vlan 999 from each trunk link then each switch will think it is root for vlan 999 ie. each switch will run it's own STP instance for vlan 999 and this instance will be local to each switch.

I don't actually think this is a problem as by definition if vlan 999 is not allowed on any switch interconnects there cannot be any loops. And if vlan 999 was allowed on the links then each STP instance would merge into one.

Thoughts ?

Jon

Hall of Fame Super Silver

Re: Ugggh PVST native vlans running wild

Hello Jon,

>> If you remove vlan 999 from each trunk link then each switch will think  it is root for vlan 999

I have seen this in our campuses

if there will be no port in vlan 999, and we are speaking  of PVST,  STP instance for vlan 999 would be not running.

Vlan 999 will be listed as vlan if we use VTP but no STP running for it.

if an STP instance for vlan 999 exist ( in PVST I mean ) then at least one port is in vlan 999 and that ports are likely the uplink L2 trunks or other trunks defined on the access layer switches.

As soon as we remove from trunk(s)  the vlan 999 the PVST instance is removed.

This is why the trunk allowed vlan has to be used on both sides of each trunk as you have noted many times about STP scalability.

Hope to help

Giuseppe

Hall of Fame Super Blue

Re: Ugggh PVST native vlans running wild

giuslar wrote:

Hello Jon,

>> If you remove vlan 999 from each trunk link then each switch will think  it is root for vlan 999

I have seen this in our campuses

if there will be no port in vlan 999, and we are speaking  of PVST,  STP instance for vlan 999 would be not running.

Vlan 999 will be listed as vlan if we use VTP but no STP running for it.

if an STP instance for vlan 999 exist ( in PVST I mean ) then at least one port is in vlan 999 and that ports are likely the uplink L2 trunks or other trunks defined on the access layer switches.

As soon as we remove from trunk(s)  the vlan 999 the PVST instance is removed.

This is why the trunk allowed vlan has to be used on both sides of each trunk as you have noted many times about STP scalability.

Hope to help

Giuseppe

Of course. Knew i was missing something but couldn't quite put my finger on it. No active ports no STP.

+5 for that one

Jon

New Member

Re: Ugggh PVST native vlans running wild

Yup you guys seem to have hit the nail on the head ... vlan 999 is not being allowed through the uplinks from the core ... and vlan 999 has mostly no other member ports on any of the access vlans ... so we seem to have either disabled PVST+ or if a member port exists its a manual copy of PVST restricted to that very switch. Allowing it via the uplinks should enable participation in the PVST ...

I had just as well assumed since 999 was native/untagged that it would implicitly exist everywhere Enabling it on the uplink trunk seemed counter intuitive to the idea of what a trunk exists for since the trunk supposedly only carried tagged traffic ... or so I thought ...

Question : Would traffic for vlan 999 still be untagged even though I'm "allowing" it on the trunk since it is my native VLAN? Isn't the native VLAN supposed to be like ....omnipresent everywhere in the campus ... like say VLAN 1 was ...

Points ... Points for everyone !!

Hall of Fame Super Blue

Re: Ugggh PVST native vlans running wild

Question : Would traffic for vlan 999 still be untagged even though I'm "allowing" it on the trunk since it is my native VLAN? Isn't the native VLAN supposed to be like ....omnipresent everywhere in the campus ... like say VLAN 1 was ...

It doesn't have to be everywhere. Because the native vlan by default is vlan 1 it is assumed it should be on all switches and trunks but there is no need for it to be. As Giuseppe pointed out, as i was being a bit slow, if you don't allocate any ports including trunk ports to vlan 999 then no STP instance for vlan 999 should be running on any switch.

So you can either -

1) allow it on all trunks and then you will have one STP instance for vlan 999 across all your switches

or

2) make sure no ports on any switch are a member of vlan 999 including trunk ports

If you did allow it on the trunk any traffic for vlan 999 would be untagged although the only traffic should be STP.

One last point, you may well not have a L3 SVI for vlan 999 but if you do you can safely get rid of it as there is no need to route the native vlan.

Jon

New Member

Re: Ugggh PVST native vlans running wild

thanks guys .. this really helps clears things up ...

New Member

Re: Ugggh PVST native vlans running wild

This is a really informative post... I don't know why I haven't discovered this forum until this week   Anyway, here is a dumb question for ya:  why use 999 as native VLAN instead of 1?  Is it for security reason?  Seems to me that if you had used 1 to begin with, you might not run into this PVST issue at all.

Hall of Fame Super Blue

Re: Ugggh PVST native vlans running wild

wchengcisco wrote:

This is a really informative post... I don't know why I haven't discovered this forum until this week   Anyway, here is a dumb question for ya:  why use 999 as native VLAN instead of 1?  Is it for security reason?  Seems to me that if you had used 1 to begin with, you might not run into this PVST issue at all.

Wilson

Welcome to the forums, a lot of people wonder why they didn't find them sooner

In answer to your question yes it is to do with security. Vlan 1 is the default vlan for a number of things including that all ports are by default in vlan 1. Cisco recommend you don't use vlan 1 for anything ie. user ports/management vlan for the switches/native vlan. So basically :-

1) shut down vlan 1 L3 interface in each switch

2) use a dedicated vlan for managing the switches

3) use a dedicated vlan for the native vlan that does not have a L3 SVI

4) use a dedicated vlan for unused ports on the switch and allocate any unused ports on the switch into that vlan. Again this vlan doesn't need a L3 SVI.

note the vlans for 2,3 & 4 should all be different from each other.

5) clear vlan 1 off the trunk links

Even after doing all this Cisco switches still use vlan 1 for their own management protocols such as CDP/VTP/PagP

If you haven't seen this already have a look at this doc which covers vlan security on the 6500 although the vast majority of it is applicable to all modern Cisco switches -

6500 vlan security

Jon

782
Views
25
Helpful
10
Replies
CreatePlease to create content