VTP offers a lot of advantages, but it can have some pretty serious drawbacks, too, especially if you’re not careful.
Imagine a network in an active office. The office is in Manhattan and spans 12 floors in a skyscraper. There is a pair of 6509s in the core, a pair of 4507Rs on each floor in the distribution layer, and 3750 access-layer switches throughout the environment. The total number of switches is close to 100. VTP is deployed with the core 6509s being the only VTP servers. The rest of the switches are all configured as VTP clients. All in all, this is a pretty well-built system, very similar to the one shown in Figure 6-1 (but on a grander scale).
Now, say that somewhere along the way, someone needed some switches for the lab and managed to get a couple of 3750s of his own. These 3750s were installed in the lab but were not connected into the network. For months, the 3750s in the lab stayed as a standalone pair, trunked only to each other. The VLAN configuration was changed often, as is usually the case in a lab environment. More importantly, the lab was created as a mirror of the production network, including the same VTP domain.
Then, months after the 3750s were installed, some knucklehead decided that the lab needed to connect to the main network. He successfully created a trunk to one of the distribution-layer 4507R switches. Within a minute, the entire network was down. Remember the angry foreman with the threatening pipe wrench? He’s got nothing on a financial ...