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.
Iâm missing something on the negotiation mechanism.
As soon as the link between SW1 and SW2 comes up their interfaces will be in blocking mode. SW2 will receive a BPDU from SW1 and now a negotiation will take place called sync:
So SW1 can both receive BPDUs but cannot send BPDUs. How can SW1 send a BPDU to SW2?
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.
Can someone please help me with this?:
âIf we introduce a hub to our network weâll have half duplex which is seen as a shared interface to rapid spanning-tree.â
Is it a shared interface because our switch shares the same collision domain with possibly several devices because of how the hub works?
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?
But my confusion or doubt is if there is any relationship between RSTP States (Discarding - Learning - Forwarding) and RSTP Sync Mechanism (Sync - Proposal - Agreement).
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.
I have a problem RSTP with MSTP. My core switch works RSTP. RSTP priority is 0. When my edge switch works as MSTP. Some of vlan has blocked. MSTP priority is 61440 and all vlans in only one instance. There is no per vlan priority in the RSTP. So I can not change Non-Vlan 1 priority like PVST-MST interoperability. How can I solve this problem?
Jan 25 10:11:31.978: %SPANTREE-2-PVSTSIM_FAIL: Blocking root port Gi1/24: Inconsistent inferior PVST BPDU received on VLAN 55, claiming root 32823:70da.4852.6600
The error message youâre encountering suggests that thereâs a problem with how the different types of STPs are interacting between your core and edge switches. Specifically, the core switch running RSTP and the edge switch running MSTP seem to not be fully compatible in their current configurations, leading to issues with VLAN 55.
Without knowing more about the topology and the configurations you have applied, I can share with you some steps that may be helpful in troubleshooting and potentially solving the issue.
Ensure Proper MST Configuration: Verify that the MST configuration on your edge switch is correctly done. Ensure that all VLANs are mapped to the MST instance as intended. In your case, it seems all VLANs are mapped to a single instance, which should be fine as long as itâs intentional and correctly configured on all MSTP switches.
MSTP to RSTP Edge Port Configuration: Ensure that the edge ports on the MSTP switch that connect to RSTP switches are properly configured. You might need to configure these ports in a way that ensures compatibility. Sometimes, setting these ports as edge ports (if they connect to end devices) or ensuring they are not sending out MSTP-specific BPDUs to RSTP switches can help.
Review and Align Priorities: Although you mentioned that thereâs no per-VLAN priority in RSTP and you canât change non-VLAN 1 priorities like in a PVST-MST interoperability scenario, you can still ensure that the overall bridge priorities are aligned in a way that the expected switch becomes the root. Given the MSTP priority is high (61440), you might want to adjust the MSTP bridge priority to ensure it doesnât inadvertently take over as the root bridge for the CST, which RSTP essentially operates under.
Spanning Tree Type Globally or Per VLAN: While RSTP operates on a per-switch basis, MSTP can be more granular. You mentioned that changing priorities like in PVST-MST interoperability is not an option, but revisiting how spanning tree is configured on both the core and edge switches might unveil some overlooked settings that could improve interoperability.
The key to resolving this issue is to ensure that MSTP and RSTP can coexist without VLANs being unexpectedly blocked due to protocol incompatibilities. Adjusting priorities and ensuring correct port configurations, and possibly consulting vendor-specific guides or support will be crucial steps in troubleshooting this issue.
Let us know how you get along and if we can be of any further help as you continue your troubleshooting.
The Topology Change Timer and the Topology Change While Timer are two different mechanisms used by two different versions of STP.
The Topology Change Timer is a timer that is set by the root bridge the moment it receives the original TCN. This timer essentially tells the root bridge for how long it should set the TC bit in the BPDUs it is sending. This timer is typically set to Max Age + Forward Delay which is 20+15=35.
The Topology Change While Timer is used in RSTP as part of the mechanism to manage and recover from topology changes in the network. When a switch detects a topology changeâlike a link failure or restorationâit uses this timer to manage the period during which it actively propagates the change notification across the network. The topology change while timer is set to twice the hello time. So the default value for this should be 4 seconds assuming a default hello timer value of 2 seconds.
To see these set values, use the show spanning-tree detail command.