VTP Bug?

[dsdd]

Hello everyone I believe there might be a bug in the Cisco Learning Labs VTP Lab (I went beyond the scope of the lab after finishing), but I wanted to verify my thoughts with everyone before moving on with filing documentation of the issue to assure my logic is sound.

I have the following setup

Here are the following configurations:

Switch1(config)#do sh vtp status
VTP Version capable             : 1 to 3
VTP version running             : 3
VTP Domain Name                 : CCNP
VTP Pruning Mode                : Disabled
VTP Traps Generation            : Disabled
Device ID                       : aabb.cc00.0200

Feature VLAN:
--------------
VTP Operating Mode                : Server
Number of existing VLANs          : 15
Number of existing extended VLANs : 0
Maximum VLANs supported locally   : 4096
Configuration Revision            : 6
Primary ID                        : aabb.cc00.0200
Primary Description               : Switch1
MD5 digest                        : 0x0B 0x76 0x80 0x87 0x2C 0xEA 0x0F 0x68
                                    0xFB 0xE1 0xD0 0x1D 0xEF 0xA6 0x7C 0x23

Switch2#sh vtp status
VTP Version capable : 1 to 3
VTP version running : 1
VTP Domain Name : CCNP
VTP Pruning Mode : Disabled
VTP Traps Generation : Disabled
Device ID : aabb.cc00.0d00
Configuration last modified by 0.0.0.0 at 10-25-17 20:31:29

Feature VLAN:
--------------
VTP Operating Mode : Transparent
Maximum VLANs supported locally : 1005
Number of existing VLANs : 6
Configuration Revision : 0
MD5 digest : 0x3A 0x1C 0x0E 0xBC 0x15 0x0F 0x09 0x93
 0xC8 0x12 0x44 0xF0 0xBD 0x20 0x08 0xFE

Switch3(config)#do sh vtp status
VTP Version capable             : 1 to 3
VTP version running             : 2
VTP Domain Name                 : CCNP
VTP Pruning Mode                : Disabled
VTP Traps Generation            : Disabled
Device ID                       : aabb.cc00.3b00
Configuration last modified by 0.0.0.0 at 10-25-17 21:35:03

Feature VLAN:
--------------
VTP Operating Mode                : Client
Maximum VLANs supported locally   : 1005
Number of existing VLANs          : 5
Configuration Revision            : 0
MD5 digest                        : 0x5E 0x16 0x5E 0x7B 0x7B 0x58 0xC6 0xD5
                                    0x39 0xDA 0xD3 0x3F 0x31 0xC1 0xFF 0x5B

Despite making various different new vlans on switch 1, I am not seeing them propagate into the switch3 vlan.dat and keep recieving the following message:

Switch3#
*Oct 25 21:54:09.934: VTP LOG RUNTIME: Incoming packet version rcvd 3 unknown

Switch 2 is relaying the  VTP information to Switch 3 despite being in transparent mode and being set to version 1 without explicitly showing in #sh vtp status as being v2 auto upgraded (not sure if it is suppose to.

Switch2#
*Oct 25 21:54:09.934: VTP LOG RUNTIME: Relaying packet received on trunk Et0/1 - in TRANSPARENT MODE (nc = false)

so somewhere between Switch 2 and 3 exists a problem. I feel I have covered VTP very thoughly in my studies yet for whatever reason I cant seem to figure out why the receiving switch isnt processing the subset advertisement properly and making changes to its vlan.dat.

Any help would be appreciated.

Thanks, Adam 

[Meheretab Mengistu]

Hi,

Please share the output of "sh vtp password", "sh vlan bri" and "sh int trunk" from the switches.

HTH,
Meheretab

[dsdd]

There was no password and sadly I cant get access to it now. But is my logic wrong as to why it should work?

[Joseph W. Doherty]

Your switches are running different VTP versions. Insure they are all running the same VTP version.

[dsdd]

I'm afraid you are missing the point of this post. This is all based on white page approved VTP information. I'm trying to make it work with the current setup for the corner cases that I am implementing in this scenario. I already changed all the versions to the same and it worked just fine, but this is testing the limitations of VTP for learning reasons.

[Joseph W. Doherty]

Ah, you didn't make that clear in your OP.

Do you have a reference to the whitepaper that describes mixing all 3 VTP versions in a way that they will inter-operate?

[dsdd]

"The functional base in VTP version 3 is left unchanged from VTP version 2, so backward compatibility is built in. It is possible, on a per link basis, to automatically discover and support VTP version 2 devices."

"Version-Dependent Transparent Mode—In VTP version 1, a VTP transparent switch inspects VTP messages for the domain name and version and forwards a message only if the version and domain name match. Because VTP version 2 supports only one domain, it ...

"If a switch running VTP version 1 but capable of running VTP version 2 receives VTP version 3 advertisements, it automatically moves to VTP version 2."

Following quotes in same link as above ^

"If a switch running VTP version 3 is connected to a switch running VTP version 1, the VTP version 1 switch moves to VTP version 2, and the VTP version 3 switch sends scaled-down versions of the VTP packets so that the VTP version 2 switch can update its database."

"When a VTP version 3 device detects a VTP version 2 device on a trunk port, it continues to send VTP version 3 packets, in addition to VTP version 2 packets, to allow both kinds of neighbors to coexist on the same trunk."

But upon searching further I finally answered my own question I believe, "A VTP version 3 device does not accept configuration information from a VTP version 2 or version 1 device". It seems that only when the v3 devices are sending subset advertisements that it works, but not upon receiving.  

[paul driver]

Hello

"A VTP version 3 device does not accept configuration information from a VTP version 2 or version 1 device"

Doesn't it state in your white paper vtp 2 is compatible with vtp 3?

The functional base in VTP version 3 is left unchanged from VTP version 2, so backward compatibility is built in. It is possible, on a per link basis, to automatically discover and support VTP version 2 devices."

However its recommended to use the same vtp version throughout your vtp domain and then if you need to troubleshoot issues relating to vtp its one thing is indeed to check would be vtp mistmatch.

res
Paul

[dsdd]

"It seems that only when the v3 devices are sending subset advertisements that it works, but not upon receiving.  "

[paul driver]

Hello

My understanding is a subset advertisement sent to a VTP3 Primary server wont have any effect -As the server wont except any changes.

Only the VTP3 primary server is allowed to make the changes, this is one for the differences in vtp3 rather than in vtp 1/2 is that a client/server CANNOT makes changes to the vtp D/B , in vtp3 ONLY a Primary server can perform this function

res
PAul

[dsdd]

Please refer to the OP above, and the following quote.

"Also on SW1 it doesn't allow you to create new vlan's unless you enter the

SW1# vtp primary force

so it has already been done prior to this posting."

So to summarize

SW1 is v3 Primary Server 

SW2 is v1 (moved to v2) Transparent 

SW3 is v3 Client 

[paul driver]

Hello

Okay didn't see that or misread it- however going back to that OP and all the recommendations that followed it suggesting to make ALL switches run the same vtp ver are still valid and it also confirmed it wasnt a BUG you were seeing but incompatibility between vtp versions

res

Paul

[Joseph W. Doherty]

Thanks for the reference.

As you've found your own answer, plus there's Paul's responses, I think there's nothing more I could add.

[paul driver]

Hello

Switch 2 vtp 1 - switch 3 vtp 2 are not compatible within the same domain

To allow propagation:

Switch 1
vtp primary force

Switch 2/3
vtp ver 3

res
Paul

[dsdd]

Correct me if I am wrong here, but SW2 is in v1 Transparent mode but since the device is v3 capable it should auto upgraded its version to v2. Which will then allow it to communicate with SW3, the v3 Client device will accept the relayed subset advertisement since the v3 is backwards compatible.

Also on SW1 it doesn't allow you to create new vlan's unless you enter the

SW1# vtp primary force

so it has already been done prior to this posting.