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:

VLAN1

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

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.

Regards,

Francois

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?

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

shut

int vlan 10

ip address 10.1.1.1 255.255.255.0

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.

HTH,

Craig

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.

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?

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.

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

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

Is either switch running VTP?

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,

Fa0/5,

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.

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.