Showing posts with label STP. Show all posts
Showing posts with label STP. Show all posts

Wednesday, February 19, 2020

Spanning-Tree LoopGuard and UDLD

If you ever used fiber cables you might have noticed that there is a different connector to transmit and receive traffic.
Fiber Cable ConnectorsIf one of the cables (transmit or receive) fails we’ll have a unidirectional link failure and this can cause spanning tree loops. There are two protocols that can take care of this problem:
  • LoopGuard
  • UDLD ( Unidirectional Link Detection )
Let’s start by taking a close look at what will happen if we have a unidirectional link failure:
switches fiber connections topology
Imagine the links between the switches are fiber links. In reality there’s a different connector for transmit and receive. SW3 is receiving BPDUs from SW2 and as a result the interface has become an alternate port and is in blocking mode.
spanning tree unidirectional link failure
Now something goes wrong…the transmit connector on SW2 towards SW3 was eaten by mice failed due to unknown reasons. As a result SW3 is not receiving any BPDUs from SW2 but it can still send traffic to SW2.
Because SW3 is not receiving anymore BPDUs on its alternate port it will go into forwarding mode. We now have a one way loop as indicated by the green arrow.
One of the methods we can use to solve our unidirectional link failure is to configure LoopGuard. When a switch is sending but not receiving BPDUs on the interface, LoopGuard will place the interface in the loop-inconsistent state and block all traffic:
spanning tree loop guard example
Let’s take a look what this looks like on actual switches. I will use the same topology:
Rapid Spanning Tree UplinkFastLet’s enable loopguard:
SW1(config)#spanning-tree loopguard default
SW2(config)#spanning-tree loopguard default
SW3(config)#spanning-tree loopguard default
Use the spanning-tree loopguard default command to enable LoopGuard globally. I don’t have any fiber connectors so I’m unable to create a unidirectional link failure. I can simulate it however by using BPDUfilter on SW2’s fa0/16 interface. SW3 won’t receive any BPDUs anymore on its alternate port which will cause it to go into forwarding mode:
SW2(config)#interface fa0/16
SW2(config-if)#spanning-tree portfast trunk
SW2(config-if)#spanning-tree bpdufilter enable
Here’s what will happen:
SW3# 
*Mar  1 00:17:14.431: %SPANTREE-2-LOOPGUARD_BLOCK: Loop guard blocking port FastEthernet0/16 on VLAN0001.
Normally this would cause a loop but luckily we have LoopGuard configured. You can see this error message appearing in your console, problem solved!
hostname SW1
!
spanning-tree loopguard default
!
end
hostname SW2
!
spanning-tree loopguard default
!
interface FastEthernet0/16
 spanning-tree portfast trunk
 spanning-tree bpdufilter enable
!
end
hostname SW3
!
spanning-tree loopguard default
!
end
If you want you don’t have to configure LoopGuard globally, you can also do it on the interface level like this:
SW3(config-if)#spanning-tree guard loop
The other protocol we can use to deal with unidirectional link failures is called UDLD (UniDirectional Link Detection). This protocol is not part of the spanning tree toolkit but it does help us to prevent loops.
Simply said UDLD is a layer 2 protocol that works like a keepalive mechanism. You send hello messages, you receive them and life is good. As soon as you still send hello messages but don’t receive them anymore you know something is wrong and we’ll block the interface.
Let’s use the same topology but configure UDLD this time. Don’t forget to get rid of loopguard first…
Rapid Spanning Tree UplinkFast
SW1(config)#udld ?      
  aggressive  Enable UDLD protocol in aggressive mode on fiber ports except
              where locally configured
  enable      Enable UDLD protocol on fiber ports except where locally
              configured
  message     Set UDLD message parameters
There are a number of methods how you can configure UDLD. You can do it globally with the udld command but this will only activate UDLD for fiber links!
There are two options for UDLD:
  • Normal (default)
  • Aggressive
When you set UDLD to normal it will mark the port as undetermined but it won’t shut the interface when something is wrong. This is only used to “inform” you but it won’t stop loops.
Aggressive is a better solution. When it loses connectivity to a neighbor it will send a UDLD frame out once a second for 8 seconds. If the neighbor does not respond the interface will be put in err-disable mode.
Let’s use two switches to demonstrate UDLD:
Spanning-Tree BPDU Guard TopologyLet’s enable UDLD:
SW2(config)#interface fa0/16
SW2(config-if)#udld port aggressive
SW3(config)#interface fa0/16
SW3(config-if)#udld port aggressive
We’ll use SW2 and SW3 to demonstrate UDLD. I’ll use aggressive mode so we can see that the interface goes down when something is wrong. To see what is going on in real time we’ll use a debug:
SW2#debug udld events 
UDLD events debugging is on
SW3#
New_entry = 34422DC (Fa0/16)
Found an entry from same device (Fa0/16)
Cached entries = 2 (Fa0/16)
Entry (0x242BB9C) deleted: 1 entries cached
Cached entries = 1 (Fa0/16)
Checking if multiple neighbors (Fa0/16)
Single neighbor detected (Fa0/16)
Checking if link is bidirectional (Fa0/16)
Found my own ID pair in 2way conn list (Fa0/16)
Now the tricky part will be to simulate a unidirectional link failure. LoopGuard was easier because it was based on BPDUs. UDLD runs its own layer 2 protocol by using the proprietary MAC address 0100.0ccc.cccc. We can create a filter to block the UDLD traffic:
SW3(config)#mac access-list extended UDLD-FILTER
SW3(config-ext-macl)#deny any host 0100.0ccc.cccc
SW3(config-ext-macl)#permit any any
SW3(config-ext-macl)#exit
SW3(config)#interface fa0/16
SW3(config-if)#mac access-group UDLD-FILTER in
This is a creative way to cause trouble. By filtering the MAC address of UDLD on one side it will think that there is an unidirectional link failure! Here’s what you will see:
SW2#
UDLD FSM updated port, bi-flag udld_empty_echo, phase udld_detection (Fa0/16)
timeout timer = 0 (Fa0/16)
Phase set to EXT.  (Fa0/16)
New_entry = 370CED0 (Fa0/16)
Found an entry from same device (Fa0/16)
Cached entries = 2 (Fa0/16)
Entry (0x3792BE0) deleted: 1 entries cached
Cached entries = 1 (Fa0/16)
Zero IDs in 2way conn list (Fa0/16)
Zero IDs in 2way conn list (Fa0/16)
UDLD disabled port, packet received in extended detection (Fa0/16)
%UDLD-4-UDLD_PORT_DISABLED: UDLD disabled interface Fa0/16, unidirectional link detected
%PM-4-ERR_DISABLE: udld error detected on Fa0/16, putting Fa0/16 in err-disable state
You’ll see a lot of debug information flying by but the end result will be that the port is now in err-disable state. Here’s a show command you can use to check it:
SW2#show udld fastEthernet 0/16

Interface Fa0/16
---
Port enable administrative configuration setting: Enabled / in aggressive mode
Port enable operational state: Enabled / in aggressive mode
Current bidirectional state: Unidirectional
Current operational state: Disabled port
You can verify it by using the show udld command.
LoopGuard and UDLD both solve the same problem: Unidirectional Link failures. They have some overlap but there are a number of differences, here’s an overview:
LoopGuardUDLD
ConfigurationGlobal / per portGlobal (for fiber) / per port
Per VLAN?YesNo, per port
AutorecoveryYesYes – requires err-disable timeout.
Protection against STP failures because of unidirectional link failuresYes – need to enable it on all root and alternate portsYes – need to enable it on all interfaces
Protection against STP failures because no BPDUs are sentYesNo
Protection against miswiringNoYes
That’s all there is to it. I hope you enjoyed this lesson about LoopGuard and UDLD.

Spanning-Tree RootGuard

RootGuard will make sure you don’t accept a certain switch as a root bridge. BPDUs are sent and processed normally but if a switch suddenly sends a BPDU with a superior bridge ID you won’t accept it as the root bridge. Normally SW2 would become the root bridge because it has the best bridge ID, fortunately we have RootGuard on SW3 so it’s not going to happen!
Let me demonstrate this with the following topology:
Spanning-Tree BPDU Guard Topology
Let me show you the configuration by using SW2 and SW3, first I will make sure that SW3 is NOT the root bridge:
SW2(config)#spanning-tree vlan 1 priority 4096
Now we’ll enable rootguard on SW2:
SW2(config)#interface fa0/16
SW2(config-if)#spanning-tree guard root 
%SPANTREE-2-ROOTGUARD_CONFIG_CHANGE: Root guard enabled on port FastEthernet0/16.
We get a nice notification message that it has been enabled. Let’s enable a debug so we can see what is going on:
SW2#debug spanning-tree events 
Spanning Tree event debugging is on
Now we’ll upset SW2 by changing the priority to the lowest value possible (0) on SW3. Normally it should now become the root bridge:
SW3(config)#spanning-tree vlan 1 priority 0
Let’s see what SW2 thinks about this:
SW2#
STP: VLAN0001 heard root     1-000f.34ca.1000 on Fa0/16
supersedes  4097-0019.569d.5700
%SPANTREE-2-ROOTGUARD_BLOCK: Root guard blocking port FastEthernet0/16 on VLAN0001.
Here goes…SW2 will not accept SW3 as a root bridge. It will block the interface for this VLAN. Here’s another useful command to verify this:
SW2#show spanning-tree inconsistentports 

Name                 Interface                Inconsistency
-------------------- ------------------------ ------------------
VLAN0001             FastEthernet0/16         Root Inconsistent

Number of inconsistent ports (segments) in the system : 1
It’s telling us that Fastethernet0/16 is inconsistent. Rootguard is a useful command to enable on your Core or Distribution layer switches so that the underlying switches will never be elected as a root bridge.
hostname SW3
!
spanning-tree vlan 1 priority 0
!
end
hostname SW2
!
spanning-tree vlan 1 priority 4096
!
interface FastEthernet0/16
 spanning-tree guard root
!
end

Spanning-Tree BPDUFilter

The spanning-tree BPDUfilter works similar to BPDUGuard as it allows you to block malicious BPDUs. The difference is that BPDUguard will put the interface that it receives the BPDU on in err-disable mode while BPDUfilter just “filters” it. In this lesson we’ll take a good look at how BPDUfilter works.
BPDUfilter can be configured globally or on the interface level and there’s a difference:
  • Global: if you enable BPDUfilter globally then any interface with portfast enabled will not send or receive any BPDUs. When you receive a BPDU on a portfast enabled interface then it will lose its portfast status, disables BPDU filtering and acts as a normal interface.
  • Interface: if you enable BPDUfilter on the interface it will ignore incoming BPDUs and it will not send any BPDUs. This is the equivalent of disabling spanning-tree.
You have to be careful when you enable BPDUfilter on interfaces. You can use it on interfaces in access mode that connect to computers but make sure you never configure it on interfaces connected to other switches; if you do you might end up with a loop.
Let’s use the following topology to demonstrate the BPDUfilter:
Spanning-Tree BPDU Guard Topology
I’m going to use SW2 and SW3 to demonstrate BPDUfilter:
SW2(config)#interface fa0/16
SW2(config-if)#spanning-tree portfast trunk
SW2(config-if)#spanning-tree bpdufilter enable
It will stop sending BPDUs and it will ignore whatever is received. Let’s enable a debug to see what it does:
SW2#debug spanning-tree bpdu
You won’t see any exciting messages but if you enable BPDU debugging you’ll notice that it doesn’t send any BPDUs anymore. If you want you can also enable BPDU debugging on SW3 and you’ll see that you won’t receive any from SW2.
SW2(config)#interface fa0/16
SW2(config-if)#no spanning-tree bpdufilter enable
Let’s get rid of the BPDUfilter command on the interface level and enable it globally:
SW2(config)#spanning-tree portfast bpdufilter default
You can also use the global command for BPDUfilter. This will enable BPDUfilter on all interfaces that have portfast.
That’s all there is to it. Personally I wouldn’t use this and use BPDUguard instead. If you don’t expect BPDUs on an interface then it’s better to get a notification (through err-disable) then not seeing what is going on…

Spanning-Tree BPDUGuard

Spanning-tree BPDUguard is one of the features that helps you protect your spanning-tree topology. Let me give you an example:
spanning tree fake bpdu
In my topology above we have a perfectly working spanning tree topology. By default spanning tree will send and receive BPDUs on all interfaces. In our example we have a computer on the fa0/2 interface of SW2. Someone with curious hostile intentions could start a tool that generates BPDUs with a superior bridge ID. What’ll happen is that our switches will believe that the root bridge can now be reached through SW2 and we’ll have a spanning tree re-calculation. Doesn’t sound like a good idea right? Here’s what could go wrong:
spanning tree mitm
You could even do a man in the middle attack without anyone knowing. Imagine I connect my computer to two switches. If I become the root bridge all traffic from SW1 or SW3 towards SW2 will flow through me. I’ll run Wireshark and wait till the magic happens.
We can use BPDUGuard to prevent this from happening as it will block BPDUs:
spanning tree bpdu guard active
BPDUguard will ensure that when we receive a BPDU on an interface that the interface will go into err-disable mode.
Let’s take a look how to configure this…

Configuration

I will use the following topology:
spanning tree bpduguard topology
To demonstrate BPDUguard I’m going to use two switches. I’ll configure the fa0/16 interface of SW2 so it will go into err-disable mode if it receives a BPDU from SW3.
SW2(config)#interface fa0/16
SW2(config-if)#spanning-tree bpduguard enable
This is how you enable it on the interface. Keep in mind normally you will never do this between switches; you should configure this on the interfaces in access mode that connect to computers.
SW2#
%SPANTREE-2-BLOCK_BPDUGUARD: Received BPDU on port Fa0/16 with BPDU Guard enabled. Disabling port.
%PM-4-ERR_DISABLE: bpduguard error detected on Fa0/16, putting Fa0/16 in err-disable state
: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/16, changed state to down
%LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan1, changed state to down
*Mar  1 00:19:32.089: %LINK-3-UPDOWN: Interface FastEthernet0/16, changed state to down
Uh oh…there goes our interface.
SW2(config-if)#no spanning-tree bpduguard 
SW2(config-if)#shutdown
SW2(config-if)#no shutdown
Get rid of BPDUguard and do a shut/no shut to get the interface back up and running.
SW2(config)#spanning-tree portfast bpduguard default
You can also use the spanning-tree portfast bpduguard default command. This will globally activate BPDUguard on all interfaces that have portfast enabled.
SW2(config)#spanning-tree portfast default
Portfast can also be enabled globally for all interfaces running in access mode.
SW2#show spanning-tree summary        
Switch is in pvst mode
Root bridge for: none
Extended system ID           is enabled
Portfast Default             is enabled
PortFast BPDU Guard Default  is enabled
Portfast BPDU Filter Default is disabled
Loopguard Default            is disabled
EtherChannel misconfig guard is enabled
UplinkFast                   is disabled
BackboneFast                 is disabled
Configured Pathcost method used is short
Here’s a useful command so you can verify your configuration. You can see that portfast and BPDUGuard have been enabled globally.
That’s all there to it. I hope you enjoyed this lesson!

Multiple Spanning Tree (MST)

By default Cisco Catalyst Switches run PVST+ or Rapid PVST+ (Per VLAN Spanning Tree). This means that each VLAN is mapped to a single spanning tree instance. When you have 20 VLANs, it means there are 20 instances of spanning tree.
Is this a problem? Like always…it depends, let’s take a look at an example:
cisco mst topology 200 vlans
Take a look at the topology above. We have three switches and a lot of VLANs. There’s 199 VLANs in total. If we are running PVST or Rapid PVST this means that we have 199 different calculations for each VLAN. This requires a lot of CPU power and memory.
When SW2 is the root bridge for VLAN 100 – 200 and SW3 for VLAN 201 – 300 our spanning-tree topologies will look like this:
cisco mst two topologies
SW2 is the root bridge for VLAN 100 up to VLAN 200. This means that the fa0/17 interface of SW1 or the fa0/14 interface on SW3 will be blocked. I’ll have 100 spanning tree calculations but they all look the same for these VLANs…
The same thing applies for VLAN 201 – 300. SW3 is the root bridge for VLAN 201 up to 300. The fa0/14 interface on SW1 or SW2 will be blocked for all these VLANs.
Two different outcomes but I still have 200 different instances of spanning tree running. That’s a waste of CPU cycles and memory right?
MST (Multiple Spanning Tree) will solve this issue. Instead of calculating a spanning tree for each VLAN we can use instances and map VLANS to each instance. For the network above I could do something like this:
  • Instance 1: VLAN 100 – 200
  • Instance 2: VLAN 201 – 300
Sounds logical right? Only two spanning tree calculations (instances) are required for all these VLANs.
MST works with the concept of regions. Switches that are configured to use MST need to find out if their neighbors are running MST.
MST Region A Region B

When switches have the same attributes they will be in the same region. It’s possible to have one or more regions and here are the attributes that need to match:
  • MST configuration name.
  • MST configuration revision number.
  • MST instance to VLAN mapping table.
When switches have the same attributes configured they will be in the same region. If the attributes are not the same the switch is seen as being at the boundary of the region. It can be connected to another MST region but also talk to a switch running another version of spanning tree.
The MST configuration name is just something you can make up, it’s used to identify the MST region. The MST configuration revision number is also something you can make up and the idea behind this number is that you can change the number whenever you change your configuration. It doesn’t matter what you pick as long as it’s the same on all switches within the MST region. VLANs will be mapped to an instance by using the MST instance to VLAN mapping table. This is something we have to do ourselves.
Within the MST region, we will have one instance of spanning tree that will create a loop-free topology within the region. When you configure MST there is always one default instance used to calculate the topology within the region. We call this the IST (Internal Spanning Tree). By default Cisco will use instance 0 to run the IST. In case you were wondering…its rapid spanning tree that we run within the MST.
MST Region Instance 0
I could create instance 1 for VLAN 100 – 200 and instance 2 for VLAN 201 – 300. Depending on which switch will become root bridge for each instance a different port will be blocked. It could look like this:
MST Region Instance 1 Instance 2
The switch outside the MST region doesn’t see what the MST region looks like. For this switch it’s like it’s talking to one big switch or a ‘black box’:
MST Region Outside
If you want to know the details of how MST and PVST+ work together, check out our MST and PVST+ interoperability lesson.  Let’s have some fun with the configuration.

MST Configuration

I will use the following topology:
mst region three switches example
We’ll start with a single MST region with the following attributes:

  • MST configuration name: “Networklessons”
  • MST configuration revision number: 1 (this is just a number that I made up)
  • MST instance to VLAN mapping table:
    • Instance 2: VLAN 10, 20 and 30.
    • Instance 3: VLAN 40, 50 and 60.
This is what we will do:
SW1(config)#spanning-tree mode mst
SW2(config)#spanning-tree mode mst
SW3(config)#spanning-tree mode mst
This is how we enable MST on our switches. Let’s look at the default MST instance:
SW1#show spanning-tree mst configuration 
Name      []
Revision  0     Instances configured 1

Instance  Vlans mapped
--------  ---------------------------------------------------------------------
0         1-4094
-------------------------------------------------------------------------------
SW2#show spanning-tree mst configuration 
Name      []
Revision  0     Instances configured 1

Instance  Vlans mapped
--------  ---------------------------------------------------------------------
0         1-4094
-------------------------------------------------------------------------------
SW3#show spanning-tree mst configuration 
Name      []
Revision  0     Instances configured 1

Instance  Vlans mapped
--------  ---------------------------------------------------------------------
0         1-4094
-------------------------------------------------------------------------------
We can use the show spanning-tree mst configuration command to see the MST instances. I haven’t created any additional instances so only instance 0 is available. You can see that all VLANs are currently mapped to instance 0. Let’s see what else we can find:
SW1#show spanning-tree mst 

##### MST0    vlans mapped:   1-4094
Bridge        address 0011.bb0b.3600  priority      32768 (32768 sysid 0)
Root          address 000f.34ca.1000  priority      32768 (32768 sysid 0)
              port    Fa0/17          path cost     0        
Regional Root address 000f.34ca.1000  priority      32768 (32768 sysid 0)
                                      internal cost 200000    rem hops 19
Operational   hello time 2 , forward delay 15, max age 20, txholdcount 6 
Configured    hello time 2 , forward delay 15, max age 20, max hops    20

Interface        Role Sts Cost      Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Fa0/14           Desg FWD 200000    128.16   P2p 
Fa0/17           Root FWD 200000    128.19   P2p
You can also use the show spanning-tree mst command. We can see the VLAN mapping but also information about the root bridge. Before we can add more instances we have to do our chores…time to add some VLANs and configure the links between the switches as trunks:
SW1(config)#interface fa0/14
SW1(config-if)#switchport trunk encapsulation dot1q
SW1(config-if)#switchport mode trunk
SW1(config)#interface fa0/17
SW1(config-if)#switchport trunk encapsulation dot1q
SW1(config-if)#switchport mode trunk
SW2(config)#interface fa0/14
SW2(config-if)#switchport trunk encapsulation dot1q
SW2(config-if)#switchport mode trunk
SW2(config)#interface fa0/16
SW2(config-if)#switchport trunk encapsulation dot1q
SW2(config-if)#switchport mode trunk
SW3(config)#interface fa0/14
SW3(config-if)#switchport trunk encapsulation dot1q
SW3(config-if)#switchport mode trunk
SW3(config)#interface fa0/16
SW3(config-if)#switchport trunk encapsulation dot1q
SW3(config-if)#switchport mode trunk
That takes cares of the trunks, and here are the VLANs:
SW1, SW2 & SW3:
(config)#vlan 10
(config-vlan)#vlan 20
(config-vlan)#vlan 30
(config-vlan)#vlan 40
(config-vlan)#vlan 50
(config-vlan)#vlan 60
(config-vlan)#exit
Now we can configure MST and the instances:
SW1(config)#spanning-tree mst configuration 
SW1(config-mst)#name Networklessons
SW1(config-mst)#revision 1
SW1(config-mst)#instance 2 vlan 10,20,30
SW1(config-mst)#instance 3 vlan 40,50,60
SW1(config-mst)#exit
SW2(config)#spanning-tree mst configuration 
SW2(config-mst)#name Networklessons
SW2(config-mst)#revision 1
SW2(config-mst)#instance 2 vlan 10,20,30
SW2(config-mst)#instance 3 vlan 40,50,60
SW2(config-mst)#exit
SW3(config)#spanning-tree mst configuration 
SW3(config-mst)#name Networklessons
SW3(config-mst)#revision 1
SW3(config-mst)#instance 2 vlan 10,20,30
SW3(config-mst)#instance 3 vlan 40,50,60
SW3(config-mst)#exit
This is how we configure MST. First you need the spanning-tree mst configuration command to enter the configuration of MST. We set the name by using the name command. Don’t forget to set a revision number and map the instances with the instance command. Let’s verify our work:
SW1#show spanning-tree mst configuration 
Name      [Networklessons]
Revision  1     Instances configured 3

Instance  Vlans mapped
--------  ---------------------------------------------------------------------
0         1-9,11-19,21-29,31-39,41-49,51-59,61-4094
2         10,20,30
3         40,50,60
-------------------------------------------------------------------------------
We can use the show spanning-tree mst configuration command to verify our configuration. You can see that we now have two instances. The VLANS are mapped to instance 2 and 3. All the other VLANs are still mapped to instance 0.
So far so good, let’s play some more with MST and change the root bridge:
mst region switch a root bridge
Within our region I want to make sure that SW1 is the root bridge. We’ll have to change the priority for the IST (Internal Spanning Tree):
SW1(config)#spanning-tree mst 0 priority 4096
This is how I change the priority for MST instance 0.
SW1#show spanning-tree mst               

##### MST0    vlans mapped:   1-9,11-19,21-29,31-39,41-49,51-59,61-4094
Bridge        address 0011.bb0b.3600  priority      4096  (4096 sysid 0)
Root          this switch for the CIST
Here you can see that SW1 is the root bridge for the IST. It says CIST which stands for Common and Internal Spanning Tree.
Let’s take a look at the interfaces:
SW1#show spanning-tree mst 0 | begin Interface
Interface        Role Sts Cost      Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Fa0/14           Desg FWD 200000    128.16   P2p 
Fa0/17           Desg FWD 200000    128.19   P2p
SW2#show spanning-tree mst 0 | begin Interface
Interface        Role Sts Cost      Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Fa0/14           Root FWD 200000    128.16   P2p 
Fa0/16           Altn BLK 200000    128.18   P2p
SW3#show spanning-tree mst 0 | begin Interface
Interface        Role Sts Cost      Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Fa0/14           Root FWD 200000    128.14   P2p 
Fa0/16           Desg FWD 200000    128.16   P2p
Now we know the state of all interfaces. Let’s draw a picture so we know what the IST looks like:
mst internal spanning tree
Now I want to make some changes to instance 2 so SW2 will be root bridge:
SW2(config)#spanning-tree mst 2 priority 4096
We’ll change the priority on SW2 for instance 2.
SW2#show spanning-tree mst 2

##### MST2    vlans mapped:   10,20,30
Bridge        address 0019.569d.5700  priority      4098  (4096 sysid 2)
Root          this switch for MST2
This command proves that SW2 is the root bridge for instance 2. Let’s check the interfaces:
SW1#show spanning-tree mst 2 | begin Interface
Interface        Role Sts Cost      Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Fa0/14           Root FWD 200000    128.16   P2p 
Fa0/17           Altn BLK 200000    128.19   P2p
SW2#show spanning-tree mst 2 | begin Interface
Interface        Role Sts Cost      Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Fa0/14           Desg FWD 200000    128.16   P2p 
Fa0/16           Desg FWD 200000    128.18   P2p
SW3#show spanning-tree mst 2 | begin Interface
Interface        Role Sts Cost      Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Fa0/14           Desg FWD 200000    128.14   P2p 
Fa0/16           Root FWD 200000    128.16   P2p
This is what instance 2 looks like. Let’s turn that into a nice picture:
mst instance 2 port states
Here’s a fancy picture of instance 2 to show you the port roles. Note that this topology looks different than the one for instance 0.
Last but not least I’m now going to make some changes for instance 3:
SW3(config)#spanning-tree mst 3 priority 4096
SW3 will become the root bridge for instance 3.
SW3#show spanning-tree mst 3

##### MST3    vlans mapped:   40,50,60
Bridge        address 000f.34ca.1000  priority      4099  (4096 sysid 3)
Root          this switch for MST3
SW3 is now the root bridge for instance 3. Let’s look at the interfaces:
SW1#show spanning-tree mst 3 | begin Interface
Interface        Role Sts Cost      Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Fa0/14           Desg FWD 200000    128.16   P2p 
Fa0/17           Root FWD 200000    128.19   P2p
SW2#show spanning-tree mst 3 | begin Interface
Interface        Role Sts Cost      Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Fa0/14           Altn BLK 200000    128.16   P2p 
Fa0/16           Root FWD 200000    128.18   P2p
SW3#show spanning-tree mst 3 | begin Interface
Interface        Role Sts Cost      Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Fa0/14           Desg FWD 200000    128.14   P2p 
Fa0/16           Desg FWD 200000    128.16   P2p
And we can draw another topology picture:
mst instance 3 port states
Let’s compare instance 2 and 3 next to each other:
mst instance 2 and 3
On the left side you see instance 2 and on the right side is instance 3.
By changing the root bridge per instance we end up with different topologies:
  • Instance 2: fa0/17 on SW1 is blocked for VLAN 10, 20 and 30.
  • Instance 3: fa0/14 on SW2 is blocked for VLAN 40, 50 and 60.
Is this making sense so far? I sure hope so!
What happens when I add another switch that is running PVST to our topology? Let’s find out!
Mst Four Switches
SW4(config)#spanning-tree mode pvst
PVST is the default on most Cisco switches but I’m showing it here so you really know I’m running PVST.
SW4(config)#interface fa0/16
SW4(config-if)#switchport trunk encapsulation dot1q 
SW4(config-if)#switchport mode trunk
SW4(config)#interface fa0/19
SW4(config-if)#switchport trunk encapsulation dot1q 
SW4(config-if)#switchport mode trunk
SW4(config)#vlan 10
SW4(config-vlan)#vlan 20
SW4(config-vlan)#vlan 30
SW4(config-vlan)#vlan 40
SW4(config-vlan)#vlan 50
SW4(config-vlan)#vlan 60
SW4(config-vlan)#exit
I want to make sure that we have trunk to SW2 and SW3 and that SW4 knows about all the VLANs. Let’s see what SW4 thinks of all this:
SW4#show spanning-tree vlan 1

VLAN0001
  Spanning tree enabled protocol ieee
  Root ID    Priority    4096
             Address     0011.bb0b.3600
             Cost        19
             Port        19 (FastEthernet0/19)
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

  Bridge ID  Priority    32769  (priority 32768 sys-id-ext 1)
             Address     0009.7c36.2880
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec
             Aging Time 300

Interface           Role Sts Cost      Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Fa0/16              Altn BLK 19        128.16   P2p 
Fa0/19              Root FWD 19        128.19   P2p
This is what SW4 sees about VLAN 1. Keep in mind this VLAN was mapped to instance 0. It sees SW1 as the root bridge and you can see which port is in forwarding and blocking mode.
SW4#show spanning-tree vlan 10

VLAN0010
  Spanning tree enabled protocol ieee
  Root ID    Priority    4096
             Address     0011.bb0b.3600
             Cost        19
             Port        19 (FastEthernet0/19)
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

  Bridge ID  Priority    32778  (priority 32768 sys-id-ext 10)
             Address     0009.7c36.2880
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec
             Aging Time 300

Interface           Role Sts Cost      Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Fa0/16              Altn BLK 19        128.16   P2p 
Fa0/19              Root FWD 19        128.19   P2p
Here’s VLAN 10 which is mapped to instance 2. SW4 sees SW1 as the root bridge for this VLAN even though we configured SW2 as the root bridge for instance 2. This is perfectly normal because MST will only advertise BPDUs from the IST to the outside world. We won’t see any information from instance 2 or instance 3 on SW4.
SW4#show spanning-tree vlan 40

VLAN0040
  Spanning tree enabled protocol ieee
  Root ID    Priority    4096
             Address     0011.bb0b.3600
             Cost        19
             Port        19 (FastEthernet0/19)
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

  Bridge ID  Priority    32808  (priority 32768 sys-id-ext 40)
             Address     0009.7c36.2880
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec
             Aging Time 300

Interface           Role Sts Cost      Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Fa0/16              Altn BLK 19        128.16   P2p 
Fa0/19              Root FWD 19        128.19   P2p
VLAN 40 is mapped to instance 3 but you can see that SW4 sees SW1 as the root bridge. SW4 receives the same BPDU for all VLANS.
That’s all I have about MST for now! I hope this tutorial was useful for you and that you learned something here.