Adding new switch to Spanning Tree network

[Benoit Desbiolles]

Hello community,

Regarding my Spanning Tree studies, I'm not sure about the behaviour on a specific use case, and specifically when we add a new switch to an existing STP topology (with cisco pvst+).

In this purpose I will expose to you my understanding of the situation, and maybe you could help me to confirm or correct me if I'm wrong.

Assuming we plug this new bridge called S4 with only one link, to the existing infrastructure (S3 bridge). This new S4 switch has already the VLAN configured.

Could you confirm to me the following statements with these 2 hypothesis ?

Hypothesis 1: new root bridge with higher priority

• The new ports up in S4 (new switch) and S3 (existing switch) will be immmediately put in listening state
• The new switch will send BPDU to announce itself as root bridge
• Existing S3 switch will ignore the S4 BPDU bridge which announcing itself as root
• Existing switch S3 will forward to S4 the BPDU of the existing root bridge
• S4 will stop to anounce itself as root, and its port will get the role of root port
• After S4 put this port as root port, the listening timer of this port continue and don't start again from 0

Hypothesis 2: new root bridge with lower/better priority

• The new ports up in S4 (new switch) and S3 (existing switch) will be immmediately put in listening state
• The new switch will send BPDU to announce itself as root bridge
• Existing S3 switch will ignore the S4 BPDU during the max_age timer (default 20s) before to announce also S4 as the new root bridge
• New convergence process start

And as complementary question, in the main lines, what will occur regarding this two hypothesis but with a RSTP ?

Ports immediately go to Learning state, and with higher priority nothing happens and with better priority a new proposal-agreement process start from S4 and S3, and continue on all the infrastructure ?

Many thanks in advance, your help will be very appreciated !

[Peter Paluch · Accepted solution]

Hello Benoit,

Hypothesis 1 is correct on all accounts.

Hypothesis 2 is not correct; what really happens is this:

• The new ports up in S4 (new switch) and S3 (existing switch) will be immmediately put in listening state
• The new switch will send BPDU to announce itself as root bridge
• Existing S3 switch will accept S4's BPDU as a superior BPDU right away, and move the role of its port toward S4 into the Root port role, note it will still be in the Listening state but the forward_delay counter will simply continue counting down.
• S3 will reevaluate the roles of all ports with respect to the knowledge about the new root bridge. This may cause its old Root port and Designated ports become Blocking, and/or old Blocking ports become Designated - this very much depends on how the topology looks like.
• Either way, the newly Designated ports on S3 will start propagating S4's BPDU, allowing the topology behing S3 to learn about the new root bridge.
• On S3, ports that have been Forwarding before S4 was connected will become Blocking after S4 connection only if they become non-designated. In other words, S3's ports do not become Blocking just because the root bridge and Root port have changed - if they become Blocking, it is become they no longer originate the best BPDU on the segment and so are not entitled to remained Designated.

With RSTP, things are somewhat different. In Scenario 1 (Hypothesis 1), both switches will send a Proposal to each other; this is because every RSTP port in Designated Discarding or Designated Learning role/state combination sends out Proposals. However, S3 will ignore S4's Proposal because the BPDU will be inferior to S3's own BPDUs. When S4 receives S3's Proposal, it will learn about the proper root bridge, elect the Root port toward S3, block all its non-edge Designated ports, and send back an Agreement, then unblock the Root port. Upon the Agreement, S3 will unblock its port toward S4. No other processing, apart from generating and flooding a Topology Change event, will happen.

In Scenario 2, it starts the same - both switches will send a Proposal to each other. This time, S4 will ignore S3's Proposal because it is inferior. S3, upon receiving S4's Proposal, will learn about a new root switch, elect the port toward S4 as a new Root port, reevaluate roles of all its remaining ports, block all of its non-edge Designated Ports, and send back an Agreement which will enable both S3 and S4 to unblock their ports on this new link. Further, as S3 has moved its non-edge Designated ports into Discarding state, this allows these ports to send out Proposals, so the Proposal wave has now effectively moved to S3, and this process will repeat in a cascade throughout the network.

Feel welcome to ask further!

Best regards,
Peter

[Benoit Desbiolles]

Thanks for this very clear answer.

[whistleblower14]

hi @Peter Paluch regarding your answer

---

@Peter Paluch wrote:

With RSTP, things are somewhat different. In Scenario 1 (Hypothesis 1), both switches will send a Proposal to each other; this is because every RSTP port in Designated Discarding or Designated Learning role/state combination sends out Proposals. However, S3 will ignore S4's Proposal because the BPDU will be inferior to S3's own BPDUs. When S4 receives S3's Proposal, it will learn about the proper root bridge, elect the Root port toward S3, block all its non-edge Designated ports, and send back an Agreement, then unblock the Root port. Upon the Agreement, S3 will unblock its port toward S4. No other processing, apart from generating and flooding a Topology Change event, will happen.

does that mean that no Network outage will happen when a new switch (with higher STP Priority than current Root-Bridge) is connected to a running network?