MSTP issues: network diameter limitation?

[Sergey_Yakovets_2]

Hi guys,

I am just browsing and looking for a solution to converge my multi-vendor switched network and bring some redundancy to it as recently

we managed to get a redundant links.

I have a need to change core switch to Cat3750G, which has Per-VLAN-RSTP+ on board, but tests have shown that it won't be compatible with some other proprietary per-VLAN RSTP solution other vendor's switches use currently.

So, I thought maybe standard-based MSTP design might do the trick. I've made some tests and got some weird and unstable switching result.

I have two topology rings with a core switch in the center. Every ring has about 10 switches, so practically network diameter may vary from 5 switches (when spanning-tree converges in the center and I have a bloking port somewhere int the middle of the ring) to about 10-11 switches (if a I have link failure on any of ports right at the core switch).

I disconnected one port from core switch to eiminate a possible switching loop while I will be configuring new MSTP design. Then I started enabling MSTP on all the switches staring from core Cat3750G to MSTP, one by one, placing all switches to the same MSTP region, and placing all VLANs to default MSTI0(CIST) cause I don't need to organize any separate MSTP instances for every VLAN or for group of VLANs. When I turned MSTP on on 7th or 8th switch in the chain (cause I had a physical chain when I disconnected one port out of redundant ring) I got all switches "flapping", storming and flooding the network with broadcasts. Even when I had one redundant port disabled.

I have no idea what I am doing wrong. I noticed that Cat3750G has an option that defines a possible network diameter which actually automatically changes some hello, max age etc. attributes according to diameter specified. When I defined a maximum network diameter of 7, if did't change anything: I still have hello timer of 2 sec etc. I've been wondering if the maximum network diameter has something more than just a "variable" to fine tune hello timers etc? Maybe I won't be able to use MSTP in my network which might have diameter more that 7 switches. Or maybe it was a mistake of placing all the switches to the same region and all the vlans to the default MSTI0 (CIST) and I should configure one MSTI per VLAN or per some group of VLANs and subdivide my switches to few MSTP regions?

My topology briefly looks like this:

+--SW1----SW2----SW3---CORE---SW4---SW5--SW6---+

|                                            |           |                                         |

+---SWxx---SWxx-----------+           +------SWxx-----SWxx----+

As I said, each "ring" has about 10 switches connected side by side.

Any suggestions are welcome. Thanks in advance.

[prima.ramadhan]

Anyone? Personally, I do not think rstp/mstp has limitation on the diameter, since it is not timer based.

[Peter Paluch]

Hi guys,

This is an interesting issue even though an old one. Would be interesting to know if Sergey solved it eventually.

Regarding the diameter issue, I do not think this is the case. In RSTP, the maximum diameter is defined by the max_age timer value. RSTP switches ignore any RSTP BPDUs whose Message Age is equal or higher to the max_age value indicated in the BPDU (IEEE 802.1D-2004 clause 9.3.4 a) ). The legacy 802.1D STP behavior of expiring a BPDU in (max_age - message_age) seconds does not apply to RSTP.

For MSTP, the situation is slightly more complex, as MSTP has two independent counters: Message Age that is incremented only between regions, and CIST Remaining Hops that is decremented within an MSTP region. However, both Message Age and CIST Remaining Hops use 20 as their default limit (Message Age must be less than 20; CIST Remaining Hops is initially set to 20 and must not be decreased to 0) so the network would need to grow rather large in order for MST BPDUs to get lost.

What I recall, however, is that older Catalyst IOSes support only a pre-standard 802.1s MSTP while the new IOSes support both pre-standard and standard MSTP, and I remember issues with inter-operating the older and newer MSTP implementation that also resulted in switching loops, just as Sergey observed. Newer IOSes mandate the use of the port-level command spanning-tree mst pre-standard to actually enable interoperation with pre-standard MSTP implementations. Perhaps this was the issue in Sergey's network.

Best regards,

Peter

[Sergey_Yakovets_2]

Hi Peter,

Unfortunately, there is no way for me to check your solution at the moment: I left my prevoius company about a year ago which had this multivendor environment I was trying to put together with MSTP. Speaking of pre-standard versions, the topology I had was trully multivendor, with quite new 3750G in the center and some Allied Telesys switches connected to it. I wish I had a chance to switch the 3570G to pre-standard MSTP to check. Anyway, who knows, maybe some day I would face the same challenge, at least I would know what else I may try if anything similar comes up. Thanks.

Regards,

Sergey

[Peter Paluch]

Hello Sergey,

Thank you very much for returning to this thread and letting us know!

I would be interested as well to see if the switchover to pre-standard MST solved these problems but, well, some things simply don't get solved. I hope the change of your employer was a positive move overall.

Best regards,

Peter