VTP v3

VTP v3 isn't technically a "new addition" to the CCIE lab, but code versions prohibited it from being used up until recently. I've been told IOL does in fact support VTP v3, so it should be considered a viable lab topic now.

So what's new in VTP v3?  In no particular order:

- Supports extended VLANs (1006 - 4094)
- Support for propagating Private VLANs
- Support for propagating Multiple Spanning Tree
- Support for flagging VLANs as RSPAN (disables MAC learning on the VLAN)
- Fixes the bane of VTP v1/2, the accidental-high-configuration-revision-wipes-out-your-network issue.
- VTP can now be turned off completely, as opposed to just transparent mode
- Support for hidden passwords

My lab is two 3560s running 15.0(2)SE6, and one 3550 running 12.x code. The 3560s support VTP v3, the 3550 I'm just using to show backwards compatibility to v2.

My switches are plugged in in a row:

SW1 3560 --> SW2 3560 --> SW3 3550

Let's enable v3 on SW1 and SW2:

SW1(config)#vtp version 3
Cannot set the version to 3 because domain name is not configured

You can't enable v3 without specifying a domain. Previous versions of VTP just inherited the domain name from its neighbors if you didn't specify one. This ties in some to the security measures, we don't necessarily want to participate in the neighbor's VTP process, so don't make assumptions.

SW1(config)#vtp domain CCIE
Changing VTP domain name from NULL to CCIE
*Mar  1 00:04:08.638: %SW_VLAN-6-VTP_DOMAIN_NAME_CHG: VTP domain name changed to CCIE.
SW1(config)#vtp version 3
*Mar  1 00:04:12.908: %SW_VLAN-6-OLD_CONFIG_FILE_READ: Old version 2 VLAN configuration file detected and read OK.  Version 3
    files will be written in the future.

I've done the same on SW2.

Let's try adding some VLANs.

SW1(config)#vtp mode server
Setting device to VTP Server mode for VLANS.
SW1(config)#vlan 100
VTP VLAN configuration not allowed when device is not the primary server for vlan database.

Let's stop here and talk about a huge problem with previous versions of VTP. As a network consultant, I always recommend - especially prior to version 3 - that customers use VTP mode transparent. The problem is that VTP devices - VTP clients included - can have their VLANs removed or changed while not connected to the mothership, and inadvertently end up with a higher configuration revision. When that switch is introduced, or reintroduced, to the greater network, the higher configuration revision "wins", and the rest of the network replicates that VLAN database, erasing their own VLANs. This can be so dramatic that the entire network can end up with just VLAN 1, and the entire layer 2 domain goes down. This is a very easy problem to create, and causes a dramatic outage.

VTPv3 can no longer create this issue.

VTP mode clients, and secondary servers cannot write the VLAN database. What's a secondary server? Well, it's any server that isn't the primary! (sorry, couldn't resist).

There can only be one primary server. The primary server is the only server allowed to write the VLAN database:

SW1#vtp primary vlan

This system is becoming primary server for feature vlan

No conflicting VTP3 devices found.

Do you want to continue? [confirm]

SW1#

*Mar  1 00:30:19.564: %SW_VLAN-4-VTP_PRIMARY_SERVER_CHG: 0014.1ceb.f600 has become the primary server for the VLAN VTP feature

SW1 is now the only device that can make changes to the contiguous v3 PVST VLAN database. Note the command vtp primary vlan is in privilege exec mode and is not saved to the config - if you reboot you lose this privilege. This completely eliminates the possibility of have a plug-and-play way of accidentally overwriting another network's VTP database.

SW1#conf t

Enter configuration commands, one per line.  End with CNTL/Z.

SW1(config)#vlan 100

SW1(config-vlan)#exit

SW2#show vlan | i 100

100  VLAN0100                         active

<output omitted for brevity>

I'd like to spend a moment looking at the primary server takeover process in a little more detail.

As I mentioned, only one server can be primary.

So if we do this from SW2:

SW2#vtp primary vlan

This system is becoming primary server for feature vlan

No conflicting VTP3 devices found.

Do you want to continue? [confirm]

SW2#

*Mar  1 00:52:46.632: %SW_VLAN-4-VTP_PRIMARY_SERVER_CHG: 0014.1cec.0280 has become the primary server for the VLAN VTP feature

So I'm confused by "No conflicted VTP3 devices found." I'm not sure what a conflicting server would be if not the existing primary server, but my switches always produce this output, so maybe it's a version/platform issue.

Anyway, if you look at SW1:

SW1(config)#

*Mar  1 00:53:36.963: %SW_VLAN-4-VTP_PRIMARY_SERVER_CHG: 0014.1cec.0280 has become the primary server for the VLAN VTP feature

SW1#show vtp status

VTP Version capable             : 1 to 3

VTP version running             : 3

VTP Domain Name                 : CCIE

VTP Pruning Mode                : Disabled

VTP Traps Generation            : Disabled

Device ID                       : 0014.1ceb.f600

Feature VLAN:

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

VTP Operating Mode                : Server

Number of existing VLANs          : 6

Number of existing extended VLANs : 0

Maximum VLANs supported locally   : 1005

Configuration Revision            : 2

Primary ID                        : 0014.1cec.0280

Primary Description               : SW2

MD5 digest                        : 0x73 0x33 0x29 0x15 0x3B 0xA7 0x29 0x04

                                    0x74 0x34 0x70 0x4F 0x58 0x74 0xAF 0x5E

Feature MST:

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

VTP Operating Mode                : Transparent

Feature UNKNOWN:

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

VTP Operating Mode                : Transparent

Note the Device ID -  0014.1ceb.f600, and then the Primary ID of  Feature VLAN - 0014.1cec.0280 (SW2's ID). SW2 just stole it from SW1. 

It's hard to show in the blog, but the process of becoming primary actually takes a little bit. There's a quicker way to steal it, which "doesn't check for conflicting devices" (not that I can seem to find conflicting devices anyway):

SW1#vtp primary vlan force

This system is becoming primary server for feature vlan

SW1#

*Mar  1 00:59:32.112: %SW_VLAN-4-VTP_PRIMARY_SERVER_CHG: 0014.1ceb.f600 has become the primary server for the VLAN VTP feature

While I'm on the topic, you can actually see your VTP neighbors now (provided they're running v3):

SW1#show vtp device

Retrieving information from the VTP domain. Waiting for 5 seconds.

VTP Feature  Conf Revision Primary Server Device ID      Device Description

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

VLAN         No   2        0014.1ceb.f600 0014.1cec.0280 SW2

Let's try to add some high-number VLANs now.

On the primary:

SW1(config)#vlan 1006

SW1(config-vlan)#exit

On the secondary, verifying

SW2#show vlan | i 1006

1006 VLAN1006                         active

<output omitted for brevity>

Let's make a routed port on the secondary (an SVI would work as well):

SW2(config)#int fa0/1

SW2(config-if)#no switchport

SW2(config-if)#ip address 192.168.0.1 255.255.255.0

Adding another VLAN on the primary:

SW1(config)#vlan 1007

SW1(config-vlan)#exit

And verifying on the secondary:

SW2(config-if)#

*Mar  1 01:04:07.384: %PM-4-EXT_VLAN_INUSE: VLAN 1007 currently in use by FastEthernet0/1

*Mar  1 01:04:07.384: %SW_VLAN-4-VLAN_CREATE_FAIL: Failed to create VLANs 1007: VLAN(s) not available in Port Manager

Well that didn't work.

Whenever you create a routed interface (SVI or interface-based) on a Catalyst switch, it assigns a VLAN between the routed interface and the control plane (best I can tell, that's what's happening...). I've heard an argument that this behavior has to do with allocating the BIA MAC addresses to routed interfaces, but if you look around, there are some Catalyst switches that just assign the same MAC to every routed interface by default, yet they still all use separate VLAN numbers, so I'm not inclined to believe that.

Anyway, the default behavior on my 3560s is to allocate these VLANs from 1006 and counting upwards, so if 1006 is in use, 1007 will be grabbed, which is what we just saw.  

vlan internal allocation policy ascending

You've seen this command if you've used a 3K series switch before, because you can't turn it off.

SW1#sh run | i ascen

vlan internal allocation policy ascending

SW1#conf t

Enter configuration commands, one per line.  End with CNTL/Z.

SW1(config)#no vlan internal allocation policy ascending

SW1(config)#do sh run | i ascend

vlan internal allocation policy ascending

SW1(config)#vlan internal allocation policy ?

  ascending  Allocate internal VLAN in ascending order

SW1(config)#vlan internal allocation policy ascending ?

  <cr>

SW1(config)#vlan internal allocation policy ascending

So, tough luck, they're ascending!  

Some higher-end platforms support descending, I don't have one sitting around to lab, but I'm told descending starts at 4094 and counts downward instead.

Back to reality on my 3560s...

SW2#show vlan internal usage

VLAN Usage

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

1007 FastEthernet0/1

Shutting down Fa0/1 releases Vlan 1007, but we're now out-of-sync. I let this sit a while and it never caught up, so I'm guessing you're just out of luck until the primary server pushes another update.

SW2(config)#int fa0/1

SW2(config-if)#shut

SW1(config)#no vlan 1007

SW1(config)#vlan 1007

SW1(config-vlan)#exit

SW2(config-if)#do show vlan | i 1007

1007 VLAN1007                         active

<output omitted>

So we've covered the primary VTP server, exactly what is the difference between a secondary VTP server and a VTP client?

Well, on the 3560, not much.

According to the VTPv3 documentation:

"Client: A device using a local temporary storage space (for example, DRAM) to hold via VTP received information for runtime use. This information is used to update other devices, such as a device that is working as a server. Local configuration of devices in the client role is not possible. After booting, a client device issues a VTP message asking for the configuration of other VTP devices."

This implies that the VTP secondary server saves its database to flash and the client doesn't store it at all. And on the 3560? My VTP clients (and secondary servers) store the full VTP database and will load it up every time unless I manually delete it. So in practice, on this equipment, I can't actually find a difference between VTP secondary servers and VTP clients.

I'm told a best practice is to demote the primary vtp server when you're done making changes. The method to accomplish that is not particularly clear, but here you have it:

SW1(config)#vtp mode client

Setting device to VTP Client mode for VLANS.

SW1(config)#vtp mode server

Setting device to VTP Server mode for VLANS.

Now you're a secondary server.

Let's take a look at the new password features. The old, plain-text password still works the same way. The hidden ones, however:

SW1(config)#vtp password CANTSEEME hidden

Setting device VTP password

SW1#show vtp password

VTP Password: 80B0218C160CD951A38982EECCC22AD5

There's apparently no way to recover it, even snooping through the vlan.dat file, so if you need to add a switch without giving the password out:

SW2(config)#vtp password 80B0218C160CD951A38982EECCC22AD5 secret

Setting device VTP password

Of note, the password is required (the unencrypted one) in order to promote a server to primary:

SW1#vtp primary vlan

This system is becoming primary server for feature vlan

Enter VTP Password:

How about interoperability with previous versions?

Previous version switches will promote themselves from v1 to v2 if connected to a v3 device:

Prior to talking to SW2:

SW3#show vtp status

VTP Version                     : running VTP1 (VTP2 capable)

Configuration Revision          : 0

Maximum VLANs supported locally : 1005

Number of existing VLANs        : 5

VTP Operating Mode              : Server

VTP Domain Name                 :

VTP Pruning Mode                : Disabled

VTP V2 Mode                     : Disabled

VTP Traps Generation            : Disabled

MD5 digest                      : 0x57 0xCD 0x40 0x65 0x63 0x59 0x47 0xBD

Configuration last modified by 0.0.0.0 at 0-0-00 00:00:00

Local updater ID is 0.0.0.0 (no valid interface found)

After talking to SW2:

SW3#show vtp status

VTP Version                     : running VTP2

Configuration Revision          : 1

Maximum VLANs supported locally : 1005

Number of existing VLANs        : 7

VTP Operating Mode              : Server

VTP Domain Name                 : CCIE

VTP Pruning Mode                : Disabled

VTP V2 Mode                     : Enabled

VTP Traps Generation            : Disabled

MD5 digest                      : 0x60 0xEC 0xC1 0xEF 0xEF 0xE3 0x24 0xB6

Configuration last modified by 0.0.0.0 at 3-1-93 00:00:58

Local updater ID is 0.0.0.0 (no valid interface found)

Note the automatic V2 change. I actually had a heck of a time getting this working when I re-labbed it for this document, and that's because I had left a hidden password on SW1 and SW2. VTPv1/2 aren't going to speak hidden password, turn that off first!

The important thing to grasp about the v2 compatibility is this must be a one-way path: The v3 network needs to make the database changes. It's best to keep the entire v2 domain as clients. If you make changes in v2, the v3 devices will not accept the changes, but the v2 domain will up its configuration revision number. Then when v3 pushes a legitimate update, the v2 domain will reject it because it will by definition be lower than that of v2.  You end up with a segmented VTP domain, and a royal mess in the v2 network:

*Mar  1 06:17:23.646: %SW_VLAN-4-VTP_USER_NOTIFICATION: VTP protocol user notification: MD5 digest checksum mismatch on receipt of equal revision summary on trunk: Fa0/21

*Mar  1 06:17:23.650: %SW_VLAN-4-VTP_USER_NOTIFICATION: VTP protocol user notification: MD5 digest checksum mismatch on  receipt of equal revision summary on trunk: Fa0/22

Disabling VTP: Why?

Most of us have been happy to use transparent for years. The big difference with disabling VTP as opposed to using transparent mode is that the switch won't even pass VTP messages in "off" mode, it deliberately filters them. The benefit would be for a network administrative boundary, like connecting trunks between two carriers.

Globally:

SW2(config)#vtp mode off

Setting device to VTP Off mode for VLANS.

Per interface:

SW2(config)#int fa0/21

SW2(config-if)#no vtp

The Private VLAN support sounds daunting, but it really does a very simple task. All it does is carry the VLAN associations, it's not assigning interface or trunk configs anywhere.

SW1(config-vlan)#vlan 601

SW1(config-vlan)#  private-vlan isolated

SW1(config-vlan)#

SW1(config-vlan)#vlan 600

SW1(config-vlan)#  private-vlan primary

SW1(config-vlan)#  private-vlan association 601

It doesn't matter where I trunk this, or what ports are applied in what fashion. This is basically all we're replicating:

SW1#show vlan private-vlan

Primary Secondary Type              Ports

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

600     601       isolated

SW2#show vlan private-vlan

Primary Secondary Type              Ports

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

600     601       isolated          Fa0/6

Of note, and this will make more sense as we move into MST, the private-vlan feature is an add-on to the "VLAN" feature, which you may have noticed inside the show vtp status output:

SW1#show vtp status

VTP Version capable             : 1 to 3

VTP version running             : 3

VTP Domain Name                 : CCIE

VTP Pruning Mode                : Disabled

VTP Traps Generation            : Disabled

Device ID                       : 0014.1ceb.f600

Feature VLAN:

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

VTP Operating Mode                : Primary Server

Number of existing VLANs          : 9

Number of existing extended VLANs : 2

Maximum VLANs supported locally   : 1005

Configuration Revision            : 3

Primary ID                        : 0014.1ceb.f600

Primary Description               : SW1

MD5 digest                        : 0xBE 0x75 0xED 0x56 0xCB 0xAF 0xF3 0xF6

                                    0x59 0x8D 0x91 0x6C 0x60 0x28 0x55 0xEB

Feature MST:

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

VTP Operating Mode                : Transparent

Feature UNKNOWN:

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

VTP Operating Mode                : Transparent

Now let's talk about those last two, Feature MST and Feature UNKNOWN.

The MST config is pretty cool. If you choose to run MST, the big drag is the manual configuration updates, and this fixes all of them.

Just as with feature VLAN, we need to make a primary server for MST. Note, this does not have to be the same switch as the feature VLAN. In fact, I'm leaving SW1 the primary for feature VLAN, and making SW2 the primary for feature MST:

SW2(config)#vtp mode server mst

Setting device to VTP Server mode for MST.

SW2(config)#exit

SW2#vtp primary mst force

This system is becoming primary server for feature  mst

SW2#

*Mar  1 00:17:26.453: %SW_VLAN-4-VTP_PRIMARY_SERVER_CHG: 0014.1cec.0280 has become the primary server for the MST VTP feature

Feature VLAN:

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

VTP Operating Mode                : Server

Number of existing VLANs          : 9

Number of existing extended VLANs : 2

Maximum VLANs supported locally   : 1005

Configuration Revision            : 3

Primary ID                        : 0014.1ceb.f600

Primary Description               : SW1

MD5 digest                        : 0xBE 0x75 0xED 0x56 0xCB 0xAF 0xF3 0xF6

                                    0x59 0x8D 0x91 0x6C 0x60 0x28 0x55 0xEB

Feature MST:

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

VTP Operating Mode                : Primary Server

Configuration Revision            : 1

Primary ID                        : 0014.1cec.0280

Primary Description               : SW2

<output omitted for brevity>

SW1(config)#vtp mode client mst

Setting device to VTP Client mode for MST.

SW2(config)#spanning-tree mst config

SW2(config-mst)#instance 1 vlan 1-100

SW2(config-mst)#instance 2 vlan 101-200

SW2(config-mst)#instance 3 vlan 201-300

SW2(config-mst)#name region1

SW2(config-mst)#revision 1

SW2(config-mst)#exit

SW2(config)#spanning-tree mode mst

SW2#show spanning-tree mst config

Name      [region1]

Revision  1     Instances configured 4

Instance  Vlans mapped

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

0         301-4094

1         1-100

2         101-200

3         201-300

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

Enable MST on SW1:

SW1(config)#spanning-tree mode mst

And we'll see it has the configuration already:

SW1#show span mst config

Name      [region1]

Revision  1     Instances configured 4

Instance  Vlans mapped

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

0         301-4094

1         1-100

2         101-200

3         201-300

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

Another nifty thing is that it actually updates the running config to match:

SW1#show run | s spanning-tree mst

spanning-tree mst configuration

 name region1

 revision 1

 instance 1 vlan 1-100

 instance 2 vlan 101-200

 instance 3 vlan 201-300

Reverting to PVST for simplicity --

SW1(config)#spanning-tree mode rapid-pvst

SW2(config)#spanning-tree mode rapid-pvst

The Remote SPAN flag is quite simple:

SW1(config)#vlan 150

SW1(config-vlan)#remote-span

SW2#show vlan remote-span

Remote SPAN VLANs

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

150

The purpose here is to tell all the switches in the forwarding path of the remote SPAN not to learn MAC addresses on that VLAN.

Feature UNKNOWN is actually kinda cool too, although I have no way of demonstrating it. VTPv3 is designed to carry different types of databases, so that it can be adapted to other replication tasks in the future. So what's an earlier VTPv3 IOS to do with these new formats it doesn't understand? Forward them or drop them?

SW1(config)#vtp mode off unknown

Setting device to VTP Off mode for unknown instances.

SW1(config)#vtp mode transparent unknown

Setting device to VTP Transparent mode for unknown instances.

You can set them only to off or transparent. Clearly can't be a VTP server for a format you don't understand.  off works the same way explained above, drop the traffic; transparent forwards without processing.

And lastly, where's this at in the DocCD?:

Switches -> 

3850 -> 

Catalyst 3850-12S-E Switch -> 

Configuration Guides -> 

VLAN Configuration Guide, Cisco IOS XE Release 3SE (Catalyst 3850 Switches) ->

Configuring VTP

v3 is just a section in the larger VTP configuration guide, but everything you need should be there.

Cheers,

Jeff