Whether we’re layer 2 or Layer 3 and (that’s core switching at Layer 2 & routing at layer 3), we love redundancy.
We’ve got to have a backup path, because a single point of failure for anything in today’s networks it’s just not acceptable. (A “single point of failure” is a point in the network where if one particular thing goes down, the entire network comes to a standstill.)
We can’t have a path go down between point A and Point B and there be no other path to get there. That said, there are important differences between L2 redundancy and L3 redundancy that we must be aware of.
L3 routing protocols allow us to use those secondary paths in addition to the primary paths, making equal – and unequal – cost load balancing possible.
With routing, we want to use as many of those paths as is feasible, as you’ll see in the OSPF and EIGRP sections.
At Layer2, our redundant paths need to be ready for action in case the primary path fails, but they will not be used in addition to the primary path. The basic purpose of the Spanning Tree Protocol (STP) is to identify valid loop-free paths and then choose the best of those paths for use.
STP will then block ports on the valid but less-desirable paths, holding those paths in standby. Should a primary path become unavailable, STP will realize this and begin to unblock the necessary ports to put the next-best path into action.
STP would analyse the port speeds in the following topology and makes a determination on which ports should be open and which should be closed in order to provide a loop-free network. STP also determines which ports should be opened in case a currently-open port goes down.
(If Cisco Exam is asking us a question about a switching loop or an L2 loop, they’re talking about spanning tree protocol)
Why is avoiding switching loops so sweet? Those loops cause serious issues, from the annoying to the highly critical:
- Due to MAC address table entries that will continually change, some or all frames will never reach their intended destination.
- Due to a lot of frame flooding, there’s an unnecessary strain put on our switch CPUs.
- There’s a larger chance of a broadcast storm, where our switches jus get pounded with broadcasts, to the point where they can’t perform their job.
- There’s a lot of wasted bandwidth.
Note: You’re going to hear about routing loops later in this course. Those happen at Layer 3, the network layer. STP has nothing to do with routing loops. STP runs strictly at L2 and is used to prevent switching loops. Watch that on exam day!
If a problem arises with an open port, STP runs the spanning-tree algorithm to recalculate the available paths and determine which port should be opened to compensate for the problematic port or ports. Those ports will go from blocking mode into forwarding mode, leaving one loop-free path between any two endpoints in our switching network.
There are intermediate STP stages that are built into the blocking-to-forwarding move that help guard against switching loops forming during the transition. We’ll cover all STP port modes in depth in this section; for now, just be aware that ports don’t go from blocking to forwarding in a heartbeat. (because if they did, we’ll have a flapping link which is a link that is up one moment and down the next, and you have the danger of a switching loop.)
So that’s all fine, you say, but what about those redundant paths? Why can’t we use every single path from “A” to “B” for switching, as we like to do for routing? Let’s have a look at a network where STP is not in use.
Note: Switching loops are something called “bridging loops”, even in networks that don’t have bridges. It’s a legacy term, and we always say “legacy” because we don’t like to say “old”.
Here we have two hosts at the top of our network ( Host A and Host B ) and two more at the bottom ( Host C and Host D ) and three switches all their upper ports are fast ethernet 0/1, all lower ports fast ethernet 0/2. HOST A is sending a frame to host C.
The three switches are all going to get a copy of that frame, and they’re all going to see it and they’ll say: “what do they do first?”
They look at the source MAC address of the incoming frame and say “Do I have an entry for that in my MAC address table?”
Now they’re going to make a note that Host A is off Fast ethernet 0/1, and then if they’ve just been turned on (which is another assumption we’re going to make), they will flood the frame that is destined for Host C, because we are assuming they do not have an entry for said host.
So you can see we end up having trouble with this particular typology because each switch is going to send a copy of that frame out their fast ethernet 0/2 ports. So each switch ends up getting a copy sent by a neighbouring switch, and the problem is the source MAC address for that is still going to be Host A. So now all three switches believe HOST A is actually found off fast Ethernet 0/2, and just that quickly we end up with a mess and we end up with a routing loop and that’s just going to keep happening.
We’re going to have these frames that continually get flooded out which tends to build up and it’s sucking up our bandwidth and the switches are having to work harder handling it all. And it’s the kind of thing that starts slowly because that’s what broadcast storms do. Things seem to be slowing down a little bit. Slowly but surely, more and more broadcast flooded traffic is forwarded by the switches. Finally, the switch is overwhelmed by those broadcasts, and we end up with what we call a broadcast storm.
STP helps to prevent those broadcast storms. In real-world networking, switching loop don’t occur often, because STP does a great job of preventing switching loops before they happen and we run into fewer broadcast storms than we used to. It all begins with the exchange of what we call Bridge Protocol Data Units (BPDUs)
BPDUs and The Root Bridge Election
STP will determine a root bridge for every VLAN in our network. And yes, your root bridges will be switches! (on your exam I expect the term root bridge to be used). The term root bridge goes back to STP’s pre-switch days, and the term stuck even after we moved from bridges to switches.
Root bridge election theory can be a little overwhelming the first time you see it, so after we cover a little bit of terminology, we’ll see the election in a two-switch network and then a walkthrough using three switches. Hang in there and you’ll knock every STP question out on exam day.
When a baby arrives in this world, that baby acts like it’s the centre of the universe. They yell, they scream, they expect to have every desire attended to immediately. (Some grow out of this; some do not.) In a similar fashion, when a switch is first powered on, it believes it’s the centre of your universe and believes it’s the root bridge for every VLAN on your network. We have to have some kind of selection process to decide who actually is true root bridge for each VLAN, and that selection is an election.
The election process is carried out via the exchange of Bridge Protocol Data Units (BPDUs). Switches are continually sending or forwarding BPDUs, but they’re the only network devices that do so. Other such devices we’ve talked about, from servers to routers and from hubs to repeaters, have nothing to do with BPDUs. It’s only going out between our switches.
There are two major BPDU types, configuration BPDUs and TCN BPDUs.
Config BPDUs are more commonly referred to as Hello BPDUs, or simply “BPDUs”, and that’s how I’ll refer to them here. TCN BPDUs are out of the scope of the CCNA exam.
Only the root bridge itself (once this election is taken place) will actually originate Hello BPDUs. The non-roots will receive and forward a copy of that BPDU, but non-root bridges do not actually create this BPDU type. The root bridge is also a switch that decides what the STP timers will be, and we’ll see that in action after we have an election.
Each switch has a Bridge ID, commonly referred to as a BID. The BID is a combination of a 2-byte Priority value and the switch’s 6-byte MAC address. The priority value comes first in the BID.
If a Cisco Switch has the default priority 32768 and a MAC address of 11-22-33-44-55-66, the resulting BID is 32768:11-22-33-44-55-66.
If the priority is left at the default on all switches, the MAC is the deciding factor in the root bridge election, and the switch with the lowest MAC address wins.
In any network, you’ll have switches that are more powerful than others in terms of processing power and speed. In general, you should ensure that your primary and your secondary root bridges are your more powerful switches. We don’t necessarily want to leave those roles to chance – or the lowest MAC address!
I’ll show you exactly how to be deterministic about root bridge elections after we walk through an example of a root bridge election using only the defaults.
The Root Bridge Election Process And STP Port States
This election is a simple process, where each switch is going to read the root bridge BID information in an incoming BPDU and simply compares that BID against its own. If the incoming root bridge BID is lower than that of the receiving switch, the receiving switch realizes that the switch that sent this BID is actually the root, and forwards the BPDU to let other switches know about it. In this case, the arriving BPDU is a superior BPDU.
If the incoming bid is higher than that of the receiving switch, the receiver will continue to announce itself as the root. A BPDU that carries a non-winning BID is an inferior BPDU.
This process continues until every switch in the network agrees on exactly which switch is the root. At this point, STP has reached a stage of convergence, a fancy way of saying “we all agree on the root”. When STP converges, every involved port on every switch will be either in forwarding mode or in blocking mode. Before we get to our labs, let’s have a look at all of the STP port stages.
The STP Port state disabled is a little odd in that you won’t see “DIS” next to a port in the output of show spanning vlan. Cisco does consider this to be an official STP state, so we will as well! A disabled port is simply a port that’s been administratively shut down. A disabled port isn’t forwarding frames or even officially running STP.
when STP puts a port into blocking mode, that port really can’t do much of anything. No frame forwarding, no frame receiving, and therefore no dynamic learning of MAC addresses.
About the only thing a blocked port can do is to accept BPDUs from neighbouring switches.
Here’s what’s going to look like:
SW2#show spanning vlan 40
Interface Role Sts Cost
———— —— —- —–
Fa0/11 Root FWD 19
Fa0/12 Altn BLK 19
shows spanning vlan 40 because we’re running per VLAN spanning tree and each VLAN has its own instance of STP, and you can see there the interface, the role (will talk about that) and under status once STP is Converged all you will see is FWD for Forwarding mode and be BLK for blocking mode.
When STP brings a port out of blocking mode, that port does not go just immediately to forwarding mode, because that would invite switching loop to form. Instead, when a port starts the transition from blocking to forwarding, it enters listening mode (LIS)
SW2#show spanning vlan40
Interface Role Sts Cost
———— —— —- —–
Fa0/11 Altn BLK 19
Fa0/12 Root LIS 9
The obvious question: “listening for what?”… A listening port is listening for BPDUs. A listening port can send BPDUs as well, allowing the port to participate in the root Bridge election. A port in listening mode still can’t forward or receive frames, and as a result the port itself cannot learn MAC addresses.
As that transition continues, the port goes from listening to learning mode (LRN) and this is exactly how you’ll see it.
SW2#show spanning vlan40
Interface Role Sts Cost
———— —— —- —–
Fa0/11 Altn BLK 19
Fa0/12 Root LIS 9
A learning port is not forwarding frames, but it is learning MAC addresses and adding them to the switch’s MAC Address table. A port in learning mode ontinues to send and receive BPDUs
Finally when all goes well, the port goes from learning to forwarding mode. Forwarding mode allows a port to forward and receive frames, send and receive BPDUs, and continue to learn MAC addresses.
Note that this is the only state where the port is actually forwarding frames and that is forwarding mode.
We’re about to walk through a root bridge election on a three-switch network, and we’ll take a look at the election from each switch’s point of view. Each switch has the default priority 32768, the MAC address of each switch is the switch’s number repeated 12 times.
All three switches are coming online at the same time, so all three of them believe that they’re the root bridge, and all three of them get very busy announcing that fact.
Since each switch believes that it’s the root, all six ports in this example will go to the listening state, allowing it to hear BPDUs from other switches. (Much more on these STP port states later in this section.) on your exam, in job interviews, and when dealing with production networks, you should be able to look at a diagram like the ones you’ll see in this section and answer this questions:
- Which bridge is the root?
- Which ports will the non-root bridges select as their root ports?
- Where are the designated ports?
- How many ports will STP block once convergence is achieved?
So let’s go ahead and dive in here:
We’re going to look at this election from Sw1’s point of view first…
It’s getting BPDUs from SW2 and SW3, but it’s looking at both of them and saying “Good to hear from you but my BID is lower than the bid that SW2 is sending me and the one SW3 is sending me.” So at this point SW1 continues to say “I am the root.” So any BPDUs it sends out, will announce itself as the root.
SW2 at the same time is going to be getting BPDUs from 1 and 3, and it’s going to look at SW3’s BPDU and say “hey my BID is lower than that. So no problem here I am still the root.” When that BPDU comes in from SW1, SW2 says “hey there’s a new king in town because this incoming BID is lower than my BID.”
So at this point SW2 would recognize SW1 as the root.
Now SW3 is about to get a massive inferiority complex, because SW3 is hearing from two different sources lower BIDs. It’s hearing a lower BID from SW2 and a lower BID from SW1.
But the thing is SW1’s BID is the lowest of all. So SW3 is going to get both of these BPDUs and say “OK SW1 is the boss (the root)”
But the thing is the root bridge election is a continual process. So if another device comes on line and says “ here’s my bid”, if it’s a lower BID than the current root, that new switch will indeed become the root.
Note that in the exam: SW4’s priority was set to 24568…and then all fours. So switch 4 comes online, sends that BPDU out and SW1 says” There’s another new king in town now because I’m hearing from a switch that has a lower bid”.
This example allowed you to see the details of a root bridge election, but in your production network, that election’s already taken place. For real-world networking success and victory on your CCNA exam, it’s a great idea to know how to see the BIDs of your live switches as well as spot the winner of a root bridge election that’s already taken place.
Leave feedback about this