Solved: Re: Ugggh PVST native vlans running wild

tekjansen101 · ‎04-24-2010

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.

Giuseppe Larosa · ‎04-24-2010

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

View solution in original post

Jon Marshall · ‎04-24-2010

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

Giuseppe Larosa · ‎04-24-2010

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

Jon Marshall · ‎04-24-2010

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

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

Giuseppe Larosa · ‎04-24-2010

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

Jon Marshall · ‎04-24-2010

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

tekjansen101 · ‎04-24-2010

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

Jon Marshall · ‎04-25-2010

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

tekjansen101 · ‎04-25-2010

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

wchengcisco · ‎04-25-2010

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.

Jon Marshall · ‎04-25-2010

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