802.1d State
802.1w State
Disabled
= Discarding
Blocking
= Discarding
Listening
= Discarding
Learning
= Learning
Forwarding
= Forwarding
Make note of the fact that RSTP basically just goes from discarding to
learning to forwarding, whereas 802.1d requires five states to transition.
The task of determining the root bridge, root ports, and designated ports
hasn’t changed from 802.1d to RSTP, and understanding the cost of each
link is still key to making these decisions well. Let’s take a look at an
example of how to determine ports using the revised IEEE cost
specifications in
Figure 15.11
.
FIGURE 15.11
RSTP example 1
Can you figure out which is the root bridge? How about which port is the
root and which ones are designated? Well, because SC has the lowest
MAC address, it becomes the root bridge, and since all ports on a root
bridge are forwarding designated ports, well, that’s easy, right? Ports
Gi0/1 and Gi0/10 become designated forwarding ports on SC.
But which one would be the root port for SA? To figure that out, we must
first find the port cost for the direct link between SA and SC. Even though
the root bridge (SC) has a Gigabit Ethernet port, it’s running at 100 Mbps
because SA’s port is a 100-Mbps port, giving it a cost of 19. If the paths
between SA and SC were both Gigabit Ethernet, their costs would only be
4, but because they’re running 100 Mbps links instead, the cost jumps to
a whopping 19!
Can you find SD’s root port? A quick glance at the link between SC and
SD tells us that’s a Gigabit Ethernet link with a cost of 4, so the root port
for SD would be its Gi0/9 port.
The cost of the link between SB and SD is also 19 because it’s also a Fast
Ethernet link, bringing the full cost from SB to SD to the root (SC) to a
total cost of 19 + 4 = 23. If SB were to go through SA to get to SC, then the
cost would be 19 + 19, or 38, so the root port of SB becomes the Fa0/3
port.
The root port for SA would be the Fa0/0 port since that’s a direct link
with a cost of 19. Going through SB to SD would be 19 + 19 + 4 = 42, so
we’ll use that as a backup link for SA to get to the root just in case we
need to.
Now all we need is a forwarding port on the link between SA and SB.
Because SA has the lowest bridge ID, Fa0/1 on SA wins that role. Also,
the Gi0/1 port on SD would become a designated forwarding port. This is
because the SB Fa0/3 port is a designed root port and you must have a
forwarding port on a network segment! This leaves us with the Fa0/2
port on SB. Since it isn’t a root port or designated forwarding port, it will
be placed into blocking mode, which will prevent looks in our network.
Let’s take a look at this example network when it has converged in
Figure
15.12
.
FIGURE 15.12
RSTP example 1 answer
If this isn’t clear and still seems confusing, just remember to always
tackle this process following these three steps:
1. Find your root bridge by looking at bridge IDs.
2. Determine your root ports by finding the lowest path cost to the root
bridge.
3. Find your designated ports by looking at bridge IDs.
As usual, the best way to nail this down is to practice, so let’s explore
another scenario, shown in
Figure 15.13
.
FIGURE 15.13
RSTP example 2
So which bridge is our root bridge? Checking priorities first tells us that
SC is the root bridge, which means all ports on SC are designated
forwarding ports. Now we need to find our root ports.
We can quickly see that SA has a 10-gigabit port to SC, so that would be a
port cost of 2, and it would be our root port. SD has a direct Gigabit
Ethernet port to SC, so that would be the root port for SD with a port cost
of 4. SB’s best path would also be the direct Gigabit Ethernet port to SC
with a port cost of 4.
Now that we’ve determined our root bridge and found the three root
ports we need, we’ve got to find our designated ports next. Whatever is
left over simply goes into the discarding role. Let’s take a look at
Figure
15.14
and see what we have.
FIGURE 15.14
RSTP example 2, answer 1
All right, it looks like there are two links to choose between to find one
designated port per segment. Let’s start with the link between SA and SD.
Which one has the best bridge ID? They’re both running the same default
priority, so by looking at the MAC address, we can see that SD has the
better bridge ID (lower), so the SA port toward SD will go into a
discarding role, or will it? The SD port will go into discarding mode,
because the link from SA to the root has the lowest accumulated path
costs to the root bridge, and that is used before the bridge ID in this
circumstance. It makes sense to let the bridge with the fastest path to the
root bridge be a designated forwarding port. Let’s talk about this a little
more in depth.
As you know, once your root bridge and root ports have been chosen,
you’re left with finding your designated ports. Anything left over goes into
a discarding role. But how are the designated ports chosen? Is it just
bridge ID? Here are the rules:
1. To choose the switch that will forward on the segment, we select the
switch with the lowest accumulated path cost to the root bridge. We
want the fast path to the root bridge.
2. If there is a tie on the accumulated path cost from both switches to the
root bridge, then we’ll use bridge ID, which was what we used in our
previous example (but not with this latest RSTP example; not with a
10-Gigabit Ethernet link to the root bridge available!).
3. Port priorities can be set manually if we want a specific port chosen.
The default priority is 32, but we can lower that if needed.
4. If there are two links between switches, and the bridge ID and priority
are tied, the port with the lowest number will be chosen—for example,
Fa0/1 would be chosen over Fa0/2.
Let’s take a look at our answer now, but before we do, can you find the
forwarding port between SA and SB? Take a look at
Figure 15.15
for
the answer.
FIGURE 15.15
RSTP example 2, answer 2
Again, to get the right answer to this question we’re going to let the
switch on the network segment with the lowest accumulated path cost to
the root bridge forward on that segment. This is definitely SA, meaning
the SB port goes into discarding role—not so hard at all!
802.1s (MSTP)
Multiple Spanning Tree Protocol (MSTP), also known as IEEE 802.ls,
gives us the same fast convergence as RSTP but reduces the number of
required STP instances by allowing us to map multiple VLANs with the
same traffic flow requirements into the same spanning-tree instance. It
essentially allows us to create VLAN sets and basically is a spanning-tree
protocol that runs on top of another spanning-tree protocol.
So clearly, you would opt to use MSTP over RSTP when you’ve got a
configuration involving lots of VLANs, resulting in CPU and memory
requirements that would be too high otherwise. But there’s no free lunch
—though MSTP reduces the demands of Rapid PVST+, you’ve got to
configure it correctly because MSTP does nothing by itself!
Modifying and Verifying the Bridge ID
To verify spanning tree on a Cisco switch, just use the command
show
spanning-tree
. From its output, we can determine our root bridge,
priorities, root ports, and designated and blocking/discarding ports.
Let’s use the same simple three-switch network we used earlier as the
base to play around with the configuration of STP.
Figure 15.16
shows the
network we’ll work with in this section.
FIGURE 15.16
Our simple three-switch network
Let’s start by taking a look at the output from S1:
S1#
sh spanning-tree vlan 1
VLAN0001
Spanning tree enabled protocol
ieee
Root ID Priority 32769
Address 0001.42A7.A603
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 0001.42A7.A603 him
Hello Time 2 sec Max Age 20 sec Forward Delay 15
sec
Aging Time 20
Interface Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- ----------------------
----------
Gi1/1 Desg FWD 4 128.25 P2p
Gi1/2 Desg FWD 4 128.26 P2p
First, we can see that we’re running the IEEE 802.1d STP version by
default, and don’t forget that this is really 802.1d PVST+! Looking at the
output, we can see that S1 is the root bridge for VLAN 1. When you use
this command, the top information is about the root bridge, and the
Bridge ID output refers to the bridge you’re looking at. In this example,
they are one and the same. Notice the
sys-id-ext 1 (for VLAN 1)
. This is
the 12-bit PVST+ field that is placed into the BPDU so it can carry
multiple-VLAN information. You add the priority and
sys-id-ext
to come
up with the true priority for the VLAN. We can also see from the output
that both Gigabit Ethernet interfaces are designated forwarding ports.
You will not see a blocked/discarding port on a root bridge. Now let’s take
a look at S3’s output:
S3#
sh spanning-tree
VLAN0001
Spanning tree enabled protocol ieee
Root ID Priority 32769
Address 0001.42A7.A603
Cost 4
Port 26(GigabitEthernet1/2)
Hello Time 2 sec Max Age 20 sec Forward Delay 15
sec
Bridge ID Priority 32769 (priority 32768 sys-id-ext 1)
Address 000A.41D5.7937
Hello Time 2 sec Max Age 20 sec Forward Delay 15
sec
Aging Time 20
Interface Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- ----------------------
----------
Gi1/1 Desg FWD 4 128.25 P2p
Gi1/2 Root FWD 4 128.26 P2p
Looking at the Root ID, it’s easy to see that S3 isn’t the root bridge, but
the output tells us it’s a cost of 4 to get to the root bridge and also that it’s
located out port 26 of the switch (Gi1/2). This tells us that the root bridge
is one Gigabit Ethernet link away, which we already know is S1, but we
can confirm this with the
show cdp neighbors
command:
Switch#
sh cdp nei
Capability Codes: R - Router, T - Trans Bridge, B - Source Route
Bridge
S - Switch, H - Host, I - IGMP, r - Repeater, P -
Phone
Device ID Local Intrfce Holdtme Capability Platform
Port ID
S3 Gig 1/1 135 S 2960
Gig 1/1
S1 Gig 1/2 135 S 2960
Gig 1/1
That’s how simple it is to find your root bridge if you don’t have the nice
figure as we do. Use the
show spanning-tree
command, find your root
port, and then use the
show cdp neighbors
command. Let’s see what S2’s
output has to tell us now:
S2#
sh spanning-tree
VLAN0001
Spanning tree enabled protocol ieee
Root ID Priority 32769
Address 0001.42A7.A603
Cost 4
Port 26(GigabitEthernet1/2)
Hello Time 2 sec Max Age 20 sec Forward Delay 15
sec
Bridge ID Priority 32769 (priority 32768 sys-id-ext 1)
Address 0030.F222.2794
Hello Time 2 sec Max Age 20 sec Forward Delay 15
sec
Aging Time 20
Interface Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- ----------------------
----------
Gi1/1 Altn BLK 4 128.25 P2p
Gi1/2 Root FWD 4 128.26 P2p
We’re certainly not looking at a root bridge since we’re seeing a blocked
port, which is S2’s connection to S3!
Let’s have some fun by making S2 the root bridge for VLAN 2 and for
VLAN 3. Here’s how easy that is to do:
S2#
sh spanning-tree vlan 2
VLAN0002
Spanning tree enabled protocol ieee
Root ID Priority 32770
Address 0001.42A7.A603
Cost 4
Port 26(GigabitEthernet1/2)
Hello Time 2 sec Max Age 20 sec Forward Delay 15
sec
Bridge ID
Priority 32770 (priority 32768 sys-id-ext 2)
Address 0030.F222.2794
Hello Time 2 sec Max Age 20 sec Forward Delay 15
sec
Aging Time 20
Interface Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- ----------------------
----------
Gi1/1 Altn BLK 4 128.25 P2p
Gi1/2 Root FWD 4 128.26 P2p
We can see that the root bridge cost is 4, meaning that the root bridge is
one gigabit link away. One more key factor I want to talk about before
making S2 the root bridge for VLANs 2 and 3 is the
sys-id-ext
, which
shows up as 2 in this output because this output is for VLAN 2. This
sys-
id-ext
is added to the bridge priority, which in this case is 32768 + 2,
which makes the priority 32770. Now that you understand what that
output is telling us, let’s make S2 the root bridge:
S2(config)#
spanning-tree vlan 2 ?
priority Set the bridge priority for the spanning tree
root Configure switch as root
S2(config)#
spanning-tree vlan 2 priority ?
<0-61440> bridge priority in increments of 4096
S2(config)#
spanning-tree vlan 2 priority 16384
You can set the priority to any value from 0 through 61440 in increments
of 4096. Setting it to zero (0) means that the switch will always be a root
as long as it has a lower MAC address than another switch that also has
its bridge ID set to 0. If you want to set a switch to be the root bridge for
every VLAN in your network, then you have to change the priority for
each VLAN, with 0 being the lowest priority you can use. But trust me—
it’s never a good idea to set all switches to a priority of 0!
Furthermore, you don’t actually need to change priorities because there is
yet another way to configure the root bridge. Take a look:
S2(config)#
spanning-tree vlan 3 root ?
primary Configure this switch as primary root for this
spanning tree
secondary Configure switch as secondary root
S2(config)#
spanning-tree vlan 3 root primary
S3(config)#
spanning-tree vlan 3 root secondary
Notice that you can set a bridge to either primary or secondary—very
cool! If both the primary and secondary switches go down, then the next
highest priority will take over as root.
Let’s check to see if S2 is actually the root bridge for VLANs 2 and 3 now:
S2#
sh spanning-tree vlan 2
VLAN0002
Spanning tree enabled protocol ieee
Root ID Priority 16386
Address 0030.F222.2794
This bridge is the root
Hello Time 2 sec Max Age 20 sec Forward Delay 15
sec
Bridge ID Priority
16386 (priority 16384 sys-id-ext 2)
Address 0030.F222.2794
Hello Time 2 sec Max Age 20 sec Forward Delay 15
sec
Aging Time 20
Interface Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- ----------------------
----------
Gi1/1 Desg FWD 4 128.25 P2p
Gi1/2 Desg FWD 4 128.26 P2p
Nice—S2 is the root bridge for VLAN 2, with a priority of 16386 (16384 +
2). Let’s take a look to see the root bridge for VLAN 3. I’ll use a different
command for that this time. Check it out:
S2#
sh spanning-tree summary
Switch is in pvst mode
Root bridge for: VLAN0002 VLAN0003
Extended system ID is enabled
Portfast Default is disabled
PortFast BPDU Guard Default is disabled
Portfast BPDU Filter Default is disabled
Loopguard Default is disabled
EtherChannel misconfig guard is disabled
UplinkFast is disabled
BackboneFast is disabled
Configured Pathcost method used is short
Name Blocking Listening Learning Forwarding STP
Active
---------------------- -------- --------- -------- ---------- -----
-----
VLAN0001 1 0 0 1
2
VLAN0002 0 0 0 2
2
VLAN0003 0 0 0 2
2
---------------------- -------- --------- -------- ---------- -----
-----
3 vlans 1 0 0 5
6
The preceding output tells us that S2 is the root for the two VLANs, but
we can see we have a blocked port for VLAN 1 on S2, so it’s not the root
bridge for VLAN 1. This is because there’s another bridge with a better
bridge ID for VLAN 1 than S2’s.
One last burning question: How do you enable RSTP on a Cisco switch?
Well, doing that is actually the easiest part of this chapter! Take a look:
S2(config)#
spanning-tree mode rapid-pvst
Is that really all there is to it? Yes, because it’s a global command, not per
VLAN. Let’s verify we’re running RSTP now:
S2#
sh spanning-tree
VLAN0001
Spanning tree enabled protocol rstp
Root ID Priority 32769
Address 0001.42A7.A603
Cost 4
Port 26(GigabitEthernet1/2)
Hello Time 2 sec Max Age 20 sec Forward Delay 15
sec
[output cut
S2#
sh spanning-tree summary
Switch is in rapid-pvst mode
Root bridge for: VLAN0002 VLAN0003
Looks like we’re set! We’re running RSTP, S1 is our root bridge for VLAN
1, and S2 is the root bridge for VLANs 2 and 3. I know this doesn’t seem
hard, and it really isn’t, but you still need to practice what we’ve covered
so far in this chapter to really get your skills solid!
Spanning-Tree Failure Consequences
Clearly, there will be consequences when a routing protocol fails on a
single router, but mainly, you’ll just lose connectivity to the networks
directly connected to that router, and it usually does not affect the rest of
your network. This definitely makes it easier to troubleshoot and fix the
issue!
There are two failure types with STP. One of them causes the same type of
issue I mentioned with a routing protocol; when certain ports have been
placed in a blocking state they should be forwarding on a network
segment instead. This situation makes the network segment unusable,
but the rest of the network will still be working. But what happens when
blocked ports are placed into forwarding state when they should be
blocking? Let’s work through this second failure issue now, using the
same layout we used in the last section. Let’s start with
Figure 15.17
and
then find out what happens when STP fails. Squeamish readers be
warned—this isn’t pretty!
Looking at
Figure 15.17
, what do you think will happen if SD transitions
its blocked port to the forwarding state?
FIGURE 15.17
STP stopping loops
Clearly, the consequences to the entire network will be pretty devastating!
Frames that already had a destination address recorded in the MAC
address table of the switches are forwarded to the port they’re associated
with; however, any broadcast, multicast, and unicasts not in the CAM are
now in an endless loop.
Figure 15.18
shows us the carnage—when you see
all the lights on each port blinking super-fast amber/green, this means
serious errors are occurring, and lots of them!
FIGURE 15.18
STP failure
As frames begin building up on the network, the bandwidth starts getting
saturated. The CPU percentage goes way up on the switches until they’ll
just give up and stop working completely, and all this within a few
seconds!
Here is a list of the problems that will occur in a failed STP network that
you must be aware of and you must be able to find in your production
network—and of course, you must know them to meet the exam
objectives:
The load on all links begins increasing and more and more frames
enter the loop. Remember, this loop affects all the other links in the
network because these frames are always flooded out all ports. This
scenario is a little less dire if the loop occurs within a single VLAN. In
that case, the snag will be isolated to ports only in that VLAN
membership, plus all trunk links that carry information for that
VLAN.
If you have more than one loop, traffic will increase on the switches
because all the circling frames actually get duplicated. Switches
basically receive a frame, make a copy of it, and send it out all ports.
And they do this over and over and over again with the same frame, as
well as for any new ones!
The MAC address table is now completely unstable. It no longer
knows where any source MAC address hosts are actually located
because the same source address comes in via multiple ports on the
switch.
With the overwhelmingly high load on the links and the CPUs, now
possibly at 100% or close to that, the devices become unresponsive,
making it impossible to troubleshoot—it’s a terrible thing!
At this point your only option is to systematically remove every
redundant link between switches until you can find the source of the
problem. And don’t freak because, eventually, your ravaged network will
calm down and come back to life after STP converges. Your fried switches
will regain consciousness, but the network will need some serious
therapy, so you’re not out of the woods yet!
Now is when you start troubleshooting to find out what caused the
disaster in the first place. A good strategy is to place the redundant links
back into your network one at a time and wait to see when a problem
begins to occur. You could have a failing switch port, or even a dead
switch. Once you’ve replaced all your redundant links, you need to
carefully monitor the network and have a back-out plan to quickly isolate
the problem if it reoccurs. You don’t want to go through this again!
You’re probably wondering how to prevent these STP problems from ever
darkening your doorstep in the first place. Well, just hang on, because
after the next section, I’ll tell you all about EtherChannel, which can stop
ports from being placed in the blocked/discarding state on redundant
links to save the day! But before we add more links to our switches and
then bundle them, let’s talk about PortFast.
Dostları ilə paylaş: |