Although Vlan Trunking Protocol does its job in distributing vlan database from server to all the other client switches. It has some major issues when wrongly implemented or trunk negotiation between switches.
1- Always reset the revision number of a switch before adding to production network. It happened almost everywhere.
The usual scenario, a switch goes down somewhere. and in the emergency state, someone will go bring that test lab switch, delete the running config. Then add it to production network. BAM, suddenly all vlans have disappeared, and we have whole network outage.
Reason for this phenomena is that the test lab switch will have higher configuration revision than the normal production network. Remember a Server will accept VTP update from client if the client had a higher revision number.
2-Always Hard code a trunk link between two different VTP domains.
In the case of keeping the default setting of trunk config in just one side.
switchport mode dynamic desirable
this will cause trunk negotiation to fail and the port will work as access, and you would have partial network outage.
In interesting case, it happened in my own organization. where the negotiation failed. but in Sw1 it showed the link as trunk using the command (show int trunk), and showed the link access in the Sw2!!
3-Know the maximum Vlan supported by a switch.
Some low end switches (2960, 2950,etc) have a maximum vlans support. If you make these switches into client mode. They will cause various issues, and the best solution would be to make them transparent.