VTP Clients Updating Servers (and Answers to Questions)

Current Job Listings

When I first heard that a VTP client can update a VTP server under the right conditions, I was frankly a non-believer. No way. I'd seen evidence to the contrary in several documents at cisco.com and in Cisco courses - but all the evidence was written, without my doing any experiments. So, I spent some time experimenting a few years ago, and found that it's true - clients can overwrite VTP server's VLAN databases. And this matters for the exam and for real life in some cases, so it seemed a good topic to talk about this week.

First, the questions from Monday and Tuesday. For Monday's question (http://www.networkworld.com/community/node/19832), the right answer is "B". For two neighboring switches to even send VTP messages, the link between the switches must be a trunk (either kind). The VTP domain name and VTP password must be the same, and the MD5 digest listed in the show vtp status command will be different if either the domain name or password differs. With all those conditions in place, the switch with the smaller revision number will see the larger revision number on the other switch, request a copy of the VLAN database from the switch with the larger revision number, and update its VLAN database. In Monday's question, SW3 and SW4 had different MD5 digests, so no VTP messages flowed into SW1 from SW3 or SW4. SW2 met the requirements for VTP to work, and SW2 had the larger revision number - so SW1 overwrote its VLAN database (a replace action, not a merge), giving SW1 a VLAN 22, but deleting VLAN 11.

Yesterday's simpler question (http://www.networkworld.com/community/node/19874) started right up front with all the requirements met for VTP to work - a working trunk, with a matching MD5 hash (indicating the same domain name and password). SW4 had the larger revision number, but SW4 is a client. As it turns out, the switches ignore the client/server status at this point. Both switches send VTP messages that announce their details (notably the MD5 hash, mode, and revision number), so SW1 (server) discovers that SW4's has the same MD5 digest and that SW4's revision number (8) is larger than SW1's (2). So, SW1 requests and receives a copy of SW4's VLAN database, with SW1 overwriting its own VLAN database with SW4's database. As a result, SW1 effectively deletes VLAN 11, and adds VLAN 44.

Now, back to the poll. At the time I'm writing this post, 44% of you chose the 2nd answer, meaning that you knew the correct VTP behavior. Given that Tuesday's question removed most of the variables from Monday's more general question, I'd say that's a pretty high percentage that would've gotten the wrong answer on such a test question. (Click here (http://www.networkworld.com/community/node/19874 to see the latest poll numbers, and participate if you haven't already done so.)

Now, if you're still skeptical, I don't blame you. I spent several hours testing this the first time I heard it, and I still get questions from readers of both my CCNA and CCIE books about this very topic. So, I figured the blog would be a good place to help get the word out. On Thursday, I'll post the outlines of a simple 3-switch test you can do at home to test this theory, if you're as skeptical as I was. But here's a more realistic scenario, one that I'm sure has happened more than once:

In a lab that's separate from the production network, an engineer is configuring switches, with VTP configured, with the same domain name and password as the production network (maybe somebody started with a copy/paste?). Anyway, one of the production switches fails, so the engineer grabs one of the VTP client switches, since the engineer thought that adding a VTP client switch to the production network would be harmless. Well, the VTP and VLAN config are stored in the vlan.dat file in flash, not in NVRAM - so even if the engineer had done a erase startup-config before unplugging the switch, the switch still has its VTP info (which matches the production network) and its VLAN database - which may well have a larger revision number, because of all the experimentation in the lab. So, you plug in the old lab switch, the trunk comes up to the production network, and you overwrite the VLAN database on all the switches, practically instantly. Yikes. This could delete all the VLANs on the existing production switches, and essentially crash the entire campus network. There's probably no better advertisement for not using VTP (aka using transparent mode) than this scary scenario.

Any similar war stories out there about killing a network with VTP? Feel free to comment away.

Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.
Related:
Now read: Getting grounded in IoT