FIGURE 15.2
A switched network with switching loops
This is a switched network with a redundant topology that includes
switching loops. Without some type of layer 2 mechanism in place to
prevent a network loop, this network is vulnerable to nasty issues like
broadcast storms, multiple frame copies, and MAC table thrashing!
Figure 15.3
shows how this network would work with STP working on the
switches.
FIGURE 15.3
A switched network with STP
There a few types of spanning-tree protocols, but I’ll start with the IEEE
version 802.1d, which happens to be the default on all Cisco IOS
switches.
Spanning-Tree Terms
Now, before I get into describing the details of how STP works within a
network, it would be good for you to have these basic ideas and terms
down first:
Root bridge The root bridge is the bridge with the lowest and,
therefore, the best bridge ID. The switches within the STP network elect a
root bridge, which becomes the focal point in the network. All other
decisions in the network, like which ports on the non-root bridges should
be blocked or put in forwarding mode, are made from the perspective of
the root bridge, and once it has been elected, all other bridges must create
a single path to it. The port with the best path to the root bridge is called
the root port.
Non-root bridges These are all bridges that aren’t the root bridge. Non-
root bridges exchange BPDUs with all the other bridges and update the
STP topology database on all switches. This prevents loops and helps
defend against link failures.
BPDU All switches exchange information to use for the subsequent
configuration of the network. Each switch compares the parameters in
the Bridge Protocol Data Unit (BPDU) that it sends to a neighbor with
the parameters in the BPDU that it receives from other neighbors. Inside
the BPDU is the bridge ID.
Bridge ID The bridge ID is how STP keeps track of all the switches in
the network. It’s determined by a combination of the bridge priority,
which is 32,768 by default on all Cisco switches, and the base MAC
address. The bridge with the lowest bridge ID becomes the root bridge in
the network. Once the root bridge is established, every other switch must
make a single path to it. Most networks benefit by forcing a specific
bridge or switch to be on the root bridge by setting its bridge priority
lower than the default value.
Port cost Port cost determines the best path when multiple links are
used between two switches. The cost of a link is determined by the
bandwidth of a link, and this path cost is the deciding factor used by
every bridge to find the most efficient path to the root bridge.
Path cost A switch may encounter one or more switches on its path to
the root bridge, and there may be more than one possible path. All unique
paths are analyzed individually, and a path cost is calculated for each
unique path by adding the individual port costs encountered on the way
to the root bridge.
Bridge Port Roles
STP uses roles to determine how a port on a switch will act within the
spanning-tree algorithm.
Root port The root port is the link with the lowest path cost to the root
bridge. If more than one link connects to the root bridge, then a port cost
is found by checking the bandwidth of each link. The lowest-cost port
becomes the root port. When multiple links connect to the same device,
the port connected to the lowest port number on the upstream switch will
be the one that’s used. The root bridge can never have a root port
designation, while every other switch in a network must have one and
only one root port.
Designated port A designated port is one that’s been determined to
have the best (lowest) cost to get to on a given network segment,
compared to other ports on that segment. A designated port will be
marked as a forwarding port, and you can have only one forwarding port
per network segment.
Non-designated port A non-designated port is one with a higher cost
than the designated port. These are basically the ones left over after the
root ports and designated ports have been determined. Non-designated
ports are put in blocking or discarding mode—they are not forwarding
ports!
Forwarding port A forwarding port forwards frames and will be either
a root port or a designated port.
Blocked port A blocked port won’t forward frames in order to prevent
loops. A blocked port will still always listen to BPDU frames from
neighbor switches, but it will drop any and all other frames received and
will never transmit a frame.
Alternate port This corresponds to the blocking state of 802.1d and is a
term used with the newer 802.1w (Rapid Spanning Tree Protocol). An
alternative port is located on a switch connected to a LAN segment with
two or more switches connected, and one of the other switches holds the
designated port.
Backup port This corresponds to the blocking state of 802.1d and is a
term now used with the newer 802.1w. A backup port is connected to a
LAN segment where another port on that switch is acting as the
designated port.
Spanning-Tree Port States
Okay, so you plug your host into a switch port and the light turns amber
and your host doesn’t get a DHCP address from the server. You wait and
wait and finally the light goes green after almost a full minute—that’s an
eternity in today’s networks! This is the STA transitioning through the
different port states verifying that you didn’t just create a loop with the
device you just plugged in. STP would rather time out your new host than
allow a loop into the network because that would effectively bring your
network to its knees. Let’s talk about the transition states; then later in
this chapter we’ll talk about how to speed this process up.
The ports on a bridge or switch running IEEE 802.1d STP can transition
through five different states:
Disabled (technically, not a transition state) A port in the
administratively disabled state doesn’t participate in frame forwarding or
STP. A port in the disabled state is virtually nonoperational.
Blocking As I mentioned, a blocked port won’t forward frames; it just
listens to BPDUs. The purpose of the blocking state is to prevent the use
of looped paths. All ports are in blocking state by default when the switch
is powered up.
Listening This port listens to BPDUs to make sure no loops occur on the
network before passing data frames. A port in listening state prepares to
forward data frames without populating the MAC address table.
Learning The switch port listens to BPDUs and learns all the paths in
the switched network. A port in learning state populates the MAC address
table but still doesn’t forward data frames. Forward delay refers to the
time it takes to transition a port from listening to learning mode, or from
learning to forwarding mode, which is set to 15 seconds by default and
can be seen in the
show spanning-tree
output.
Forwarding This port sends and receives all data frames on the bridged
port. If the port is still a designated or root port at the end of the learning
state, it will enter the forwarding state.
Switches populate the MAC address table in learning and
forwarding modes only.
Switch ports are most often in either the blocking or forwarding state. A
forwarding port is typically the one that’s been determined to have the
lowest (best) cost to the root bridge. But when and if the network
experiences a topology change due to a failed link or because someone
has added in a new switch, you’ll see the ports on a switch transitioning
through listening and learning states.
As I said earlier, blocking ports is a strategy for preventing network loops.
Once a switch determines the best path to the root bridge for its root port
and any designated ports, all other redundant ports will be in blocking
mode. Blocked ports can still receive BPDUs—they just don’t send out
any frames.
If a switch determines that a blocked port should become the designated
or root port because of a topology change, it will go into listening mode
and check all BPDUs it receives to make sure it won’t create a loop once
the port moves into forwarding mode.
Convergence
Convergence occurs when all ports on bridges and switches have
transitioned to either forwarding or blocking modes. No data will be
forwarded until convergence is complete. Yes—you read that right: When
STP is converging, all host data stops transmitting through the switches!
So if you want to remain on speaking terms with your network’s users, or
remain employed for any length of time, you must make sure that your
switched network is physically designed really well so that STP can
converge quickly!
Convergence is vital because it ensures that all devices have a coherent
database. And making sure this happens efficiently will definitely require
your time and attention. The original STP (802.1d) takes 50 seconds to go
from blocking to forwarding mode by default and I don’t recommend
changing the default STP timers. You can adjust those timers for a large
network, but the better solution is simply to opt out of using 802.1d at all!
We’ll get to the various STP versions in a minute.
Link Costs
Now that you know about the different port roles and states, you need to
really understand all about path cost before we put this all together. Port
cost is based on the speed of the link, and
Table 15.1
breaks down the
need-to-know path costs for you. Port cost is the cost of a single link,
whereas path cost is the sum of the various port costs to the root bridge.
Table 15.1
IEEE STP link costs
Speed
Cost
10 Mb/s
100
100 Mb/s
19
1000 Mb/s
4
10,000 Mb/s 2
These costs will be used in the STP calculations to choose a single root
port on each bridge. You absolutely need to memorize this table, but no
worries—I’ll guide you through lots of examples in this chapter to help
you do that quite easily! Now it’s time to take everything we’ve learned so
far and put it all together.
Spanning-Tree Operations
Let’s start neatly summarizing what you’ve learned so far using the
simple three-switch network connected together as shown in
Figure 15.4
.
FIGURE 15.4
STP operations
Basically, STP’s job is to find all the links in the network and shut down
any redundant ones, thereby preventing network loops from occurring. It
achieves this by first electing a root bridge that will have all ports
forwarding and will also act as a point of reference for all other devices
within the STP domain. In
Figure 15.4
, S1 has been elected the root
bridge based on bridge ID. Since the priorities are all equal to 32,768,
we’ll compare MAC addresses and find that the MAC address of S1 is
lower than that of S2 and S3, meaning that S1 has a better bridge ID.
Once all switches agree on the root bridge, they must then determine
their one and only root port—the single path to the root bridge. It’s really
important to remember that a bridge can go through many other bridges
to get to the root, so it’s not always the shortest path that will be chosen.
That role will be given to the port that happens to offer the fastest,
highest bandwidth.
Figure 15.5
shows the root ports for both non-root
bridges (the RP signifies a root port and the F signifies a designated
forwarding port).
FIGURE 15.5
STP operations
Looking at the cost of each link, it’s clear why S2 and S3 are using their
directly connected links, because a gigabit link has a cost of 4. For
example, if S3 chose the path through S2 as its root port, we’d have to add
up each port cost along the way to the root, which would be 4 + 4 for a
total cost of 8.
Every port on the root bridge is a designated, or forwarding, port for a
segment, and after the dust settles on all other non-root bridges, any port
connection between switches that isn’t either a root port or a designated
port will predictably become a non-designated port. These will again be
put into the blocking state to prevent switching loops.
Okay—at this point, we have our root bridge with all ports in forwarding
state and we’ve found our root ports for each non-root bridge. Now the
only thing left to do is to choose the one forwarding port on the segment
between S2 and S3. Both bridges can’t be forwarding on a segment
because that’s exactly how we would end up with loops. So, based on the
bridge ID, the port with the best and lowest would become the only
bridge forwarding on that segment, with the one having the highest,
worst bridge ID put into blocking mode.
Figure 15.6
shows the network
after STP has converged.
FIGURE 15.6
STP operations
Since S3 had a lower bridge ID (better), S2’s port went into blocking
mode. Let’s discuss the root bridge election process more completely
now.
Selecting the Root Bridge
The bridge ID is used to elect the root bridge in the STP domain and to
determine the root port for each of the remaining devices when there’s
more than one potential root port available because they have equal-cost
paths. This key bridge ID is 8 bytes long and includes both the priority
and the MAC address of the device, as illustrated in
Figure 15.7
.
Remember—the default priority on all devices running the IEEE STP
version is 32,768.
FIGURE 15.7
STP operations
So, to determine the root bridge, you combine the priority of each bridge
with its MAC address. If two switches or bridges happen to have the same
priority value, the MAC address becomes the tiebreaker for figuring out
which one has the lowest and, therefore, best ID. This means that because
the two switches in
Figure 15.7
are both using the default priority of
32,768, the MAC address will be the determining factor instead. And
because Switch A’s MAC address is 0000.0cab.3274 and Switch B’s MAC
address is 0000.0cf6.9370, Switch A wins and will become the root
bridge. A really easy way to figure out the lowest MAC address is to just
start reading from the left toward the right until you find a lesser value.
For Switch A, I only needed to get to 0000.0ca before stopping. Switch A
wins since switch B is 0000.0cf. Never forget that the lower value is
always the better one when it comes to electing a root bridge!
I want to point out that prior to the election of the root bridge, BPDUs are
sent every 2 seconds out all active ports on a bridge/switch by default,
and they’re received and processed by all bridges. The root bridge is
elected based on this information. You can change the bridge’s ID by
lowering its priority so that it will become a root bridge automatically.
Being able to do that is important in a large switched network because it
ensures that the best paths will actually be the ones chosen. Efficiency is
always awesome in networking!
Types of Spanning-tree Protocols
There are several varieties of spanning-tree protocols in use today:
IEEE 802.1d The original standard for bridging and STP, which is really
slow but requires very little bridge resources. It’s also referred to as
Common Spanning Tree (CST).
PVST+ (Cisco default version) Per-VLAN Spanning Tree+ (PVST+)
is the Cisco proprietary enhancement for STP that provides a separate
802.1d spanning-tree instance for each VLAN. Know that this is just as
slow as the CST protocol, but with it, we get to have multiple root bridges.
This creates more efficiency of the links in the network, but it does use
more bridge resources than CST does.
IEEE 802.1w Also called Rapid Spanning Tree Protocol (RSTP), this
iteration enhanced the BPDU exchange and paved the way for much
faster network convergence, but it still only allows for one root bridge per
network like CST. The bridge resources used with RSTP are higher than
CST’s but less than PVST+.
802.1s (MSTP) IEEE standard that started out as Cisco propriety
MISTP. Maps multiple VLANs into the same spanning-tree instance to
save processing on the switch. It’s basically a spanning-tree protocol that
rides on top of another spanning-tree protocol.
Rapid PVST+ Cisco’s version of RSTP that also uses PVST+ and
provides a separate instance of 802.1w per VLAN. It gives us really fast
convergence times and optimal traffic flow but predictably requires the
most CPU and memory of all.
Common Spanning Tree
If you’re running Common Spanning Tree (CST) in your switched
network with redundant links, there will be an election to choose what
STP considers to be the best root bridge for your network. That switch
will also become the root for all VLANs in your network and all bridges in
your network will create a single path to it. You can manually override
this selection and pick whichever bridge you want if it makes sense for
your particular network.
Figure 15.8
shows how a typical root bridge would look on your switched
network when running CST.
FIGURE 15.8
Common STP example
Notice that switch A is the root bridge for all VLANs even though it’s
really not the best path for some VLANs because all switches must make a
single path to it! This is where Per-VLAN Spanning Tree+ (PVST+) comes
into play. Because it allows for a separate instance of STP for each VLAN,
it frees up the individual selection of the most optimal path.
Per-VLAN Spanning Tree+
PVST+ is a Cisco proprietary extension to 801.2d STP that provides a
separate 802.1 spanning-tree instance for each VLAN configured on your
switches. All of the Cisco proprietary extensions were created to improve
convergence times, which is 50 seconds by default. Cisco IOS switches
run 802.1d PVST+ by default, which means you’ll have optimal path
selection, but the convergence time will still be slow.
Creating a per-VLAN STP instance for each VLAN is worth the increased
CPU and memory requirements, because it allows for per-VLAN root
bridges. This feature allows the STP tree to be optimized for the traffic of
each VLAN by allowing you to configure the root bridge in the center of
each of them.
Figure 15.9
shows how PVST+ would look in an optimized
switched network with multiple redundant links.
This root bridge placement clearly enables faster convergence as well as
optimal path determination. This version’s convergence is really similar
to 802.1 CST’s, which has one instance of STP no matter how many
VLANs you have configured on your network. The difference is that with
PVST+, convergence happens on a per-VLAN basis, with each VLAN
running its own instance of STP.
Figure 15.9
shows us that we now have a
nice, efficient root bridge selection for each VLAN.
FIGURE 15.9
PVST+ provides efficient root bridge selection.
To allow for the PVST+ to operate, there’s a field inserted into the BPDU
to accommodate the extended system ID so that PVST+ can have a root
bridge configured on a per-STP instance, shown in
Figure 15.10
. The
bridge ID actually becomes smaller—only 4 bits—which means that we
would configure the bridge priority in blocks of 4,096 rather than in
increments of 1 as we did with CST. The extended system ID (VLAN ID)
is a 12-bit field, and we can even see what this field is carrying via
show
spanning-tree
command output, which I’ll show you soon.
FIGURE 15.10
PVST+ unique bridge ID
But still, isn’t there a way we can do better than a 50-second convergence
time? That’s a really long time in today’s world!
Rapid Spanning Tree Protocol 802.1w
Wouldn’t it be wonderful to have a solid STP configuration running on
your switched network, regardless of switch type, and still have all the
features we just discussed built in and enabled on every one of your
switches too? Rapid Spanning Tree Protocol (RSTP) serves up exactly this
amazing capacity right to our networking table!
Cisco created proprietary extensions to “fix” all the sinkholes and
liabilities the IEEE 802.1d standard threw at us, with the main drawback
to them being they require extra configuration because they’re Cisco
proprietary. But RSTP, the new 802.1w standard, brings us most of the
patches needed in one concise solution. Again, efficiency is golden!
RSTP, or IEEE 802.1w, is essentially an evolution of STP that allows for
much faster convergence. But even though it does address all the
convergence issues, it still only permits a single STP instance, so it
doesn’t help to take the edge off suboptimal traffic flow issues. And as I
mentioned, to support that faster convergence, the CPU usage and
memory demands are slightly higher than CST’s. The good news is that
Cisco IOS can run the Rapid PVST+ protocol—a Cisco enhancement of
RSTP that provides a separate 802.1w spanning-tree instance for each
VLAN configured within the network. But all that power needs fuel, and
although this version addresses both convergence and traffic flow issues,
it also demands the most CPU and memory of all solutions. And it’s also
good news that Cisco’s newest switches don’t have a problem with this
protocol running on them.
Keep in mind that Cisco documentation may say STP 802.1d
and RSTP 802.1w, but it is referring to the PVST+ enhancement of
each version.
Understand that RSTP wasn’t meant to be something completely new and
different. The protocol is more of an evolution than an innovation of the
802.1d standard, which offers faster convergence whenever a topology
change occurs. Backward compatibility was a must when 802.1w was
created.
So, RSTP helps with convergence issues that were the bane of traditional
STP. Rapid PVST+ is based on the 802.1w standard in the same way that
PVST+ is based on 802.1d. The operation of Rapid PVST+ is simply a
separate instance of 802.1w for each VLAN. Here’s a list to clarify how
this all breaks down:
RSTP speeds the recalculation of the spanning tree when the layer 2
network topology changes.
It’s an IEEE standard that redefines STP port roles, states, and
BPDUs.
RSTP is extremely proactive and very quick, so it doesn’t need the
802.1d delay timers.
RSTP (802.1w) supersedes 802.1d while remaining backward
compatible.
Much of the 802.1d terminology and most parameters remain
unchanged.
802.1w is capable of reverting to 802.1d to interoperate with
traditional switches on a per-port basis.
And to clear up confusion, there are also five terminology adjustments
between 802.1d’s five port states and 802.1w’s, compared here,
respectively:
Dostları ilə paylaş: |