VTP Problems

[JohnJohnson1]

Hi,

I'm trying to add a new switch to our network however it doesn't seem to want to join the VTP domain or download the VLANs.

I've done a search on the web for it and it seems to be known issue and to fix it all i had to do was create a dummy vlan on the core which is the VTP Domain server. I have done this but the new switch is still not recieving the VLAN info.

I just did a show logging command on one of out other access switches and i'm getting the following output.

%SW_VLAN-4-VTP_USER_NOTIFICATION: VTP protocol user notification: Version 1 device detected on Po1 after grace period has ended

This has only started showing on these switches since i created and deleted the dummy VLAN.

After a bit more digging there seems to be some inconsistences which i find confusing.

on the VTP server, show vtp status

VTP Version capable             : 1 to 3

VTP version running               : 1

VTP Domain Name                : domain

VTP Pruning Mode                : Disabled

VTP Traps Generation           : Disabled

Device ID                              : 6c20.56bb.6a80

Configuration last modified by 172.16.1.1 at 1-24-14 18:43:16

Local updater ID is 172.16.1.1 on interface Vl10 (lowest numbered VLAN interface found)

Feature VLAN:

--------------

VTP Operating Mode                          : Server

Maximum VLANs supported locally     : 1005

Number of existing VLANs                  : 18

Configuration Revision                        : 1

MD5 digest                                       :

on all the other access switches

VTP Version capable              : 1 to 3

VTP version running               : 2

VTP Domain Name                : domain

VTP Pruning Mode                : Disabled

VTP Traps Generation            : Disabled

Device ID                               : 203a.07bb.5580

Configuration last modified by 192.100.101.1 at 5-17-13 13:45:52

Feature VLAN:

--------------

VTP Operating Mode                        : Client

Maximum VLANs supported locally   : 255

Number of existing VLANs                : 23

Configuration Revision                      : 25

What i find strange is the versions are different and the revision numbers are way out!!

Any idea on whats going on and how to resolve?

[Jose Solano]

Hi,

It looks like there is another device acting as the VTP server, if you see on the output where you put all access swicthes, it says Configuration last modified by 192.100.101.1 at 5-17-13 13:45:52 which is really odd since the server looks like has a different ip address. You may want to first change the VTP version to match either Version 1 or 2 and then check why the other switches are showing that.

Hope this helps.

[JohnJohnson1]

If i change the VTP version on the core and it has a different revision number wont the clients try and push an update back to the server?

This change would be live so i want to limit any downtime. Do you envisage that it was cause a problem?

[paul driver]

Hello

If i change the VTP version on the core and it has a different revision  number wont the clients try and push an update back to the server?  - yes it would that is one possible solution as the server has a lower revison number?

There area couple of others senarios also you could do to avoid any down time:

Scenario 1

1) Promote a existing switch that is running in client mode and has the highest revision number to vtp server

2) Demote the switch that is the current vtp server and running vtp version1 to transparent mode

3) Change this switch vtp version number to 2 and promote back to either server or client mode

Scenario 2

1) Demote the switch that is the current vtp server and running vtp version1 to transparent mode

2) Manually add all the current vlans running in your vtp domain to this switch

3) change this switch vtp version number to 2 and promote back to either server or client mode

Please note:

There is sometimes a misconception that a switch running in  vtp client mode cannot overwrite the vtp database - But unfortunately this is incorrect, Even though your are not able to add/remove or delete vlans in vtp client mode, this mode can still can pose a threat to overwriting your vtp database if you not aware.

res

Paul

Please don't forget to rate any posts that have been helpful.

Thanks.

[Rolf Fischer]

Paul,

John,

I could be wrong but I think if you change a VTP server or client to transparent mode, add your changes, and change it back to server/client it will start with a configuration revision of zero and all the changes will be overwritten by another VTP device with a higher CR.

So I would set one of the clients to server instead and make sure that both partitions of the domain have the very same VLAN-information. Then I would configure VTP domain and password of the new added switch like the rest of the domain.

(A 'debug sw-vlan vtp events' could help finding the reason for the current mismatch.)

The VTP version then should also get synchronized within the domain by the device with the highest CR.

This has only started showing on these switches since i created and deleted the dummy VLAN.

This makes perfectly sense, because this change of the VLAN database incremented the CR from 0 to 1 and the switch started to transmit VTP Summary Advertisements. There has to be some sort of mismatch.

HTH

Rolf

[Bilal Nawaz]

pdriver wrote:
There is sometimes a misconception that a switch running in  vtp client mode cannot overwrite the vtp database - But unfortunately this is incorrect, Even though your are not able to add/remove or delete vlans in vtp client mode, this mode can still can pose a threat to overwriting your vtp database if you not aware.

Why wouldnt you then set everything to transparent?

Get the server in shape, vtp mode, domain, password, add all the VLANs etc... Then one by one configure the client switches to be clients again, part of the same domain.... You kindof mitigate all the risks. I would do this out of hours, theres no doubt amongst us regarding this.

[Rolf Fischer]

 I would do this out of hours, theres no doubt amongst us regarding this.

I agree. A point that cannot be stressed enough!

A 'debug sw-vlan vtp events' could help finding the reason for the current mismatch.

You'll typically see messages like this:

VTP LOG RUNTIME: Dropping packet received on trunk Fa0/1 - not in domain

=> Make sure that there are no whitespaces in the domain name.

VTP LOG RUNTIME: MD5 digest failing

calculated = FD A1 5B 74 45 15 D5 D8 A1 C7 E4 2B 5C 04 E7 1C

transmitted = 1F 58 E0 B8 97 EC 77 0A 02 EE A9 36 CA 54 2E E7

=> Most probably a password-mismatch.

HTH

Rolf 

[Bilal Nawaz]

Just wanted to mention, VTP does authentication whether you have it or not - it does NULL/NO authentication. Sort of "type 0" without a password set. The switch then takes the revision number and the NULL/NO password and uses it for the seed of the MD5 digest. If there is mismatch within the domain you may get eg. ***MD5 digest checksum mismatch on trunk Te1/1***

Doesn't necessarily mean you have a password set with wrong passwords. This is perhaps why there is disagreement between two switches that both have the capability to add/remove/edit vlans in the domain currently. They're not sync'd because of the mismatch of some sort. You could even fall into an order of operations problem. Whereby configuration revision is mismatched, or some mismatch in the vlan database - you start with switch where you have vlans, then you start the VTP process on another switch that didnt have all the vlans. In this case you could simply add a vlan on the server then delete it to trigger an update to the VTP process - a change to the revision number.

In my mind it would just make sense changing everything to transparent, thus setting the clients config revision num to 0 - they still have their old vlans right? Make all the changes necessary to the server as mentioned previously. Then gracefully bring back the clients to the domain.

I guess everyone has their own ways of doing things, whats good about this field is there is more ways then one.

Please rate useful posts & remember to mark any solved questions as answered. Thank you.

[paul driver]

Hello

Bilal

Why wouldnt you then set everything to transparent? As this would obviously defeats the object of VTP sychronisation -

in my mind it would just make sense changing everything to transparent, thus setting the clients config revision num to 0  - If you had 100+ switches this would be very time consuming and unecessary

Rolf

as I have stated promoting a current vtp client to server ( which has all the current and active vlans  its  database)  isn't going to cause a issue- why would it? - as for the old  vtp server , when the vtp mode is change to transparent yes the revision number would be rest to zero and then when it is promoted back to a client/server it will inherit it vlan config from the current vtp server  or client with the highest revision number. ( just like adding a new siwtch to the network)

There are a few ways this can be archived but OP was to outline a way to utilize the vtp sychronisation process.

Lastly -  I have stated this can be done without incurring any downtime but obviously any change on a production network would have to be scheduled at a reasonable time period, and when traffic is at its lowest.

res

Paul

Please don't forget to rate any posts that have been helpful.

Thanks.

[Bilal Nawaz]

Well, because of the obvious reasons?:

1. clean up
2. make everything consistent
3. reduce the overhead of creating vlans in future

Even though you think it would be very time consuming and unnecessary, don't you think it might be worth it in the long run... I know what my answer would be to this. Then infact it does make sense if it was around 2 - 30 switches.

If I had 100+ switches - you should be asking a separate question, the design of a network would be something totally different, I would not run with VTP client server relationship at all, everything would be transparent. We haven't even discussed the size of this domain, so you are just assuming its a large network with lots of switches. Anything past 30 - 40 switches I wouldn't really consider running with this config anyway. There are more better, efficient ways of getting around this.

Out thoughts differ, so we should leave it at that. I know how I would do it thats for sure

Please rate useful posts & remember to mark any solved questions as answered. Thank you.

[paul driver]

Hello Bilal

"I had 100+ switches - you should be asking a separate question, the design of a network would be something totally different, I would not run with VTP client server relationship at all, everything would be transparent. "

For discussion sake why would you do this - what if there was a future requirement for additional vlans?

Res
Paul



Sent from Cisco Technical Support iPad App

[Bilal Nawaz]

I didn't say I would though :-/ Like I said, I wouldn't have VTP client/server relationship with 100+ switches. Are you telling me you would run 100+ switches in VTP client server modes. You practically have a risk of wiping out your entire domain. Bigger your domain, the more impact there is.

I've seen many large world wide enterprise networks in my very short career, only running transparent, why? They can't be bothered with the risk. Especially with financial institutions.

If you want to know what I would do in that case...

All transparent, or Layer 3 at the access layer.

Please rate useful posts & remember to mark any solved questions as answered. Thank you.

[Jose Solano]

Hi,

I would say that your access switches are not receiving any updates from the server switch. Also the switches will update the vlan database when they received an advertisement with a higher revision number.

I would suggest to make this changes during change window to avoid any issues.

Regards,

Sent from Cisco Technical Support iPhone App