VTP3 interoperability with VTP2 in the same domain

[willsmith1701]

I'm trying to determine the best way to implement extended vlans in a network where all of the devices will not immediately support

vtp3.  We do not need extended vlans campus wide, but only on the head of stack device in each closet of each building. These head of

stack switches will be 3850's used as wireless access controllers.  The extended vlans will be for the building wireless networks.

(the purchase of a 5760 is deferred until next year, so this is an interim wireless configuration). The majority of the switches in

the network are vtp2 capable, but all are running in vtp1 mode because of a handful (maybe 5) that are vtp 1 only capable.  These

5 will be removed from the network in the near future. 

The VTP3 docs seem counterdictory.  They seem to imply that VTP3 and VTP2 are interoperable, and that

vtp 2 switches will accept configuration changes from a vtp 3 primary server. (I know the reverse is not true and do not need that). But then the same doc explicitly states that all devices in the same domain have to run the same vtp version.  So which is true?  Can the core switch and

the connecting 3850's run vtp3 with the extended vlan ranges, while the rest of the network switches remain at version 2, with the

version 2 switches able to accept configuration changes for vlans 1-1005 from the version 3 primary vtp switch?  Also, if the vtp

version 2 core switch is converted to vtp3, will the configuration version be reset to 0? If  vtp version 2 and 3 are not interoperable as just described, then how do we get the extended range higher number vlans in the network? 

Would vtp transparent be an option?  But then wouldn't the core switch, as well as the rest of the switches in the network, have to

be configured as transparent as well? And if the core switch (a 6509E running 12.2(17r)SX7) is converted from vtp 2 to transparent,

will it retain the existing version 2 vlan database, or will all of the vlans need to be reconfigured on the switch?

What is the best way to implement extended vlans in the situation?

Please ask questions if you need more information to respond.

[nranjha01]

Will, did you find a solution for the above then?

[swtechsupp]

I know this thread is old, but in case you arrive here and are curious I have just worked on this in a mini lab and plan to check this into production. Lab consisted of the following;

1xWS-C3750V2-24PS (yes its old J) “flash:/c3750-ipbasek9-mz.122-55.SE10/c3750-ipbasek9-mz.122-55.SE10.bin” – Root Bridge Core Switch.

1xWS-C3750-24P same code revision as above.

Both switches connected via single uplink configured for dot1q trunk mode on!

1 x WS-C3550-48 System image file is "flash:c3550-i9q3l2-mz.121-22.EA1a/c3550-i9q3l2-mz.121-22.EA1a.bin" This again was connected back to the root bridge C3750V2

So began with VTP2 topology throughout

Root Bridge Switch VTP Server all the rest running as clients. Note I was not using any passwords for VTP! Created a few VLANs in VTP2 range. All good revision numbers updated and could see the VLANs on each switch.

Then went ahead and set Root Bridge to version VTP3 making it the primary. (not sure you can have two primary server like the old days or if you can elect a secondary.. . need to stage this a little more, but no time!, plus will be running a stack in production so have the fault tolorance anyway.

So far to good set the other 3750 running the same code revision to VTP version 3 all OK.

Now this is when I noticed the revision number step down. Which is fine. I when back on to the primary created another vlan in the vtp2 range (non extended) and one in the VTP3 range and the VTP3 update reached the VTP3 client, but not the old 3550 L. I was interested about connectivity during the transition and had a PC connect on this switch which I was pinging form the C3750 edge (not the root) and no dropped pings. . . . , but I Segway a little. On the 3550 (which cannot support VTP3 with the current revision) the recent non extended range vlan that I created didn’t update the VTP2 client instance. Why? I looked at the revision number and it was higher than the VTP3 instance.

The only way round this was to change the VTP domain name (resets to 0 note that it’s still in client mode BTW!) then change it back again to the same domain name as the primary and whack I got the vlan update from VTP3 -> VTP2 and revision numbers back insync. Hope this helps.

Note that I got this error during the rename %DTP-5-DOMAINMISMATCH: Unable to perform trunk negotiation on port Fa1/0/23 because of VTP domain mismatch <- I did not lose connectivity during this event, but FYI.

My use case.. . is extending Layer 2 VLAN to another Data Centre (BCS site) ensuring no clash. I like to use the 3rd octect in the subnet for the VLAN id so where there is an overlap 10.64.103.x (VLAN-103) between production BCS 10.128.103.x (2103) I can use a higher number range.