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 today’s 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, let’s take a look at the L2 switching diagram we will be playing with in the lab this morning.
Before we get into the more specific and complicated aspects of STP, lets first have a quick review of how we got to the above state in the first place:
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 24577 Address 001b.d4c7.f680 This bridge is the root Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec Bridge ID Priority 24577 (priority 24576 sys-id-ext 1) Address 001b.d4c7.f680 Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec Aging Time 300 Interface Role Sts Cost Prio.Nbr Type ------------------- ---- --- --------- -------- ----------------------------- 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 finally 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 are important to understand, as well as a few different states our ports can be in. The important timers are as follows:
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 different states of STP are as follows:
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 first 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 it’s 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 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 isn’t really a state of STP. This means STP is essentially turned off.
Bringing A Port Online Initially
Alright, now that we have covered the basics, lets get into our first hands on example. We are simply going to fire 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 first 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. Let’s take a look.
Cat1#sh int status | i Fa0/1 Fa0/1 disabled 1 auto auto 10/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, let’s 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 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 won’t 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 specifically 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#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 it’s 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!
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.f680 on port Fa0/21, cost 57 Feb 19 08:27:49.528: STP: VLAN0001 sent Topology Change Notice on Fa0/21
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 Feb 19 08:27:33.526: STP: VLAN0001 heard root 32769-000b.bef0.6080 on Fa0/21 Feb 19 08:27:35.531: STP: VLAN0001 heard root 32769-000b.bef0.6080 on Fa0/21 Feb 19 08:27:37.528: STP: VLAN0001 heard root 32769-000b.bef0.6080 on Fa0/21 Feb 19 08:27:39.524: STP: VLAN0001 heard root 32769-000b.bef0.6080 on Fa0/21 Feb 19 08:27:41.529: STP: VLAN0001 heard root 32769-000b.bef0.6080 on Fa0/21 Feb 19 08:27:43.525: STP: VLAN0001 heard root 32769-000b.bef0.6080 on Fa0/21 Feb 19 08:27:45.530: STP: VLAN0001 heard root 32769-000b.bef0.6080 on Fa0/21 Feb 19 08:27:47.527: STP: VLAN0001 heard root 32769-000b.bef0.6080 on Fa0/21
After max-age expires, Cat3 transitions Fa0/23 from blocking into listening. It learns it’s new root-port is via Fa0/23 and awaits to move it into learning and finally forwarding.
Feb 19 08:27:49.372: STP: VLAN0001 new root port Fa0/23, cost 38 Feb 19 08:27:49.372: STP: VLAN0001 Fa0/23 -> listening Feb 19 08:27:49.523: STP: VLAN0001 heard root 32769-000b.bef0.6080 on Fa0/21 Feb 19 08:27:49.532: STP: VLAN0001 Topology Change rcvd on Fa0/21 Feb 19 08:27:49.532: STP: VLAN0001 sent Topology Change Notice on Fa0/23
15 seconds after going into listening Fa0/23 goes into learning.
Feb 19 08:28:04.379: STP: VLAN0001 Fa0/23 -> learning
15 seconds after going into learning Fa0/23 goes into forwarding.
Feb 19 08:28:19.387: STP: VLAN0001 sent Topology Change Notice on Fa0/23 Feb 19 08:28:19.387: STP: VLAN0001 Fa0/23 -> forwarding
Note the total convergence time for the network here is @50 seconds.
OK, let’s break down what just happened here, starting on Cat1 when we shutdown Fa0/23. Fa0/23 was Cat1′s 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 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 Cat1′s 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 off 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 first 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 fluff 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:
Now that everything has settled down and converged, let’s break it again hehe…We 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(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:53.177: STP: VLAN0001 Fa0/23 -> listening Feb 19 09:05:54.005: STP: VLAN0001 new root port Fa0/23, cost 19 Feb 19 09:05:54.009: STP: VLAN0001 Topology Change rcvd on Fa0/21 Feb 19 09:05:54.009: STP: VLAN0001 sent Topology Change Notice on Fa0/23
15 seconds later Fa0/23 transitions from listening –> learning.
Feb 19 09:06:08.177: STP: VLAN0001 Fa0/23 -> learning
15 seconds later Fa0/23 transitions from learning –> forwarding.
Feb 19 09:06:23.177: STP: VLAN0001 sent Topology Change Notice on Fa0/23 Feb 19 09:06:23.177: STP: VLAN0001 Fa0/23 -> forwarding
Note the total convergence from Cat1′s perspective is 30 seconds.
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.
Feb 19 09:05:54.002: STP: VLAN0001 new root port Fa0/21, cost 38 Feb 19 09:05:54.002: STP: VLAN0001 sent Topology Change Notice on Fa0/21 Feb 19 09:05:54.002: STP: VLAN0001 Fa0/23 -> blocking
Note that the total convergence from Cat3′s 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, doesn’t 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 effectively.
Let’s 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 first 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 aren’t 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 it’s 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 influence 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 first 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