Just need your assistance in understanding BackBone fast feature...
I have a simple topology as below:
My understanding is, with backbone fast enabled, when the port Gig0/3 on SW2 receives a inferior BPDU it skips the Max-age then starts its transition towards Forwarding.
According to cisco documentation http://www.cisco.com/en/US/tech/tk389/tk621/technologies_tech_note09186a00800c2548.shtml
Inferior BPDU is defined by:
If an inferior BPDU is received on a port from our designated bridge, then this bridge has:
I tried case 1, it was working perfectly fine. The problem is with Case 2:
SW3 is a designated bridge and when I increase its cost to the Root (link b/w Sw3 - Sw1) then I would expect the following changes.
1. Gig0/2 is the new Root port for SW3
2. Fa0/31 on Sw3 will be blocked.
3. Gig0/3 on SW2 will be forwarding.
All the three are happing but in this case, since the gig0/3 on SW2 now receiving an inferior BPDU I would expect it to send RLQ Msg's but I dont see that ..
The transitions are happening but no RLQ msg's sent..
*Mar 1 20:27:58.786: STP: VLAN0001 Gi0/3 -> listening
*Mar 1 20:27:59.834: STP: VLAN0001 Topology Change rcvd on Gi0/3
*Mar 1 20:27:59.834: STP: VLAN0001 sent Topology Change Notice on Fa0/47
*Mar 1 20:28:13.793: STP: VLAN0001 Gi0/3 -> learning
*Mar 1 20:28:28.800: STP: Generating TC trap for port GigabitEthernet0/3
*Mar 1 20:28:28.800: STP: VLAN0001 sent Topology Change Notice on Fa0/47
*Mar 1 20:28:28.800: STP: VLAN0001 Gi0/3 -> forwarding
Am I missing something here? or have I totally misunderstood the concept?
Sorry somehow by mistake I deleted your post.
Your reply was:
Conceptually, yes that is how BackboneFast is supposed to work. Which debug are you running here? Looks like debug spanning-tree events. I don't think this shows you the RLQ messages. Can you try the same thing with a debug spanning-tree backbonefast?
I have run the debug "spanning-tree backbonefast" as well but not luck. Also the port transitions to LIS/LRN state only after the expiry of Max-Age timer.
Sorry about the late response. I tested this out myself and I see the same behavior that you do. It looks like BackboneFast is supposed to kick in only in cases of indirect root failure.
It seems to be looking at the root bridge information only to determine if a BPDU is inferior or not. An inferior BPDU due to a higher cost to root does not cause it to run. With a path cost increase only, the root bridge information still remains the same. So a switch receiving such a BPDU already knows that the root is not lost, only the cost has changed.
I suppose BackboneFast's main purpose is to quickly establish if the root is still existant in the network or not and re-converge appropriately. And in the case of an increased cost to root, we already know the root is still there since the root bridge information is same and hence it never kicks in.