SWITCH 300-115 1.4 Configure and verify trunking

1.4.a VTPv1, VTPv2, VTPv3, VTP pruning

1.4.d Manual pruning

Before I get to manual pruning, VTP version 3 deserves a mention.

VTP version 3 comes with a bit of an upgrade that sets itself apart from earlier versions, to wit:

Version 3 now supports extended range vlans and private vlans.
The vtp database can support other formats, ie, MST.
Precautions against database hijacking, ie, inserting a switch with a higher revision number
   can’t whack the existing database because only the primary vtp domain server may make
Hidden and secret passwords are available, not just plain text
Version 3 can be configured per port instead of only globally as in earlier versions.

Version 3  offers optimized resource handling and more efficient information transfer, whatever that means. (Sounds like marketing)

Let’s look at vtp version 3.

From enable mode make the vtp server the primary vtp server. See below:
Then continue as for the earlier versions, except for the password. Hidden and secret are now
SW1(config)#vtp password ccie secret
VTP secret has to be 32 characters in length
SW1(config)#vtp password ccie hidden
Setting device VTP password
As discussed earlier in the VTP section, VTP pruning in my estimation is about the only good thing to come from the whole VTP mess.
Manual pruning is what it says; manual. If you are not using VTP pruning to limit unnecessary broadcasts then you will want to prune vlans that are not in use, by hand.

SWITCH 300-115 1.4 Configure and verify trunking

1.4.d Manual pruning




from switch flg pg 66

On trunk links, it is recommended to manually prune the VLANs that are not used.
You can use VTP pruning if VTP is in use, but manual pruning (using a switch-
port trunk allowed VLAN) is a secure way of allowing only those VLANs that are
expected and allowed on the link. In addition to this, it is also a good practice to
have an unused VLAN as a native VLAN on the trunk links to prevent DTP spoof-

SWITCH 300-115 1.4 Configure and verify trunking

1.4.c Native VLAN

from switch flg pg 50

When configuring an 802.1Q trunk, a matching native VLAN must be defined on each
end of the trunk link. A trunk link is inherently associated with tagging each frame with
a VID. The purpose of the native VLAN is to enable frames that are not tagged with a
VID to traverse the trunk link.




SWTCH 300-115 1.6 Configure and verify spanning tree

1.6.a PVST+, RPVST+, MST

We understand that the sys-id-ext field in spanning-tree is represented by 12 bits of the total 2 byte priority field. The other 4 bits represent the priority in multiples of 4096. We also understand that 2 to the 12th gives us 4096 possible vlans (0-4095 is 4096 vlaues total, 4094 of which are actually configurable), and the determined vlan (if not the default Vlan 1) plus the priority (if adminstratively configured other than the default 32768) completes the priority calculation:

SW2#sh spann | i Br
Bridge ID  Priority    32769  (priority 32768 sys-id-ext 1)

We have 4 bits for priority. 4 bits gives us only 16 possible priority values. (2 to the 4th, feel free to do the binary)


This is also why the root primary/secondary macro is decremented by 4096; there is no choice.

SW2(config)#spann vlan 1 prio 32767
% Bridge Priority must be in increments of 4096.
% Allowed values are:
0     4096  8192  12288 16384 20480 24576 28672
32768 36864 40960 45056 49152 53248 57344 61440