The reason why you never see the discarding state is that the discarding state is there only momentarily. It’s not there for any extended period of time, so in order for you to issue the show command right at the moment when the discarding state is, it is very rare. This is one of the features that make RSTP rapid in comparison to STP, which maintained the listening state for 15 seconds before going to the learning state.
So it’s unlikely you will be able to observe that particular state, simply because it is in the discarding state for such a short period of time.
Today, ive been reviewing this topic and i have a doubt about RSTP link failure.
I’ll extract two different excerpts of this lesson :
“With the classic spanning tree a link failure would trigger a topology change. Using rapid spanning tree a link failure is not considered as a topology change. Only non-edge interfaces (leading to other switches) that move to the forwarding state are considered as a topology change”
“Rapid spanning-tree works differently! BPDUs are now used as a keepalive mechanism similar to what routing protocols like OSPF or EIGRP use. If a switch misses three BPDUs from a neighbor switch it will assume connectivity to this switch has been lost and it will remove all MAC addresses immediately.”
My doubt is, whenever a non-edge stop receiving 3xhello bpdu (keep alive mechanism) it only does a mac add flush (all cam tbl) but not generate any BPDU TCN ?
Yes, that’s exactly correct. If a port misses three hellos, the link is considered down. When a link goes down, either due to missed BPDUs or even if a cable is unplugged, no TCN is sent. Only when the BPDUs begin flowing again and the port is considered up again will a TCP be sent.
I have another 2 questions :
So in RSTP when a switch misses 3x bpdu from a neigh switch, the switch that stop receiving these bpdu do a complete flush of its cam table or only flush mac add previous learned from the port that misses these bpdu ?
and the other question is about the TCN mechanisn in RSTP :
from the lessson in understand the following :
a TC in RSTP is only when a non-edge port change to forwarding state, therefore the switch that has been detected this TC will generate a while timer ( 2x hello timer = 4 secs) , what is the purpose of that ? i mean when a port changes to forwarding and then the switch generates a BPDU with a timer set in 4 secs , in which bpdu field ? and this bpdu is sent out of all non-dsg ports to the others switches, except the port that changed to forwarding state ?
thanks in advance.
Whenever three BPDUs are missed, or if there is a topology change, the flushing of the MAC table only involves those entries associated with the specific ports. The rest of the entries in the MAC address table remain unchanged. This helps to minimize the impact of topology changes on the rest of the network. This is the case for normal STP as well as RSTP. Take a look at this documentation which specifies this:
In RSTP, the while timer helps to ensure that the switch has received sufficient information from other switches in the network before transitioning to a new state. This helps to ensure rapid and consistent convergence of the network in the event of a topology change. Note that this timer is not included in any field of the BPDU. As long as the while timer is active, it will set the TC bit in the BPDUs. When downstream switches receive these BPDUs, they too will set their while timers.
There is a little bit more detail that’s involved here as far as what goes on when a new link between two RSTP switches comes up. As soon as a new link comes up, both ports on either end of the link go into Designated Discarding state. Rene calls it “blocking state” which is a more generic term we use for STP in general. Designated DIscarding is the default state in RSTP as soon as a port comes up.
Every Designated Discarding port sends BPDUs with the proposal bit set to 1. This bit is set to indicate to the other switch that the initial negotiation is to take place. That means that both SW1 and SW2 will send these BPDUs. Rene focuses on the BPDU being sent from SW1 to SW2 in the lesson, because this is the only relevant exchange since SW1 will be the root bridge. Any BPDU sent by SW2 to SW1 will simply be ignored.
The term “shared” is used to refer to an interface on a switch that has been connected to a hub within an RSTP environment. This term is used because the port is connected to what is considered a shared communication medium since multiple devices, even other ports on the same switch, will compete for the same bandwidth within the same broadcast domain. And within that broadcast domain, collisions can occur.
“With the classic spanning tree a link failure would trigger a topology change. Using rapid spanning tree a link failure is not considered as a topology change. Only non-edge interfaces (leading to other switches) that move to the forwarding state are considered as a topology change.”
Why does a link failure trigger a topology change in STP? There are 5 kinds of link failure that I could think of. Out of these 5, only 3 lead to a topology change, but 2 don’t. Which means that I don’t see how we can make this statement about all link failures.
Here are all 5 scenarios:
If a Designated Port (DP) of the Root Switch goes down. This scenario has 2 subscenarios:
1a) If the Root Switch’s DP leads to an end-user device (i.e. this DP is an edge port), then there’s no switch on the other end that’s cut off from the Root Switch. Scenario 1a) does not lead to a topology change.
1b) If the Root Switch’s DP leads to a non-root switch. In that case, the (non-root) switch on the other end must find another path to the Root Switch. Scenario 1b) leads to a topology change.
If a (non-root) switch’s Root Port goes down: in that case, that switch must find another path towards the Root Switch. Scenario 2) leads to a topology change.
If a (non-root) switch’s (let’s call it SW1) Designated Port goes down. This scenario has 2 subscenarios:
3a) SW1’s DP leads to another switch (let’s call it SW2). In that case, SW2 loses its path to the Root Switch. So because SW2 must find another path towards the Root Switch, scenario 3a) leads to a topology change.
3b) But if SW1’s DP leads to an end-user device (i.e. SW1’s DP is an edge port), then there’s no switch on the other end that’s cut off from the Root Switch. So scenario 3b) does not lead to a topology change.
This paragraph may need to be modified slightly to more correctly describe the situation. You are correct that if the port that fails is connected to an end device (i.e. it’s an edge port) then no topology change notification will be sent.
Remember, STP will send out a TCN when there is a failure on the active path. So maybe a more appropriate statement would be:
With the classic spanning tree a link failure along the active path would trigger a topology change.
Or more simply, a link failure between switches, or a link failure other than links connected to end devices.
In any case, thanks for making this clarification. I will let Rene know to consider making any necessary modifications to the content.
I’m little confused about this :
"are you following me so far? The lesson to learn here is that rapid spanning tree uses this sync mechanism instead of the “timer-based” mechanism that the classic spanning tree uses (listening > learning > forwarding). "
So, i don’t know how to relate the rstp states (“timers” or when you say timers you max age timer ?) 1.discarding 2.learning 3.forwarding if then you say RSTP doesn’t these timers anymore and instead use the sync mechanism.
Classic IEEE 802.1D STP used the blocking → listening → learning → forwarding set of port states. Each of these states exists for a predetermined amount of time. The forward delay timer is used to determine how long a port must stay in both the listening and learning states. The default value is 15 seconds for each state, for a total of 30 seconds.
In addition, there is the Max Age timer which is by default 20 seconds, and it defines the amount of time a switch port will consider a BPDU it has received valid. This timer essentially helps to determine how long a switch should wait for a BPDU on a port before it decides the link is down. So if a link goes down, STP can potentially wait up to 20+15+15 = 50 seconds before it reconverges, something which in today’s networks is no longer acceptable.
So what’s the difference with RSTP? RSTP also has states, including discarding → learning → forwarding. They’re different, there are fewer, but they are there. The difference is the fact that RSTP no longer depends upon timers to move from one state to the next. The sync mechanism is a negotiation mechanism that completes within milliseconds. Moving from state to state is no longer a matter of dozens of seconds, but sub-second time intervals. Does that make sense?
Ah yes, I apologize for the confusion. Yes, there is a relationship between the RSTP states and the sync mechanism. As soon as the ports come up on a link between two switches, a BPDU will be sent to begin the synchronization mechanism. When this happens, all ports on the switch that receives such a BPDU will go into the discarding state. The transition to the various states is further described below:
Discarding to Learning: A port moves from the discarding state to the learning state after it receives a BPDU that makes it a root port or an alternate port (which would indicate that it provides a backup path to the root). This means that it’s safe for the port to start learning MAC addresses without causing a loop. For a designated port, the switch also sends a proposal to the downstream switch indicating its intent to move this port to the forwarding state. The port then waits for an agreement from the downstream switch before it moves to the learning state.
Learning to Forwarding: This transition is almost instantaneous. Once the MAC address table starts to populate, and the required conditions are met, the port will transition from the “learning” state to the “forwarding” state. What are the required conditions?
For a designated port, after sending a proposal, it must receive an agreement from all connected devices before it can transition to the forwarding state. This ensures a loop-free topology before starting to forward traffic.
For a root port, the transition to the forwarding state happens after receiving a superior BPDU (which makes the port become the root port) or after receiving a proposal from the upstream switch.
Edge ports can transition to the forwarding state immediately, without waiting, because there’s no possibility of a bridging loop occurring on them.
The key here is the proposal-agreement mechanism, which allows for rapid, loop-free changes in port states. The transition from the discarding state to the learning state is based on the receipt of specific BPDUs and the sending of a proposal, while the transition from the learning state to the forwarding state is based on the receipt of an agreement.
The process of learning MAC addresses takes place all the time. When the port is in the forwarding state, it still learns MAC addresses. MAC address learning is not restricted only to the learning state.
The purpose of the learning state in the original STP is to prevent network loops during the transitional period when the spanning tree topology is still being established. By not forwarding frames immediately, the switch can avoid creating loops that could occur if frames were forwarded without a clear understanding of the network topology. The duration of the learning state is typically set to ensure that the switch has enough time to populate the MAC address table before starting to forward frames.
Where STP used a timeout to ensure this loop-free topology, RSTP+ uses a request/response mechanism which is faster. The learning stage is almost instantaneous because the switch sends an RSTP proposal message immediately and receives one right away. If there are still MAC addresses to be learned they will be learned in due course whenever a new frame arrives on a port of that particular switch.
Yes, you’re on the right track, but let’s clarify a bit. The stages you mentioned are part of the RSTP convergence process.
Proposal: The root bridge sends a proposal to its directly connected switches indicating that it has a better path to the root. The bridges then stop forwarding data frames and go into a discarding state to prevent loops.
Sync: The directly connected switches send a sync message to their directly connected switches to prepare them for the upcoming change in the network topology.
Agreement: After receiving the sync message, the directly connected switches send an agreement back to the root bridge. This indicates that they have prepared their directly connected switches for the upcoming change.
Forwarding: Once the root bridge receives an agreement from all its directly connected switches, it starts forwarding data frames again. The directly connected switches then repeat this process with their directly connected switches.
So, your understanding is correct, but remember these are not stages but rather processes that happen during RSTP convergence.