Skip navigation
Cisco Learning Home > CCNP R&S Study Group > Discussions
2035 Views 15 Replies Latest reply: May 4, 2012 10:35 AM by Tian Yan RSS 1 2 Previous Next

Currently Being Moderated

BPDU details when topology change in STP

Apr 26, 2012 7:45 AM

Tian Yan 57 posts since
Apr 24, 2012

Hello all,

I am currently reviewing CCNP BCMSN Official ExamCertification Ver 4.0 and encounter below queries in STP chapters.

Untitled.jpg

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

Tian Yan

  • Martin 13,081 posts since
    Jan 16, 2009
    Currently Being Moderated
    1. Apr 26, 2012 10:46 PM (in response to Tian Yan)
    Re: BPDU details when topology change in STP

    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

  • Martin 13,081 posts since
    Jan 16, 2009
    Currently Being Moderated
    3. Apr 26, 2012 10:41 PM (in response to Tian Yan)
    Re: BPDU details when topology change in STP

    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.

  • Martin 13,081 posts since
    Jan 16, 2009
    Currently Being Moderated
    5. Apr 27, 2012 2:11 PM (in response to Tian Yan)
    Re: BPDU details when topology change in STP

    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.

  • Martin 13,081 posts since
    Jan 16, 2009
    Currently Being Moderated
    7. Apr 27, 2012 8:05 PM (in response to Tian Yan)
    Re: BPDU details when topology change in STP

    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.

  • Martin 13,081 posts since
    Jan 16, 2009
    Currently Being Moderated
    9. Apr 28, 2012 2:11 PM (in response to Tian Yan)
    Re: BPDU details when topology change in STP

    PT is no good for testing; GNS3 or real gear.

  • ktoruner 15 posts since
    Jan 22, 2010
    Currently Being Moderated
    10. Apr 28, 2012 2:35 PM (in response to Tian Yan)
    Re: BPDU details when topology change in STP

    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. 

  • ktoruner 15 posts since
    Jan 22, 2010
    Currently Being Moderated
    12. May 4, 2012 12:41 AM (in response to Tian Yan)
    Re: BPDU details when topology change in STP

    Hi,

     

    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.

     

    Untitled-1.jpg

    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.

    Kutay

      

  • ktoruner 15 posts since
    Jan 22, 2010
    Currently Being Moderated
    14. May 4, 2012 10:17 AM (in response to Tian Yan)
    Re: BPDU details when topology change in STP

    Hi Tian,

     

    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.

     

    Kutay

Actions

More Like This

  • Retrieving data ...

Bookmarked By (1)