Core issue
VLAN Trunk Protocol (VTP) allows ease of VLAN management because it allows the addition or deletion of VLANs across many switches. VTP does not require you to make additions or deletions individually on each switch.
Devices configured as VTP servers (the default) periodically send messages with their VLAN configuration across the VTP domain to which they belong. Each time a VLAN is deleted or added on a switch, the config revision number is increased.
The addition of a switch to a network within a VTP domain can cause lost connectivity across that network. This happens because the newly introduced switch has a higher config revision number than that of the VTP domain. The other switches adopt its VLAN configuration. The VLAN configuration of the new switch does not match the other switches. Since the new addition has the highest config revision number, all of the other switches configured as a VTP client or server in the VTP domain modify their VLAN configurations to match.
This behavior can lead to the deletion of numerous VLANs, a loss of connectivity across the network, and the ports can become inactive. This most commonly occurs when the new switch was previously tested in a lab setting where repeated VLAN modifications were made. If precautions are not taken before the switch is connected to the production network, what is normally a beneficial feature causes a major issue.
Resolution
To remedy the situation, perform this procedure:
- If the links are down for ports because they are assigned to VLANs that no longer exist, put the switch(es) into VTP transparent state and manually configure the VLANs.
This results in immediate recovery.
- Verify that the current VTP core server has the needed VLANS, and is connected to the rest of the switches through trunked ports that are:
- allowed on those trunks
- allowed and active in management domain
- in spanning tree forwarding state and not pruned
Note: If the clients are still in the same VTP domain, and trunked correctly, ideally VTP messages traverse that VTP domain.
- If problems persist, reload the switch and configure it manually in order to restore connectivity.
Note: Always verify a switch's VTP configuration before connecting it to a production network. If the switch has been previously configured or used elsewhere, it might already be in VTP server or client mode with a VTP configuration revision number that is higher than other switches in the production VTP domain. In that case, other switches will listen and learn from the new switch because it has a higher revision number and must know more recent information. This could cause the new switch to introduce bogus VLANs into the domain or, worse yet, to cause all other switches in the domain to delete all their active VLANs.
In order to prevent over-writing the VTP network whenever a new switch is added in the future, always take these precautions:
- Reset the configuration revision number so that it is lower than that of the rest of the VTP domain with these steps.
- Change the VTP domain of the new switch to a bogus and nonexistent VTP domain name, and then change the VTP domain back to the original name
- Change the VTP type from server (the default) to transparent, and then change the mode back to client or server.
- Physically connect the switch to the network.
For additional information on this issue, including step-by-step instructions, refer to How a Recently Inserted Switch Can Cause Network Problems section of the document Troubleshooting VLAN Trunk Protocol (VTP).
