lso that when a switch participating in VTP receives an update that has a higher revision number than its own configuration's revision number, the switch will implement the new scheme. In our scenario, the lab's 3550s had been functioning as a standalone network with the same VTP domain as the regular network. Multiple changes were made to their VLAN configurations, resulting in a high configuration revision number. When these switches, which were VTP servers, were connected to the more stable production network, they automatically sent out updates. Each of the switches on the main network, including the core 6509s, received an update with a higher revision number than its current configuration. Consequently, they all requested the VLAN configuration from the rogue 3550s, and implemented that design. What's especially scary in this scenario is that the people administering the lab network may not even have been involved in the addition of the rogue 3550s to the production network. If they were involved, they might have recognized the new VLAN scheme as coming from the lab. If not, troubleshooting this problem could take some time. The lesson here is that VTP can be dangerous if it is not managed well. In some cases, such as in smaller networks that are very stable, VTP should not be used. A good example of a network that should not use VTP is an e-commerce web site. Changes to the VLAN design should occur rarely, if ever, SO there is little benefit to deploying VTP. In larger, more dynamic environments where VTP is of use, proper procedures must be followed to ensure that unintended problems do not occur. In the example described above, security measures such as enabling VTP passwords (discussed in Chapter 6: VLAN Trunking Protocol the next section) would probably have prevented the disaster. More importantly, perhaps, connecting rogue switches to a production network should not be allowed without change-control procedures being followed. A good way to prevent the con- nection of rogue switches is to shut down al