Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

VTP Configuration Revision

Say i have one new Switch and i set it to vtp client mode. This Switch have a revision number of 1120.

Next, i connect it to the live network Switch which are in vtp server mode. But the revision number is only 900.

Can the new Switch affect the live Switch which is on vtp Server mode?

17 REPLIES
Hall of Fame Super Bronze

Re: VTP Configuration Revision

I've seen odd behavior when doing such thing.

I highly recommend changing the VTP domain to something else on this switch (this reset the revision number), then connect the switch to the production network, change the VTP domain to the current production network and the Vlan information will be received from one of the VTP server along with the current revision number of 900.

HTH,

__

Edison.

Please rate helpful posts

Re: VTP Configuration Revision

Hi

AFAIK if the domain name is same then the new switch might overwrite the existing vtp database if the domain name is different it will be fine.

Thanks

Mahmood

Re: VTP Configuration Revision

I believe the behavior is version dependent. There was one time when I would have said unequivocably "Yes, the version 1120 client will update the version 900 server."

Now I say "The version 1120 client might update the version 900 server."

I did some experiments on this a while back, and I found that if the 1120 switch has been rebooted since it became client, then it could not update the server. But if you make it server, arrive at version 1120, change it to client, and then connect it ... yes it will update the 900 server.

So, it is probably version dependent. In any case I can definitely say that a client with a higher config level is dangerous.

One day I shall find time to repeat my experiments and publish my results properly.

Kevin Dorrell

Luxembourg

Re: VTP Configuration Revision

As soon as you change the domain of the client with higher revision number to your vtp domain, the client definitely overwrites the server with its own vlan information.

Re: VTP Configuration Revision

Mmm, I don't think that's right. If I remember rightly, changing the domain name, even on a client, will knock the revision level down to 0, so it will pick up from the server.

Can anyone tell me I remembered wrong?

Kevin Dorrell

Luxembourg

Hall of Fame Super Bronze

Re: VTP Configuration Revision

VTP Version : 2

Configuration Revision : 6

Maximum VLANs supported locally : 1005

Number of existing VLANs : 14

VTP Operating Mode : Client

VTP Domain Name : NET34

VTP Pruning Mode : Enabled

VTP V2 Mode : Enabled

VTP Traps Generation : Disabled

MD5 digest : 0x0D 0x76 0xE5 0xE5 0xB2 0x90 0x44 0x58

!

!

!

S2(config)#vtp domain test

Changing VTP domain name from NET34 to test

S2(config)#end

S2#sh vtp status

VTP Version : 2

Configuration Revision : 0

Maximum VLANs supported locally : 1005

Number of existing VLANs : 14

VTP Operating Mode : Client

VTP Domain Name : test

VTP Pruning Mode : Enabled

VTP V2 Mode : Enabled

VTP Traps Generation : Disabled

MD5 digest : 0xCB 0xC1 0xB2 0xC8 0xA7 0x9A 0xE9 0x86

____________

The other statement about wiping the database is also incorrect. I've seen strange behavior with different configuration revision numbers but I haven't seen a client wiping the server VTP database.

__

Edison.

Re: VTP Configuration Revision

Edison,

Thanks for verifying that for us.

I have seen a client update a server's database, but the test is quite a corner case. These are the steps:

1. Set up two switches, one in server mode, one in client, and check they are synchronised.

2. Disconnect the trunk between them.

3. Change the client to a server, delete a few VLANs, and then change it back to a client.

4. Reconnect the trunk.

When I did this test, the server got updated by the client.

Do not reload the "client" switch at any time during the test. Reloading seems to prevent the update, and the "client" stays at the higher revision level until the rest of the domain catches up.

Kevin Dorrell

Luxembourg

Hall of Fame Super Bronze

Re: VTP Configuration Revision

I have seen a client update a server's database, but the test is quite a corner case.

Didn't I say you can see weird behaviors when dealing with VTP configuration? :)

That's is very strange and I've tried to duplicate it here w/o success (running 12.2(25)SEC2 on 3560 switches).

Since I always reset the VTP revision number on a newly inserted switch *and* delete the vlan.dat, it will be hard for me to see that problem unless I'm really looking for that problem.

Deleting the vlan.dat from a new switch should also be included as a step for best practice in a production network.

__

Edison.

Re: VTP Configuration Revision

Edison, thanks for highlighting this. Strange!!! I'm a victim of an outage due to client switch overwriting the server, when i directly added it to the vtp domain in production. From your example it seems changing the domain name resets the config revision to 0, which didnt happen in my case.

Hall of Fame Super Bronze

Re: VTP Configuration Revision

Hi narayana,

Very strange indeed, regarding your network outage.

What you experienced does not follow the VTP guidelines as the "client" should never send updates to the server. The "client" only receives updates from the server and the server is the only one with send/receive updates features as it needs to communicate with other servers (that's the reason the receive feature is available in addition to the send feature).

Was the client configured as server previously and never rebooted between changes as Kevin explained above?

__

Edison.

Hall of Fame Super Bronze

Re: VTP Configuration Revision

Well Narayana,

I stand corrected. Your outage is documented as a normal behavior.

Please see:

http://www.cisco.com/en/US/tech/tk389/tk689/technologies_tech_note09186a0080094c52.shtml

and click on the Flash Animation: VTP presentation.

My apologies.

__

Edison.

Re: VTP Configuration Revision

Edison,

That flash animation was the starting point for my experiment, but I don't think it told the whole story. I was expecting the client always to update the server if it had a higher revision, but I found that a reboot prevented that. That's why I say it must be version dependant.

I'll see if I can find the version in my old lab notes this evening. (It was before I started blogging, so the notes are written out in longhand on paper.)

Kevin Dorrell

Luxembourg

Hall of Fame Super Bronze

Re: VTP Configuration Revision

Kevin,

Perhaps this issue has been fixed with recent IOS versions as I can't duplicate in my lab.

Hall of Fame Super Bronze

Re: VTP Configuration Revision

Well, Kevin,

5 pointer for you. I followed your steps and I was able to duplicate it.

See my attached files.

The key is rebooting between sessions.

Thanks !

__

Edison.

Re: VTP Configuration Revision

Hello Edison, from the text file "vtp client wipe" following are my observations:

-You changed the domain of s2 to test, deleted vlan.dat & rebooted. But after reboot, it synchronised with s1 in domain NET34. this should have not happened. does this mean, irrespective of the domain higher config revision always overwrites lower revision.

-Also, before reboot s2 had vtp v2 enabled. but after reload it was vtp v2 disabled. was this intentional?

With reference to "vtp client does not wipe":

- S2 is client with higher revision. s1 is server with lower revision & rebooted.

After reboot:

Expected: s2 (client with higher revision) should overwrite s1 with its own vtp information. strange, it didnt happened.

Desired: s1 being a server should update s2 with its vtp info. strange, this also didnt happened.

Hall of Fame Super Bronze

Re: VTP Configuration Revision

-You changed the domain of s2 to test, deleted vlan.dat & rebooted. But after reboot, it synchronised with s1 in domain NET34. this should have not happened. does this mean, irrespective of the domain higher config revision always overwrites lower revision.

Based on my test, that's correct. This whole process occurs during the VTP synchronization.

-Also, before reboot s2 had vtp v2 enabled. but after reload it was vtp v2 disabled. was this intentional?

Good eye. I didn't make any changes in the version 2. I simply deleted the vlan.dat bringing every back to default.

Expected: s2 (client with higher revision) should overwrite s1 with its own vtp information. strange, it didnt happened.

Strange, indeed. Add it to the odd behaviors I mentioned in the beginning of this thread.

The safest approach is to always delete vlan.dat to avoid any of this mess.

HTH,

__

Edison.

Re: VTP Configuration Revision

Thank you Edison!

KJD

400
Views
10
Helpful
17
Replies