I am currently reviewing CCNP BCMSN Official ExamCertification Ver 4.0 and encounter below queries in STP chapters.
Catalyst A is the root bridge here, when link between switch A and Switch C fails. FE1/2 of switch C will transition to Forwarding status after 2 seconds as configuration BPDU with TCN bit will arrive on that port. thus STP can re-convergence in 2 seconds. However, what I concern here is the action of switch C. Query 1: Will it immediately initial STP algorithm (flooding out BPDU assuming itself as Root Bridge) upon decting the link failure or it just waits for a new BPDU from Root bridge from other ports?
Query 2: If FE1/2 of Switch C is Designated Port and the far-end is Blocked port, same link fails, what is the detailed procedure for convergencing (I did not find this scenario discusssed in that Book). In this case, Switch C won't be able to recive the configuraiton BPDU with TCN bit from Root.
Any help is highly appreciated. thx
Yes, it immediately initial STP algorithm 'casue of layer 1 failure;
in case 2, switch C waits for BPDU from Root switch via SW B (SW A sends TCN to all). ports are in learning state when topology changes.
Message was edited by: Martin
thx for your reply, martin. I am clear on query 1 now. one further query though,
In case 2 where FE1/2 of switch C is Designated Port and its far-end is Blocked Port, and same link fails, Switch C behaves below actions in sequence:
1. Even though Switch C realizes alternated path to Root Bridge through its Designated Port, TCN BPDU is only allowed to send from Root Port of Non-root bridges. Therefore, Switch C won't send out TCN BPDU through Designated Port but will immedately flood out BPDUs assuming itself as Root Bridge. FE1/2 of switch C now transitions to Listening from previous Forwarding.
2. Swtich B will receive both STP Initial BPDU from switch C and configuration BUDP with TCN bit set from Root bridge, then it examines the bridge ID and pritory on both BPDUs and decides that root bridge should be Switch A again.
3. Finally, Switch B should relay the configuration BPDU with TCN bit set to switch C through its FE1/2 which is blocked at that time, how can BPDU be sent out on that port ? So I assum that Switch B will wait for Forward Delay (15 secs) before transitioning the FE1/2 to Listening status and relay the configuration BPDU to Swtich C. Thus network re-convergences after about 37 seconds (15 secs forward delay + configuration BPDU sent out every 2 seconds + 15 seconds forward delay on FE1/2 of switch C) when Switch C transitions FE1/2 to forwarding as Root Port.
I don't think FE1/2 of Switch B will transition to Listening status immediately upon detecting either the STP intialization BPDU from switch C or the configuration BPDU from the root bridge, as CCNP books confirms me that Non-root bridges react to the configuration BPDU with TCN bit set only by shortenning their bridging table aging out from 300 secs to 15 secs rather than changing the status of its ports immediately.
Please correct if I was wrong. thx
Opps, you are correct, I thought about RSTP;
Switch C waits for TCN BPDU from Root after the failure. Root SW A sends TCN to B, B sends it to SW C who will change its port upon receiving TCN.
and the "immediately" meaning Sw A sends TCN becasue of layer 1 failure.
thx for your clarify, Martin. However, I want dive deeper here for more details, (sorry about my endless queries)
1. Upon detecting the failure, Switch C will immediately remove the best Root Path Cost from its memory. If Switch C will wait at this point, how long ? After that, what happen to the Port state on Switch C ?
2. If Switch C begins to initial STP assuming itself as Root bridge, Switch B would receive "inferior" BPDU from switch C, How will switch B react to those BPDUs and how will the port states on swtich B change during this reacting? (personally, I think switch B will ignor these inferior BPDUs as it can figure out that switch C is not eligible for root bridge)
Furthermore, I am quite confused about how exactly non-root bridge will react to configuration BPDU with TCN bit set sent by Root bridge. Books says bridging table aging out time will be shortened from 300 to 15 seconds.
3. During the 15 seconds elapse, all ports on non-root bridge will keep their states unchanged ? can they still learn MAC address from the incoming frame?
4. During the 15 seconds elapse, the MAC address table is left untouched or is cleared ?
I just did not see the differences caused by the aging time shorterning.
Pls also help.
it is 20 sec. as of MAX Age. timer is used to do anything when interface stops getting BPDUs.
Case 1: shutting down port on Root Sw.
1. Link Root port C to Sw A (root sw) fails; 0 is start time. + 1 or 2 BPDUs = 2 - 4 sec.
2. Sw C forwarding port waits for BPDU for 20 sec. (waits for MAx Age timer to expire) 0 +20 sec. +/- 4 sec
3. SW C previously blocking port starts to listen mode for 15 sec;
4. Sw C port moves to learning phase for another 15 sec. 0+20+15+15
5. Sw C new Root port is forwarding after apprx. 50 -54 sec.
Case 2: C and A link failure.
Link that is Root port on C goes down, C still has other port getting BPDUs from B so it does not have to wait for timer to expire (no need for 20 sec max age) and moves the other port to listening, learning , and forwarding.
This is layer 1 failure on same switch that has root and blocking port. Switch knows that one of its port failed so starts STP process on the other port skipping 20 sec. Total 30 sec +/- 2 sec.
Time for reconvergence is either 30 sec or 50 sec +/- 4 sec depending on where failure has occurred, how far is from Root, on default setting and configs and model of switches. 20 sec is MAX Age timer;
So, problem is that sometimes you do have 20 sec and other times you do not. Since it is Cisco exam, I would stick with whatever books say.
In RSTP Switch C assumes itself as Root bridge, not in STP and not in your case because of C getting BPDUs from sw b over blocking port. Blocking ports still getting BPDUs, they just not sending out or forward traffic.
In RSTP, sw C would tell B that he is the root, but B would reply that A is the root and sw C must agree.
Hey, Martin, you are the man, I am clear about the topology change issues now. thank you so much.
Now, the only unsolved query is how exactly the non-bridge react to the configuration BPDU with TCN bit set.(query 3 and 4 in my previous post).
Any information is grateful.
Forgot to add, according to my notes, 15 seconds is for CAM table to time out and start process of re-fresh or re-flooding from time of TCN BPDU arriving at switch;
STP only Root switch will send TCN when it hears about topology change. When non-root switch gets it, it starts 15 sec timer and sends TCN ACK back to Root.
I think MAC address table is left untouched on all switches during first 15 seconds;
What happens to ports on non-root switches, it depends is the switch is affected by TCN change or not; if you run debug spanning-tree events you may notice no changes on non-root and unaffected switches; while switch affected or crated TCN does moves thru port stages.
do u have GNS? GNS3 supports STP with switching modules in; you can run 3 switches and simulate TCN like from picture above.
Never use PT for advanced STP issues. PT will definitely causes confusion because it's not stable when monitoring advanced and specific packet flow. As Martin said go with GNS3 or a home lab.
I setup this topology on my lab and i listed the reactions of switches (by the help of sniffers on both switches) to the topology change below. Everything is clear except one thing which i’ll try to explain later and i need help to grasp the issue.
1. Link between SwA and SwC broke.
2. SwC loses its root port. It’s also not receiving BPDUs from SwB. Only option for SwC is to start sending Config.BPDU’s with TCN bit set and assuming itself as the root bridge. By the time SwC port ½ is still a designated port.
3. SwB receives the BPDU from SwC on its blocked port. As this one is not the one it expected (normally expecting for a BPDU with SwA as the root bridge.) it starts the max-age timer (because the BPDU it’s keeping already is better than the one it received. –SwA’s mac address is lower than SwC )
4. After max-age lasts (20 sec.) SwB shifts it’s port ½ as designated (keeps it’s root port because the Conf. BPDU from SwA is better). And relays the first Config. BPDU from SwA to SwC.
5. SwC immediately changes it’s port ½’s status from designated to root.
6. Now converging is achieved.
Here is my question:
I know that non-root bridges send TCN BPDU’s if only two conditions occur.
· When a port that was forwarding is going down (blocking for instance).
· When a port transitions to forwarding and the bridge has a designated port. (This means that the bridge is not standalone.)
SwC sends a TCN BPDU just after shifting it’s port ½ as root port. There is no incident that it’s port is being blocked and goes again forwarding. Just a shift from designated to root. Is it normal that SwC sends a TCN BPDU from it’s 1/2 port.
I can share my frame logs if anyone would like to have a look. Thanks in advance.
As per martin's answers to my preceding queries, wgen link between A and C breaks, C won't be able to receive any BPDU packet with TCN bit set. Thus, it will wait for Max aging time (20 secs) before it floods out BPDU assuming itself as root bridge. However, as per your information above, switch C immediately floods out BPDU assuming itself as root bridge when link breaks. For this collision, I prefer to beleive that the Cisco Packet Tracer does not show up the correct actioins as that silumation software is regarded as far from a good one for advanced and indepth simulation.
for you query, I just outline my own thoughts. When Switch C begins to flood out BPDU assuming itself as root bridge, all ports will be actually in Listening state, and transition to Learning, finally Forwarding (exactly the same time you see port 1/2 has been elected as root port). So there is actually a Topolgy change here (port 1/2 transition from listening, learinig to Forwarding).
Anyway, most guys has recommend me to use GNS for CCNP lab rather than cisco packet tracer as it might be quite tricky.
I used my home lab (real switches a 3560, a 3750 and a 2900xl) for simulating the topology. The actions listed above is from a real lab. I just used PT to easily draw the topology. I can share the frame flow files from wireshark if you'd like.