Overview
In today's networks - heck, even in yesterday's networks - we love redundancy. A single point of failure just isn't acceptable today, so we're going to spend quite a bit of time in the SWITCH course learning how to create that redundancy when it doesn't already exist.
Basics Of LAN Switching
BPDUs
The Root Bridge Election
Root Port Selection And Cost
Default Root Port Costs
STP Port States
STP Timers
Making A Nonroot Switch The Root Bridge
Where Should The Root Bridge Be Located?
Topology Change Notification BPDU Operation
Load Sharing With The port-priority Command
The Extended System ID Feature
With our routing protocols such as EIGRP and OSPF, redundant paths can be used in addition to the primary path to perform equal-cost and/or unequal-cost load balancing. That's a desirable behavior with routing.
With switching, those redundant paths need to be ready to be put into action in case the primary path fails, but they won't be used in addition to the primary path. This is the responsibility of the Spanning Tree Protocol (STP, defined by IEEE 802.1d).
If you recently earned your CCNA, much of the first part of this section will seem familiar. If it's been a while since you studied STP, we'll get you back up to speed quickly - and then we'll all dive in to advanced STP features.
LAN Switching Basics
Switches use their MAC address table to switch frames, but when a switch is first added to a network, it has no entries in this table save for a few entries for the CPU.
The switch will dynamically build its MAC table by examining the source MAC address of incoming frames. (The source MAC address is the first thing the switch looks at on incoming frames.)
As the switch builds the MAC table, it quickly learns the hosts that are located off each port. But what if the switch doesn't know the correct port to forward a frame to? What if the frame is a broadcast or multicast?
Glad you asked!
Unknown unicast frames are frames destined for a particular host, but there is no MAC address table entry for that destination. Unknown unicast frames are forwarded out every port except the one they came in on. Under no circumstances will a switch send a frame back out the same port it came in on.
Broadcast frames are destined for all hosts, while multicast frames are destined for a specific group of hosts. Broadcast and multicast frames are also forwarded out every port except the one they came in on.
Known unicast frames are frames destined for a particular host, and this destination has an entry in the receiving switch's MAC table. Since we know the right port through which to forward the frame, there's no reason to send it out all ports, so this frame will be unicast via that port listed in
the MAC table.
To review:
Unknown unicast, broadcast, and multicast frames are forwarded out all ports except the one upon which they were originally received Known unicast frames are unicast via the port listed in the MAC address table
That all sounds nice and neat, right? For the most part, it is. But as we all know, production networks are rarely nice and neat. We don't want to have only one known path from "Point A" to "Point B".
We want redundancy - that is, if one path between two hosts is unusable, there should be a second path that is almost immediately available.
The problem is that with redundant links comes the possibility of a switching loop. The Spanning Tree Protocol (STP) helps to prevent switching loops from forming, but what if STP didn't exist? What if you decide to turn it off? Let's walk through what would happen in a switching network with redundant paths if STP did not exist.
Now this is redundancy! We've got three separate switches connecting two ethernet segments, so even if two separate switches become
unavailable, these hosts would be able to communicate. But we better have STP on to prevent switching loops.
If we didn't, what would happen? If Host A sends a frame to Host C, all three switches would receive the frame on their port 0/1. Since none of the switches would have an entry for Host A in their MAC tables, each switch would make an entry for that host, listing it as reachable via port 0/1.
None of the switches know where Host C is yet, so the switches will follow the default behavior for an unknown unicast address - they will flood the frame out all ports except the one it came in on. That includes port 0/2 on all three switches.
Just this quickly, without STP, we have a switching loop. Each switch will see the frames that the other two switches just forwarded out their port 0/2. The problem is that the source MAC address is still the address of Host A, but now the switches will each be receiving frames with that source MAC address on port 0/2.
Since all the switches had port 0/1 as the port for Host A, they'll now change that MAC address table listing to port 0/2 - and again flood the frame. The frames are just going to keep going in circles, and that's why we call it a switching loop, or bridging loop.
Switching loops cause three problems:
Frames can't reach their intended destination, either totally or in part Unnecessary strain put on CPU
Unnecessary use of bandwidth
Luckily for us, switching loops just don't occur that often, because STP does a great job of preventing switching loops before they can occur - and STP all begins with the exchange of Bridge Protocol Data Units (BPDUs).
The Role Of BPDUs
BPDUs are transmitted every two seconds to the well-known multicast MAC address 01-80-c2-00-00-00. (It might not have been well-known to
you before, but it is now!) We've actually got two different BPDU types:
Topology Change Notification (TCN)
Configuration
We'll talk about TCNs later in this section, but for now it's enough to know that the name is the recipe - a switch sends a TCN when there is a change in the network topology.
Configuration BPDUs are used for the actual STP calculations. Once a root bridge is elected, only that root bridge will originate Configuration BPDUs; the non-root bridges will forward copies of that BPDU.
BPDUs also carry out the election to decide which switch will be the Root Bridge. The Root Bridge is the "boss" of the switching network - this is the switch that decides what the STP values and timers will be. Each switch will have a Bridge ID Priority value, more commonly referred to as a BID.
This BID is a combination of a 2-byte Priority value and the 6-byte MAC address.
The BID has the priority value listed first. For example, if a Cisco switch has the default priority value of 32,768 and a MAC address of 11-22-33-44-55-66, the BID would be 32768:11-22-33-44-55-66. Therefore, if the switch priority is left at the default on all switches, the MAC address is the deciding factor in the root bridge election.
Is that a bad thing? Maybe...
Why You Should Care About The Winner Of This Election
Before we take a look at the root bridge election process itself, let's talk a bit about why we care which switch wins.
Cisco switches are equal, but some are more equal than others. In any network you're going to have switches that are more powerful than others when it comes to processing power and speed, and your root bridges are going to have a heavier workload than the non-root bridges.
Bottom line: Your most powerful switches, which are also hopefully centrally located in your network, should be your root bridges.
Note that I said "root bridges". Not only can we as the network admins determine which of our switches will be the primary root bridge, we can also determine the secondary root bridge - the switch that will become the root bridge if the primary root bridge goes down.
After we take a look at the important defaults of the root bridge election, along with several examples, I'll show you exactly how to configure any given Cisco switch in your network as the primary or secondary root bridge. As the network admins, it's you and I that should decide this election, rather than....
... well, let's see what happens without admin intervention!
The Default Root Bridge Election Process
Switches are a lot like people - when they first arrive, they announce that they are the center of the universe.
Unlike some people, the switches will soon get over it.
But seriously, folks, BPDUs will be exchanged between our switches until one switch is elected Root Bridge, and it's the switch with the lowest BID that will end up being the Root Bridge.
In this example, we'll look at a three-switch network and the Root Bridge election from each switch's point of view. Each switch is running the default priority of 32768, and the MAC address of each switch is the switch's letter 12 times. Through the magic of technology, all three switches are coming online at the same time, all three believe they are the root bridge, and all three get very busy announcing that fact.
Since each of these switches believe it's the root bridge, all six ports in this example will go to the listening state, allowing it to hear BPDUs from other switches.
More about those STP states later in the course - let's focus on the election for now.
SW A has a BID of 32768:aa-aa-aa-aa-aa-aa. That switch will receive BPDUs from both SW B and SW C, both containing their individual BIDs.
SW A will see that the BIDs it's getting from both of those switches are higher than its own, so SW A will continue to send BPDUs announcing itself as the Root Bridge.
SW B has a BID of 32768:bb-bb-bb-bb-bb-bb. SW B will receive the BIDs as shown, and since SW A is sending a lower BID than SW B's, SW B will recognize that SW A is the true Root Bridge, and SW B will then
recognize SW A as the root.
SW C is in the same situation. SW C will receive the BIDs as shown, and since SW A is sending a lower BID than SW C's, SW C will recognize that SW A is the Root Bridge.
Even though these switches have quickly agreed that SW A is the root, this election really never ends. If a new switch comes online and advertises a BID that is lower than SW A's. that switch would then become the root bridge.
In the following example, SW D has come online and has a BID lower than the current Root Bridge, SW A. SW D will advertise this BID via a BPDU to SW B, and SW B will realize that SW D should be the new root bridge. SW B will then announce this to the other switches, and soon SW D is indeed the root bridge. Since BPDUs are sent every two seconds, SW D will be seen as the new root bridge very quickly.
To see the local switch's BID, as well as that of the current root bridge, run show spanning-tree vlan x. We'll run this command with another network topology, this one a simple two-switch setup with two trunk links connecting the switches.
SW1#show spanning-tree vlan 1
VLAN0001
Spanning tree enabled protocol ieee Root ID Priority 32769
Address 000f.90e1.c240 This bridge is the root
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 32769 (priority 32768 sys-id-ext 1) Address 000f.90e1.c240
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec Aging Time 15
Interface Role Sts Cost Prio.Nbr Type
--- ---- --- --- --- ---
Fa0/11 Desg FWD 19 128.11 P2p Fa0/12 Desg FWD 19 128.12 P2p
There are actually four tip-offs in this readout that you're on the root bridge. The highlighted text is one - what are the other three?
The MAC address of the Root ID (indicating the root) and the Bridge ID (the info for the local switch) is the same
There is no root port on this switch. As you'd expect, the root port is the port a switch will use to reach the port. The root bridge doesn't need a root port, and therefore will not have one
All ports are in Forwarding (FWD) mode. No ports on the root bridge for a given VLAN will be in Blocking (BLK) mode.
What do things look like on the non-root bridge, you ask? Let's take a
look at the same command's output on SW2.
SW2#show spanning-tree vlan 1
VLAN0001
Spanning tree enabled protocol ieee Root ID Priority 32769
Address 000f.90e1.c240 Cost 19
Port 11 (FastEthernet0/11)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 32769 (priority 32768 sys-id-ext 1) Address 000f.90e2.1300
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec Aging Time 15
Interface Role Sts Cost Prio.Nbr Type
--- ---- --- --- --- ---
Fa0/11 Root FWD 19 128.11 P2p Fa0/12 Altn BLK 19 128.12 P2p
There are four tip-offs that you're not on the root bridge. One is highlighted. What are the other three?
No "this bridge is the root" message
The MAC address of the Root ID and Bridge ID fields are different, as shown
This bridge does have a root port (fast 0/11) There is a port in Blocking mode (BLK)
STP works by putting certain ports into Blocking mode, which in turn prevents switching loops from forming. Notice that only one port in our little two-switch network is in blocking mode, and in this case that's enough to leave only one available path between the switches. No ports on the root bridge will be put into blocking mode.
The port that SW2 is using to reach the root bridge is called the root port,
and it wasn't selected at random. Each switch port has an assigned path cost, and this path cost is used to arrive at the root path cost.
Yes, I hate it when two different values have practically the same name, too. Here's a very short chart to help you keep them straight:
Path cost: Assigned to an individual port. Strictly a local value and is not advertised to upstream or downstream switches. A port's Path Cost is assigned in accordance with the speed of the port - the faster the port, the lower the Path Cost.
Root path cost: Cumulative value reflecting the overall cost to get to the root. Is advertised to downstream switches via BPDUs.
The BPDU actually carries the Root Path Cost, and this cost increments as the BPDU is forwarded throughout the network. A port's Path Cost is locally significant only and is unknown by downstream switches.
The root bridge will transmit a BPDU with the Root Path Cost set to zero.
When a neighboring switch receives this BPDU, that switch adds the cost of the port the BPDU was received on to the incoming Root Path Cost.
Root Path Cost increments as BPDUs are received, not sent. That new root path cost value will be reflected in the BPDU that switch then sends out.
The Path Cost is locally significant only. In the previous example, SW3 doesn't have any idea what the Path Cost on SW2's receiving interface is, and doesn't particularly care. No switch downstream of SW3 will know of any Path Costs on SW2 or SW3 - the downstream switches will only see the cumulative cost, the Root Path Cost.
Let's go back to our two-switch example...
...the incoming Root Path Cost should be the same for both ports on SW2, since the two links are the same speed. Let's run show spanning-tree vlan 1 again to see what the deciding factor was.
SW2#show spanning-tree vlan 1
Interface Role Sts Cost Prio.Nbr Type
--- ---- --- --- --- ---
Fa0/11 Root FWD 19 128.11 P2p Fa0/12 Altn BLK 19 128.12 P2p
The costs are indeed the same, 19 for each port. (That's the default cost for a 100 Mbps port. Remember, the port cost is determined by the speed of the port.) SW2 is receiving BPDUs from SW1 on both ports 0/11 and 0/12, and one of those ports has to be chosen as the Root Port by SW2.
Here's the process of choosing a Root Port, and how these steps factored into SW2's decision-making process.
1. Choose the port receiving the superior BPDU. By "superior BPDU", we mean the one with the lowest Root BID. The BPDUs are coming from the same switch - SW1 - so this is a tie.
2. Choose the port with the lowest Root Path Cost to the root bridge. That's a tie here, too.
3. Choose the port receiving the BPDU with the lowest Sender BID. Since the same switch is sending both BPDUs, that's a tie here as well.
4. Choose the lowest sender Port ID. That was the tiebreaker here.
Using our three-router network, we can easily identify the root ports on both SW B and SW C. Both ports on SW A will be in forwarding mode, since this is the root bridge.
STP isn't quite done, though. A designated port needs to be chosen for the segment connecting SW B and SW C. Let's add a host to that segment to see why a designated port needs to be chosen.
Let's say that host is transmitting frames that need to be forwarded to SW A. There are two switches that can do this, but to prevent switching loops from possibly forming, we only want one switch to forward the frames.
That's where the Designated Port (DP) comes in. The switch that has the lowest Root Path Cost will have its port on this shared segment become the Designated Port.
Of course, there's a chance that both switches in this example would have the same Root Path Cost. In that case, the port belonging to the switch with the lowest BID will become the Designated Port. Additionally, all ports on the root bridge are considered Designated Ports.
Here's a clip from show spanning vlan 1 on our root bridge:
Fa0/11 Desg FWD 19 128.11 P2p Fa0/12 Desg FWD 19 128.12 P2p
Note that both ports are in "Desg" mode.
Assuming that SW B has a priority of 32768:bb-bb-bb-bb-bb-bb and SW C has a priority of 32768:cc-cc-cc-cc-cc-cc, port 0/2 on SW B would become a Designated Port, and port 0/1 on SW C would be placed into blocking mode.
It's interesting to note that of the six ports involved in our example, five are in forwarding mode and only one is blocked - but placing that one particular port into blocking mode prevents switching loops from forming.
Now we know how root bridges are elected - but this knowledge brings up a couple of interesting questions.
What if our least powerful switch is elected as the root bridge?
What if a switch on the very edge of the network is elected? (That's likely to be one of our least powerful switches, too.)
What if a switch on the very edge of the network is elected? (That's likely to be one of our least powerful switches, too.)