STP Blocking Port

[parthrawat979]

I just want to know does a port of a switch in Blocking State(Alt.) process the bpdu's?? Like in this given forum 
https://community.cisco.com/t5/switching/stp-indirect-topology-change/td-p/2202906
When SW3(R3) apparently received a inferior bpdu on it's blocking state port than how does it process it and then send a superior bpdu from that same port?? And how does this change happen from blocking to DP just after receiving a inferior bpdu from the neighbor??

[Mark Elsen]

 
- @parthrawat979   A port in Blocking / Alternate state absolutely does process BPDUs — it just does not forward them.
                               If an Alternate port didn’t process BPDUs, it would never know when the currently active path fails.

  M.

[balaji.bandi]

Switch port in the Blocking State (or Alternate role) continues to receive and process BPDUs. While it discards standard data frames to prevent loops,
It must monitor BPDUs to detect topology changes and maintain the Spanning Tree Algorithm (STA)

STP constantly sends and receives BPDUs so it can detect topology changes. When a topology change is detected, the root bridge sends a TCN to all switches, and all switches go through full convergence to determine a new topology.

When a blocking port on a switch (like SW3) receives an inferior BPDU from a neighbour, it indicates the neighbour has lost its path to the Root Bridge and now thinks it is the new Root.

You can find how the backend works :

https://community.cisco.com/t5/artigos-routing-switching/spanning-tree-protocolo-stp/ta-p/5209086

[paul driver]

Hello

---

@parthrawat979 wrote:

I just want to know does a port of a switch in Blocking State(Alt.) process the bpdu's?? 
When SW3(R3) apparently received a inferior bpdu on it's blocking state port than how does it process it and then send a superior bpdu from that same port?? And how does this change happen from blocking to DP just after receiving a inferior bpdu from the neighbor??

---

In a blocking state it ONLY receives them but does read them to see it it has that received bpdu is still "better" then its own (meaning it has a better bridge ID or path cost to the root switch) 

If the received BPDU is "worse" then its own bridge id or path cost to the root, it will begin to claim a better path toward the root thus it will begin to send/receive bpdus and participate in stp process by coming out its blocking state

[Cristian Matei]

Hi,

   A port in Blocking / Discarding final state (not blocking initial state, so the port has transitioned through listening and learning phases and ended up in Blocking final state, or because it has the portfast / edge function enabled it went to Forwarding state and instantly back to Blocking final state) does not send BPDU's, unless one o the following conditions happens:

1. Bridge Assurance is enabled (bridge assurance means all ports send BPDU's at the BDPU HELLO interval of 2 seconds unless this value has been changed, regardless of port role and state)

2. It stops receiving superior BPDU's on the port, either for the Max Age interval with a default value of 20 seconds unless changed (for STP and MSTP CIST), either for three times the BPDU Hello interval (for RSTP and MSTP non-CIST); in the case of no longer receiving BPUD's, the port understands that something has changed in the topology and it needs to reconverge, thus it needs to start sending BPDU's to negotiate its new final state and role

3. It starts receiving inferior BDPU's on the port, so the port understands that something has changed in the topology and it needs to reconverge, thus it needs to start sending BPDU's to negotiate its new final state and role; it will transition into Forwarding state and Designated Role

4. Its Root Port and / or associated "cost" from STP algorithm perspective has changed towards a better path, so the switch now has a better path towards Root Bridge than the information in the BPDU received on its Blocking port, in which case switch understands that something has changed in the topology and it needs to reconverge, thus it needs to start sending BPDU's on its Blocking port to negotiate its new final state and role; it will transition into Forwarding state and Designated Role 

   Except, the above mentioned conditions / triggers, a port in final Blocking state it will only receive, accept and process BPDU's to keep its port in a stable state and role, however it will never send BPDU's on that port. BPDU's are never relayed but generated, as each BPDU lives on a specific link / segment only.

    Also, although in Cisco IOS you see the ALT / Alternate role showing up regardless which STP flavour you run, the ALT Role does not exist in STP / 802.1D, it only exits on RSTP / 802.1w or MSTP / 802.1s algorithms; so just to be clear, IOS shows the ALT Role when when running STP / 802.1D, however from re-convergence perspective the port will NOT behave as ALT as 802.1D algorithm is not aware of the concept.

   Also, topology change is signalled through TCN BPDU only by STP / 802.1D and MSTP CIST, while RSTP / 802.1w and MSTP non-CIST use the TC bit in a regular configuration BPDU for this purpose.

    I hope this add some clarity. If you need further guidance, can you make your question clear and elaborate it more? 

Thanks,

Cristian.

[parthrawat979]

BPDU's are never relayed but generated, as each BPDU lives on a specific link / segment only. Coudn't understand this line of yours. I thought BPDU's are always generated by a Root Bridge in an stp topology and relayed by non-root bridges??

[Cristian Matei]

Hi,

   Regardless of the STP version you're running and who's the root bridge, imagine three switches, connected like SW1 -- SW2 -- SW3. Initially, there's STP Root Bridge Election as well as Port States and Roles Election, so initially, as any link comes UP, both sides of the link will send at least one BPDU (we take into consideration only STP being enabled, without features like BPDU Filter which based on how it's enabled it might alter my statements). Finally, for the sake of the discussion, let's assume that SW1 is elected as the Root Bridge and layer 2 wise network has converged (all ports have reached their final port states and roles).

1. This means on the link between SW1 and SW2, SW1's port will have Designated Role and Forwarding State, thus will be the one switch sending / generating BPDU's on the link, while SW2's port will have Root Port / Non Designated Role and Forwarding State, thus will be the switch receiving BPDU's on the link.

2. On the link between SW2 and SW3, as SW2 has a better path to the Root Bridge than SW3 from STP's computation algorithm perpective, it means SW2's port will have Designated Role and Forwarding State, thus will be the one switch sending / generating BPDU's on the link, while SW3's port will have Root Port / Non Designated Role and Forwarding State, thus will be the switch receiving BPDU's on the link.

   So just to be clear, on each link, the source MAC address of the BPDU being sent is the MAC address of that link which belongs to the switch owning the link. So, claiming / stating that BPUD's are relayed is a false statement, it was done in many documents and books to easily explain a specific behaviour seen in STP vs. RSTP / MSTP (which is different), however, as you can see, as you're not the only engineer with this doubt, it led to misunderstandings. Do a packet capture and see it for yourself, as seeing is believing and enhances learning. What this statement was supposed to say is that in STP, if a bridge no longer receives BPDU's from the Root Bridge (so from upstream, namely on its Root Port), it will NO longer generate BPDU's away from the Root Bridge (so downstream, namely on its Designated Ports), thus the misleading concept of relaying, because in STP for a bridge to generate BPDU's downstream it MUST receive BPDU's from upstream; In RSTP / MSTP, this changed, for many reasons, primarily for faster convergence as in RSTP a switch will ALWAYS send BPDU's downstream, regardless if receiving or not receiving BPDU's from upstream.

   Hope it makes much more sense now.

Thanks,

Cristian.

[paul driver]

Hello 

---

@Cristian Matei wrote:

 So, claiming / stating that BPUD's are relayed is a false statement

---

Can you elaborate on this please, As based on the above statement this is incorrect, and what i mean by that is take cBPDUs, these are relayed, but you saying they are not

So the above implies - once a cBPDU is receive on a root port, that cBPDU is just read then discarded and then the non root switch recreates its own cBPDU, adds it own link path cost to the root path cost of the original cBPDU along with any tca/tc flags then forward's it ?

[Cristian Matei]

Hi,

  Yes, this is exactly what I'm saying, with one minor adjustment to your statement, at the end I would use "then sends it" instead of "then forward's it", as forwarding generally means I got something and send it further as is.

Thanks,

Cristian.

[paul driver]

Hello
thats interesting- 
Just to make sure we are talking about STP as a whole (not just 802.1w) any bpdu in STP are never relayed ?

[Cristian Matei]

Hi,

   Yes, absolutely. BPDU lives on a single link / segment, cannot be send / relayed / flooded downstream as received from upstream, it needs to be regenerated; it also makes complete sense if you think about it, as STP shares similarities with distance vector algorithms (RIP / EIGRP) where switches exchange BPDU's only with their direct neighbors rather than knowing the entire network map as in the case of link-state algorithms (IS-IS intra-level or OSPF intra-area).

Thanks,

Cristian.

[paul driver]

Hello @Cristian Matei 
Okay, if we specifically focus a on cBPDU within say pvst+  my understanding and always has been that ONLY the root switch can generate and relay or "forward" these cBPDUs.

However you are stating this is an invalid statement, of which you seem quite certain it is.

So now if you are correct, Then I'd say its quite disconcerting to know the literature Cisco have produced on this is invalid, be it from its online CCO documentation or from its official press books.

Maybe others have a view on this-- I surly cannot be the only one to have the same point of view or do I?

Edited- good discussion by the way!

[Cristian Matei]

Hi,

 As stated before, the term relaying has been misleading, nothing more. Can you share a specific document or Cisco press chapter where this is explained deeper, as I would be able to put the light on where the misunderstanding lies.

As also stated, in 802.1D, if the root bridge does not generate BPDU's for whatever reason, the other switches will not generate BPDU's either, it's a condition in the STP algorithm, where the non-root bridge requires receiving upstream BPDU's to generate downstream BPDU's.

Obviously, suggest make your own testing environment with packet captures and /or read the IEEE standard document to see it happening.

Thanks,

Cristian.

[paul driver]

Hello @Cristian Matei 
It makes sense what you are saying but it doesn't justify against the multiple sources of materiel that states "relaying/forwarding/flooding" of cBPDUs- does happen

INE -  switched campus - STP
narbik kocharians CCIE lab guide - switching stp
CCIE Routing and Switching v5.0 Cert Guide  - chapter 3 page 111                     
Ciscos own document mentions relaying prior to rpvst - Understand Rapid Spanning Tree Protocol (802.1w)
Cisco CCIE development - lan switch - BPDU types chapter 6 - propagation of cBPU page 183
Cisco Encor enterprise press -  chapter 2 stp  page 49 - phase 3, page 50 indirect failures