VTP 3 updates config revision but vlans don't appear
-
Im resumitting the vlan data in brief form... sorry
Here is the server:C1.1#show vlan br
VLAN Name Status Ports
1 default active Gi0/1, Gi0/26, Gi0/28
100 DATA active Gi0/3, Gi0/5, Gi0/6, Gi0/7
Gi0/8, Gi0/9, Gi0/10, Gi0/11
Gi0/12, Gi0/13, Gi0/14, Gi0/15
Gi0/16, Gi0/17, Gi0/18, Gi0/19
Gi0/20, Gi0/22, Gi0/23, Gi0/24
Gi0/25
101 GUEST active Gi0/2
102 VOICE active Gi0/5, Gi0/6, Gi0/7, Gi0/8
Gi0/9, Gi0/10, Gi0/11, Gi0/12
Gi0/13, Gi0/14, Gi0/15, Gi0/16
Gi0/17, Gi0/18, Gi0/19, Gi0/20
Gi0/21, Gi0/22, Gi0/23, Gi0/24
1002 fddi-default act/unsup
1003 trcrf-default act/unsup
1004 fddinet-default act/unsup
1005 trbrf-default act/unsupHere is the problem client:
E2.128#show vlan br
VLAN Name Status Ports
1 default active Gi0/50, Gi0/51, Gi0/52
100 VLAN0100 active Gi0/1, Gi0/2, Gi0/3, Gi0/4
Gi0/5, Gi0/6, Gi0/7, Gi0/8
Gi0/9, Gi0/10, Gi0/11, Gi0/12
Gi0/13, Gi0/14, Gi0/15, Gi0/16
Gi0/17, Gi0/18, Gi0/19, Gi0/20
Gi0/21, Gi0/22, Gi0/23, Gi0/24
Gi0/25, Gi0/26, Gi0/27, Gi0/28
Gi0/29, Gi0/30, Gi0/31, Gi0/32
Gi0/33, Gi0/34, Gi0/35, Gi0/36
Gi0/37, Gi0/39, Gi0/40, Gi0/41
Gi0/42, Gi0/43, Gi0/44, Gi0/45
Gi0/46, Gi0/47, Gi0/48
1002 fddi-default act/unsup
1003 trcrf-default act/unsup
1004 fddinet-default act/unsup
1005 trbrf-default act/unsup -
Your domain name looks good on both
I think your password may not be matching on your switches.Please issue:
show vtp passwordto compare passwords on both of the switches. If different, change to the one you want. If they match, I would remove the passwords then set them again.
After that. on the vtp server, issuevtp mode server vtp primary force vtp primary vlan forceFinally, Create a test vlan on vtp server...check to see if vlan propagates.
-
The passwords are hidden, but the encrypted versions matched.
If the passwords didn't match, I don't think the VTP revision would stay in sync and it does.
In any case, I removed the passwords and reset them to no avail.
I reset the the server mode and followed it with the force commands again to no avail.
I added a new vlan on the server. It appeared on the server, it appeared on other switches. It did NOT appear on the problem switch.I removed the passwords again on both server and client then added another test vlan It acted exactly the same. It shows me the proper revision but no vlans change on the client.
We cleared the switches configuration back to factory new and reloaded our config file in an attempt to see what's wrong. It made no difference. The config file matches other switches that are working... at least I can't see any difference to speak of. I'm beginning to think this switch is defective although that doesn't make a lot of sense.
-
This is certainly bizarre, The "normal" issues like password mismatches, trunk problems, and domain mismatches do not appear to apply. Is the problem switch running the same IOS code release? I wonder what happens if we drop all switches back to VTP Version 2?
-
I went with version 3 because it allows me to hide the password. Version 2 doesnt support that. But, as a test I can certainly try. I thought there was a restriction on going back to version two from version 3. Perhaps not. I’ll give it a go.
-
The three switches I have been using for this testing are running exactly the same ios version as seen below:
The Server is running...
C1.1#show ver
Cisco IOS Software, C3560 Software (C3560-IPSERVICESK9-M), Version 12.2(55)SE12, RELEASE SOFTWARE (fc2)The client that is working fine is running...
C1.89#show ver
Cisco IOS Software, C3560 Software (C3560-IPSERVICESK9-M), Version 12.2(55)SE12, RELEASE SOFTWARE (fc2)The client with the issues is running...
E2.128#show ver
Cisco IOS Software, C3560 Software (C3560-IPSERVICESK9-M), Version 12.2(55)SE12, RELEASE SOFTWARE (fc2)I tried dropping the switches back to version 2 and nothing seemed to work. I suspect this could be because there are a couple of switches between the server and the two clients I'm working with.... I can't be sure. I'll play with it a bit more tomorrow. I don't have a network map and don't want to recreate it tonight.
-
Great idea to find out if there are non VTP switches in between the ones you listed!
-
They are all set to the same VTP version 3 settings. They are all properly responding with the sole exception of the problem switch. I just wasn’t sure if having them in the chain would prevent version 2 BPDUs from properly propagating along the version 3 chain.
-
I changed the problem switch as well as the one adjacent it to version 2. I set the adjacent switch to server mode and they seemed to operate properly. I could add/remove vlans on the server and the problem switch reacted properly to the changes. I changed them back to version 3 and now they won't talk to me. I suspect I lost a vlan or two on each. I'm going to get a console cable and fix the problem. Different building and it's 32 deg and nasty outside. Yuck!
-
Well, you're gonna love this one. I got a wild hair and decided to change the problem switch to server mode. When I did, it started working properly. I added a vlan to the primary server and it showed up on the problem switch. I then removed the vlan and it disappeared fro the problem switch. Now for the weird part... I changed it back to client mode and it still works properly. I added and removed a couple of vlans on the primary server to convince myself that it is working and the changes were always echoed on the problem switch.
I have no idea why this worked but it did. So I'd say my problem is solved.
-
Great way to work through the problem! I just found the same solution online:
https://castroaa.blogspot.com/2016/10/troubleshooting-vtp-version-3.html
-
ROFL.. .timely. <g>
I can't find how to mark this as solved??? -
It's ok it didn't post as question....I'll try and change that when I figure out how to get posted as question! Glad you're a member!
Just changed, it... so if you look in the lower right corner...you'll see
Topic Tools. that 's a drop down list that will allow you to mark this as solved.
