VLAN Database Updating

[thomascollins]

What could cause the vlan database on our core switch to get updated? We don?t run VTP, and our trunk links to other switches are set as 802.1Q and ?switchport nonegotiate? (which should prevent DTP from updating the vlan databases I thought).

But somehow vlan changes to a switch are causing the vlan database on the core switch to be wiped out.

How can I prevent that? I only want the vlan database to be updated manually from the core.

[Jon Marshall]

Hi Thomas

Are you saying that all your switches are in VTP transparent mode ?.

As far as i know DTP is about dynamically negotiating trunks not vlan propogation.

Jon

[glen.grant]

Only a server can update the vlan database or it can be done locally if it is transparent . If it changed for some unknown reason I would start looking for another device in server mode . If the switch is transparent then someone manually changed it , check logs .

[bjw]

Or if you have a switch running VTP V2 as a client and it's rev# is higher than the VTP server, it could cause undesirable issues.

Set the core to servers and all others to transparent.

[thomascollins]

Thanks everyone...

Turns out the problem was as you suggested...a new switch running v2 set as a server, with a higher database revision.

So my question is now how to fix it.

I think there are two paths...

-Force the "core" switch to be the VTP master server and all others to be clients, and probably assign a password so new switches can't become VTP domain servers?

-Set the "core" switch to VTP transparent mode, which would only allow updates locally?? That's the one I'm not too sure about the implications of.

Thanks!

[sundar.palaniappan · Accepted solution]

If all your switches are capable of running VTP then I highly recommend enabling VTP as the configuration scales well as your network grows.

Make your core switch(s) to be the VTP server and all the other switches to be VTP clients. Configure a VTP password on all your switches and this would prevent any accidental introduction of a new switch from causing network disruptions. Another key thing to remember is when you add a new switch, even if it's in client mode, to the network always reset the switch to factory settings before putting in the configuration as a VTP client would convert itself into a VTP server if the config revision is higher than that of the actual VTP server itself and this could create serious problem.

Instead, if you set them all to transparent mode then you would have to configure the VLANs manually on every switch and that could be a pain depending on how many switches/vlans you have in your network. It doesn't matter even if the VTP domain name matches in transparent mode.

HTH

Sundar

[bjw]

I would look at changing the "unwanted VTP server" first transparent mode then to client mode. As long as you're not sourcing VLANs from the false-master-VTP-server switch, the VTP dbase rev on the "newly-assigned" client should dump to 0.

And if your not sourcing any vlans locally on the false-master-VTP-server, you could just leave it in transparent mode.

Try it in a lab or on spare gear. I think you'll find it works as advertised.

[glen.grant]

Anyone who is putting new equipment on the network should know enough to clear any existing config before installing a new config on the box which would eliminate this from possibly happening , if they don't understand this then you should scrutinize who has the ability to configure devices for your network.