Switching

VLAN Trunking Protocol is a Cisco proprietary protocol that allows the switch to propagate VLANs. Some may argue that it is poorly named protocol since the name implies that it has to do something with trunking VLANs. Maybe the name should’ve been VLAN Propagation Protocol (VPP)? I may have taken the name and the thought that the protocol is poorly named from Jeremy Cioara. It’s hard to tell now since I’ve watched a lot of videos and read a lot of books, blogs, and discussion forums.

As I was reading the CCNP SWITCH OCG book, a way for me to refresh my BCMSN knowledge, I was curious about what the book says regarding VTP v1 and v2 transparent mode.

In VTP version 1, a transparent mode switch does not even relay VTP information it receives to other switches unless its VTP domain names and VTP version numbers match those of the other switches. In VTP version 2, transparent switches do forward received VTP advertisements out of their trunk ports, acting as VTP relays. This occurs regardless of the VTP domain name setting.

On Cisco’s documentation page, it says something different than the book.

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. Although VTP version 2 supports only one domain, a VTP version 2 transparent switch forwards a message only when the domain name matches.

Since the book and the documentation page conflicts with each other, it’s time to put this to the test to end this confusion once and for all.

Switch Topology

Just a simple three-switch topology to test if VLANs will propagate when VTP Transparent mode is in the middle.

Configuration

Our first test is configured the same for all the necessary interfaces of the switches. The configuration is shown below for reference. Since we’re going to play with different VTP domain names, we’ll need to turn off the DTP as shown below.

interface FastEthernet0/1
 switchport trunk encapsulation dot1q
 switchport mode trunk
 switchport nonegotiate

Switches that are in factory default settings have NULL domain or a blank domain name and as soon as they hear the first VTP advertisement from another switch who has VTP configured then it will inherit that name and start updating its database.

SW1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
SW1(config)#vtp mode server
Device mode already VTP SERVER.
SW1(config)#vtp domain networkjutsu
Changing VTP domain name from NULL to networkjutsu
SW1(config)#vtp version 1
VTP mode already in V1.
SW1#sh vtp
VTP Version capable             : 1 to 3
VTP version running             : 1
VTP Domain Name                 : networkjutsu
VTP Pruning Mode                : Disabled
VTP Traps Generation            : Disabled
Device ID                       : 0015.6264.3300
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)
Feature VLAN:
--------------
VTP Operating Mode                : Server
Maximum VLANs supported locally   : 1005
Number of existing VLANs          : 5
Configuration Revision            : 0
MD5 digest                        : 0xBC 0xB8 0xA3 0xEE 0x7E 0xDE 0x5A 0xDE
                                    0xBE 0xB3 0xDC 0xCE 0xE8 0xB8 0x5A 0x82
SW2#sh vtp statu
VTP Version capable             : 1 to 3
VTP version running             : 1
VTP Domain Name                 : networkjutsu
VTP Pruning Mode                : Disabled
VTP Traps Generation            : Disabled
Device ID                       : 001c.5823.6480
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)
Feature VLAN:
--------------
VTP Operating Mode                : Server
Maximum VLANs supported locally   : 1005
Number of existing VLANs          : 5
Configuration Revision            : 0
MD5 digest                        : 0xBC 0xB8 0xA3 0xEE 0x7E 0xDE 0x5A 0xDE
                                    0xBE 0xB3 0xDC 0xCE 0xE8 0xB8 0x5A 0x82
SW3#sh vtp statu
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                 : networkjutsu
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)

Once every switch are in the same VTP domain mode, we are now ready to test. Let’s create a VLAN on SW1 to verify that VTP is actually working. Before I issue the command below, I enabled the debugging of VTP on SW2 and SW3 by issuing debug sw-vlan vtp events.

SW1(config)#vlan 10
SW1(config-vlan)#end
SW1#

Once the command was issued in SW1, both SW2 and SW3 received the VTP advertisements – this is expected in VTP Server mode.

SW2# debug sw-vlan vtp events
VTP LOG RUNTIME: Summary packet received, domain = networkjutsu, rev = 1, followers = 1
VTP LOG RUNTIME: Summary packet rev 1 greater than domain networkjutsu rev 0
VTP LOG RUNTIME: Domain networkjutsu currently not in updating state
VTP LOG RUNTIME: Subset packet received, domain = networkjutsu, rev = 1, seq = 1, length = 165
VTP LOG RUNTIME: Transmit vtp summary, domain networkjutsu, rev 1, followers 1
   MD5 digest calculated = BF 22 27 B3 02 83 26 97 D2 70 B1 33 21 96 DA 12
VTP LOG RUNTIME: Summary packet received, domain = networkjutsu, rev = 1, followers = 1
VTP LOG RUNTIME: Summary packet rev 1 equal to domain networkjutsu rev 1
VTP LOG RUNTIME: Subset packet received, domain = networkjutsu, rev = 1, seq = 1, length = 165
SW2#sh vlan id 10
VLAN Name                             Status    Ports
---- -------------------------------- --------- -------------------------------
10   VLAN0010                         active    
SW3#sh vlan id 10
VLAN Name                             Status    Ports
---- -------------------------------- --------- -------------------------------
10   VLAN0010                         active

VTP v1 Transparent Mode

Now, let’s try changing the VTP mode on SW2 to see if the SWITCH OCG book is correct and create another VLAN on SW1.

SW2(config)#vtp mode trans
Setting device to VTP TRANSPARENT mode.
SW2# sh vtp statu
VTP Version capable             : 1 to 3
VTP version running             : 1
VTP Domain Name                 : networkjutsu
VTP Pruning Mode                : Disabled
VTP Traps Generation            : Disabled
Device ID                       : 001c.5823.6480
Configuration last modified by 0.0.0.0 at 3-1-93 00:36:47
Feature VLAN:
--------------
VTP Operating Mode                : Transparent
Maximum VLANs supported locally   : 1005
Number of existing VLANs          : 6
Configuration Revision            : 0
MD5 digest                        : 0xCF 0xCE 0x8A 0x4E 0x4F 0xFA 0x6E 0x4D
                                    0x4F 0xA4 0xA7 0xA2 0xE3 0xD9 0xB2 0x15
SW1(config)#vlan 20
SW1(config-vlan)#end
SW1#

Upon creating VLAN 20 on SW1, SW2 relayed the VTP advertisements and SW3 updated its database. As expected, switch on transparent mode would not update it’s database.

SW2#
VTP LOG RUNTIME: Relaying packet received on trunk Fa0/1 - in TRANSPARENT MODE (nc = false)
VTP LOG RUNTIME: Relaying packet received on trunk Fa0/1 - in TRANSPARENT MODE (nc = false)
VTP LOG RUNTIME: Relaying packet received on trunk Fa0/2 - in TRANSPARENT MODE (nc = false)
VTP LOG RUNTIME: Relaying packet received on trunk Fa0/2 - in TRANSPARENT MODE (nc = false)
VTP LOG RUNTIME: Relaying packet received on trunk Fa0/2 - in TRANSPARENT MODE (nc = false)
VTP LOG RUNTIME: Relaying packet received on trunk Fa0/1 - in TRANSPARENT MODE (nc = false)
SW2# sh vlan id 20
VLAN id 20 not found in current VLAN database
SW3#
VTP LOG RUNTIME: Summary packet received, domain = networkjutsu, rev = 2, followers = 1
VTP LOG RUNTIME: Summary packet rev 2 greater than domain networkjutsu rev 1
VTP LOG RUNTIME: Domain networkjutsu currently not in updating state
VTP LOG RUNTIME: Subset packet received, domain = networkjutsu, rev = 2, seq = 1, length = 185
VTP LOG RUNTIME: Transmit vtp summary, domain networkjutsu, rev 2, followers 1
   MD5 digest calculated = 1B 2E 5F 19 49 46 C4 E6 B7 D2 3C 7A DD 86 D6 42
SW3#sh vlan id 20
VLAN Name                             Status    Ports
---- -------------------------------- --------- -------------------------------
20   VLAN0020                         active

Different VTP Domain, VTP v1 Transparent

Now, how about we change the domain name. According to SWITCH OCG book, the switch with VTP1 Transparent mode will not forward VTP advertisements if it doesn’t match the domain name and version number.

SW2(config)#vtp domain NetworkJutsu
Changing VTP domain name from networkjutsu to NetworkJutsu
SW2(config)#end
SW2#sh vtp statu
VTP Version capable             : 1 to 3
VTP version running             : 1
VTP Domain Name                 : NetworkJutsu
VTP Pruning Mode                : Disabled
VTP Traps Generation            : Disabled
Device ID                       : 001c.5823.6480
Configuration last modified by 0.0.0.0 at 3-1-93 00:36:47
Feature VLAN:
--------------
VTP Operating Mode                : Transparent
Maximum VLANs supported locally   : 1005
Number of existing VLANs          : 6
Configuration Revision            : 0
MD5 digest                        : 0x2A 0xE8 0x6D 0xF7 0x91 0x0A 0x62 0xC4
                                    0x03 0xD0 0x07 0x07 0x7C 0xE2 0x23 0xED
SW1(config)#vlan 30
SW1(config-vlan)#end
SW1#

Upon creating VLAN 30 on SW1, SW2 dropped the VTP advertisement and SW3 never received it.

SW2#
*Mar  1 00:42:56.963: VTP LOG RUNTIME: Dropping packet received on trunk Fa0/1 - not in domain networkjutsu
*Mar  1 00:42:56.963: VTP LOG RUNTIME: Dropping packet received on trunk Fa0/1 - not in domain networkjutsu
SW3#sh vl id 30
VLAN id 30 not found in current VLAN database

Different Domain, VTP v2 Transparent

Let’s change SW2’s VTP version and leave the VTP domain name unchanged.

SW2(config)#vtp ver 2
SW2(config)#end
SW2#sh vtp statu
VTP Version capable             : 1 to 3
VTP version running             : 2
VTP Domain Name                 : NetworkJutsu
VTP Pruning Mode                : Disabled
VTP Traps Generation            : Disabled
Device ID                       : 001c.5823.6480
Configuration last modified by 0.0.0.0 at 3-1-93 00:36:47
Feature VLAN:
--------------
VTP Operating Mode                : Transparent
Maximum VLANs supported locally   : 1005
Number of existing VLANs          : 6
Configuration Revision            : 0
MD5 digest                        : 0x1B 0xF8 0xD3 0x9D 0xD2 0x06 0xC7 0xD7
                                    0x33 0x4B 0x66 0x50 0xC5 0x77 0xF5 0xE1

Now, let’s create another VLAN on SW1 and see if the SWITCH OCG book is correct.

SW1(config)#vlan 40
SW1(config-vlan)#end
SW1#
SW3#
VTP LOG RUNTIME: Dropping packet received on trunk Fa0/1 - not in domain networkjutsu
VTP LOG RUNTIME: Dropping packet received on trunk Fa0/2 - not in domain networkjutsu
SW3#sh vlan id 40
VLAN id 40 not found in current VLAN database

We now know that VTP v2 transparent mode does not relay traffic if the domain does not match. This means that the book is incorrect and the Cisco’s documentation page is spot on. Let’s prove it by changing the domain back to its previous name.

SW2(config)#vtp domain networkjutsu
Changing VTP domain name from NetworkJutsu to networkjutsu
SW2#sh vtp statu
VTP Version capable             : 1 to 3
VTP version running             : 2
VTP Domain Name                 : networkjutsu
VTP Pruning Mode                : Disabled
VTP Traps Generation            : Disabled
Device ID                       : 001c.5823.6480
Configuration last modified by 0.0.0.0 at 3-1-93 00:36:47
Feature VLAN:
--------------
VTP Operating Mode                : Transparent
Maximum VLANs supported locally   : 1005
Number of existing VLANs          : 6
Configuration Revision            : 0
MD5 digest                        : 0xF1 0x29 0x4F 0xB3 0x73 0x0A 0x3A 0xE7
                                    0xF9 0x38 0x1B 0x1A 0xD1 0xAC 0xA6 0x19
SW2#
*Mar  1 01:10:35.944: VTP LOG RUNTIME: Relaying packet received on trunk Fa0/1 - in TRANSPARENT MODE (nc = false)
*Mar  1 01:10:35.953: VTP LOG RUNTIME: Relaying packet received on trunk Fa0/2 - in TRANSPARENT MODE (nc = false)
*Mar  1 01:10:36.532: VTP LOG RUNTIME: Relaying packet received on trunk Fa0/1 - in TRANSPARENT MODE (nc = false)
*Mar  1 01:10:36.532: VTP LOG RUNTIME: Relaying packet received on trunk Fa0/1 - in TRANSPARENT MODE (nc = false)
*Mar  1 01:10:36.574: VTP LOG RUNTIME: Relaying packet received on trunk Fa0/2 - in TRANSPARENT MODE (nc = false)
*Mar  1 01:10:36.574: VTP LOG RUNTIME: Relaying packet received on trunk Fa0/2 - in TRANSPARENT MODE (nc = false)
SW3#sh vlan id 40
VLAN Name                             Status    Ports
---- -------------------------------- --------- -------------------------------
40   VLAN0040                         active    Fa0/1

So far, the book did get the information correctly for the VTP Transparent mode version 1 but wrong for version 2.

All VTP version 2

Now, let’s try to change SW1 and SW3 to version 2 and see the effects. Let’s see if the book has more errors in its statement.

SW3(config)#vtp ver 2
SW3(config)#end
SW1(config)#vtp ver 2
SW1(config)#end
SW1(config)#vlan 50
SW1(config-vlan)#end
SW2#
*Mar 1 01:15:36.810: VTP LOG RUNTIME: Relaying packet received on trunk Fa0/1 - in TRANSPARENT MODE (nc = false)
*Mar 1 01:15:36.810: VTP LOG RUNTIME: Relaying packet received on trunk Fa0/1 - in TRANSPARENT MODE (nc = false)
*Mar 1 01:15:36.852: VTP LOG RUNTIME: Relaying packet received on trunk Fa0/2 - in TRANSPARENT MODE (nc = false)
*Mar 1 01:15:36.852: VTP LOG RUNTIME: Relaying packet received on trunk Fa0/2 - in TRANSPARENT MODE (nc = false)
SW3#sh vlan id 50
VLAN Name                             Status    Ports
---- -------------------------------- --------- -------------------------------
50   VLAN0050                         active    Fa0/1

As the book says, in version 2 transparent mode the VTP advertisements are forwarded out to the trunks. Great, the book is correct.

Different Domain, VTP v2 Transparent and Servers

Now, how about testing what the book says on the last sentence? The book says “this occurs regardless of the VTP domain name setting.”

SW2(config)#vtp domain NetworkJutsu
Changing VTP domain name from networkjutsu to NetworkJutsu
*Mar  1 01:17:27.196: %SW_VLAN-6-VTP_DOMAIN_NAME_CHG: VTP domain name changed to NetworkJutsu.
SW2(config)#end
SW1(config)#vlan 60
SW1(config-vlan)#exit
SW1(config)#
SW2#
*Mar  1 01:18:08.057: VTP LOG RUNTIME: Dropping packet received on trunk Fa0/1 - not in domain networkjutsu
*Mar  1 01:18:08.057: VTP LOG RUNTIME: Dropping packet received on trunk Fa0/1 - not in domain networkjutsu
SW3#sh vlan id 60
VLAN id 60 not found in current VLAN database

It looks like the book got it wrong again. Let’s continue with our testing.

Different Domain, VTP v1 Transparent, VTP v2 Servers

For our penultimate test, let’s try to change SW2’s VTP version to 1 and domain name unchanged, and let SW1 and SW3 remain in version 2. According to the book, with VTP v1 Transparent the domain name and version must match. Let’s see if our gears agree with that.

SW1(config)#vlan 70
SW1(config-vlan)#exit
SW2#
*Mar  1 01:19:19.377: VTP LOG RUNTIME: Dropping packet received on trunk Fa0/1 - not in domain networkjutsu
*Mar  1 01:19:19.377: VTP LOG RUNTIME: Dropping packet received on trunk Fa0/1 - not in domain networkjutsu
SW3#sh vlan id 70
VLAN id 70 not found in current VLAN database

It looks like the book is wrong again.

Same Domain, VTP v1 Transparent, VTP v2 Servers

Now for our last test, let’s change it back to the original domain name and leave other settings unchanged.

SW2(config)#vtp domain networkjutsu
Changing VTP domain name from NetworkJutsu to networkjutsu
*Mar  1 01:20:26.500: %SW_VLAN-6-VTP_DOMAIN_NAME_CHG: VTP domain name changed to networkjutsu.
SW1(config)#vlan 80
SW1(config-vlan)#exit
SW2
*Mar  1 01:20:26.645: VTP LOG RUNTIME: Relaying packet received on trunk Fa0/1 - in TRANSPARENT MODE (nc = false)
*Mar  1 01:20:26.645: VTP LOG RUNTIME: Relaying packet received on trunk Fa0/1 - in TRANSPARENT MODE (nc = false)
*Mar  1 01:20:26.687: VTP LOG RUNTIME: Relaying packet received on trunk Fa0/2 - in TRANSPARENT MODE (nc = false)
*Mar  1 01:20:26.687: VTP LOG RUNTIME: Relaying packet received on trunk Fa0/2 - in TRANSPARENT MODE (nc = false)
SW3#sh vlan |  i active
1    default                          active    Fa0/2, Fa0/3, Fa0/4, Fa0/5
10   VLAN0010                         active
20   VLAN0020                         active
30   VLAN0030                         active
40   VLAN0040                         active
50   VLAN0050                         active
60   VLAN0060                         active
70   VLAN0070                         active
80   VLAN0080                         active

Summary

In theory, theory and practice are the same. In practice, they are not. – Albert Einstein

We’ve just witnessed that it doesn’t matter what the switch’s VTP version is set to so long as the VTP domain name match then the advertisement will be forwarded. Please note that the behavior of VTP version 3 may not be the same as shown here. Unfortunately, I only have two switches capable of running VTP version 3 so it was not tested this time. Maybe when I get a hands on three switches capable of VTP version 3 then I will revisit this blog and update it.

Want to learn more about VTP or switching?

CCNP SWITCH 642-813 Official Certification Guide (Official Cert Guide)
CCNP Routing and Switching SWITCH 300-115 Official Cert Guide
CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1 (5th Edition)

Disclosure

NetworkJutsu.com is a participant in the Amazon Services LLC Associates Program, an affiliate advertising program designed to provide a means for sites to earn advertising fees by advertising and linking to Amazon.com.

Dynamic Trunking Protocol (DTP) is the second generation of Dynamic Inter-Switch Link (DISL) which allow switches to negotiate trunking state of the link between two switches. Both DISL and DTP are Cisco proprietary protocol that are designed to learn whether the device on the other end wants to perform trunking or not.

DTP was covered in BCMSN exam and continues to be covered in SWITCH and even in the CCIE R&S v4.0 book – though not as detailed as the SWITCH/BCMSN books. In Cisco Press’ SWITCH Foundation Learning Guide (FLG in short), there’s table in chapter two that shows combination of DTP modes between two switches. While it’s a great table for DTP reference, it’s incomplete. The table is shown below.

One might ask, what’s missing? Well, DTP on this table shows that it is still on – except for the access. One mode that is missing is the DTP off mode which one would get if the switchport nonegotiate command was issued on a port. The table that the authors should’ve used is something like shown below.

While having DTP turned on can save some time in forming trunks between two switches (assuming that proper modes match up), it is in my opinion that it is not good to leave this feature turned on. Why? Imagine an access port left with default configuration and a malicious user connects to the port and successfully negotiated as a trunk and at the same time decided to attack the STP topology by assigning his computer to be the root bridge for all VLANs. Another example would be an attacker successfully negotiated as a trunk and decided to send traffic to hosts on all VLANs allowed in a trunk. Leaving the DTP on can leave a security hole in an organization’s network so turning it off is a good practice.

While there are ways to mitigate the attacks that I’ve described above, there are other ways one can be convinced to turn DTP off. As a network engineer, do you want ports to automatically negotiate as a trunk even though you didn’t want these ports to be trunk in the first place? A poorly design network is full of unintended scenarios such as this. Why would a network engineer let a finance employee who brought a switch and decided to plug it in to one of the data drops and able to negotiate as a trunk be allowed? Another reason to turn it off is to do increase the speed of convergence. While DTP negotiation is not time consuming, if your uptime is measured in milliseconds then shaving some milliseconds off the DTP negotiation is a good reason, in my opinion.

One final reason that I can think of right now not to rely on DTP, is when you use VTP with multiple domains in your network. If you try to link two switches with different VTP domains, the DTP will not negotiate even if it matches the modes in the table. An example is shown below.

The link between Switch 1 and Switch 2 is Fa0/1. Switch 2’s Fa0/1 is administratively down.

SW1#sh vtp statu
VTP Version : 3 (capable)
Configuration Revision : 0
Maximum VLANs supported locally : 1005
Number of existing VLANs : 5
VTP Operating Mode : Server
VTP Domain Name : CISCO
VTP Pruning Mode : Disabled (Operationally Disabled)
VTP V2 Mode : Disabled
VTP Traps Generation : Disabled
MD5 digest : 0xD3 0x78 0x41 0xC8 0x35 0x56 0x89 0x97
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)
VTP version running : 1
SW1#sh int f0/1 sw
Name: Fa0/1
Switchport: Enabled
Administrative Mode: dynamic desirable
Operational Mode: trunk
Administrative Trunking Encapsulation: negotiate
Operational Trunking Encapsulation: isl
Operational Dot1q Ethertype: 0x8100
Negotiation of Trunking: On
Access Mode VLAN: 1 (default)
Trunking Native Mode VLAN: 1 (default)
Administrative Native VLAN tagging: enabled
Operational Native VLAN tagging: disabled
Voice VLAN: none
Administrative private-vlan host-association: none
Administrative private-vlan mapping: none
Operational private-vlan: none
Trunking VLANs Enabled: ALL
Pruning VLANs Enabled: 2-1001
Capture Mode Disabled
Capture VLANs Allowed: ALL
SW2#sh vtp statu
VTP Version : 3 (capable)
Configuration Revision : 0
Maximum VLANs supported locally : 1005
Number of existing VLANs : 5
VTP Operating Mode : Server
VTP Domain Name : SYSTEMS
VTP Pruning Mode : Disabled (Operationally Disabled)
VTP V2 Mode : Disabled
VTP Traps Generation : Disabled
MD5 digest : 0x9E 0x9B 0x51 0x32 0x00 0xB3 0xDC 0x5D
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)
VTP version running : 1
SW2#sh int f0/1 sw
Name: Fa0/1
Switchport: Enabled
Administrative Mode: dynamic desirable
Operational Mode: down
Administrative Trunking Encapsulation: negotiate
Negotiation of Trunking: On
Access Mode VLAN: 1 (default)
Trunking Native Mode VLAN: 1 (default)
Administrative Native VLAN tagging: enabled
Operational Native VLAN tagging: disabled
Voice VLAN: none
Administrative private-vlan host-association: none
Administrative private-vlan mapping: none
Operational private-vlan: none
Trunking VLANs Enabled: ALL
Pruning VLANs Enabled: 2-1001
Capture Mode Disabled
Capture VLANs Allowed: ALL

Upon bringing up the interface on Switch 2, DTP event on Switch 1 shows that it failed to trunk due to VTP domain mismatch.

SW2(config)#int f0/1 
SW2(config-if)#no shut 
SW2(config-if)#end 
SW2# *Feb 9 03:00:32.847: %SYS-5-CONFIG_I: Configured from console by console 
SW2# *Feb 9 03:00:34.075: %LINK-3-UPDOWN: Interface FastEthernet0/1, changed state to up *Feb 9 03:00:35.079: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/1, changed state to up 
SW1#debug DTP events DTP events debugging is on 
SW1# *Feb 9 03:00:32.715: %DTP-5-DOMAINMISMATCH: Unable to perform trunk negotiation on port Fa0/1 because of VTP domain mismatch.

To verify this, one can issue show interface trunk.

SW1#sh int trunk
SW1#
SW2#sh int trunk
SW2#

As already mentioned above, the command to turn DTP off is by issuing switchport nonegotiate command. But issuing it on an interface without specifying the trunk will give you an error message as shown below.

SW1(config)#int f0/1
Switch(config-if)#switchport nonegotiate
Command rejected: Conflict between 'nonegotiate' and 'dynamic' status.

To properly turn DTP off, you need to specify what kind of trunk you want to use as shown below.

SW1(config)#int f0/1
SW1(config-if)#switchport trunk encapsulation dot1q
SW1(config-if)#switchport mode trunk
%LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/1, changed state to down
%LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/1, changed state to up
SW1(config-if)#switchport nonegotiate

To verify that DTP is turned off, you can issue the command below.

SW1#sh int f0/1 switchport
Name: Fa0/1
Switchport: Enabled
Administrative Mode: trunk
Operational Mode: trunk
Administrative Trunking Encapsulation: dot1q
Operational Trunking Encapsulation: dot1q
Negotiation of Trunking: Off
Access Mode VLAN: 1 (default)
Trunking Native Mode VLAN: 1 (default)
Voice VLAN: none
Administrative private-vlan host-association: none
Administrative private-vlan mapping: none
Administrative private-vlan trunk native VLAN: none
Administrative private-vlan trunk encapsulation: dot1q
Administrative private-vlan trunk normal VLANs: none
Administrative private-vlan trunk private VLANs: none
Operational private-vlan: none
Trunking VLANs Enabled: All
Pruning VLANs Enabled: 2-1001
Capture Mode Disabled
Capture VLANs Allowed: ALL
Protected: false
Unknown unicast blocked: disabled
Unknown multicast blocked: disabled
Appliance trust: none

This command can also be issued on an access port. If the port was not configured with static access, then the error shown earlier will appear as well. That said, change the port to mode access then issue the nonegotiate command.

I believe that this should be a standard configuration in any network for all trunk ports and also the switchport host command on user ports. While not having the nonegotiate command on access ports yield to the same results, it might be a good idea to consider turning it off. If default configuration present more risks than it can offer are then I’d rather issue more commands than be sorry in the future. As what Jeremy Cioara would say, auto is ought not to use it.

Want to learn more about DTP or switching?

CCNP SWITCH 642-813 Official Certification Guide (Official Cert Guide)

CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1 (5th Edition)

Disclosure

NetworkJutsu.com is a participant in the Amazon Services LLC Associates Program, an affiliate advertising program designed to provide a means for sites to earn advertising fees by advertising and linking to Amazon.com.

At the time of writing, Cisco released the Catalyst 2960X not too long ago. It is the new version of the Cisco Catalyst 2960S, which allows stacking of up to eight switches. It provides up to 80 Gbps bandwidth using the optional FlexStack+ module. For more information about the specifications of the switch, head over to Cisco’s site.

I was not really a fan of the 2960S because of the four switches in a stack limitation. With the introduction of 2960X, network professionals can now pick it over 3750 or 3850 in certain scenarios and also save money. Speaking of money, since Cisco designed 2960X to be backward compatible, companies can take advantage of deploying the switch to join existing 2960S stacks. Therefore, provides their customer’s investment protection.

Mixed Stack

The 2960X allows stacking of up to eight switches and can provide up to 80 Gbps bandwidth with FlexStack+. Since 2960S can only stack up to four and provides up to 40 Gbps bandwidth, both switches are architecturally different and one would think that it shouldn’t stack – but, it does. Since both switches are architecturally different, there have to be some restrictions with mixed stack configuration. If you agreed, then you are correct that there are restrictions with mixed stack and are listed below:

• Stacking is not supported on switches running the LAN Lite image. All switches in the stack must be running the LAN Base image.
• In a mixed stack of Catalyst 2960-X and Catalyst 2960-S switches, the number of supported stack members is reduced from eight to four.
• In a mixed stack of Catalyst 2960-X and Catalyst 2960-S switches, full stack bandwidth is reduced from 80 Gbps to 40 Gbps.
• In a mixed stack of Catalyst 2960-X and Catalyst 2960-S switches, stack convergence time is increased from milliseconds to 1 to 2 seconds.

Preparation

As with the stacking of 2960S or 3750, network professionals do not need to configure the switches. The stacking is done automatically by the switch by connecting the FlexStack or StackWise cables. However, there will be some work for the network professional to get the mixed stack configuration working properly.

In this scenario, the existing stack is 2960S with 12.2 IOS image and 2960X with 15.0 IOS image. As with the stacking of 2960S and 3750, the IOS needs to match first before the switch can join the stack properly. That said, the 2960S needs to be upgraded to the same software train as the 2960X.

The output shown here is a familiar log message and show switch output that informs the user that there is a software version mismatch.

*Mar  1 00:16:39.041: %STACKMGR-4-STACK_LINK_CHANGE: Stack Port 2 Switch 2 has changed to state UP
*Mar  1 00:16:55.168: %STACKMGR-4-SWITCH_ADDED_VM: Switch 1 has been ADDED to the stack (VERSION_MISMATCH)
*Mar  1 00:20:55.182: %IMAGEMGR-6-AUTO_COPY_SW_INITIATED: Auto-copy-software process initiated for switch number(s) 1
*Mar  1 00:20:55.606: %IMAGEMGR-6-AUTO_COPY_SW: Searching for stack member to act
*Mar  1 00:20:55.606: %IMAGEMGR-6-AUTO_COPY_SW: as software donor...
*Mar  1 00:20:55.606: %IMAGEMGR-6-AUTO_COPY_SW: Software was not copied
*Mar  1 00:20:55.606: %IMAGEMGR-6-AUTO_ADVISE_SW_INITIATED: Auto-advise-software process initiated for switch number(s) 1
*Mar  1 00:20:55.984: %IMAGEMGR-6-AUTO_ADVISE_SW: Systems with incompatible software have
*Mar  1 00:20:55.984: %IMAGEMGR-6-AUTO_ADVISE_SW: been added to the stack.  The storage
*Mar  1 00:20:55.984: %IMAGEMGR-6-AUTO_ADVISE_SW: devices on all of the stack members have
*Mar  1 00:20:55.984: %IMAGEMGR-6-AUTO_ADVISE_SW: been scanned, and the software required
*Mar  1 00:20:55.984: %IMAGEMGR-6-AUTO_ADVISE_SW: to make all stack members compatible with
*Mar  1 00:20:55.989: %IMAGEMGR-6-AUTO_ADVISE_SW: each other was not found. The "archive
*Mar  1 00:20:55.989: %IMAGEMGR-6-AUTO_ADVISE_SW: download-sw" command can be used to
*Mar  1 00:20:55.989: %IMAGEMGR-6-AUTO_ADVISE_SW: install software off of the network from
*Mar  1 00:20:55.989: %IMAGEMGR-6-AUTO_ADVISE_SW: a tar file.
Switch#sho sw
Switch/Stack Mac Address : f4ea.67ad.7580
                                           H/W   Current
Switch#  Role   Mac Address     Priority Version  State 
----------------------------------------------------------
 1       Member 64e9.50f1.8100     1      2       Version Mismatch    
*2       Master f4ea.67ad.7580     1      1       Ready

The 2960X are designed to work with the 15.0 code. That said, we need to make sure the 2960S is upgraded to the same software train as the 2960X in order for it to form the stack. While the 2960S is being upgraded, we need to prepare the 2960X to ensure it forms the stack. Preparing 2960X to join the stack is as simple as issuing only one command. However, my recommendation is to issue another command for the preparation, which will be covered in a bit.

The switch stack port-speed 10 is the command we need to ensure the switch forms the stack. As the command implies, it sets the port speed of the stack port to 10 Gbps since the default of 2960X is 20 Gbps. Without this command, the 2960S will not recognize anything connected to the stack ports. As a result, the stack will not form. The sample output of the command is shown below. As always, make sure to save the configuration before reload.

Switch(config)#switch stack port-speed 10
WARNING: Changing the stack speed may result in a
stack speed mismatch .
Do you want to continue?[confirm]
New stack speed will be effective after next reload

Optional

The second command that I recommend ensures that both switches are running on the same SDM preference. By default, at least in my testing, the 2960S is set to default as the SDM preference. Make sure to check the SDM preference of the 2960S before changing the 2960X.

In addition, the second command helps with the booting process. Without it, the booting will take a little bit of time since the 2960X will attempt to match the existing stack’s SDM preference. By matching the SDM preference ahead of time, we are bypassing another process that the stack goes through for boot up sequence. A snippet of the boot up output is shown below.

Election Complete
Switch 2 booting as Member, Switch 1 elected Master
HCOMP: Compatibility check PASSED 
Waiting for feature sync....
Waiting for Port download...Complete
Stack Master is ready
 !!!!!!! SDM MISMATCH !!!!!!!
 Master Template is default & Local Template is lanbase-default
Reloading because of sdm template mismatch

SDM Preference

In the previous section, the output displays that the SDM preference of the switches do not match. The output below shows the default SDM preference of the switches.

2960X#show sdm prefer
 The current template is "lanbase-default" template.
 The selected template optimizes the resources in
 the switch to support this level of features for
 0 routed interfaces and 1024 VLANs. 
2960S#sho sdm prefer
 The current template is "default" template.
 The selected template optimizes the resources in
 the switch to support this level of features for
 0 routed interfaces and 255 VLANs.

To change the SDM preference on the 2960X, please issue the command below. Don’t forget to save the configuration before reloading. Once the configurations are done, the 2960X is ready to join the 2960S stack.

Switch(config)#sdm prefer ?  
  default          Default bias
  lanbase-default  Enhanced support for both IPv4 and IPv6 Routing
  lanbase-routing  Supports both IPv4 and IPv6 Routing
Switch(config)#sdm prefer default
Changes to the running SDM preferences have been stored, but cannot take effect 
until the next reload.
Use 'show sdm prefer' to see what SDM preference is currently active.

Verification

Just as any other Cisco stack, to verify if the switch(es) join the stack properly is to issue the command show switch, as shown below.

Switch#sh sw
Switch Ports Model              SW Version            SW Image                 
------ ----- -----              ----------            ----------               
     1 52    WS-C2960X-48FPD-L  15.0(2)EX3            C2960X-UNIVERSALK9-M     
*    2 52    WS-C2960S-48FPS-L  15.0(2)EX3            C2960S-UNIVERSALK9-M

Thoughts

It is a good thing that Cisco is providing investment protection for their customers. It is also good that Cisco released a new version of 2960 platform that supports more than four switches in a stack. The limitation of the 2960S platform that allows only up to four switches in a stack has always been my complaint with it. That said, I don’t normally deploy them in a stack. As a standalone switch, it is a good platform and cheaper than 3750. Having said that, I’ve always liked the 3750 platform for scenarios where I need to have stacking capability since it can go up to nine switches. But with this new 2960 platform, it has earned a place with me.

Disclosure

NetworkJutsu.com is a participant in the Amazon Services LLC Associates Program, an affiliate advertising program designed to provide a means for sites to earn advertising fees by advertising and linking to Amazon.com.

I like using Catalyst 3750 stack for user access switch. Don’t get me wrong, I’d rather use chassis based switches (Catalyst 4500 or 6500) but as we all know that money is usually a concern. 3750 stack is way less than a dual sup and fully populated 4500 or 6500 so if you’re in a budget then 3750 for user access is the way to go, in my opinion. Yes, you don’t have to get dual sup, but you don’t get the redundancy and it is still more money than a 3750 stack. With the 3750 stack, you get the redundancy since all other switches in the stack can take over as the master switch – equivalent to active switch (VSS) or active sup (dual sup chassis based switch).

3750’s StackWise/StackWise Plus/StackPower, 2960’s FlexStack, and VSS, which was mentioned here, are pretty much the same thing – device pooling/stackable switch technologies. With StackWise/StackWise Plus, you can stack up to nine switches. StackPower and FlexStack allows you to stack up to four switches. The last time I checked, the VSS (Virtual Switching System) allows you to stack only up two chassis based switches. If I remember correctly, VSS used to be a 6500 only technology but now the newer 4500s chassis can support VSS as long as it is equipped with the right supervisor – like Sup 7E.

Stacking Catalyst 3750 does not need any manual configuration. All you have to do is connect the StackWise cables (included when you buy it), boot it up and the stack will automatically form. When you rack and stack nine 3750s with 1U space in between, you’ll need one 3M (~9ft) StackWise cable. The one that comes with the switch is only 50CM (~1ft) which is enough to connect all switches except from the top to the bottom switch with 1U space between switches. If you don’t need the 3M then you can also buy the 1M (~3ft) which is good for 3 – 5 switch stack configuration with 1U space between switches, if I remember correctly. Make sure you plan accordingly when ordering your 3750 stack.

Once all the StackWise cables are connected and the switch powers up, it’ll go through its POST sequence, master election, and etc. What I am concern here is the master election. I like my switch stack to be predictable. As what Jeremy Cioara would say, auto = ought not to use it. Though in QoS video, he admitted liking the AutoQoS. Having said all that, I want to know exactly who should take over as a master when it boots up or when the master fails. As mentioned, the switch stack goes through a master election and is described here. In all the scenarios that I’ve experienced, there are only two things that I need to remember and they are the priority and MAC address.

MAC address is only important when you’re working on a new stack or a stack which has no config in it. The switch with the lowest MAC address wins the master election when the priority is set by default (value of 1). See the example below. The stack below is fresh out of the box.

Switch#show sw
Switch/Stack Mac Address : a493.4cd6.5b80
                                           H/W   Current
Switch#  Role   Mac Address     Priority Version  State
----------------------------------------------------------
 1       Member d867.d990.bb80     1      1       Ready
*2       Master a493.4cd6.5b80     1      1       Ready

As you can tell, I only have two switches in this stack. The switch 2 won the master election since the switch priority is a tie and has a lower MAC address than the switch 1. Switch priority is the first one to be checked when it boots up. That’s not what the Cisco’s documentation says, but again I only consider switch priority and MAC address in the election process. Higher switch priority wins the master election and when all the switches have the same priority then the one with the lowest MAC address wins, as already mentioned.

There maybe some network professionals out there that do not care about who the master is in the stack, but I am not one of them. The scenario in this post is physically laid out as switch 1 being the bottom switch and switch 2 as the top switch. I like my switch stack organized, so whenever I set one up I try to match the logical and physical view of the switch stack. In addition, I like my master to be on the top of the switch stack, physically and logically, so I have to alter my configuration to match the way I want it to look like. The configuration below shows you how to alter the switch stack to match the logical and physical view of the stack.

The first step I do is to configure one of the switches to have a higher priority so I know exactly who the master is on a switch stack. In this scenario, I picked switch 2 to have the highest priority. I don’t have to change the priority on this stack since I know this stack will never grow more than two. However, as best practice, I like to configure the priority value of the switches.

Switch#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Switch(config)#switch 2 priority 15
Changing the Switch Priority of Switch Number 2 to 15
Do you want to continue?[confirm]
New Priority has been set successfully

If you recall, switch 2 is placed on the top of the stack (physically) and as mentioned earlier I want both physical and logical to match so I have to configure that as well to reflect it. Below is how to configure it to match physical and logical view of the stack.

Switch(config)#switch 2 renumber 1
WARNING: Changing the switch number may result in a configuration change for that switch.
The interface configuration associated with the old switch number will remain as a provisioned configuration.
Do you want to continue?[confirm]
Changing Switch Number 2 to Switch Number 1
New Switch Number will be effective after next reboot

As you may have guessed, you can’t have two switches with the same number so you have to change the remaining switches in the stack. If your stack contains nine switches, then knowing the switch number is important so you can renumber the right switch. To do this easily, you press the mode button of the switch until the stack LED lights up. You’ll now notice that the LED of the port numbers are blinking as well. Take note of those numbers so you can rename the proper switch with the right number. I normally use the top to bottom approach when I number my stack. In this scenario, I only have two switches so it’s easy to do but if you have you nine switches it’ll most likely be jumbled up. Your switch 3 (physically) may be numbered as 9, so make sure to write it down. Anyway, below is to finish what I’ve started.

Switch(config)#switch 1 renumber 2
WARNING: Changing the switch number may result in a configuration change for that switch.
The interface configuration associated with the old switch number will remain as a provisioned configuration.
Do you want to continue?[confirm]
Changing Switch Number 1 to Switch Number 2
New Switch Number will be effective after next reboot

Since I only have two switches and I know that this stack is not going to get another switch, I didn’t change the switch priority on the other one. I normally change the priorities of all the switches in the stack whenever I configure a stack from scratch except for the bottom switch. This way, I know which switch will be the next master switch when the original master fails. Obviously, this is a matter of preference so you don’t have to follow my method.

Once everything has been renumbered, it’s time to reboot the stack. When the stack is fully booted, verify the switch stack to make sure that everything is what you desire it to be.

Switch>sho switch
Switch/Stack Mac Address : a493.4cd6.5b80
                                           H/W   Current
Switch#  Role   Mac Address     Priority Version  State
----------------------------------------------------------
*1       Master a493.4cd6.5b80     15     1       Ready
 2       Member d867.d990.bb80     1      1       Ready

If you compare the previous show switch output earlier, the switch with a493.4cd6.5b80 is now showing up as switch 1 and has a priority of 15. With the priority set to 15, this helps determine who will be the master of the switch during election. Again, this does not guarantee that it’ll always be the master, however, since when there’s a tie in priority the next one to check is the MAC address.

Hope this has been helpful and thank you for reading!

Disclosure

NetworkJutsu.com is a participant in the Amazon Services LLC Associates Program, an affiliate advertising program designed to provide a means for sites to earn advertising fees by advertising and linking to Amazon.com.