For those of you still skeptical about the whole VTP-client-updating-a-VTP-server thing, here are some details for a short experiment to prove the point. The trick is to get to the beginning state of the question, in which the VTP client has a larger revision number than the VTP server – knowing that you still can’t configure VLANs on VTP clients.
If you just have two questions, say with 1 VTP server (SW1) and 1 VTP client (SW4), matching the names used in Tuesday’s questions (http://www.networkworld.comhttps://www.networkworld.com//community/node/19874), there’s no way to reach the initial state in the question, with SW4 having a higher revision number. So, put another switch into the network, SW2, that’s also a VTP server, with the same domain name and password.
So, for this experiment, erase the startup config, delete the vlan.dat files, and reload each switch – all while disconnected from each other. Then configure them with the same domain name and password, making SW1 and SW2 servers, and SW4 a client. Then connect each switch to each other switch, using trunks. Then, at either SW1 or SW2, create VLAN 11. VTP will advertise the VLAN to the other two switches, so all 3 switches will know about the 5 default VLANs (1, 1002-1005), plus the new VLAN 11, and all have a revision number of 2.
Next, disconnect both trunks connected to SW1, so it’s isolated.
Then, start adding and deleting VLANs on SW2. SW4, still connected to SW2, will learn of the changes, and keep incrementing its VTP revision number as well. For example, if you delete VLAN 11, create VLAN 44, and then create/delete another VLAN twice, that’ll be 6 more changes, driving SW2’s revision number up to 8. SW4 will keep learning of the changes, and be at revision number 8 as well. The VLAN database on SW2 and SW4 will not include VLAN 11, but it will have VLAN 44, matching Tuesday’s example question. However, the main point is that SW4’s revision number is now larger than SW1’s, and their VLAN databases are different.
To finish the experiment, disconnect the trunk between SW2 and SW4, so that all three switches are isolated. Now the conditions match the original problem statement from Tuesday’s question, assuming you just ignore SW2 from now on. To finish the experiment, connect the trunk from SW1 to SW4 again, and watch SW1’s VLAN database and VTP revision number change to match (client) SW4’s database.
Of course, nobody would bother to do this for any real purpose in a production network – this is just an easy way to test the concept with only 3 switches. If any of you take the time to try the experiment, I’d love to hear about it!
