STP Question - Need Quick Answers

[visitor68]

Hi... need to connect a non-Cisco switch that only runs open standard rstp, stp or mstp, but NO rapid-pvst+.

I need to uplink the switch to 3 separate Cisco L2 domains....

Can this be done?

imagine each domain has vlans 2-10, 11-20 and 21-30 respectively...no redundant numbers....

THANKS

[Peter Paluch]

Hello,

It is possible to connect RPVST+ switch to a pure RSTP switch.

Cisco's RPVST+ will interoperate with pure RSTP using its VLAN1 instance. The RPVST+ running in VLAN1 will interact with the non-Cisco switch and its RSTP and will negotiate the resulting spanning tree topology as seen in the pure RSTP region. RPVST+ instances for other VLANs will be tunneled across the pure RSTP region without interacting with it. The net result is that the non-Cisco region will establish a loop-free topology in cooperation with VLAN1 RPVST+, and the RPVST+ instances for all other VLANs will be carried across this loop-free topology transparently.

In this scenario, it is especially important to make sure that the native VLAN on trunk is set identically on both switches interconnected by that trunk, i.e. avoid native VLAN mismatches.

Ideally, in this case, you should consider running MSTP on all switches but converting to MSTP will require an outage window, and also, MSTP requires knowing a fair share about its internal operation before deploying it - it is not exactly a plug-and-play toy.

Best regards,

Peter

[visitor68]

Peter, I totally agree with you about how r-pvst+ interacts with the rstp open standard....

My concern is that there will effectively be 3 separate RSTP instances running on the same non-Cisco switch. Will it simply converge in a manner such that 3 separate CSTs will be running on the same switch? Will it simply recognize 3 different root bridges? This is the confusing part because CST converges on VLAN 1, but now you have 3 instances of VLAN 1 from 3 separate L2 domains.

So when I do a sh spanning-tree brief on my 3rd party switch, which switch in which domain will it recognize as the root bridge? Will it recognize three root bridges...?

A bit confusing, no?

[Peter Paluch]

Hello,

My concern is that there will effectively be 3 separate RSTP instances running on the same non-Cisco switch.

Hmm, I do not understand this statement. Why do you believe that the non-Cisco switch will run 3 separate RSTP instances? If this switch truly does not support per-VLAN RSTP then regardless of the number of connected ports and created VLANs, the switch should run a single RSTP instance that is oblivious of all VLANs. The spanning-tree that this single RSTP instance negotiates will then be forced upon all VLANs created on the non-Cisco switch.

Please correct me here if you believe that the non-Cisco switch behaves differently.

Best regards,

Peter

[visitor68]

           

I have 3 separate L2 domains, right? OK, each domain has its root bridge for VLAN 1. So, if the non-Cisco switch only recgnize ONE CST and ONE root bridge...how does it handle the other two? OR is it the case that the access switch will simply evaluate ALL the BPDUs from all 6 switches and recognize ONE of the 6 switches as the root?

Lets answer this question first before we continue....

[Peter Paluch]

Hello,

is it the case that the access switch will simply evaluate ALL the BPDUs  from all 6 switches and recognize ONE of the 6 switches as the root?

This is the correct option. Regardless of how many separate L2 domains you have, each of them speaks RSTP in VLAN1, so they will merge in their VLAN1 spanning tree. As the non-Cisco switch does not understand exactly "RSTP in VLAN1" - it understands only RSTP without respect to VLANs - it will seamlessly merge with this spanning tree that results from VLAN1 running on all Cisco switches.

Best regards,

Peter

[visitor68]

OK., now we are getting somewhere....

scenario:

MAC A can be reached through the uplink to switch 3. The access switch knows this from the usual MAC learning process. HOWEVER, the access switch sees switch 1 as the root bridge....

So how does it reconcile sending a frame to switch 3 via the uplink to switch 3 when switch 1 is the root?

Typically, after STP convergence, all but one link to the root is blocked....so, in this case the acces switch will learn that MAC A is accessible through link 3 to switch 3, but it is NOT the root...how are the two reconciled?

EDIT: Actually, let me rephrase that....once the link to switch 1 is active because switch 1 is the root, ALL the other uplinks should be BLOCKED, yes? After all, we said that the access switch is running ONE instance of RSTP -- the CST. So, with link 1 to switch 1 active and all other 5 links blocked, and with L2 domain 1 separated from domains 2 and 3, how are hosts in the other domains (2 and 3) reached??? EDIT

[Peter Paluch · Accepted solution]

Hello,

Actually, let me rephrase that....once the link to switch 1 is active  because switch 1 is the root, ALL the other uplinks should be BLOCKED,  yes? After all, we said that the access switch is running ONE instance  of RSTP -- the CST. So, with link 1 to switch 1 active and all other 5  links blocked, and with L2 domain 1 separated from domains 2 and 3, how  are hosts in the other domains (2 and 3) reached???

The resulting spanning tree in VLAN1/CST will end up like this:

Here, according to your assumption, switch 1 is the root bridge. I have removed all links from this topology that would be blocked by CST or RPVST+ running in VLAN1. Note that for switches 3/4 and 5/6, their direct connection would be blocked. Only the direct link between switches 1 and 2 would be forwarding, and the link from switch 2 to the non-Cisco switch would be blocked. So this is basically what the non-Cisco switch and RPVST+ in VLAN1 will see. So if there are stations in multiple domains put into VLAN1, this would be the loop-free topology through which they would communicate.

You are asking how are hosts in the other domains 2 and 3 reached from domain 1 if the domains have their own non-overlapping set of VLANs. I am afraid I do not understand this question. If each domain uses its own distinct set of VLANs then hosts in different domains (and hence different VLANs) won't communicate at all precisely because they are in different VLANs. Perhaps you could clarify your question a little more. Thank you!

Best regards,

Peter

[visitor68]

Peter, outstanding....I see where I went wrong. I had the wrong converged topology in my head...thats where my questions stemmed from. Well, first I was thinking that 3 separate STP instances would be running, which was obviously wrong. You cleared that up with your answer of 9:39 pm. My second mistake after realizing that it will all be one topology, was the convergence model in my head. For some stupid reason, I was thinking that ONLY ONE path will be forwarding and all others blocked...forgetting that there is no reason why the other links to separate domains which do NOT cause a loop should be blocked.

Last question. How did you come up with this logical topology? Why would the crosslink between 1 and 2 remain in tact, yet the other crosslinks are blocked?

Thank you!!

[Peter Paluch]

Hello,

Last question. How did you come up with this logical topology? Why would  the crosslink between 1 and 2 remain in tact, yet the other crosslinks  are blocked?

Hey, don't make this the last question This discussion is awesome so if you have any ideas, questions or comments, keep them coming!

The crosslink between 1 and 2 would remain because if 1 is the root bridge, the shortest path from 2 to 1 is via the direct link, not through the non-Cisco switch (assuming that all links have the same STP cost). For the remaining switches, the shortest path is through the non-Cisco switch directly, not via their neighbor and only then to the non-Cisco switch. Hence the topology I sketched.

Best regards,

Peter

[visitor68]

Peter, excellent thread....thanks for straightening out my thinking..Honestly, I should have known better...not sure why my mind crapped out on this one :-)

[Peter Paluch]

Hello,

Thank you! If this thread is excellent then it is because you have presented a fine case and was giving interesting questions. Thanks again!

Regarding "knowing better" - well, the STP protocol is somehow prone to misunderstandings. I needed quite a few years to wrap my head around it and I am still not entirely sure I understand everything...

Take care!

Best regards,

Peter