Spanning Tree problems when changing the management VLAN

Unanswered Question
Mar 6th, 2009
User Badges:

I've been migrating our management VLAN off of VLAN 1 and have run into some problems with STP. When migrating both switch interfaces (near switch, far switch), I have to time the pastes perfectly for the native vlan command or I run into an issue where I lose permanent connection to the switch on the far side of the connection. I ONLY lose connection to VLAN 1 and the new management VLAN. The other VLANs continue to work fine. The only solution I have found that works is to reboot the near switch which resets "something" and the blocked vlans go back into a forwarding state. My question is, how can I clear the blocked vlans without having to reboot switches? I've tried clearing the mac table, shutting down cdp, resetting cdp, shutting down the interface and turning it back on, nothing seems to work. I have been reading STP troubleshooing for days and the ONLY solution I could find didn't pertain to the switches I am working on, 3500s. These switches do NOT have multiple uplink connections by the way. Any advice would be greatly appreciated.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Francois Tallet Fri, 03/06/2009 - 09:09
User Badges:
  • Gold, 750 points or more

Hi Mike,

I would not be surprised if you had a PVID inconsistency on your trunk when you change the native vlan.

If you have an inconsistency on the native vlan, traffic will hop from one vlan to another. Say that native vlan is X and you are moving it to Y on one side. The traffic that you send untagged (for Y) is received in vlan X on the remote side that has not yet changed the native vlan. This has the potential for opening bridging loops in certain condition. As a result, if a BPDU send for vlan Y is received on vlan X on the remote side (there is a VLAN TLV in Cisco's SSTP BPDUs), STP blocks both vlan X and Y on the trunk.

Now, this is just an assumption of your problem, because what I'm describing should not be affected by a reload (unless there is unsaved configuration that goes away). When you say that the vlans are blocked, can you see (and post here) the spanning tree state for those vlans by any chance?

Thanks and regards,


miketennyson Fri, 03/06/2009 - 09:18
User Badges:

PVID is my problem. I am getting that the VLAN names are not correct. Unfortunately I can't paste because I can't get to the remote switch. It's on the other side of town. If this problem occurs between a remote switch and the VTP root, I get the error messages on the root as well. In this case, it is happening several hops out.

When I say the vlans are blocked, its from doing a show spann brief. It would look similar to this:


Spanning tree enabled protocol IEEE

ROOT ID Priority 1

Address 0009.7bd8.7801

Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

Bridge ID Priority 49152

Address 0007.50e7.15c0

Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

Port Designated

Name Port ID Prio Cost Sts Cost Bridge ID Port ID

------- ------- ---- ---- --- ---- -------------- -------

Gi0/1 128.67 128 3004 BLK* 0 0009.7bd8.7801 128.136

Gi0/2 128.75 128 3004 BLK* 3004 0007.50e7.15c0 128.75

Francois Tallet Fri, 03/06/2009 - 09:36
User Badges:
  • Gold, 750 points or more

Hi Mike,

VTP should be entirely unrelated. You are not changing the vlans. Just the encapsulation that is used on a link. This inconsistency should have local consequences (on the link directly attached to the configuration). Well, let me restate: if you only have cisco switches in your network, this should have local consequences;-)

If you started by changing the remote switch, updating the local config should fix the problem. If you started by changing the local switch, reverting the config should fix the issue.

Now, of course, if there are third party bridges involved, it's more complex as they flood SSTP BPDUs.



miketennyson Fri, 03/06/2009 - 09:42
User Badges:

This is a straight link, Cisco to Cisco. It will say there is a VLAN name mismatch (PVID)etc. I will try to get the exact message. Moving the VLAN back to 1 does not fix my problem. It says that there is a native vlan mismatch. The configs on both ends are showing the new native vlan. I just cant get them out of the blocked state. Rebooting the near switch brings the connection up on the new native vlan. There has to be some way to clear or write something to do the same thing that the reboot is doing right?

xcz504d1114 Fri, 03/06/2009 - 11:09
User Badges:
  • Bronze, 100 points or more

Francois is right about the VLAN's. I'm making the assumption you are changing both your Native VLAN and your Management VLAN? Depending on the 3500 you have, you might only be able to have 1 active IP address on any given VLAN, so you have to shut down your current management VLAN, then bring up the new one, obviously this creates a conundrum when trying to do this remotely.

Try this as a work around:

1) Create a text file named "mgmt.txt" with the following configuration

Config t

int vlan 1


int vlan 10

ip address

no shut

2) TFTP the text file to your remote switch

3) run the command "copy mgmt.txt run"

So step one creates a config file named "mgmt.txt", step two places teh file on your remote switch, and step 3 executes the configuration locally on the switch so you don't get half a configuration on there and get disconnected. You can change your native VLAN etc. on your trunk ports in the txt file as well.

Then do the same thing to your local switch, setup a continuous ping to both devices, and they should come up just fine.



miketennyson Fri, 03/06/2009 - 11:28
User Badges:

That is a great idea. I can do this moving forward. What I really need to know though is how do you unblock a vlan on an interface once it goes into the blocked state without rebooting the next switch?

I've tried all kinds of scenarios. Rebooting the far switch does nothing. Changing the VLANs to and from 1 and the new management VLAN does nothing. The ONLY thing that seems to work is rebooting the near switch. My problem will be resolved at 3:30 when all the people leave for the day. I just know there has to be something I can do without having to take the switch down to get the VLANs to sync. The message states that the VLAN names are different.

xcz504d1114 Fri, 03/06/2009 - 11:33
User Badges:
  • Bronze, 100 points or more

You have VLAN inconsistencies somewhere in your topology, the port will transition out of a blocking state automatically once consistency has been restored.

Are any of your VLAN's not participating in spanning-tree? On a 3500, you would see "no spanning-tree vlan X" in the output of your running configuration.

Are you running ISL or dot1q?

glen.grant Fri, 03/06/2009 - 11:38
User Badges:
  • Purple, 4500 points or more

The easiest way might be to take your existing config , modify it in a text file then download it to startup config . Then when you are ready either copy start run or reload the 3500 . Then you just have to modify the distribution side of the link to match . They will take a slight outage when you do this so maybe after they have gone home for the day.

miketennyson Fri, 03/06/2009 - 11:50
User Badges:

I dont have physical access to the remote switch. to copy configs, I'd need to do this before the problem starts.

I am using dot1q. Doing a show spann summ gives me the vlans in question,1 and 3:

3548#sh spann sum

UplinkFast is enabled

PortFast BPDU Guard is disabled

Name Blocking Listening Learning Forwarding STP Active

-------------------- -------- --------- -------- ---------- ----------

VLAN1 0 0 0 2 2

VLAN2 0 0 0 3 3

VLAN3 0 0 0 2 2

-------------------- -------- --------- -------- ---------- ----------

3 VLANs 0 0 0 7 7

xcz504d1114 Fri, 03/06/2009 - 12:20
User Badges:
  • Bronze, 100 points or more

What's the "show VLAN" look like on both switches? (Only concerned with VLAN 1 and 3)

Is either switch running VTP?

miketennyson Fri, 03/06/2009 - 12:31
User Badges:

sco3548-1-6#sh vlan

VLAN Name Status Ports

---- -------------------------------- --------- ------

1 default active

2 central6 active Fa0/9

3 3 active

261 261-488 active Fa0/1,


All switches are running in vtp client mode except for the distribution switch which is running in server mode. Prior to the move, they were in one vtp domain. During the move, I migrated to a new domain. The new domain was setup prior to moving the management vlan to the new vlan. The vtp domain is correct on all switches have been verified multiple times.

If a reboot fixes this, then there has to be a clear command that would also fix this I am assuming.

xcz504d1114 Fri, 03/06/2009 - 12:41
User Badges:
  • Bronze, 100 points or more

The reason I'm looking for the VLAN and VTP information is because you indicated the error message said the names did not match.

I have seen instances where an upstream switch was not sending VTP information to a downstream client switch (reboot fixed my problem and VTP distribution commenced).

One thing to check is the VTP configuration of your switches, remember domain names are case sensitive, verify version numbers etc. Easiest way to see if VTP is working or not is to look at the VTP revision number, it should be the same on all switches.

Also check your switch that is acting as your VTP server and verify you have VLAN 3 created on him.


This Discussion