Part Two: Describe the Spanning-Tree Process...

Preface: For this blog entry, I am referring to Scott Bennett's book "31 Days Before Your CCNA Exam". While the occasional passage may be copied from this book, it is not my intention to infringe upon the copyright of this work (which is ©2007, Cisco Systems Inc), nor is it my intention to make the content of the book available to read online. 

Note for any casual readers: I hope you find this entertaining and perhaps even informative. It might seem a bit circuitous and at times perhaps even silly, but when describing things quickly, I tend to describe them in very train-of-thought type ways. I'll repeat myself, refer back to stuff I might not have said, perhaps even (I hope not!) contradict myself from time to time, but hey, this is a learning experience for me too, and as long as I know what I mean, that's the important thing ;-).

Switches filter frames by their layer 2 MAC address, and can speed up a network. But if you want to start adding backup connections to a switched network, it's important that you run Spanning-Tree Protocol (STP).
Redundantly connected switches provide a valuable backup connection, but if something goes wrong and these backup connections end up causing loops, the formerly-useful backup links can bring parts of the network grinding to a halt. 

How It Works (Or "How Stuff Goes Wrong"): 

Remember. If a switch does not recognise the destination MAC address for a frame, it broadcasts/floods that frame out of all ports except the port that originally received the frame. Fair enough. Consider what happens though, if a frame comes in, destined for an address that none of the switches recognise. Note that the diagram is used just to describe the topology of the networks, and not the state of the links. These links are all up, ok? :-)

Switch 0 receives the frame from Router0, doesn't recognise the MAC address, so floods it out of all ports except the one it arrived on, so the frame arrives at Switch 1 and Switch 2. Neither of those recognise the address of the frame, so they flood it out in the same manner, essentially passing the frame across the link to each other (and their respective PCs, but they're just there to look pretty for the time being). What then happens, is that Switch0 receives two frames, one from S1 and one from S2, both of which are copies of each other, but neither of which have known MAC addresses. So what happens? S0 floods S1's frame to the router and to S2, and floods S2's frame to the router and to S1. When S1 and S2 receive these frames, again, they flood them to each other, and from there back up to S0, and round and round they go. Switches have no way of recognising frames that it has previously received.
The situation like this, where frames just go round and round and round, is called a loop. Imaginative, huh?

Okay, the situation above doesn't sound that serious, switches process loads and loads of data, and a few misdirected packets here and there aren't that big a problem surely?

Okay, what about when you're looking at a redundancy topology like this?:

Verwarnung! Sendung Sturm! (Or "The Network Falls Over"): 

Loops in themselves are pretty annoying, but you'd think that on a small topology with a single redundancy link like the one in the first example, they wouldn't become that big a problem. But the size of the problem increases with the size of the network.
On our new "bigger" topology, it's a different picture. Let's say for example that switch 9 receives a broadcast frame from a PC attached to it. Switch 9 would forward the frame to the two multilayer switches that it's connected to, MS7 and MS5, which would duplicate the broadcast frame, sending it to another 6 and 4 switches, respectively. Before we realise what's happening, one broadcast frame has become 13, and so far, the frame has only gone through two cycles of duplication. While the switches don't send the frames back out on the ports that they were received on, there are still 17 devices with a total of 30 connections, and each device duplicates every broadcast frame that it receives, so you can imagine the rapidly increasing amount of traffic, with broadcasts being received, duplicated, and broadcast, over and over again, without end. This is known as a Broadcast Storm. That people intentionally introduce broadcast storms into networks as a form of attack tells you just how badly these situations can affect network performance. Before you know it, for every genuine data frame that needs to be forwarded, there are a huge (and always increasing) number of broadcast frames that need to be processed first. Within a short time, the bandwidth is completely eaten up by broadcast frames, the switching hardware is working at 100% processing load, real network traffic slows to a crawl, and the network becomes unusable.

Enter Our Hero: To stop this situation, or to at least mitigate it, we have Spanning-Tree Protocol.

STP is defined by the IEEE 802.1d standard, and exists to identify the shortest paths in a switched network. It does this so that it can build a loop free topology.
"But wait", you ask. "How can a protocol change the way the network is wired?" Well, obviously it can't. However, what it can do, is change the way that each switch uses the ports, going so far as to block non-STP-management traffic from being received or sent on ports.

Early, when the switch is powered on, STP kicks in, and starts going through the Election Process.
This process exists to define the Root Bridge, a kind of "Main Switch". Having a root bridge allows STP to create a logical "tree" over which to send frames. It allows the other switches to say "That's the 'main' switch, let's use that as the top of our tree".

The Bridge Protocol Data Unit exists to allow each switch to identify the root bridge. Once the root bridge is determined, the switches are then able to maintain a single link towards the root bridge, using designated ports.

The Election Process:

A root bridge election is triggered when either a switch has finished booting, or when a path failure has been detected. All switch ports are initially in the blocking state, and this lasts for 20 seconds. This prevents a loop from occurring before STP has had its chance to do its thing.
After switches have booted, they immediately start sending BPDU frames to advertise their BID - their Bridge ID.

Important notes to bear in mind at this point:

•  The BID consists of both the priority value of the switch, and the MAC address of the sending switch.
• If two or more switches have identical priority values, the one with the LOWEST MAC ADDRESS has the lower bid. 
• The LOWER the bid, the better.

Initially, all switches assume that they themselves are the root bridge. The BPDU frames sent out initially have the root ID field matching the BID field, indicating that each switch considers itself the root bridge.
As each switch receives BPDU frames, it compares the root ID from the frames, with the switch's locally configured root ID. If the root ID on the received frame is lower, the locally held one, the switch updates the locally configured root ID to match the new, lower one.
Once this update is complete, the switch incorporates this new root ID in all future BPDU frame transmissions.
The election process ends once the lowest bridge ID populates the root ID field of all switches in the broadcast domain. 

Port States:

• Blocking: To begin with, when STP starts up, all ports on all switches enter the Blocking State. This means that the ports are essentially shut down, with the exception of one type of traffic, the BPDU.
• Listening: The port [switch? Is this an error in the book?] checks for multiple paths to the root bridge, and blocks all ports except the port with the lowest path cost to the root bridge. 
• Learning: The port MAC addresses and begins to populate the MAC Address Table.
• Forwarding: The port is now part of the active topology, and forwards both data and BPDU frames.

Ports that are not the lowest cost path to the root bridge return to the blocking state and remain there until STP is recalculated.

Types of Ports:

• Designated Port: Think of the designated port as the designated driver. It's the only type of non-root port that is still allowed to forward traffic on the network (Also known as the Downstream Port, as it forwards traffic away from the Root Bridge).
• Root Port: The root port is the port (on any switch that isn't the root bridge) that is closest to the root bridge (Also known as the Upstream Port, as it forwards traffic towards the Root Bridge).
• Non-Designated Port: These are ports that STP puts into the blocking state. They do not forward traffic.

What Happens Now?: Even though the topology has been created successfully, with an agreed-upon root bridge and the ports in their final states,  BPDUs continue to be sent advertising the root ID of the bridge, every two seconds.
Each switch is configured with a maximum age timer that determines how long a switch retains the current BPDU configuration, and this is usually set to 20 seconds.
This means that if a switch fails to receive 10 consecutive BPDU frames from one of its neighbours, the switch goes "hey, the path must have failed. If so, this BPDU info is no longer correct!" and the whole process of electing a new root bridge is triggered again.

Verification: You can verify the spanning tree port assignments  with the "show spanning tree" command, from privileged exec mode.

Let's fire up the lab and see what this looks like:

Here we see that we have three interfaces up. One connects to a PC (edge P2p), and two connect to switches (S2 and S3). Because S2 and S3 each only have one connection to S1, both of S1's connections are Desg (Designated) ports.

Notice in this second example, in this case, the output from Switch 2, that the root bridge ID is 32769 (S1) and is reachable by port FA0/22 (The connection between S2 and S1).
Also note, that while FA0/22 has been configured (by spanning-tree) as a Root Port, FA0/23 is "Altn". What this means is that this port has been defined as an "Alternate" port, which is a port role used by RSTP (Rapid Spanning Tree Protocol), which a more advanced version of the original STP (and is therefore in use by default, on the switches in my lab). More on this later.

Changes to Topology: A switch decides that a topology change has occured, either when a port that was forwarding has gone down, or when a port transitions to forwarding and the switch has a designated port.

The switch notifies the root bridge of the spanning-tree, which broadcasts the information to the entire network.

The switch that notices the change sends out TCNs (Topology Change Notification) BPDUs  on its root port. The receiving switch (unless it is the root bridge itself) is called the designated bridge. The designated bridge replies to the TCN with a TCA - a BPDU with the "Topology Change Acknowledgement" bit set. This process is repeated, with the designated bridge sending out its own TCN to the next switch along the route (which itself becomes the designated bridge), until the root bridge itself is contacted.

Once the root bridge becomes aware of a topology change, it sends out its config BPDUs with the Topology Change bit set.

These BPDUs are received on forwarding and blocking ports.

Manual Configuration: There are five commands that are really beneficial where STP is concerned. These are as follows:

• (config)#Spanning-Tree Vlan 1[ID] Root Primary [Secondary] : Sets the switch to be either the primary root bridge, or the secondary root bridge of the network. You can configure a switch to be a secondary root bridge, in case the primary fails.
• (config)#Spanning-Tree Vlan 1[ID] Priority [0-61440 in increments of 4096] : Sets the priority of the switch manually, allowing for some fine tuning.
• (config-if)#Spanning-Tree Portfast: Skips the majority of the STP process and forces the ports it is applied to, straight to forwarding. Portfast should only ever be used on ports that are connected to a single host (as opposed to a hub or a switch).
• (config)#Spanning-Tree Mode PVST [Rapid-PVST] : Changes the mode of STP operation.
• (config-if)#Spanning-Tree Cost 1 [value] (Not modeled in packet tracer for some reason): Allows you to manually assign costs to each port, to create desired routes to the root bridge.

Modes of STP Operation: Since it was created, STP has gone through several incarnations, each with a variety of features. Some of the more widely used are:

• Rapid Spanning Tree: An updated version of STP, RSTP allows substantially faster convergence. Not only this, but it permits the use of Alternate ports in STP topologies (as discussed earlier). RSTP allows each port to perform a role seperate to its final state. For example, a designated port could temporarily be in the discarding state, even though its final state is to be forwarding. Port states and roles are able to change independently of each other. A useful example is that of the Alternate port, which is in a discarding (not transmitting data) state by default, but upon being needed, passes into the forwarding state.
• Per Vlan Spanning Tree: A network can run an STP instance for each VLAN in a network, which means that each VLAN has its own defined primary and secondary root bridges. This allows for extra redundancy.

That's all for now.