My VLANs are all gone?! "VTP Chaos" Packet Tracer Demo

This file was inspired by the example presented in APJ Instructor Forum on July 15, 2010.

VTP (VLAN Trunk Protocol) is a very convenient tool for us to distribute VLAN information. However, some serious LAN outage might happen if we do not use it with care, while adding new switches.

I created this Packet Tracer (v5.2) file to demonstrate such disastrous situation.

• VTP-Chaos.zip, (Backup Link)

You can make use of this file by "Normal Scenario" first, then "Chaos Scenario", to demonstrate the disaster.

Normal Scenario

Start this PT file, and the spanning tree will become stable after a while.

Now PC1 should be able to PING PC3. At the same time, PC2 should be able to PING PC4. In fact, PC1 and PC3 are both in VLAN 10, while PC2 and PC4 are both in VLAN 20. When PINGs are successful, it shows a normal working LAN scenario.

Live network contains only Switch1 and Switch2. Switch3 and Switch4 denote the new switches to be added later.

Note: at this step, the trunk link between Switch3 and Switch1 is shutdown at Switch3 side on purpose. This simulates the new switch Switch3 is not plugged into Switch1 yet. So is that between Switch4 and Switch2.

Chaos Scenario

Before next step, I suggest to start continuous PINGs to show clearly the effects of chaos. Continuous PING can be done by "ping -t 1.1.1.3" on PC1, for example.

Now, clear existing configuration by "write erase" on Switch3 (or Switch4), and then do a reload.

The trunk link between Switch3 and Switch1 will become active. This simulates Switch3 is plugged into live network at Switch1. So is that between Switch4 and Switch2.

The chaos would begin soon! You can see it on the failed PING responses on PCs. The ports PCs attached to will also become in "err-disabled" state, in orange color.

More on this: How to "solve the problem" when it happens?

The only way out is to re-create all live VLANs on one VTP server role switch. If you have good maintenance documentation and are a good typer, you would be able to recover all VLANs in tens of minutes.

In this case, create VLAN 10 and VLAN 20 on Switch1, by these commands:

config t
vlan 10
vlan 20

More on this: How to "prevent the problem"?

The root cause of the problem is at the VTP revision number. When the newly added switch has larger revision number, its VLAN information would overwrite existing VLAN information, and on, and thus whole network is down.

Please note that adding VTP server or VTP client would both cause such problem. I assigned Swtich3 as VTP client role to demonstrate this scenario. That is, adding VTP client is no safer than VTP server!

To prevent this, you must reset the VTP revision number to zero before plugging in the new switch. To reset the revision number, you can do one of the following:

• Set VTP mode to transparent and then back
• Change VTP domain string to other and then back
• Delete flash:vlan.dat before power-off the new switch

---
Cheers!

Reference:
Reference of the problem on Cisco.com: "How a Recently Inserted Switch Can Cause Network Problems"