Posts Tagged ‘Spanning-tree’

See my video on this very specific topology, what I’ve encountered, and the solution I found to work for me:


We know that for switches to cooperate inside each region the following must be configured the same:

  • Name – Case Sensitive
  • Revision – Any number, but should be the same
  • Instance mappings and their respective VLANs

Now, what about the VLANs themselves? What about switches and security? I looked all over for this answer and it was vague at best and each vendors documentation said something a little different from each others. However, this is just my preliminary testing, I added multiple instances to my spanning-tree setup on my Cisco Catalyst 3750. My scenario was as follows along with the outputs:

  1. Two instances
  2. Instance 1 had all the real VLANs that were actual VLANs on the switch
  3. Instance 2 had 2 VLANs mapped
    • The first test of MIST2 was with both VLANs not being defined on the switch
    • The second test of MIST2 was with one VLAN defined and the other not
    • The third test of MIST2 was with both the VLANs defined

Because MST instances themselves do not communicate the actual VLANs or VLAN mappings, and IST/CIST does not actually communicate the actual VLAN-to-Instance mapping either. Instead, we rely on IST0 to transmit the BPDUs that contain our information like: name, revision, checksum/Config digest/hash and the actual configuration digest/checkum/hash is the value to which each switch will calculate to determine if they’re operating in the exact same region or in different regions. The digest/hash/checksum is calculated based on parameters present in the MST configuration table. Want to know more about the hashing? Here is a link: 802.1s explained.

The information is long and boring, but do a search for “digest” and you’ll find yourself deep into figuring out how this all works. The test results are soon to come, I am working on both Catalyst and Nexus outputs to benefit not just enterprise and branch, but for those in the data center who’re having to work in vPC hybrid environments with STP attached devices. More to come…


All Cisco switches by default have PVST+ as their spanning-tree protocol (mode). PVST+ is Cisco proprietary and, in my humble opinion, should never be used in a production environment. The alternatives are: RPVST and MST. In a basic 1-3 VLAN network with little to no knowledge of spanning-tree you should run RPVST (802.1w) and be done with it. However, if you have a lot of VLANs and/or you need to ensure you’re not over utilizing the CPU resources, you should use MST (802.1s).

MST (802.1s) is called Multiple instances of Spanning-Tree Protocol and actually relies on RPVST to run inside each instance. MST runs in instances (think of them as groups) and in those instances you can map as many VLANs as you want; thus, you reduce the number of RPVST processes running. For example, in RPVST if you have 10 VLANs, you will have 10 instances of RPVST running, one per VLAN. However, in MST, if you have 10 VLANs grouped into only one instance, there is only one instance running, not 10.

MST is powerful because it reduces the CPU cycles used for spanning-tree operations but can also be used to create multiple paths for groups of VLANs. Configuring MST is simple and requires only a few things to be configured, which I will show here


spanning-tree mode mst

spanning-tree mst configuration
name SOMENAMEGOESHERE
revision 1
instance 1 vlan 1-4094

spanning-tree mst 0-1 priority 4096

For the breakdown:

  • spanning-tree mode mst – Turns on MST as the spanning-tree mode
  • spanning-tree mst configuration – Places you into MST subconfiguration menu
  • name – The name is case sensitive and must match on ALL switches
  • revision 1 – This sets the revision number, which must match across ALL switches, any number will do
  • instance 1 vlan 1-4094 – This maps all the VLANs to instance (group) #1, taking them out of the default IST instance 0
  • spanning-tree mst 0-1 priority 4096 – This sets the priority of both the IST (0) and instance 1 to 4096 to ensure it is always the root bridge

By default there are two instances started by default: IST (Internal Spanning-tree) and CST (Common instance Spanning-tree); however, these are commonly viewed as just one instance CIST. Basically, CIST interacts with other “modes” of spanning tree and is ALWAYS active on access and trunk ports. You can review the details here .

This brief introduction will end with the output of the command: show spanning-tree mst

Core-Switch-01#sh spanning-tree mst

##### MST0 vlans mapped: none
Bridge address 1833.9da2.5700 priority 4096 (4096 sysid 0)
Root this switch for the CIST
Operational hello time 2 , forward delay 4 , max age 6 , txholdcount 6
Configured hello time 2 , forward delay 4 , max age 6 , max hops 20

Interface Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Fa1/0/1 Desg FWD 200000 128.3 P2p
Fa1/0/2 Desg FWD 200000 128.4 P2p
Fa1/0/3 Desg FWD 200000 128.5 P2p
Fa1/0/4 Desg FWD 200000 128.6 P2p
Fa1/0/5 Desg FWD 200000 128.7 P2p
Fa1/0/6 Desg FWD 200000 128.8 P2p
Fa1/0/9 Desg FWD 200000 128.11 P2p
Fa1/0/12 Desg FWD 200000 128.14 P2p
Fa1/0/22 Desg FWD 200000 128.24 P2p
Fa1/0/23 Desg FWD 200000 128.25 P2p
Fa1/0/24 Desg FWD 200000 128.26 P2p

##### MST1 vlans mapped: 1-4094
Bridge address 1833.9da2.5700 priority 4097 (4096 sysid 1)
Root this switch for MST1

Interface Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Fa1/0/1 Desg FWD 200000 128.3 P2p
Fa1/0/2 Desg FWD 200000 128.4 P2p
Fa1/0/3 Desg FWD 200000 128.5 P2p
Fa1/0/4 Desg FWD 200000 128.6 P2p
Fa1/0/5 Desg FWD 200000 128.7 P2p
Fa1/0/6 Desg FWD 200000 128.8 P2p
Fa1/0/9 Desg FWD 200000 128.11 P2p
Fa1/0/12 Desg FWD 200000 128.14 P2p
Fa1/0/22 Desg FWD 200000 128.24 P2p
Fa1/0/23 Desg FWD 200000 128.25 P2p
Fa1/0/24 Desg FWD 200000 128.26 P2p

Notice that MST0 has no VLANs mapped but is still active on all the same ports listed in MST1. Also notice it says: Root this switch for CIST


Spanning-tree is the red headed step child of networking and I firmly believe it is not spanning-trees fault, I blame ignorance of the engineer. Spanning-tree is a tool and like any tool it is typically designed with a specific purpose; however, like most tools in life, you can apply the tool against something else not intended to get desired results. The ignorance people have for spanning-tree causes a lot of issues on networks I have had to resolve in the past and they were relatively easy to resolve. I will explain the single most forgotten configuration parameter: bridge priority: Read the rest of this entry »


You can’t disable spanning-tree on a per-port bases in IOS but you can disable spanning tree per VLAN using the global command:

no spanning-tree vlan vlan-id