MST

Multiple STP

• Started as Cisco’s MISTP
• Originally starndard defined in IEE 802.1d
• Now standard per IEEE 802.1q- 2005

How does it Work.

• STP instance to VLAN mappings is use defined
• Topology calculation is done by RSTP

Result is higher scalability

• (Rapid) PVST uses one instance per VLAN
• As VLANs scale , control plane dies.
• PVST is inefficient because there are typically only 3 possible trees anyways

MST Defines a Region as Bridges that agree upon , 

• instance name
• Revision number
• VLAN to STP instance

Intra vs Inter Region 

Intra Region

• Details of the region are known within the region
• VLAN to STP are manually defined
• Undefined VLANS fall into CIST (MST 0 )

CIST – Common Internal Spanning Tree.

Inter Region

• Details between region are  not known
• Different regions see each other as virtual bridges
• Result  is simplified inter-Region calculation
• Intra-region MSTIs are collapsed into CIST.

MST interoperability

• MST is backward compatible with legacy CST and PVST plus
• Behaves like inter-region MST
• CST Root must be within MST Domain

MST Configuration

Define the following MST Configuration mode

• Region name
• Revision number
• VLAN to instance mappings

Enable MST globally

• Real deployment must start at root and work down.

Same election prcoess as Legacy STP

spanning-tree mst configuration
name MST1
revision 1
instance 1 vlan 10-20
instance 2 vlan 21-30
instance 3 vlan 31-40
!

Rapid STP

Rapid Spanning-Tree Protocol.

• New standard originally defined in IEEE 802.1w
•  Now incorporated as IEEE 802.1D -2004

Changes cs Legacy STP

• Simplifies port states
• additional port roles
•  Rapid convergence based on synchronization process
• Path calculation remains the same.

Legacy STP Uses

• Disabled
• Blocking
• Listening
• Learning
• Forwarding

RSTP Simplifies to…

• Discarding – Dropping frames
• Learning – Dropping Frames but building the CAM
• Forwarding – Normal Forwarding

RSTP Ports Roles 

• Port roles are decoupled from port states
• Root Port & Designated Port
• New Roles : Alternate(compared to uplinkfast ) , Backup Designated ( activates if the primary Designated port fails)  & Edge ( immediately transitions to forwarding , Do not generate TCN for state change).

Maintains edge status as long as no BPDUs are received.

• If BPDU received , remove edge status and Generate TCN.

RSTP Link Types

• Non-edge
• Point – point
• shared

Only Point to point Designated ports use the sync process for rapid convergence.

RSTP Sync Process

• Goal is for a bridge to synchronize its root port with the rest for the topology.
• When a bridge elects a root port it assumes all non-edge ports to be designated ( all no-edge ports are discarding at this moment ).
• Bridge sends proposals out all designated ports ( Proposal has port roles set to designated ports : Proposal contains root bridge info ( priority , cost , etc ).
• Downstream bridges review this information ( if they don’t have better paths to the root they agree : If they do have it they announce their information.)
• When designated port receives agreement , it is unblocked .
• If downstream bridge sends a better root information , local bridge changes root port.
• if downsteam bridge agrees to upstream proposal , then it ( elects a local root port , Blocks all non-edge designated ports , Starts sync process on all designated ports
• Port blocking is essential in preventing transient loops.

RSTP Fault Detection

• In legacy STP , BPDUs are only generated by root Bridge ( all other bridges forward them on )
• Is RSTP , each bridge generates BPDU every Hello interval.
• If 3 hellos are missed from a neighbor re-convergence begins ( 6sec vs 20 sec Max age )

Max Age is used as hop Count

• Every bridge sends BPDUs on its own
• Age incremented by every bridge
• Max Age also on shared ports for legacy STP backward compatibility.

Faults can be detected faster by means of physical signalling.

RSTP Convergence

• RSTP needs to re-converge when root ports  lost
• If there is an Alternate port , it is selected in place of old Root Port ( new root is then Synchronized with down stream bridges.)
• If there are no Alternate ports and no better info  ( declare itself as root , Synchronise adapt to better info )

RSTP Topology Change 

• Originated by switch that detected the event
• uses special BPDU bit to signal topology change
• flooded by all switches using reverse path forwading

Flushes MAC table address tables

• causes temporary excessive unicast traffic flooding
• Use Egde ports as much as possible.

spanning-tree portfast bpduguard default global configuration command. Spanning tree shuts down ports that are in a Port Fast-operational state if any BPDU is received on them. In a valid configuration, Port Fast-enabled ports do not receive BPDUs. Receiving a BPDU on a Port Fast-enabled port means an invalid configuration, such as the connection of an unauthorized device, and the BPDU guard feature puts the port in the error-disabled state. When this happens, the switch shuts down the entire port on which the violation occurred.

panning-tree portfast bpdufilter default global configuration command. This command prevents interfaces that are in a Port Fast-operational state from sending or receiving BPDUs. The interfaces still send a few BPDUs at link-up before the switch begins to filter outbound BPDUs. You should globally enable BPDU filtering on a switch so that hosts connected to these interfaces do not receive BPDUs. If a BPDU is received on a Port Fast-enabled interface, the interface loses its Port Fast-operational status, and BPDU filtering is disabled.

STP Convergence Optimizations

STP Topology Change Notifications

• In normal STP operation, a bridge keeps receiving configuration BPDUs from the root bridge on its root port. But, it never sends out a BPDU toward the root bridge. In order to achieve that, a special BPDU called the topology change notification (TCN) BPDU has been introduced. Therefore, when a bridge needs to signal a topology change, it starts to send TCNs on its root port. The designated bridge receives the TCN, acknowledges it, and generates another one for its own root port. The process continues until the TCN hits the root bridge.
• The TCN is a very simple BPDU that contains absolutely no information that a bridge sends out every hello_time seconds (this is locally configured hello_time, not the hello_time specified in configuration BPDUs). The designated bridge acknowledges the TCN by immediately sending back a normal configuration BPDU with the topology change acknowledgement (TCA) bit set. The bridge that notifies the topology change does not stop sending its TCN until the designated bridge has acknowledged it. Therefore, the designated bridge answers the TCN even though it does not receive configuration BPDU from its root
• With legacy STP 802.1D , ports that are facing away from the root bride and are connected to devices that are not participating in STP ( PCs ) 
• If a port connecting a PC by default goes down in STP , the port sends a TCN up towards the root bridge and the root bridge is then going to send a TCN Ack down to the other devices , in the case of legacy STP what does the STP TCN do ? 
• It tells the other bridges to change the MAC address aging time ( 300 sec ) to the maximum age time ( 20 sec ) , this means in a legacy Spanning Tree Design  for any of your edge ports that are not configured as Edge ports (portfast ) when PC powers on & off  , its gonna cause the entire Layer network to to age out the entire MAC address table in 20 secs.
• Basically you end up having the large spikes in broadcast traffic in unknown traffic because the MAC address get flushed out  & the network needs to re-learn them.
• In Rapid STP the issue is even worse  because when TCN is generated  it  causes the switches to immediately Flush out the MAC table as opposed to wait for the MAX Age timer ( RSTP is event driven ).

# spanning tree portfast default – enables portfast on all switch ports that are not receiving BPDUs.

# spanning tree portfast bpdufilter default – enable both portfast and BPDU filter on all ports that are not Receiving BPDUs.

Spanning Tree

Root Bridge : is the reference point of how the other switches need to build their topology. The root bridge itself does not make  any path selection decisions its only used as a reference point for the other switches to make their decisions.

Root Port – Forwarding upstream , Elected based on lowest Root Path Cost ( cumulative cost of all links to the root )

• if Tie in Cost
• Choose lowest upstream BID
• Choose lowest upstream port ID

Designated Port- Forwarding Downstream

• Lowest Root Path Cost
• Lowest  BID
• Lowest  port ID

Blocking Port – Dropping the traffic  , blocking means  i can not associate MAC addresses in the CAM table. Link in the blocking state can receive traffic inbound (BPDU , Broadcast )  but can not do MAC address learning.

Spanning timers are only adjusted on the Root Bridge , you adjust them on the non-root Switches but in wont change anything.

The show spanning Tree output does not show overall path cost to the root bridge only shows the link cost value , to get more detailed info use sh spanning-tree detail.

Normal STP (802.1d) uses four different port states.

Blocking – The port does not forward data frames.

Listening – The port does not forward frames, but it does listen to BPDUs so that it can participate in things like the election of the root bridge, root ports, and designated ports.  We saw earlier that a switch can learn info from BPDUs when not in a forwarding state

Learning – The port does not forward frames, but it does continue to listen to BPDUs and it does begin to learn MAC address information from frames that pass through the port.  If a port makes it to the learning state, the switch already knows that it will either be a designated port or a root port.  If it’s not one of those two ports types, the port will immediately go into blocking after listening and never reach the learning mode.

Forwarding – Once past the learning mode a port will move into the forwarding mode.  The port will now begin to send and receive data frames like a normal switch port and continue to learn MAC addresses on an ongoing basis.

A debug on a switch can shows us these states occurring…

*Mar  1 02:12:18.886: set portid: VLAN0001 Gi1/0/12: new port id 800C
*Mar  1 02:12:18.886: STP: VLAN0001 Gi1/0/12 -> listening
*Mar  1 02:12:20.890: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/12, changed state to up
*Mar  1 02:12:21.897: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/12, changed state to up
*Mar  1 02:12:33.893: STP: VLAN0001 Gi1/0/12 -> learning
*Mar  1 02:12:48.900: STP: VLAN0001 sent Topology Change Notice on Gi1/0/2
*Mar  1 02:12:48.900: STP: VLAN0001 Gi1/0/12 –> forwarding

Note the time difference between each event.  It takes the switch 15 seconds to transition a port between each state.  A total of 30 seconds to bring a port from blocking to forwarding.  The time between each state is referred to as the ‘forward delay’ value and in normal STP is 15 seconds by default.  There are two other times that are used.  The ‘hello’ timer is used to determine how often BPDUs are sent by switches.

REF: http://www.dasblinkenlichten.com/spanning-tree-802-1d-timers-and-misc/

The last timer is the ‘max age’ timer.  The max age timer is used to determine how long a switch should keep BPDU information heard from other switches.  That being said, once a BPDU is removed from a switches STP topology, the topology has to be recalculated.  So if a switch doesn’t see new BPDUs by the end of the max age timer, it knows that something has changed.  We can observe this behavior as well…

*Mar  1 02:24:30.557: STP: VLAN0001 heard root 32769-0012.0100.4d00 on Gi1/0/1
*Mar  1 02:24:32.402: STP: VLAN0001 heard root 32769-0012.0100.4d00 on Gi1/0/1
*Mar  1 02:24:34.407: STP: VLAN0001 heard root 32769-0012.0100.4d00 on Gi1/0/1
*Mar  1 02:24:36.412: STP: VLAN0001 heard root 32769-0012.0100.4d00 on Gi1/0/1
*Mar  1 02:24:38.417: STP: VLAN0001 heard root 32769-0012.0100.4d00 on Gi1/0/1
*Mar  1 02:24:40.422: STP: VLAN0001 heard root 32769-0012.0100.4d00 on Gi1/0/1
*Mar  1 02:24:42.427: STP: VLAN0001 heard root 32769-0012.0100.4d00 on Gi1/0/1
*Mar  1 02:24:44.440: STP: VLAN0001 heard root 32769-0012.0100.4d00 on Gi1/0/1
*Mar  1 02:24:46.436: STP: VLAN0001 heard root 32769-0012.0100.4d00 on Gi1/0/1
*Mar  1 02:24:48.441: STP: VLAN0001 heard root 32769-0012.0100.4d00 on Gi1/0/1
*Mar  1 02:24:48.550: STP: VLAN0001 Gi1/0/1 -> listening
*Mar  1 02:24:49.599: STP: VLAN0001 Topology Change rcvd on Gi1/0/1
*Mar  1 02:24:49.599: STP: VLAN0001 sent Topology Change Notice on Gi1/0/2
*Mar  1 02:25:03.558: STP: VLAN0001 Gi1/0/1 -> learning
*Mar  1 02:25:18.565: STP: VLAN0001 sent Topology Change Notice on Gi1/0/2
*Mar  1 02:25:18.565: STP: VLAN0001 Gi1/0/1 –> forwarding

The top blue section shows the 20 seconds it took for the switch to decide to do something.  In this case, I unplugged one of the links on the switch that had switch1 connected to the root switch3.  When I did this, the switch started hearing the root BPDUs on a different interface.  After the max age timer expired, it kicked the port into the normal listening, learning, forwarding process which took an additional 30 seconds (shown in green).  All told, this process took 50 seconds.

The timers in 802.1d can be adjusted, however you only need to adjust them on the root bridge.  The other MLS read the configuration information sent in the root’s BPDUs and adapt their own timers to match that of the roots.  We can see the timers present in the root bridge’s BPDUs…

UplinkFast
I talked about the uplinkfast sometime ago in this post where I talked about using it to migrate to a new port-channel.  Uplinkfast comes in handy when you have multiple paths between two switches that aren’t in a port-channel.  If they are two separate interfaces, one will always be in blocking mode.  If a link failure occurs, it will take spanning-tree anywhere from 30 to 50 seconds to move the previosuly blocked port into a forwarding state.

Uplinkfast fixes this problem by allowing a blocking port to move immediately into the forwarding state if the forwarding link fails.  As an interesting side-effect of configuring uplinkfast, the switch increase the bridge priority to 41952 and the port costs by 3000.  The rationale is that this will make the switch less likely to become the root switch as well as make it less likely to become a transit switch in the STP topology.  Uplinkfast can not be configured on the root switch and is configured globally.

BackboneFast
Backbonefast is a means for a switch to detect an indirect root failure.  Basically, backbonefast just allows a switch to use RLQs (Root Link Queries) to determine if the root is still accessible.  If it is, the switch can immediately bypass it’s max age timer, and start moving a port that was once blocking directly into the listening and learning state.  We can see this in action pretty easily…

*Mar  1 03:14:47.956: STP: VLAN0001 heard root 32769-000d.2818.a
*Mar  1 03:14:49.340: STP: VLAN0001 heard root 32769-000d.2818.a
*Mar  1 03:14:51.345: STP: VLAN0001 heard root 32769-000d.2818.a
*Mar  1 03:14:53.350: STP: VLAN0001 heard root 32769-000d.2818.a
*Mar  1 03:14:55.354: STP: VLAN0001 heard root 32769-000d.2818.a
*Mar  1 03:14:57.359: STP: VLAN0001 heard root 32769-000d.2818.a
*Mar  1 03:14:59.364: STP: VLAN0001 heard root 32769-000d.2818.a
*Mar  1 03:15:01.369: STP: VLAN0001 heard root 32769-000d.2818.a
*Mar  1 03:15:03.374: STP: VLAN0001 heard root 32769-000d.2818.a
*Mar  1 03:15:05.379: STP: VLAN0001 heard root 32769-000d.2818.a
*Mar  1 03:15:05.949: STP: VLAN0001 Fa1/0/2 -> listening
*Mar  1 03:15:07.006: STP: VLAN0001 Topology Change rcvd on Fa1/
*Mar  1 03:15:07.006: STP: VLAN0001 sent Topology Change Notice
*Mar  1 03:15:20.957: STP: VLAN0001 Fa1/0/2 -> learning
*Mar  1 03:15:35.964: STP: VLAN0001 sent Topology Change Notice on Fa1/0/40
*Mar  1 03:15:35.964: STP: VLAN0001 Fa1/0/2 -> forwarding

This is what we expect to see.  20 seconds for max age, and then 30 seconds from listening to forwarding.  If we enable backbonefast, we see something different…

*Mar  1 03:20:32.795: STP: VLAN0001 heard root 32769-000d.2818.af00 on Fa1/0/2
*Mar  1 03:20:32.795: STP: VLAN0001 Fa1/0/2 -> listening
*Mar  1 03:20:33.801: STP: VLAN0001 Topology Change rcvd on Fa1/0/2
*Mar  1 03:20:33.801: STP: VLAN0001 sent Topology Change Notice on Fa1/0/40
*Mar  1 03:20:47.802: STP: VLAN0001 Fa1/0/2 -> learning
*Mar  1 03:21:02.809: STP: VLAN0001 sent Topology Change Notice on Fa1/0/40
*Mar  1 03:21:02.809: STP: VLAN0001 Fa1/0/2 -> forwarding

It only took 30 seconds for the port to become forwarding.  Notice that the instant it heard the root on a different port it went to listening mode.  This completely got rid of the max age timer.

Spanning-Tree protection
Uplinkfast and backbone fast are Cisco proprietary means to optimize spanning-tree.  There are also a couple of options to protect spanning-tree that you should be aware of…

Root Guard
Root guard prevents a port from learning of a new ,superior, root bridge.  If the port with root guard enabled on it receives a superior BPDU, it will place the port into a ‘root insistent’ state.  This equates to the port being in the spanning-tree blocked state.  Once the port stops hearing the BPDUs, the port will automatically go back into formal forwarding mode.

BPDU Guard
Is a feature that should be enabled on any port that also has portfast enabled on it.  BPDU guard err-disables a port if it receives a BPDU.  This makes sense to enable on portfast enabled ports since they should be edge ports that never receive a BPDU.  If the port does become err-disabled you need to shut/no shut the interface to return it to normal operating state.

BPDU Filter
Prevents a port from sending or receiving BPDUs entirely

Loop Guard
Loop guard is usually talked about in conjunction with UDLD.  I’m not going to cover UDLD but suffice to say it allows you to detect unidirectional links.  Loop guard ran on top of UDLD allows a port to detect when it has stopped receiving BPDUs.  When that happens, it puts the link into ‘loop inconsistent’ state which prevents the port from moving into the forwarding state.