nected 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 institution's CTO on a rampage! What went wrong? Remember that many switches are VTP servers by default. Re- member, also, 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 3750s had been functioning as 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 switch on the main network, including the core 6509s, received an update with a higher revi- sion number than its current configuration. Consequently, they all requested the VLAN configuration from the rogue 3750s 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 3750s 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, V