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?
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.
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?
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
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.
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
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.
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.
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 ?
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.
I have configured a lab connecting three switches on gns3 (SW1,SW2 and SW3). SW1 is the Root switch. They are connected like this:
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!
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!