This topic is to discuss the following lesson:
Nice explanation, Rene.
You nicely described in STP, how the affected switch updated CAM table.
When a link fails (Uplink/Backbone) in RSTP environment, how the affected switch will collect MAC?
Hi Betar,
Here’s an example how the MAC addresses are updated for uplink failures:
Uplinkfast can be enabled for “classic” STP but a similar mechanism is built-in RSTP.
Backbone fast is also a good read:
A similar mechanism is built in for RSTP.
Rene
Rene,
Hi. In the last part of the lesson you convert switch B to PVST mode - what is the impact to the network - does computer A lose connectivity to the rest of the network outside of switch B for 30 seconds? What about if there was a host connected off of switch A and another host connected off switch B - they would still continue to communicate throughout the change of switch B to PVST mode?
Many thanks,
Thomas
Hi Thomas,
I just tried this, 3 switches and two hosts (one on SW1 and SW2). If you switch to any of the STP mode, you have donwtime. When I change one switch from RPVST to PVST+ then you see the interfaces going through the listening and learning states again.
When all switches are running PVST+ and I turn one of them into RPVST, you see it sending and waiting for proposals. It’s all compatible but expect your interfaces to be blocked for a moment 
Rene
Hi Rene,
Pasting the debug msgs:
SwitchA#
setting bridge id (which=3) prio 4097 prio cfg 4096 sysid 1 (on) id 1001.0011.bb0b.3600
what does it mean ? I’m not able to understand.
Sorry, Shanmugasiva,
I am not understanding what you are asking. Could you ask this another way?
If you are asking what this message means, I can try to help.
setting bridge id (which=3) prio 4097 prio cfg 4096 sysid 1 (on) id 1001.0011.bb0b.3600
“cfg 4096”
This means you set (either via spanning-tree vlan 1 4096, or spanning-tree vlan 1 root primary). This is what it means when it says “prio cfg 4096”–the vlan was configured to be priority 4096.
“prio 4097”
However, the actual priority is the configured priority + vlan number. So, in this case, the actual priority is 4097 (4096 + 1, for vlan 1). This is what it means for “prio 4097”
“(on) id 1001.0011.bb0b.3600”
This is the MAC address of the switch where this command was issued.
Thanks Andrew!
I meant to ask about the priority 4096 and 4097.
From the picture, Switch A has the priority 32768. Why do we represent 4096 here ?
Hi Shanmugasiva,
I suspect this simply might be a case of label in the picture not matching the configured IOS. In one of the outputs from Switch A it says “This bridge is the root” and it lists the Root ID of 4097.
Notice, the same thing is true for Switch B. It says in the text output it says its priority is 8193, but the label in the picture shows 32768.
Good catch!
--Andrew
Hello Rene,
I have configured a lab connecting three switches on gns3 (SW1,SW2 and SW3). SW1 is the Root switch. They are connected like this:
SW1(e1/3-DP)>>>SW2(e1/3-RP)
SW1(e3/0-DP)>>>SW3(e3/2-RP)
SW2(e3/0-DP)>>>SW3(e3/3-ALT/BLK)
The issue is that as soon as i admin down the port on SW3(e3/2-RP), the other port e3/3 becomes the new RP. This is expected. But when i bring back the port up on SW3(e3/2), the port doesn’t becomes automatically RP again, because its far end device port SW1 (e3/0) is going into err-disabled state, essentially the moment that i admined down the port on SW3(e3/2). Hence, in order e3/2 of SW3 reclaim again the RP role, i have to manually bounce the interface e3/0 of SW1. After that e3/0 of SW1 becomes UP, and e3/2 of SW3 becomes RP again. Is this expected behavior? Thank you in advance.
Ok i think i have found the issue here. I have configured udld mode aggressive on all the ports. So that is why when i admin down the port on SW3(e3/2-RP), the Root switch port SW1 (e3/0) goes into err-disable state! Since Root Switch port e3/0 will not receive any traffic, it goes into err-disable state. Finally, i just needed to bounce it, to work as before.
Also, when i tried to admin down the port on the Root Switch (SW1-e3/0) i noticed that the far end port doesn’t go to the error-disable state, even though the far end port (SW3-e3/2) is configured with udld mode aggressive. But then i remember that this should be expected, since i am admining down a port on a Root Switch, and the root switch is not sending BPDUs ever, so that is why SW3-e3/2 doesn’t go also into err-disable state!
Hello Angelos
Thanks so much for sharing your experiences with us. It’s great to learn from the learning experiences of others as it helps us all to identify similar situations in our studies and our jobs.
Once again, greatly appreciated!
Laz
Hi .
Whats P2p in type ?
whats the meaning of : SW3#
RSTP(1): updt rolesroot port Fa0/14 is going down
RSTP(1): Fa0/16 is now root port . whats updt rolesroot
SW2#
RSTP(1): updt roles, root port Fa0/14 going down
RSTP(1): we become the root bridge
RSTP(1): updt roles, received superior bpdu on Fa0/16
RSTP(1): Fa0/16 is now root port
now sw2 is he root bridge not SW1 ?
SW2#
RSTP(1): initializing port Fa0/2
RSTP(1): Fa0/2 is now designated
*Mar 1 04:08:32.931: %LINK-3-UPDOWN: Interface Fast Ethernet/2, changed state to up
how fa0/2 is designated in fa0/2 ?
Hello Abdul
Take a look at this post:
Based on the debug output you have displayed here, it looks like on SW3, Fa0/14 was originally the root port of the switch, but it is “going down”. Therefore, a new root port had to be designated, and it looks like the switch chose Fa0/16 for the new root port.
On SW2, it looks like Fa0/14 went down on this switch as well. The initial result was that SW2 made itself the root bridge. But in the meantime, it received a superior BPDU on Fa0/16, which informed SW2 that another switch will become the root. Therefore, SW2 changes its own role (it is no longer the root bridge), and thus it must choose a root port, choosing Fa0/16 for this role.
So to answer your question, no SW2 is not the root bridge. It temporarily became the root bridge until it received a superior BPDU. Remember that these events take place quite quickly and can occur in a different order each time. SW3 didn’t get a chance to become root bridge, but immediately received the appropriate BPDU on Fa0/16 to make that root port. While SW2 decided to become the root bridge until a superior BPDU is received, which it was. But these things happen so quickly that the order doesn’t really matter. For users, the quickness of reconvergence is still quite fast.
Fa0/2 is a new port that just came up. It becomes designated immediately simply because it didn’t receive a superior BPDU on that port.
I hope this has been helpful!
Laz
Thanks Really. The best explanation I have ever read!
Hello, new here
im trying to enable debug on these switches and keep on getting the error below on all three switches.im using packet tracer what am doing wrong ?.Thanks
S1>en
S1#debug spanning-tree events
^
% Invalid input detected at '^' marker.
S2>en
S2#debug spanning-tree events
^
% Invalid input detected at '^' marker.Hello Bernard
Unfortunately, Packet Tracer doesn’t support all of the commands and features available on real Cisco devices. This is one example of unsupported commands. Alternatively, you can use the GNS3 emulator which includes all of the commands available in a particular IOS image, or a choice of several other emulators including Cisco CML. More info on these can be found at the following lesson. The lesson may refer to CCIE, but the same applies for all Cisco certifications:
I hope this has been helpful!
Laz
1 Like
Hi,
Stupid question, think I may have missed something but I understand that RSTP uses Discarding, learning and forwarding port roles however uses the sync/proposal mechanism for convergence and Edge Ports can go immediately to forwarding with PortFast. In which circumstances does it go through the port roles (Discarding, learning and forwarding)?
Hello Samad
One thing that we have to keep in mind when examining the port states of rapid spanning tree is the fact that we have no timers. You are correct that the states are Discarding, Learning, and Forwarding. How they relate to classic STP states can be seen in this lesson:
Now you bring up a good question. When does a port actually enter each state, and under what circumstances? Well, STP states are straightforward, because they are timer-based, and they take place in sequential order, except when you have portfast configured.
For rapid spanning tree, these states are associated with the synchronization mechanism used. Specifically, as soon as a link between two switches running rapid spanning-tree comes up, the interfaces are in blocking mode. As the first BPDUs are being exchanged, the ports go into the learning state. This learning state is momentary and exists until the BPDU sync process (proposal bit and agreement) are exchanged. Once that takes place, the port will go into the forwarding state.
If you configure an edge port, then no synchronization process takes place. Thus the port immediately goes into the forwarding state without the need to send and receive BPDUs with proposals and agreements.
Now keep in mind that RTP is backward compatible with STP. If it detects an STP switch on the other end of the link, it will go into a classic STP operation, with the normal STP timers for all the states.
I hope this has been helpful!
Laz
Hi ,
I’d really like some clarification on RSTP and if there is a maximum\default diameter.
There are multiple links that seems to have conflicting information.
Some saying that the max age time decrements each switch it travels through, others saying max diamter of 20-40. I can’t find anything concrete written by Cisco.
I’m currently trying to troubleshoot an issue with a large spanning tree ring on the cusp of 20 switches, and one of the sides has had a break which is basically worst case secnario, as there is now one leg with the last switch in 19th place.
Is there a maximum size by default for RSTP? i was under the impression that it would just negotiate root ports \ superior BPDU’s with it’s neighbour. But what i’m seeing is that it is constantly flapping between making itself root and designated.
I have run a few debugs and this is what i’m receving.
Jan 11 2022 22:01:48.364 UTC: RSTP(150): Gi1/1 is now designated
Jan 11 2022 22:01:48.364 UTC: Found no corresponding dummy port for instance 150, port_id 128.1
Jan 11 2022 22:01:48.364 UTC: RSTP(210): Gi1/1 rcvd info expired
Jan 11 2022 22:01:48.364 UTC: RSTP(210): updt roles, information on root port Gi1/1 expired
Jan 11 2022 22:01:48.364 UTC: RSTP(210): we become the root bridge
Jan 11 2022 22:01:48.364 UTC: RSTP(210): Gi1/1 is now designated
Jan 11 2022 22:01:48.364 UTC: Found no corresponding dummy port for instance 210, port_id 128.1
Jan 11 2022 22:01:48.364 UTC: RSTP(303): Gi1/1 rcvd info expired
Jan 11 2022 22:01:48.364 UTC: RSTP(303): updt roles, information on root port Gi1/1 expired
Jan 11 2022 22:01:48.364 UTC: RSTP(303): we become the root bridge
Jan 11 2022 22:01:48.364 UTC: RSTP(303): Gi1/1 is now designated
Jan 11 2022 22:01:48.364 UTC: Found no corresponding dummy port for instance 303, port_id 128.1
Jan 11 2022 22:01:48.364 UTC: Found no corresponding dummy port for instance 303, port_id 128.9
Jan 11 2022 22:01:48.364 UTC: Found no corresponding dummy port for instance 303, port_id 128.9
Jan 11 2022 22:01:48.364 UTC: RSTP(303): Gi1/9 not in sync
Jan 11 2022 22:01:48.385 UTC: RSTP(150): updt roles, received superior bpdu on Gi1/1
Jan 11 2022 22:01:48.385 UTC: RSTP(150): Gi1/1 is now root port
Jan 11 2022 22:01:48.385 UTC: Found no corresponding dummy port for instance 150, port_id 128.1
Jan 11 2022 22:01:48.385 UTC: STP[150]: Generating TC trap for port GigabitEthernet1/1
Jan 11 2022 22:01:48.385 UTC: RSTP(210): updt roles, received superior bpdu on Gi1/1
Jan 11 2022 22:01:48.385 UTC: RSTP(210): Gi1/1 is now root port
Jan 11 2022 22:01:48.385 UTC: Found no corresponding dummy port for instance 210, port_id 128.1
Jan 11 2022 22:01:48.385 UTC: STP[210]: Generating TC trap for port GigabitEthernet1/1
Jan 11 2022 22:01:48.385 UTC: RSTP(303): updt roles, received superior bpdu on Gi1/1
and on the otherside i see similar, and disputes.
033478: Jan 11 12:04:19.464: RSTP(500): transmitting a proposal on Gi1/2
033479: Jan 11 12:04:19.474: RSTP(500): received an agreement on Gi1/2
033480: Jan 11 12:04:19.474: Found no corresponding dummy port for instance 500, port_id 128.2
033481: Jan 11 12:04:19.474: RSTP[500]: Gi1/2 dispute resolved
033482: Jan 11 12:04:19.995: RSTP(150): Gi1/2 Dispute!
033483: Jan 11 12:04:19.995: Found no corresponding dummy port for instance 150, port_id 128.2
033484: Jan 11 12:04:20.072: RSTP(210): transmitting a proposal on Gi1/2
033485: Jan 11 12:04:20.075: RSTP(210): received an agreement on Gi1/2
033486: Jan 11 12:04:20.075: Found no corresponding dummy port for instance 210, port_id 128.2
033487: Jan 11 12:04:20.075: RSTP[210]: Gi1/2 dispute resolved
033488: Jan 11 12:04:21.470: RSTP(500): Gi1/2 Dispute!
033489: Jan 11 12:04:21.470: Found no corresponding dummy port for instance 500, port_id 128.2
033490: Jan 11 12:04:21.501: RSTP(603): Gi1/2 Dispute!
033491: Jan 11 12:04:21.501: Found no corresponding dummy port for instance 603, port_id 128.2
033492: Jan 11 12:04:21.505: RSTP(603): transmitting a proposal on Gi1/2
033493: Jan 11 12:04:21.512: RSTP(603): received an agreement on Gi1/2
033494: Jan 11 12:04:21.512: Found no corresponding dummy port for instance 603, port_id 128.2
033495: Jan 11 12:04:21.512: RSTP[603]: Gi1/2 dispute resolved
033496: Jan 11 12:04:21.998: RSTP(150): transmitting a proposal on Gi1/2
033497: Jan 11 12:04:22.001: RSTP(150): received an agreement on Gi1/2
033498: Jan 11 12:04:22.001: Found no corresponding dummy port for instance 150, port_id 128.2
033499: Jan 11 12:04:22.001: RSTP[150]: Gi1/2 dispute resolved
033500: Jan 11 12:04:22.078: RSTP(210): Gi1/2 Dispute!
033501: Jan 11 12:04:22.078: Found no corresponding dummy port for instance 210, port_id 128.2
033502: Jan 11 12:04:22.078: RSTP(210): transmitting a proposal on Gi1/2
033503: Jan 11 12:04:22.092: RSTP(210): received an agreement on Gi1/2
033504: Jan 11 12:04:22.092: Found no corresponding dummy port for instance 210, port_id 128.2
033505: Jan 11 12:04:22.096: RSTP[210]: Gi1/2 dispute resolved
Is anyone able to shed any light on what could be causing this.
When the ring is in tact, spanning tree converges normally and everything is how it would be expected in terms of root bridges etc.