So here is the scenario for the question. The Fa0/24 connection is suddenly broken between SW1 and SW2, and while that is down, a new VLAN (we will use 999) is created on SW3 like this:

SW3(config)#vlan 999

And then, a few minutes later, SW3 is completely powered off, shipped to another city, and removed completely from this network forever.

If we then restore the Fa0/24 connection between SW1 (the server) and SW2 (the client) what will happen to the VTP/VLAN information on the two switches? Will there be an update on either switch, will SW1 wait for a Server advertisement or will something else happen all together?

Take a moment, and let us know what you think.

Best wishes.

PS We’ll post the results as a after you have had some time to consider the results.

A few hours have passed, and we have had over 50 comments , ideas and theories.

I appreciate you taking the time to work through this. May your hard work pay off with a successful lab.

And the correct answer is:

SW1, will see that its configuration revision number is lower than SW2, and even though SW2 is a “client” SW1 will use the updated information in the VTP advertisement from SW2 to update to its VLAN database, and get in “sync” with the rest of the VTP domain, including knowing about VLAN 999. The configuration revision number would also move to 4.

I believe that despite SW2 being a client, when SW1 comes back online it will still see the higher revision number that SW2 has in its advertisements and update its VLAN configuration with the new 999 VLAN.

Sw2 will get the newly created vlan and the revision number will be raised in Sw2 and Sw3. However, there is no sync from Sw2 (client) to Sw1 (server) so the newly created vlan wont show up in Sw1 until Sw3 is plugged in again.

Yes. Clients really can overwrite servers’ configs (if they have higher revision number and all other needed parameters match).
OMG! Client(SW2) will pass it’s configuration to SERVER(SW1) (since it has higher revision number) despite the corollary that servers rule the world (the domen).
I remember those days then it was written in my favorite CCNA book what ONLY SERVERS can update configuration and I decided to check it out with real equipment and I was shocked to see it!

Interesting scenario, SW1 will receive a VTP summary with a higher revision number from SW2, then it will send a request to SW2 for vlans information, SW2 will respond with a VTP subset packet including details of its vlans, including the new one, SW1 will add the new vlans and update its revision number.

As soon as the SW1 is back up, the SW2 receives its VTP updates and see the revision number less than the one it has.
SW2 will update the SW1 and SW1 will update have its VTP updated with the new VLAN.

I guess this is due the possibility to SW2 (as client) receives VTP updates from other servers.

We know that VTP propagates the VTP information received from other switches, since within the same VTP domain and properly configured.

Since Client has a better VTP, it was sent to SW1 and SW1 updated its vlan database and revision number.

1. Link down between SW1 and SW2
2. SW3 created new vlan
3. SW3 increate its vtp advertisement number.
4. SW2 will get this advertisement and because it’s received higher advertisement number then it will take that as an update.
5. SW2 will have it’s new vlan
6. SW will update the new advertisement with new vlan and increase the advertisement number.
7. SW3 turned off
8. IF the link between SW1 and SW2 came back, then SW2 will advertise this to SW1
9. SW1 will take this new update and have its new vlan.
7. SW2 will adv
After the connection restored, other switches will learn the new vlan from the highest revision update number.

The definition of VTP client mode said that we cannot add, delete or change the VLAN but there is still no indication that it will not update the other switches if a lower configuration value received from a peer switch. In this case, the switch SW1 will be updated after some time when periodic advertisements are exchanged between the two switches.

Even though, SW1 is the server for the VTP domain,SW1 will get the Vlan 999 from the SW2 because they have the same VTP domain name and SW2 will have highher configuration revision number. This might not be much of an issue, in this case, because the existing vlans on SW1 do not have any interfaces in them and they have not been removed from the vlan database. If those vlans had been removed on SW3 and thus SW2, and if SW1 had ports assigned into the respective vlans, the ports would have been disabled.

When the Fa0/24 connection is restored the configuration revision number on switch 1 is lower than that of the client switch 2 due to the addition of VLAN 999 when switch 1 was disconnected. The clients (switch 2) VLAN database will update the server (switch 2), with the recently created VLAN 999.

assuming you type exit after vlan 999, and that vlan is created in the database, switch 2 will be updated with the new vlan.

after the connection between SW1 and SW2 is brought back, SW1 will not have the new vlan. SW1 will be updated if SW2 create a new vlan, as VTP advertisement will be sent if there is any change in the vlan database.

SW3 creates VLAN 999 and both it and SW2 go to configuration revision 4. When SW3 is removed and SW1 is reconnected, it will see the higher revision number on SW2 when SW2 sends a summary advertisement. Although SW2 is a client, SW1 will still update its VLAN database and configuration revision to match and will see VLAN 999.

Keith correct me if i`m wrong but in some cases VTP client can override the VTP server configuration if the revision number is higher so the switch with the smaller revision number (SW1) will see the larger revision number on the other switch (SW2), request a copy of the VLAN database from the switch with the larger revision number, and update its VLAN database and VLAN99 will be on SW1 … hope i`m correct

I do not think their will be a vtp update altogether. As far as I know, VTP updates are sent only when updates are triggered within a given domain.i.e a new vlan is created and the trunk link between the switches is up.

First the new VLAN 999 will be learned by SW3 itself due to the configuration change. The configuration revision number will be incremented to 4.

VTP exchange will make the same happen on SW2. It learns the new VLAN 999 and will also increment the configuration revision number to 4. It will do this because the configuration revision number was smaller when the VTP info was received.

When SW3 is removed nothing will happen. SW2 knows VLAN 999 already. The configuration revision number will stay 4 because no configuraion change is done. Ofcourse, nothing will happen on SW1 because no VTP information is exchanged with this switch due to the link failure.

After the link is restored. VTP information can (and will) be exchanged. Because the configuration revision number on SW2 > SW1 the last switch will learn the new VLAN. It doesn’t matter that SW2 is a client and that SW1 is a server. SW2 will even wreak havoc if it has to (when for example it has no VLANs in its database, but the configuration revision number is still higher than the other switches). Put in other words: because SW2 has the highest revision number its VLAN database will be mirrored to SW1. It doens’t matter what the contents of the VLAN database on SW1 are. The fact that a switch is a VTP server only makes it possible to make configuration changes to the VLAN database (by hand!). That cannot be done on a client. It will refuse. But VTP can and will make changes regardless of client or server mode.

In this case the new VLAN will be learned by SW1 after the link is restored and that’s probably what you want, assuming VLAN 999 is actually needed on this network.

Nice post. To answer the question. The SW2 (client) will learn the new vlan 999 from sw3 and up rev will change to 4 and store it in NVRAM.

Once SW3 powered off, it will not affect the sw2 database, all VLANs will still remain. Upon link between SW1 and SW2 comes up, SW2 send the advertise its database to SW1 with its revision 4 high than Sw1 rev 3, so the Sw2 database is preferred and Sw1 update its VLANs database with this new value.

SW3 is a server and since a new VLAN is created it will propagate the change (addition of VLAN 999) to the rest of the network. SW2 as a client will update its VLAN database and add VLAN 999.

However, since the link between SW2 and SW1 is broken by the time of VPT advertisement, SW1 will not update its VLAN database accordingly. Then SW3 is removed completely from the network and SW1 remains the only switch in VTP server mode.

As soon as the link between SW2 and SW1 is restored, VTP server SW1 will check its config revision within VTP (still and will try to update the SW2 (will have config revision 4 after the addition of VLAN 999 in its database) with its own (most updated as he thinks) VLAN database. This VLAN 999 will be removed from SW2 VLAN database and a service affection for specific VLAN will occur for whoever is configured in it.

Whatever VLAN configuration is present on the SW1 (after restoring the link between itslef and the SW2) will be revelead as well on SW2′s show VLAN output. Note that the VLAN 999 (propagated by SW3 to SW2) when SW1-SW2 link was broken, will not be shown on the ‘show vlan’ output after SW1-SW2 is restored.

after vlan 999 has been added, SW2 will have a higher revision than SW1
when the link between SW1 & SW2 is back up, vlan 999 will be added to SW1 because it looks at rev-nr. no matter if SW2 is a client

I think the new Vlan in sw2 will disappear.
Here is my explanation:
When the connection between Sw1 and Sw2 is restablished, Sw1 is the server and would have a low revision number in vtp, so it would populate its vtp database to sw2, then only vlans 2,3 and 4 would stay in SW3.

My first thought is that SW-2 will at first not have a problem and remain to support vlan 999. Advertisements from SW-1 will be ignored as long as the version is lower or equal to its own. But after SW-1 has had changes to its VLAN database, its version will increase until the client version on SW-2 is lower than the version on VTP-server SW-1. At this time it will sync its database and vlan 999 will disapear from its database as SW-1 is not aware of this vlan. (as long as any changes did not include this vlan of course).
This is my reasoning anyways…

After VLAN 999 is added, SW2 and SW3 will increase Configuration Revision to 4, while SW1 will remain on revision number 3.
After link between SW1 and SW2 is up again, SW2 can not populate it’s VLAN database to SW1, as SW2 is VTP client. So, switches have inconsistent VLAN database at this moment.
After admin adds or removes VLAN on SW1, it’s VTP revision will increment by one.
This has actually have to happen twice, as if revision number in VTP advertisement is equal, receiving switch ignores this advertisement.
So, after 2 VLAN changes on SW1, VLAN 999 is wiped out from SW2 VLAN database and SW2 has it’s VLANs aligned to SW1.

Sw3 will update Sw2 with vlan 999
Sw2 will increase it’s Configuration revision nuber (Switch 3 & 2 are now on the same revision number)
Sw3 is disconnected. No biggie there.
Connection to SW1 is restored,
Sw2 will override Sw1 because it has a higher configuration revision number.
Sw1 will add vlan 999 and update it’s revision number.

Hi Keith!!!
Answering your post about VPT… If you disconnect the SW 3 but you have created a vlan 99 before that, this VTP Update will be propagated to all others VTP CLIENT and SERVERS. Since VLAN 99 have been created by a VTP SERVER it will be advertised to SW 1 even if it is not connected to the network at this moment, breaking the rule of VTP Client/Server update. So the VTP Revision Configuration number will increase in one accepting the VLAN 99 which was created but another VTP Server, not by a VPT Client. Let me know any comments about it. Thank`s

Sw2 will have the vlan 999 information but not sw1, since the sw2 have the higher revision number, it won’t update its vlan information from sw1 although sw1 is the server. Only when sw1 have a higher revision number, then sw2 will get updated.
Does it make sense ?

as soon as the trunk between SW1 and SW2 comes up both will sync to each other and SW1′s revision number sync to SW2 and vlan 999 created on SW1 as well. full description of it available in below cisco VTP flash.http://www.cisco.com/warp/public/473/vtp_flash/

When the Link comes up again, the VTP Server will send a Summary Advertisement to the VTP Client.
The Client compares his local Revision Number with the Revision Number inside of the Summary Advertisement.
The received Summary Advertisment from the Server contains a lower Revison Number then on the VTP Client locally (because of the creation of VLAN 999 on SW3 which was propagated to the VTP Client,) and the Summary Advertisement is ignored from the VTP Client.
The VTP Client also sends a Summary Advertisement to the Server. The Server compares the local Revision Number and recognizes that the received Revision Number is higher then the locally stored.
The VTP Server will then send an Advertisement Request to the VTP Client which answers the request with a Summary Advertisement and (one or more) subset Advertisements.

In Short, The VTP Server inserts the information about vlan 999 in his VTP Database.

In my opinion it will forward the vlan 999 to SW1 since it has a higher revision number on the client hence SW1 will be updated with this new information. In a client mode you cannot create, delete or change but you forward the information.

SW3 creates the vlan and sends an update to SW2 since the revision number is higher SW2 updates its vlan database and when the link between SW2 and SW1 cames back up it will send the update so SW1 will have vlan 999 too

Correct is
SW3 update vlan database on SW1 due better revision number, revision number are equal at both switches
SW3 shutdown
SW1 up
SW1 receive info from SW2 about better revision number than its own and so SW1 updates vlan database with vlan 999
p.s no changes for vlan databse at SW1 during disconnection from network – tested in simulation, and its logical by theory
p.p.s better revison number == higher revision number
p.p.p.s sorry for bad english

Arnuad is mistaken. You do NOT have to exit the config-vlan mode for VTP to replicate a VLAN, since it was a global command. Even if you are in the vlan database, you do NOT have to exit for it to apply.

Switches do not even need to be in FWD state for it to replicate VTP updates.

Sw2 will tell Sw1 about the new Revision when it comes back up, even before the trunk is in FWD state, as VTP is like BPDU’s and CDP, which talk before fwd’ng data.

Sw2 would even replicate the Revision to Sw1 even if Sw2 was transparent, as long as it is in the same Domain, in this case INE (which is case sensitive).

It also would replicate in transparent if it was NULL.

The only time it would not replicate is if it had a different domain name than Sw2.

VTP Version 2 doesn’t help at all, as it only gives you Token Ring support, and since they are all the same replicate just fine.

I have made a mistake in the previous comment because I though that configuration revision of SW3 was 8! I have to be more cautious next time…I saw 8 that was the number of VLANs created in SW1 and mistaken it with config revision, thus leading to a wrong reasoning!

Leave a Reply

Currently you have JavaScript disabled. In order to post comments, please make sure JavaScript and Cookies are enabled, and reload the page.Click here for instructions on how to enable JavaScript in your browser.