Spanning-Tree Direct Vs Indirect Link Failures - Imp - CCIE Blog - IPexpert

9/29/2014
Spanning-Tree Direct VS Indirect Link Failures | CCIE Blog | iPexpert
Spanning-Tree Direct VS Indirect Link

Failures
March 22, 2010 [http://blog.ipexpert.com/spanning-tree-direct-vs-indirect-linkfailures/]
by
ipexpert.
Today we are going to be taking a look at the real blood and guts of the
spanning-tree protocol in order to better understand STP timers and
convergence with respect to direct and indirect link failures. Buckle in, it
should be a fun ride!!!
This blog will not be for the beginner or the faint of heart. A general
knowledge of STP and the STP algorithm is assumed. In todays blog, we will
be running PVSTP+ and we will only be running VLAN 1 across all trunks in
order to simplify things a bit. To get things started, lets take a look at the L2
switching diagram we will be playing with in the lab this morning.
Before we get into the more speci c and complicated aspects of STP, lets rst
have a quick review of how we got to the above state in the rst place:
http://blog.ipexpert.com/spanning-tree-direct-vs-indirect-link-failures/
1/12
9/29/2014
Quick review of the STP algorithm

1) There is a root bridge election. Basically, all the switches think they are the
root bridge. By receiving superior BPDUs from other switches they all
eventually agree on who is the root bridge. The root bridge is the bridge with
the lowest BID. A BID is a priority appended to a MAC address. In this case
Cat2 is the root bridge because we have manually given it the lowest priority.
We can see this here:
Cat2#sh span vlan 1

VLAN0001
Spanning tree enabled protocol ieee
Root ID
Priority
Address
24577
001b.d4c7.f680
This bridge is the root

Hello Time
2 sec
Bridge ID
Priority
Address
Hello Time
Max Age 20 sec

24577
Forward Delay 15 sec
(priority 24576 sys-id-ext 1)
001b.d4c7.f680
2 sec
Max Age 20 sec
Forward Delay 15 sec
Role Sts Cost
Prio.Nbr Type
Aging Time 300

Interface
------------------- ---- --- --------- -------- ---------------------------Fa0/21
Desg FWD 19
128.23
P2p
Fa0/23
Desg FWD 19
128.25
P2p
2) Each Non-Root bridge elects a root-port (RP) which is the port on that
switch with the lowest cost path to the root bridge. In the event of a tie, they
will go with lowest sending BID, and nally lowest port-priority
3) On each segment, a designated port (DP) is elected. The DP is the port on
that particular segment with the lowest cost path to the root bridge. The DP
has the responsibility of sending BPDUs on to the segment.
4) At the end of all this, if a port is not a RP or a DP, it is put into the blocking
state. In this case, we see Fa0/23 on Cat3 goes into the blocking state to
prevent an L2 loop from occurring
STP Timers & States

Again, before we get into the more complex topics, it is important to
understand some of the basics. In regular old STP we have a few timers that
2/12
9/29/2014
are important to understand, as well as a few di erent states our ports can be
in. The important timers are as follows:
STP Timers
Hello Timer This is how often the root bridge will send out BPDUs. These
BPDUs get relayed down the spanning-tree to all the other switches. The
default is 2 seconds.
Max Age Timer This is how often a bridge will actually save the BPDU
information it receives from other switches. Think of it as sort of a hold timer.
The default is 20 seconds, and it helps prevent against loops in the event of
indirect link failures.
Forward-Delay This determines how long a switch will spend in each of the
listening and learning states of STP. The default is 15 seconds, which means
that out of the box we spend 15 seconds in listening and 15 seconds in
learning.
The di erent states of STP are as follows:
STP States
Blocking In the blocking state the port is essentially shut down. The switch
discards frames received on the interface. It will receive BPDUs from the DP
on the segment but will not pass them along to other switches. The important
thing to note, and that we will see in this blog through actual logs is that the
blocking state is not something that a port goes into every single time it
comes up. A switch will go through the blocking state when it is rst initialized
(boots up) and it will place ports that could cause L2 loops into blocking when
necessary. This does not mean that every single time you plug a device into
the switch that the port goes into blocking before going to listening and
learning. As we will see later, the blocking state is typically only seen during
indirect link failures.
Listening In listening state the port is starting to transition into doing
something. In this state, the switch will actually process the BPDUs it receives
on the port although we are still discarding frames at this point. Note that per
the RFC Listening and Learning MUST be the same amount of time. There is
no way to tweak one or the other. If you change one, you change the other.
Learning In the learning state the port continues its transition by learning
MAC addresses on the port, continuing to receive and process BPDUs, and
transmitting BPDUs on to neighboring switches. Note that per the RFC
3/12
9/29/2014
Listening and Learning MUST be the same amount of time. There is no way to
tweak one or the other. If you change one, you change the other.
Forwarding In the forwarding state the port is up and running. At this point
the port actually forwards frames and continues to monitor BPDUs
Disabled This isnt really a state of STP. This means STP is essentially
turned o .
Bringing A Port Online Initially

Alright, now that we have covered the basics, lets get into our rst hands on
example. We are simply going to re up the switchport on Cat1 that connects
to R1 Fa0/0. In this case, R1 will be simulating a client plugging into the
network. We will observe how spannting-tree reacts and show that when a
device is rst plugged into the network, the time it will take to reach
forwarding state is actually 30 seconds. Some people and books will tell you it
is 50 seconds, but what they are missing is the fact that the port will never go
through the blocking state of STP. Lets take a look.
Cat1#sh int status | i Fa0/1

Fa0/1
disabled
auto
auto 1
0/100BaseTX
Cat1#debug spanning-tree events
Spanning Tree event debugging is on
Cat1#conf t
Enter configuration commands, one per line.
End with CNTL/Z.
Cat1(config)#int fa0/1
Cat1(config-if)#no shutdown
Feb 19 08:16:04.023: set portid: VLAN0001 Fa0/1: new port id 8001
Feb 19 08:16:04.023: STP: VLAN0001 Fa0/1 -> listening
Feb 19 08:16:19.023: STP: VLAN0001 Fa0/1 -> learning
Feb 19 08:16:34.023: STP: VLAN0001 sent Topology Change Notice on
Fa0/23
Feb 19 08:16:34.023: STP: VLAN0001 Fa0/1 -> forwarding
OK, lets break it down! As you can see, immediately upon enabling the
interface, the port when directly into the listening state. There is no blocking
state happening here in any way, shape or form. Do not pass go. Do not
collect $200. Note the time stamp of when the port went into listening state.
Exactly 15 seconds later (the default forward-delay) it enters the learning
state. Exactly 15 seconds after that, the port goes forwarding. Total time from
4/12
9/29/2014
plugged in to forwarding frames: 30 seconds. So what does this tell us? If you
are presented with a question in your lab regarding the time it takes for a PC
to start forwarding frames, do not bother playing with the max-age timer. It
wont help us here. The only things we can really do would be enable portfast
(it would then transition directly to forwarding) or change the forward-delay
timer.
Convergence After Indirect Link Failure

Now we are going to take a look at what happens speci cally to our topology
during an indirect link failure. During an indirect link failure, one of the
switches will likely have to deal with the max-age timer to expire (blocking
state), as well as waiting 2x the forward delay. Therefore, an indirect link
failure will yield a convergence time of about 50 seconds right out of the box
(20 seconds max-age + 2x forward-delay). To demonstrate this, we will
shutdown the link between Cat1 and Cat2. This will be an example of an
indirect link failure from the perspective of Cat3 and a direct link failure from
the perspective of Cat1. We will take a look at both Cat1 and Cat3 during this
convergence period. For an explanation of the comments, check out the next
paragraph.
Cat1:
Cat1#debug spanning-tree events

Spanning Tree event debugging is on
Cat1#conf t
Enter configuration commands, one per line.
End with CNTL/Z.
Cat1(config)#int fa0/23
Cat1(config-if)#shutdown
Cat1 lost its root-port and has no idea who the root bridge is. Therefore, Cat1
advertises ITSELF as the root bridge out fa0/21 towards Cat3 IMMEDIATELY.
Feb 19 08:27:31.528: STP: VLAN0001 we are the spanning tree root
After max-age expires over on Cat3, Cat3 transitions Fa0/23 into listening
mode which means it now forwards BPDUs from the path Cat2 > Cat4 >
Cat3 over to Cat1. Cat1 realizes it is not the real root bridge and submits to
Cat2 being the real root!
5/12
9/29/2014
Feb 19 08:27:49.528: STP: VLAN0001 heard root 24577-001b.d4c7.f680

on Fa0/21
Feb 19 08:27:49.528:
supersedes 32769-000b.bef0.6080
Feb 19 08:27:49.528: STP: VLAN0001 new root is 24577, 001b.d4c7.f6

80 on port Fa0/21, cost 57
Fa0/21
Cat3:
As soon as the Cat1/Cat2 link goes down Cat3 starts receiving inferior BPDUs
from Cat1 who is now claiming to be the root bridge. We will ignore these
claims completely until the max-age timer expires.
Feb 19 08:27:31.530: STP: VLAN0001 heard root 32769-000b.bef0.6080

on Fa0/21
on Fa0/21
on Fa0/21
on Fa0/21
on Fa0/21
on Fa0/21
on Fa0/21
on Fa0/21
on Fa0/21
After max-age expires, Cat3 transitions Fa0/23 from blocking into listening. It
learns its new root-port is via Fa0/23 and awaits to move it into learning and
nally forwarding.
Feb 19 08:27:49.372: STP: VLAN0001 new root port Fa0/23, cost 38

6/12
9/29/2014

on Fa0/21
Feb 19 08:27:49.532: STP: VLAN0001 Topology Change rcvd on Fa0/21
Fa0/23
15 seconds after going into listening Fa0/23 goes into learning.
15 seconds after going into learning Fa0/23 goes into forwarding.

Fa0/23
Note the total convergence time for the network here is @50 seconds.
OK, lets break down what just happened here, starting on Cat1 when we
shutdown Fa0/23. Fa0/23 was Cat1s root port. Remember also that at this
point when we shut down the link Fa0/23 on Cat3 is in the blocking state. That
means that when we shut down that link on Cat1, Cat1 now has no idea who
the root bridge is. He obviously is no longer receiving the BPDU from Cat2
since we shut the link down. He is not receiving the BPDU from Cat2 > Cat4
> Cat3 > Cat1 either because Cat3 Fa0/23 is in blocking and is not passing on
the BPDU information at this point. This would be an example of a direct link
failure from the perspective of Cat1.
We see in the log that Cat1 actually advertises itself as the root bridge. Over
on Cat3, we see this inferior BPDU being received repeatedly. Interestingly
enough, it is exactly every two seconds The hello time. What happens is
that Cat1 starts advertising out that it is the root bridge every hello interval.
Cat3 receives these BPDUs but will ignore them until the max-age timer
expires. This is 20 seconds by default.
After that max-age timer expires, Cat3 will transition Fa0/23 into the listening
state. It does this because it has not heard about the root bridge it had before
in a while (On Fa0/21 for max-age time). At this point Cat3 has BPDUs from
Cat1 who is claiming to be the root bridge coming in Fa0/21, and from Cat2
7/12
9/29/2014
who is the real root bridge and thus has a superior BPDU on Fa0/23. We can
see in the log of Cat3 that it hears about the root port on Fa0/21 (from Cat1 ,
inferior BPDU) and from Cat2 on Fa0/23 and it chooses Fa0/23 to be the new
root port.
Notice the timestamps indicate that the time interval from the point where
Cat3 started hearing about Cat1s bogus root bridge advertisement to the
point where it moves Fa0/23 into listening is almost exactly 20 seconds (max
age). It is a few seconds o because remember the hello-time is 2 seconds.
Say Cat3 received the normal BPDU describing Cat2 as the root bridge on
Fa0/21 at time t = 0. At time t = 2 the link between Cat1 and Cat2 goes down.
Now, we only have 18 seconds left before max-age expires.
In summary, what just happened is that Cat3 had to wait the max-age timer
before entering listening and learning, so the convergence time is now almost
exactly 50 seconds. Look at the timestamps on Cat3. At 08:27:31 we hear our
rst BPDU from Cat1 claiming to be the root bridge. At 08:28:19 Fa0/23 goes
forwarding. Total convergence time from indirect link failure: Roughly 48
seconds (two seconds u time here due to what I talked about in the last
paragraph)
So, in a situation where we have an indirect link failure, and we wanted to
tweek the time it takes for ports to go forwarding, we could actually play with
the max-age timer, the forward-delay or both!!!
Bringing a new switch online

At this point our topology is going to look something like this:
8/12
9/29/2014
Now that everything has settled down and converged, lets break it again
heheWe wil now bring the link between Cat1 and Cat2 back up and analyse
what happens. Take note, that at this point there is no loop in the network.
Therefore, nothing is in the blocking state. If nothing is in the blocking state,
max-age plays no role in anything. Bringing this link back up will essentially be
simulating adding a new link into the network that will cause a loop to
happen.
Cat1:
Cat1(config-if)#no shut
Feb 19 09:05:53.177: set portid: VLAN0001 Fa0/23: new port id 8017
The port comes online, and IMMEDIATELY goes into listening mode. As you
see, blocking is not involved. Thus, max-age is not involved here.

Feb 19 09:05:54.009: STP: VLAN0001 Topology Change rcvd on Fa0/21
9/12
9/29/2014

Fa0/23
15 seconds later Fa0/23 transitions from listening > learning.
15 seconds later Fa0/23 transitions from learning > forwarding.

Fa0/23
Note the total convergence from Cat1s perspective is 30 seconds.

Cat3:
Cat3 has no ports in the blocking state at the moment. As soon as it hears
about a better cost path to the root bridge via Fa0/21, it switches the root port
to Fa0/21 instead of Fa0/23. That means Fa0/23 is not a root port anymore.
Because Cat4 on the Cat3/Cat4 segment has a superior BPDU on the segment,
Cat4 Fa0/23 is the DP. Cat3 Fa0/23 is now neither a RP or a DP so it
immediately goes into blocking.

Fa0/21
Feb 19 09:05:54.002: STP: VLAN0001 Fa0/23 -> blocking
Note that the total convergence from Cat3s perspective is actually a matter of
MILLISECONDS after the link came back online between Cat1/Cat2. However,
just because Cat3 converged in less than a second, doesnt really do us any
good. Since the link between Cat1/Cat2 is still down for 30 seconds while Cat1
Fa0/23 goes from listening > learning > forwarding, the network will be
down for 30 seconds e ectively.
10/12
9/29/2014
Lets break down what happened here. Note that after we no shut Fa0/23 on
Cat1, it went DIRECTLY to the listening state. There is no need to go to
blocking rst here. Exactly 30 seconds later (2x the forward-delay) we are up
and running!
The more interesting part to me is actually on Cat3. Notice that it converges in
under 1 second. We arent using RSTP or anything crazy. Plain old STP. Cat3
has no ports in the blocking state when all this goes down. As soon as the
Cat1/Cat2 link comes back online, Cat3 will start to receive BPDUs on Fa0/21
that indicate Fa0/21 has a better path to the root bridge. IMMEDIATELY, it
switches its root port to Fa0/21. Do not wait for max-age, do not pass go, do
not collect $200! Now, since Fa0/23 is no longer the root port, and it is not the
designated port (because Cat4 has a superior cost to the root), Fa0/23 goes
into blocking immediately. We have now come full circle.
In summary, when you are looking at tweaking out your STP timers to
in uence how long it takes for things to go forwarding you should keep the
following general rules in mind:
1) If you are just plugging a machine into the network for the rst time on an
access-port, you will wait 2x forward-delay to go forwarding (30 seconds). The
only thing you can do here is play with the forward-delay timer. Max-age is
useless to you. Portfast can get around the entire process entirely.
2) The convergence of your switch after a direct link failure may be quicker
than the convergence of the entire network. The convergence of everything as
a whole may take up to 50 seconds because of the max-age timer needing to
expire on some other switch before moving a port that is currently blocking
into listening, learning and forwarding.
3) The convergence of your switch after an indirect link failure will largely
depend on weather or not the switch currently has a port in blocking mode or
not. If not, the convergence can be quite fast. If so, it could take up to 50
seconds due to max-age.
Joe Astorino CCIE #24347 (R&S)

Sr. Technical Instructor IPexpert
Mailto: jastorino@ipexpert.com
(Visited 162 time, 2 visit today)
0
Tweet
Like
23
Share
CONTINUE READING
11/12
9/29/2014
Sustaining
Greatness
Launched in 2001, iPexpert, Inc. is a 3-time Inc 5000
honoree as well as a 3-time Corp! award winner. We
are committed to the highest quality of training and
are passionate about our client's satisfaction and
success.
iPexpert is an accredited Better Business Bureau
company with an A+ rating.
CONTACT
CONNECT WITH US
Technical
Support
Sales & Pricing
Questions
Group Plans
Contact Us
3,200+
CCIE SUCCESS STORIES SINCE
2001
Sitemap | CCIE Blog | Terms & Conditions | 2014 iPexpert Inc. All rights reserved
12/12

Spanning-Tree Direct Vs Indirect Link Failures - Imp - CCIE Blog - IPexpert

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Spanning-Tree Direct Vs Indirect Link Failures - Imp - CCIE Blog - IPexpert

Diunggah oleh

Hak Cipta:

Format Tersedia

9/29/2014

Spanning-Tree Direct VS Indirect Link Failures | CCIE Blog | iPexpert