Broadcast Loops

Broadcasts and Layer 2 loops can be a dangerous combination.

Consider Figure 6-2.

Figure 6-2 Without STP, Broadcasts Create Feedback Loops

Assume that neither switch is running STP. Host-A begins by sending

out a frame to the broadcast MAC address (FF-FF-FF-FF-FF-FF) in
Step 1. Because Ethernet is a bus medium, this frame travels to both
Cat-1 and Cat-2 (Step 2).

When the frame arrives at Cat-1:Port-1/1, Cat-1 will follow the

standard bridging algorithm and flood the frame out Port 1/2 (Step 3).

1
Again, this frame will travel to all nodes on the lower Ethernet
segment, including Cat-2:Port1/2 (Step 4). Cat-2 will flood the
broadcast frame out Port 1/1 (Step 5) and, once again, the frame will
show up at Cat-1:Port-1/1 (Step 6). Cat-1, being a good little switch,
will follow orders and send the frame out Port 1/2 for the second time
(Step 7). By now I think you can see the pattern—there is a pretty
good loop going on here.

Additionally, notice that Figure 6-2 quietly ignored the broadcast that
arrived at Cat-2:Port-1/1 back in Step 2. This frame would have also
been flooded onto the bottom Ethernet segment and created a loop in
the reverse direction. In other words, don't forget that this "feedback"
loop would occur in both directions.

Bridge Table Corruption

Many switch/bridge administrators are aware of the basic problem of

broadcast storms as discussed in the previous section. However,
fewer people are aware of the fact that even unicast frames can
circulate forever in a network that contains loops. Figure 6-4
illustrates this point.

Figure 6-4 Without STP, Even Unicast Frames Can Loop and
Corrupt Bridging Tables

2
For example, suppose that Host-A, possessing a prior ARP entry for
Host-B, wants to send a unicast Ping packet to Host-B. However,
Host-B has been temporarily removed from the network, and the
corresponding bridge-table entries in the switches have been flushed
for Host-B. Assume that both switches are not running STP. As with
the previous example, the frame travels to Port 1/1 on both switches
(Step 2), but the text only considers things from Cat-1's point of view.
Because Host-C is down, Cat-1 does not have an entry for the MAC
address BB-BB-BB-BB-BB-BB in its bridging table, and it floods the
frame (Step 3). In Step 4, Cat-2 receives the frame on Port 1/2. Two
things (both bad) happen at this point:

1. Cat-2 floods the frame because it has never learned MAC

address BB-BB-BB-BB-BB-BB (Step 5). This creates a
feedback loop and brings down the network.
2. Cat-2 notices that it just received a frame on Port 1/2 with a
source MAC of AA-AA-AA-AA-AA-AA. It changes its bridging
entry for Host-A's MAC address to the wrong port!

As frames loop in the reverse direction (recall that the feedback loop
exists in both directions), you actually see Host-A's MAC address
flipping between Port 1/1 and Port 1/2.

3
Two Key Spanning-Tree Protocol Concepts

Spanning Tree calculations make extensive use of two key concepts

when creating a loop-free logical topology:

 Bridge ID (BID)
 Path Cost

Bridge IDs

Figure 6-5 The Bridge ID (BID) Is Composed of Bridge Priority

and a MAC Address

Path Cost

Bridges use the concept of cost to evaluate how close they are to
other bridges. 802.1D originally defined cost as 1000 Mbps divided by
the bandwidth of the link in Mbps. For example, a 10BaseT link has a
cost of 100 (1000/10), Fast Ethernet and FDDI use a cost of 10
(1000/100).

Table 6-1. STP Cost Values for Network Bridges

Bandwidth STP Cost
4 Mbps 250
10 Mbps 100
16 Mbps 62
45 Mbps 39
100 Mbps 19
155 Mbps 14

4
622 Mbps 6
1 Gbps 4
10 Gbps 2

Four-Step STP Decision Sequence

When creating a loop-free logical topology, Spanning Tree always

uses the same four-step decision sequence:

Step 1. Lowest Root BID

Step 2. Lowest Path Cost to Root Bridge

Step 3. Lowest Sender BID

Step 4. Lowest Port ID

Bridges pass Spanning Tree information between themselves using

special frames known as bridge protocol data units (BPDUs). A
bridge uses this four-step decision sequence to save a copy of the
best BPDU seen on every port. When making this evaluation, it
considers all of the BPDUs received on the port as well as the BPDU
that would be sent on that port. As every BPDU arrives, it is checked
against this four-step sequence to see if it is more attractive (that is,
lower in value) than the existing BPDU saved for that port. If the new
BPDU (or the locally generated BPDU) is more attractive, the old
value is replaced.

Tip

Bridges send configuration BPDUs until a more attractive

BPDU is received.

In addition, this "saving the best BPDU" process also controls the
sending of BPDUs. When a bridge first becomes active, all of its ports
are sending BPDUs every 2 seconds (when using the default timer

5
values). However, if a port hears a BPDU from another bridge that is
more attractive than the BPDU it has been sending, the local port
stops sending BPDUs. If the more attractive BPDU stops arriving
from a neighbor for a period of time (20 seconds by default), the local
port can once again resume the sending of BPDUs.

Note

There are actually two types of BPDUs: Configuration BPDUs

and Topology Change Notification (TCN) BPDUs. The first
half of this chapter only discusses Configuration BPDUs. The
second half discusses TCNs and the differences between the
two.

Three Steps of Initial STP Convergence

This section considers the algorithm that the Spanning-Tree Protocol

uses to initially converge on a loop-free logical topology. Although
there are many facets to the Spanning-Tree Protocol, the initial
convergence can be broken down into three simple steps:

Step 1. Elect one Root Bridge

Step 2. Elect Root Ports

Step 3. Elect Designated Ports

When the network first starts, all of the bridges are announcing a
chaotic mix of BPDU information. However, the bridges immediately
begin applying the four-step decision sequence discussed in the
previous section. This allows the bridges to hone in on the set of
BPDUs that form a single tree spanning the entire network. A single
Root Bridge is elected to act as the "center of the universe" for
this network (Step 1). All of the remaining bridges calculate a set
of Root Ports (Step 2) and Designated Ports (Step 3) to build a
loop-free topology. You can think of the resulting topology as a
wheel—the Root Bridge is the hub with loop-free active paths
(spokes) radiating outward. In a steady-state network, BPDUs flow
from the Root Bridge outward along these loop-free spokes to every
segment in the network.

6
After the network has converged on a loop-free active topology
utilizing this three-step process, additional changes are handled using
the Topology Change process. This subject is covered later in the
"Topology Change Process" section.

For the discussion that follows in the rest of the chapter, refer to
Figure 6-6 as the model layout of a three switches/bridges network.

Figure 6-6 Model Network Layout for Discussion of Basic STP

Operations

This network consists of three bridges connected in a looped

configuration. Each bridge has been assigned a fictitious MAC
address that corresponds to the device's name (for example, Cat-A
uses MAC address AA-AA-AA-AA-AA-AA).

Step One: Elect One Root Bridge

The switches first need to elect a single Root Bridge by looking for
the bridge with the lowest Bridge ID (BID). Remember, in "STP
economics", the lowest BID wins! This process of selecting the bridge
with the lowest BID often goes by the exciting title of a Root War.

Figure 6-7 The Network Must Select a Single Root Bridge

7
Okay, but how did the bridges learn that Cat-A had the lowest BID?
This is accomplished through the exchange of BPDUs. As discussed
earlier, BPDUs are special packets that bridges use to exchange
topology and Spanning Tree information with each other. By default,
BPDUs are sent out every two seconds. BPDUs are bridge-to-bridge
traffic; they do not carry any end-user traffic (such as Doom or, if you
are boring, e-mail traffic). Figure 6-8 illustrates the basic layout of a
BPDU. (BPDU formats are covered in detail in the "Two Types of
BPDUs" section.)

Figure 6-8 Basic BPDU Layout

For the purposes of the Root War, the discussion is only

concerned with the Root BID and Sender BID fields (again, the

8
real names come later). When a bridge generates a BPDU every 2
seconds, it places who it thinks is the Root Bridge at that instant in
time in the Root BID field. The bridge always places its own BID in
the Sender BID field.

Tip

Remember that the Root BID is the bridge ID of the current

Root Bridge, while the Sender BID is the bridge ID of the local
bridge or switch.

It turns out that a bridge is a lot like a human in that it starts out
assuming that the world revolves around itself. In other words, when
a bridge first boots, it always places its BID in both the Root BID and
the Sender BID fields. Suppose that Cat-B boots first and starts
sending out BPDUs announcing itself as the Root Bridge every 2
seconds. A few minutes later, Cat-C boots and boldly announces
itself as the Root Bridge. When Cat-C's BPDU arrives at Cat-B, Cat-B
discards the BPDU because it has a lower BID saved on its ports (its
own BID). As soon as Cat-B transmits a BPDU, Cat-C learns that it is
not quite as important as it initially assumed. At this point, Cat-C
starts sending BPDUs that list Cat-B as the Root BID and Cat-C as
the Sender BID. The network is now in agreement that Cat-B is the
Root Bridge.

Five minutes later Cat-A boots. As you saw with Cat-B earlier, Cat-A
initially assumes that it is the Root Bridge and starts advertising this
fact in BPDUs. As soon as these BPDUs arrive at Cat-B and Cat-C,
these switches abdicate the Root Bridge position to Cat-A. All three
switches are now sending out BPDUs that announce Cat-A as the
Root Bridge and themselves as the Sender BID.

Step Two: Elect Root Ports

After the bloodshed of the Root War is behind them, the switches
move on to selecting Root Ports. A bridge's Root Port is the port that
is closest to the Root Bridge. Every non-RootBridge must select one
Root Port.

9
 Tip

Every non-Root Bridge will select one Root Port.

As discussed earlier, bridges use the concept of cost to judge

closeness. Specifically, bridges track something called Root Path
Cost, the cumulative cost of all links to the Root Bridge. Figure 6-9
illustrates how this value is calculated across multiple bridges and the
resulting Root Port election process.

Figure 6-9 Every Non-Root Bridge Must Select One Root Port

When Cat-A (the Root Bridge) sends out BPDUs, they contain a Root
Path Cost of 0 (Step 1). When Cat-B receives these BPDUs, it adds
the Path Cost of Port 1/1 to the Root Path Cost contained in the
received BPDU. Assume the network is running Catalyst 5000 switch
code greater than version 2.4 and that all three links in Figure 6-9
are Fast Ethernet. Cat-B receives a Root Path Cost of 0 and adds in

10
Port 1/1's cost of 19 (Step 2). Cat-B then uses the value of 19
internally and sends BPDUs with a Root Path Cost of 19 out Port 1/2
(Step 3).

When Cat-C receives these BPDUs from Cat-B (Step 4), it increases
the Root Path Cost to 38 (19+19). However, Cat-C is also receiving
BPDUs from the Root Bridge on Port 1/1. These enter Cat-C:Port-1/1
with a cost of 0, and Cat-C increases the cost to 19 internally (Step
5). Cat-C has a decision to make: it must select a single Root Port,
the port that is closest to the Root Bridge. Cat-C sees a Root Path
Cost of 19 on Port 1/1 and 38 on Port 1/2—Cat-C:Port-1/1 becomes
the Root Port (Step 6). Cat-C then begins advertising this Root Path
Cost of 19 to downstream switches (Step 7).

Although not detailed in Figure 6-9, Cat-B goes through a similar set
of calculations: Cat-B:Port-1/1 can reach the Root Bridge at a cost of
19, whereas Cat-B:Port-1/2 calculates a cost of 38…Port-1/1
becomes the Root Port for Cat-B. Notice that costs are incremented
as BPDUs are received on a port.

Tip

Remember that STP costs are incremented as BPDUs are

received on a port, not as they are sent out a port.

For example, BPDUs arrive on Cat-B:Port-1/1 with a cost of 0 and get

increased to 19 "inside" Cat-B.."

Tip

Remember the difference between Path Cost and Root Path

Cost.

Path Cost is a value assigned to each port. It is added to

BPDUs received on that port to calculate the Root Path Cost.

Root Path Cost is defined as the cumulative cost to the Root

Bridge. In a BPDU, this is the value transmitted in the cost

11
 field. In a bridge, this value is calculated by adding the
receiving port's Path Cost to the value contained in the
BPDU.

Step Three: Elect Designated Ports

The loop prevention part of STP becomes obvious during the third
step of initial STP convergence: electing Designated Ports. Each
segment in a bridged network has one Designated Port. This port
functions as the single bridge port that both sends and receives traffic
to and from that segment and the Root Bridge. The idea is that if only
one port handles traffic for each link, all of the loops have been
broken! The bridge containing the Designated Port for a given
segment is referred to as the Designated Bridge for that segment.

As with the Root Port selection, the Designated Ports are chosen
based on cumulative Root Path Cost to the Root Bridge (see Figure
6-10).

Figure 6-10 Every Segment Elects One Designated Port Based

on the Lowest Cost

12
 To locate the Designated Ports, take a look at each segment in turn.
First look at Segment 1, the link between Cat-A and Cat-B. There are
2 bridge ports on the segment: Cat-A:Port-1/1 and Cat-B:Port-1/1.
Cat-A:Port-1/1 has a Root Path Cost of 0 (after all, it is the Root
Bridge), whereas Cat-B:Port-1/1 has a Root Path Cost of 19 (the
value 0 received in BPDUs from Cat-A plus the Path Cost of 19
assigned to Cat-B:Port1/1). Because Cat-A:Port-1/1 has the lower
Root Path Cost, it becomes the Designated Port for this link.

For Segment 2 (Cat-A to Cat-C link), a similar election takes place.

Cat-A:Port-1/2 has a Root Path Cost of 0, whereas Cat-C:Port-1/1
has a Root Path Cost of 19. Cat-A:Port-1/2 has the lower cost and
becomes the Designated Port. Notice that every active port on the
Root Bridge becomes a Designated Port. The only exception to this
rule is a Layer 1 physical loop to the Root Bridge (for example, you
connected two ports on the Root Bridge to the same hub or you
connected the two ports together with a crossover cable).

Now look at Segment 3 (Cat-B to Cat-C): both Cat-B:Port-1/2 and

Cat-C:Port-1/2 have a Root Path Cost of 19. There is a tie! When
faced with a tie (or any other determination), STP always uses the
four-step decision sequence discussed earlier in the section "Four-
Step STP Decision Sequence." Recall that the four steps are as
follows:

Step 1. Lowest Root BID

Step 2. Lowest Path Cost to Root Bridge

Step 3. Lowest Sender BID

Step 4. Lowest Port ID

In the example shown in Figure 6-10, all three bridges are in

agreement that Cat-A is the Root Bridge, causing Root Path Cost to
be evaluated next. However, as pointed out in the previous
paragraph, both Cat-B and Cat-C have a cost of 19. This causes BID,
the third decision criteria, to be the deciding factor. Because Cat-B's
BID (32,768.BB-BB-BB-BB-BB-BB) is lower than Cat-C's BID
(32,768.CC-CC-CC-CC-CC-CC), Cat-B:Port-1/2 becomes the

13
Designated Port for Segment 3. Cat-C:Port-1/2 therefore becomes a
non-Designated Port.

Initial STP Convergence Review

Before continuing, this section recaps the points already discussed.

Recall that switches go through three steps for their initial
convergence:

Step 1. Elect one Root Bridge

Step 2. Elect one Root Port per non-Root Bridge

Step 3. Elect one Designated Port per segment

First, the bridged network elects a single Root Bridge. Second, every
non-Root Bridge elects a single Root Port, the port that is the closest
to the Root Bridge. Third, the bridges elect a single Designated Port
for every segment.

Figure 6-12 Sample Network with Port States Identified

14
Table 6-4 documents the symbols used throughout the book to
represent Spanning Tree states.

Table 6-4. STP State and Port Symbols

State/Port Symbol
Blocking B
Forwarding F
Designated Port DP
Root Port RP
Non-Designated Port NDP

15
Figure 6-14 Using show spantree to Locate t he Root Bridge

1: af-5d-00 , 2: 1d-32-00, 3: 16-28-00 , 4: 52-ba-00

16
One Root Bridge, three Root Ports, and 404 Designated Ports (one
per segment, including the 400 segments connected to end users)

17
18
The network is partitioned into two halves. Each half elects its
own Root Bridge. There is a partial outage of approximately 50

19
seconds. After the Root Bridges have been established, connectivity
resumes within the two halves, but the two halves cannot
communicate.

Five STP States

After the bridges have classified their ports as Root, Designated, or

non-Designated, creating a loop-free topology is straightforward: Root
and Designated Ports forward traffic, whereas non-Designated Ports
block traffic. Although Forwarding and Blocking are the only two
states commonly seen in a stable network, Table 6-3 illustrates that
there are actually five STP states.

Table 6-3. STP States

State Purpose
Forwarding Sending/receiving user data

20
Learning Building bridging table
Listening Building "active" topology
Blocking Receives BPDUs only
Disabled Administratively down

As long as a port sees its own Configuration BPDU as the most

attractive, it continues sending Configuration BPDUs. A port begins
this process of sending Configuration BPDUs in what is called the
Listening state. Although BPDU processing is occurring during the
Listening state, no user traffic is being passed. After waiting for a
period of time defined by the Forward Delay parameter (default=15
seconds), the port moves into the Learning state. At this point, the
port starts adding source MAC addresses to the bridging table, but all
incoming data frames are still dropped. After another period equal to
the Forward Delay, the port finally moves into the Forwarding state
and begins passing end-user data traffic. However, if at any point
during this process the port hears a more attractive BPDU, it
immediately transitions into the Blocking state and stops sending
Configuration BPDUs.

21
Three STP Timers

The previous section mentioned that a bridge spends 15 seconds in

each of the Listening and Learning states by default. In all, the
Spanning-Tree Protocol is controlled by the three timers documented
in Table 6-5.

Table 6-5. STP Timers

Timer Primary Purpose Default
Hello Time Time between sending of Configuration BPDUs 2 Secs
by the Root Bridge
Forward Duration of Listening and Learning states 15
Delay Secs
Max Age Time BPDU stored 20
Secs

The explanation of the timers is as follows:

Hello timer: 2 seconds. This timer is used to determine how often the
root bridge sends
configuration BPDUs.
Maximum Age (Max Age): 20 seconds. This timer tells the bridge
how long to keep ports
in the blocking state before listening.
Forward Delay (Fwd Delay): 15 seconds. This timer determines how
long to stay in the
listening state before learning, and in the learning state before forwarding.

22
For example, assume that the Segment 3 link in Figure 6-12 uses a
hub and Cat-B:Port-1/2's transceiver falls out. Cat-C has no
immediate notification of the failure because it's still receiving
Ethernet link from the hub. The only thing Cat-C notices is that
BPDUs stop arriving. Twenty seconds (Max Age) after the failure,
Cat-C:Port-1/2 ages out the stale BPDU information that lists Cat-B
as having the best Designated Port for Segment 3. This causes Cat-
C:Port-1/2 to transition into the Listening state in an effort to become
the Designated Port. Because Cat-C:Port-1/2 now offers the most
attractive access from the Root Bridge to this link, it eventually
transitions all the way into Forwarding mode. In practice, it takes 50
seconds (20 Max Age + 15 Listening + 15 Learning) for Cat-C to take
over after the failure of Port 1/2 on Cat-B.

In some situations, bridges can detect topology changes on directly

connected links and immediately transition into the Listening state
without waiting Max Age seconds. For example, consider Figure 6-
13.

23
Figure 6-13 Failure of a Link Directly Connected to the Root Port
of Cat-C

In this case, Cat-C:Port-1/1 failed. Because the failure results in a

loss of link on the Root Port, there is no need to wait 20 seconds for
the old information to age out. Instead, Cat-C:Port-1/2 immediately

24
goes into Learning mode in an attempt to become the new Root Port.
This has the effect of reducing the STP convergence time from 50
seconds to 30 seconds (15 Listening + 15 Learning).

Tip

You can only modify the timer values from the Root Bridge.
Modifying the values on other bridges has no effect. However,
don't forget to update any "backup" Root Bridges.

Using Spanning Tree in Real-World Networks

Look at Figure 6-20 for a more complex topology, and see how all
this STP detail adds up in the real world.

Figure 6-20 A Complex Network with All Links Shown

25
26
Figure 6-20 illustrates a network of seven switches connected in a
highly redundant (that is, looped) configuration. Link costs are
indicated—all are Fast Ethernet (cost of 19) except for the vertical link
on the far left that is 10BaseT (cost of 100).

Assuming that Cat-4 wins the Root War, Figure 6-21 shows the
active topology that results.

Figure 6-21 Complex Network with Central Root Bridge and

Active Topology

27
28
The setup in Figure 6-21 clearly illustrates the basic objective of the
Spanning-Tree Protocol: make one bridge the center of the universe
and then have all other bridges locate the shortest path to that
location ("all roads lead to Rome"). This results in an active topology
consisting of spoke-like branches that radiate out from the Root
Bridge.

Notice that the Root Bridge is acting as the central switching station
for all traffic between the four branches and must be capable of
carrying this increased load. For example, Cat-7 and Cat-5 on
Branch-D must send all traffic through the Root Bridge (Cat-4) to
reach any of the other switches. In other words, don't use your
slowest bridge in place of Cat-4!

Figure 6-21 also illustrates the importance of a centrally located

Root Bridge. Consider the traffic between Host-A on Cat-7 and Host-
B on Cat-6. When these two users want to fire up a game of Doom,
the traffic must cross four bridges despite the fact that Cat-7 and Cat-
6 are directly connected. Although this might seem inefficient at first,
it could be much worse! For example, suppose Cat-1 happened to
win the Root War as illustrated in Figure 6-22.

Figure 6-22 Complex Network with Inefficient Root Bridge and

Active Topology

29
30
In this scenario, the network has converged into two branches with all
traffic flowing through the Root Bridge. However, notice how
suboptimal the flows are—Doom traffic between Host-A and Host-B
must now flow through all seven bridges!

Types of STP
So far, this chapter has discussed STP in terms of its operation to
prevent loops and to recover
from topology changes in a timely manner. STP was originally
developed to operate in a bridged
environment, basically supporting a single LAN (or one VLAN).
Implementing STP into a switched
environment has required additional consideration and modification to
support multiple VLANs.
Because of this, the IEEE and Cisco have approached STP
differently. This section reviews the three traditional types of STP that
are encountered in switched networks and how they relate to one
another. No specific configuration commands are associated with the
various types of STP. Rather,you need a basic understanding of how
they interoperate in a network.

Common Spanning Tree (CST)

The IEEE 802.1Q standard specifies how VLANs are to be trunked
between switches. It also
specifies only a single instance of STP for all VLANs. This instance is
referred to as the Common
Spanning Tree (CST). All CST BPDUs are transmitted over the native
VLAN as untagged frames.

Having a single STP for many VLANs simplifies switch configuration

and reduces switch CPU load during STP calculations. However,
having only one STP instance can cause limitations, too. Redundant
links between switches will be blocked with no capability for load
balancing. Conditions can also occur that would cause forwarding on
a link that does not support all VLANs, while other links would be
blocked.

Per-VLAN Spanning Tree (PVST)

31
Cisco has a proprietary version of STP that offers more flexibility than
the CST version. Per-VLAN
Spanning Tree (PVST) operates a separate instance of STP for each
individual VLAN. This allows the STP on each VLAN to be configured
independently, offering better performance and tuning for specific
conditions. Multiple Spanning Trees also make load balancing
possible over redundant links when the links are assigned to different
VLANs.

Due to its proprietary nature, PVST requires the use of Cisco Inter-
Switch Link (ISL) trunking
encapsulation between switches. In networks where PVST and CST
coexist, interoperability
problems occur. Each requires a different trunking method, so
BPDUs will never be exchanged between STP types.

Per-VLAN Spanning Tree Plus (PVST+)

Cisco has a second proprietary version of STP that allows devices to
interoperate with both PVST and CST. Per-VLAN Spanning Tree Plus
(PVST+) effectively supports three groups of STP operating in the
same campus network:

_ Catalyst switches running PVST

_ Catalyst switches running PVST+
_ Switches running CST over 802.1Q

To do this, PVST+ acts as a translator between groups of CST

switches and groups of PVST
switches. PVST+ can communicate directly with PVST by using ISL
trunks. To communicate with
CST, however, PVST+ exchanges BPDUs with CST as untagged
frames over the native VLAN.
BPDUs from other instances of STP (other VLANs) are propagated
across the CST portions of the network by tunneling. PVST+ sends
these BPDUs by using a unique multicast address so that the CST
switches forward them on to downstream neighbors without
interpreting them first. Eventually, the tunneled BPDUs reach other
PVST+ switches where they are understood.

32
33
34
35
36
Two Types of BPDUs

To this point, the chapter has referred to all BPDUs as a single type.
Actually, there are two types of BPDUs:

 Configuration BPDUs
 Topology Change Notification (TCN) BPDUs

Configuration BPDUs are originated by the Root Bridge and flow

outward along the active paths that radiate away from the Root

37
Bridge. Topology Change Notification BPDUs flow upstream (toward
the Root Bridge) to alert the Root Bridge that the active topology has
changed.

In addition to determining the path and direction of data forwarding, Root

and Designated Ports also play a key role in the sending of BPDUs. In short,
Designated Ports send Configuration BPDUs, whereas Root Ports send TCN
BPDUs.

Configuration BPDU Processing

Configuration BPDUs are sent in three cases. The discussion that

follows breaks these into two categories, normal processing and
exception processing. (This terminology is non-standard, but useful
for understanding how STP works.)

Normal Configuration BPDU Processing

Normal processing occurs every Hello Time seconds on all ports of

the Root Bridge (unless there is a physical layer loop). This results in
the origination of Configuration BPDUs at the Root Bridge.

Normal processing also occurs when a non-Root Bridge receives a

Configuration BPDU on its Root Port and sends an updated version
of this BPDU out every Designated Port. This results in the
propagation of Configuration BPDUs away from the Root Bridge and
throughout the entire Layer 2 network.

These two conditions account for the normal flow of Configuration

BPDUs that constantly stream away from the Root Bridge during
steady state processing. The Root Bridge originates Configuration
BPDUs on its Designated Ports every two seconds (the default value
of Hello Time). Note that every active port on the Root Bridge should
be a Designated Port unless there is a physical layer loop to multiple
ports on this bridge. As these Configuration BPDUs arrive at the Root
Ports of downstream bridges, these bridges then propagate
Configuration BPDUs on their Designated Ports. Figure 7-4

38
illustrates how this process propagates Configuration BPDUs away
from the Root Bridge.

Figure 7-4 Normal Sending of Configuration BPDUs

Figure 7-4 shows Cat-A, the Root Bridge, originating Configuration

BPDUs every two seconds. As these arrive on Cat-B:Port-1/1 (the
Root Port for Cat-B), Configuration BPDUs are sent out Cat-B's
Designated Ports, in this case Port 1/2.

Several observations can be made about the normal processing of

Configuration BPDUs:

 Configuration BPDUs flow away from the Root Bridge.

 Root Ports receive Configuration BPDUs.
 Root Ports do not send Configuration BPDUs.
 Blocking ports do not send Configuration BPDUs.
 If the Root Bridge fails, Configuration BPDUs stop flowing
throughout the network. This absence of Configuration BPDUs
continues until another bridge's Max Age timer expires and
starts taking over as the new Root Bridge.
 If the path to the Root Bridge fails (but the Root Bridge is still
active), Configuration BPDUs stop flowing downstream of the
failure. If an alternate path to the Root Bridge is available, this
absence of Configuration BPDUs continues until another path is
taken out of the Blocking state. If an alternate path to the Root
Bridge is not available, the bridged network has been
partitioned and a new Root Bridge is elected for the isolated
segment of the network.

Therefore, under the normal behavior, a non-Root Bridge only sends

Configuration BPDUs when a Root Bridge-originated BPDU arrives
on its Root Port.

39
Exception Configuration BPDU Processing

Exception Configuration BPDU processing, by contrast to normal

processing, occurs when a Designated Port hears an inferior BPDU
from some other device and sends a Configuration BPDU in
response. The Spanning Tree algorithm includes this exception
processing to squelch less attractive information as quickly as
possible and speed convergence. For example, consider Figure 7-5
where the Root Bridge failed (Step 1 in the figure) just before Cat-C
was connected to the Ethernet hub (Step 2 in the figure).

Figure 7-5 The Root Bridge Failed Just Before Cat-C Was
Connected

Figure 7-6 illustrates the conversation that ensues between Cat-C

and Cat-B.

Figure 7-6 Exception Processing of Configuration BPDUs

As discussed in Chapter 6, Cat-C initially assumes it is the Root

Bridge and immediately starts sending BPDUs to announce itself as

40
such. Because the Root Bridge is currently down, Cat-B:Port-1/2 has
stopped sending Configuration BPDUs as a part of the normal
processing. However, because Cat-B:Port-1/2 is the Designated Port
for this segment, it immediately responds with a Configuration BPDU
announcing Cat-A as the Root Bridge. By doing so, Cat-B prevents
Cat-C from accidentally trying to become the Root Bridge or creating
loops in the active topology.

The sequence illustrated in Figure 7-6 raises the following points

about Configuration BPDU exception processing:

 Designated Ports can respond to inferior Configuration BPDUs

at any time.
 As long as Cat-B saves a copy of Cat-A's information, Cat-B
continues to refute any inferior Configuration BPDUs.
 Cat-A's information ages out on Cat-B in Max Age seconds
(default=20 seconds). In the case of Figure 7-5, Cat-B begins
announcing itself as the Root Bridge at that time.
 By immediately refuting less attractive information, the network
converges more quickly. Consider what might happen if Cat-B
only used the normal conditions to send a Configuration
BPDU—Cat-C would have 20 seconds to incorrectly assume
that it was functioning as the Root Bridge and might
inadvertently open up a bridging loop. Even if this did not result
in the formation of a bridging loop, it could lead to unnecessary
Root and Designated Port elections that could interrupt traffic
and destabilize the network.
 Because Cat-D:Port-1/1 is not the Designated Port for this
segment, it does not send a Configuration BPDU to refute Cat-
C.

Tip

Configuration BPDUs are sent in three cases:

 When the Hello Timer expires (every two seconds by

default), the Root Bridge originates a Configuration
BPDU on every port (assuming no self-looped ports).
This is a part of the normal Configuration BPDU
processing.

41
  When non-Root Bridges receive a Configuration BPDU
on their Root Port, they send (propagate) updated
Configuration BPDUs on all of their Designated Ports
(normal processing).
 When a Designated Port hears an inferior Configuration
BPDU from another switch, it sends a Configuration
BPDU of its own to suppress the less attractive
information.

TCN BPDU Processing

Whereas Configuration BPDUs are the general workhorse of the STP

algorithm, TCN BPDUs perform a very specific role by assisting in
network recovery after changes in the active topology. When a non-
Root Bridge detects a change in the active topology, a TCN BPDU is
propagated upstream through the network until the Root Bridge is
reached. The Root Bridge then tells every bridge in the network to
shorten their bridge table aging periods from 300 seconds to the
interval specified by Forward Delay. In other words, TCN BPDUs are
used to tell the Root Bridge that the topology has changed so that
Configuration BPDUs can be used to tell every other bridge of the
event.

TCN BPDUs are sent in three cases. It is useful to group these into
two categories, change detection and propagation:

 Change detection—

Occurs in the event that a bridge port is put into the Forwarding
state and the bridge has at least one Designated Port. Change
detection also occurs when a port in the Forwarding or Learning
states transitions to the Blocking state.

 Propagation—

Occurs in the event that a non-Root Bridge receives a TCN

(from a downstream bridge) on a Designated Port.

42
The first two conditions categorized under change detection
constitute a change in the active topology that needs to be reflected
in bridging tables throughout the network. The last condition is used
to propagate TCN BPDUs up through the branches of the Spanning
Tree until they reach the Root Bridge.

Tip

TCN BPDUs are sent in three cases:

 When a port is put in the Forwarding state and the

bridge has at least one Designated Port (this is a part of
change detection).
 When a port is transitioned from the Forwarding or
Learning states back to the Blocking state (change
detection).
 When a TCN BPDU is received on Designated Port, it is
forwarded out the bridge's Root Port (propagation).

Several observations can be made about TCN BPDUs:

 TCN BPDUs are only sent out Root Ports.

 TCN BPDUs are the only BPDUs sent out Root Ports
(Configuration BPDUs are only sent out Designated Ports, not
Root Ports).
 TCN BPDUs are received by Designated Ports.
 TCN BPDUs flow upstream toward the Root Bridge.
 TCN BPDUs use a reliable mechanism to reach the Root
Bridge. When a bridge sends a TCN BPDU, it continues
repeating the BPDU every Hello Time seconds until the
upstream bridge acknowledges receipt with a Topology Change
Acknowledgement flag in a Configuration BPDU. TCN BPDUs
are not periodic in the same sense as Configuration BPDUs.
Other than the retransmission of already generated TCN
BPDUs discussed in the previous bullet and used as a reliability
mechanism, completely new TCN BPDUs are not sent until the
next topology change occurs (this could be hours, days, or
weeks later).

43
  TCN BPDUs are acknowledged even if the normal
Configuration BPDU processing discussed earlier has stopped
(because the flow of Configuration BPDUs from the Root Bridge
has stopped flowing).

Spanning tree operation requires that each switch have a unique BID. In the
original 802.1D
standard, the BID was composed of the Priority Field and the MAC address
of the switch, and
all VLANs were represented by a CST. Because PVST requires that a
separate instance of
spanning tree run for each VLAN, the BID field is required to carry
VLAN ID (VID)
information. This is accomplished by reusing a portion of the Priority
field as the extended
system ID to carry a VID.

To accommodate the extended system ID, the original 802.1D 16-bit Bridge
Priority field is
split into two fields, resulting in these components in the BID:


44
Bridge Priority: A 4-bit field still used to carry bridge priority. Because of
the limited bit
count, priority is now conveyed in discreet values in increments of 4096
rather than
discreet values in increments of 1, as they would be with the full 16-bit
field available. The
default priority, in accordance with IEEE 802.1D, is 32,768, which is the
midrange value.

Extended System ID: A 12-bit field carrying, in this case, the VID for
PVST.

MAC Address: A 6-byte field with the MAC address of a single switch.

By virtue of the MAC address, a BID is always unique. When the priority
and extended system
ID are appended to the switch MAC address, each VLAN on the switch can
be represented by a
unique BID.

If no priority has been configured, every switch will have the same default
priority, and the
election of the root for each VLAN will be based on the MAC address. This
is a fairly random
means of selecting the ideal root bridge; for this reason, it is advisable to
assign a lower priority
to the switch that should serve as root bridge.

45
Only four bits are now used to set the bridge priority. Because of the
limited bit count, priority is now configurable only in increments of
4096.
A switch responds with possible priority values if an incorrect value is
entered:
Switch(config)#spanning-tree vlan 1 priority 1234
% Bridge Priority must be in increments of 4096.
% Allowed values are:
0 4096 8192 12288 16384 20480 24576 28672
32768 36864 40960 45056 49152 53248 57344 61440
If no priority has been configured, every switch will have the same
default priority of
32768.
Assuming that all other switches are at default priority, the spanning-
tree vlan vlan-id
root primary command will set a value of 24576.
Assuming that all other switches are at default priority, the spanning-
tree vlan vlan-id
root secondary command will set a value of 28672.

46
The switch with the lowest BID becomes the root bridge for a VLAN.
Specific configuration
commands are used to determine which switch will become the root bridge.

A Cisco Catalyst switch running PVST maintains an instance of spanning

tree for each active
VLAN that is configured on the switch. A unique BID is associated with
each instance. For
each VLAN, the switch with the lowest BID becomes the root bridge for that
VLAN.
Whenever the bridge priority changes, the BID also changes. This results in
the recomputation
of the root bridge for the VLAN.

To configure a switch to become the root bridge for a specified VLAN, use
the command
spanning-tree vlan vlan-ID root primary.

47
A secondary root is a switch that may become the root bridge for a VLAN if
the primary root
bridge fails. To configure a switch as the secondary root bridge for the
VLAN, use the
command spanning-tree vlan vlan-ID root secondary. Assuming that the
other bridges in the
VLAN retain their default STP priority, this switch will become the root
bridge in the event that
the primary root bridge fails. This command can be executed on more
than one switch to
configure multiple backup root bridges.

Tuning the Root Path Cost

The Root Path Cost for each active port of a switch is determined by the
cumulative cost as a BPDU
travels along. As a switch receives a BPDU, the port cost of the receiving
port is added to the Root
Path Cost in the BPDU. The port or path cost is inversely proportional to the
port’s bandwidth. If
desired, a port’s cost can be modified from the default value.

48
Use the following interface configuration command to set a switch port’s
path cost:
Switch (config-if)# spanning-tree [vlan vlan-id] cost cost
If the vlan parameter is given, the port cost is modified only for the specified
VLAN. Otherwise, the
cost is modified for the port as a whole (all active VLANs). Table 10-2 lists
the cost value ranges
from 1 to 65,535, according to the standard IEEE values.

Tuning the Port ID

The fourth criteria of an STP decision is the Port ID. The Port ID value that
a switch uses is actually
a 16-bit quantity—8 bits for the Port Priority and 8 bits for the Port Number.
Port Priority is a value
from 0 to 255 and defaults to 128 for all ports. The Port Number can range
from 0 to 255 and
represents the port’s actual physical mapping. Port Numbers begin with 1 at
port 0/1 and increment
across each module. (The numbers might not be consecutive because each
module is assigned a
particular range of numbers.)

49
Obviously, switch port’s Port Number is fixed because it is based on
hardware location. The Port ID,
however, can be modified to influence an STP decision by using the Port
Priority. You can configure
the Port Priority with this interface configuration command:

Switch(config-if)# spanning-tree [vlan vlan-list] port-priority port-

priority

You can modify the Port Priority for a specific VLAN by using the vlan
parameter. Otherwise, the
Port Priority is set for the port as a whole (all active VLANs). The value of
port-priority can range
from 0 to 255 and defaults to 128.

Root Bridge Placement Load Balancing

Fortunately, one of the most effective load balancing techniques is

also the simplest. By carefully placing the Root Bridge for each VLAN
in different locations, data can be forced to follow multiple paths.
Each VLAN looks for the shortest path to its Root Bridge.

For example, Figure 7-10 adds load balancing to the network in

Figure 7-9.

50
This network contains two VLANs. Cat-A is the Root Bridge for VLAN
2, and Cat-B is the Root Bridge for VLAN 3. From Cat-C's
perspective, the available bandwidth to the servers has been
doubled. First, examine VLAN 2. Cat-C has two possible paths to the
Root Bridge: Cat-C:Port-1/1 can reach the Root Bridge with a cost of
19, whereas Cat-C:Port-1/2 can get there at a cost of 38. Obviously,
Port 1/1 is chosen as Cat-C's Root Port for VLAN 2. VLAN 3 also has
two paths to the Root Bridge, but this time the costs are reversed: 38
through Port 1/1 and 19 through Port 1/2. Therefore, VLAN 3's traffic
uses Cat-C:Port-1/2. Both links are active and carrying traffic.
However, if either link fails, Spanning Tree places all bandwidth on
the remaining link to maintain connectivity throughout the network.

Root Bridge Placement in Flat Networks

Although Root Bridge placement is appropriate for most well-

designed campus networks such as that shown in Figure 7-11, the
disadvantage is that many topologies do not support this approach.
This is especially true of non-hierarchical, flat-earth networks. In
some of these networks, traffic patterns are not clearly enough

51
defined (or understood) for this technique to be effective. In other
cases, the traffic between the VLANs is too similar.

As Chapter 15 discusses, the general rule of thumb in non-

hierarchical networks is that you should try to place your Root
Bridges in the path of your high-volume traffic flows. In the case
of flat-earth networks, this usually translates into locating the Root
Bridges as close to your servers as possible. Because end-station-to-
server farm traffic accounts for over 90 percent of the load on most
modern networks, this approach causes Spanning Tree to look for the
shortest paths where your load is heaviest. If you place the Root
Bridge at the other end of the network from your server farm, the
high-volume traffic might be forced to take a very inefficient path.

Therefore, the Root Bridge placement load balancing technique is

most effective in flat-earth networks where there is a clearly defined
server location for every VLAN. Simply place the Root Bridge on the
server farm switches and Spanning Tree naturally looks for the most
efficient path. Figure 7-12 illustrates such a network.

Figure 7-12 Root Bridge Placement Load Balancing Requires

Well-Defined Traffic Patterns

Part A of Figure 7-12 illustrates the physical topology and the

location of servers. The Sales department has its servers
attached to Cat-A, whereas the Human Resources department
has connected their servers to Cat-F. Part B of Figure 7-12

52
shows the active topology for the Sales VLAN. By placing the
Root Bridge at the servers, the Spanning Tree topology
automatically mirrors the traffic flow. Part C of Figure 7-12
shows the active topology for the Human Resources VLAN.
Again, the paths are optimal for traffic destined to the servers in
that VLAN. Consider what happens if the Root Bridges for both
VLANs are placed on Cat-F. This forces a large percentage of the
Sales VLAN's traffic to take an inefficient path through Cat-F.

A potential problem with using this technique is that the traffic

between the VLANs might be too similar. For example, what if a
single server farm handles the entire network? You are left with two
unappealing options. First, you could optimize the traffic flow by
placing all of the Root Bridges at the server farm, but this eliminates
all load balancing. Second, you could optimize for load balancing by
distributing the Root Bridges, but this creates unnecessary bridge
hops for traffic that is trying to reach the servers.

Implementing Root Bridge Placement

To implement Root Bridge placement load balancing, use the set

spantree priority command discussed in the "Manual Root Bridge
Placement: set spantree priority" section of Chapter 6. For
instance, load balancing could be achieved in Figure 7-12 with the
following commands:

Cat-A (enable) set spantree priority 100 2

Cat-F (enable) set spantree priority 100 3

The first command lowers the Bridge Priority on Cat-A to 100 for
VLAN 2 (the Sales VLAN) so that it wins the Root Bridge election. In

53
a similar fashion, the second command configures Cat-F to be the
Root Bridge for VLAN 3 (the Human Resources VLAN).

Port/VLAN Priority Load Balancing

Another topology where Root Bridge placement load balancing

does not work is with back-to-back switches or bridges. For
example, consider Figure 7-13.

Figure 7-13 Back-to-Back Switches Cannot Use Root Bridge

Placement Load Balancing

First, examine VLAN 2 as shown in Part A. Cat-A needs to pick a

single Root Port to reach Cat-B, the Root Bridge for VLAN 2. As
soon as Cat-A recognizes Cat-B as the Root Bridge, Cat-A
begins evaluating Root Path Cost. Because both Cat-A:Port-1/1
and Cat-A:Port-1/2 have a cost of 19 to the Root Bridge, there is

54
a tie. In an effort to break the tie, Cat-A considers the Sending
BID that it is receiving over both links. However, both ports are
connected to the same bridge, causing Cat-A to receive the
same Sending BID (100.BB-BB-BB-BB-BB-BB) on both links.
This results in another tie. Finally, Cat-A evaluates the Port ID
values received in Configuration BPDUs on both ports. Cat-
A:Port-1/1 is receiving a Port ID of 0x8001, and Cat-A:Port-1/2 is
receiving a Port ID of 0x8002. Cat-A chooses the lower value for
a Root Port, causing it to send all traffic out Port 1/1 while
Blocking on Port 1/2.

With VLAN 3 in Part B of Figure 7-13, the roles are reversed

but the outcome is the same—all traffic is passing over the left
link. In this case, it is Cat-B that must elect a Root Port to reach
the Root Bridge, Cat-A. Cat-B calculates identical values for
Root Path Cost and Sending BID as discussed in the previous
paragraph. To resolve the resulting tie, Cat-B evaluates the
received Port ID values, chooses Port 1/1 as the Root Port, and
places Port 1/2 in the Blocking state.

Although the Root Port selection and traffic flow is happening in

the opposing direction, both switches have selected Port 1/1 as
the Forwarding link. The result—the left link is carrying 100
percent of the traffic, and the right link is totally idle.

Note

Note that it is possible to implement load balancing in

Figure 7-13 by crossing the cables such that Cat-
B:Port-1/1 connects to Cat-A:Port-1/2 and Cat-B:Port-1/2
connects to Cat-A:Port-1/1. However, this approach is not
very scalable and can be difficult to implement in large
networks. Exercise 1 at the end of this chapter explores
this load balancing technique.

Although the network in Figure 7-13 fails to implement load

balancing, it does raise two interesting points. First, notice that
it is the non-Root Bridge that must implement load balancing.

55
Recall that all ports on the Root Bridge become Designated
Ports and enter the Forwarding state. Therefore, it is the non-
Root Bridge that must select a single Root Port and place the
other port in a Blocking state. It is precisely this decision
process that must be influenced to implement load balancing.

Second, it is the received values that are being used here. Cat-A
is not evaluating its own BID and Port ID; it is looking at the
values contained in the BPDUs being received from Cat-B.

Note

There is one case where the local Port ID is used. As

shown in Figure 7-14, imagine two ports on Cat-B
connecting to a hub that also connects to Cat-A, the Root
Bridge. In this case, the received Port ID is the same on
both ports of Cat-B. To resolve the tie, Cat-B needs to
evaluate its own local Port ID values (the lower Port ID
becomes the Root Port). This topology is obviously fairly
rare in modern networks and not useful for load
balancing purposes.

56
 Figure 7-14 Using the Local Port ID Value As a Tie-
Breaker

How does all this bit-twiddling cause traffic to flow across multiple
paths? Figure 7-16 redraws the VLANs originally presented in
Figure 7-13 to locate the Root Bridge for both VLANs on Cat-B.

Figure 7-16 Back-to-Back Switches: The Root Bridge for Both

VLANs Is on Cat-B

57
As was the case with Part A of Figure 7-13, the default
Configuration BPDUs received on Port 1/1 of Cat-A contains a Port
ID of 0x8001, but Port 1/2 receives the value 0x8002. Because
0x8001 is lower, Port 1/1 becames the Root Port for all VLANs by
default. However, if you lower VLAN 3's Port Priority to 31 on Cat-
B:Port-1/2, it lowers the Port ID that Cat-A:Port-1/2 receives for VLAN
3 to 0x7C01. Because 0x7C01 is less than 0x8001, Cat-A now elects
Port 1/2 as the Root Port for VLAN 3 and sends traffic over this link.
The syntax to implement this change is as follows:

Cat-B (enable) set spantree portvlanpri 1/2 31 3

Voilá, you have load balancing—VLAN 2 is using the left link and
VLAN 3 is using the right link.

Tip

Note that the portvlanpri value must be less than the value
specified by portpri.

58
By default, Cat-A is already sending traffic over the 1/1 link, so it is
not necessary to add any commands to influence this behavior.
However, it is probably a good idea to explicitly put in the command
so that you can document your intentions and avoid surprises later:

Cat-B (enable) set spantree portvlanpri 1/1 31 2

This command lowers Cat-B's Port Priority on Port 1/1 to 31 for VLAN
2 and reinforces Cat-A's default behavior of sending traffic over this
link for VLAN 2.

PortFast

PortFast is a feature that is primarily designed to optimize switch

ports that are connected to end-station devices. By using PortFast,
these devices can be granted instant access to the Layer 2 network.

PortFast works by making a fairly simple change in the STP

process. Rather than starting out at the bottom of the Blocking-
to-Listening-to-Learning-to-Forwarding hierarchy of states as
with normal STP, PortFast starts at the top. As soon as your
switch sees the link, the port is placed in the Forwarding state
(Catalyst 3000s actually spend one second in both Listening and
Learning, but who's counting?). If STP later detects that you
have a loop, it does all of the Root and Designated Port
calculations discussed earlier. If a loop is detected, the port is
put in the Blocking state.

This magic only occurs when the port first initializes. If the port
is forced into the Blocking state for some reason and later needs
to return to the Forwarding state, the usual Listening and
Learning processing is done.

Precautions for Using PortFast

You will probably run into people who recommend that you only
enable PortFast if it is absolutely necessary. The stern warning that
Catalysts issue when you enable this feature backs up this opinion:

59
Warning: Spantree port fast start should only be
enabled on ports connected
to a single host. Connecting hubs, concentrators,
switches, bridges, etc. to
a fast start port can cause temporary Spanning Tree
loops. Use with caution.

However, to the contrary, PortFast can actually improve the

stability of large networks! Recall the discussion of TCN BPDUs.
TCN BPDUs are sent every time a bridge detects a change in the
active topology to shorten the bridge table age-out time to the
Forward Delay interval. Do you really want to potentially flush
large sections of your bridging tables every time a user boots?
Probably not.

Tip

Use PortFast on your end-station ports. Not only does it avoid

problems when these devices boot, it reduces the amount of
Topology Change Notifications in your network.

Despite all of PortFast's benefits, you should not carelessly

enable it on every port. Only enable it on ports that connect to
workstations. Because servers rarely reboot (you hope), don't
enable it here.

Tip

One exception to the rule of not using PortFast on server

ports involves the use of fault-tolerant NICs. If you are
using one of these NICs that toggles link-state during
failover (most don't), you should enable PortFast on
these server ports.

60
Finally, you cannot use PortFast on trunk ports. Although
Catalysts allow the command to be entered on trunk links, it is
ignored. In short, PortFast is like any other power tool: it is
extremely useful, but only if used correctly.

Tip

Do not enable PortFast on looped ports

UplinkFast

UplinkFast is an exciting feature that Cisco rolled out in the 3.1 NMP
release. This exclusive feature (it is patented) allows wiring closet
switches to converge in two to three seconds!

The syntax for UplinkFast is even simpler than PortFast:

set spantree uplinkfast {enable | disable} [rate

station_update_rate]

You should only enable UplinkFast on IDF-like wiring closet

switches in correctly designed networks. UplinkFast is designed
to only operate on switches that are leaves (end nodes) in your
Spanning Tree. If you enable it in the core of you network, it
generally leads to unexpected traffic flows.

For example, consider Figure 7-22, the typical campus introduced

earlier.

Figure 7-22 A Typical Campus Network Using UplinkFast

61
Cat-D is an IDF switch that is connected to two MDF switches
(Cat-B and Cat-C). Although set spantree uplinkfast is a global
command that applies to all VLANs, this section only analyzes a
single VLAN: VLAN 2. Cat-A, the server farm switch, is the Root
Bridge for VLAN 2. Cat-D has two uplink ports that are potential
Root Port candidates. Utilizing the load balancing techniques
discussed earlier, the cost on Port 1/2 has been increased to

62
1000 to force VLAN 2's traffic across the 1/1 link. Notice that Port
1/1 becomes the Root Port. UplinkFast is then enabled on Cat-D with
the following command:

Cat-D> (enable) set spantree uplinkfast enable

This causes Cat-D to notice that Port 1/2 is Blocking and therefore
constitutes a redundant connection to the Root Bridge. By making a
note of this backup uplink port, Cat-D can set itself up for a quick
rollover in the event that Port 1/1 fails. The list of potential uplink ports
can be viewed with the show spantree uplinkfast command as in
Example 7-15.

It is important to recognize that UplinkFast is a Root Port

optimization. It allows wiring closet switches to quickly bring up
another Root Port in the event that the primary port fails.

Tip

UplinkFast is a Root Port optimization.

Therefore, it is futile to enable UplinkFast on a Root Bridge—

because Root Bridges contain no physical Root Ports there is
nothing for UplinkFast to optimize. In other words, only
implement this feature on leaf-node switches sitting at the ends
of the branches of your Spanning Tree. These leaf-node
switches should not be used as a transit switches to reach the
Root Bridge. So, as a general rule, only enable UplinkFast on
your IDF wiring closet switches.

Tip

Do not enable UplinkFast on every switch in your

network! Only enable UplinkFast on leaf-node Catalysts
such as your IDF switches.

63
To enforce the requirement of leaf-node status, Cisco modifies
several STP parameters when UplinkFast is enabled. Take a look at
the output of the set spantree uplinkfast command in Example 7-
16.

First, the Bridge Priority is modified to an unusually high value

of 49,152. This causes the current switch to effectively take itself
out of the election to become the Root Bridge. Second, it adds
3000 to the cost of all links. This is done to discourage other
switches from using the current switch as a transit switch to the
Root Bridge. Notice that neither of these actions limits STP
failover in your network. The Bridge Priority modification only
discourages other switches from electing this switch as the
Root Bridge. If the other switches fail, this switch happily
becomes the Root Bridge. Also, the increase to Path Cost only
discourages other switches from using the current switch as a
transit path to the Root Bridge. However, if no alternate paths
are available, the current switch gleefully transfers traffic to and
from the Root Bridge.

Notice the third line in the output in Example 7-16 (in bold).
This is evidence of a subtle trick that is the crux of what
UplinkFast is all about. It should probably be fairly obvious by
now that a failure on Cat-D:Port-1/1 forces Cat-D to take all MAC
addresses associated with Port 1/1 in the Bridging Table and
points them to Port 1/2. However, a more subtle process must
take place to convert the bridging tables in other switches. Why
is this extra step necessary? Figure 7-23 shows the network
with the left-hand link broken.

Figure 7-23 UplinkFast Behavior When the Primary Uplink Is

Lost

64
Cat-D changes MAC address 00-AA-00-12-34-56 (Host-A) to Port
1/2 so that it has a correct view of the network. However, notice
that Cat-A, Cat-B, and Cat-C are still trying to send traffic for 00-
00-1D-2B-DE-AD (Host-B) to the broken link! This is where the
real ingenuity of UplinkFast comes in: Cat-D sends out a dummy
multicast frame for the addresses in its local Bridging Table.
One frame is sent for each MAC address that is not associated
with one of the uplink ports. These packets are sent to a
multicast 01-00-0C-CD-CD-CD destination address to ensure that
they are flooded throughout the bridged network. Recall from
Chapter 3 that multicast addresses are flooded as with broadcast
frames. However, note that Cisco does not use the traditional
multicast address of 01-00-0C-CC-CC-CC. Because this multicast
address is reserved for single hop protocols such as Cisco Discovery
Protocol (CDP), VLAN Trunk Protocol (VTP), Dynamic ISL (DISL),
and Dynamic Trunk Protocol (DTP), Cisco devices have been

65
programmed to not flood the 01-00-0C-CC-CC-CC. To avoid this
behavior, a new multicast address needed to be introduced.

Each frame contains the source address of a different entry in the

local Bridging Table. As these packets are flooded through the
network, all of the switches and bridges make a note of the new
interface the frame arrived on and, if necessary, adjust their bridging
tables. By default, the Catalyst sends 15 of these dummy frames
every 100 milliseconds, but this rate can be adjusted with the
[rate station_update_rate] parameter (the number represents
how many dummy updates to send every 100 milliseconds).

However, adjusting the rate parameter usually does not improve

failover performance. Notice that only MAC addresses not learned
over the uplinks are flooded. Because UplinkFast only runs on leaf-
node switches where the vast majority of the MAC addresses in the
bridging table are associated with the uplink ports, usually only a few
hundred addresses require flooding. The default rate floods 450 to
600 addresses in the 3–4 second UplinkFast convergence period.
Therefore, it only makes sense to increase the rate if you have more
than about 500 devices connected to your wiring closet switch.

UplinkFast is an extremely effective and useful feature. It provides

much faster convergence than any of the timer tuning techniques
discussed earlier and is much safer. As long as you only deploy it in
leaf-node switches, it can be a wonderful way to maintain the safety
of STP while dramatically improving failover times in most situations.

BackboneFast

BackboneFast is a complementary (and patented) technology to

UplinkFast. Whereas UplinkFast is designed to quickly respond
to failures on links directly connected to leaf-node switches, it
does not help in the case of indirect failures in the core of the
backbone. This is where BackboneFast comes in.

Don't expect BackboneFast to provide the two to three second

rollover performance of UplinkFast. As a Max Age optimization,
BackboneFast can reduce the indirect failover performance from
50 to 30 seconds (with default parameters; and from 14 to 8
seconds with the tunable values set their minimums). However,

66
it never eliminates Forwarding Delay and provides no assistance
in the case of a direct failure (recall from the "Tuning Max Age"
section that direct failures do not use Max Age).

Tip

BackboneFast is a Max Age optimization. It allows the

default convergence time for indirect failures to be
reduced from 50 seconds to 30 seconds.

As discussed in the previous section, UplinkFast should only be

enabled on a subset of all switches in your network (leaf-node,
wiring closet switches). On the other hand, BackboneFast
should be enabled on every switch in your network. This allows
all of the switches to propagate information about link failures
throughout the network.

Tip

BackboneFast should be enabled on every switch in your

network.

When a device detects a failure on the link directly connected to its

Root Port, the normal rules of STP dictate that it begin sending
Configuration BPDUs in an attempt to become the Root Bridge. What
other devices do with these Configuration BPDUs depends on where
the Designated Ports are located. If a Designated Port hears these
inferior BPDUs, it immediately refutes them with a Configuration
BPDU as discussed in the "Configuration BPDU" section earlier.
If a non-Designated Port receives the inferior BPDU, it is
ignored. However, in either case, the 802.1D standard does not
provide a mechanism that allows switches receiving inferior
BPDUs to make any judgments about the state of the network.

67
How does BackboneFast magically eliminate Max Age from the
STP convergence delay? By taking advantage of the following
two mechanisms:

 The first allows switches to detect a possible indirect

failure.
 The second allows them to verify the failure.

The BackboneFast detection mechanism is built around the

concept that inferior BPDUs are a signal that another bridge
might have lost its path to the Root Bridge. BackboneFast's
verification mechanism employs a request and response
protocol that queries other switches to determine if the path to
the Root Bridge has actually been lost. If this is the case, the
switch can expire its Max Age timer immediately, reducing the
convergence time by 20 seconds.

To detect the possible failure of the Root Bridge path,

BackboneFast checks the source of the inferior BPDU. If the
BPDU is from the local segment's Designated Bridge, this is
viewed as a signal of an indirect failure. If the inferior BPDU
came from another switch, it is discarded and ignored.

The verification process is more complex than the detection

process. First, BackboneFast considers if there are alternate
paths to the Root Bridge. If the switch receiving an inferior
BPDU has no ports in the Blocking state (ports looped to itself
are excluded), it knows that it has no alternate paths to the Root
Bridge. Because it just received an inferior BPDU from its
Designated Bridge, the local switch can recognize that it has lost
connectivity to the Root Bridge and immediately expire the Max
Age timer.

If the switch does have blocked ports, it must utilize a second

verification mechanism to determine if those alternate paths
have lost connectivity to the Root Bridge. To do this, the
Catalysts utilize a Root Link Query (RLQ) protocol. The RLQ
protocol employs two types of packets—RLQ Requests and RLQ
Responses.

68
RLQ Requests are sent to query upstream bridges if their connection
to the Root Bridge is stable. RLQ Responses are used to reply to
RLQ Requests. The switch that originates the RLQ Request sends
RLQ frames out all non-Designated Ports except the port that
received the inferior BPDU. A switch that receives an RLQ Request
replies with an RLQ Response if it is the Root Bridge or it knows that
it has lost its connection to the Root Bridge. If neither of these
conditions is true, the switches propagate the RLQ Requests out their
Root Ports until the stability of the Root Bridge is known and RLQ
Responses can be sent. If the RLQ Response is received on an
existing Root Port, the switch knows that its path to the Root Bridge is
stable. On the other hand, if the RLQ Response is received on some
port other than the current Root Port, it knows that it has lost its
connection to the Root Bridge and can immediately expire the Max
Age timer. A switch propagates BPDUs out all Designated Ports until
the switch that originated the RLQ Request is reached.

To illustrate this process, consider the simplified campus network

shown in Figure 7-24.

Figure 7-24 BackboneFast Operation

69
As discussed earlier, BackboneFast must be enabled on all three
switches in this network. Assume that Cat-A is the Root Bridge. This
results in Cat-B:Port-1/2 and Cat-C:Port-1/1 becoming Root Ports.
Because Cat-B has the lower BID, it becomes the Designated Bridge
for Segment 3, resulting in Cat-C:Port-1/2 remaining in the Blocking
state.

Next, assume that Segment 1 fails. Cat-A and Cat-B, the

switches directly connected to this segment, instantly know that
the link is down. To repair the network, it is necessary that Cat-
C:Port-1/2 enter the Forwarding state. However, because
Segment 1 is not directly connected to Cat-C, Cat-C does not
start sending any BPDUs on Segment 3 under the normal rules
of STP until the Max Age timer has expired.

BackboneFast can be used to eliminate this 20-second delay

with the following eight-step process (illustrated in Figure 7-
25):

Figure 7-25 BackboneFast Steps to Eliminating the 20-Second

Delay

70
Step 1. Segment 1 breaks.

Step 2. Cat-B immediately withdraws Port 1/2 as its Root Port and
begins sending Configuration BPDUs announcing itself as the new
Root Bridge on Port 1/1. This is a part of the normal STP behavior
(Steps 3–7 are specific to BackboneFast).

Step 3. Cat-C:Port-1/2 receives the first Configuration BPDU from

Cat-B and recognizes it as an inferior BPDU.

Step 4. Cat-C then sends an RLQ Request out Port 1/1.

Step 5. Cat-A:Port-1/1 receives the RLQ Request. Because Cat-A is

the Root Bridge, it replies with an RLQ Response listing itself as the
Root Bridge.

Step 6. When Cat-C receives the RLQ Response on its existing Root
Port, it knows that it still has a stable connection to the Root Bridge.

71
Because Cat-B originated the RLQ Request, it does not need to
forward the RLQ Response on to other switches.

Step 7. Because Cat-C has a stable connection to the Root Bridge, it

can immediately expire the Max Age timer on Port-1/2.

Step 8. As soon as the Max Age timer expires in Step 7, the normal
rules of STP require Port Cat-C:Port-1/2 to start sending
Configuration BPDUs. Because these BPDUs list Cat-A as the Root
Bridge, Cat-B quickly learns that it is not the Root Bridge and it has
an alternate path to Cat-A.

Although this allows Cat-B to learn about the alternate path to the
Root Bridge within several seconds, it still requires that Cat-C:Port-
1/2 go through the normal Listening and Learning states (adding 30
seconds of delay to the convergence with the default values and 8
seconds with the minimum value for Forward Delay).

72
73